Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Steven Chamberlain]

Hi,

On 08/02/13 20:52, Bdale Garbee wrote:
> Joey Hess  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
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51158fbb.5070...@pyro.eu.org

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Bdale Garbee]

Joey Hess  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


pgpairXVB3Onr.pgp
Description: PGP signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Philipp Kern]

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
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Adam D. Barratt]

On 07.02.2013 14:46, Joey Hess wrote:

Cyril Brulebois wrote:

Joey Hess  (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.




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


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/802784afd7484f8e74647b4d60188...@mail.adsl.funky-badger.org

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Joey Hess]

Cyril Brulebois wrote:
> Joey Hess  (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.
> 
> 

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
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Cyril Brulebois]

Joey Hess  (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.




Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Joey Hess]

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
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Joey Hess]

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
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Ansgar Burchardt]

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


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/511374cc.1090...@debian.org

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Raphael Hertzog]

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/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130207092243.ga12...@x230-buxy.home.ouaza.com

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Raphael Hertzog]

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  because , 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/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130207083122.ga11...@x230-buxy.home.ouaza.com

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Russ Allbery]

Cyril Brulebois  writes:
> Bdale Garbee  (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 (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq0dx6xk@windlord.stanford.edu

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Cyril Brulebois]

Bdale Garbee  (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
Description: Digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Michael Biebl]

On 06.02.2013 23:22, Don Armstrong wrote:
> On Wed, 06 Feb 2013, Russ Allbery wrote:
>> Don Armstrong  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
Description: OpenPGP digital signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Russ Allbery]

Bdale Garbee  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 (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3qlqdrq@windlord.stanford.edu

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Bdale Garbee]

Russ Allbery  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


pgpy9AV6WD5V5.pgp
Description: PGP signature

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Don Armstrong]

On Wed, 06 Feb 2013, Russ Allbery wrote:
> Don Armstrong  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


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013020624.gf17...@rzlab.ucr.edu

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Russ Allbery]

Don Armstrong  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 (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vca5rvyu@windlord.stanford.edu

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Don Armstrong]

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


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130206204100.gd17...@rzlab.ucr.edu

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Adam D. Barratt]

On 05.02.2013 23:55, Don Armstrong wrote:

On Wed, 06 Feb 2013, Cyril Brulebois wrote:
Daniel Baumann  
(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


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/9700fa19d26232d0f5501dc6bcb64...@mail.adsl.funky-badger.org

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Don Armstrong]

On Wed, 06 Feb 2013, Cyril Brulebois wrote:
> Daniel Baumann  (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


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130205235509.gm6...@rzlab.ucr.edu

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Cyril Brulebois]

Daniel Baumann  (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
Description: Digital signature