Debian Bug report logs - #699808
tech-ctte: syslinux vs the wheezy release

Package: tech-ctte; Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Julien Cristau <jcristau@debian.org>

Date: Tue, 5 Feb 2013 12:51:01 UTC

Severity: normal

Fixed in version syslinux/3:4.05+dfsg-6+deb7u2

Done: Daniel Baumann <daniel@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, syslinux@packages.debian.org, debian-release@lists.debian.org, debian-boot@lists.debian.org, leader@debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#699808; Package tech-ctte. (Tue, 05 Feb 2013 12:51:04 GMT) (full text, mbox, link).

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
New Bug report received and forwarded. Copy sent to syslinux@packages.debian.org, debian-release@lists.debian.org, debian-boot@lists.debian.org, leader@debian.org, Technical Committee <debian-ctte@lists.debian.org>. (Tue, 05 Feb 2013 12:51:04 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Package: tech-ctte

[cc to syslinux maintainer, debian-release, debian-boot, leader]

Hi,

the background for this request can be found in bug#699382.  Here are
the highlights:
- the debian-installer source package, which builds the installer images
  for debian's releases, build-depends on syslinux
- the release freeze for wheezy started in June 2012, and is now in its
  final stages
- one of the prerequisites for the release is a release candidate for
  the installer
- the syslinux maintainer uploaded new upstream versions of his package
  to unstable, which were unsuitable for wheezy, in November 2012, and
  again at the end of January 2013
- the latest of these uploads breaks the installer, making it impossible
  to build and upload the planned wheezy release candidate, since
  build-dependencies are fetched from unstable
- when asked to revert this change, the syslinux maintainer refused, and
  said disagreements should be referred to the technical committee

The submitters consider this disregard for the Debian release process
not acceptable, and ask that the technical committee
- overrule the syslinux maintainer, and decide that the syslinux package
  in unstable should be reverted to the version currently in wheezy (or a
  version compatible with the release team's freeze policy), until
  the wheezy release
- rule that the syslinux package maintainer should be willing to
  collaborate with maintainers of its reverse-dependencies (and in
  particular the Debian Installer team) in a way that's compatible with
  Debian's release processes, and not against them.

The submitters sincerely hope that all parties can work together for a
speedy resolution to this problem, avoiding further delay to this
release.

Thanks,
Julien Cristau - for the release team
Cyril Brulebois - d-i release manager

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#699808; Package tech-ctte. (Tue, 05 Feb 2013 13:12:06 GMT) (full text, mbox, link).

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 05 Feb 2013 13:12:06 GMT) (full text, mbox, link).

Message #10 received at 699808@bugs.debian.org (full text, mbox, reply):

or:

  * apply the following tested and working patch from #699742 in
    debian-installer, consisting of this ('trimmed' output rather than
    full-diff):

---snip---
+if [ -e /usr/lib/syslinux/ldlinux.c32 ]; then \
+	mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/ldlinux.c32 ::ldlinux.c32; \
+	mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/libcom32.c32 ::libcom32.c32; \
+	mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/libutil.c32 ::libutil.c32; \
+fi; \
---snap--

    note that it is needed for wheezy+1 anyway, and even
    should be considered anyway for wheezy in order to allow using
    building stable images with syslinux backports (as needed for some
    people for better hw support, and specifically for future syslinux
    uefi images; similar as to which e.g. changes to debootstrap for
    stable+1 are desireable in stable).

that way:

  * unstable remains usable for the maintainer to do work even during
    freezes, not effectively 'freezing testing *and* unstable but
    without freezing unstable technically'.

  * keep experimental 'free' to use for experimental syslinux 6.x with
    UEFI support.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 05 Feb 2013 23:33:08 GMT) (full text, mbox, link).

Message #15 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Daniel Baumann <daniel.baumann@progress-technologies.net> (05/02/2013):
> or:
> 
>   * apply the following tested and working patch from #699742 in
>     debian-installer, […]

Except that this “tested and working patch” doesn't fix anything. Same
issue, as seen by Michael and myself.

KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 05 Feb 2013 23:57:05 GMT) (full text, mbox, link).

Message #20 received at 699808@bugs.debian.org (full text, mbox, reply):

On Wed, 06 Feb 2013, Cyril Brulebois wrote:
> Daniel Baumann <daniel.baumann@progress-technologies.net> (05/02/2013):
> > or:
> > 
> >   * apply the following tested and working patch from #699742 in
> >     debian-installer, […]
> 
> Except that this “tested and working patch” doesn't fix anything. Same
> issue, as seen by Michael and myself.

Is it the intention of the Release Managers not to accept a newer
version of syslinux into wheezy? [That is, if the CTTE were to decide
to require some "fix" to d-i, we'd also have to override the RMs?]


Don Armstrong

-- 
I now know how retro SCOs OSes are. Riotous, riotous stuff. How they
had the ya-yas to declare Linux an infant OS in need of their IP is
beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over
TCP. The 80's called, they want their features back.
 -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html

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

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#699808; Package tech-ctte. (Wed, 06 Feb 2013 10:00:08 GMT) (full text, mbox, link).

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 10:00:08 GMT) (full text, mbox, link).

Message #25 received at 699808@bugs.debian.org (full text, mbox, reply):

On 05.02.2013 23:55, Don Armstrong wrote:
> On Wed, 06 Feb 2013, Cyril Brulebois wrote:
>> Daniel Baumann <daniel.baumann@progress-technologies.net> 
>> (05/02/2013):
>> > or:
>> >
>> >   * apply the following tested and working patch from #699742 in
>> >     debian-installer, […]
>>
>> Except that this “tested and working patch” doesn't fix anything. 
>> Same
>> issue, as seen by Michael and myself.
>
> Is it the intention of the Release Managers not to accept a newer
> version of syslinux into wheezy? [That is, if the CTTE were to decide
> to require some "fix" to d-i, we'd also have to override the RMs?]

Given that the syslinux packages in sid are a different major upstream
version from those in wheezy, with a raw diffstat of

 621 files changed, 36622 insertions(+), 15023 deletions(-)

and that upstream version has been in unstable for a little over a week 
in
total, I'm certainly uncomfortable that accepting the new version at 
this
point would be in the best interest of the release. We've already said 
"no" to
changes in other packages which were significantly smaller and didn't 
carry
the possibility of affecting something as key as the installer.

Shipping an installer that was built with a differing version of 
syslinux
than we eventually ship also causes me concern, since the first update 
to d-i in
a point release will obviously be rebuilt against wheezy's syslinux. 
This
introduces a situation that we can't reasonably test beforehand, as we 
could no
longer be confident that the released version of the wheezy installer 
could be
correctly booted on all of our architectures.

(tl,dr; right now, "yes, we believe the changes are too potentially 
disruptive".)

Regards,

Adam

Acknowledgement sent to Stefano Zacchiroli <leader@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 13:45:08 GMT) (full text, mbox, link).

Message #30 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, Feb 05, 2013 at 01:48:22PM +0100, Julien Cristau wrote:
> The submitters sincerely hope that all parties can work together for a
> speedy resolution to this problem, avoiding further delay to this
> release.

As a possibly useful data point for procedural reasons: I've verified on
IRC with the submitters that this issue is blocking the release of d-i
version RC1.  As such, I'd appreciate if the tech-ctte could prioritize
this issue over others submitted to their attention (this might imply
increasing the severity of this bug as needed).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Anthony Towns <aj@erisian.com.au>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 14:18:05 GMT) (full text, mbox, link).

Message #35 received at 699808@bugs.debian.org (full text, mbox, reply):

On 5 February 2013 22:48, Julien Cristau <jcristau@debian.org> wrote:
> Package: tech-ctte

> - the debian-installer source package, which builds the installer images
>   for debian's releases, build-depends on syslinux
> - the release freeze for wheezy started in June 2012, and is now in its
>   final stages
> - one of the prerequisites for the release is a release candidate for
>   the installer
> - the syslinux maintainer uploaded new upstream versions of his package
>   to unstable, which were unsuitable for wheezy, in November 2012, and
>   again at the end of January 2013
> - the latest of these uploads breaks the installer, [...]

Isn't this a rationale for d-i to use the stable builds of syslinux
present in testing (or potentially testing-proposed-updates) rather
than unstable?

Cheers,
aj

-- 
Anthony Towns <aj@erisian.com.au>

Message #40 received at 699808@bugs.debian.org (full text, mbox, reply):

On 06.02.2013 14:17, Anthony Towns wrote:
> On 5 February 2013 22:48, Julien Cristau <jcristau@debian.org> wrote:
>> Package: tech-ctte
>
>> - the debian-installer source package, which builds the installer 
>> images
>>   for debian's releases, build-depends on syslinux
>> - the release freeze for wheezy started in June 2012, and is now in 
>> its
>>   final stages
>> - one of the prerequisites for the release is a release candidate 
>> for
>>   the installer
>> - the syslinux maintainer uploaded new upstream versions of his 
>> package
>>   to unstable, which were unsuitable for wheezy, in November 2012, 
>> and
>>   again at the end of January 2013
>> - the latest of these uploads breaks the installer, [...]
>
> Isn't this a rationale for d-i to use the stable builds of syslinux
> present in testing (or potentially testing-proposed-updates) rather
> than unstable?

It's a build-dependency in the (debian-installer) source package, so 
will naturally be pulled from whichever suite that package is being 
built in.

I assume it could instead be downloaded from a mirror during the build 
process, similarly to udebs, but my understanding was that we were 
trying to reduce the use of such mechanisms within the d-i build, rather 
than adding more of them.

Regards,

Adam

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 14:48:03 GMT) (full text, mbox, link).

Message #45 received at 699808@bugs.debian.org (full text, mbox, reply):

On Thu, Feb  7, 2013 at 00:17:16 +1000, Anthony Towns wrote:

> On 5 February 2013 22:48, Julien Cristau <jcristau@debian.org> wrote:
> > Package: tech-ctte
> 
> > - the debian-installer source package, which builds the installer images
> >   for debian's releases, build-depends on syslinux
> > - the release freeze for wheezy started in June 2012, and is now in its
> >   final stages
> > - one of the prerequisites for the release is a release candidate for
> >   the installer
> > - the syslinux maintainer uploaded new upstream versions of his package
> >   to unstable, which were unsuitable for wheezy, in November 2012, and
> >   again at the end of January 2013
> > - the latest of these uploads breaks the installer, [...]
> 
> Isn't this a rationale for d-i to use the stable builds of syslinux
> present in testing (or potentially testing-proposed-updates) rather
> than unstable?
> 
Not any more than it is a rationale for any other package currently
uploaded to unstable and targetted at wheezy to get its
build-dependencies from testing?  I.e. probably not...

Cheers,
Julien

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 15:36:07 GMT) (full text, mbox, link).

Message #50 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/06/2013 12:55 AM, Don Armstrong wrote:
> Is it the intention of the Release Managers not to accept a newer
> version of syslinux into wheezy? [That is, if the CTTE were to decide
> to require some "fix" to d-i, we'd also have to override the RMs?]

jftr, i never did nor intended to ask for having syslinux 5 in wheezy. 
what i care about is having it in unstable (for reasons said earlier).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Milan Kupcevic <milan@physics.harvard.edu>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 17:21:08 GMT) (full text, mbox, link).

Message #55 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 02/06/2013 10:38 AM, Daniel Baumann wrote:
> On 02/06/2013 12:55 AM, Don Armstrong wrote:
>> Is it the intention of the Release Managers not to accept a newer
>> version of syslinux into wheezy? [That is, if the CTTE were to decide
>> to require some "fix" to d-i, we'd also have to override the RMs?]
> 
> jftr, i never did nor intended to ask for having syslinux 5 in wheezy.
> what i care about is having it in unstable (for reasons said earlier).
> 

Well, the d-i development is happening in sid. Therefore, this upload
disrupted the development process of syslinux dependent d-i components
that have to end up, but are not yet in wheezy.

Milan

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 19:45:04 GMT) (full text, mbox, link).

Message #60 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/06/2013 03:17 PM, Anthony Towns wrote:
> Isn't this a rationale for d-i to use the stable builds of syslinux
> present in testing (or potentially testing-proposed-updates) rather
> than unstable?

exactely; it is fundamentally broken to build a $distribution image 
containing anything outside the $distribution itself (which is why e.g. 
live-build doesn't do that (unless told otherwise for special 'needs')).

if it is (socially) not possible to fix the tools and therefore building 
$distribution means that $distribution+1 needs to be frozen too, then 
either freeze both $distribution and $distribution+1, or freeze a 
certain list of packages in $distribution+1 in addition to $distribution 
that are known-needed for $distribution (as syslinux).

keeping $distribution+1 unfrozen but at the same time not allowing it to 
be used as unfrozen is broken (i already said why using experimental 
doesn't work in this case).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #63 received at 699808@bugs.debian.org (full text, mbox, reply):

On Tue, 05 Feb 2013, Julien Cristau wrote:
> - the latest of these uploads breaks the installer, making it
>   impossible to build and upload the planned wheezy release
>   candidate, since build-dependencies are fetched from unstable

> - when asked to revert this change, the syslinux maintainer refused,
>   and said disagreements should be referred to the technical
>   committee

Assuming that the patch for #699742[0] fixes this issue with DI RC
releases being installed, is there still an outstanding issue for the
CTTE?

[I can understand a bit of wariness of having d-i built with a version
of syslinux that isn't being distributed in wheezy, but I think that
might need to be discussed and a technical solution fleshed out
elsewhere, and probably isn't ripe for a CTTE decision.]


Don Armstrong

0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#30 
1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#40

-- 
[Panama, 1989. The U.S. government called it "Operation Just Cause".]
I think they misspelled this. Shouldn't it be "Operation Just 'Cause"?
 -- TekPolitik http://slashdot.org/comments.pl?sid=59669&cid=5664907

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

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 21:12:06 GMT) (full text, mbox, link).

Message #68 received at 699808@bugs.debian.org (full text, mbox, reply):

Don Armstrong <don@debian.org> writes:

> Assuming that the patch for #699742[0] fixes this issue with DI RC
> releases being installed, is there still an outstanding issue for the
> CTTE?

Earlier in this thread, there had been a couple of reports that fix didn't
work.  I haven't looked further, though.

> [I can understand a bit of wariness of having d-i built with a version
> of syslinux that isn't being distributed in wheezy, but I think that
> might need to be discussed and a technical solution fleshed out
> elsewhere, and probably isn't ripe for a CTTE decision.]

In practice, at least for the last couple of release cycles, we freeze
unstable for non-leaf packages during the release freeze because otherwise
it's too difficult with our current infrastructure to finish the release.
I believe this has even been made explicit in release-team updates,
although I haven't gone back and checked the exact wording.

I concur with Daniel and with Anthony that it does feel like a deficiency
in our tools that we don't have a way to distinguish wheezy-targeted
packages from post-wheezy development and build wheezy-targeted packages
with the build dependencies that will be released with wheezy.  If we had
such a thing, I think it would save the release team some time, since it
would limit the problems caused by uncoordinated library transitions
during the release freeze.  I also concur with Daniel that it can make
development during the release freeze rather annoying when there are
multiple branches of upstream that one wants to follow, since we only have
one other archive available for packages that aren't eligible for release.

But, well, that's the architecture we have right now and we're clearly not
going to fix it immediately.  Given that, I think it makes sense to, as
Daniel mentioned, make it rather explicit that, yes, unstable is frozen
for non-leaf packages until we complete the release.  And, in this
specific case, to revert the syslinux update in unstable (and hopefully
upload to experimental) so that we're not building d-i against a package
that isn't part of the release.

That does take over experimental for that purpose, but, well, there's
always personal repositories; that's what I sometimes do when there are
more branches of development to juggle than there is space in Debian.
It's annoying, and we need better tools, but it's possible.

In the longer term, I think it would be interesting to provide some more
metadata and automation around the whole release request/unblock/build
process than we have right now.  For example, I could see some use in a
system where one has to explicitly tag a package as being targeted for the
next release or not targeted for the next release, which could be
communicated to the buildds in some fashion so that they would build
release-targeted packages against only the release-targeted packages, and
new uploads of release-targeted packages would be automatically diffed and
brought to the release team's attention.  There could even be a convention
for including the justification for the change.  (I can see a lot of
complexity here in how one would have to set up the archive suites, since
you can't just point the buildds at testing since there would be no way to
stage library transitions that *are* going into the release, so let me
note that this is not a well-thought-out proposal, just the sketch of an
idea.)  But that's all outside the scope of tech-ctte deliberation, since
that's technical design, and regardless isn't something that we would do
right now.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 22:18:05 GMT) (full text, mbox, link).

Message #73 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 06.02.2013 17:48, Michael Biebl wrote:
> Hi,
> 
> On 06.02.2013 16:36, Daniel Baumann wrote:
>> On 02/05/2013 09:33 PM, Michael Biebl wrote:
>>> I tried this patch against cc123e0 from debian-installer git.
>>> Unfortunately the problem is still the same.
>>
>> indeed; only the first part of the patch was attached; here's the 
>> complete one.
> 
> I can confirm that this patch works now. Thanks.

I have to correct myself: While the bootloader now does show up (when
trying an installation in VBOX), and I no longer get the error message
about the missing ldlinux.c32 file, it hangs after selecting the Install
option. The screen just stays black.

This didn't happen with syslinux 4.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 22:27:10 GMT) (full text, mbox, link).

Message #78 received at 699808@bugs.debian.org (full text, mbox, reply):

On Wed, 06 Feb 2013, Russ Allbery wrote:
> Don Armstrong <don@debian.org> writes:
> 
> > Assuming that the patch for #699742[0] fixes this issue with DI RC
> > releases being installed, is there still an outstanding issue for the
> > CTTE?
> 
> Earlier in this thread, there had been a couple of reports that fix didn't
> work.  I haven't looked further, though.

Yeah, that was for the first incomplete patch. I was referring to the
second one.


Don Armstrong

-- 
Let us chat together a moment, my friend. There are still several
hours until dawn, and I have the whole day to sleep.
 -- Count Orlock in _Nosferatu (1922)_

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

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 06 Feb 2013 22:27:13 GMT) (full text, mbox, link).

Message #83 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Russ Allbery <rra@debian.org> writes:

> In practice, at least for the last couple of release cycles, we freeze
> unstable for non-leaf packages during the release freeze because otherwise
> it's too difficult with our current infrastructure to finish the
> release.

I personally consider this a regrettable situation, and hope that for
jessie and beyond we can work out how to do this better.  It is
unacceptable to me to "freeze" anything in sid for more than a week or
two at a time.  Holding d-i's build dependencies static in unstable for
more than half a year is just nuts to me!  Sure seems like d-i is
something we should build using the components of the release it will be
contained in and not unstable... but I haven't tried to think hard about
what that might imply that's problematic.  And I certainly don't think
this is something we should even consider changing at this late date in
for wheezy release cycle!

> Given that, I think it makes sense to, as
> Daniel mentioned, make it rather explicit that, yes, unstable is frozen
> for non-leaf packages until we complete the release.  And, in this
> specific case, to revert the syslinux update in unstable (and hopefully
> upload to experimental) so that we're not building d-i against a package
> that isn't part of the release.

I agree that we need to bring this current situation to closure quickly
so that the RC1 build of d-i for wheezy can proceed.  We seem to have
three options:

    patch d-i to build successfully against the syslinux in sid

    wiggle the d-i build processing to fetch syslinux from testing

    (re-)upload the previous syslinux version with a new epoch

The first requires a patch that actually works, and there is at least
one assertion that the patch Daniel pointed to does not.  The second I
can't speak to the complexity of since the last time I looked at d-i was
just before the last stable release.  The third is "easy" to accomplish
but requires agreement from the maintainer or a TC vote to overrule him.

I'm relatively unavailable for the next 24 hours.  Hopefully by then
further investigation and/or discussion will help make it clear which of
the above options we should pursue.

Bdale

[Message part 2 (application/pgp-signature, inline)]

Message #88 received at 699808@bugs.debian.org (full text, mbox, reply):

Bdale Garbee <bdale@gag.com> writes:

> I personally consider this a regrettable situation, and hope that for
> jessie and beyond we can work out how to do this better.  It is
> unacceptable to me to "freeze" anything in sid for more than a week or
> two at a time.  Holding d-i's build dependencies static in unstable for
> more than half a year is just nuts to me!  Sure seems like d-i is
> something we should build using the components of the release it will be
> contained in and not unstable... but I haven't tried to think hard about
> what that might imply that's problematic.  And I certainly don't think
> this is something we should even consider changing at this late date in
> for wheezy release cycle!

Yes.  This is pretty much exactly how I feel.  And I suspect it's a
general feeling by a lot of people: we freeze for too long, and we don't
like a lot of the implications of that, but we don't know how to do better
and get releases out faster because there's a truly intimidating amount of
work that has to get done to do the release and all the alternatives seem
to make the work even worse.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #93 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 06.02.2013 23:22, Don Armstrong wrote:
> On Wed, 06 Feb 2013, Russ Allbery wrote:
>> Don Armstrong <don@debian.org> writes:
>>
>>> Assuming that the patch for #699742[0] fixes this issue with DI RC
>>> releases being installed, is there still an outstanding issue for the
>>> CTTE?
>>
>> Earlier in this thread, there had been a couple of reports that fix didn't
>> work.  I haven't looked further, though.
> 
> Yeah, that was for the first incomplete patch. I was referring to the
> second one.

Unfortunately the second patch doesn't work either. See [1].


Cheers,
Michael

[1] https://lists.debian.org/debian-boot/2013/02/msg00115.html

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#699808; Package tech-ctte. (Thu, 07 Feb 2013 00:57:14 GMT) (full text, mbox, link).

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 00:57:14 GMT) (full text, mbox, link).

Message #98 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Bdale Garbee <bdale@gag.com> (06/02/2013):
> I personally consider this a regrettable situation, and hope that for
> jessie and beyond we can work out how to do this better.  It is
> unacceptable to me to "freeze" anything in sid for more than a week or
> two at a time.  Holding d-i's build dependencies static in unstable for
> more than half a year is just nuts to me!

How is that different from e.g. refraining to upload new libraries to
unstable, so that a package needing an upload (say, we need RC
bugfixes) doesn't pick new dependencies (on libraries not in testing)?

That's how testing works; and it's been this way for years/releases
now (since testing replaced frozen, I think).

> Sure seems like d-i is something we should build using the
> components of the release it will be contained in and not
> unstable...

Why should that source package be special? Yes, it's cumbersome, it
needs many uploads, if only because we need kernel fixes and
improvements, along with fixes for its 100+ components. I'm happy to
consider improvements to the process when we have time for that,
meaning not 8 months into the freeze, but I'd be happy to receive an
answer to the above question.

> And I certainly don't think this is something we should even
> consider changing at this late date in for wheezy release cycle!

I concur.

> I agree that we need to bring this current situation to closure
> quickly so that the RC1 build of d-i for wheezy can proceed.  We
> seem to have three options:
> 
>     patch d-i to build successfully against the syslinux in sid

And chase all regressions between syslinux 4 and 5? I'd rather not do
that, especially given how tested and working patches are failing to
deliver. Over the last few months on the d-i front, we've had 1 alpha,
4 betas; we would be throwing away the testing efforts of those 5
releases!

>     wiggle the d-i build processing to fetch syslinux from testing

See above question, why should we special-case this build-dependency?

>     (re-)upload the previous syslinux version with a new epoch

I don't see a better solution than this one.


On a personal note, I'm unsure how we came up with a situation where a
single maintainer can *actively* stall a release… Not caring about the
release process put into place years ago is a thing. Stopping people
from fixing problems created by such carelessness is another one…

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 01:18:12 GMT) (full text, mbox, link).

Message #103 received at 699808@bugs.debian.org (full text, mbox, reply):

Cyril Brulebois <kibi@debian.org> writes:
> Bdale Garbee <bdale@gag.com> (06/02/2013):

>> I personally consider this a regrettable situation, and hope that for
>> jessie and beyond we can work out how to do this better.  It is
>> unacceptable to me to "freeze" anything in sid for more than a week or
>> two at a time.  Holding d-i's build dependencies static in unstable for
>> more than half a year is just nuts to me!

> How is that different from e.g. refraining to upload new libraries to
> unstable, so that a package needing an upload (say, we need RC bugfixes)
> doesn't pick new dependencies (on libraries not in testing)?

I personally think it's exactly the same problem.  I think the situation
with libraries is regrettable as well.  (Note that, and I'm guessing I
speak for Bdale here too, "regrettable" is not intended to assign any sort
of blame!  This is the best solution that we've been able to come up with
to date as a project.  It's just still has some problems.)

> That's how testing works; and it's been this way for years/releases now
> (since testing replaced frozen, I think).

Yes.  It's always a source of some tension, since there are always people
who would prefer to have a place to continue to do development in an
unstable context even during the release process.  (Cue the standard
debate over the usability of experimental for this purpose -- I'm sure
nearly everyone reading this can fill it in from memory.  *grin*)

If we could find a way to release some of that tension, that would be
great, but it's a hard problem, and there's no way that we're going to
come up with a solution to it right now in the middle of the wheezy
freeze.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 06:27:05 GMT) (full text, mbox, link).

Message #108 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/06/2013 11:48 PM, Michael Biebl wrote:
> Unfortunately the second patch doesn't work either. See [1].

that is incorrect; the patch works, it's just the old vbox version in 
current debian testing/sid which has a bug (try the image on real 
hardware or any other virtualization and it works).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Michael Tokarev <mjt@tls.msk.ru>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 06:39:06 GMT) (full text, mbox, link).

Message #113 received at 699808@bugs.debian.org (full text, mbox, reply):

07.02.2013 10:30, Daniel Baumann wrote:
> On 02/06/2013 11:48 PM, Michael Biebl wrote:
>> Unfortunately the second patch doesn't work either. See [1].
>
> that is incorrect; the patch works, it's just the old vbox version in current debian testing/sid which has a bug (try the image on real hardware or any other virtualization and it works).

This makes me wonder what other components are also buggy somehow and
needs to be updated?  How many (old) hardware machines has something
similar too?  And how much more testing we need to declare that everything
we use is compatible?

Thanks,

/mjt

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 06:48:05 GMT) (full text, mbox, link).

Message #118 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 07.02.2013 07:30, Daniel Baumann wrote:
> On 02/06/2013 11:48 PM, Michael Biebl wrote:
>> Unfortunately the second patch doesn't work either. See [1].
> 
> that is incorrect; the patch works, it's just the old vbox version in 
> current debian testing/sid which has a bug (try the image on real 
> hardware or any other virtualization and it works).

Well, VBOX is pretty popular, so shipping an installer which doesn't
work for such an environment is certainly a no-go.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 06:51:05 GMT) (full text, mbox, link).

Message #123 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 07:35 AM, Michael Tokarev wrote:
> This makes me wonder what other components are also buggy somehow and
> needs to be updated?

first, this is a specific bug in vbox that was fixed some time ago but 
didn't make it into debian yet (because it lags a significant amount of 
upstream releases behind; and yes, i should and will fill a bug about it 
at some later point).

> How many (old) hardware machines has something
> similar too?  And how much more testing we need to declare that everything
> we use is compatible?

second, if you follow the bug, it's affecting sid and doesn't affect 
wheezy release images - they will have the same tested and working 
syslinux version that has proven to be stable during d-i alpha/beta 
images (unless i'm missing something and d-i *release* images are built 
with sid packages as well, in which case i personally would consider 
such a misfeature to be in critical need of a fix (iirc steve puts a 
local copy of the 'to be used' syslinux version to be used by debian-cd 
for release images manually on the local fs; not sure about the same 
that ends up in the final release copy of debian-installer-images, will 
check later on)).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 06:57:08 GMT) (full text, mbox, link).

Message #128 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 07:45 AM, Michael Biebl wrote:
> Well, VBOX is pretty popular, so shipping an installer which doesn't
> work for such an environment is certainly a no-go.

again, the syslinux in sid would not be in wheezy. making it a 
*temporary* problem until vbox has been fixed in debian (which i'm happy 
to NMU again, will look to cherry-pick the required patch later today).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 06:57:10 GMT) (full text, mbox, link).

Message #133 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 07.02.2013 07:58, Daniel Baumann wrote:
> On 02/07/2013 07:45 AM, Michael Biebl wrote:
>> Well, VBOX is pretty popular, so shipping an installer which doesn't
>> work for such an environment is certainly a no-go.
> 
> again, the syslinux in sid would not be in wheezy. making it a 
> *temporary* problem until vbox has been fixed in debian (which i'm happy 
> to NMU again, will look to cherry-pick the required patch later today).

I think it is obvious by now that reverting to syslinux 4 from wheezy is
the only sensible way forward at this point in the release.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 07:03:09 GMT) (full text, mbox, link).

Message #138 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 07:55 AM, Michael Biebl wrote:
> I think it is obvious by now that reverting to syslinux 4 from wheezy is
> the only sensible way forward at this point in the release.

'obvious'?

it requires two straight forward things, that, again, as said, are 
required to be applied for jessie anyway, and are wherey much desired to 
be applied on the wheezy source (to build images with syslinux backports):

  * patch applied against debian-installer to include the additionally
    required .c32 modules when using vesamenu.c32

  * patch applied against debian-cd to include the additionally required
    .c32 modules when using vesamenu.c32

and fixing one temporary breakage in vbox for convenience:

  * cherry-pick upstream commit to fix a bug in vbox

not more, not less.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 07:09:05 GMT) (full text, mbox, link).

Message #143 received at 699808@bugs.debian.org (full text, mbox, reply):

sorry, forgot to put in the links to the patches..

On 02/07/2013 08:06 AM, Daniel Baumann wrote:
>    * patch applied against debian-installer to include the additionally
>      required .c32 modules when using vesamenu.c32

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#30

>    * patch applied against debian-cd to include the additionally required
>      .c32 modules when using vesamenu.c32

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699884#20

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 07:15:05 GMT) (full text, mbox, link).

Message #148 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On 07.02.2013 08:06, Daniel Baumann wrote:
> On 02/07/2013 07:55 AM, Michael Biebl wrote:
>> I think it is obvious by now that reverting to syslinux 4 from wheezy is
>> the only sensible way forward at this point in the release.
> 
> 'obvious'?

Imho, yes. But then, it's not up to me to decide.

>    * patch applied against debian-installer to include the additionally
>      required .c32 modules when using vesamenu.c32
> 
>    * patch applied against debian-cd to include the additionally required
>      .c32 modules when using vesamenu.c32
> 
>    * cherry-pick upstream commit to fix a bug in vbox

This list is getting longer with each email. Seeing that syslinux 5 has
been in sid for less then 10 days, I'm worried what other issues might
show up.
While I can understand (from personal experience) that freeze-time is
sometimes frustrating, delaying the release even further doesn't help
anyone.
If we want to improve our procedures, how we handle d-i, freeze etc, now
is not the time to discuss/work on this.

Just my 2¢

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 07:33:10 GMT) (full text, mbox, link).

Message #153 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 08:12 AM, Michael Biebl wrote:
> This list is getting longer with each email. Seeing that syslinux 5 has
> been in sid for less then 10 days, I'm worried what other issues might
> show up.

apart from the two obvious things (debian-installer and debian-cd) that 
do need to be updated to copy in the additionally required c32 modules 
when using vesamenu.c32, there's only vbox broken.

while i can see that one is inclined to jump to the conclusion that now 
each and every package in debian needs an update, it really isn't so.

no package is directly interacting with a bootloader, except those that 
create images (debian-installer, debian-cd), or boot images *and* have 
bugs fixed-upstream-long-time-ago-but-not-in-debian (vbox).

again, note that any other virtualization software, be it in wheezy 
directly (qemu, kvm) or otherwise (parallels, vmware) which i've tested 
with, has no bugs with syslinux 5. it's an isolated thing that vbox 
still has that bug in debian.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 08:03:05 GMT) (full text, mbox, link).

Message #158 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Daniel Baumann <daniel.baumann@progress-technologies.net> (07/02/2013):
> On 02/07/2013 08:12 AM, Michael Biebl wrote:
> >This list is getting longer with each email. Seeing that syslinux 5 has
> >been in sid for less then 10 days, I'm worried what other issues might
> >show up.
> 
> apart from the two obvious things (debian-installer and debian-cd)
> that do need to be updated to copy in the additionally required c32
> modules when using vesamenu.c32, there's only vbox broken.

So obvious that you didn't submit any patches against the reverse
build-dependencies you broke unilaterally, without any prior notice?
I always thought of Debian as something which included “team work”
and people interacting with each others to build a nice operating
system. Apparently I was wrong all along.

> while i can see that one is inclined to jump to the conclusion that
> now each and every package in debian needs an update, it really
> isn't so.
> 
> no package is directly interacting with a bootloader, except those
> that create images (debian-installer, debian-cd), or boot images
> *and* have bugs fixed-upstream-long-time-ago-but-not-in-debian
> (vbox).

That's nowhere like anything which could qualify with something
starting with “no package except […]”.

> again, note that any other virtualization software, be it in wheezy
> directly (qemu, kvm) or otherwise (parallels, vmware) which i've
> tested with, has no bugs with syslinux 5. it's an isolated thing
> that vbox still has that bug in debian.

That's called a showstopper.

Last I checked, we have nothing to gain with syslinux 5 apart losing
accumulated testing, having to include patches you can't even come up
with a full list of, hitting known-and-unfixed regressions, and having
to bother tech-ctte instead of just releasing a new d-i.

Thank you so much. Not.

KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 08:33:05 GMT) (full text, mbox, link).

Message #163 received at 699808@bugs.debian.org (full text, mbox, reply):

Hi,

On Wed, 06 Feb 2013, Bdale Garbee wrote:
> two at a time.  Holding d-i's build dependencies static in unstable for
> more than half a year is just nuts to me!  Sure seems like d-i is
> something we should build using the components of the release it will be
> contained in and not unstable... but I haven't tried to think hard about
> what that might imply that's problematic. And I certainly don't think
> this is something we should even consider changing at this late date in
> for wheezy release cycle!

Technically d-i point release updates are built in
"stable-proposed-updates" and build dependencies are satisfied in stable
(+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy
in testing-proposed-updates right now (and have build-deps satisfied in
wheezy). t-p-u is frowned upon for normal packages because the release
team like the testing packages get in unstable, but in the case of d-i the
only thing that needs to be tested are the installer images which end up
on the mirror and not in the package repository (the installer directories
are shared between wheezy and sid).

That said this was never done yet and we're not sure what dak
would do with the by-hand archive containing the installer images. Maybe
some ftpmasters could answer on this point?

I discussed this with Cyril and Julien and they were (rightfully IMO) not keen
on trying this at this point of the release.

That said this whole discussion is interesting and might even help up
in the long term but the real problem is that Daniel is just actively
working against the release team wishes and this is unacceptable to me.
We all know the limitations of our processes, any help to improve them
is welcome, but working against them is not acceptable.

But judging the social behaviour of a developer is not really in the realm
of the tech-ctte and the best technical outcome might not be in line with
the release team's plans.

Thus I would subject to word a resolution along the line of "The tech-ctte
suggests the release team to try out <this> because <bar>, but if the release team
doesn't wish to try it out, then the release team has the right to upload
an older version of syslinux to unstable (given that the maintainer
deliberately ignored recommendations of the release team).".

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 08:42:04 GMT) (full text, mbox, link).

Message #168 received at 699808@bugs.debian.org (full text, mbox, reply):

i'm not commenting on unfair accusations, so only to the relevant part:

On 02/07/2013 09:00 AM, Cyril Brulebois wrote:
>> again, note that any other virtualization software, be it in wheezy
>> directly (qemu, kvm) or otherwise (parallels, vmware) which i've
>> tested with, has no bugs with syslinux 5. it's an isolated thing
>> that vbox still has that bug in debian.
>
> That's called a showstopper.

you're aware that regardless of syslinux version in sid, the current 
vbox version in wheezy will not be able to boot any post-wheezy image at 
all? so, again, the vbox bug is entirely unrelated to what version of 
syslinux is in sid now and probably should be fixed anyway, even in wheezy.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:03:06 GMT) (full text, mbox, link).

Message #173 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Daniel Baumann <daniel.baumann@progress-technologies.net> (07/02/2013):
> i'm not commenting on unfair accusations, so only to the relevant part:
> 
> On 02/07/2013 09:00 AM, Cyril Brulebois wrote:
> >>again, note that any other virtualization software, be it in wheezy
> >>directly (qemu, kvm) or otherwise (parallels, vmware) which i've
> >>tested with, has no bugs with syslinux 5. it's an isolated thing
> >>that vbox still has that bug in debian.
> >
> >That's called a showstopper.
> 
> you're aware that regardless of syslinux version in sid, the current
> vbox version in wheezy will not be able to boot any post-wheezy
> image at all? so, again, the vbox bug is entirely unrelated to what
> version of syslinux is in sid now and probably should be fixed
> anyway, even in wheezy.

I don't disagree. Having a fixed virtualbox would be nice. That doesn't
mean we should be keeping syslinux 5 in sid in the meanwhile, especially
since that's preventing us from releasing d-i wheezy rc1.

KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:12:05 GMT) (full text, mbox, link).

Message #178 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 09:59 AM, Cyril Brulebois wrote:
> That doesn't
> mean we should be keeping syslinux 5 in sid in the meanwhile, especially
> since that's preventing us from releasing d-i wheezy rc1.

(ftr) which is where i disagree, with the mentioned patch against d-i 
and debian-cd, you can release d-i wheezy rc1, even with syslinux 5.x in 
sid.

even more so: since steve uses a local copy of syslinux anyway (judging 
from debian-cd sources as unfortunately the setup of debian-cd on the 
buildhost is not documented) when invoking debian-cd, it doesn't matter 
at all what version of syslinux is in sid.

therefore, right now, even without any patches, the only actually 
affected things are the images within the debian-installer-images 
tarball built by src:debian-installer, which i believe should be 
possible to fix without too much of a hassle. let me know if you want me 
to come up with a patch for that too.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:15:05 GMT) (full text, mbox, link).

Message #183 received at 699808@bugs.debian.org (full text, mbox, reply):

On 07.02.2013 08:31, Raphael Hertzog wrote:
> Technically d-i point release updates are built in
> "stable-proposed-updates" and build dependencies are satisfied in 
> stable
> (+ s-p-u maybe). Similarly it should be possible to build d-i for 
> wheezy
> in testing-proposed-updates right now (and have build-deps satisfied 
> in
> wheezy).

For reference, it would also require an otherwise no-op upload of the 
debian-installer package to unstable, to ensure that testing <= 
unstable.

> t-p-u is frowned upon for normal packages because the release
> team like the testing packages get in unstable, but in the case of 
> d-i the
> only thing that needs to be tested are the installer images which end 
> up
> on the mirror and not in the package repository (the installer 
> directories
> are shared between wheezy and sid).

I believe they once were shared; that's no longer the case - to the 
extent that there's a "dak copy-installer" command to migrate the 
non-package elements.

Regards,

Adam

Message #188 received at 699808@bugs.debian.org (full text, mbox, reply):

On Thu, 07 Feb 2013, Raphael Hertzog wrote:
> on the mirror and not in the package repository (the installer directories
> are shared between wheezy and sid).

Cyril pointed out to me that this specific point is wrong, while
wheezy/main/installer-* and unstable/main/installer-* have the same
content right now, they are not the same (and thus not shared). There's a
"dak copy-installer" involved to copy the installer from unstable to
wheezy.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:30:06 GMT) (full text, mbox, link).

Message #193 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Daniel Baumann <daniel.baumann@progress-technologies.net> (07/02/2013):
> (ftr) which is where i disagree, with the mentioned patch against
> d-i and debian-cd, you can release d-i wheezy rc1, even with
> syslinux 5.x in sid.
> 
> even more so: since steve uses a local copy of syslinux anyway
> (judging from debian-cd sources as unfortunately the setup of
> debian-cd on the buildhost is not documented) when invoking
> debian-cd, it doesn't matter at all what version of syslinux is in
> sid.

That means at least broken mini.iso, which is totally unacceptable.

> therefore, right now, even without any patches, the only actually
> affected things are the images within the debian-installer-images

(wrong)

> tarball built by src:debian-installer, which i believe should be
> possible to fix without too much of a hassle. let me know if you
> want me to come up with a patch for that too.

We're not going to patch various things to cope with syslinux 5 “just
because”. Especially when the list of said things is growing over
time.

It's time to realize that we had working things, and that you broke
athem. Patching reverse dependencies isn't what is going to happen
here.

KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Ansgar Burchardt <ansgar@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:36:03 GMT) (full text, mbox, link).

Message #198 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 09:31, Raphael Hertzog wrote:
> Technically d-i point release updates are built in
> "stable-proposed-updates" and build dependencies are satisfied in stable
> (+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy
> in testing-proposed-updates right now (and have build-deps satisfied in
> wheezy). t-p-u is frowned upon for normal packages because the release
> team like the testing packages get in unstable, but in the case of d-i the
> only thing that needs to be tested are the installer images which end up
> on the mirror and not in the package repository (the installer directories
> are shared between wheezy and sid).
> 
> That said this was never done yet and we're not sure what dak
> would do with the by-hand archive containing the installer images. Maybe
> some ftpmasters could answer on this point?

Uploading d-i images to wheezy (or t-p-u) should work as far as dak is
concerned. They should end in t-p-u and could be copied from there to
wheezy (dak copy-installer), similar to stable updates.

However I'm not sure if this has ever been tested and the RC images of
d-i might not be the best time to try. I also spotted a bug when uploads
would go to t-p-u instead of wheezy in the .changes (which should be
fixed now)...

As Adam already pointed out we would still need another d-i upload to
unstable to make sure unstable has a higher-or-equal version compared to
testing.

Ansgar

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:45:08 GMT) (full text, mbox, link).

Message #203 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 10:27 AM, Cyril Brulebois wrote:
> That means at least broken mini.iso, which is totally unacceptable.

broken without the patch i send for debian-installer, yes.

>> therefore, right now, even without any patches, the only actually
>> affected things are the images within the debian-installer-images
>
> (wrong)

hm?

> We're not going to patch various things to cope with syslinux 5 “just
> because”. Especially when the list of said things is growing over
> time.

i already commented on 'growing' and why that's wrong.

> It's time to realize that we had working things, and that you broke
> athem. Patching reverse dependencies isn't what is going to happen
> here.

as elaborated, i disagree. to repeat, again, at minimum, it needs one 
(confirming working[0]) patch (to d-i), and steve using the wheezy 
local-copy of syslinux on the cdbuilder for debian-cd. not more, not less.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Steve McIntyre <steve@einval.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:57:09 GMT) (full text, mbox, link).

Message #208 received at 699808@bugs.debian.org (full text, mbox, reply):

On Thu, Feb 07, 2013 at 07:52:13AM +0100, Daniel Baumann wrote:
>
>consider such a misfeature to be in critical need of a fix (iirc
>steve puts a local copy of the 'to be used' syslinux version to be
>used by debian-cd for release images manually on the local fs; not
>sure about the same that ends up in the final release copy of
>debian-installer-images, will check later on)).

Correcting - that used to be the case several years ago, but debian-cd
now explicitly extracts files from the syslinux(-common) package in
the main archive at CD build time, using the same suite as used in d-i
for consistency.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 09:57:11 GMT) (full text, mbox, link).

Message #213 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Daniel Baumann <daniel.baumann@progress-technologies.net> (07/02/2013):
> On 02/07/2013 10:27 AM, Cyril Brulebois wrote:
> >That means at least broken mini.iso, which is totally unacceptable.
> 
> broken without the patch i send for debian-installer, yes.

If that can't be used with virtualbox (and we already established
that, thanks to Michael's testing), that means it's broken with your
patch too.

> i already commented on 'growing' and why that's wrong.

That…

> > It's time to realize that we had working things, and that you
> > broke athem. Patching reverse dependencies isn't what is going to
> > happen here.
> 
> as elaborated, i disagree. to repeat, again, at minimum, it needs

and “at minimum” doesn't exactly play along very well.

> one (confirming working[0]) patch (to d-i), and steve using the
> wheezy local-copy of syslinux on the cdbuilder for debian-cd. not
> more, not less.

I'm going to repeat it again for you:
 - that's already too much
 - that would still mean known regressions (which you'll try to blame
   on virtualbox, but not going to syslinux 5 means no problem, so just
   let's just not use that)
 - and above all: that wouldn't gain us anything at all.

KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #218 received at 699808@bugs.debian.org (full text, mbox, reply):

On Thu, Feb 07, 2013 at 10:15:42AM +0100, Daniel Baumann wrote:
>On 02/07/2013 09:59 AM, Cyril Brulebois wrote:
>>That doesn't
>>mean we should be keeping syslinux 5 in sid in the meanwhile, especially
>>since that's preventing us from releasing d-i wheezy rc1.
>
>(ftr) which is where i disagree, with the mentioned patch against d-i
>and debian-cd, you can release d-i wheezy rc1, even with syslinux 5.x
>in sid.
>
>even more so: since steve uses a local copy of syslinux anyway
>(judging from debian-cd sources as unfortunately the setup of
>debian-cd on the buildhost is not documented) when invoking
>debian-cd, it doesn't matter at all what version of syslinux is in
>sid.

Already corrected elsewhere (repeating for clarity for people who may
not read all of the thread here) - debian-cd uses syslinux from the
archive at build time.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 10:06:09 GMT) (full text, mbox, link).

Message #223 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 10:53 AM, Cyril Brulebois wrote:
> If that can't be used with virtualbox (and we already established
> that, thanks to Michael's testing), that means it's broken with your
> patch too.

as already elaborated, the bug in vbox needs to be fixed anyway, 
regardless what version of syslinux is in the archive.. and if you wait 
until the end of the day, that problem is gone anyway.

>   - and above all: that wouldn't gain us anything at all.

which is not an argument.. any package that i don't use/care about 
doesn't give any benefits to me when it get any upload. with that in 
mind, from my point of view, for any package that i don't use, they 
should be never ever touched at all to prevent bringing any (potential) 
bug that could affect me indirectly.

i'm argueing for either an explicit unfrozen sid or an explicit frozen 
sid. since it's neither right now, and you intend to overwrite the 
maintainers decision via CTTE to upload newer syslinux to sid, you need 
to argue against it, not 'doesn't gain anything'.

i've already made the case why i want newer syslinux in sid, and have 
provided patches for the two packages that needs an update for that 
(plus the third and only remaining one, vbox, is in the works).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Samuel Thibault <sthibault@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 10:21:07 GMT) (full text, mbox, link).

Message #228 received at 699808@bugs.debian.org (full text, mbox, reply):

Daniel Baumann, le Thu 07 Feb 2013 11:08:55 +0100, a écrit :
> i've already made the case why i want newer syslinux in sid,

I must have missed that, and I can't find it on either bug #699382,
699742 or 699808.

Samuel

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 10:33:05 GMT) (full text, mbox, link).

Message #233 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 11:17 AM, Samuel Thibault wrote:
> I must have missed that, and I can't find it on either bug #699382,
> 699742 or 699808.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699808#10

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Acknowledgement sent to Stefano Zacchiroli <leader@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 10:48:03 GMT) (full text, mbox, link).

Message #238 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Feb 07, 2013 at 11:08:55AM +0100, Daniel Baumann wrote:
> i'm argueing for either an explicit unfrozen sid or an explicit
> frozen sid. since it's neither right now, and you intend to
> overwrite the maintainers decision via CTTE to upload newer syslinux
> to sid, you need to argue against it, not 'doesn't gain anything'.

Daniel, I don't think this is the place for such a broad discussion. I
believe we would all agree that a frozen distro development (no matter
the suite where it happens) is a PITA that we could all live without.
But at present, this is what our release processes and technologies
offer. Like it or not. It would be very nice to improve them, and I've
high hopes that dak based personal package archives would help a lot
with that, but this is not the time for this kind of changes.

More importantly, it is arguably false that sid is not "explicitly
frozen". The freeze policy [1], which has been repeatedly announced on
d-d-a, reads:

> Please also note that since many updates (hopefully, the vast
> majority) will still be going in through unstable, major changes in
> unstable right now can disrupt efforts to get RC bugs fixed. We don't
> ask you not to make changes in unstable, but we do ask that you be
> aware of the effects your changes can have -- especially if you
> maintain a library. Please continue to keep disruptive changes out of
> unstable and continue making use of experimental where
> appropriate. Note that you can stage NEW uploads in experimental to
> avoid disruption in unstable.

[1]: http://release.debian.org/wheezy/freeze_policy.html

by evidence, your change to unstable has been disruptive. I understand
(better, I trust your claim on that, but I haven't checked) that
experimental is not a viable path for syslinux development. But that is
no justification for getting in the way of a release, going explicitly
against the freeze policy.

Please put back in sid the syslinux version that the release team wants
to see in there. Ideally, it wouldn't be for long, and an action of that
kind will avoid burning cycles of all the people participating in this
thread. I'm pretty sure we can all use those cycles to the betterment of
Wheezy instead.

As soon as Wheezy is out of the door, please re-raise this topic in a
project-wide place, where we can work on solutions to avoid this kind of
frustrating long freezes. That would be the appropriate time and place
for this kind of discussions.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 13:09:05 GMT) (full text, mbox, link).

Message #243 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Bdale Garbee wrote:
> Sure seems like d-i is something we should build using the components
> of the release it will be contained in and not unstable... but I
> haven't tried to think hard about what that might imply that's
> problematic.  And I certainly don't think this is something we should
> even consider changing at this late date in for wheezy release cycle!

This is not desirable outside the freeze because packages in unstable
that are used to build d-i then don't get tested until they land in
testing.

It might be desirable during the freeze.

>     wiggle the d-i build processing to fetch syslinux from testing

This can be done easily, just upload d-i to t-p-u. d-i uploads are 
already built with udebs from testing, for similar reasons.

There seems to be an unholy fear of using t-p-u for anything these days,
which I don't really understand. Even when not using it causes massive
and unnecessary logjams in unstable during the freeze.

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #248 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Steve McIntyre wrote:
> On Thu, Feb 07, 2013 at 07:52:13AM +0100, Daniel Baumann wrote:
> >
> >consider such a misfeature to be in critical need of a fix (iirc
> >steve puts a local copy of the 'to be used' syslinux version to be
> >used by debian-cd for release images manually on the local fs; not
> >sure about the same that ends up in the final release copy of
> >debian-installer-images, will check later on)).
> 
> Correcting - that used to be the case several years ago, but debian-cd
> now explicitly extracts files from the syslinux(-common) package in
> the main archive at CD build time, using the same suite as used in d-i
> for consistency.

Howver, that is not the only image provided by Debian that uses
syslinux. The d-i mini.iso is another one, which uses the syslinux
provided by d-i's Build-Depedency, ie the one from unstable.

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #253 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Bdale Garbee wrote:
>     patch d-i to build successfully against the syslinux in sid

syslinux is GPL'd, so this would result in shipping d-i images in wheezy
which contain a GPL'd binary for which there is no source in wheezy.

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 13:33:12 GMT) (full text, mbox, link).

Message #258 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Joey Hess <joeyh@debian.org> (07/02/2013):
> This can be done easily, just upload d-i to t-p-u. d-i uploads are 
> already built with udebs from testing, for similar reasons.
> 
> There seems to be an unholy fear of using t-p-u for anything these days,
> which I don't really understand. Even when not using it causes massive
> and unnecessary logjams in unstable during the freeze.

<fdf81293a6165c5d51397bb855d29ea0@mail.adsl.funky-badger.org>


Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to daniel.baumann@progress-technologies.net:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 14:03:05 GMT) (full text, mbox, link).

Message #263 received at 699808@bugs.debian.org (full text, mbox, reply):

On 02/07/2013 02:14 PM, Joey Hess wrote:
> Howver, that is not the only image provided by Debian that uses
> syslinux. The d-i mini.iso is another one, which uses the syslinux
> provided by d-i's Build-Depedency, ie the one from unstable.

that has already been discussed in earlier messages.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #268 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Cyril Brulebois wrote:
> Joey Hess <joeyh@debian.org> (07/02/2013):
> > This can be done easily, just upload d-i to t-p-u. d-i uploads are 
> > already built with udebs from testing, for similar reasons.
> > 
> > There seems to be an unholy fear of using t-p-u for anything these days,
> > which I don't really understand. Even when not using it causes massive
> > and unnecessary logjams in unstable during the freeze.
> 
> <fdf81293a6165c5d51397bb855d29ea0@mail.adsl.funky-badger.org>

Yes, that's a good example of spreading FUD aboput using t-p-u, rather
than just using it and dealing with any breakage.

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 15:12:05 GMT) (full text, mbox, link).

Message #273 received at 699808@bugs.debian.org (full text, mbox, reply):

On 07.02.2013 14:46, Joey Hess wrote:
> Cyril Brulebois wrote:
>> Joey Hess <joeyh@debian.org> (07/02/2013):
>> > This can be done easily, just upload d-i to t-p-u. d-i uploads are
>> > already built with udebs from testing, for similar reasons.
>> >
>> > There seems to be an unholy fear of using t-p-u for anything these 
>> days,
>> > which I don't really understand. Even when not using it causes 
>> massive
>> > and unnecessary logjams in unstable during the freeze.
>>
>> <fdf81293a6165c5d51397bb855d29ea0@mail.adsl.funky-badger.org>
>
> Yes, that's a good example of spreading FUD aboput using t-p-u, 
> rather
> than just using it and dealing with any breakage.

If you want to describe being concerned with dak refusing to import the 
result of a britney run due to the version constraints being broken FUD, 
sure. Note that I didn't say it was a reason not to use tpu, just a 
pre-condition in this case.

Regards,

Adam

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 15:36:03 GMT) (full text, mbox, link).

Message #278 received at 699808@bugs.debian.org (full text, mbox, reply):

On Tue, Feb 05, 2013 at 01:48:22PM +0100, Julien Cristau wrote:
> the background for this request can be found in bug#699382.  Here are
> the highlights:
> - the debian-installer source package, which builds the installer images
>   for debian's releases, build-depends on syslinux
> - the release freeze for wheezy started in June 2012, and is now in its
>   final stages
> - one of the prerequisites for the release is a release candidate for
>   the installer
> - the syslinux maintainer uploaded new upstream versions of his package
>   to unstable, which were unsuitable for wheezy, in November 2012, and
>   again at the end of January 2013
> - the latest of these uploads breaks the installer, making it impossible
>   to build and upload the planned wheezy release candidate, since
>   build-dependencies are fetched from unstable
> - when asked to revert this change, the syslinux maintainer refused, and
>   said disagreements should be referred to the technical committee
> 
> The submitters consider this disregard for the Debian release process
> not acceptable, and ask that the technical committee
> - overrule the syslinux maintainer, and decide that the syslinux package
>   in unstable should be reverted to the version currently in wheezy (or a
>   version compatible with the release team's freeze policy), until
>   the wheezy release
> - rule that the syslinux package maintainer should be willing to
>   collaborate with maintainers of its reverse-dependencies (and in
>   particular the Debian Installer team) in a way that's compatible with
>   Debian's release processes, and not against them.

Even if the process is broken (and I can see arguments either way on
that), now is not the time to rearrange it.  If it was known in advance
that d-i et al would break, at the very least patches for that should
have been landed first.  If it was not known, then what makes us think
that the three problems identified to date (d-i, debian-cd, virtualbox)
are a complete list?  At the very least, it puts into question a
considerable amount of the installer testing done to date.

I would not wish to "rule that the syslinux package maintainer should be
willing to collaborate" etc.; this is the type of assuming-bad-faith
element of rulings that I think has not generally gone well when the TC
has attempted it in the past, and it's at best questionable whether it's
within our power anyway.  But I do think that the syslinux maintainer
should revert to 4.x in unstable; I'd rather that be voluntary but I'd
be willing to vote to overrule if need be.

As for the reasoning Daniel gave for putting 5.x in unstable in the
first place, my recommendation would be to put 5.x in experimental and
6.x in some other archive; they are hardly difficult to set up and I'm
quite sure Daniel's already familiar with what's involved there.  The
additional marketing gained by having 6.x in the Debian archive proper
doesn't justify indirectly causing problems for wheezy, even if one
disagrees with the process by which those problems are caused.

On a personal note, this is exactly the kind of reason I deliberately
kept GRUB 1.99 in unstable and 2.00 in experimental, even though it
would have been more convenient and rather more pleasing to be able to
ship wheezy with 2.00.  There are certainly cases where new upstream
versions in unstable during a freeze don't cause a practical problem and
needn't involve any fuss - I've uploaded some such myself - but once
it's clear they do cause a practical problem the proper course of action
is surely to revert and let everyone get on with pre-existing problems.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 16:27:07 GMT) (full text, mbox, link).

Message #283 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Feb 07, 2013 at 01:55:11AM +0100, Cyril Brulebois wrote:
> On a personal note, I'm unsure how we came up with a situation where a
> single maintainer can *actively* stall a release… Not caring about the
> release process put into place years ago is a thing. Stopping people
> from fixing problems created by such carelessness is another one…

Speaking as an ex-RM, I think the answer here is that it used to be that
when a maintainer made such an upload (and it did happen), we would revert
it without hesitation and without apology.

I'm having a hard time deciding, with my TC member hat on, if I think this
is actually an ok thing to do.  But whether or not it's ok, I do think I
would still do it today if I were in your position on the grounds that it's
easier to ask forgiveness than to ask permission, and asking explicit
permission from every maintainer who is in a position to become a critical
blocker for the release is a good way to make sure releases don't happen.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 07 Feb 2013 16:30:03 GMT) (full text, mbox, link).

Message #288 received at 699808@bugs.debian.org (full text, mbox, reply):

Colin Watson writes ("Bug#699808: tech-ctte: syslinux vs the wheezy release"):
>  But I do think that the syslinux maintainer
> should revert to 4.x in unstable; I'd rather that be voluntary but I'd
> be willing to vote to overrule if need be.

From what I've read so far I tend to agree.

In Julien's referral mail:

 | - the debian-installer source package, which builds the installer
 |   images for debian's releases, build-depends on syslinux

For the avoidance of any doubt, I take this to mean that the version
of the syslinux binary from unstable is actually copied into
debian-installer's outputs.

The observed problem is that the newer syslinux in sid has new bugs.
Daniel seems to be proposing that we deal with these by patching the
various other programs which don't work with the new syslinux.  I
think that approach is out of the question at this stage of the
release.

There is a wider problem which is that of course we want wheezy's
installer to ship with the version of syslinux in the wheezy suite of
the archive.

I'm sympathetic to the argument that fetching sid's syslinux is not a
sensible approach for d-i, at least during the freeze.  From what I've
read so far it would be good for this to be changed.  But such a
process fix should have been implemented and deployed _before_ the new
syslog entered sid.


How about this for a disposal:

 The Technical Committee notes that:

 1. The syslinux maintainer has uploaded syslinux 5 to unstable.

 2. The Release Managers intend to release wheezy with syslinux 4.

 3. debian-installer even in wheezy and even now during the freeze
    uses syslinux binaries from unstable when building installers.

 Our view is that:

 4. Updating to syslinux 5 at this stage of the release (whether in
    the installer, or generally) is out of the question.

 5. It is arguable that arrangements should be made so that during the
    freeze debian-installer builds using testing's syslinux.  Similar
    considerations may apply to shared libraries.

 6. However now is not the time for these kind of process
    improvements.  We therefore state no definite conclusion on this
    question.

 7. The new syslinux should not have been uploaded to unstable, before
    the corresponding process improvements (if indeed they are
    improvements) are in place.

 Accordingly we decide as follows, overruling the syslinux maintainer:

 9. The version of syslinux in wheezy should be re-uploaded to
    unstable.

 9. No other updates should be made to syslinux in unstable, unless
    one of the following applies:
    
    (i) wheezy has been released and jessie opened and unfrozen;
    
    (ii) the Release Managers give their consent; or
    
    (iii) the debian-installer maintainers confirm that arrangements
          have been put in place to avoid this problem.

 10. The syslinux maintainer should state ASAP what package version
    number they would like to be used for this re-upload.  Any NMU of
    syslinux should honour such a statement, and in the absence of
    such a statement should not be made before 2013-02-10 17:00+0000.

 And we make the following (non-binding) statements of our opinion:

 11. We request that everyone involved in this issue cordially discuss
    possible process improvements, preferably after the release of
    wheezy.

 12. Whenever changes to Debian's software and processes are required,
    deployment should occur in a planned and cooperative way.
    Maintainers should be reluctant to upload changes which break
    other packages.  If such breakage is necessary to move forward, it
    should only occur after obtaining rough consensus amongst the
    relevant contributors or the project as a whole.

Ian

Message #291 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Feb 07, 2013 at 10:33:00AM +0100, Ansgar Burchardt wrote:
> As Adam already pointed out we would still need another d-i upload to
> unstable to make sure unstable has a higher-or-equal version compared to
> testing.

Sometimes I wonder why it cannot simply propagate to the upper suite.
We do that for packages from s-p-u at point release time, too.
I guess the flow would be "britney import → if version > unstable
→ stuff the new testing version into unstable".

We used to propagate security updates from stable into testing
so that they only have to be done once. But I guess both times
concerns about "not being built within the suite in question" might
apply. But we still do that for packages installed into *stable* (i.e.
across the major divergence between stable and unstable, or
at least into testing).

Kind regards
Philipp Kern

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#699808; Package tech-ctte. (Fri, 08 Feb 2013 03:21:03 GMT) (full text, mbox, link).

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 03:21:03 GMT) (full text, mbox, link).

Message #296 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Feb 07, 2013 at 04:26:49PM +0000, Ian Jackson wrote:
> How about this for a disposal:

I would vote for the below with reservation or modifications.  Thanks for
drafting this, Ian.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

>  The Technical Committee notes that:
> 
>  1. The syslinux maintainer has uploaded syslinux 5 to unstable.
> 
>  2. The Release Managers intend to release wheezy with syslinux 4.
> 
>  3. debian-installer even in wheezy and even now during the freeze
>     uses syslinux binaries from unstable when building installers.
> 
>  Our view is that:
> 
>  4. Updating to syslinux 5 at this stage of the release (whether in
>     the installer, or generally) is out of the question.
> 
>  5. It is arguable that arrangements should be made so that during the
>     freeze debian-installer builds using testing's syslinux.  Similar
>     considerations may apply to shared libraries.
> 
>  6. However now is not the time for these kind of process
>     improvements.  We therefore state no definite conclusion on this
>     question.
> 
>  7. The new syslinux should not have been uploaded to unstable, before
>     the corresponding process improvements (if indeed they are
>     improvements) are in place.
> 
>  Accordingly we decide as follows, overruling the syslinux maintainer:
> 
>  9. The version of syslinux in wheezy should be re-uploaded to
>     unstable.
> 
>  9. No other updates should be made to syslinux in unstable, unless
>     one of the following applies:
>     
>     (i) wheezy has been released and jessie opened and unfrozen;
>     
>     (ii) the Release Managers give their consent; or
>     
>     (iii) the debian-installer maintainers confirm that arrangements
>           have been put in place to avoid this problem.
> 
>  10. The syslinux maintainer should state ASAP what package version
>     number they would like to be used for this re-upload.  Any NMU of
>     syslinux should honour such a statement, and in the absence of
>     such a statement should not be made before 2013-02-10 17:00+0000.
> 
>  And we make the following (non-binding) statements of our opinion:
> 
>  11. We request that everyone involved in this issue cordially discuss
>     possible process improvements, preferably after the release of
>     wheezy.
> 
>  12. Whenever changes to Debian's software and processes are required,
>     deployment should occur in a planned and cooperative way.
>     Maintainers should be reluctant to upload changes which break
>     other packages.  If such breakage is necessary to move forward, it
>     should only occur after obtaining rough consensus amongst the
>     relevant contributors or the project as a whole.

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 03:36:06 GMT) (full text, mbox, link).

Message #301 received at 699808@bugs.debian.org (full text, mbox, reply):

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> How about this for a disposal:

Works for me.  Thank you!

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 07:39:03 GMT) (full text, mbox, link).

Message #306 received at 699808@bugs.debian.org (full text, mbox, reply):

On 08.02.2013 03:16, Steve Langasek wrote:
> On Thu, Feb 07, 2013 at 04:26:49PM +0000, Ian Jackson wrote:
>> How about this for a disposal:
>
> I would vote for the below with reservation or modifications.  Thanks 
> for
> drafting this, Ian.

Is there an "out" missing in the first sentence? (If not, what 
modifications?)

Regards,

Adam

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 08:03:03 GMT) (full text, mbox, link).

Message #311 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Fri, Feb 08, 2013 at 07:37:36AM +0000, Adam D. Barratt wrote:
> On 08.02.2013 03:16, Steve Langasek wrote:
> >On Thu, Feb 07, 2013 at 04:26:49PM +0000, Ian Jackson wrote:
> >>How about this for a disposal:

> >I would vote for the below with reservation or modifications.
> >Thanks for
> >drafting this, Ian.

> Is there an "out" missing in the first sentence? (If not, what
> modifications?)

Hah.  Yes, "without" reservation or modifications.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 11:33:09 GMT) (full text, mbox, link).

Message #316 received at 699808@bugs.debian.org (full text, mbox, reply):

Thanks for the feedback.  I'm calling for a vote on the resolution
below.  It's unchanged except that I fixed the paragraph numbering to
not have two para.9s.

The options are:
  Y  Revert syslinux in unstable, overruling maintainer (needs >3:1)
  F  Further discussion

Ian.

 The Technical Committee notes that:

 1. The syslinux maintainer has uploaded syslinux 5 to unstable.

 2. The Release Managers intend to release wheezy with syslinux 4.

 3. debian-installer even in wheezy and even now during the freeze
    uses syslinux binaries from unstable when building installers.

 Our view is that:

 4. Updating to syslinux 5 at this stage of the release (whether in
    the installer, or generally) is out of the question.

 5. It is arguable that arrangements should be made so that during the
    freeze debian-installer builds using testing's syslinux.  Similar
    considerations may apply to shared libraries.

 6. However now is not the time for these kind of process
    improvements.  We therefore state no definite conclusion on this
    question.

 7. The new syslinux should not have been uploaded to unstable, before
    the corresponding process improvements (if indeed they are
    improvements) are in place.

 Accordingly we decide as follows, overruling the syslinux maintainer:

 9. The version of syslinux in wheezy should be re-uploaded to
    unstable.

 10. No other updates should be made to syslinux in unstable, unless
    one of the following applies:
    
    (i) wheezy has been released and jessie opened and unfrozen;
    
    (ii) the Release Managers give their consent; or
    
    (iii) the debian-installer maintainers confirm that arrangements
          have been put in place to avoid this problem.

 11. The syslinux maintainer should state ASAP what package version
    number they would like to be used for this re-upload.  Any NMU of
    syslinux should honour such a statement, and in the absence of
    such a statement should not be made before 2013-02-10 17:00+0000.

 And we make the following (non-binding) statements of our opinion:

 12. We request that everyone involved in this issue cordially discuss
    possible process improvements, preferably after the release of
    wheezy.

 13. Whenever changes to Debian's software and processes are required,
    deployment should occur in a planned and cooperative way.
    Maintainers should be reluctant to upload changes which break
    other packages.  If such breakage is necessary to move forward, it
    should only occur after obtaining rough consensus amongst the
    relevant contributors or the project as a whole.

--

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 11:33:11 GMT) (full text, mbox, link).

Message #321 received at 699808@bugs.debian.org (full text, mbox, reply):

Ian Jackson writes ("Re: Bug#699808: tech-ctte (CFV): syslinux vs the wheezy release"):
> Thanks for the feedback.  I'm calling for a vote on the resolution
> below.  It's unchanged except that I fixed the paragraph numbering to
> not have two para.9s.
> 
> The options are:
>   Y  Revert syslinux in unstable, overruling maintainer (needs >3:1)
>   F  Further discussion

I vote
  Y F

Ian.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 11:42:03 GMT) (full text, mbox, link).

Message #326 received at 699808@bugs.debian.org (full text, mbox, reply):

Ian Jackson writes ("Re: Bug#699808: tech-ctte (CFV): syslinux vs the wheezy release"):
> Thanks for the feedback.  I'm calling for a vote on the resolution
> below.  [...]

I'd like to draw the attention of the syslinux maintainer to this
paragraph of the proposed resolution:

>  Accordingly we decide as follows, overruling the syslinux maintainer:
...
>  11. The syslinux maintainer should state ASAP what package version
>     number they would like to be used for this re-upload.  Any NMU of
>     syslinux should honour such a statement, and in the absence of
>     such a statement should not be made before 2013-02-10 17:00+0000.

That's two-and-a-bit days from now.

I think there's nothing stopping the maintainer from expressing their
opinion in advance of the end of the TC vote.  This is particularly
relevant since it is of course possible that the TC vote will end
after the stated date and time.

Ian.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 18:00:07 GMT) (full text, mbox, link).

Message #331 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> The options are:
>   Y  Revert syslinux in unstable, overruling maintainer (needs >3:1)
>   F  Further discussion

I vote Y F.

>  The Technical Committee notes that:

>  1. The syslinux maintainer has uploaded syslinux 5 to unstable.

>  2. The Release Managers intend to release wheezy with syslinux 4.

>  3. debian-installer even in wheezy and even now during the freeze
>     uses syslinux binaries from unstable when building installers.

>  Our view is that:

>  4. Updating to syslinux 5 at this stage of the release (whether in
>     the installer, or generally) is out of the question.

>  5. It is arguable that arrangements should be made so that during the
>     freeze debian-installer builds using testing's syslinux.  Similar
>     considerations may apply to shared libraries.

>  6. However now is not the time for these kind of process
>     improvements.  We therefore state no definite conclusion on this
>     question.

>  7. The new syslinux should not have been uploaded to unstable, before
>     the corresponding process improvements (if indeed they are
>     improvements) are in place.

>  Accordingly we decide as follows, overruling the syslinux maintainer:

>  9. The version of syslinux in wheezy should be re-uploaded to
>     unstable.

>  10. No other updates should be made to syslinux in unstable, unless
>     one of the following applies:
>     
>     (i) wheezy has been released and jessie opened and unfrozen;
>     
>     (ii) the Release Managers give their consent; or
>     
>     (iii) the debian-installer maintainers confirm that arrangements
>           have been put in place to avoid this problem.

>  11. The syslinux maintainer should state ASAP what package version
>     number they would like to be used for this re-upload.  Any NMU of
>     syslinux should honour such a statement, and in the absence of
>     such a statement should not be made before 2013-02-10 17:00+0000.

>  And we make the following (non-binding) statements of our opinion:

>  12. We request that everyone involved in this issue cordially discuss
>     possible process improvements, preferably after the release of
>     wheezy.

>  13. Whenever changes to Debian's software and processes are required,
>     deployment should occur in a planned and cooperative way.
>     Maintainers should be reluctant to upload changes which break
>     other packages.  If such breakage is necessary to move forward, it
>     should only occur after obtaining rough consensus amongst the
>     relevant contributors or the project as a whole.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[Message part 2 (application/pgp-signature, inline)]

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 20:54:03 GMT) (full text, mbox, link).

Message #336 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Joey Hess <joeyh@debian.org> writes:

> Bdale Garbee wrote:
>>     patch d-i to build successfully against the syslinux in sid
>
> syslinux is GPL'd, so this would result in shipping d-i images in wheezy
> which contain a GPL'd binary for which there is no source in wheezy.

My unstated assumption was that if d-i were able to successfully build
against the syslinux version in sid, that said version would be promoted
into testing before the actual release.  For the record, I certainly
wasn't trying to propose an obvious GPL violation!

Bdale

[Message part 2 (application/pgp-signature, inline)]

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 20:57:10 GMT) (full text, mbox, link).

Message #341 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I'm calling for a vote on the resolution below. 

I vote Y F.

Bdale

[Message part 2 (application/pgp-signature, inline)]

Acknowledgement sent to Steven Chamberlain <steven@pyro.eu.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 08 Feb 2013 23:57:06 GMT) (full text, mbox, link).

Message #346 received at 699808@bugs.debian.org (full text, mbox, reply):

Hi,

On 08/02/13 20:52, Bdale Garbee wrote:
> Joey Hess <joeyh@debian.org> writes:
>> syslinux is GPL'd, so this would result in shipping d-i images in wheezy
>> which contain a GPL'd binary for which there is no source in wheezy.
> 
> My unstated assumption was that if d-i were able to successfully build
> against the syslinux version in sid, that said version would be promoted
> into testing before the actual release.

But the new upload of syslinux would not satisfy the Release Team's
freeze policy, would it?  As per their most recent 'bits' mail to d-d-a
and published at:

http://release.debian.org/wheezy/freeze_policy.html

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#699808; Package tech-ctte. (Sat, 09 Feb 2013 11:03:06 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Barth <aba@ayous.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 09 Feb 2013 11:03:06 GMT) (full text, mbox, link).

Message #351 received at 699808@bugs.debian.org (full text, mbox, reply):

* Ian Jackson (ijackson@chiark.greenend.org.uk) [130208 12:31]:
> Thanks for the feedback.  I'm calling for a vote on the resolution
> below.  It's unchanged except that I fixed the paragraph numbering to
> not have two para.9s.
> 
> The options are:
>   Y  Revert syslinux in unstable, overruling maintainer (needs >3:1)
>   F  Further discussion

I vote YF.


Andi

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 09 Feb 2013 11:45:13 GMT) (full text, mbox, link).

Message #356 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Fri, Feb 08, 2013 at 11:30:42AM +0000, Ian Jackson wrote:
> The options are:
>   Y  Revert syslinux in unstable, overruling maintainer (needs >3:1)
>   F  Further discussion

I vote YF.

-- 
Colin Watson                                       [cjwatson@debian.org]

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 09 Feb 2013 20:00:05 GMT) (full text, mbox, link).

Message #361 received at 699808@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

I vote YF.

On Fri, Feb 08, 2013 at 11:30:42AM +0000, Ian Jackson wrote:
> The options are:
>   Y  Revert syslinux in unstable, overruling maintainer (needs >3:1)
>   F  Further discussion

>  The Technical Committee notes that:

>  1. The syslinux maintainer has uploaded syslinux 5 to unstable.

>  2. The Release Managers intend to release wheezy with syslinux 4.

>  3. debian-installer even in wheezy and even now during the freeze
>     uses syslinux binaries from unstable when building installers.

>  Our view is that:

>  4. Updating to syslinux 5 at this stage of the release (whether in
>     the installer, or generally) is out of the question.

>  5. It is arguable that arrangements should be made so that during the
>     freeze debian-installer builds using testing's syslinux.  Similar
>     considerations may apply to shared libraries.

>  6. However now is not the time for these kind of process
>     improvements.  We therefore state no definite conclusion on this
>     question.

>  7. The new syslinux should not have been uploaded to unstable, before
>     the corresponding process improvements (if indeed they are
>     improvements) are in place.

>  Accordingly we decide as follows, overruling the syslinux maintainer:

>  9. The version of syslinux in wheezy should be re-uploaded to
>     unstable.

>  10. No other updates should be made to syslinux in unstable, unless
>     one of the following applies:

>     (i) wheezy has been released and jessie opened and unfrozen;

>     (ii) the Release Managers give their consent; or

>     (iii) the debian-installer maintainers confirm that arrangements
>           have been put in place to avoid this problem.

>  11. The syslinux maintainer should state ASAP what package version
>     number they would like to be used for this re-upload.  Any NMU of
>     syslinux should honour such a statement, and in the absence of
>     such a statement should not be made before 2013-02-10 17:00+0000.

>  And we make the following (non-binding) statements of our opinion:

>  12. We request that everyone involved in this issue cordially discuss
>     possible process improvements, preferably after the release of
>     wheezy.

>  13. Whenever changes to Debian's software and processes are required,
>     deployment should occur in a planned and cooperative way.
>     Maintainers should be reluctant to upload changes which break
>     other packages.  If such breakage is necessary to move forward, it
>     should only occur after obtaining rough consensus amongst the
>     relevant contributors or the project as a whole.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Reply sent to Daniel Baumann <daniel@debian.org>:
You have taken responsibility. (Sun, 10 Feb 2013 15:06:14 GMT) (full text, mbox, link).

Notification sent to Julien Cristau <jcristau@debian.org>:
Bug acknowledged by developer. (Sun, 10 Feb 2013 15:06:14 GMT) (full text, mbox, link).

Message #366 received at 699808-close@bugs.debian.org (full text, mbox, reply):

Source: syslinux
Source-Version: 3:4.05+dfsg-6+deb7u2

We believe that the bug you reported is fixed in the latest version of
syslinux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 699808@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Baumann <daniel@debian.org> (supplier of updated syslinux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 10 Feb 2013 15:43:56 +0100
Source: syslinux
Binary: syslinux syslinux-udeb extlinux syslinux-common
Architecture: source i386 all
Version: 3:4.05+dfsg-6+deb7u2
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann <daniel.baumann@progress-technologies.net>
Changed-By: Daniel Baumann <daniel@debian.org>
Description: 
 extlinux   - collection of boot loaders (ext2/3/4 and btrfs bootloader)
 syslinux   - collection of boot loaders
 syslinux-common - collection of boot loaders (common files)
 syslinux-udeb - collection of boot loaders (udeb)
Closes: 699382 699596 699742 699808 699884 699890
Changes: 
 syslinux (3:4.05+dfsg-6+deb7u2) unstable; urgency=low
 .
   * Reuploading to unstable (Closes: #699382, #699596, #699742, #699808,
     #699884, #699890).
Checksums-Sha1: 
 b9ca5c47eb830071aae7c4e2f66696d5404f7afd 1449 syslinux_4.05+dfsg-6+deb7u2.dsc
 bdf58c9d11a246b3cb9db7d0af07f5e4097d5b5f 4483608 syslinux_4.05+dfsg.orig.tar.xz
 4ff6c014a3cf39ee428ef112c6731e5bee6ef3fd 31764 syslinux_4.05+dfsg-6+deb7u2.debian.tar.xz
 1b7be98a78ae626a9f408e9f815696034830a5f0 95982 syslinux_4.05+dfsg-6+deb7u2_i386.deb
 0297ea06c28628441d84072863f5b237eddc9443 42234 syslinux-udeb_4.05+dfsg-6+deb7u2_i386.udeb
 6f9198e60a53446944f82ede671b1bec7d3e5006 113792 extlinux_4.05+dfsg-6+deb7u2_i386.deb
 0815a89f4ac3efc9f20231cbcc00ca5bacf9e1e7 939984 syslinux-common_4.05+dfsg-6+deb7u2_all.deb
Checksums-Sha256: 
 7722aace037bca2d2167f7f2aaacb3ddad0035f56f95ca73a11b2f83a070f99c 1449 syslinux_4.05+dfsg-6+deb7u2.dsc
 91f57a24dafd950ff137d2a1378c9db30fda57e82c58ecf09fe6e558ca1b5056 4483608 syslinux_4.05+dfsg.orig.tar.xz
 bf8223b2ed766ff3720485be4cbc61e7676738f0e264ee927b4a191a6e326c64 31764 syslinux_4.05+dfsg-6+deb7u2.debian.tar.xz
 56d98b273090bba1bb507f6f827da84298c854ee8f31ce394477887f4a609f6d 95982 syslinux_4.05+dfsg-6+deb7u2_i386.deb
 aa363176df6b1bc2517478c36b052a13c06cd462e1478ee6599caccc8262f131 42234 syslinux-udeb_4.05+dfsg-6+deb7u2_i386.udeb
 5969b3ee76b2e1e8477c7c0682e1c8b43250647eec0ae16b9d287d8492e3be78 113792 extlinux_4.05+dfsg-6+deb7u2_i386.deb
 b8c83cb7c2ee3824c1aa142a82055616cab4c1970fc1a5b4c31e31aeda9da540 939984 syslinux-common_4.05+dfsg-6+deb7u2_all.deb
Files: 
 1dfb45bf84f735ee756574e83692368f 1449 utils optional syslinux_4.05+dfsg-6+deb7u2.dsc
 7a1ef95ba82804dec3cd99e80aab0201 4483608 utils optional syslinux_4.05+dfsg.orig.tar.xz
 08115808a701c7615367cac87f03cc2f 31764 utils optional syslinux_4.05+dfsg-6+deb7u2.debian.tar.xz
 760e77fd0b01946823f36d101b60ac03 95982 utils optional syslinux_4.05+dfsg-6+deb7u2_i386.deb
 ea2cd89a97afdca92d775a6071f104ea 42234 debian-installer optional syslinux-udeb_4.05+dfsg-6+deb7u2_i386.udeb
 8095ef10557b0ff02ce05f585f45ccbc 113792 utils optional extlinux_4.05+dfsg-6+deb7u2_i386.deb
 690950fd9af6b69dd7c1fcb45032ef22 939984 utils optional syslinux-common_4.05+dfsg-6+deb7u2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlEXtakACgkQ+C5cwEsrK55KRACfeo4b2wM72pXmkEjY7iqxTJ15
vvkAoMZu9oENGG/VjIO664ZQ7UauYSEJ
=LiE+
-----END PGP SIGNATURE-----

Information stored :
Bug#699808; Package tech-ctte. (Mon, 11 Feb 2013 22:03:05 GMT) (full text, mbox, link).

Acknowledgement sent to Stefano Zacchiroli <leader@debian.org>:
Extra info received and filed, but not forwarded. (Mon, 11 Feb 2013 22:03:05 GMT) (full text, mbox, link).

Message #371 received at 699808-quiet@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, Feb 05, 2013 at 01:48:22PM +0100, Julien Cristau wrote:
> Package: tech-ctte
> 
> [cc to syslinux maintainer, debian-release, debian-boot, leader]
> 
> Hi,
[…]

Just a short notice to thank everyone for the speedy handling of this
matter. I've been impressed. tech-ctte should always remain the last
resort to solve technical conflicts in Debian. But when it comes to
tech-ctte, it is really important to be efficient, otherwise developers
would lose faith in tech-ctte ability to solve issues in the time-frame
that matters to them. This particular aspect has been perceived as an
issue affecting the tech-ctte in the past, but we are now clearly past
that, thanks to your work --- no matter how unpleasant I'm pretty sure
it is sometimes. Kudos.

-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 12 Mar 2013 07:25:54 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Jun 5 04:29:56 2023; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #699808 tech-ctte: syslinux vs the wheezy release

Debian Bug report logs - #699808
tech-ctte: syslinux vs the wheezy release