Re: Scheduling 9.1, maybe 8.9

[Joerg Jaspert]

On 14714 March 1977, Jonathan Wiltshire wrote:

> A month or so from 9.0 bring us to about 15th July. How would any of these
> suit? Is 8.9 at the same time feasible?
> 8/9 July (probably a bit soon)
> 15/16 July

Both of them don't work for me.

> 22/23 July

That I could do.

-- 
bye, Joerg

Bug#866183: debian-live: loopback.cfg is not working

[JimmyZ]

Package: debian-live
Version: 9.0.1
Severity: normal

It's really glad to see debian-live supports loopback.cfg now, however, two
minor issues prevented it from working:

# /boot/grub/loopback.cfg:
source /grub/grub.cfg
# should be /boot/grub/grub.cfg

# boot/grub/grub.cfg, line 22~24:
if [ ${iso_path} ] ; then
set loopback="findiso=${iso_path}"
# needs `export loopback` here
fi

And all d-i entries won't work since d-i only supports findiso= in the
hdmedia flavor, d-i in cd/dvd doesn't support it.

Thanks for your time.

Debian package live-wrapper

[Charles Chambers]

To my understanding the Live ISO performs two functions:

1)  Live operation from [USB] media without installation onto a hard drive.

2)  Installation of Debian onto a hard drive entirely from that media if
all looks fine in a Live session.

Is my understanding correct?

Is the installation considered a function of the live-wrapper package?

-- 
Charlie
ccha...@gmail.com

Re: IMPORTANT: Do live Debian images have a future?

[Michael .]

Charles, let me clear up a couple of misconceptions for you. Debian Live
(made with Live Wrapper) is an official Debian project. Live Build (the old
Debian Live) apparently wasn't official but was recognised by Debian for
its official images. Live Build is now officially part of Debian and Rafael
Hertzog is the new developer maintainer of Live Build. As for reporting
bugs because Debian Live (that uses Live Wrapper) is an official Debian
project bugs should be reported through the bug tracker. That is the way it
has been since Live Wrapper was first released. However people still do,
and I have done it also, report issues with Live Wrapper in the Live
mailing list. Hope that helps.

On 27 June 2017 at 21:54, Charles Chambers  wrote:

> 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! 
>
> Charlie
>
>
>
> On Jun 26, 2017 12:55 PM, "Michael ."  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  wrote:
>>
>>> [ Note the cross-posting... ]
>>>
>>> Hey folks,
>>>
>>> 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 [1], 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
>>> enough.
>>>
>>> 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
>>> 

Processed: Re: Bug#865065: cups: Print Service Not Available -- debian-live-9.0.0-amd64-gnome

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 865065 - moreinfo
Bug #865065 [cups] cups: Print Service Not Available -- 
debian-live-9.0.0-amd64-gnome
Removed tag(s) moreinfo.
> reassign 865065 live-build
Bug #865065 [cups] cups: Print Service Not Available -- 
debian-live-9.0.0-amd64-gnome
Bug reassigned from package 'cups' to 'live-build'.
No longer marked as found in versions cups/1.7.5-11+deb8u1.
Ignoring request to alter fixed versions of bug #865065 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
865065: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865065
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: IMPORTANT: Do live Debian images have a future?

[Charles Chambers]

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! 

Charlie



On Jun 26, 2017 12:55 PM, "Michael ."  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  wrote:
>
>> [ Note the cross-posting... ]
>>
>> Hey folks,
>>
>> 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 [1], 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
>> enough.
>>
>> 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.
>>
>> [1] https://get.debian.org/images/release/current-live/amd64/iso
>> -hybrid/#issues
>>
>> --
>> Steve McIntyre, Cambridge, UK.
>> st...@einval.com
>> "...In the UNIX world, people tend to interpret `non-technical user'
>>  as meaning someone who's only ever written one device driver." -- Daniel
>> Pead
>>
>
>

Re: GParted doesn't see Debian Live partition?

[Andreas Heinlein]

Hello,

debian live images have to solve two problems:
1. a single image that must work both when written to DVD and when 
written to USB drive

2. a single image that must boot both EFI and BIOS machines

The combination of this results in 4 different ways of booting which 
need to be combined into a single image:
1. BIOS booting from DVD requires a boot sector within the ISO 
filesystem, which is ignored when the image is written to USB drive
2. BIOS booting from USB requires an MBR partition table with a 
partition marked as active, where the first sector is loaded from and 
executed
3. EFI booting from DVD requires a file EFI\BOOT\BOOTx64.efi within the 
ISO filesystem, which is loaded and executed
4. EFI booting from USB requires a GPT partition table with a partition 
of type 'ef' and a FAT filesystem, which in turn needs to contain a file 
EFI\BOOT\BOOTx64.efi


So the resulting image has two problems:
- In order to achieve 2.) and 4.), we have two partition tables which 
violates the standard - GPT standard requires that a "protective MBR" is 
present, with a single partition enclosing the entire space, in order to 
prevent MBR-only tools from treating the drive as empty.
- In order to achieve 1.) and 3.), the EFI folder is included in the ISO 
filesystem in the first partition, and the same folder is "mapped" once 
again in a FAT filesystem within the second partition. If you take a 
closer look at the cfdisk output, you can see that the first partition 
starts at 0 and ends at 3793663, while the second starts at 2136 and 
ends at 2967. So the second partition actually resides within the first, 
exposing the same EFI folder that is contained in the first partition. 
In terms of standards, this is clearly invalid, but BIOSes ignore this 
and boot just fine using this method.


The latter is the reason why cfdisk chokes on this layout; it only looks 
at the end of the last partition, which is 2967 in this case, and 
calculates the start of the free space to be at the next cylinder/MiB 
boundary from there.


Sfdisk should be able to deal with this, it's the tool that works with 
most of the "strange" disk layouts including disordered partitions etc.


The latter problem could be avoided by creating the image differently, 
it is also possible to just append the EFI partition at the end of the 
first and copy the EFI folder there. This means the same data is 
included twice, and care needs to be taken that both are actually 
identical, but it prevents problems like yours. But there is no way to 
prevent having both MBR and GPT in the image, even though *most* EFI 
implementations also boot from MBR.


Hope I could clarify a bit,
Andreas

Am 24.06.2017 um 19:52 schrieb Markus Laire:
Thanks, but it seems that cfdisk doesn't understand this partition 
structure properly either:


Device  Boot   StartEndSectorsSize Id Type
/dev/sdd1   *  0379366337936641.8G  0 Empty
/dev/sdd2   2136   2967832416K ef EFI 
(FAT-12/16/32)

>>  Free space  4096  246480895  246476800 117.5G

If /dev/sdd1 is 3793664 sectors then there is no way that free space 
starts at sector 4096. And if I try to create new partition there, 
cfdisk doesn't allow that and gives error "Start sector 4096 out of 
range."


On Sat, Jun 24, 2017 at 7:44 PM, Tom & Karen Pino 
> wrote:


You have a 'Hidden HPFF/NTFS' partition for your main partition.

Gparted is a fine partition tool for general work but don't use it
for this sort of job.

Use cfdisk instead.
# cfdisk /dev/sdd

On 06/24/2017 09:08 AM, Markus Laire wrote:

I just put debian-live-9.0.1-amd64-xfce.iso to 128 GB USB-stick and
then tried to check the created partitions on a computer running
Debian Strech.

When I check partitions with "cat /proc/partitions" I get:
8   48  123240448 sdd
8   491896832 sdd1
8   50416 sdd2

So there is one main partition and one tiny one.

But if I start GParted to modify partitions, it doesn't see main
partition at all, only the tiny one. GParted claims that USB-stick
has:
- 1.04 MiB unallocated space
- 416 KiB fat16 partition
- 117.53 GiB unallocated space

Why GParted doesn't see the main partition? I want to create another
partition for persistence, but I'm afraid GParted will destroy main
partition (which it doesn't see) if I try to do any changes.

-- 


--
Markus Laire https://www.MarkusLaire.com

Re: IMPORTANT: Do live Debian images have a future?

[shirish शिरीष]

at bottom :-

On 26/06/2017, Steve McIntyre  wrote:
> [ Note the cross-posting... ]
>
> Hey folks,
>
> 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 [1], 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
> enough.
>
> 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.
>
> [1]
> https://get.debian.org/images/release/current-live/amd64/iso-hybrid/#issues
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "...In the UNIX world, people tend to interpret `non-technical user'
>  as meaning someone who's only ever written one device driver." -- Daniel
> Pead
>

One of the things at least to my mind is we (the users) do not know
which is most closest testing release  near to the final release. For
e.g.  take the last/latest announcement done by Cyril Brulebois on
13th June talking about the Stretch RC5 release. In the whole
announcement, there is not even a hint to potential testers that this
might be the closest to the final released (gold) image. I am
presuming/assuming that Cyril was also talking about the live image
and not the just the installer improvements.

What would be nicer/better perhaps if debian-live does announcements
on d-d-a  and more importantly hint as when it's going to be nearer to
release (final image).

We are going to have a release party this week-end in Pune (haven't
posted the details yet at https://wiki.debian.org/ReleasePartyStretch
, hoping the organizers will do the needful otherwise will do it in a
day or two.

I/we could also have testing parties before the release as well with a
two-week window to the final image . This also gives times to students
to see how things work in the real world as well.

I can't volunteer for any activities atm (due to health issues) except
for taking part in organising testing party in Pune before release and
getting more people to file bugs in case they hit problems.

I am hopeful we can find a better way/solution to the above.


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Re: IMPORTANT: Do live Debian images have a future?

[Narcis Garcia]

A Live Debian-Hurd would be cool too.
These days has been a doubt in debian-hurd list, and some proposed
solutions were to boot from other media to perform fsck + grub-install
to repair a boot. This action needs live media.



__
I'm using this express-made address because personal addresses aren't
masked enough at this list's archives. Mailing lists service
administrator should fix this.
El 26/06/17 a les 23:09, Rick Thomas ha escrit:
> I'm a user and a tester, not a dev, and I know nothing (and don't want
> to know anything)
> about the personal politics between Debian developers.  So that's all
> I'll say on that subject.
> 
> To Steve's original point:
> 
> First, a big THANK YOU! to Steve for taking this job on.  I, for one, an
> grateful.
> 
> I use Debian a lot, but I'm only an occasional user of the Debian Live
> images.
>  But when I need them, I need them. And when I need them, I want them to
> just work.
> If having them there and working when I need them means I have to add
> them to my
> list of things to test and report on, I'm willing to make that investment.
> 
> Please add me to your "testers" list.
> 
> Thank you,
> Rick
> 
> 
> PS: On a related topic:  What I think would be really cool, would be
> Debian Live images
> for some of the ARM architectures.  Something I could dd to a USB stick
> and boot
> right away when I get a new box in for testing.  Even cooler would be
> the ability
> to use that self-same live image to install Debian after the testing
> phase was over.
> 
> 
> 
> On 27 June 2017 at 00:08, Steve McIntyre  > wrote:
> 
> [ Note the cross-posting... ]
> 
> 
> 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.
> 
> [1]
> 
> https://get.debian.org/images/release/current-live/amd64/iso-hybrid/#issues
> 
> 
> 
> --
> Steve McIntyre, Cambridge, UK.   
> st...@einval.com 
> "...In the UNIX world, people tend to interpret `non-technical user'
>  as meaning someone who's only ever written one device driver."
> -- Daniel Pead
> 
> 
>