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 07-10-2011, 09:31 PM
Jon Masters
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, 2011-07-10 at 16:23 -0500, Matt Domsch wrote:
> On Sun, Jul 10, 2011 at 04:43:30PM +0100, Matthew Garrett wrote:
> > On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote:
> >
> > > * Fedora should (IMO) institute mandatory mass rebuilds. Either every
> > > cycle, or every other cycle. I've briefly discussed with Dennis.
> > > Bootstrapping (and similar activities) are far easier with a clean set
> > > of deps, which is the case for F15. It should always be the case that we
> > > know everything builds and self-hosts through a mass rebuild per cycle.
> >
> > This has been raised with FESCO in the past, and I don't think there's
> > any fudnamental disagreement on it. But scheduling one mass rebuild per
> > cycle doesn't prevent us ending up in a broken state unless we do it
> > right at the end of the cycle, and right now that's problematic in terms
> > of release process - rebuilding everything we've just QAed is an
> > excellent way to introduce subtle breakage. So it really needs to be an
> > out-of-archive verification rather than one that's targetted at the
> > release, and we need the resources and manpower to handle it.
>
> Alternately, we could take a lesson from our compatriots at openSUSE.
> Their openSUSE Build Service throws a combination of automated
> intelligence and hardware at the problem. Given the package
> dependency tree, if package B BuildRequires package A, then every time
> A gets rebuilt, B is also bumped and rebuilt.

This is, in my opinion, the correct way to solve the problem. You can't
really know if something FTBFS unless you do this kind of thing. I'd go
further and advocate for sufficient hardware to continually rebuild
everything daily and automate bootstrap like Debian are looking into,
but that's all stuff for the future.

> This causes build
> breakage to get caught fairly early in the process (rather than via an
> asynchronous out-of-tree process), and the resulting packages are available in
> their equivalent of the rawhide tree for test and use.

It doesn't just benefit bootstrap either. Take (random example) the
recent CFLAGS change in redhat-rpm-config. What should happen at that
point is that every package is automatically rebuilt. Should it cause a
problem? No. But having packages randomly fail to build later because of
some change made months or even years earlier is something to fix.

I know I'm preaching to the choir here. There are many reasonable
reasons why some of these problems exist, and it's no failure on the
part of rel-eng folks, who do their best.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-10-2011, 09:44 PM
Matthew Garrett
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, Jul 10, 2011 at 05:31:09PM -0400, Jon Masters wrote:

> It doesn't just benefit bootstrap either. Take (random example) the
> recent CFLAGS change in redhat-rpm-config. What should happen at that
> point is that every package is automatically rebuilt. Should it cause a
> problem? No. But having packages randomly fail to build later because of
> some change made months or even years earlier is something to fix.

That change was made based on the assumption that there'll be a mass
rebuild in the F16 timescale. It's not practical for us to insist on
mass rebuilds every time we make an individual change, especially since
in this case we'd have had to do it again once it's moved to ldflags
rather than cflags.

It's certainly true that we could do more to identify ftbfs situations
earlier, but we've had mass rebuilds in most recent releases. Random
failures years down the line really aren't a realistic concern.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-10-2011, 10:11 PM
Peter Robinson
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, Jul 10, 2011 at 10:44 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:

On Sun, Jul 10, 2011 at 05:31:09PM -0400, Jon Masters wrote:



> It doesn't just benefit bootstrap either. Take (random example) the

> recent CFLAGS change in redhat-rpm-config. What should happen at that

> point is that every package is automatically rebuilt. Should it cause a

> problem? No. But having packages randomly fail to build later because of

> some change made months or even years earlier is something to fix.



That change was made based on the assumption that there'll be a mass

rebuild in the F16 timescale. It's not practical for us to insist on

mass rebuilds every time we make an individual change, especially since

in this case we'd have had to do it again once it's moved to ldflags

rather than cflags.



It's certainly true that we could do more to identify ftbfs situations

earlier, but we've had mass rebuilds in most recent releases. Random

failures years down the line really aren't a realistic concern.


I actually disagree. I've been working on rebuilding F-14 for the current softfp arm platform that doesn't need to be boot strapped. The amount of packages in Fedora 14 that don't compile on the main intel platform even if I do a plain vanilla F-14 install with no updates (ie it was broken on release and wasn't any better with any of the updates). There wasn't a mass rebuild for F-14, just for perl and python dependencies.


Even with the F-15 mass rebuild I've found a number of packages that their owners never bothered to fix the FTBFS that was a result of the F-15 mass rebuild that have caused me problems that I've had to fix because the owner of the package never bothered to fix the FTBFS.


Peter

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-10-2011, 10:12 PM
Jon Masters
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, 2011-07-10 at 22:44 +0100, Matthew Garrett wrote:

> It's certainly true that we could do more to identify ftbfs situations
> earlier, but we've had mass rebuilds in most recent releases. Random
> failures years down the line really aren't a realistic concern.

I can think of specific cases where dependent packages failed to rebuild
6 months later because of an earlier change, and I'm sure we can find
some involving years at a time. Further, there are some noarch packages
that haven't been rebuilt in many releases, but that's another issue.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-10-2011, 10:34 PM
Matthew Garrett
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, Jul 10, 2011 at 06:12:38PM -0400, Jon Masters wrote:
> On Sun, 2011-07-10 at 22:44 +0100, Matthew Garrett wrote:
>
> > It's certainly true that we could do more to identify ftbfs situations
> > earlier, but we've had mass rebuilds in most recent releases. Random
> > failures years down the line really aren't a realistic concern.
>
> I can think of specific cases where dependent packages failed to rebuild
> 6 months later because of an earlier change, and I'm sure we can find
> some involving years at a time. Further, there are some noarch packages
> that haven't been rebuilt in many releases, but that's another issue.

6 months isn't even one year, let alone many. Let's avoid hyperbole.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-10-2011, 10:49 PM
Matthew Garrett
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, Jul 10, 2011 at 11:11:52PM +0100, Peter Robinson wrote:
> On Sun, Jul 10, 2011 at 10:44 PM, Matthew Garrett <mjg59@srcf.ucam.org>wrote:
> > It's certainly true that we could do more to identify ftbfs situations
> > earlier, but we've had mass rebuilds in most recent releases. Random
> > failures years down the line really aren't a realistic concern.
> >
> >
> I actually disagree. I've been working on rebuilding F-14 for the current
> softfp arm platform that doesn't need to be boot strapped. The amount of
> packages in Fedora 14 that don't compile on the main intel platform even if
> I do a plain vanilla F-14 install with no updates (ie it was broken on
> release and wasn't any better with any of the updates). There wasn't a mass
> rebuild for F-14, just for perl and python dependencies.
>
> Even with the F-15 mass rebuild I've found a number of packages that their
> owners never bothered to fix the FTBFS that was a result of the F-15 mass
> rebuild that have caused me problems that I've had to fix because the owner
> of the package never bothered to fix the FTBFS.

Finding that something that didn't build, hasn't been changed and still
doesn't build isn't terribly random We could do better, but
introducing more mass rebuilds as part of the release cycle isn't going
to make things significantly better when we're already failing to deal
with the fallout from the mass rebuilds we *do* carry out. Fixing this
is a process issue rather than one that's fixed by having FESCO mandate
a mass rebuild after every change that could conceivably cause breakage.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-10-2011, 10:59 PM
Peter Robinson
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, Jul 10, 2011 at 11:49 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:

On Sun, Jul 10, 2011 at 11:11:52PM +0100, Peter Robinson wrote:

> On Sun, Jul 10, 2011 at 10:44 PM, Matthew Garrett <mjg59@srcf.ucam.org>wrote:

> > It's certainly true that we could do more to identify ftbfs situations

> > earlier, but we've had mass rebuilds in most recent releases. Random

> > failures years down the line really aren't a realistic concern.

> >

> >

> I actually disagree. I've been working on rebuilding F-14 for the current

> softfp arm platform that doesn't need to be boot strapped. The amount of

> packages in Fedora 14 that don't compile on the main intel platform even if

> I do a plain vanilla F-14 install with no updates (ie it was broken on

> release and wasn't any better with any of the updates). There wasn't a mass

> rebuild for F-14, just for perl and python dependencies.

>

> Even with the F-15 mass rebuild I've found a number of packages that their

> owners never bothered to fix the FTBFS that was a result of the F-15 mass

> rebuild that have caused me problems that I've had to fix because the owner

> of the package never bothered to fix the FTBFS.



Finding that something that didn't build, hasn't been changed and still

doesn't build isn't terribly random We could do better, but

introducing more mass rebuilds as part of the release cycle isn't going

to make things significantly better when we're already failing to deal

with the fallout from the mass rebuilds we *do* carry out. Fixing this

is a process issue rather than one that's fixed by having FESCO mandate

a mass rebuild after every change that could conceivably cause breakage.



If a mass rebuild causes breakage its a problem which ever way you look at it, the package will eventually be rebuilt and cause the breakage, in my opinion your better off doing that in a controlled manner rather than sweeping it under the carpet and hoping no one will notice.


Peter


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-10-2011, 11:02 PM
Matthew Garrett
 
Default Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY

On Sun, Jul 10, 2011 at 11:59:36PM +0100, Peter Robinson wrote:
> On Sun, Jul 10, 2011 at 11:49 PM, Matthew Garrett <mjg59@srcf.ucam.org>wrote:
> > Finding that something that didn't build, hasn't been changed and still
> > doesn't build isn't terribly random We could do better, but
> > introducing more mass rebuilds as part of the release cycle isn't going
> > to make things significantly better when we're already failing to deal
> > with the fallout from the mass rebuilds we *do* carry out. Fixing this
> > is a process issue rather than one that's fixed by having FESCO mandate
> > a mass rebuild after every change that could conceivably cause breakage.
> >
> >
> If a mass rebuild causes breakage its a problem which ever way you look at
> it, the package will eventually be rebuilt and cause the breakage, in my
> opinion your better off doing that in a controlled manner rather than
> sweeping it under the carpet and hoping no one will notice.

I agree, but if we're failing to deal with FTBFS with the number of mass
rebuilds we currently have, introducing more mass rebuilds doesn't
magically make things better.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:57 PM.

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