FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 12-07-2010, 04:35 AM
Jeffrey Fearn
 
Default Proposed package blocking due to FTBFS

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"

Cheers, Jeff.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-07-2010, 04:41 AM
Matt Domsch
 
Default Proposed package blocking due to FTBFS

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. I don't use koji in my builds, I use
plain vanilla mock, on systems with limited network ability - e.g. no
outbound http/ftp/mail capability.

--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-07-2010, 04:54 AM
Ralf Corsepius
 
Default Proposed package blocking due to FTBFS

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.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-07-2010, 05:01 AM
Jon Masters
 
Default Proposed package blocking due to FTBFS

On Mon, 2010-12-06 at 23:01 -0600, Matt Domsch wrote:

> I trust module-init-tools will get resolved with an impending upstream
> release. Not like that can go unfixed forever. :-)

Should be fixed before Wednesday (tomorrow). I have some fixes for
compressed modules too. Will let you know when this is resolved.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-07-2010, 08:29 AM
Jon Masters
 
Default Proposed package blocking due to FTBFS

On Tue, 2010-12-07 at 01:01 -0500, Jon Masters wrote:
> On Mon, 2010-12-06 at 23:01 -0600, Matt Domsch wrote:
>
> > I trust module-init-tools will get resolved with an impending upstream
> > release. Not like that can go unfixed forever. :-)
>
> Should be fixed before Wednesday (tomorrow). I have some fixes for
> compressed modules too. Will let you know when this is resolved.

This is now done. Thanks.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-07-2010, 03:34 PM
"Richard W.M. Jones"
 
Default Proposed package blocking due to FTBFS

On Mon, Dec 06, 2010 at 11:01:20PM -0600, Matt Domsch wrote:
> mingw32-libglademm24-2.6.7-8.fc12 [u'631374 NEW'] (build/make) sailer,rjones
> mingw32-pangomm-2.26.0-1.fc12 [u'631208 NEW'] (build/make) sailer,rjones
> mingw32-plotmm-0.1.2-4.fc12 [u'631082 NEW'] (build/make) sailer,rjones
> mingw32-gtkmm24-2.19.6-1.fc14 [u'631110 NEW'] (build/make) sailer,rjones

CC-ing to the mailing list. We've hired someone to take over the
"residual maintenance" of the few mingw32 packages that people are
using but not enough to want to take ownership. Unfortunately he
doesn't start for another 3 months.

> ocaml-deriving-0.1.1a-10.fc13 [u'631141 NEW'] (build/make) rjones,ocamlmaint

This will be fixed in the coming OCaml rebuild (F15 feature).

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-07-2010, 06:10 PM
Orcan Ogetbil
 
Default Proposed package blocking due to FTBFS

On Tue, Dec 7, 2010 at 12:01 AM, 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).
>

The subtlety here is that a FTBFS does not imply the package is not
functional. A package may be FTBFS due to various trivial reasons,
e.g. the name of a BuildRequires has changed and the new BuildRequires
does not Provides the old one. In such cases, from the functionality
perspective, the package does not need a rebuild.

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.

Orcan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-07-2010, 07:12 PM
Matt Domsch
 
Default Proposed package blocking due to FTBFS

On Tue, Dec 07, 2010 at 02:10:00PM -0500, Orcan Ogetbil wrote:
> On Tue, Dec 7, 2010 at 12:01 AM, 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).
> >
>
> The subtlety here is that a FTBFS does not imply the package is not
> functional. A package may be FTBFS due to various trivial reasons,
> e.g. the name of a BuildRequires has changed and the new BuildRequires
> does not Provides the old one. In such cases, from the functionality
> perspective, the package does not need a rebuild.
>
> 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.

I believe keeping the distribution self-hosting (meaning, it can build
itself) is an important goal. When we have packages that no longer
build, either through their fault or through the fault of one of their
dependencies, we lose the ability to be self-hosting, and I question
the value of being open source if we can't use that source anymore.


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

Thread Tools




All times are GMT. The time now is 05:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org