Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Wed, 2011-06-29 at 02:17 -0400, Jon Masters wrote:
> Hi Folks,
>
> Join us on Friday to celebrate July with another in our series of VFADs!

Hi Jon,

Just a heads up that you won't have many Canadians joining you -- July 1
is Canada Day, a *big* party date on our calendar.

-Chris

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

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Wed, 2011-06-29 at 02:17 -0400, Jon Masters wrote:
> Hi Folks,
>
> Join us on Friday to celebrate July with another in our series of VFADs!

Hi Jon,

Just a heads up that you won't have many Canadians joining you -- July 1
is Canada Day, a *big* party date on our calendar.

-Chris

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

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Wed, 2011-06-29 at 08:02 -0400, Chris Tyler wrote:
> On Wed, 2011-06-29 at 02:17 -0400, Jon Masters wrote:
> > Hi Folks,
> >
> > Join us on Friday to celebrate July with another in our series of VFADs!

> Just a heads up that you won't have many Canadians joining you -- July 1
> is Canada Day, a *big* party date on our calendar.

Absolutely! Happy Canada Day!

Yea, I did know, and I'm aware the July 4th holiday is happening in the
US on Monday, so we'll see a lot of people being away, but for
consistency, I'll still help out with anyone who turns up :) I want to
get into a regular rhythm with this being a Friday thing.

Jon.


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

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote:

> We are hosting another one of our regular Fedora 15 hardfp Virtual
> Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern
> Daylight Time). The purpose of this session is to co-ordinate the
> bootstrap of F15 hardfp (hardware floating point). Going forward, the
> proposal is that these remain on Fridays, and at the same time.

As a followup, we now have a working yum installation. Next week, we
will be working on support for mock. Once we have these, we can build up
missing dependencies, then rebuild everything we have with rpmbuild. At
that point, we can rebuild everything within mock and Koji-fyificate.

It's becoming clear that several points do need raising with FESCo:
* 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.
* Fedora would benefit from an explicit position on the dependency
explosion we're seeing in basic packages. Without going off too far into
my personal opinions on a need to respect UNIX heritage, etc. I will say
that the explosion of requirements is going to be a problem for any
future efforts and will get worse without guidance.

Meanwhile, enjoy working yum. Next week, working mock, hopefully.

Thanks,

Jon.


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

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Sun, Jul 10, 2011 at 12:45 AM, Jon Masters <jcm@redhat.com> wrote:
> On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote:
>
>> We are hosting another one of our regular Fedora 15 hardfp Virtual
>> Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern
>> Daylight Time). The purpose of this session is to co-ordinate the
>> bootstrap of F15 hardfp (hardware floating point). Going forward, the
>> proposal is that these remain on Fridays, and at the same time.
>
> As a followup, we now have a working yum installation. Next week, we
> will be working on support for mock. Once we have these, we can build up
> missing dependencies, then rebuild everything we have with rpmbuild. At
> that point, we can rebuild everything within mock and Koji-fyificate.
>
> It's becoming clear that several points do need raising with FESCo:
> * * * ** 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.
> * * * ** Fedora would benefit from an explicit position on the dependency
> explosion we're seeing in basic packages. Without going off too far into
> my personal opinions on a need to respect UNIX heritage, etc. I will say
> that the explosion of requirements is going to be a problem for any
> future efforts and will get worse without guidance.
>
> Meanwhile, enjoy working yum. Next week, working mock, hopefully.
>
> Thanks,
>
> Jon.
>
>

I agree, we must have a bootstrapping guide.


--
------------

Itamar Reis Peixoto
msn, google talk: itamar@ispbrasil.com.br
+55 11 4063 5033 (FIXO SP)
+55 34 9158 9329 (TIM)
+55 34 8806 3989 (OI)
+55 34 3221 8599 (FIXO MG)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Sun, 2011-07-10 at 00:48 -0300, Itamar Reis Peixoto wrote:
> On Sun, Jul 10, 2011 at 12:45 AM, Jon Masters <jcm@redhat.com> wrote:
> > On Fri, 2011-07-08 at 00:52 -0400, Jon Masters wrote:
> >
> >> We are hosting another one of our regular Fedora 15 hardfp Virtual
> >> Fedora Activity Day today Friday July 8th, at 14:00UTC (10:00 Eastern
> >> Daylight Time). The purpose of this session is to co-ordinate the
> >> bootstrap of F15 hardfp (hardware floating point). Going forward, the
> >> proposal is that these remain on Fridays, and at the same time.
> >
> > As a followup, we now have a working yum installation. Next week, we
> > will be working on support for mock. Once we have these, we can build up
> > missing dependencies, then rebuild everything we have with rpmbuild. At
> > that point, we can rebuild everything within mock and Koji-fyificate.
> >
> > It's becoming clear that several points do need raising with FESCo:
> > * 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.
> > * Fedora would benefit from an explicit position on the dependency
> > explosion we're seeing in basic packages. Without going off too far into
> > my personal opinions on a need to respect UNIX heritage, etc. I will say
> > that the explosion of requirements is going to be a problem for any
> > future efforts and will get worse without guidance.
> >
> > Meanwhile, enjoy working yum. Next week, working mock, hopefully.

> I agree, we must have a bootstrapping guide.

We're going to deliver one after this armv7hl bootstrap. What we're
going to do is get koji running with a minimal mock (or even once we get
to just mock) and then re-run the bootstrap scripts
automatically/rebuild the RPMs and hope that we caught every
customization we needed. Those that were missed will be documented, then
everything will be written up. Maybe not Shakespeare, but sufficiently.

The wider problem that feeds from this is setting guidance. I'll throw
some recommendations out there as a result of the bootstrap, not limited
to just the two observations so far. Debian and others have much more
comprehensive documentation on this stuff and that needs fixing.

Jon.


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

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Sun, Jul 10, 2011 at 6:31 AM, Jon Masters <jcm@redhat.com> wrote:
>
> We're going to deliver one after this armv7hl bootstrap. What we're
> going to do is get koji running with a minimal mock (or even once we get
> to just mock) and then re-run the bootstrap scripts
> automatically/rebuild the RPMs and hope that we caught every
> customization we needed. Those that were missed will be documented, then
> everything will be written up. Maybe not Shakespeare, but sufficiently.
>
> The wider problem that feeds from this is setting guidance. I'll throw
> some recommendations out there as a result of the bootstrap, not limited
> to just the two observations so far. Debian and others have much more
> comprehensive documentation on this stuff and that needs fixing.
>
> Jon.



how hard is to add a flag bootstrap in rpm spec file to all base
packages needed to start ?


--
------------

Itamar Reis Peixoto
msn, google talk: itamar@ispbrasil.com.br
+55 11 4063 5033 (FIXO SP)
+55 34 9158 9329 (TIM)
+55 34 8806 3989 (OI)
+55 34 3221 8599 (FIXO MG)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote:
> It's becoming clear that several points do need raising with FESCo:
> * 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.

I agree with Jon 100%.

As folks know, I have been an ardent supporter of self-hosting since I
started working with Linux (and RHL/Fedora) 12 years ago. I'm not
alone in this position, and have had the help of many maintainers over
the years to fix FTBFS bugs as I've uncovered and reported them -
Thank You!

However, I haven't had as much time to put into that effort recently
as I believe it deserves. FESCo asked me to draft a procedure [1], a
task from [2] for ensuring identified FTBFS packages were blocked,
which I've done. But the procedure lacks a key component -
identifying, through Fedora Project-maintained efforts (and not my own
private efforts), the list of pacakges that FTBFS. That could be a
rel-eng mass rebuild run. That could be a stand-alone rebuild effort.
I'm not going to dictate. I have had some interest from individuals
asking how they could help, but they seemed to be daunted by the need
for a good deal of builder resources to do a mass rebuild in a
reasonable amount of time. And unfortunately, I'm not in a position
to put the builders I scrounged up on the public internet for use.

If self-hosting and reliable package building is important to you,
please chime in with ideas for how we can make this a standard part of
the Fedora release process.


[1] https://fedoraproject.org/wiki/Deprecate_FTBFS_packages
[2] https://fedoraproject.org/wiki/Release_Engineering_Release_Tickets

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

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

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.

> * Fedora would benefit from an explicit position on the dependency
> explosion we're seeing in basic packages. Without going off too far into
> my personal opinions on a need to respect UNIX heritage, etc. I will say
> that the explosion of requirements is going to be a problem for any
> future efforts and will get worse without guidance.

My personal opinion is that bootstrapping is an intrinsically difficult
and time consuming exercise. I'm enthusiastic about changes that make it
easier, but not if they come at the cost of providing features that
maintainers want to provide. It's rare for us to need to start an
architecture from scratch, and I think optimising for rare cases is
misguided.

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

Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
 

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 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.

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