And I'll add my 2¢ as an end user.The live images exist IMHO to test compatibility before committing to installation, and to install what was just tested and demonstrated, regardless of environment. It's a nice feature (arguably an essential feature) that the actual install mirror *exactly* the tested compatibility and appearance. To go with this, it *was* nice to be able to install in the absence of a network connection or Internet service.The Live environment still works fine for testing for compatibility, especially when the Nonfree repository is included. Installation, no longer.My 2¢ is that installation suffers from a lack of testing, probably because Debian Live is a "unofficial" branch off the development tree. It's made worse because bugs for Live have no clear reporting process. Where DOES one report a problem - to this mailing list, or the mailing list more obviously suited (think a bug found while installing...report here, or report to debian-install, or to debian-boot)?Inquiring minds want to know! <g>CharlieOn Jun 26, 2017 12:55 PM, "Michael ." <firstname.lastname@example.org> wrote:I'm not a dev but I am a user and I do test so I'll add my bit here.Let's be frank Live Wrapper only exists because of animosity within Debian towards the originator of Live Build (and to be honest his own lack of concern for what Debian required of Live Build). Live Wrapper was rushed and was never going to be ready for Stretch and in hindsight it was a little foolish to think it would be ready to build the types of images Debian required. Live Build wasn't up to scratch but the UEFI support issue has been fixed so what other issues are there with Live Build that makes it unreasonable to use?On 27 June 2017 at 00:08, Steve McIntyre <email@example.com> wrote:[ Note the cross-posting... ]
Background: we released live images for Stretch using new tooling,
namely live-wrapper. It is better than what we had before (live-build)
in a number of ways, particularly in terms of build reliability and
some important new features (e.g. UEFI support). But it's also less
mature and has seen less testing. There have been bugs because of
that. I have fixes for most of the ones I know about , and I'm
still working on more bugfixes yet.
While the bugs are annoying, what worries me more is that they were
only spotted in release builds. There had been testing versions of
live images available for multiple weeks beforehand, presumably with
the same bugs included. (Almost) none of them reported. This shows
that we don't have enough people using these live images and/or caring
about filing bugs.
We have a similar lack of involvement in terms of the content of the
live images. As I said above, I'm happy that we now have a reliable
tool for building our live images - that makes my life much
easier. But I honestly have no idea if the multiple desktop-specific
live images are actually reasonable representations of each of the
desktops. For example, I *seriously* hope that normal KDE
installations are not effected by #865382 like our live KDE
images. Validation by the various desktop teams would be useful here.
The current situation is *not* good enough. I ended up getting
involved in live image production because the images needed making,
and I was already the main person organising production of Debian's
official images. To be frank, I had (and still have) no direct use for
the live images myself and I don't *particularly* care about them all
that much. Despite that, I've ended up spending a lot of time working
on them. A few other people have also spent a lot of time working in
this area - thanks are due to those people too. But it's still not
If our live images are going to be good enough to meet the standards
that Debian users deserve and expect, we need *consistent*,
*sustained* involvement from a lot more people. Please tell me if
you're going to help. If we don't see a radical improvement soon, I'll
simply disable building live images altogether to remove the false
promises they're making.
Steve McIntyre, Cambridge, UK. firstname.lastname@example.org
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead