Proposed package blocking due to FTBFS
 

On Tue, Dec 7, 2010 at 8:12 PM, Matt Domsch <Matt_Domsch@dell.com> wrote:
>> Note that I am not advocating keeping these packages unfixed. I wanted
>> to point out that things might turn ugly and might even trigger an
>> avalanche when you remove the FTBFS packages from the repo and then
>> the packages that depend on them will start to cry.
>
> skvidal pointed out repoquery --tree-whatrequires can help us find the
> whole affected set of packages. *I'm looking at generating that list
> now. *If we include all ~550 orphan packages in the run, plus the ~100
> FTBFS packages, plus all packages that these depend on, I'm sure it'll
> wind up being a long list. *All the more reason to look _now_, and not
> 2 days before Alpha compose.

Not to over burden you with the FTBFS effort. But to help me best
prioritize my own time it would be great if you configure out a way
for me quickly find the FTBFS packages in the dep chain for the
packages I already co-maintain.

The current representative governing body of voices in my head are not
primarily an altruistic group. To get their resource allocation
approval it would help immensely if I could show them the specific
FTBFS packages that have a direct impact on my current workload.


-jef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

Ralf Corsepius wrote:
> On 12/07/2010 06:41 AM, Matt Domsch wrote:
>> On Tue, Dec 07, 2010 at 03:35:35PM +1000, Jeffrey Fearn wrote:
>>> Matt Domsch wrote:
>>>> I would like to propose blocking packages at the F15 alpha compose
>>>> point if they have not resolved their FTBFS from F14 or earlier. The
>>>> lists may be broken down by when they last did build. With 3
>>>> exceptions, these 110 bugs are all still in NEW state as well, so they
>>>> haven't had much maintainer love in quite some time (6-18 months).
>>>>
>>>> I trust module-init-tools will get resolved with an impending upstream
>>>> release. Not like that can go unfixed forever. :-)
>>>>
>>>> perl-Makefile-Parser-0.211-3.fc14 [u'631098 NEW'] (build/make) nb,nb,perl-sig
>>> Isn't the real bug here that koji is allowing Auto Install to run?
>>>
>>> Koji should be exporting:
>>>
>>> export PERL_EXTUTILS_AUTOINSTALL="--skipdeps"
>> Perhaps- but not Koji - mock.
> No. rpm.specs are supposed to be independent of the context they are
> being built in (... koji, mock, plain rpmbuild or whatever).
>
> I.e. if at all, then it should be rpm which sets something of this kind
> (I am not proposing it to do so.)
>
> ATM, packages need to take precautions that autoinstall doesn't run by
> themselves.

Form over function arguments seem to rule Fedora, which is probably why
I find working in it so utterly frustrating.

Anyway I think the best thing for me to do is stop being a package
maintainer and get off the devel list, then I never have to spend my
time on it again ... which sounds wonderful!

Cheers, Jeff.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On Mon, 2010-12-06 at 23:01 -0600, Matt Domsch wrote:
> I would like to propose blocking packages at the F15 alpha compose
> point if they have not resolved their FTBFS from F14 or earlier.

You better not.

> The
> lists may be broken down by when they last did build. With 3
> exceptions, these 110 bugs are all still in NEW state as well, so they
> haven't had much maintainer love in quite some time (6-18 months).

All the Fedora bugzilla bugs assigned to you, ever:
http://bit.ly/dTndTs
A whole 73.

Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me:
http://bit.ly/gBtVRP
810 bugs.

When you deal with as many bugs as I (or some other people) do can you
take executive decisions on blocking packages in newer revisions.

I bet most of those packages are still functional, and fail to build due
to some minor changes in the build system, or breakage in dependency
libraries.

<snip>
> ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make) dcbw
> NetworkManager-openvpn-0.8.1-1.fc14 [u'631111 NEW'] (build/make) dcbw,choeger,huzaifas,steve
> NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw

And I'm guessing this list didn't get read by humans either.

Feel free to insert here complaints about how the Red Hat bugzilla is
slow, bad at reporting, and that abrt reports with missing attachments,
poor backtraces and no support for tools like GNOME Bugzilla's
simple-dup-finedr aren't helping us keep the bug count down.

And I'll go back to fixing actual bugs encountered by people instead of
random bot-driven bugs.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On Wed, 08 Dec 2010 01:05:06 +0000
Bastien Nocera <bnocera@redhat.com> wrote:

...snip...

> > The
> > lists may be broken down by when they last did build. With 3
> > exceptions, these 110 bugs are all still in NEW state as well, so
> > they haven't had much maintainer love in quite some time (6-18
> > months).
>
> All the Fedora bugzilla bugs assigned to you, ever:
> http://bit.ly/dTndTs
> A whole 73.
>
> Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me:
> http://bit.ly/gBtVRP
> 810 bugs.
>
> When you deal with as many bugs as I (or some other people) do can you
> take executive decisions on blocking packages in newer revisions.

How about asking for help?
Co-maintainers on packages that get lots of bugs?
Have you considered training up some bugzappers to help triage your
components? They could at least work on de-duping abrt reports.

Lets try and get you help...

> I bet most of those packages are still functional, and fail to build
> due to some minor changes in the build system, or breakage in
> dependency libraries.

The ones he's refering to have not built since f12. It's a wonder if
they work at all. ;)

> <snip>
> > ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make)
> > dcbw NetworkManager-openvpn-0.8.1-1.fc14 [u'631111 NEW']
> > (build/make) dcbw,choeger,huzaifas,steve
> > NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw
>
> And I'm guessing this list didn't get read by humans either.

You are refering to the wrong list.

That was a list of all things that don't currently build right now in
rawhide. The proposed block list was much smaller and contained things
that have not been built since f12.

> Feel free to insert here complaints about how the Red Hat bugzilla is
> slow, bad at reporting, and that abrt reports with missing
> attachments, poor backtraces and no support for tools like GNOME
> Bugzilla's simple-dup-finedr aren't helping us keep the bug count
> down.

I'm intrigued. Can we modify 'simple-dup-finder' to work on our
bugzilla? Any docs or pointers to what it does?

...snip...

kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On Mon, Dec 06, 2010 at 11:01:20PM -0600, Matt Domsch wrote:
> I would like to propose blocking packages at the F15 alpha compose
> point if they have not resolved their FTBFS from F14 or earlier. The
> lists may be broken down by when they last did build. With 3
> exceptions, these 110 bugs are all still in NEW state as well, so they
> haven't had much maintainer love in quite some time (6-18 months).
>
> I trust module-init-tools will get resolved with an impending upstream
> release. Not like that can go unfixed forever. :-)
>
>
> Last built on Fedora 12 (52):

And if I resolve all the packages that depend on these 52, I wind up
with a few more (136, but this counts some twice, and is binary
packages, not source package, so not quite as many in reality):

beldi-0:0.9.25-2.fc12.x86_64
celestia-0:1.5.1-2.fc12.x86_64
chm2pdf-0:0.9.1-8.fc14.noarch
classpathx-jaf-0:1.0-15.1.fc12.x86_64
classpathx-jaf-javadoc-0:1.0-15.1.fc12.x86_64
cone-0:0.78-3.fc12.x86_64
cone-devel-0:0.78-3.fc12.i686
cone-devel-0:0.78-3.fc12.x86_64
cone-doc-0:0.78-3.fc12.x86_64
coq-0:8.2pl1-1.fc12.x86_64
coq-coqide-0:8.2pl1-1.fc12.x86_64
coq-doc-0:8.2pl1-1.fc12.x86_64
coq-emacs-0:8.2pl1-1.fc12.x86_64
cpm-0:0.23-0.3.beta.fc12.x86_64
drgeo-0:1.1.0-16.fc12.x86_64
drgeo-doc-0:1.6-11.fc12.noarch
dumbster-0:1.6-9.fc12.noarch
gdmap-0:0.8.1-6.fc12.x86_64
genius-0:1.0.7-1.fc12.x86_64
genius-devel-0:1.0.7-1.fc12.i686
genius-devel-0:1.0.7-1.fc12.x86_64
gnokii-0:0.6.28-1.fc12.i686
gnokii-0:0.6.28-1.fc12.x86_64
gnokii-devel-0:0.6.28-1.fc12.i686
gnokii-devel-0:0.6.28-1.fc12.x86_64
gnokii-smsd-0:0.6.28-1.fc12.x86_64
gnokii-smsd-mysql-0:0.6.28-1.fc12.x86_64
gnokii-smsd-pgsql-0:0.6.28-1.fc12.x86_64
gnome-do-plugins-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-banshee-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-bibtex-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-clawsmail-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-eog-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-epiphany-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-evolution-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-firefox-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-flickr-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-pidgin-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-rhythmbox-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-tasque-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-thunderbird-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-tomboy-0:0.8.2-1.fc12.x86_64
gnome-do-plugins-vinagre-0:0.8.2-1.fc12.x86_64
gnome-genius-0:1.0.7-1.fc12.x86_64
gnome-phone-manager-0:0.65-8.fc14.x86_64
gnome-phone-manager-telepathy-0:0.65-8.fc14.x86_64
gpsk31-0:0.5-4.fc12.x86_64
gshutdown-0:0.2-6.fc12.x86_64
gsql-0:0.2.1-4.fc12.i686
gsql-0:0.2.1-4.fc12.x86_64
gsql-devel-0:0.2.1-4.fc12.i686
gsql-devel-0:0.2.1-4.fc12.x86_64
gsql-engine-mysql-0:0.2.1-4.fc12.x86_64
gsql-plugins-0:0.2.1-4.fc12.x86_64
gtkglextmm-0:1.2.0-10.fc12.i686
gtkglextmm-0:1.2.0-10.fc12.x86_64
gtkglextmm-devel-0:1.2.0-10.fc12.i686
gtkglextmm-devel-0:1.2.0-10.fc12.x86_64
guile-gnome-platform-0:2.16.1-4.fc12.i686
guile-gnome-platform-0:2.16.1-4.fc12.x86_64
guile-gnome-platform-devel-0:2.16.1-4.fc12.i686
guile-gnome-platform-devel-0:2.16.1-4.fc12.x86_64
gwave-0:2-18.20090213snap.fc13.x86_64
htmldoc-0:1.8.27-13.fc12.x86_64
imgtarget-0:0.1.4-4.fc12.x86_64
ipa-server-0:1.2.2-4.fc15.x86_64
jack-audio-connection-kit-0:1.9.6-2.fc15.i686
jack-audio-connection-kit-0:1.9.6-2.fc15.x86_64
javatar-0:2.5-2.fc13.x86_64
kanatest-0:0.4.8-3.fc12.x86_64
kdetv-0:0.8.9-13.fc12.i686
kdetv-0:0.8.9-13.fc12.x86_64
koji-web-0:1.4.0-4.fc15.noarch
kpolynome-0:0.1.2-15.fc12.x86_64
ktechlab-0:0.3.70-3.20090304svn.fc12.x86_64
libctl-0:3.0.2-10.fc12.i686
libctl-0:3.0.2-10.fc12.x86_64
libctl-devel-0:3.0.2-10.fc12.i686
libctl-devel-0:3.0.2-10.fc12.x86_64
libfreebob-0:1.0.11-6.fc12.i686
libfreebob-0:1.0.11-6.fc12.x86_64
libfreebob-devel-0:1.0.11-6.fc12.i686
libfreebob-devel-0:1.0.11-6.fc12.x86_64
libopensync-plugin-gnokii-1:0.22-4.fc12.x86_64
libopensync-plugin-kdepim-1:0.22-6.fc12.x86_64
manaworld-0:0.0.29.1-2.fc12.x86_64
manaworld-music-0:0.0.20-4.fc12.noarch
maven-embedder-0:2.0.4-6.fc12.noarch
maven-embedder-javadoc-0:2.0.4-6.fc12.noarch
maven-plugin-cobertura-0:2.3-3.fc12.noarch
maven-plugin-cobertura-javadoc-0:2.3-3.fc12.noarch
mingw32-gtkmm24-0:2.19.6-1.fc14.noarch
mingw32-libglademm24-0:2.6.7-8.fc12.noarch
mingw32-pangomm-0:2.26.0-1.fc12.noarch
mingw32-plotmm-0:0.1.2-4.fc12.noarch
mod_auth_kerb-0:5.4-5.fc12.x86_64
multiget-0:1.2.0-7.fc12.x86_64
netgo-0:0.5-12.fc12.x86_64
notecase-0:1.6.1-6.fc12.x86_64
oorexx-0:4.0.0-2.4801.fc12.x86_64
oorexx-devel-0:4.0.0-2.4801.fc12.i686
oorexx-devel-0:4.0.0-2.4801.fc12.x86_64
oorexx-docs-0:4.0.0-2.4801.fc12.x86_64
oorexx-libs-0:4.0.0-2.4801.fc12.i686
oorexx-libs-0:4.0.0-2.4801.fc12.x86_64
openvas-client-0:3.0.0-8.fc14.x86_64
ovirt-server-0:0.100-5.fc15.noarch
petitboot-0:0.2-4.fc12.x86_64
pigment-0:0.3.17-3.fc12.i686
pigment-0:0.3.17-3.fc12.x86_64
pigment-devel-0:0.3.17-3.fc12.i686
pigment-devel-0:0.3.17-3.fc12.x86_64
pigment-python-0:0.3.12-3.fc14.x86_64
postgresql-pgpool-ha-0:1.1.0-8.fc12.noarch
python-visual-0:5.40-2.fc15.x86_64
qgo-0:1.5.4r2-3.fc12.x86_64
qtgpsc-0:0.2.3-6.fc12.x86_64
quarry-0:0.2.0-5.fc12.x86_64
qucs-0:0.0.15-4.fc12.x86_64
raidem-0:0.3.1-11.fc12.x86_64
raidem-music-0:1.0-4.fc12.noarch
rubygem-attributes-0:5.0.1-5.fc12.noarch
rubygem-cobbler-0:1.6.1-1.fc12.noarch
rubygem-main-0:4.0.0-1.fc13.noarch
sear-0:0.6.3-14.fc12.x86_64
starlab-0:4.4.3-7.fc12.x86_64
starlab-devel-0:4.4.3-7.fc12.i686
starlab-devel-0:4.4.3-7.fc12.x86_64
starlab-libs-0:4.4.3-7.fc12.i686
starlab-libs-0:4.4.3-7.fc12.x86_64
subtitlecomposer-0:0.5.3-3.fc12.x86_64
tuxpaint-stamps-0:2008.06.30-3.fc12.noarch
valknut-0:0.4.9-3.fc12.x86_64
xgnokii-0:0.6.28-1.fc12.x86_64
xscorch-0:0.2.1-0.4.pre2.fc12.x86_64
xsri-1:2.1.0-17.fc12.x86_64


My goal isn't to make life difficult for everyone. My goal is to keep
the distribution in a form where it can actually build from the open
source we provide.

If you own a leaf package, and thus would be affected by one of your
dependencies going unloved, please consider resolving the FTBFS bug
for your dependent package, and your fellow maintainer.

Thanks,
Matt

--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On Wed, 2010-12-08 at 01:05 +0000, Bastien Nocera wrote:

> And I'll go back to fixing actual bugs encountered by people instead of
> random bot-driven bugs.

every abrt report, ever, is an actual bug encountered by an actual
person. They have to be sufficiently narked about the app crashing (and
it really must have crashed) to click through a rather convoluted
process (the first time, anyway) to send in a report.

so are all these bugs, for that matter: they're actual bugs encountered
by Matt. The package failing to build is clearly a bug. Matt tried to
build it and so encountered the bug. Where does it fail to meet your
criteria?

I agree it's a bit questionable whether we should block packages for
FTBFS, but the argument can clearly be made; being self-hosting is
obviously important for an F/OSS project. At some point it devolves into
Stallmanite wankery about whether you can flash your mouse, but where
exactly we should draw the line isn't a slam-dunk :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On 12/08/2010 09:50 AM, Adam Williamson wrote:
> On Wed, 2010-12-08 at 01:05 +0000, Bastien Nocera wrote:

> I agree it's a bit questionable whether we should block packages for
> FTBFS,

IMO, there can't be any doubt about FTBFS's to be "must fixes" and them
to release blockers for packages being affected.

Rationale:
- It's important packages are buildable at any time, to be able to
quickly react on bugs.

- Packages, which are hit by FTBFS issues often suffer from other but
"mere technical issues", e.g. maintainers having gone AWOL, the package
being of low quality, maintainers not being sufficiently skilled etc.

- Packages, which are hit by FTBFS issue often reveil hidden packaging
issues (e.g. broken deps having silently being introduced), which should
be addressed as soon as possible to prevent other packages from being
infected with "work-arounds" (e.g. redundant package deps or
configuration hackery).

- FTBFS issues occasionally reveil global issues, which so far have
managed to get away unaddressed/unnoticed (e.g. compiler bugs, toolchain
issues etc.)

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On Tue, 2010-12-07 at 18:12 -0700, Kevin Fenzi wrote:
> On Wed, 08 Dec 2010 01:05:06 +0000
> Bastien Nocera <bnocera@redhat.com> wrote:
>
> ...snip...
>
> > > The
> > > lists may be broken down by when they last did build. With 3
> > > exceptions, these 110 bugs are all still in NEW state as well, so
> > > they haven't had much maintainer love in quite some time (6-18
> > > months).
> >
> > All the Fedora bugzilla bugs assigned to you, ever:
> > http://bit.ly/dTndTs
> > A whole 73.
> >
> > Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me:
> > http://bit.ly/gBtVRP
> > 810 bugs.
> >
> > When you deal with as many bugs as I (or some other people) do can you
> > take executive decisions on blocking packages in newer revisions.
>
> How about asking for help?
> Co-maintainers on packages that get lots of bugs?
> Have you considered training up some bugzappers to help triage your
> components? They could at least work on de-duping abrt reports.
>
> Lets try and get you help...
>
> > I bet most of those packages are still functional, and fail to build
> > due to some minor changes in the build system, or breakage in
> > dependency libraries.
>
> The ones he's refering to have not built since f12. It's a wonder if
> they work at all. ;)

Well, they probably did, or at least I didn't get any reports saying
they don't.

> > <snip>
> > > ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make)
> > > dcbw NetworkManager-openvpn-0.8.1-1.fc14 [u'631111 NEW']
> > > (build/make) dcbw,choeger,huzaifas,steve
> > > NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw
> >
> > And I'm guessing this list didn't get read by humans either.
>
> You are refering to the wrong list.

>From Matt:
"
I would like to propose blocking packages at the F15 alpha compose
point if they have not resolved their FTBFS from F14 or earlier.
"

So that means that those packages would have gotten blocked.

> That was a list of all things that don't currently build right now in
> rawhide. The proposed block list was much smaller and contained things
> that have not been built since f12.

Again, that's not what's mentioned above.

> > Feel free to insert here complaints about how the Red Hat bugzilla is
> > slow, bad at reporting, and that abrt reports with missing
> > attachments, poor backtraces and no support for tools like GNOME
> > Bugzilla's simple-dup-finedr aren't helping us keep the bug count
> > down.
>
> I'm intrigued. Can we modify 'simple-dup-finder' to work on our
> bugzilla? Any docs or pointers to what it does?

GNOME's dup finder:
http://git.gnome.org/browse/bugzilla-newer/tree/dupfinder

The README is probably outdated, as per:
http://live.gnome.org/BugzillaUpgrade/UpgradeStatus#Simple-dup-finder

KDE and a number of other bugzillas seem to have similar infrastructure.
I'm pretty sure it wouldn't work due to abrt's use of attachments
instead of full backtraces.

Also sorely missing from the RH bugzilla is an equivalent to the
"browse" functionality in the GNOME BZ:
https://bugzilla.gnome.org/browse.cgi

And the fact that NEEDINFO is a real status, not a flag, which makes it
easier to filter.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On Wed, Dec 8, 2010 at 1:12 AM, Kevin Fenzi <kevin@scrye.com> wrote:
> On Wed, 08 Dec 2010 01:05:06 +0000
> Bastien Nocera <bnocera@redhat.com> wrote:
>
> ...snip...
>
>> > * The
>> > lists may be broken down by when they last did build. *With 3
>> > exceptions, these 110 bugs are all still in NEW state as well, so
>> > they haven't had much maintainer love in quite some time (6-18
>> > months).
>>
>> All the Fedora bugzilla bugs assigned to you, ever:
>> http://bit.ly/dTndTs
>> A whole 73.
>>
>> Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me:
>> http://bit.ly/gBtVRP
>> 810 bugs.
>>
>> When you deal with as many bugs as I (or some other people) do can you
>> take executive decisions on blocking packages in newer revisions.
>
> How about asking for help?
> Co-maintainers on packages that get lots of bugs?
> Have you considered training up some bugzappers to help triage your
> components? They could at least work on de-duping abrt reports.

I agree with Bastien on this one. Its very hard and if I spent all my
time dealing with abrt bug reports I'd never do anything else. Besides
I thought abrt was support to support de-dupe.

>> I bet most of those packages are still functional, and fail to build
>> due to some minor changes in the build system, or breakage in
>> dependency libraries.
>
> The ones he's refering to have not built since f12. It's a wonder if
> they work at all. ;)

For some reason I thought we'd had a mass rebuild since f-12 but maybe
that was just python and other sub group stuff. That aside I know of a
number of packages that haven't been rebuilt since F-12 and work just
fine.

>> <snip>
>> > ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make)
>> > dcbw NetworkManager-openvpn-0.8.1-1.fc14 [u'631111 NEW']
>> > (build/make) dcbw,choeger,huzaifas,steve
>> > NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw
>>
>> And I'm guessing this list didn't get read by humans either.
>
> You are refering to the wrong list.
>
> That was a list of all things that don't currently build right now in
> rawhide. The proposed block list was much smaller and contained things
> that have not been built since f12.

I don't think blocking things that haven't been rebuilt is such a good
criteria. I also happen to know of at least 1 library that fails to
build on rawhide and F-14 and works perfectly well and if it was
removed I think a large chunk of gnome 3 would fail based on the
dependency tree. I bet that would put the cat amongst the pigeons!

>> Feel free to insert here complaints about how the Red Hat bugzilla is
>> slow, bad at reporting, and that abrt reports with missing
>> attachments, poor backtraces and no support for tools like GNOME
>> Bugzilla's simple-dup-finedr aren't helping us keep the bug count
>> down.

It was my understanding that abrt was suppose to block on backtraces
without debuginfo but I still regularly get bugs with little or no
decent info. What's worse is often they are the first report and abrt
de-dupes against that report and still doesn't automatically either
update the backtrace with a complete one from other reports or attach
a new one. So you end up in a situation with a bug report with 30
dupes and have to ask the users to attach a manual complete one. Not
ideal!

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed package blocking due to FTBFS
 

On Wed, Dec 8, 2010 at 8:50 AM, Adam Williamson <awilliam@redhat.com> wrote:
> On Wed, 2010-12-08 at 01:05 +0000, Bastien Nocera wrote:
>
>> And I'll go back to fixing actual bugs encountered by people instead of
>> random bot-driven bugs.
>
> every abrt report, ever, is an actual bug encountered by an actual
> person. They have to be sufficiently narked about the app crashing (and
> it really must have crashed) to click through a rather convoluted
> process (the first time, anyway) to send in a report.

Or 1 person submits a report 30 times each time with an incomplete
backtrace and then asks why you haven't fixed their bug yet which you
can't recreate or debug!

> so are all these bugs, for that matter: they're actual bugs encountered
> by Matt. The package failing to build is clearly a bug. Matt tried to
> build it and so encountered the bug. Where does it fail to meet your
> criteria?
>
> I agree it's a bit questionable whether we should block packages for
> FTBFS, but the argument can clearly be made; being self-hosting is
> obviously important for an F/OSS project. At some point it devolves into
> Stallmanite wankery about whether you can flash your mouse, but where
> exactly we should draw the line isn't a slam-dunk :)

I'm sitting on the fence on this one. There are packages built on F-12
that work perfectly well on rawhide that don't build on rawhide. What
about an instance where there's dependant packages. Do they
automatically get blocked too or do we go through another route of
FTBFS on those too? In the case of a leaf one it might be that by it
not building currently doesn't affect anything and the maintainer is
aware of the problem but needs the time to fix the issue properly when
he gets time. In this case the maintainer then has to jump through the
review process all over again to get it unblocked and then will likely
just not be bothered. I have this case with moblin-panel-media. Its
been dropped by upstream but people have shown interest in it
remaining so they don't need to have mono. It needs patches to build
but I've not had time to deal with it (see the issues with meego in
general atm) but I'm aware of the problem and will get to it
eventually.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel