Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

>>> Is anybody else interested in helping? Thoughts/comments?
>>
>>Sorry to bump an old thread
>>
>>Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
>>the platform.
>>
>>Clang 3.5 and 3.6 are no longer maintained. The bugs we are
>>discovering and reporting are being closed as "invalid" and "won't
>>fix" because Clang is outside its freshness date.
>>
>>Also pick up this for glibc:
>>http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
>>. Though it was first seen in Clang 3.3, its still a problem today.
>
> ACK, thanks for thinking about this still.
>
> Progress to date has been quiet, but work is ongoing. KiBi has a good
> set of patches ready for d-i already, and I'm working on debian-cd to
> add useful backports support. My first quick-hack attempt failed
> dismally, so I'm midway down a more disruptive but thorough set of
> changes now.

Another pothole for Clang... '-march=native' does not perform as
expected at least about one third of the time. I have not narrowed it
down, but it affects at least MacPorts and Ubuntu. Apple Clang appears
to be OK. I don't recall the results of Debian testing.

When we added code generation tests to our test script, we found Clang
was not generating SSE3, SSSE3, SSE4, AVX, BMI, etc. The work around
in the field is to cat /proc/cpuinfo, and then do something like the
following based on the CPU flags (from
http://github.com/weidai11/cryptopp/blob/master/cryptest.sh):

X86_CPU_FLAGS=$(cat /proc/cpuinfo 2>&1 | "$AWK" '{IGNORECASE=1}{if ($1
== "flags"){print;exit}}' | cut -f 2 -d ':')

if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "ssse3") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mssse3"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.1") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.1"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "sse4.2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-msse4.2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "aes") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-maes"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "pclmulqdq") -ne "0")
]]; then PLATFORM_CXXFLAGS+=("-mpclmul"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdrand") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdrnd"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "rdseed") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mrdseed"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "avx2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mavx2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "bmi2") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-mbmi2"); fi
if [[ ($(echo -n "$X86_CPU_FLAGS" | "$GREP" -c "adx") -ne "0") ]];
then PLATFORM_CXXFLAGS+=("-madx"); fi

Most users don't realize the silent failure is occurring. Ideally,
this would be fixed in the compiler front end.

Also see Clang {3.4|3.5|3.6|3.7} only advertises SSE2:
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616723,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616729,
http://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.4/+bug/1616731,
etc.

Jeff

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Tue, Sep 06, 2016 at 11:27:49PM -0400, Jeffrey Walton wrote:
>> There's something I've been pondering for a while, along with some
>> other folks - it might be useful to do a "jessie and a half" release,
>> similarly to what we did in the etch days. That's *basically* just
>> like a normal jessie release, but with a few key updates:
>>
>>  * backports kernel
>>  * rebuilt d-i to match that kernel
>>  * X drivers
>>  * ... (other things that might be needed for consistency)
>>
>> all rolled up with a small installer image build (netinst, maybe DVD#1).
>>
>> A lot of arm64 machine users would benefit from this, and maybe owners
>> of very recent amd64 machines too, with better support for things on
>> the Skylake platform. Those are the only two architectures I'm
>> thinking of supporting at this point.
>>
>> Is anybody else interested in helping? Thoughts/comments?
>
>Sorry to bump an old thread
>
>Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
>the platform.
>
>Clang 3.5 and 3.6 are no longer maintained. The bugs we are
>discovering and reporting are being closed as "invalid" and "won't
>fix" because Clang is outside its freshness date.
>
>Also pick up this for glibc:
>http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
>. Though it was first seen in Clang 3.3, its still a problem today.

ACK, thanks for thinking about this still.

Progress to date has been quiet, but work is ongoing. KiBi has a good
set of patches ready for d-i already, and I'm working on debian-cd to
add useful backports support. My first quick-hack attempt failed
dismally, so I'm midway down a more disruptive but thorough set of
changes now.

Once that's working, I'll ask on -devel again for package lists.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

On Tue, Sep 06, 2016 at 11:27:49PM -0400, Jeffrey Walton wrote:
> > There's something I've been pondering for a while, along with some
> > other folks - it might be useful to do a "jessie and a half" release,
> > similarly to what we did in the etch days. That's *basically* just
> > like a normal jessie release, but with a few key updates:
> >
> >  * backports kernel
> >  * rebuilt d-i to match that kernel
> >  * X drivers
> >  * ... (other things that might be needed for consistency)
> >
> > all rolled up with a small installer image build (netinst, maybe DVD#1).
> >
> > A lot of arm64 machine users would benefit from this, and maybe owners
> > of very recent amd64 machines too, with better support for things on
> > the Skylake platform. Those are the only two architectures I'm
> > thinking of supporting at this point.
> >
> > Is anybody else interested in helping? Thoughts/comments?
> 
> Sorry to bump an old thread
> 
> Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
> the platform.
> 
> Clang 3.5 and 3.6 are no longer maintained. The bugs we are
> discovering and reporting are being closed as "invalid" and "won't
> fix" because Clang is outside its freshness date.
> 
> Also pick up this for glibc:
> http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
> . Though it was first seen in Clang 3.3, its still a problem today.
> 
> Jeff
> 

Hi Jeff,

Actually, good timing to bump the thread!  Gianfranco has backported LLVM and 
Clang 3.8.

Cheers,
Nicholas


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Ian Jackson]

Henrique de Moraes Holschuh writes ("Re: Thinking about a "jessie and a half" 
release"):
> And so are the microcode packages, which are absolutely required for
> stable operation of at least Skylake and Broadwell right now (or your
> data is toast due to TSX malfunction or one of the multiple undefined
> behavior errata).  
> 
> One or two Skylake motherboards have good enough UEFI updates available,
> but that's like 1% of them. This should get better in time, of course...
> If people would update their firmware frequently in the first place.

Of course a Debian user who has such a BIOS, that updates the
microcode for them, is in no better position (from a software freedom
point of view) than a Debian user who enables non-free to get the
microcode from Debian.  Arguably in many respects they are in a worse
position.

If there is a *practical* benefit to Debian being awkward about
non-free microcode, it lies in being sure that users know what's going
on, discouraging users from buying such hardware in the first place
and perhaps in encourating better behaviour by manufacturers.

Of course it also allows Debian proper to carry on without tainting
its hands with this non-free stuff.  I'm sure that this would make a
lovely case study for a philosophy essay but -devel probably isn't a
good venue for that.

In the meantime I wanted to thank those who are indeed sullying their
hands to try to help users make their machines reliable.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Thinking about a "jessie and a half" release

[Henrique de Moraes Holschuh]

On Tue, Jul 12, 2016, at 10:28, Jeffrey Walton wrote:

> [38229.510127] mce: [Hardware Error]: Machine check events logged
> 
> $ sudo mcelog
> mcelog: Family 6 Model 3d CPU: only decoding architectural errors

Update that bios/UEFI *and* install intel-microcode from
stable-proposed-updates or backports.

Looks like the rather easily triggered mce storm errata, so chances are
the newest microcode will stop that.  Of course, it could be a real
hardware defect as well.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Thinking about a "jessie and a half" release

[Henrique de Moraes Holschuh]

On Sat, Jul 9, 2016, at 07:59, Ben Hutchings wrote:

> Non-free is not part of Debian so those components would need to be
> explicitly installed.
> 
> firmware-nonfree is up-to-date in backports (at least, it is in synch
> with testing and unstable).

And so are the microcode packages, which are absolutely required for
stable operation of at least Skylake and Broadwell right now (or your
data is toast due to TSX malfunction or one of the multiple undefined
behavior errata).  

One or two Skylake motherboards have good enough UEFI updates available,
but that's like 1% of them. This should get better in time, of course...
If people would update their firmware frequently in the first place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?

Sorry to bump an old thread

Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for
the platform.

Clang 3.5 and 3.6 are no longer maintained. The bugs we are
discovering and reporting are being closed as "invalid" and "won't
fix" because Clang is outside its freshness date.

Also pick up this for glibc:
http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548
. Though it was first seen in Clang 3.3, its still a problem today.

Jeff

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

Hi Jeffrey,

On 12 July 2016 at 09:28, Jeffrey Walton  wrote:
>
> I think it would benefit more than Skylake users. The last few
> processors are missing support. Below is from a Core i5-5300U (5th
> gen) and a 3.19.0-64-generic kernel.
>
> **
>
> $ dmesg | egrep -i '(error|failed)'
> ...
> [35679.953137] mce: [Hardware Error]: Machine check events logged
> [35980.749723] mce: [Hardware Error]: Machine check events logged
> [36280.594838] mce: [Hardware Error]: Machine check events logged
> [36580.439940] mce: [Hardware Error]: Machine check events logged
> [37029.202190] mce: [Hardware Error]: Machine check events logged
> [37179.118743] mce: [Hardware Error]: Machine check events logged
> [37629.831878] mce: [Hardware Error]: Machine check events logged
> [37779.748453] mce: [Hardware Error]: Machine check events logged
> [38229.510127] mce: [Hardware Error]: Machine check events logged
>
> $ sudo mcelog
> mcelog: Family 6 Model 3d CPU: only decoding architectural errors
>

Out of curiosity, what does the mcelog version in jessie-backports
output when running this kernel version?

Cheers,
Nicholas

Re: Thinking about a "jessie and a half" release

[Jeffrey Walton]

> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?

I think it would benefit more than Skylake users. The last few
processors are missing support. Below is from a Core i5-5300U (5th
gen) and a 3.19.0-64-generic kernel.

**

$ dmesg | egrep -i '(error|failed)'
...
[35679.953137] mce: [Hardware Error]: Machine check events logged
[35980.749723] mce: [Hardware Error]: Machine check events logged
[36280.594838] mce: [Hardware Error]: Machine check events logged
[36580.439940] mce: [Hardware Error]: Machine check events logged
[37029.202190] mce: [Hardware Error]: Machine check events logged
[37179.118743] mce: [Hardware Error]: Machine check events logged
[37629.831878] mce: [Hardware Error]: Machine check events logged
[37779.748453] mce: [Hardware Error]: Machine check events logged
[38229.510127] mce: [Hardware Error]: Machine check events logged

$ sudo mcelog
mcelog: Family 6 Model 3d CPU: only decoding architectural errors

Re: Thinking about a "jessie and a half" release

[Cyril Brulebois]

Philipp Kern  (2016-07-10):
> On 2016-07-04 18:08, Cyril Brulebois wrote:
> >>How would we keep that working given that backports keeps changing?
> >Backports changing isn't an issue AFAICT if we're only publishing a
> >netinst image which has all the kernel bits (kernel udebs), as opposed
> >to netboot.
> >
> >Or are you thinking of other issues?
> 
> that was the main issue. Apart from the updates part below.

OK.

> 
> >>Would we copy the kernel at the time into a special suite?
> >
> >I don't think that's needed.
> >
> >>How would updates work?
> >
> >Updates to?
> > - d-i: nothing has to change (except if we want to republish a new
> >   image with an ever newer kernel version), see above.
> 
> Where to would we upload d-i?

jessie-backports.

> Under what name?

Not sure I understand the question. If that's for an “jessie+1/2”
alternative, I have no proposals right now.

> With what content?

For src:debian-installer? fork from master, remove everything not
fitting backports (package renames etc.), is probably a better idea
than trying to backport (mostly) kernel config changes. Later such
versions (if needed) can then be prepared by git merging further
from master.

> Would we re-spin stable d-i plus backports-related changes into
> backports?

Based on the above reply, no.

> Would backports ftp-masters be ok with that?

Based on the above reply, that's just the usual “copy most of it,
leave changes that don't make sense for stable aside” policy, so I
would expect they would be. But right, I didn't ask yet.

The installer-$arch/ thing shouldn't have any consequences since it
isn't used yet AFAICT; we might need to iron out some bugs though.

> I feel somewhat uncomfortable with one-offs that are not being
> updated anymore and cannot even be updated if need be because the
> kernel will have disappeared by them (as it tracks testing rather
> than its own version line).

I don't see why we wouldn't be able to update that. Just git merge
from master (and pick whatever newer kernel version it depends on),
and adjust as I mentioned, done.

Note: I don't think it's reasonable to require someone to commit to
doing regular updates for this one-off. But anyway, the “cannot”
part seems bogus to me, as I've just explained.

> > - installed system: as usual for systems with backported packages
> >   (NotAutomatic & ButAutomaticUpgrades).
> 
> So which metapackages would we need to install to keep track of
> new major kernel versions in backports?

Hm? linux-image-$arch from src:linux-latest, as usual?


KiBi.


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Philipp Kern]

Hi,

On 2016-07-04 18:08, Cyril Brulebois wrote:

How would we keep that working given that backports keeps changing?

Backports changing isn't an issue AFAICT if we're only publishing a
netinst image which has all the kernel bits (kernel udebs), as opposed
to netboot.

Or are you thinking of other issues?


that was the main issue. Apart from the updates part below.


Would we copy the kernel at the time into a special suite?


I don't think that's needed.


How would updates work?


Updates to?
 - d-i: nothing has to change (except if we want to republish a new
   image with an ever newer kernel version), see above.


Where to would we upload d-i? Under what name? With what content? Would 
we re-spin stable d-i plus backports-related changes into backports? 
Would backports ftp-masters be ok with that?


I feel somewhat uncomfortable with one-offs that are not being updated 
anymore and cannot even be updated if need be because the kernel will 
have disappeared by them (as it tracks testing rather than its own 
version line).



 - installed system: as usual for systems with backported packages
   (NotAutomatic & ButAutomaticUpgrades).


So which metapackages would we need to install to keep track of new 
major kernel versions in backports?


Kind regards and thanks
Philipp Kern

Re: Thinking about a "jessie and a half" release

[Ben Hutchings]

On Fri, 2016-07-08 at 23:17 -0400, Nicholas D Steeves wrote:
> On 4 July 2016 at 18:38, Ben Hutchings  wrote:
[...]
> > > Also, I imagine this might one day be necessary,
> > > particularly if tracking backported linux-src due to ABI changes
> > > between kernels, eg: if the out-of-tree drivers in testing begin
> > > to
> > > require >> linux-src=3.16.0 ABI.
> > 
> > I think you mean API.  We don't ship out-of-tree drivers as
> > binaries.
> > 
> 
> Yes, you're absolutely right, I meant API.  Given that people with,
> for example broadcom wifi chipsets will be using this new Debian spin
> (Maybe it should be called Debian Fresh Spin?) in the hopes of
> hardware enablement, do you think it should pin the bpo versions of
> out-of-tree drivers, and also include bpo non-free firmware?

Non-free is not part of Debian so those components would need to be
explicitly installed.

firmware-nonfree is up-to-date in backports (at least, it is in synch
with testing and unstable).

Ben.

-- 

Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

On 4 July 2016 at 18:38, Ben Hutchings  wrote:
> On Mon, 2016-07-04 at 16:01 -0400, Nicholas D Steeves wrote:
> [...]

> [...]
>> So for radeon hardware enablement, there is 1) the proprietary driver
>
> fglrx is dead upstream and removed from unstable.  (It's still in
> jessie-backports, but should be removed there as well.)

Ok, so a very real need for the new radeon driver bpo is/has probably
emerging/ed.  And Bug #828087 on others mentioned in another email to
this thread are blockers to a bpo of xorg-core, which would need to
happen first.

> [...]
>> Also, I imagine this might one day be necessary,
>> particularly if tracking backported linux-src due to ABI changes
>> between kernels, eg: if the out-of-tree drivers in testing begin to
>> require >> linux-src=3.16.0 ABI.
>
> I think you mean API.  We don't ship out-of-tree drivers as binaries.
>

Yes, you're absolutely right, I meant API.  Given that people with,
for example broadcom wifi chipsets will be using this new Debian spin
(Maybe it should be called Debian Fresh Spin?) in the hopes of
hardware enablement, do you think it should pin the bpo versions of
out-of-tree drivers, and also include bpo non-free firmware?

Cheers,
Nicholas

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

On 5 July 2016 at 08:40, Samuel Henrique  wrote:
>
> 2016-07-05 7:43 GMT-03:00 Jose R R :
>>
>> We're getting to the point where there's a fairly pressing need for
>> arm64 - the more useful hardware is starting to get a wider distribution
>> and we don't really have anything for people who want to run Debian
>> that gets them a supported system with an upgrade path.
>
>
> We have Debian Stretch, which is what i recommend to anybody who wants do
> install Debian as a desktop.
>
> I understand the difference of running Debian Testing and Debian Stable with
> some backported packages, but is it really worth it?
> Shouldn't we discuss more the usability of Testing as a solid release, or
> maybe start doing a stable release and another release kinda like Testing
> but with more stability guarantees?
>
> I'm not really sure, but i think opensuse has a model like that.
>
...
> They always end up using Debian Testing, knowing that the main risk comes
> when the unfreeze happens and that while the freeze is rolling they will
> have a more stable debian (compared to when unfreezed).

I personally like to test stable+1 on my laptop by changing stable to
stable+1_codename about a month after the freeze happens; it then
transitions to stable automatically, and no trouble with the unfreeze.
As for building off of a [semi]rolling release model, from testing,
I'm pessimistic because of historical precedents for success.  For
example: http://cut.debian.net/
https://www.reddit.com/r/debian/comments/3yeg6z/what_happened_with_debian_cut/

Tanglu seems to have stalled, and SolydXK is now stable+bpos, but
maybe they will go back to using stable+1 once it freezes? And a
recent discussion on running testing ->
http://forums.debian.net/viewtopic.php?f=30&t=128598&start=0

Of course, I'd also love to see it work! :-)  I'm guessing it requires
a substantial investment of time and a very dedicated—and large
enough—team.

Cheers,
Nicholas

Re: Thinking about a "jessie and a half" release

[Riku Voipio]

On Thu, Jul 07, 2016 at 12:24:03PM +0200, Alexander Wirt wrote:
> On Thu, 07 Jul 2016, Riku Voipio wrote:
> > On Mon, Jul 04, 2016 at 02:01:03PM +0100, Steve McIntyre wrote:
> > > There's something I've been pondering for a while, along with some
> > > other folks - it might be useful to do a "jessie and a half" release,
> > > similarly to what we did in the etch days. That's *basically* just
> > > like a normal jessie release, but with a few key updates:
> > > 
> > >  * backports kernel
> > >  * rebuilt d-i to match that kernel
> > >  * X drivers
> > >  * ... (other things that might be needed for consistency)
> > > 
> > > all rolled up with a small installer image build (netinst, maybe DVD#1).
> > > 
> > > A lot of arm64 machine users would benefit from this
> > 
> > One particular pain point is libssl. The version in jessie:
> > 
> > - Is too old for providing HTTP/2 servers for chrome [1]
> > - Lacks API features already used by apps like nodejs, #815272
> > - Has no arm64 optimizations 
> > 
> > The problem is that uploading latest openssl from unstable to
> > jessie-backports is not really feasible (ABI break and security
> > maintainance needed...). 
> In fact the maintainer uploaded a new openssl to backports and I approved it
> an hour again or so.
 
Great, I love to be proven wrong :) Thanks Kurt! 

Riku 

Re: Thinking about a "jessie and a half" release

[Alexander Wirt]

On Thu, 07 Jul 2016, Riku Voipio wrote:

> On Mon, Jul 04, 2016 at 02:01:03PM +0100, Steve McIntyre wrote:
> > There's something I've been pondering for a while, along with some
> > other folks - it might be useful to do a "jessie and a half" release,
> > similarly to what we did in the etch days. That's *basically* just
> > like a normal jessie release, but with a few key updates:
> > 
> >  * backports kernel
> >  * rebuilt d-i to match that kernel
> >  * X drivers
> >  * ... (other things that might be needed for consistency)
> > 
> > all rolled up with a small installer image build (netinst, maybe DVD#1).
> > 
> > A lot of arm64 machine users would benefit from this
> 
> One particular pain point is libssl. The version in jessie:
> 
> - Is too old for providing HTTP/2 servers for chrome [1]
> - Lacks API features already used by apps like nodejs, #815272
> - Has no arm64 optimizations 
> 
> The problem is that uploading latest openssl from unstable to
> jessie-backports is not really feasible (ABI break and security
> maintainance needed...). 
In fact the maintainer uploaded a new openssl to backports and I approved it
an hour again or so.

Alex

Re: Thinking about a "jessie and a half" release

[Riku Voipio]

On Mon, Jul 04, 2016 at 02:01:03PM +0100, Steve McIntyre wrote:
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
> 
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
> 
> all rolled up with a small installer image build (netinst, maybe DVD#1).
> 
> A lot of arm64 machine users would benefit from this

One particular pain point is libssl. The version in jessie:

- Is too old for providing HTTP/2 servers for chrome [1]
- Lacks API features already used by apps like nodejs, #815272
- Has no arm64 optimizations 

The problem is that uploading latest openssl from unstable to
jessie-backports is not really feasible (ABI break and security
maintainance needed...). 

Riku

[1] 
https://ma.ttias.be/day-google-chrome-disables-http2-nearly-everyone-may-31st-2016/
#815272 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815272

Re: Thinking about a "jessie and a half" release

[Timo Jyrinki]

2016-07-06 21:18 GMT+03:00 Teemu Likonen :
> Problem 2: CPU's built-in graphics work badly. I tried with kernel 4.5
> and with kernel option i915.preliminary_hw_support=1 (as someone
> suggested). Couldn't start X window system. Fortunately I have better
> graphics card so I don't care that much about the built-in one. Skylake
> graphics probably need some yet unreleased kernel version.

It's not just the kernel that affects graphics. libdrm,
xserver-xorg-video-intel, xserver itself (to an extent required by the
intel driver) and mesa all play an important role there. The
Xorg.0.log might contain some explanations. Skylake support was deemed
stable (not preliminary) in kernel 4.3, so the option would not have
an affect.

With recent software the intel driver is strictly not necessary
anymore, as the generic modesetting driver with glamor acceleration
also works well.

-Timo

Re: Thinking about a "jessie and a half" release

[Holger Levsen]

On Wed, Jul 06, 2016 at 09:18:24PM +0300, Teemu Likonen wrote:
> Problem 2: CPU's built-in graphics work badly.
> [...] Skylake
> graphics probably need some yet unreleased kernel version.

Skylake != Skylake

I have another Skylake system which works ok with 4.6 kernel and
xorg-server-video-intel from jessie-backports. (Fullscreen video
on 4k displays is still unusable, but normal 4k operation or fullscreen
in other resolutions work fine.)

(Installation was done with the jessie installer too.)

> I wish it were a standard practice to create new netinst images with
> backported kernels.

Same here.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Teemu Likonen]

Steve McIntyre [2016-07-04 14:01:03+01] wrote:

> it might be useful to do a "jessie and a half" release, [...] That's
> *basically* just like a normal jessie release, but with a few key
> updates:
>
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)

A short version: I have a "Skylake" chip and motherboard. Debian 8.5
installation worked with the normal 3.16 kernel except that bug #785149
caused trouble with Grub. CPU's built-in graphics work badly with X
window system, even with kernel 4.5.

A long version: I managed to install Debian 8.5 (netinstall) to my new
Skylake machine (MSI Z170A Gaming Pro motherboard + Intel Core i7-6700K
processor). The installation worked fine with kernel 3.16 (network and
DVI-connected monitor). Before doing anything serious I upgraded the
kernel 4.5 from backports (now 4.6).

Problem 1: Debian 8.5 installer couldn't install Grub to /dev/nvme0n1xx
device (NVME M.2 SSD) and the error message didn't say anything useful.
I went through without Grub (I was using expert install mode). I booted
again the installer, chose rescue/recovery mode, chrooted to the new
install and installed grub manually. Then it worked. The issue is
reported as #785149 and there has been some work on it.

Problem 2: CPU's built-in graphics work badly. I tried with kernel 4.5
and with kernel option i915.preliminary_hw_support=1 (as someone
suggested). Couldn't start X window system. Fortunately I have better
graphics card so I don't care that much about the built-in one. Skylake
graphics probably need some yet unreleased kernel version.

> all rolled up with a small installer image build (netinst, maybe
> DVD#1).

I wish it were a standard practice to create new netinst images with
backported kernels. (Even though my actual problems were with
installer's Grub stage.)

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: Thinking about a "jessie and a half" release

[Breno Leitao]

On 07/05/2016 07:43 PM, Steve McIntyre wrote:

On Tue, Jul 05, 2016 at 04:15:36PM -0300, Breno Leitao wrote:

Steve,

On 07/04/2016 10:01 AM, Steve McIntyre wrote:

A lot of arm64 machine users would benefit from this, and maybe owners
of very recent amd64 machines too.


ppc64el port would take benefit from it also, since, there were many new
kernel features that made linux after 3.16.


ACK. Just kernel, or any other bits?


I think just the kernel is enough for this 'jessie and half' release. 
Userspace packages upgrade can wait for Stretch.

Re: Thinking about a "jessie and a half" release

[Holger Levsen]

On Wed, Jul 06, 2016 at 08:55:39AM +0100, Steve McIntyre wrote:
> ACK - I'm not wedded to the name in the slightest. It's more a
> proposal of what we're going to do.
 
ok, cool.

> >maybe "jessie+bpo-installer" would be a better fit?
> Maybe that fits, but it's horrid name.

I don't think it's that horrible, OTOH it's descriptivem, which IMO is a
big plus.

"Jessie+half" OTOH implies things it doesnt really hold up too, plus
it's confusing, cause the rules for this shall be different than the
rules we had for "Etch+half", so yes, I think, a different name would be
apt.

Maybe even "8.5+bpo installer"?

Other suggestions?

> >and maybe, we could also do such releases more regularily (if this works
> >out and turns out not to be that much extra work…)
> *possibly*, yes.

I guess our users would applaud that…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Tixy]

On Wed, 2016-07-06 at 08:55 +0100, Steve McIntyre wrote:
> On Wed, Jul 06, 2016 at 07:33:38AM +, Holger Levsen wrote:
[...]
> > I'd like to suggest *not* to call it jessie+half, as we have used
> >that term already (for etch+half) and there we had a frozen/stable kernel,
> >not a moving target like bpo.
> 
> ACK - I'm not wedded to the name in the slightest.

And it could be misleading, I'm already running Jessie and a half

$ cat /etc/debian_version 
8.5

:-)

-- 
Tixy

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Wed, Jul 06, 2016 at 07:33:38AM +, Holger Levsen wrote:
>On Tue, Jul 05, 2016 at 11:43:14PM +0100, Steve McIntyre wrote:
>> >I assume "forking" the kernel for jessie+½ as done for etch-and-half is
>> >the plan already? (forking as in using a new source package…)
>> God, no - really *not* that way at all. I'm thinking of using the
>> kernel in backports at the time we do a build/test/release
>> cycle. People using this and updating will end up following bpo for a
>> while until the Stretch release.
> 
>ah, ok. 
>
>then I'd like to suggest *not* to call it jessie+half, as we have used
>that term already (for etch+half) and there we had a frozen/stable kernel,
>not a moving target like bpo.

ACK - I'm not wedded to the name in the slightest. It's more a
proposal of what we're going to do.

>maybe "jessie+bpo-installer" would be a better fit?

Maybe that fits, but it's horrid name.

>and maybe, we could also do such releases more regularily (if this works
>out and turns out not to be that much extra work…)

*possibly*, yes.

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

Re: Thinking about a "jessie and a half" release

[Holger Levsen]

On Tue, Jul 05, 2016 at 11:43:14PM +0100, Steve McIntyre wrote:
> >I assume "forking" the kernel for jessie+½ as done for etch-and-half is
> >the plan already? (forking as in using a new source package…)
> God, no - really *not* that way at all. I'm thinking of using the
> kernel in backports at the time we do a build/test/release
> cycle. People using this and updating will end up following bpo for a
> while until the Stretch release.
 
ah, ok. 

then I'd like to suggest *not* to call it jessie+half, as we have used
that term already (for etch+half) and there we had a frozen/stable kernel,
not a moving target like bpo.

maybe "jessie+bpo-installer" would be a better fit?

and maybe, we could also do such releases more regularily (if this works
out and turns out not to be that much extra work…)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Tue, Jul 05, 2016 at 04:15:36PM -0300, Breno Leitao wrote:
>Steve,
>
>On 07/04/2016 10:01 AM, Steve McIntyre wrote:
>>A lot of arm64 machine users would benefit from this, and maybe owners
>>of very recent amd64 machines too.
>
>ppc64el port would take benefit from it also, since, there were many new
>kernel features that made linux after 3.16.

ACK. Just kernel, or any other bits?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Tue, Jul 05, 2016 at 06:11:24PM +, Holger Levsen wrote:
>On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote:
>> I still wonder if a fork of the last linux:src=4.4, updated to bring
>> it to linux-4.4.14 would be a lower support burden?  I'm still finding
>> that there are a fair number of issues reported with 4.5.x and 4.6.x
>> on various mailing lists.  Does anyone know how Skylake support is
>> like for the 4.4.x branch?  What is arm64 support like?  I've
>> corresponded with Ben Hutchings, and he tells me an LTS kernel effort
>> is ok to do, but unofficial.  Personally, I believe following bpo
>> kernel is a bit of a rodeo in comparison to what one expects from
>> Debian Stable, which is why I'm looking into this project. 
>
>Steve, *this* is a major open question as I see it, what's you take on
>it? 
>
>I assume "forking" the kernel for jessie+½ as done for etch-and-half is
>the plan already? (forking as in using a new source package…)

God, no - really *not* that way at all. I'm thinking of using the
kernel in backports at the time we do a build/test/release
cycle. People using this and updating will end up following bpo for a
while until the Stretch release.

>(Probably related to the remark that jessie+½ might become obsolete by
>stretch quite soon after too… related as in: what will be the next
>upstream LTS kernel?)
>
>
>-- 
>cheers,
>   Holger


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Tue, Jul 05, 2016 at 02:37:06PM +0200, Martin Zobel-Helas wrote:
>Hi Steve, 
>
>On Mon Jul 04, 2016 at 14:01:03 +0100, Steve McIntyre wrote:
>> A lot of arm64 machine users would benefit from this, and maybe owners
>> of very recent amd64 machines too, with better support for things on
>> the Skylake platform. Those are the only two architectures I'm
>> thinking of supporting at this point.
>> 
>> Is anybody else interested in helping? Thoughts/comments?
>
>from a cloud image users perspective this sounds like a great idea.
>There are several things eg. in the kernel with 10GE network drivers,
>where a newer kernel would  definitivly help a lot. Also maybe newer
>cloud-init and friends would help.
>
>Please go for it.
>
>+1 from my side.

ACk, thanks for the feedback.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Mon, Jul 04, 2016 at 07:05:42PM +0200, Ben Hutchings wrote:
>On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote:
>> Hey folks,
>> 
>> There's something I've been pondering for a while, along with some
>> other folks - it might be useful to do a "jessie and a half" release,
>> similarly to what we did in the etch days.
>
>As I recall, that added extra packages to the etch suite, whereas it
>seems like this would take updated packages the jessie-backports suite.

Yup, that's what I'm thinking.

>> That's *basically* just like a normal jessie release, but with a few
>> key updates:
>> 
>>  * backports kernel
>>  * rebuilt d-i to match that kernel
>>  * X drivers
>>  * ... (other things that might be needed for consistency)
>
>For the kernel: firmware-nonfree, kernel-wedge, linux-base, linux-
>latest, linux-signed, sbsigntool.  All of those are already in jessie-
>backports, except the last two which will be needed starting with 4.7.

Right.

>For user-space graphics: libdrm and mesa, presumably.
>
>> all rolled up with a small installer image build (netinst, maybe DVD#1).
>> 
>> A lot of arm64 machine users would benefit from this, and maybe owners
>> of very recent amd64 machines too, with better support for things on
>> the Skylake platform. Those are the only two architectures I'm
>> thinking of supporting at this point.
>> 
>> Is anybody else interested in helping? Thoughts/comments?
>
>When do you anticipate this would be releasable?  Would it really be
>long enough before stretch, to be worthwhile?

I'm thinking late July / early August, which would still give us a
number of months lead on Stretch.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: Thinking about a "jessie and a half" release

[Breno Leitao]

Steve,

On 07/04/2016 10:01 AM, Steve McIntyre wrote:

A lot of arm64 machine users would benefit from this, and maybe owners
of very recent amd64 machines too.


ppc64el port would take benefit from it also, since, there were many new
kernel features that made linux after 3.16.

Re: Thinking about a "jessie and a half" release

[Cyril Brulebois]

Holger Levsen  (2016-07-05):
> On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote:
> > I still wonder if a fork of the last linux:src=4.4, updated to bring
> > it to linux-4.4.14 would be a lower support burden?  I'm still finding
> > that there are a fair number of issues reported with 4.5.x and 4.6.x
> > on various mailing lists.  Does anyone know how Skylake support is
> > like for the 4.4.x branch?  What is arm64 support like?  I've
> > corresponded with Ben Hutchings, and he tells me an LTS kernel effort
> > is ok to do, but unofficial.  Personally, I believe following bpo
> > kernel is a bit of a rodeo in comparison to what one expects from
> > Debian Stable, which is why I'm looking into this project. 
> 
> Steve, *this* is a major open question as I see it, what's you take on
> it? 
> 
> I assume "forking" the kernel for jessie+½ as done for etch-and-half is
> the plan already? (forking as in using a new source package…)

AFAICT the plan is to use whatever is in backports and confirmed to just
work at the time, release, and be happy.


KiBi.


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Holger Levsen]

On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote:
> I still wonder if a fork of the last linux:src=4.4, updated to bring
> it to linux-4.4.14 would be a lower support burden?  I'm still finding
> that there are a fair number of issues reported with 4.5.x and 4.6.x
> on various mailing lists.  Does anyone know how Skylake support is
> like for the 4.4.x branch?  What is arm64 support like?  I've
> corresponded with Ben Hutchings, and he tells me an LTS kernel effort
> is ok to do, but unofficial.  Personally, I believe following bpo
> kernel is a bit of a rodeo in comparison to what one expects from
> Debian Stable, which is why I'm looking into this project. 

Steve, *this* is a major open question as I see it, what's you take on
it? 

I assume "forking" the kernel for jessie+½ as done for etch-and-half is
the plan already? (forking as in using a new source package…)

(Probably related to the remark that jessie+½ might become obsolete by
stretch quite soon after too… related as in: what will be the next
upstream LTS kernel?)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Ben Hutchings]

On Tue, 2016-07-05 at 08:25 +0100, Rebecca N. Palmer wrote:
> Would it be possible/reasonable (at least for stretch) to have the 
> installer detect this and ask "your hardware appears to be too new for 
> this release, would you like to enable -backports?"

It might be, but it's going to be hard to tell what's 'too new'.  We
could check whether there are drivers that match the device IDs for the
detected PCI and USB devices.  However, we know that device IDs are
sometimes added to a driver before the driver has stable support for
those devices.  That question might also be giving false hope, in that
the devices not supported in stable might still be unsupported in
stable-backports.

> On 04/07/16 23:38, Ben Hutchings wrote:
> > As I understand it, xserver-xorg-video-modesetting should be used
> > instead of xserver-xorg-video-intel, for chips supported by the i915
> > kernel driver.  So the latter should be changed to limit the device IDs
> > it claims, then both of them should be backported.
> 
> This appears to be causing at least one actual problem: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828087
[...]

Once this is fixed in unstable and then testing, I wonder how to fix
this for jessie-backports.  The modesetting driver is now part of
xserver-xorg-core and that has had a driver ABI bump which would
require backporting other driver packages.

Ben.

-- 

Ben Hutchings
Life is what happens to you while you're busy making other plans.
   - John
Lennon


signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Samuel Henrique]

2016-07-05 7:43 GMT-03:00 Jose R R :

> > Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea
> Well IBM set a precedent for that: OS/2.
> Accordingly, Jessie BP could be called Jessie/2 ;-)


​Well, that would be a half Jessie, not Jessie and a half, right?​ We could
use 3Jessie/2 or Jessie3/2, or maybe not.

Mark Brown

> We're getting to the point where there's a fairly pressing need for
> arm64 - the more useful hardware is starting to get a wider distribution
> and we don't really have anything for people who want to run Debian
> that gets them a supported system with an upgrade path.
>

​We have Debian Stretch, which is what i recommend to anybody who wants do
install Debian as a desktop.

I understand the difference of running Debian Testing and Debian Stable
with some backported packages, but is it really worth it?
Shouldn't we discuss more the usability of Testing as a solid release, or
maybe start doing a stable release and another release kinda like Testing
but with more stability guarantees?

I'm not really sure, but i think opensuse has a model like that.

I use debian for a considerable amount of time now, but just started
interacting with the community recently, having installed debian to a lot
of new users on installfests over the years, one of the most common
problems i found out for novice Debian users is that they don't really know
how Debian releases works and thinks using stable in their laptop bought
last year is a good idea, then i always end up having a conversation where
they're needing help with problems related to using stable, i have to
explain things like: why their performance is crap, why they can't see
youtube html5 videos on iceweasel version lastversion-4, why they can't
install softwares like steam (wheezy was a hard one on this)* and how the
testing stability is the same, or better, than of the other distros they
used to use.
They always end up using Debian Testing, knowing that the main risk comes
when the unfreeze happens and that while the freeze is rolling they will
have a more stable debian (compared to when unfreezed).

*these are just some of the various conversations i've had.

​Unfortunately i' not attending DebConf, but it is a great opportunity to
discuss​ things like this there, maybe even form a team and work on
policies changes for this "new testing" release, if i'm not dreaming too
big.


Samuel Henrique O. P. [samueloph]

Re: Thinking about a "jessie and a half" release

[Martin Zobel-Helas]

Hi Steve, 

On Mon Jul 04, 2016 at 14:01:03 +0100, Steve McIntyre wrote:
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
> 
> Is anybody else interested in helping? Thoughts/comments?

from a cloud image users perspective this sounds like a great idea.
There are several things eg. in the kernel with 10GE network drivers,
where a newer kernel would  definitivly help a lot. Also maybe newer
cloud-init and friends would help.

Please go for it.

+1 from my side.

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Re: Thinking about a "jessie and a half" release

[Jose R R]

On Tue, Jul 5, 2016 at 2:01 AM, Christian Seiler  wrote:
>
> On 07/04/2016 03:01 PM, Steve McIntyre wrote:
> > There's something I've been pondering for a while, along with some
> > other folks - it might be useful to do a "jessie and a half" release,
> > similarly to what we did in the etch days. That's *basically* just
> > like a normal jessie release, but with a few key updates:
> >
> >  * backports kernel
> >  * rebuilt d-i to match that kernel
> >  * X drivers
> >  * ... (other things that might be needed for consistency)
> >
> > all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea
Well IBM set a precedent for that: OS/2.
Accordingly, Jessie BP could be called Jessie/2 ;-)

> to regularly have a "backports installer" netinst image? So when
> 8.6 (or 8.7 if it takes longer) comes around, there'll be an image,
> part of the point release, that will contain the backports kernel
> that's current at that time, plus the installer will enable backports
> automatically, plus it will install a preferences.d file that will
> enable pulling kernel + X11 drivers from backports. (But not other
> things.)
>
> This could then be a regular part of the released installer images,
> and any new major release (e.g. Stretch 9.0) would enable the
> preferences.d file + backports automatically, but would still use
> the regular kernel at that point (because there'd be no backports
> then).
>
> That way, you'd have a little more work in the installer in creating
> an image that uses a backports kernel, but there'd be no need in
> having to support a new release in addition to Jessie, because the
> installed system would be equivalent to Jessie + upgrade kernel to
> backports + remove old kernel package. Which is already something
> that people do _now_.
>
> Regards,
> Christian
>


Good luck!

-- 
Jose R R
http://metztli.it
-
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
-
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
-

Re: Thinking about a "jessie and a half" release

[Mark Brown]

On Tue, Jul 05, 2016 at 10:52:37AM +0200, Ben Hutchings wrote:
> On Tue, 2016-07-05 at 10:07 +0200, Mark Brown wrote:

> > We're getting to the point where there's a fairly pressing need for
> > arm64 - the more useful hardware is starting to get a wider distribution
> > and we don't really have anything for people who want to run Debian
> > that gets them a supported system with an upgrade path.

> I'm not questioning whether it would be good to have this now.  But we
> don't have it now and won't have it for some time.

So long as it's substantially before the next release it shuld still be
useful.


signature.asc
Description: PGP signature

Re: Thinking about a "jessie and a half" release

[Christian Seiler]

On 07/04/2016 03:01 PM, Steve McIntyre wrote:
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
> 
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
> 
> all rolled up with a small installer image build (netinst, maybe DVD#1).

Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea
to regularly have a "backports installer" netinst image? So when
8.6 (or 8.7 if it takes longer) comes around, there'll be an image,
part of the point release, that will contain the backports kernel
that's current at that time, plus the installer will enable backports
automatically, plus it will install a preferences.d file that will
enable pulling kernel + X11 drivers from backports. (But not other
things.)

This could then be a regular part of the released installer images,
and any new major release (e.g. Stretch 9.0) would enable the
preferences.d file + backports automatically, but would still use
the regular kernel at that point (because there'd be no backports
then).

That way, you'd have a little more work in the installer in creating
an image that uses a backports kernel, but there'd be no need in
having to support a new release in addition to Jessie, because the
installed system would be equivalent to Jessie + upgrade kernel to
backports + remove old kernel package. Which is already something
that people do _now_.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Thinking about a "jessie and a half" release

[Ben Hutchings]

On Tue, 2016-07-05 at 10:07 +0200, Mark Brown wrote:
> On Mon, Jul 04, 2016 at 07:05:42PM +0200, Ben Hutchings wrote:
> > On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote:
> 
> > > A lot of arm64 machine users would benefit from this, and maybe owners
> > > of very recent amd64 machines too, with better support for things on
> > > the Skylake platform. Those are the only two architectures I'm
> > > thinking of supporting at this point.
> 
> > > Is anybody else interested in helping? Thoughts/comments?
> 
> > When do you anticipate this would be releasable?  Would it really be
> > long enough before stretch, to be worthwhile?
> 
> We're getting to the point where there's a fairly pressing need for
> arm64 - the more useful hardware is starting to get a wider distribution
> and we don't really have anything for people who want to run Debian
> that gets them a supported system with an upgrade path.

I'm not questioning whether it would be good to have this now.  But we
don't have it now and won't have it for some time.

Ben.

-- 

Ben Hutchings
Life is what happens to you while you're busy making other plans.
   - John
Lennon


signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote:
>>>
>>> Is anybody else interested in helping? Thoughts/comments?
>
>Yes, it's a project I'm already working on ;-)  Is this project a
>candidate for a new Debian Team?

I guess so, yes. :-)

>>  2. Does it have to be called "jessie and a half"? (How much is the
>> concept understood across users? Wouldn't it be a better idea to
>> squeeze the "backports" concept into the name somehow?)
>
>Maybe something like jessie-fresh-unofficial?

I'm definitely *not* thinking of saying this is "unofficial" - I'm
wanting this to be blessed as an additional installation option here.

>On 4 July 2016 at 13:13, Hideki Yamane  wrote:
>>
>>  Just a comment. I don't have any objection for this proposal.
>>
>>  However, not only half but also updates with some point is better
>>  to deliver value for users, I hope it'll be in Stretch cycle.
>>
>>  Recently I've read "lean software development" and it's quite
>>  impressive for me. "deliver value to users" is one of the most
>>  important thing in Debian (it means "do continuous improvement
>>  for stable"), IMO.
>
>Agreed!  Also, OpenSUSE has been doing this with their post-42.x
>release model.  Mind you, to the best of my knowledge Debian has
>always cherry picked fixes and essential hardware enablement fixes for
>the stable packages (eg: intel-microcode).  This newly proposed Debian
>project seems to be a more aggressive approach...but does it also have
>a client machine focus to the exclusion of servers, or should it serve
>both?

I'm more concerned about easy installation on new "client" x86
machines at this point, and for arm64 machines in general as they've
seen massive changes since we released jessie. I don't think x86
server machines are such an issue, but I'm open-minded if somebody
wants to argue otherwise.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Re: Thinking about a "jessie and a half" release

[Mark Brown]

On Mon, Jul 04, 2016 at 07:05:42PM +0200, Ben Hutchings wrote:
> On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote:

> > A lot of arm64 machine users would benefit from this, and maybe owners
> > of very recent amd64 machines too, with better support for things on
> > the Skylake platform. Those are the only two architectures I'm
> > thinking of supporting at this point.

> > Is anybody else interested in helping? Thoughts/comments?

> When do you anticipate this would be releasable?  Would it really be
> long enough before stretch, to be worthwhile?

We're getting to the point where there's a fairly pressing need for
arm64 - the more useful hardware is starting to get a wider distribution
and we don't really have anything for people who want to run Debian
that gets them a supported system with an upgrade path.


signature.asc
Description: PGP signature

Re: Thinking about a "jessie and a half" release

[Steve McIntyre]

On Mon, Jul 04, 2016 at 03:12:34PM +0200, Cyril Brulebois wrote:
>Hi,
>
>Steve McIntyre  (2016-07-04):
>> There's something I've been pondering for a while, along with some
>> other folks - it might be useful to do a "jessie and a half" release,
>> similarly to what we did in the etch days. That's *basically* just
>> like a normal jessie release, but with a few key updates:
>> 
>>  * backports kernel
>
>That's a given.
>
>>  * rebuilt d-i to match that kernel
>
>You know there are patches around for that.

ACK. :-)

>>  * X drivers
>
>I don't see backports for them.

I installed a backport Intel xserver driver over the weekend at the
installfest, and it helped the user in question.

>>  * ... (other things that might be needed for consistency)
>> 
>> all rolled up with a small installer image build (netinst, maybe
>> DVD#1).
>
>That'd probably make it easy to decide how to resolve open questions
>with my "d-i vs. backported kernel" patches.

Cool.

>> Is anybody else interested in helping? Thoughts/comments?
>
>Questions:
> 1. Is it going to pick pieces from backports only? (See X question
>above.)

That's my current plan, unless people have good arguments otherwise.

> 2. Does it have to be called "jessie and a half"? (How much is the
>concept understood across users? Wouldn't it be a better idea to
>squeeze the "backports" concept into the name somehow?)

I'm not attached to any particular name. Something like "Jessie
Backport August 2016" would work for me too - suggest a better name?

> 3. What about security support once the system is installed? (Which
>can be answered along with 1., I suppose.)

Most of the core packages I'd expect to use in backports are seeing
regular updates AFAICS. That's probably enough?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Re: Thinking about a "jessie and a half" release

[Russell Stuart]

On Tue, 2016-07-05 at 08:25 +0100, Rebecca N. Palmer wrote:
> Have you reported this bug (with the full warnings)?  If not, please
> do so.

I haven't.  If I got a response at all to "My monitor doesn't work" it
looks to me it would be: compile latest source with instrumentation
turned on and send log.  I've tried compiling the Intel drivers before
- I could not get patches to apply.

Fortunately, others get the same backtrace:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523088

It probably isn't related to my monitor not displaying, but I won't be
able to tell until 4.8, when the patch addressing that report is
scheduled to make it to a released kernel.  Like I said, progress is
slw.

My point is really the 4.4 kernel is nothing special for amd64.
 Laptop's with Intel chipsets that started shipping over 6 months ago
don't work 100% with it.  Actually from memory the Intel GPU driver
opps's on occasion in 4.4.

signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Rebecca N. Palmer]

Would it be possible/reasonable (at least for stretch) to have the 
installer detect this and ask "your hardware appears to be too new for 
this release, would you like to enable -backports?"


On 04/07/16 23:38, Ben Hutchings wrote:

As I understand it, xserver-xorg-video-modesetting should be used
instead of xserver-xorg-video-intel, for chips supported by the i915
kernel driver.  So the latter should be changed to limit the device IDs
it claims, then both of them should be backported.


This appears to be causing at least one actual problem: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828087


(The other backports-kernel bugs known to me are 
https://lists.debian.org/debian-backports/2016/06/threads.html#00133 
(appears to be fixed in 4.6) and 
https://lists.debian.org/debian-backports/2016/06/threads.html#00139 (no 
details yet)).


Russell Stuart wrote:

Currently 4.6.0 doesn't work with skylake for me when I plug in a
3440x1440 monitor on a Dell XPS 9550, both with and without xserver-
xorg-video-intel installed.  It never has worked reliably on any kernel
version.  Currently, the monitor works maybe 20% of the time - so if
you persist for 5 boots you've got a reasonable chance of getting
lucky. The only noticeable change from 4.5 to 4.6 is in the kernel
backtraces produced - they have got fewer, and they are only warnings
now.


Have you reported this bug (with the full warnings)?  If not, please do so.

Re: Thinking about a "jessie and a half" release

[Russell Stuart]

On Tue, 2016-07-05 at 00:38 +0200, Ben Hutchings wrote:
> As I understand it, xserver-xorg-video-modesetting should be used
> instead of xserver-xorg-video-intel, for chips supported by the i915
> kernel driver.  So the latter should be changed to limit the device
> IDs it claims, then both of them should be backported.

Currently 4.6.0 doesn't work with skylake for me when I plug in a
3440x1440 monitor on a Dell XPS 9550, both with and without xserver-
xorg-video-intel installed.  It never has worked reliably on any kernel
version.  Currently, the monitor works maybe 20% of the time - so if
you persist for 5 boots you've got a reasonable chance of getting
lucky. The only noticeable change from 4.5 to 4.6 is in the kernel
backtraces produced - they have got fewer, and they are only warnings
now.

So from my point of view Intel still hasn't produced a working kernel
driver for hardware they released a year ago.  I sincerely hope they
get the thing stable before we get to stretch, but to date progress has
been very slow.

signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Ben Hutchings]

On Mon, 2016-07-04 at 16:01 -0400, Nicholas D Steeves wrote:
[...]
> > >  * rebuilt d-i to match that kernel
> > 
> > You know there are patches around for that.
> > 
> > >  * X drivers
> > 
> > I don't see backports for them.
> 
> libdrm2: 2.4.68-1~bpo8+1
> libgl1-mesa-.*: 11.1.3-1~bpo8+1
> xserver-xorg-video-intel:2:2.99.917+git20160522-1~bpo8+1

As I understand it, xserver-xorg-video-modesetting should be used
instead of xserver-xorg-video-intel, for chips supported by the i915
kernel driver.  So the latter should be changed to limit the device IDs
it claims, then both of them should be backported.

[...]
> So for radeon hardware enablement, there is 1) the proprietary driver

fglrx is dead upstream and removed from unstable.  (It's still in
jessie-backports, but should be removed there as well.)

[...]
> Also, I imagine this might one day be necessary,
> particularly if tracking backported linux-src due to ABI changes
> between kernels, eg: if the out-of-tree drivers in testing begin to
> require >> linux-src=3.16.0 ABI.

I think you mean API.  We don't ship out-of-tree drivers as binaries.

> Ben, could you please lend your insight into this point?
[...]

I don't know what the question is.  I have no involvement in
maintenance or testing of out-of-tree drivers, other than occasionally
checking whether they build against the current kernel version and
filing bugs on those that don't.

Ben.

-- 

Ben Hutchings
Life is what happens to you while you're busy making other plans.
   - John
Lennon


signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Nicholas D Steeves]

On 4 July 2016 at 09:12, Cyril Brulebois  wrote:
> Hi,
>
> Steve McIntyre  (2016-07-04):
>> There's something I've been pondering for a while, along with some
>> other folks - it might be useful to do a "jessie and a half" release,
>> similarly to what we did in the etch days. That's *basically* just
>> like a normal jessie release, but with a few key updates:
>>
>>  * backports kernel
>
> That's a given.

I still wonder if a fork of the last linux:src=4.4, updated to bring
it to linux-4.4.14 would be a lower support burden?  I'm still finding
that there are a fair number of issues reported with 4.5.x and 4.6.x
on various mailing lists.  Does anyone know how Skylake support is
like for the 4.4.x branch?  What is arm64 support like?  I've
corresponded with Ben Hutchings, and he tells me an LTS kernel effort
is ok to do, but unofficial.  Personally, I believe following bpo
kernel is a bit of a rodeo in comparison to what one expects from
Debian Stable, which is why I'm looking into this project.  I would
very much prefer to do it as a team, because I do not believe that I
am qualified to maintain kernel packages.

Philipp, what do you think?

>>  * rebuilt d-i to match that kernel
>
> You know there are patches around for that.
>
>>  * X drivers
>
> I don't see backports for them.

libdrm2: 2.4.68-1~bpo8+1
libgl1-mesa-.*: 11.1.3-1~bpo8+1
xserver-xorg-video-intel:2:2.99.917+git20160522-1~bpo8+1

I backported the libva stuff and required dependencies yesterday.
Some time ago, there was also a user who requested a
xserver-xorg-video-savage bpo on IRC.  I made a quick one, sent him
the link, but he never filed a bug report and I forgot to officially
upload it.

In private email correspondence with Andreas Boll, with respect to
backported X drivers and mesa, it came to light that

On 21 March 2016 at 14:49, Andreas Boll  wrote:
>
> Actually radeonsi requires LLVM >= 3.6 but since we currently use Mesa
> with LLVM 3.7 in unstable and testing it would make sense to backport
> LLVM 3.7.

So for radeon hardware enablement, there is 1) the proprietary driver
2) a need to backport llvm.

>>  * ... (other things that might be needed for consistency)

Maybe pinning a list of drivers that a user would expect would come
from backports instead of main?  eg: presumably a user would expect
that this Jessie+hardware enablement bpos would choose the latest
broadcom-sta-dkms in backports.  I could be wrong here, and I
recognise that backports are officially opt-in only, but if we're
already opting the user into a bpo X-stack, wouldn't he/she also
assume that installing some-non-free-dkms-driver will also pull in the
bpo version?  Also, I imagine this might one day be necessary,
particularly if tracking backported linux-src due to ABI changes
between kernels, eg: if the out-of-tree drivers in testing begin to
require >> linux-src=3.16.0 ABI.

Ben, could you please lend your insight into this point?

>> all rolled up with a small installer image build (netinst, maybe
>> DVD#1).
>
> That'd probably make it easy to decide how to resolve open questions
> with my "d-i vs. backported kernel" patches.
>
>> A lot of arm64 machine users would benefit from this, and maybe owners
>> of very recent amd64 machines too, with better support for things on
>> the Skylake platform. Those are the only two architectures I'm
>> thinking of supporting at this point.
>>
>> Is anybody else interested in helping? Thoughts/comments?

Yes, it's a project I'm already working on ;-)  Is this project a
candidate for a new Debian Team?

> Questions:
>  1. Is it going to pick pieces from backports only? (See X question
> above.)

Please see Philipp and my concern wrt rolling kernel updates.

>  2. Does it have to be called "jessie and a half"? (How much is the
> concept understood across users? Wouldn't it be a better idea to
> squeeze the "backports" concept into the name somehow?)

Maybe something like jessie-fresh-unofficial?

>  3. What about security support once the system is installed? (Which
> can be answered along with 1., I suppose.)

Given the current status of backports, security support would be
"Unfortunately not" ( https://backports.debian.org/FAQ/ ).  This is
one point in support of a team that would monitor a subset/list of
supported/shipped/blessed backports for security issues.

Sorry this is so long, I'm excited to see that there are other people
interested in this project!

On 4 July 2016 at 13:13, Hideki Yamane  wrote:
>
>  Just a comment. I don't have any objection for this proposal.
>
>  However, not only half but also updates with some point is better
>  to deliver value for users, I hope it'll be in Stretch cycle.
>
>  Recently I've read "lean software development" and it's quite
>  impressive for me. "deliver value to users" is one of the most
>  important thing in Debian (it means "do continuous improvement
>  for stable"), IMO.

Agreed!  Also, OpenSUSE has been doing this with their post-42.x
release model.  Mind you

Re: Thinking about a "jessie and a half" release

[Hideki Yamane]

Hi,

On Mon, 4 Jul 2016 14:01:03 +0100
Steve McIntyre  wrote:
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,

 Just a comment. I don't have any objection for this proposal.
 
 However, not only half but also updates with some point is better
 to deliver value for users, I hope it'll be in Stretch cycle.

 Recently I've read "lean software development" and it's quite
 impressive for me. "deliver value to users" is one of the most
 important thing in Debian (it means "do continuous improvement
 for stable"), IMO.


-- 
Hideki Yamane 

Re: Thinking about a "jessie and a half" release

[Ben Hutchings]

On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote:
> Hey folks,
> 
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days.

As I recall, that added extra packages to the etch suite, whereas it
seems like this would take updated packages the jessie-backports suite.

> That's *basically* just like a normal jessie release, but with a few
> key updates:
> 
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)

For the kernel: firmware-nonfree, kernel-wedge, linux-base, linux-
latest, linux-signed, sbsigntool.  All of those are already in jessie-
backports, except the last two which will be needed starting with 4.7.

For user-space graphics: libdrm and mesa, presumably.

> all rolled up with a small installer image build (netinst, maybe DVD#1).
> 
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
> 
> Is anybody else interested in helping? Thoughts/comments?

When do you anticipate this would be releasable?  Would it really be
long enough before stretch, to be worthwhile?

Ben.

-- 

Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing
anyway.


signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Cyril Brulebois]

(Please keep me cc'd.)

Philipp Kern  (2016-07-04):
> On 2016-07-04 15:12, Cyril Brulebois wrote:
> >Steve McIntyre  (2016-07-04):
> >>There's something I've been pondering for a while, along with some
> >>other folks - it might be useful to do a "jessie and a half" release,
> >>similarly to what we did in the etch days. That's *basically* just
> >>like a normal jessie release, but with a few key updates:
> >>
> >> * backports kernel
> >
> >That's a given.
> 
> Does that mean "kernel from backports"?

Yes.

> How would we keep that working given that backports keeps changing?

Backports changing isn't an issue AFAICT if we're only publishing a
netinst image which has all the kernel bits (kernel udebs), as opposed
to netboot.

Or are you thinking of other issues?

> Would we copy the kernel at the time into a special suite?

I don't think that's needed.

> How would updates work?

Updates to?
 - d-i: nothing has to change (except if we want to republish a new
   image with an ever newer kernel version), see above.
 - installed system: as usual for systems with backported packages
   (NotAutomatic & ButAutomaticUpgrades).

> That is to mean: I can see how this would work as a sort of
> continuously built thing whenever the kernel in backports changes and
> the supporting d-i changes are committed. But in the terms of a
> release seems to be a little hard.
> 
> >> * rebuilt d-i to match that kernel
> >
> >You know there are patches around for that.
> >
> >> * X drivers
> >
> >I don't see backports for them.
> 
> Would it also mean X proper or "just" drivers?

Last I did backports for X, backports ftpmasters insisted on not getting
just the drivers. So I ended up backporting the whole X stack. I'm not
sure what happens in the X world these days (is backporting just drivers
feasible and/or desirable), or whether backports ftpmasters would decide
otherwise now. (Note: that was 5 years ago.)


KiBi.


signature.asc
Description: Digital signature

Re: Thinking about a "jessie and a half" release

[Jose R R]

On Mon, Jul 4, 2016 at 6:01 AM, Steve McIntyre  wrote:
> Hey folks,
>
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
>
>  * backports kernel
I built Reiser4-patched (SFRN 4.0.1) Linux kernel 4.6.2-2 from Debian
source (i.e, 'backport') for Jessie on AMD64.

>  * rebuilt d-i to match that kernel
Did - but upon d-i test installation of Debian Desktop Environment, I
found out it(seems *all* GUIs selected in d-i) has a 'nasty'
dependency on xserver-xorg-input-vmmouse for VMware. Those of us not
on proprietary stuff can purge xserver-xorg-input-vmmouse; however,
action will also remove a couple of task*-related packages. Adding the
Stretch repositories and subsequently installing
xserver-xorg-input-vmmouse, it will bring about plenty of X upgrades.

So *yes*:
>  * X drivers
>  * ... (other things that might be needed for consistency)
>
> all rolled up with a small installer image build (netinst, maybe DVD#1).
>
> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
>
> Is anybody else interested in helping? Thoughts/comments?
>
> --


Best Professional Regards.

-- 
Jose R R
http://metztli.it
-
Try at no charge http://b2evolution.net for http://OpenShift.com PaaS
-
from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way!
-

Re: Thinking about a "jessie and a half" release

[Philipp Kern]

On 2016-07-04 15:12, Cyril Brulebois wrote:

Steve McIntyre  (2016-07-04):

There's something I've been pondering for a while, along with some
other folks - it might be useful to do a "jessie and a half" release,
similarly to what we did in the etch days. That's *basically* just
like a normal jessie release, but with a few key updates:

 * backports kernel


That's a given.


Does that mean "kernel from backports"? How would we keep that working 
given that backports keeps changing? Would we copy the kernel at the 
time into a special suite? How would updates work?


That is to mean: I can see how this would work as a sort of continuously 
built thing whenever the kernel in backports changes and the supporting 
d-i changes are committed. But in the terms of a release seems to be a 
little hard.



 * rebuilt d-i to match that kernel


You know there are patches around for that.


 * X drivers


I don't see backports for them.


Would it also mean X proper or "just" drivers?

Kind regards
Philipp Kern

Re: Thinking about a "jessie and a half" release

[Cyril Brulebois]

Hi,

Steve McIntyre  (2016-07-04):
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
> 
>  * backports kernel

That's a given.

>  * rebuilt d-i to match that kernel

You know there are patches around for that.

>  * X drivers

I don't see backports for them.

>  * ... (other things that might be needed for consistency)
> 
> all rolled up with a small installer image build (netinst, maybe
> DVD#1).

That'd probably make it easy to decide how to resolve open questions
with my "d-i vs. backported kernel" patches.

> A lot of arm64 machine users would benefit from this, and maybe owners
> of very recent amd64 machines too, with better support for things on
> the Skylake platform. Those are the only two architectures I'm
> thinking of supporting at this point.
> 
> Is anybody else interested in helping? Thoughts/comments?

Questions:
 1. Is it going to pick pieces from backports only? (See X question
above.)
 2. Does it have to be called "jessie and a half"? (How much is the
concept understood across users? Wouldn't it be a better idea to
squeeze the "backports" concept into the name somehow?)
 3. What about security support once the system is installed? (Which
can be answered along with 1., I suppose.)


KiBi.


signature.asc
Description: Digital signature

Thinking about a "jessie and a half" release

[Steve McIntyre]

Hey folks,

There's something I've been pondering for a while, along with some
other folks - it might be useful to do a "jessie and a half" release,
similarly to what we did in the etch days. That's *basically* just
like a normal jessie release, but with a few key updates:

 * backports kernel
 * rebuilt d-i to match that kernel
 * X drivers
 * ... (other things that might be needed for consistency)

all rolled up with a small installer image build (netinst, maybe DVD#1).

A lot of arm64 machine users would benefit from this, and maybe owners
of very recent amd64 machines too, with better support for things on
the Skylake platform. Those are the only two architectures I'm
thinking of supporting at this point.

Is anybody else interested in helping? Thoughts/comments?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.