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 > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-09-2008, 09:15 PM
Evgeni Golov
 
Default pre-building NEW packages, when they only introduce new binary packages

Hi *,

at the moment I am preparing the next release of pokerth, which will
contain the pokerth-server package. As this one is new, the whole
pokerth will have to go through NEW again.
However, there is already pokerth 0.6-1-2 in the archive and I do not
change the source tarball, so the chances I made something really bad I
would get a REJECT for are low.

I thought it would be a (time) improvement, when a package which already
has an orig.tar.gz in the archive, but introduces a new binary package,
hits NEW the buildds could start building it (at a low priority)
without uploading to the archive and then wait for the ftp-masters to
approve the package, after what the buildds would upload the already
finished packages.
That probably won't make much time difference on "fast" archs (i386,
amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
hold up testing transition ).

Regards
Evgeni
 
Old 02-10-2008, 12:10 AM
Philippe Cloutier
 
Default pre-building NEW packages, when they only introduce new binary packages

That probably won't make much time difference on "fast" archs (i386,
amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
hold up testing transition ).
A missing build will only slow testing migration if the package wasn't
built when the unstable testing delay is over. Since almost all uploads
to NEW are low urgency, the build would need to take over 10 days to
affect the time to testing migration. To speed up testing migration due
to missing builds, it would be much more efficient to work on buildd
redundancy (or other improvements to the buildd network).



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-10-2008, 06:06 PM
Evgeni Golov
 
Default pre-building NEW packages, when they only introduce new binary packages

On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:

> > That probably won't make much time difference on "fast" archs (i386,
> > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > hold up testing transition ).
> A missing build will only slow testing migration if the package wasn't
> built when the unstable testing delay is over. Since almost all uploads
> to NEW are low urgency, the build would need to take over 10 days to
> affect the time to testing migration.

pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet
uploaded] today), so it *can* make a difference (not a really big one
though in this case)

> To speed up testing migration due
> to missing builds, it would be much more efficient to work on buildd
> redundancy (or other improvements to the buildd network).

More/faster buildds, nicer dependencies etc, sure. But why not this one
too?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-11-2008, 08:02 AM
Charles Plessy
 
Default pre-building NEW packages, when they only introduce new binary packages

Le Sun, Feb 10, 2008 at 08:06:38PM +0100, Evgeni Golov a écrit :
> On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
>
> > > That probably won't make much time difference on "fast" archs (i386,
> > > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > > hold up testing transition ).
> > A missing build will only slow testing migration if the package wasn't
> > built when the unstable testing delay is over. Since almost all uploads
> > to NEW are low urgency, the build would need to take over 10 days to
> > affect the time to testing migration.
>
> pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet
> uploaded] today), so it *can* make a difference (not a really big one
> though in this case)

Indeed, especially that it has been said that having the buildds not
keeping up is not uncommon during a release cycle, implementing a
mechanism to reduce the impact of this problem would be a good thing.

We are ending up in a similar stress situation as for last release, when
uploading to NEW many weeks before the freeze we were wondering if the
package would be part of the release or not. People with
responsibilities in Debian's core infrastructures should consider that
it is demotivating for many.

Have a nice day,

--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-11-2008, 06:44 PM
Philippe Cloutier
 
Default pre-building NEW packages, when they only introduce new binary packages

On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:

> > That probably won't make much time difference on "fast" archs (i386,
> > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > hold up testing transition ).
> A missing build will only slow testing migration if the package wasn't
> built when the unstable testing delay is over. Since almost all uploads
> to NEW are low urgency, the build would need to take over 10 days to
> affect the time to testing migration.


pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet
uploaded] today), so it *can* make a difference (not a really big one
though in this case)

Ah, yes. I misinterpreted your message. I thought you meant that the
package would spend more than the testing transition delay actually
compiling, which is not reasonable. I see others reasons to mention slow
arches:

1. Builds tend to take more time to be signed
2. Builds tend to fail more often
3. Slow arches are more often unable to keep up

Your suggestion could help with 1 and 2, but not really with 3. If the
NEW package gets earlier in the queue, it's built more quickly, but
packages that come later are built more slowly. And 3 must be the main
reason for the delay in this case, presumably more than 90% of the delay.


> To speed up testing migration due
> to missing builds, it would be much more efficient to work on buildd
> redundancy (or other improvements to the buildd network).


More/faster buildds, nicer dependencies etc, sure. But why not this one
too?
I didn't mean this one shouldn't be done. I just meant that if it
should, it's a low priority one.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-12-2008, 12:48 AM
Charles Plessy
 
Default pre-building NEW packages, when they only introduce new binary packages

Le Mon, Feb 11, 2008 at 02:44:59PM -0500, Philippe Cloutier a écrit :
>
> If the NEW package gets earlier in the queue, it's built more quickly,
> but packages that come later are built more slowly.

Dear Philippe,

if the ressources are scarce, I think that it would be fair that the
internal competition for the access to them would be organised in a
productive way. The current system disfavours the works that changes the
structure of the package. How does this fit in a strategy to optimise
the usage of the buildd power in Debian?

Of course there are alternatives to competition. When a buildd has a
15-day queue for more than a month, we could agree to refrain from
uploading changes that can be postponed, in the same spirit as the
people who share their cars when trains are on strike.

An alternative approach would be to add a buildd, but for a reason that
I do not understand, it seems to be off-topic on this list. So let's
learn the "décroissance" way in Debian, it is a good training for real
life anyway.

Have a nice day,

--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-12-2008, 01:58 AM
Philippe Cloutier
 
Default pre-building NEW packages, when they only introduce new binary packages

Dear Philippe,

if the ressources are scarce, I think that it would be fair that the
internal competition for the access to them would be organised in a
productive way. The current system disfavours the works that changes the
structure of the package. How does this fit in a strategy to optimise
the usage of the buildd power in Debian?

It avoids building packages that will be rejected.

If by "disfavour" you imply that it's intentional that NEW packages
aren't built before being accepted, I think you're wrong. I think it
would require not completely trivial changes.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-12-2008, 07:19 AM
Joerg Jaspert
 
Default pre-building NEW packages, when they only introduce new binary packages

On 11293 March 1977, Philippe Cloutier wrote:

Lets jump in here, even if not all points address your mail only.

> If by "disfavour" you imply that it's intentional that NEW packages
> aren't built before being accepted, I think you're wrong. I think it
> would require not completely trivial changes.

It *is* intentional that NEW queue packages wont get build
automagically.

One of the reasons is that we arent allowed to transfer
packages from NEW outside of the US, unless we accept them into the
archive. (US export laws and stuff and lalala, details can be read in
threads way in the past when crypto in main went live. The basic
knowledge is: NEW has to be in the US and packages not exported unless
they are accepted into the archive).


Now, one might limit the packages to such ones that already got accepted
in the past and "just" change binary package names. But thats IMO much more
work than it will ever gain us, as you

- need to sort out which packages are ok to get autobuild from NEW
- need to make them accessible to the buildds in some way. And only
them.
- Have to let buildds and wanna-build look at yet another location for
packages and build them
- Have to sort them into the queue somehow. If you go and sort them
"below everything in unstable" then you wont have *any* advantage
from "autobuilding NEW", as only faster architectures will ever
built them, as the slower ones wont get down that far in the queue.

And last, but also most complicated:

- Need a way for all the buildd admins to see when they can finally
sign a build log for a NEW package (after it got accepted), or when
they need to go and delete it, as it wont ever get accepted, thanks
to a REJECT. While you can do the first automagical by, lets say,
looking at incoming.debian.org or packages files, you can't do the
latter in any good way. Packages might get rejected due to some
issue in them, and then maintainers are free to upload them with the
same version to NEW again.[1]

The whole thing is just way less benefit compared to the work one needs
to do for it.

[1] Yes, for REJECTs you can re-use the version number. The archive only
requires new versions when the package got visible for users.

--
bye Joerg
< vorlon> I realize the risk of portability problems is lower than with certain other desktop
environments beginning with K that will go unnamed


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-12-2008, 09:04 PM
Philippe Cloutier
 
Default pre-building NEW packages, when they only introduce new binary packages

Le February 12, 2008 03:19:47 am Joerg Jaspert, vous avez crit :
> On 11293 March 1977, Philippe Cloutier wrote:
>
> Lets jump in here, even if not all points address your mail only.
>
> > If by "disfavour" you imply that it's intentional that NEW packages
> > aren't built before being accepted, I think you're wrong. I think it
> > would require not completely trivial changes.
>
> It *is* intentional that NEW queue packages wont get build
> automagically.
[...]
>
> Now, one might limit the packages to such ones that already got accepted
> in the past and "just" change binary package names. But thats IMO
much more

> work than it will ever gain us, as you
[...]
> - Have to sort them into the queue somehow. If you go and sort them
> "below everything in unstable" then you wont have *any* advantage
> from "autobuilding NEW", as only faster architectures will ever
> built them, as the slower ones wont get down that far in the queue.
You do get the advantage that builds for faster archs are ready right
away. Also, slow archs don't necessarily always have a queue. They just
need to have more buildds than fast archs. At the moment, "only" hppa
and mips* have significant queues, so...at least arm would build sooner.


[...]
>
> The whole thing is just way less benefit compared to the work one needs
> to do for it.

Thanks.
Of course, it *is* intentional not to throw NEW packages to the buildd
network in its current form, since it's not designed to support that. I
was talking about whether it was intentional to autobuild *none* of NEW.
Your mail clarifies that this is not intentional, we just don't have the
infrastructure for it, but we agree that even if it's possible to
autobuild at least parts, this would be low priority work.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-13-2008, 09:39 AM
Vincent Danjean
 
Default pre-building NEW packages, when they only introduce new binary packages

Evgeni Golov wrote:
> On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
>
>>> That probably won't make much time difference on "fast" archs (i386,
>>> amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
>>> hold up testing transition ).
>> A missing build will only slow testing migration if the package wasn't
>> built when the unstable testing delay is over. Since almost all uploads
>> to NEW are low urgency, the build would need to take over 10 days to
>> affect the time to testing migration.
>
> pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet
> uploaded] today), so it *can* make a difference (not a really big one
> though in this case)

paje.app 1.97+cvs20080110-2 did not built on mipsel for 26 days:
http://packages.qa.debian.org/p/paje.app.html
http://buildd.debian.org/build.php?arch=mipsel&pkg=paje.app&ver=1.97%2Bcvs2 0080110-2

I wrote a mail to mipsel@buildd.debian.org (I put them in CC of this mail again)
asking to trigger a build on 5 feb. I got no answer (can someone confirm that
I'm using the good address email) ?

I really hope this package will be build soon: paje.app was removed from testing a few
time ago due to old FTBFS bugs. I would like this version to be in testing some times
before the lenny freeze (new upstream version with new GNUStep libraries)
Currently, paje.app in unstable 1.97+cvs20080110-2 has no bugs for 26 days but mipsel
build is missing and preventing testing migration...

Best regards,
Vincent


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 11:08 AM.

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