Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu Development (http://www.linux-archive.org/ubuntu-development/)
-   -   Archive rebuild proposal for Lucid (http://www.linux-archive.org/ubuntu-development/270460-archive-rebuild-proposal-lucid.html)

Scott Kitterman 10-28-2009 04:31 AM

Archive rebuild proposal for Lucid
 
Here are some numbers for where we stand on the ever of release for FTBFS in
Karmic:

http://qa.ubuntuwire.org/ftbfs/

389 packages FTBFS on at least one arch. Only 12 are in Main.

We did a rebuild test that started September 9th and took a few weeks to run:

http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-
karmic.html

1,226 packages FTBFS on at least one arch during the test (which is only an
approximation of what we could do in the archive in many respects). 93 of
these were in Main.

641 packages (of which 90 were in Main) had uploads after the rebuild. Most
should have done better, but we didn't have an easy way to track exactly.

585 packages (of which 3 were in Main) weren't uploaded again after the
rebuild and are presumably unbuildable currently.

When I first looked at these numbers I thought they were very impressive and a
good basis for confidence about our situation. More than half the packages
that FTBFS in the rebuild had post-rebuild uploads and the difference between
the known FTBFS (389) and the known unfixed rebuild FTBFS (585) doesn't seem
like a lot and some of these packages got removed, narrowing the gap further.
In the context of 16,158 source packages in Karmic, that's a small percentage.

When I looked the second time, I noticed something that made me a lot more
concerned. The 389 number from the archive is all 7 architectures. The 585
from the rebuild is only i386 and amd64. If I look at the i386/amd64 FTBFS in
the archive it's only 55 (of which none are in Main). So the apples to apples
comparison isn't 389/585, it's 55/585.

When I look at it that way, I'm a lot more concerned that we have a significant
fraction of the archive that's unbuildable on at least some architectures and
is unsupportable/fixable (this is particularly concerning for security
support). In many cases these are easy to fix, but some are equally almost
impossible.

Particularly for Lucid, since it's an LTS release, we want everything to be
supportable.

My proposal is that once the Lucid toolchain is in place, we do another
archive rebuild test and then do a binary removal of any packages that fail
(modulo not completely breaking the archive and having to reboostrap). From
then on, we could be confident that any package that had a binary had built at
least once during the cycle and should build/be relatively easily buildable
after release.

I wouldn't propose removing source, because we want these to get fixed.

Along these lines, I did ask for removal of one package that couldn't be built
that had sat untouched since before Warty released. We have a lot of really
old dead stuff that no one is going to miss.

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Lucas Nussbaum 10-28-2009 07:05 PM

Archive rebuild proposal for Lucid
 
On 28/10/09 at 01:31 -0400, Scott Kitterman wrote:
> We did a rebuild test that started September 9th and took a few weeks to run:

Hi,

If that's helpful, I could do some rebuild during the Lucid cycle using
a grid infrastructure I have access to (I do some for Debian on a
regular basis). I can do them for i386 and amd64, and it only takes ~8
hours to rebuild all the packages on both arches.

However, it's unlikely that I will have time to process the results, so
I would only provide a list of packages that FTBFS, and access to the
logs. Someone else would have to do the analysis.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Scott Kitterman 10-28-2009 07:16 PM

Archive rebuild proposal for Lucid
 
On Wed, 28 Oct 2009 21:05:32 +0100 Lucas Nussbaum
<lucas@lucas-nussbaum.net> wrote:
>On 28/10/09 at 01:31 -0400, Scott Kitterman wrote:
>> We did a rebuild test that started September 9th and took a few weeks to
run:
>
>Hi,
>
>If that's helpful, I could do some rebuild during the Lucid cycle using
>a grid infrastructure I have access to (I do some for Debian on a
>regular basis). I can do them for i386 and amd64, and it only takes ~8
>hours to rebuild all the packages on both arches.
>
>However, it's unlikely that I will have time to process the results, so
>I would only provide a list of packages that FTBFS, and access to the
>logs. Someone else would have to do the analysis.
>

That would be very helpful. One of the problems with the Launchpad rebuild
system is how long it takes and the archive skew that happens in the mean
time.

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Morten Kjeldgaard 10-29-2009 08:25 AM

Archive rebuild proposal for Lucid
 
On 28/10/2009, at 06.31, Scott Kitterman wrote:

> My proposal is that once the Lucid toolchain is in place, we do
> another
> archive rebuild test and then do a binary removal of any packages
> that fail
> (modulo not completely breaking the archive and having to
> reboostrap). From
> then on, we could be confident that any package that had a binary
> had built at
> least once during the cycle and should build/be relatively easily
> buildable
> after release.
>
> I wouldn't propose removing source, because we want these to get
> fixed.

+1

I think this is a very sensible thing to do. It's been a problem in
karmic that the rebuild happened so late in the cycle; many of the
packages on the FTBFS list had -*ubuntu1 tags, so it would be relevant
to take care of these problems very early on in the cycle, especially
because many of the problems are toolchain related.

In addition, I suggest that the rebuilding script files a bug on LP
when a package FTBFS. This will help us get the problems fixed in the
normal work-flow, and the bug-fix history of the package will be
recorded under +source which will help Debian maintainers and ourselves.

Cheers,
Morten


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

"Michael Bienia" 10-29-2009 09:04 AM

Archive rebuild proposal for Lucid
 
On 2009-10-29 10:25:39 +0100, Morten Kjeldgaard wrote:
> I think this is a very sensible thing to do. It's been a problem in
> karmic that the rebuild happened so late in the cycle; many of the
> packages on the FTBFS list had -*ubuntu1 tags, so it would be relevant
> to take care of these problems very early on in the cycle, especially
> because many of the problems are toolchain related.

We should do an archive rebuild twice: once at the beginning of a
release cycle to see what doesn't build anymore with the new toolchain
and to have enough time to fix it and once near the end to catch those
packages which broke during the development of the next release.

E.g. while karmic changed very early to gcc-4.4, it only changed from
glibc 2.9 to eglibc 2.10 in the middle of karmic schedule. The
combination of g++ 4.4 and eglibc 2.10 enforces a more strict ISO C++
compliance which caused several FTBFS found by the late archive rebuild.
You wouldn't find them in an early archive rebuild.

> In addition, I suggest that the rebuilding script files a bug on LP
> when a package FTBFS. This will help us get the problems fixed in the
> normal work-flow, and the bug-fix history of the package will be
> recorded under +source which will help Debian maintainers and ourselves.

Please don't or only if you can filter out false positives. Some FTBFS
are caused by one arch being faster than an other and thus a
build-dependency being temporarily not installable.

Michael

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

"Michael Bienia" 10-29-2009 09:29 AM

Archive rebuild proposal for Lucid
 
On 2009-10-28 01:31:43 -0400, Scott Kitterman wrote:
> When I looked the second time, I noticed something that made me a lot more
> concerned. The 389 number from the archive is all 7 architectures. The 585
> from the rebuild is only i386 and amd64. If I look at the i386/amd64 FTBFS in
> the archive it's only 55 (of which none are in Main). So the apples to apples
> comparison isn't 389/585, it's 55/585.

Did you substract those "Upload errors" from the archive rebuild? Those
packages build successfully but couldn't get uploaded to the rebuild
archive because of a bug in LP which was fixed for production but not
for the rebuild archive. That are around 70 packages.

> My proposal is that once the Lucid toolchain is in place, we do another
> archive rebuild test and then do a binary removal of any packages that fail
> (modulo not completely breaking the archive and having to reboostrap). From
> then on, we could be confident that any package that had a binary had built at
> least once during the cycle and should build/be relatively easily buildable
> after release.

+1 on the basis that it will be announced so we don't blame LP for
eating debs again :)
And more important a page listing source packages with missing debs so
we know which source packages needs looking at. Without such a page only
a fraction of the deleted debs will come back.

Michael

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Matthias Klose 10-29-2009 10:14 AM

Archive rebuild proposal for Lucid
 
On 29.10.2009 11:04, Michael Bienia wrote:
> On 2009-10-29 10:25:39 +0100, Morten Kjeldgaard wrote:
>> In addition, I suggest that the rebuilding script files a bug on LP
>> when a package FTBFS. This will help us get the problems fixed in the
>> normal work-flow, and the bug-fix history of the package will be
>> recorded under +source which will help Debian maintainers and ourselves.
>
> Please don't or only if you can filter out false positives. Some FTBFS
> are caused by one arch being faster than an other and thus a
> build-dependency being temporarily not installable.

but a lot of these would point out to build dependencies which should be more
tight. seen at least with many gnome and kde uploads where pkg-config did
complain about a version not recent enough. catching this with a build
dependency puts the package is dep-wait, and then is retried after some time.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Scott Kitterman 10-30-2009 10:20 PM

Archive rebuild proposal for Lucid
 
On Wed, 28 Oct 2009 21:05:32 +0100 Lucas Nussbaum
<lucas@lucas-nussbaum.net> wrote:
>On 28/10/09 at 01:31 -0400, Scott Kitterman wrote:
>> We did a rebuild test that started September 9th and took a few weeks to
run:
>
>Hi,
>
>If that's helpful, I could do some rebuild during the Lucid cycle using
>a grid infrastructure I have access to (I do some for Debian on a
>regular basis). I can do them for i386 and amd64, and it only takes ~8
>hours to rebuild all the packages on both arches.
>
>However, it's unlikely that I will have time to process the results, so
>I would only provide a list of packages that FTBFS, and access to the
>logs. Someone else would have to do the analysis.
>

Once we have the toolchain for Lucid in place (should be very shortly) I
think it would be great to do this. Ubuntuwire.com will host a
summary/status page to support developers doing analysis.

Thanks,

Scott K

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


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

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.