Hi!

On Sun, 2011-04-17 at 11:20:07 +0200, Stefano Zacchiroli wrote:
> On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
> > > The main decision which needs to be made is whether, as a project, we
> > > want source only uploads or to throw away DD built non-all debs.
> > > There's not entire agreement amongst the ftpmasters about this (I err
> > > on the side of the source-only uploads to avoid making people waste
> > > time and bandwidth but that's not the only opinion).
> > <snip>
> > > Once a decision is made, implementation is easy, but I'd like some
> > > form of consensus before we go down that route.
>
> Further round of update on this one, after some more discussion on list
> and a brief chat of mine with Mark.
>
> - There seems to be consensus to go ahead with throw-away debs; they
> require a bit of work though so either be patient or, better,
> volunteer with FTP masters to help out with the implementation of the
> remaining bits.

I think this was mentioned in some previous incarnation of this
discussion, but throwing away debs unconditionally, or at least w/o
having a way to specify they must not be thrown away is going to be
an issue when bootstrapping packages. Those cases where we have
a cyclic build dependency chain, which is not uncommon:

1) Some compilers written in the same language they target.
2) Build tools: pkg-config Build-Depends on libglib2.0-dev,
libglib2.0-dev Build-Depends on pkg-config. pkg-config used to
bundle an ancient glib 1.x to be able to automatically bootstrap
but that was removed with some recent upstream release.
3) IDL generators: mig Build-Depends on gnumach-dev, gnumach
Build-Depends on mig.
4) ...

Having to request ftp-masters each time one of these is first
bootstrapped anew on an architecture is going to be annoying, both
for the porter/packager and for the ftp-masters.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110606081601.GC16010@gaara.hadrons.org">http://lists.debian.org/20110606081601.GC16010@gaara.hadrons.org

On 2011-06-06, Guillem Jover <guillem@debian.org> wrote:
>> - There seems to be consensus to go ahead with throw-away debs; they
>> require a bit of work though so either be patient or, better,
>> volunteer with FTP masters to help out with the implementation of the
>> remaining bits.
> I think this was mentioned in some previous incarnation of this
> discussion, but throwing away debs unconditionally, or at least w/o
> having a way to specify they must not be thrown away is going to be
> an issue when bootstrapping packages. Those cases where we have
> a cyclic build dependency chain, which is not uncommon:

You should still be able to upload binaries. So two uploads, one with the
source and one with the binaries only should still let them be accepted.

I.e. I think we should still allow non-buildd binaries, e.g. for those cases
you mentioned.

Kind regards
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniup5u4.l9s.trash@kelgar.0x539.de">http://lists.debian.org/slrniup5u4.l9s.trash@kelgar.0x539.de

On Mon, 2011-06-06 at 09:03:00 +0000, Philipp Kern wrote:
> On 2011-06-06, Guillem Jover <guillem@debian.org> wrote:
> > I think this was mentioned in some previous incarnation of this
> > discussion, but throwing away debs unconditionally, or at least w/o
> > having a way to specify they must not be thrown away is going to be
> > an issue when bootstrapping packages. Those cases where we have
> > a cyclic build dependency chain, which is not uncommon:
>
> You should still be able to upload binaries. So two uploads, one with the
> source and one with the binaries only should still let them be accepted.

Ah right, and while still slightly cumbersome, it would at least not
be as annoying as needing to prod people around, etc.

> I.e. I think we should still allow non-buildd binaries, e.g. for those
> cases you mentioned.

Yes, please.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110606162543.GA32373@gaara.hadrons.org">http://lists.debian.org/20110606162543.GA32373@gaara.hadrons.org

On 06/06/2011 10:16 AM, Guillem Jover wrote:
> Hi!
>
> On Sun, 2011-04-17 at 11:20:07 +0200, Stefano Zacchiroli wrote:
>> On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
>>>> The main decision which needs to be made is whether, as a project, we
>>>> want source only uploads or to throw away DD built non-all debs.
>>>> There's not entire agreement amongst the ftpmasters about this (I err
>>>> on the side of the source-only uploads to avoid making people waste
>>>> time and bandwidth but that's not the only opinion).
>>> <snip>
>>>> Once a decision is made, implementation is easy, but I'd like some
>>>> form of consensus before we go down that route.
>>
>> Further round of update on this one, after some more discussion on list
>> and a brief chat of mine with Mark.
>>
>> - There seems to be consensus to go ahead with throw-away debs; they
>> require a bit of work though so either be patient or, better,
>> volunteer with FTP masters to help out with the implementation of the
>> remaining bits.
>
> I think this was mentioned in some previous incarnation of this
> discussion, but throwing away debs unconditionally, or at least w/o
> having a way to specify they must not be thrown away is going to be
> an issue when bootstrapping packages. Those cases where we have
> a cyclic build dependency chain, which is not uncommon:
>
> 1) Some compilers written in the same language they target.
> 2) Build tools: pkg-config Build-Depends on libglib2.0-dev,
> libglib2.0-dev Build-Depends on pkg-config. pkg-config used to
> bundle an ancient glib 1.x to be able to automatically bootstrap
> but that was removed with some recent upstream release.
> 3) IDL generators: mig Build-Depends on gnumach-dev, gnumach
> Build-Depends on mig.
> 4) ...
>
> Having to request ftp-masters each time one of these is first
> bootstrapped anew on an architecture is going to be annoying, both
> for the porter/packager and for the ftp-masters.

Are you saying they cannot be bootstrapped with older versions (which
are already in the archive)??!

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4DED107B.3050103@debian.org">http://lists.debian.org/4DED107B.3050103@debian.org

On Mon, 2011-06-06 at 19:38:03 +0200, Luk Claes wrote:
> Are you saying they cannot be bootstrapped with older versions (which
> are already in the archive)??!

By definition if they need to be manually bootstrapped it's because
their build dependencies are not available. The usual cases for that
are a set of NEW packages, existing packages for new architectures,
or for existing architectures where those packages have never built
before.

Take mig on kfreebsd-i386 as an example. To build it we'd first need
to unpack gnumach, manually run “debian/rules build/config.status� and
“make -C build install-data� to just install the headers. Then unpack
mig, remove gnumach-dev from the Build-Depends, build and install the
new mig.deb. Now we can build a clean gnumach, and install the
resulting gnumach-dev. And finally just to make sure, we rebuild a
clean mig (and possibly a cleaner gnumach with the clean mig). We've
just bootstrapped mig ang gnumach on kfreebsd-i386.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110607015208.GA13160@gaara.hadrons.org">http://lists.debian.org/20110607015208.GA13160@gaara.hadrons.org

On Mon, 06 Jun 2011, Philipp Kern wrote:
> I.e. I think we should still allow non-buildd binaries, e.g. for
> those cases you mentioned.

Non-buildd binaries should still be allowed, but they should be
followed immediately by a binNMU. [Are there any cases where we
wouldn't want to rebuild the package after it was bootstrapped?]


Don Armstrong

--
Identical parts aren't.
-- Beach's Law

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110607022454.GU4397@rzlab.ucr.edu">http://lists.debian.org/20110607022454.GU4397@rzlab.ucr.edu

* Don Armstrong (don@debian.org) [110607 04:25]:
> On Mon, 06 Jun 2011, Philipp Kern wrote:
> > I.e. I think we should still allow non-buildd binaries, e.g. for
> > those cases you mentioned.
>
> Non-buildd binaries should still be allowed, but they should be
> followed immediately by a binNMU. [Are there any cases where we
> wouldn't want to rebuild the package after it was bootstrapped?]

There are cases where porters need to upload, because of "funny"
issues. Or hand-builds within sane buildd chroots where the buildd
software refuses. Or similar. (I think I did less than 10 such uploads
recently.)



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110607074538.GU15003@mails.so.argh.org">http://lists.debian.org/20110607074538.GU15003@mails.so.argh.org

On Tue, 07 Jun 2011, Andreas Barth wrote:
> * Don Armstrong (don@debian.org) [110607 04:25]:
> > On Mon, 06 Jun 2011, Philipp Kern wrote:
> > > I.e. I think we should still allow non-buildd binaries, e.g. for
> > > those cases you mentioned.
> >
> > Non-buildd binaries should still be allowed, but they should be
> > followed immediately by a binNMU. [Are there any cases where we
> > wouldn't want to rebuild the package after it was bootstrapped?]
>
> There are cases where porters need to upload, because of "funny"
> issues. Or hand-builds within sane buildd chroots where the buildd
> software refuses. Or similar. (I think I did less than 10 such
> uploads recently.)

Ok. Am I correct that these odd cases are bugs which should be fixed?

If so, it seems reasonable to queue a binNMU, and then file bugs
appropriately if it failed.


Don Armstrong

--
[T]he question of whether Machines Can Think, [...] is about as
relevant as the question of whether Submarines Can Swim.
-- Edsger W. Dijkstra "The threats to computing science"

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110607155947.GV4397@rzlab.ucr.edu">http://lists.debian.org/20110607155947.GV4397@rzlab.ucr.edu

* Don Armstrong (don@debian.org) [110607 18:11]:
> On Tue, 07 Jun 2011, Andreas Barth wrote:
> > * Don Armstrong (don@debian.org) [110607 04:25]:
> > > On Mon, 06 Jun 2011, Philipp Kern wrote:
> > > > I.e. I think we should still allow non-buildd binaries, e.g. for
> > > > those cases you mentioned.
> > >
> > > Non-buildd binaries should still be allowed, but they should be
> > > followed immediately by a binNMU. [Are there any cases where we
> > > wouldn't want to rebuild the package after it was bootstrapped?]
> >
> > There are cases where porters need to upload, because of "funny"
> > issues. Or hand-builds within sane buildd chroots where the buildd
> > software refuses. Or similar. (I think I did less than 10 such
> > uploads recently.)
>
> Ok. Am I correct that these odd cases are bugs which should be fixed?

Usually yes.

> If so, it seems reasonable to queue a binNMU, and then file bugs
> appropriately if it failed.

It's reasonable to queue a binNMU, but it's not to assume that it's
successful. Or that there might be transient issues, e.g. a hand-build
to just complete the transition to testing, and the next source
version is uploaded directly after the transition and built normally.
Or issues, where we don't need to wait for the binNMU to fail, but
just directly file the bug - of course I'm happy to fail the build by
hand in such cases.

As said, all that are exceptions to the rule.



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110607165245.GH2657@mails.so.argh.org">http://lists.debian.org/20110607165245.GH2657@mails.so.argh.org

Hi,

Chipping in late... sorry for that.

2011/6/7 Don Armstrong <don@debian.org>:
> On Tue, 07 Jun 2011, Andreas Barth wrote:

>> > Non-buildd binaries should still be allowed, but they should be
>> > followed immediately by a binNMU. [Are there any cases where we
>> > wouldn't want to rebuild the package after it was bootstrapped?]

>> There are cases where porters need to upload, because of "funny"
>> issues. Or hand-builds within sane buildd chroots where the buildd
>> software refuses. Or similar. (I think I did less than 10 such
>> uploads recently.)

> Ok. Am I correct that these odd cases are bugs which should be fixed?
>
> If so, it seems reasonable to queue a binNMU, and then file bugs
> appropriately if it failed.

FWIW, there are corner cases, besides cyclic build dependencies were a
bootstrap is needed. Some emulators might need some ROM code compiled
on one architecture to be run on another architecture. I have also
attended some requests where people was wanting to access porter boxes
to hand-build packages, IIRC, mlton compiler was one of such cases.
Having said that I believe our build daemon infrastructure is quite
good, but still there are several corner cases where manual uploads
are needed and there is nothing bad about it, even policy is not
against that. If ever consider source-only uploads, please make an
exception to the rule to allow corner cases like the ones discussed,
some to be followed by binNMU, some others not to be followed by
binNMU.

Best regards,
--
*Héctor Orón *-.. . -... .. .- -. * -.. . ...- . .-.. --- .--. . .-.

<free spam>
-- Would you like to make a donation for Debian Conference?
* *** http://debconf11.debconf.org/payments.xhtml **
</free spam>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTikafaw-Br0B4M=_N+t7vevJTrkUsw@mail.gmail.com">http://lists.debian.org/BANLkTikafaw-Br0B4M=_N+t7vevJTrkUsw@mail.gmail.com