Bug#959175: [checkbashisms] false "source" detection

[jnqnfe]

Package: devscripts
Version: 2.20.3

I just encountered a misidentification of a bashism where "source" was
used in a sed replacement that modifies a grub config file.

Link to auto test that failed:

https://salsa.debian.org/jnqnfe/live-build/-/jobs/706904

This is the code where it failed:
```
possible bashism in scripts/build/binary_loopback_cfg line 284 (should
be '.', not 'source'):
sed -i \
-e "s|@LINUX_LIVE@|$(escape_for_sed "${LINUX_LIVE}")|" \
-e "s|@KERNEL_GI@|${KERNEL_GI}|" \
-e "s|@INITRD_GI@|${INITRD_GI}|" \
-e "s|@APPEND_GI@|${APPEND_GI}|" \
-e "s|@KERNEL_DI@|${KERNEL_DI}|" \
-e "s|@INITRD_DI@|${INITRD_DI}|" \
-e "s|@APPEND_DI@|${APPEND_DI}|" \
-e "s|@KERNEL_LIVE@|${KERNEL_LIVE}|" \
-e "s|@INITRD_LIVE@|${INITRD_LIVE}|" \
-e "s|@APPEND_LIVE@|${APPEND_LIVE}|" \
 -e "s|@LB_BOOTAPPEND_INSTALL@|${LB_BOOTAPPEND_INSTALL}|" \
-e "s|@LB_BOOTAPPEND_LIVE_FAILSAFE@|${LB_BOOTAPPEND_LIVE_FAILSAFE}|
" \
-e "s|@LB_BOOTAPPEND_LIVE@|${LB_BOOTAPPEND_LIVE}|" \
-e "s|@APPEND_INSTALL@|${LB_BOOTAPPEND_INSTALL}|" \
-e "s|@ENABLE_INSTALL_MENU@|${ENABLE_INSTALL_MENU}|" \
-e "s|@ENABLE_MEMTEST@|${ENABLE_MEMTEST}|" \
-e "s|@MEMTEST_BIN@|${MEMTEST_BIN}|" \
-e "s|@MEMTEST_VERSION@|${LB_MEMTEST}|" \
-e "s|LINUX_LIVE|$(escape_for_sed "${LINUX_LIVE}")|" \
-e "s|LINUX_INSTALL|source /boot/grub/install_start.cfg|" \
-e "s|LINUX_ADVANCED_INSTALL|source /boot/grub/install.cfg|" \
-e "s|MEMTEST|${MEMTEST}|" \
-e "s|KERNEL_GI|${KERNEL_GI}|" \
-e "s|INITRD_GI|${INITRD_GI}|" \
-e "s|APPEND_GI|${APPEND_GI}|" \
-e "s|KERNEL_DI|${KERNEL_DI}|" \
-e "s|INITRD_DI|${INITRD_DI}|" \
-e "s|APPEND_DI|${APPEND_DI}|" \
-e "s|KERNEL_LIVE|${KERNEL_LIVE}|" \
-e "s|INITRD_LIVE|${INITRD_LIVE}|" \
-e "s|APPEND_LIVE|${APPEND_LIVE}|" \
-e "s|LB_BOOTAPPEND_INSTALL|${LB_BOOTAPPEND_INSTALL}|" \
-e "s|LB_BOOTAPPEND_LIVE_FAILSAFE|${LB_BOOTAPPEND_LIVE_FAILSAFE}|"
\
-e "s|LB_BOOTAPPEND_LIVE|${LB_BOOTAPPEND_LIVE}|" \
"${_TARGET}"/*.cfg
```

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Response embedded below. Just a quick note first - it was a little hard
to read the response you wrote because the embedded responses were
directly adjacent to the quoted text, with no spacing between (my email
client does not automatically add spacing and shows both quote and text
in similar colours unfortunately); it'd be helpful to add some spacing
please next time. :)

On Thu, 2020-04-16 at 01:15 +0200, adrian15sgd wrote:
> El 8/4/20 a las 16:56, jnq...@gmail.com escribió:
> > To fix the issue of broken EFI booting when syslinux is not used
> > (and
> > thus binary_syslinux was not put in place /live/vmlinuz), I was
> > intending to solve by moving creation of short filename kernel
> > files
> > out of binary_syslinux into somewhere common.
> > 
> > The first problem with this though is that alone of course it is
> > not
> > enough because it does not cover the `/live/vmlinuz1` multi-flavour
> > case, so a change to binaru_grub-efi would also be needed in order
> > to
> > dynamically change the searched for file to /live/vmlinuz1 where
> > appropriate.
> 
> You should also know that current isolinux/syslinux supports booting 
> from long filenames. So we could ditch using short 8.3 names for the 
> kernels.

Ok, noted, though I don't know that I'll bother the team with
submitting that change for now at least.

> This problem about having to update binary_grub-efi for searching
> for 
> long names would arise anyways.

Except when switching to a solution not involving the kernel filename,
as is the case now with the `/.disk/info` based search now
merged.

> > However, I now understand from reading #924053 that although this
> > would
> > fix things in all/most cases, it's at risk of breaking for odd
> > situations like your HP laptop case. Using /.disc/info as the
> > searched
> > for file as proposed in #924053 is much a better solution.
> It collides with Ubuntu live usbs which also have /.disc/info but it 
> would be a quick and easy fix for the current situation where HP
> laptop 
> are involved.

Exactly.

> > My current intention is to take the patch of yours provided in
> > #924053
> > that makes this change, though with a tweaked commit message (I
> > think
> > the problem is EFI specific not Secure Boot specific), and submit
> > it in
> > an MR, along with the fix for grub-pc, and some additional loosely
> > related work, in one or more MRs.
> The Secure Boot code works from an EFI sort-of-ramdisk so it needs
> to 
> find its own root somehow. That's why it was Secure Boot specific.

Ok. I can't say that I currently follow. It's been a long time since I
last researched bootloader specifics, and I don't think there even was
Linux secure boot support back then. I was a little confused (1) by the
comments in the binary_grub-efi script as to which bits were
generically EFI and which bits secure boot, considering you saying the
bit concerning the root search is secure boot specific, and (2) from
the fact that the search bit seems involved in loading an image in an
EFI virtualbox VM, which I don't think emulates secure boot. But
anyway, I think you know more about this than I currently...

> > While the concept of correctly identifying discs (aka liveid type
> > stuff) is interesting and of some potential value, priority should
> > be
> > given to simply fixing the ability to create working images first
> > and
> > foremost.
> > 
> > I will have the patches mark this bug and #924053 as closed, and
> > leave
> > you to create a new wishlist bug to propose or re-start discussion
> > of
> > the unique-disc identification stuff as you wish.
> 
> I don't think your solution is optimal (because you are postponing
> the 
> actual fact that every live cd cannot detect itself).
> 
> Liveid let's you find the correct live cd.

As things stand with the currently released version of live-build, we
have the following problems:

 1. If using `--bootloaders grub-pc` you get an unbootable image.
 2. If using `--bootloaders grub-pc,grub-efi` you get an unbootable
image in both BIOS and EFI (I'm not certain grub-efi can be used on its
own, I've not tried, but presumably it would fail just the same).
 3. If using `--bootloaders syslinux,grub-efi` with multiple kernel
versions such that you end up with `vmlinuz1`, you get an unbootable
image for EFI.
 4. You've got the problem with the HP system.
 5. You've got the problem liveid focusses on of correctly loading the
right image in a situation where there are multiple (multiple
CDs/DVS/pendrives; a pendrive containing multiple images like with
rEFInd).

Solving them:
 - The first four are easily solvable with just two tiny tweaks (the `-
-prefix=boot` grub-pc fix and the `/.disk/info` based search fix, both
of which have now been merged.
 - Fixing the last requires a much bigger and more complex solution,
with lots of decisions to make on how to proceed, issues with whether
or not the team will like the proposed solution, etc.

The difficulties with getting a final 

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Apologies once again for the time it's taking to get back to you, so
much to do. I'll try to get focussed on responding to all of your
messages now/next...

The fix for this bug report has been merged now since your response.

The piece of code modified to add `--prefix=/boot/grub` lived within a
condition of `"${LB_FIRST_BOOTLOADER}" = "grub-pc"`, so does not apply
to the default situation of using syslinux at least...

Furthermore the code concerns generation of a 'grub_eltorito' file,
which is then later used in a xorriso only when grub-pc is selected for
use.

So it seems to me that this only affects grub-pc...

It's been quite some time since I last researched the details of ISOs
and bootloaders and such. So I cannot say with complete confidence that
you're mistaken in being concerned about this breaking secure boot.
Especially since testing is tricky since I don't think my VM emulates
it, so would be a pain to double check, considering how busy I am.

If you're still concerned, would you happen to please have a little
spare time to double check?

Thanks,
Lyndon.


On Thu, 2020-04-16 at 01:03 +0200, adrian15sgd wrote:
> I suspect this would break Secure Boot support but it's only a guess.
> 
> El 8/4/20 a las 2:23, jnq...@gmail.com escribió:
> > update: I've just tried adding --prefix=/boot/grub to the grub-
> > mkimage
> > command in binary_iso (which should really be done in binary_grub-
> > pc)
> > that generates the core_img file that becomes part of
> > grub_eltorito,
> > and success!
> > 
> > So now that I know how fundamentally to fix the problems, I'll
> > follow
> > up soon with patches.
> > 

Bug#959006: [live-manual] translation/contributing documentation inadequacies

[jnqnfe]

Package: live-manual
Version: 2:20151217.1

In moving (in live-manual MR #27) the contributing notes out of the
manual itself to files under `doc/` in the repo, I see problems with
the translation/contributing documentation that could do with
addressing. Preferably after MR #27 has merged.

I'd submit an MR myself, and may do later, but now's not the best
moment to do any such rewriting for me (more important stuff to
address) and I'd have to research the translation tool usage details.

Including:

 - The set of files referenced for starting a new translation seem to
be outdated and in need of replacement with reference to all *.pot
files.
 - The instructions should be reclarified to instruct making a copy of
the *.pot files as *.po files within manual/po/XX/ where XX is a
suitable language reference, and then translate those files.
 - The *.pot files can commonly be out of date, making it a good idea
for translators to start by regenerating them to ensure they are
working from up-to-date strings. There are no instructions about this.
It may be also be helpful to give a hint as to whether or not a commit
updating the *.pot files is welcome.
 - Similarly there could be stray *.pot files (or stray translation
*.po files) left over from removed English files, so a good idea to
hint that they compare to the set of English *.po files to ensure they
do not unintentionally waste time.
 - The `doc/contributing.md` content should perhaps note to readers
that they should checkout `doc/authoring` for SiSU markup hints (until
such time that we possibly move to a more common markup if we do).
 - The new `doc/contributing.md` file (which is focussed on
contributing to the manual) should be adjusted to properly suit the
different users who might read it - those wanting to update the English
text vs. those interested in translating.

Bug#956553:

[jnqnfe]

apparently fixed in upstream master now, just needs packaging :)

Bug#956553: blurry notifications in gnome 3.36

[jnqnfe]

Control: forwarded -1 https://github.com/jnsh/arc-theme/issues/31

I did test and confirm not present in adwaita, just forgot to mention,
sorry.

Reported upstream.

On Sun, 2020-04-12 at 21:15 +0100, David Mohammed wrote:
> Please test with adwaita.
> 
> If notifications are still blurred with adwaita then its not a theme
> issue.
> 
> If notifications are blurred only with arc theme then please report
> this to the upstream issue tracker - 
> https://github.com/jnsh/arc-theme
> 
> On Sun, 12 Apr 2020 at 21:03,  wrote:
> > Package: arc-theme
> > Version: 20190917+git20200328-1
> > 
> > Notifications, such as new email received, are now blurry for me
> > after
> > the gnome 3.36 update.
> > 
> > Example attached.
> > 
> > I have a Hi-DPI screen.
> > 
> > Relevant (?) font config from tweak tool:
> >  - interface: cantarell regular 11
> >  - hinting: slight
> >  - antialiasing: subpixel
> >  - scaling factor: 1.00
> > 
> > Hi-DPI scaling factor is set to 2 somewhere. Ah, settings >
> > displays >
> > scale: 200%

Bug#955638: Please update cargo - it's holding up a firefox update, impacting security

[jnqnfe]

Control: severity -1 serious

On Sat, 4 Apr 2020 14:17:43 +0100 Ximin Luo 
wrote:
> Yes, I will update cargo immediately after I get rustc 1.42 into
Debian, which is currently blocked on NEW.

Hi Ximin,

It's been a couple days since rustc entered unstable, and no sign yet
of cargo.

Firefox v75 is currently held up waiting upon cargo being updated.
Firefox v75 was released five days ago (and been queued for unstable
for four), and as usual it comes with a bunch of very important
security fixes.

I'm sure you are probably working on this already, but _please_ make
addressing this your top priority. We're relying upon you. Not wanting
to be overly dramatic, but considering the importance of a secure web
browser, the security of many Sid users has been at stake these past
few days waiting upon your getting this done.

Regards,
Lyndon

Bug#956553: blurry notifications in gnome 3.36

[jnqnfe]

Package: arc-theme
Version: 20190917+git20200328-1

Notifications, such as new email received, are now blurry for me after
the gnome 3.36 update.

Example attached.

I have a Hi-DPI screen.

Relevant (?) font config from tweak tool:
 - interface: cantarell regular 11
 - hinting: slight
 - antialiasing: subpixel
 - scaling factor: 1.00

Hi-DPI scaling factor is set to 2 somewhere. Ah, settings > displays >
scale: 200%

Bug#857740: live-build: /etc/resolv.conf has unsafe permissions when copied from config/includes.chroot

[jnqnfe]

Patch submitted as MR #175
https://salsa.debian.org/live-team/live-build/-/merge_requests/175

On Fri, 10 Apr 2020 02:30:08 +0100 jnq...@gmail.com wrote:
> Confirmed, this is still a problem. I'll make a patch right now.

Bug#857740: live-build: /etc/resolv.conf has unsafe permissions when copied from config/includes.chroot

[jnqnfe]

Confirmed, this is still a problem. I'll make a patch right now.

On Tue, 14 Mar 2017 15:53:26 +0100 intrig...@debian.org wrote:
> Package: live-build
> Severity: normal
> Version: 1:20170213
> Tags: security
> User: tails-...@boum.org
> Usertags: misc-reported
> 
> Hi!
> 
> when the config/includes.chroot/etc/resolv.conf file exists in the
> source tree, it is copied into the rootfs with "cp -a". So for
> example, if I've cloned a lb config source tree using Git as my user,
> the resulting live system has a /etc/resolv.conf owned by 1000:1000,
> and thus writable by the default live user. Depending on the exact
> context in which the live system is used, the security impact can be
> non-existent or rather severe.
> 
> Disclaimer: I've only verified this behavior on Tails' patched
> live-build 2.x. Sorry! But the affected code looks very much the same
> on the current master branch.
> 
> Cheers,
> -- 
> intrigeri
> 
> 

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

partially answering my own question here, the binary_grub-efi script
rejects use for netboot images (as well as hdd coincidentally), so no
need to be concerned with compatibility there.

On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote:
> Oh, quick addition of something I forgot to put in the below message:
> 
> So in the discussion of #924053 it was suggested that the /.disc/info
> based solution would only work for ISO/ISO-hybrid images because this
> file was created by xorriso. I added a comment just now pointing out
> that in fact this file is created by the binary_disc script, which
> generates it for iso, iso-hybrid and hdd image types.
> 
> It does not create any such info for netboot and tar images types,
> though. I do not expect the tar image will be booted will it? and
> thus
> there's no concern there? I really do not know all that much about
> netboot, so I do not know whether or not there is a problem there.

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Oh, one more thing I mean to say, @adrian, can you please confirm that
this installation of a live-build (?) image in this HP system does not
in fact include the /.disk/ files. Moving to a /.disk/info/ based
detection is of course not going to improve things in that situation if
the file exists in it anyway. I'm sure you probably thought of this,
but I did not notice any explicit mention in your discussion in
#924053...

On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote:
> Oh, quick addition of something I forgot to put in the below message:
> 
> So in the discussion of #924053 it was suggested that the /.disc/info
> based solution would only work for ISO/ISO-hybrid images because this
> file was created by xorriso. I added a comment just now pointing out
> that in fact this file is created by the binary_disc script, which
> generates it for iso, iso-hybrid and hdd image types.
> 
> It does not create any such info for netboot and tar images types,
> though. I do not expect the tar image will be booted will it? and
> thus
> there's no concern there? I really do not know all that much about
> netboot, so I do not know whether or not there is a problem there.
> 
> On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote:
> > Hi,
> > 
> > Okay, so I've just take a cursory look at your liveid stuff which
> > also
> > led me to #924053 where you've already brought up the EFI failure
> > side
> > of things.
> > 
> > I'll limit my response here (this bug report discussion) to matters
> > relating to simply fixing the broken ability to get bootable
> > images;
> > discussion of a unique-disc identification solution can take place
> > separately.
> > 
> > To fix the issue of broken EFI booting when syslinux is not used
> > (and
> > thus binary_syslinux was not put in place /live/vmlinuz), I was
> > intending to solve by moving creation of short filename kernel
> > files
> > out of binary_syslinux into somewhere common.
> > 
> > The first problem with this though is that alone of course it is
> > not
> > enough because it does not cover the `/live/vmlinuz1` multi-flavour
> > case, so a change to binaru_grub-efi would also be needed in order
> > to
> > dynamically change the searched for file to /live/vmlinuz1 where
> > appropriate.
> > 
> > However, I now understand from reading #924053 that although this
> > would
> > fix things in all/most cases, it's at risk of breaking for odd
> > situations like your HP laptop case. Using /.disc/info as the
> > searched
> > for file as proposed in #924053 is much a better solution.
> > 
> > My current intention is to take the patch of yours provided in
> > #924053
> > that makes this change, though with a tweaked commit message (I
> > think
> > the problem is EFI specific not Secure Boot specific), and submit
> > it
> > in
> > an MR, along with the fix for grub-pc, and some additional loosely
> > related work, in one or more MRs.
> > 
> > While the concept of correctly identifying discs (aka liveid type
> > stuff) is interesting and of some potential value, priority should
> > be
> > given to simply fixing the ability to create working images first
> > and
> > foremost.
> > 
> > I will have the patches mark this bug and #924053 as closed, and
> > leave
> > you to create a new wishlist bug to propose or re-start discussion
> > of
> > the unique-disc identification stuff as you wish.
> > 
> > Regards,
> > Lyndon
> > 
> > On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote:
> > > I think what you need is liveid.
> > > 
> > > https://github.com/rescatux/liveid
> > > 
> > > Here you can find the technical details and commits:
> > > 
> > > https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md
> > > 
> > > That way you won't longer depend on arbitrary files such as
> > > vmlinuz.
> > > 
> > > 
> > > Feedback is welcome.
> > > 
> > > 
> > > P.S.: I was going to do proper merge requests in about 5 or 6
> > > months 
> > > later but here you are.
> > > 
> > > adrian15
> > > 
> > > 
> > > El 8/4/20 a las 1:02, jnq...@gmail.com escribió:
> > > > update:
> > > > 
> > > > 1) from my notes, in fact I'd gone back as far as v5.0
> > > > confirming
> > > > the
> > > > presence of the grub-pc failure.
> > > > 
> > > > 2) I've noticed the presence of the fixed path '/live/vmlinuz'
> > > > in
> > > > binary_grub-efi, and with a hack to have this replaced with the
> > > > long
> > > > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI
> > > > side
> > > > of
> > > > the
> > > > problem, so that explains how the EFI stuff ends up checking
> > > > that
> > > > fixed
> > > > /live/vmlinuz' path and presents an alternate opportunity for a
> > > > fix. It
> > > > seems the author of the EFI live-build functionality only
> > > > tested
> > > > it
> > > > with syslinux.
> > > > 

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Oh, quick addition of something I forgot to put in the below message:

So in the discussion of #924053 it was suggested that the /.disc/info
based solution would only work for ISO/ISO-hybrid images because this
file was created by xorriso. I added a comment just now pointing out
that in fact this file is created by the binary_disc script, which
generates it for iso, iso-hybrid and hdd image types.

It does not create any such info for netboot and tar images types,
though. I do not expect the tar image will be booted will it? and thus
there's no concern there? I really do not know all that much about
netboot, so I do not know whether or not there is a problem there.

On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote:
> Hi,
> 
> Okay, so I've just take a cursory look at your liveid stuff which
> also
> led me to #924053 where you've already brought up the EFI failure
> side
> of things.
> 
> I'll limit my response here (this bug report discussion) to matters
> relating to simply fixing the broken ability to get bootable images;
> discussion of a unique-disc identification solution can take place
> separately.
> 
> To fix the issue of broken EFI booting when syslinux is not used (and
> thus binary_syslinux was not put in place /live/vmlinuz), I was
> intending to solve by moving creation of short filename kernel files
> out of binary_syslinux into somewhere common.
> 
> The first problem with this though is that alone of course it is not
> enough because it does not cover the `/live/vmlinuz1` multi-flavour
> case, so a change to binaru_grub-efi would also be needed in order to
> dynamically change the searched for file to /live/vmlinuz1 where
> appropriate.
> 
> However, I now understand from reading #924053 that although this
> would
> fix things in all/most cases, it's at risk of breaking for odd
> situations like your HP laptop case. Using /.disc/info as the
> searched
> for file as proposed in #924053 is much a better solution.
> 
> My current intention is to take the patch of yours provided in
> #924053
> that makes this change, though with a tweaked commit message (I think
> the problem is EFI specific not Secure Boot specific), and submit it
> in
> an MR, along with the fix for grub-pc, and some additional loosely
> related work, in one or more MRs.
> 
> While the concept of correctly identifying discs (aka liveid type
> stuff) is interesting and of some potential value, priority should be
> given to simply fixing the ability to create working images first and
> foremost.
> 
> I will have the patches mark this bug and #924053 as closed, and
> leave
> you to create a new wishlist bug to propose or re-start discussion of
> the unique-disc identification stuff as you wish.
> 
> Regards,
> Lyndon
> 
> On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote:
> > I think what you need is liveid.
> > 
> > https://github.com/rescatux/liveid
> > 
> > Here you can find the technical details and commits:
> > 
> > https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md
> > 
> > That way you won't longer depend on arbitrary files such as
> > vmlinuz.
> > 
> > 
> > Feedback is welcome.
> > 
> > 
> > P.S.: I was going to do proper merge requests in about 5 or 6
> > months 
> > later but here you are.
> > 
> > adrian15
> > 
> > 
> > El 8/4/20 a las 1:02, jnq...@gmail.com escribió:
> > > update:
> > > 
> > > 1) from my notes, in fact I'd gone back as far as v5.0 confirming
> > > the
> > > presence of the grub-pc failure.
> > > 
> > > 2) I've noticed the presence of the fixed path '/live/vmlinuz' in
> > > binary_grub-efi, and with a hack to have this replaced with the
> > > long
> > > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side
> > > of
> > > the
> > > problem, so that explains how the EFI stuff ends up checking that
> > > fixed
> > > /live/vmlinuz' path and presents an alternate opportunity for a
> > > fix. It
> > > seems the author of the EFI live-build functionality only tested
> > > it
> > > with syslinux.
> > > 

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Hi,

Okay, so I've just take a cursory look at your liveid stuff which also
led me to #924053 where you've already brought up the EFI failure side
of things.

I'll limit my response here (this bug report discussion) to matters
relating to simply fixing the broken ability to get bootable images;
discussion of a unique-disc identification solution can take place
separately.

To fix the issue of broken EFI booting when syslinux is not used (and
thus binary_syslinux was not put in place /live/vmlinuz), I was
intending to solve by moving creation of short filename kernel files
out of binary_syslinux into somewhere common.

The first problem with this though is that alone of course it is not
enough because it does not cover the `/live/vmlinuz1` multi-flavour
case, so a change to binaru_grub-efi would also be needed in order to
dynamically change the searched for file to /live/vmlinuz1 where
appropriate.

However, I now understand from reading #924053 that although this would
fix things in all/most cases, it's at risk of breaking for odd
situations like your HP laptop case. Using /.disc/info as the searched
for file as proposed in #924053 is much a better solution.

My current intention is to take the patch of yours provided in #924053
that makes this change, though with a tweaked commit message (I think
the problem is EFI specific not Secure Boot specific), and submit it in
an MR, along with the fix for grub-pc, and some additional loosely
related work, in one or more MRs.

While the concept of correctly identifying discs (aka liveid type
stuff) is interesting and of some potential value, priority should be
given to simply fixing the ability to create working images first and
foremost.

I will have the patches mark this bug and #924053 as closed, and leave
you to create a new wishlist bug to propose or re-start discussion of
the unique-disc identification stuff as you wish.

Regards,
Lyndon

On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote:
> I think what you need is liveid.
> 
> https://github.com/rescatux/liveid
> 
> Here you can find the technical details and commits:
> 
> https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md
> 
> That way you won't longer depend on arbitrary files such as vmlinuz.
> 
> 
> Feedback is welcome.
> 
> 
> P.S.: I was going to do proper merge requests in about 5 or 6 months 
> later but here you are.
> 
> adrian15
> 
> 
> El 8/4/20 a las 1:02, jnq...@gmail.com escribió:
> > update:
> > 
> > 1) from my notes, in fact I'd gone back as far as v5.0 confirming
> > the
> > presence of the grub-pc failure.
> > 
> > 2) I've noticed the presence of the fixed path '/live/vmlinuz' in
> > binary_grub-efi, and with a hack to have this replaced with the
> > long
> > name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of
> > the
> > problem, so that explains how the EFI stuff ends up checking that
> > fixed
> > /live/vmlinuz' path and presents an alternate opportunity for a
> > fix. It
> > seems the author of the EFI live-build functionality only tested it
> > with syslinux.
> > 

Bug#924053: Find /.disk/info patch

[jnqnfe]

On Tue, 12 Mar 2019 00:14:49 +0100 adrian15 
wrote:
> So I guess, as long as we only support binary_iso it's fine for now
to
> rely on /disk/.info (only generated by xorriso) till we find a better
> method (like the one suggested by Thomas).

small correction as I'm reading through this - the /.disk/info file is
not generated by xorriso, it's generated by the binary_disk script

binary_disk generates output including this file for all of the
following image types: iso, iso-hybrid, hdd

it is skipped for the others: netboot, tar

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

update: I've just tried adding --prefix=/boot/grub to the grub-mkimage
command in binary_iso (which should really be done in binary_grub-pc)
that generates the core_img file that becomes part of grub_eltorito,
and success!

So now that I know how fundamentally to fix the problems, I'll follow
up soon with patches.

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

update:

1) from my notes, in fact I'd gone back as far as v5.0 confirming the
presence of the grub-pc failure.

2) I've noticed the presence of the fixed path '/live/vmlinuz' in
binary_grub-efi, and with a hack to have this replaced with the long
name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the
problem, so that explains how the EFI stuff ends up checking that fixed
/live/vmlinuz' path and presents an alternate opportunity for a fix. It
seems the author of the EFI live-build functionality only tested it
with syslinux.

Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux

[jnqnfe]

Package: live-build
Version: 1:20191221

As mentioned previously in work on an MR, testing images built with
grub (grub-pc and grub-efi) instead of syslinux, I've found that they
are non-bootable, at least with ISO images and in the VM I used.

 - If you use `--bootloaders=grub-pc` on an otherwise default config,
booting the image in a VM (BIOS based) results in a blinking underline
in the top left of a black screen.
 - If you use `--bootloaders=grub-pc,grub-efi` then you get the same
for grub-pc using the VM in BIOS mode of course, and an error regarding
a missing '/live/vmlinuz' in EFI mode (again on an otherwise black
screen).
 - I have not bothered trying `--bootloaders=grub-efi` only, but expect
no difference.
 - I have not bothered trying grub-legacy.

Investigating, there are definitely two parts to this problem. I have
identified one issue, for which I will craft a patch in due course; the
other I do not yet know the cause of. I'm submitting this to ensure
that the problem is documented, until such time as it is completely
solved.

The one issue that I have identified (as I'd previously guessed at) is
that the syslinux script takes responsibility for creating copies of
the kernel files with short filenames. When syslinux is not used, the
kernel files with short filenames (/live/vmlinuz and /live/initrd.img)
do not exist. I have confirmed with a modified image that when the
short filename copies of the kernel files are present, the issue in EFI
mode goes away. So one part of the solution is to move the creation of
the short filename files out of the syslinux script to something used
in all (or more) cases. (Since I cannot see any reference to the
filename/path in creation of the ISO, I presume /live/vmlinuz and
/live/initrd.img paths are hard coded into the grub EFI binaries, so
this is therefore the only solution, not just probably the ideal one
anyway).

This does not however solve the problem with BIOS mode (i.e. grub-pc).
I do not know the cause of the failure here. Hence I felt it
appropriate to get a bug report created.

Note that I have previous made some effort to try to try to locate the
point at which grub-pc last worked, if it ever did, but only got as far
as confirming that this is not a problem introduced by any of my recent
work. It predates that, if grub-pc support ever actually worked at all
(I would not be surprised if it has always been broken).

Again, all my testing has been with ISO images. I've not tried any
others.

Bug#955827: Please remove me from uploaders

[jnqnfe]

On Sun, 2020-04-05 at 13:43 +0100, Ana Custura wrote:
> On 05/04/2020 12:46, jnq...@gmail.com wrote:
> > you can submit a merge request via salsa... 
> 
> Done, thanks! I should probably be removed from the salsa team too.
> 
> Ana
> 

no problem :)

the reviewer will want you to add a "Closes: #955827" line to the
commit message though, such that the bug report automatically gets
marked as pending & closed upon merge and release of the next version
respectively.

probably be a good idea to email Steve / Raphaël / Iain to get your
salsa team membership removed rather than rely upon them noticing it in
this bug discussion.

Bug#955827: Please remove me from uploaders

[jnqnfe]

On Sun, 2020-04-05 at 12:35 +0100, Ana Custura wrote:
> I've not been involved in this for a while now, please remove me from
> the uploaders field in the next upload to keep the list accurate.

you can submit a merge request via salsa...

Bug#954977: "Daily Limit Exceeded" connection error

[jnqnfe]

Package: evolution
Version: 3.36.0-1
Severity: grave

I am currently seeing the following error come up in evolution when
trying to connect to my gmail accounts. Presumably it is a knock on
effect of increased usage brought on by the lock down for COVID-19.

Someone needs to get the quota bumped up.

filing against evolution; apologies if it should have been against
gnome-online-accounts, i was not certain.

```
Daily Limit Exceeded. The quota will be reset at midnight Pacific Time
(PT). You may monitor your quota usage and adjust limits in the API
Console: 
https://console.developers.google.com/apis/api/caldav.googleapis.com/quotas?project=44438659992
```

Bug#954915: [libc6] upgrade fail: A copy of the C library was found in an unexpected directory

[jnqnfe]

Package: libc6
Version: 2.30-3

sudo aptitude upgrade just now:

```
Preparing to unpack .../libc6-dev_2.30-3_amd64.deb ...
Unpacking libc6-dev:amd64 (2.30-3) over (2.30-2) ...
Preparing to unpack .../libc-dev-bin_2.30-3_amd64.deb ...
Unpacking libc-dev-bin (2.30-3) over (2.30-2) ...
Preparing to unpack .../libc6-dbg_2.30-3_amd64.deb ...
Unpacking libc6-dbg:amd64 (2.30-3) over (2.30-2) ...
Preparing to unpack .../libc6_2.30-3_amd64.deb ...

A copy of the C library was found in an unexpected directory:
  '/usr/lib/x86_64-linux-gnu/ld-2.30.so'
It is not safe to upgrade the C library in this situation;
please remove that copy of the C library or get it out of
'/usr/lib/x86_64-linux-gnu' and try again.

dpkg: error processing archive /var/cache/apt/archives/libc6_2.30-
3_amd64.deb (--unpack):
 new libc6:amd64 package pre-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.30-3_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
dpkg: dependency problems prevent configuration of libc6-dbg:amd64:
 libc6-dbg:amd64 depends on libc6 (= 2.30-3); however:
  Version of libc6:amd64 on system is 2.30-2.

dpkg: error processing package libc6-dbg:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libc6-dev:amd64:
 libc6-dev:amd64 depends on libc6 (= 2.30-3); however:
  Version of libc6:amd64 on system is 2.30-2.

dpkg: error processing package libc6-dev:amd64 (--configure):
 dependency problems - leaving unconfigured
Setting up libc-dev-bin (2.30-3) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for libc-bin (2.30-2) ...
Errors were encountered while processing:
 libc6-dbg:amd64
 libc6-dev:amd64
```

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

On Tue, 2020-03-24 at 21:16 +0100, Julian Andres Klode wrote:
> On Tue, Mar 24, 2020 at 08:09:24PM +, jnq...@gmail.com wrote:
> > Hi, Julian,
> > 
> > Thanks for adding the colour support in apt 2.0.1.
> > 
> > I'm curious though, most implementations use isatty() to determine
> > the
> > default colour control setting, which it seems that your
> > implementation
> > lacks, instead only outputting colour when explicitly enabled via
> > `-o
> > APT::Color=true`.
> > 
> > Was it a deliberate decision to not make use of isatty() to
> > determine a
> > default?
> 
> That's how it works, apt(8) sets APT::Color to true by default, and
> the
> code sets it to false if stdout is not a tty. Which it already did
> before,
> as you can see in apt list, for example.
> 
> As is customary, for compatibility reasons, apt-get(8) and apt-cache
> and 
> friends do not change behavior.

Oh, sorry. I saw no isatty() related change in a commit referenced from
the automatic 'pending' notification, and I did indeed try with apt-get 
rather than pure apt after updating which had no color by default, so
figured it must be missing. thanks.

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

Hi, Julian,

Thanks for adding the colour support in apt 2.0.1.

I'm curious though, most implementations use isatty() to determine the
default colour control setting, which it seems that your implementation
lacks, instead only outputting colour when explicitly enabled via `-o
APT::Color=true`.

Was it a deliberate decision to not make use of isatty() to determine a
default?

Regards,
Lyndon

Bug#954232: [deluge] wrong status labels

[jnqnfe]

To be more clear, the download speed and amount uploaded are swapped

On Thu, 19 Mar 2020 03:06:48 + jnq...@gmail.com wrote:
> Package: deluge
> Version: 2.0.3-2
> 
> labels in the status panel are mismatched with the values given
> 
> e.g.
> Download Speed: 1.0G (614.3 M)
> Up Speed: 7.3 K/s
> Downloaded: 6.7 G (1.1 G)
> Uploaded: 8.4 K/s

Bug#954235: [deluge] crash on select folder

[jnqnfe]

Package: deluge
Version: 2.0.3-2

Where ever selecting a directory, such as 'download to' in preferences,
or move to actions, there are two buttons, one on either side of the
path textbox. the one on the left with a folder icon works fine and
allows you to accomplish the job. The one on the right has a down arrow
and hovering says "saved paths" in a tooltip. Clicking on this results
in an immediate crash of the application.

Bug#954233: [deluge] ctrl+up/down jumps multiple rows

[jnqnfe]

Package: deluge
Version: 2.0.3-2

Using ctrl+up|down sometimes moves the selected item multiple rows
instead of one

Also, after the move, if you then just use up|down to change the
selection, it jumps to the wrong place based upon seemingly outdated
information.

Bug#954232: [deluge] wrong status labels

[jnqnfe]

Package: deluge
Version: 2.0.3-2

labels in the status panel are mismatched with the values given

e.g.
Download Speed: 1.0G (614.3 M)
Up Speed: 7.3 K/s
Downloaded: 6.7 G (1.1 G)
Uploaded: 8.4 K/s

Bug#954081: debian-live-10.3.0-amd64-gnome.iso fails to load desktop on Acer A515-43-R19L laptop

[jnqnfe]

Just throwing a couple of thoughts your way in case it helps at all.

Ending up with a blank screen with a blinking cursor in the top left
instead of the graphical login suggests that the graphical environment
could not load for some reason. I have experienced this myself a couple
of times using Debian's unstable channel after a major partial upgrade
to a new version of Gnome. I also happen to have experienced it today
when I returned to my computer only to find that a download had used up
all of my remaining free disk space and things were not happy.

Note that you can use CTRL+ALT+ to switch to a different
console interface and thus login in in text based mode. (The default
graphical environment is assigned to one of the F1-12 keys, just try
different F1-12 keys with CTRL+ALT until you get a text console).

Since other distro live discs are working, but not the current Debian
discs, have you tried an older Debian disc? Perhaps the particular
package versions in the latest discs have a bug, just like I've
experienced with the updated Gnome situation just mentioned, and the CD
release team did not notice or it only occurs in certain situations.

Note that you can build your own custom live disc with Debian's live-
build tool, though of course if you're having trouble getting Debian
installed in the first place ...

On Mon, 2020-03-16 at 11:13 -0700, Lou Poppler wrote:
> This is possibly a "non-free" firmware problem.  I suggest you try
> with one of
> the "unofficial" "non-free" live images or installer images.
> 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
> 
> On Mon, 2020-03-16 at 09:25 -0400, Mike Haag wrote:
> > Package: debian-live
> > Severity: important
> > 
> > I first updated the BIOS using the supplied Windows 10, then
> > replaced the
> > supplied 128GB SSD with a new 500GB SSD.
> > 
> > Verified the iso file with SHA512, and tried running as both DVD
> > and USB thumb
> > drive:
> > 
> > Grub starts as expected.
> > 
> > 1. Attempted to start the live desktop environment from the first
> > Grub menu
> > item, "Debian GNU/Linux Live (kernel 4.19.0-8-amd64)".
> > 2. Multiple status messages are displayed. Then, a Debian splash
> > screen is
> > briefly displayed, followed immediately by a blank screen with a
> > blinking
> > cursor, and the system freezes.
> > 3. Ctrl-Alt-Del will reboot the laptop into the Grub menu.
> > 
> > The graphical installer (third Grub menu item) runs, and appears to
> > complete
> > successfully. But, the installed system exhibits the same problem:
> > Multiple
> > startup messages, and the system freezes before the desktop
> > environment starts,
> > just displaying a blank screen and blinking cursor.
> > 
> > For what it's worth, I also tried several other Debian-based and
> > RPM
> > distributions. Could only get a working system with the RPMs:
> > 
> > 1. Debian: The following produce the same results as above.
> > 
> >  debian-live-10.3.0-amd64-gnome+nonfree.iso
> >  debian-live-testing-amd64-gnome.iso
> >  debian-10.3.0-amd64-netinst.iso
> > 
> > 2. Ubuntu 19.10 and LinuxMint 19.3: The live distributions work as
> >expected. Installed systems begin to boot but then both fail
> > with
> >unspecified watchdog soft lock errors before their respective
> > desktop
> >environments start.
> > 
> > 3. Fedora 31: Live runs as expected. Installed system boots and
> > runs as
> > expected.
> > 
> > 4. OpenSUSE Leap 15.1: Live runs as expected. Installed system
> > boots and runs
> > as expected.
> > 
> > The only recommendation I could find using the Acer user forum and
> > other
> > internet searches, was to try editing the Grub menu line to
> > "nomodeset", but
> > that doesn't work. There was also some theorizing that the kernel
> > needed to be
> > updated to 5.0, but openSUSE 15.1 is kernel 4.12, and that is
> > working.
> > 
> > Looking for advice and suggestions: I do not know how to proceed
> > with further
> > trouble-shooting.
> > 
> > Thanks, Mike
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: 10.3
> >   APT prefers stable-updates
> >   APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 

Bug#952854: [live-build] disks handling for netboot

[jnqnfe]

just to update this...

the relevant fix for addressing the core issue of the missing netboot
case was addressed in the merged commit
c48caf36fd33c45328cfa570849af352e8b443d8. but this only introduced the
case entry and output of the disk info file, which was obvious. what
remains, hence this bug report, is to address what is correct for the
netboot case with respect to the other details done for other cases,
and thus address the fixmes I left.

 - what should the `DISK_TYPE` be set to for the netboot case?
 - should anything being output for binary/.disk/base_components?
 - should binary/.disk/base_installable be created?
 - should a udeb include file be copied?

Bug#953957: [live-build] W: Download is performed unsandboxed as root as file '.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[jnqnfe]

For the record - I also did not realised until it was pointed out that
apt has it's own user account.

Bug#953957: [live-build] W: Download is performed unsandboxed as root as file '.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[jnqnfe]

On Sun, 2020-03-15 at 11:34 +, Luca Boccassi wrote:
> The reason I asked for the change and I wasn't comfortable with
> making
> the download directory 777 is that live-build is routinely used in
> automated production systems to create images. I do not want to
> introduce the risk of a rogue, unprivileged process to be able to
> mess
> with the downloaded files after apt has ran, if it's just to fix a
> harmless warning.
> 
> If it can be fixed without introducing risk - great! If not, I would
> recommend to document it and leave it.

I hope that my bug report did not make you feel that I was being
critical of your decision. That is not the case, I very much agree with
whying away from 777. I was just trying to document the details of what
worked and what did not. :)

FWIW I care greatly about security and as mentioned in the MR, I need
to refresh my mind (I'll  look it up shortly) as to what protections
parent directory permissions give to subdirs as I might have been
mistakenly thinking that the parent having root:root 755 permissions
would prevent malicious outside access to this directory, but I'm
probably wrong. (a long time since I last referenced that fundamental
detail).

I'm not so sure that we could consider the warning harmless. I would
expect that apt is warning that it was unable to drop root privileges
to do verification of the file or something, which means that a
malicious file from a MITM hijack could trigger a bug if there were one
in apt and gain root privileges rather than user.

Anyway, I'm getting a little off topic...

---

Regarding the bug itself, I had an epiphany last night which I just
checked out and confirmed. The problem is simply that we're performing
the chown from the host level whilst running apt-get within the chroot,
and there's no guarantee that the _apt user will have the same UID
between the two. To fix the problem all we need to do is run chown
within the chroot environment too, thus actually assigning the correct
UID to the folder.

I just tested this and it works :D
I'll post an MR in a moment.

Bug#953957: [live-build] W: Download is performed unsandboxed as root as file '.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[jnqnfe]

Package: live-build
Version: 1:20191221

744141c60f55144b4d8944ba0d745adcc4b34116 (from MR #97) tried to fix the
bug of the source stage generating permissions related warnings when
downloading source packages.

the original fix submitted in the MR was to set the permissions of the
download directory to 777. the reviewer requested that instead
ownership be set to _apt:root, which was the version of the commit that
then got merged.

unfortunately this modified solution does not work. i do not know why
this was not caught at the time, whether i did not bother to test since
it seemed so obvious that it should work, or whether something went
wrong with conducting a fresh test, but re-running the source stage now
i see that the problem still exists.

i have been playing around with trying to figure out a suitable
alternative to properly solve this but not been successful so far.

submitting this as a bug report to ensure that a record is made in case
i don't find a solution / i end up forgetting about this / someone else
can find a solution in the meantime.

Bug#835498: checkbashisms treats 'command' incorrectly

[jnqnfe]

control: severity -1 important

Debian policy v4.1.5 (July 2018) updated from SUSv3 to POSIX.1-2017
(aka SUSv4). This should presumably (without double checking the
specifics of this version) mean that the way is clear for checkbashisms
to be modified to accept `command -v` etc.

Please address this; the lack of support just impacted some work on
live-build with some work getting reverted due to not passing
checkbashisms, when it turns out that the commit was fine, but
checkbashisms is outdated.

thanks.

On Fri, 26 Aug 2016 12:38:19 +0100 "Adam D. Barratt" <
a...@adam-barratt.org.uk> wrote:
> Control: tags -1 + moreinfo
> 
> On 2016-08-26 11:47, Eero Vuojolahti wrote:
> > Secondly, there are no optional flags listed in the 2008/2013
version
> > of the 'command' specification. In the older (2004) standard, the
|-v|
> > and |-V| options were part of the 'user portability' subset, not
part
> > of the core.
> > 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
> 
> POSIX 2004 might be "older" but it is the version referenced by
Debian 
> Policy - as per 
> ;:
> 
> "Scripts may assume that /bin/sh implements the SUSv3 Shell Command 
> Language[90] plus the following additional features not mandated by 
> SUSv3
> [list that doesn't mention "command"]
> 
> If a shell script requires non-SUSv3 features from the shell
interpreter 
> other than those listed above, the appropriate shell must be
specified 
> in the first line of the script (e.g., #!/bin/bash) and the package
must 
> depend on the package providing the shell (unless the shell package
is 
> marked "Essential", as in the case of bash).
> [...]
> 90
> 
> Single UNIX Specification, version 3, which is also IEEE 1003.1-2004 
> (POSIX), and is available on the World Wide Web from The Open Group 
> after free registration.
> "
> 
> checkbashisms's handling of "command" appears to be in line with
that 
> Policy requirement.
> 
> Regards,
> 
> Adam
> 
> 

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

On Tue, 2020-03-10 at 21:10 +0100, Julian Andres Klode wrote:
> Control: severity -1 wishlist
> Control: tag -1 confirmed
> 
> On Tue, Mar 10, 2020 at 06:13:28AM +, jnq...@gmail.com wrote:
> > Package: src:apt
> > Version: 2.0.0
> > 
> > Please add red/yellow colour highlighting to the 'E'/'W' prefixex
> > respectively output for errors/warnings respectively. (UX
> > improvement).
> > 
> > This would not only benefit direct use of apt binaries, but also be
> > beneficial when used in scripting, such as with live-build where a
> > warnign could be hidden in the middle of a great deal more output
> > that
> > with direct use.
> 
> How does the attached look? Bold red for error, bold yellow for
> warning and yellow for notice; matching dpkg.


on second thoughts, playing here with the colouring for a different
program, having yellow+bold for warnings and yellow without bold for
notices might not be the best idea; depending upon colour scheme and
options, boldness might actually not actually have any effect, thus
rendering warnings and noticed being coloured the same, detracting from
the point of highlighting them in the first place.

i'd keep red+bold for errors and yellow+bold for warnings, but perhaps
reconsider the choice for notices. perhaps blue/cyan/light-magenta
might be more sensible. i'd like to see dpkg reconsider this also.

though ideally we'd want to stick as closely as possible with common
choices. if different programs are selecting different colours then it
can become a complete mess, especially when multiple programs are run
by a script like live-build...

Bug#953639: [live-manual] old urls

[jnqnfe]

Package: live-manual
Version: 2:20151217.1

I've addressed two old alioth urls in an MR, two more remain though.

user_customisation-packages.ssi uses such a url in an example apt
sources.list line.

project_procedures.ssi uses such a url in reference to a location where
images can be downloaded.

i am not aware of whether newer urls exist somewhere or otherwise what
would be the ideal solution in terms of addressing the broken
information.

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

On Tue, 2020-03-10 at 21:10 +0100, Julian Andres Klode wrote:
> Control: severity -1 wishlist
> Control: tag -1 confirmed
> 
> On Tue, Mar 10, 2020 at 06:13:28AM +, jnq...@gmail.com wrote:
> > Package: src:apt
> > Version: 2.0.0
> > 
> > Please add red/yellow colour highlighting to the 'E'/'W' prefixex
> > respectively output for errors/warnings respectively. (UX
> > improvement).
> > 
> > This would not only benefit direct use of apt binaries, but also be
> > beneficial when used in scripting, such as with live-build where a
> > warnign could be hidden in the middle of a great deal more output
> > that
> > with direct use.
> 
> How does the attached look? Bold red for error, bold yellow for
> warning and yellow for notice; matching dpkg.

looks perfectly fine to me in principle. I'm familiar with dpkg's
colouring which sticks to the common values of "\033[1;31m" (red+bold)
for error and "\033[1;33m" (yellow+bold) for warnings, which is what
I'm sure you've probably used also and is inline with my expectations
:)

Bug#951679: [gedit] sh syntax highlighting bug

[jnqnfe]

control: fixed 3.36.0-1

I no longer experience this with gedit 3.36

I reported it upstream earlier ([1]), which I've left open in case they
want to still address the bug in gtksourceview 3.24, but no longer
affects me as gedit 3.36 uses gtksourceview v4 which does not suffer
from it (and has nicer highlighting on top).

[1]: https://gitlab.gnome.org/GNOME/gedit/issues/274

Bug#953399: [apt] indentation issues

[jnqnfe]

I meant to add that since apt documents a specific set of options for
the `indent` application to achieve the correct formatting, that it
would be best for a maintainer to simply make use of that (if my
pointing it out helps as a reminder of this shortcut). Offering a patch
would be a waste of time wrt. the time needed to review it, vs. running
the tool yourself obviously, which is why I did not attach one.

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

Package: src:apt
Version: 2.0.0

Please add red/yellow colour highlighting to the 'E'/'W' prefixex
respectively output for errors/warnings respectively. (UX improvement).

This would not only benefit direct use of apt binaries, but also be
beneficial when used in scripting, such as with live-build where a
warnign could be hidden in the middle of a great deal more output that
with direct use.

thanks.

Bug#953399: [apt] indentation issues

[jnqnfe]

Package: apt
Version: 2.0.0

The codebase contains indentation issues resulting from lack of 
consistency. I see a lot of lines using tabs mixed together with lines
using the correct 3-space indentation (per style guide).

This might not look so bad for people with editors set to 8-space tab
width, but things are misaligned for those like me at 4-space.

Bug#953387: [dpkg] colour highlighted error/warning label not always output

[jnqnfe]

having now taken a look at the codebase, I can see that most of it is
in fact perfectly well suited to such colour highlighting and I'm
probably creating a small fuss over nothing; regretting bothering to
submit the report now.

two utilities are missing it - start-stop-daemon and update-
alternatives, but I don't know whether to bother submitted a patch for
that. I should probably take it on good faith that it was thought
unnecessary for them, considering the excellent state of this
throughout the dpkg source anyway.

so going back to the case originally mentioned of the output from when
dependency problems exist when trying to perform a purge, the only
question is whether this could be enhanced with a colour highlighted
error/warn label...

Bug#953387: [dpkg] colour highlighted error/warning label not always output

[jnqnfe]

Package: dpkg
Version: 1.19.7

I've noticed that in some cases dpkg gives colour highlighted
error/warning labels in its output, but in others it doesn't.
The highlighting obviously gives an enhanced UX experience and lacking
it in places detracts from that.

For example, I notice that it _is_ used with bad options, e.g. in
"dpkg: error: unknown option --purg"

While it is not done in "dpkg: error processing package python3-uno (
--purge)"

In the latter case of course there is no actual such label to
highlight, the word "error" is part of the specific log message.

So this breaks down into two issues
1) instances where colour support is missing (e.g. from looking at the
codebase I can see that the start-stop-daemon utility lacks it)
2) instances where there is no label to colour

I'm looking at the codebase to see if I can offer up a patch to address
both of these.

Bug#952859: Acknowledgement ([live-build] Help() appears to be unused)

[jnqnfe]

Hmm, somehow despite basing this upon a codesearch via the gedit 'find
in files' plugin, I've just noticed that the report is partially wrong
since `lb config --help` and `lb clean --help` do call Help().

The HELP strings in each script otherwise is however still pointless.

Bug#952933: [live-build] local var scope in functions

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

there are many variables that are local to functions for which `local`
should be used.

patch to be submitted via salsa soon

Bug#952932: [live-build] download version specific sources

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

source packages are downloaded by name only. surely it would be best if
we added version specific qualifiers to thus target specifically copies
of the packages that actually definitely correspond to the versions
used/installed?

patch to be submitted via salsa soon

Bug#952931: [live-build] download src pkgs to clean dir

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

the source stage downloads src packages into the root of the chroot. it
would surely be better to download them into the clean directory
created to hold them.

patch to be submitted via salsa soon

Bug#952930: [live-build] inst: use bool rather than int

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

the DOWNLOAD_GTK_INSTALLER variable in installer_debian-installer is an
integer with two states, 0 or 1. This would be better as a boolean.

patch to be submitted via salsa soon

Bug#952929: [live-build] disable rather than remove deb-src entries

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

when generating apt sources.list files, deb-src files are either
included or they are not. alternatively what if they were always
included but commented out when not wanted?

the benefit is that should the user ever want src packages, all they
would have to do is uncomment the relevant line(s) rather than add
them. is that not better?

patch to be submitted via salsa soon

Bug#952928: [live-build] tidier deb-src inclusion

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

the code for building apt sources.list (which also suffers from a
duplication issue - #952889) is overly messy due to conditionals placed
around every possible inclusion of deb-src entries.

it could be a great deal neater if the conditionals were scrapped, the
deb-src entries thus always written, and then at the end sed was
conditionally used to remove the lines if unwanted.

writing data that only has to then be unwritten "rubs against the
grain", but these are tiny files, only written a couple of times or so
in a build, and the enhanced readability of the code makes this very
much worth it.

patch to be submitted via salsa soon

Bug#952927: [live-build] inconsistency and unnecessary complexity in bin checking

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

there are lots of checks being done that tools are available and
executable. this is done with a mixture of use of `which` and fixed
paths, redirection of output to /dev/null (`2>/dev/null`) and redundant
executability tetsing on top of `which` checks (which already does such
a check).

this can be tidied up and robustified.
 - we can move everything to `which` and drop fixed paths, thus
robustifying things should a bin every move (you never know).
 - we can drop performing pointless `-x` testig on top of `which` use,
since `which` already performs this and signals such in its exist code
(returns 1 if nonexistant or nonexecutable).
 - we can drop the `2>/dev/null` redirection which in my testing seemed
to make no difference.

proposal: switch to conditionals of the form:
```
if [ $(which dpkg) ]; then
#whatever
fi
```

patch to be submitted via salsa soon

Bug#952924: [live-build] inefficient mkdir/rmdir use in chroot_hooks

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

per title, mkdir/rmdir use in copying hooks is inefficient

patch to be submitted via salsa soon

Bug#952923: [live-build] caching override not overriding

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are four caching rated controls --cache, --cache-indices, --
cache-packages and --cache-stages.

The first has a description of "defines globally if any cache should be
used at all. Different caches can be controlled through the their own
options.".

It is somewhat ambiguous, but should --cache, if specified, not
overrule the others. if so, then there is no such enforcement of this.

patch to be submitted via salsa soon

Bug#952921: [live-build] explanatory file needed in source image

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

a copy of the build config is stored in the source image. it might be a
good idea to have a readme file to accompany this to explain WTH that
set of files and folders is to anyone browsing the disk/image contents.

patch to be submitted via salsa soon

Bug#952920: [live-build] confusing config handling function names

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

the functions Set_defaults() and Check_defaults() are not ideally clear
in that they relate to the config. Proposal: renaming to
Set_config_defaults() and Check_config_defaults() respectively.

patch to be submitted via salsa soon

Bug#952919: [live-build] messy script init

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

some of the steps performed in the initialisation steps of scripts are
messy and suffer from  code duplication issues (e.g. the list of config
files to read).

it would is trivial to address this will a little effort.

low-level build components all:
 - run `Arguments "${@}"`
 - read the set of config files
 - run Set_defaults()

this could be consolidated into a hypothetical `Init_config_data
"${@}"` call.

the major build stages all:
 - check for the existence of a config and conditionally call `lb
config`
 - run `Arguments "${@}"`
 - read the set of config files
 - run Set_defaults()
 - run Setup_cleanup()

this could be consolidated into a hypothetical `Init_build_stage
"${@}"` call.

the primary commands (`lb config`, `lb build` and `lb clean`) could
make use of some of the same component helpers that those hypothetical
functions might use, e.g. to get the set of config files from a single
declaration.

patches to be submitted via salsa soon

Bug#952918: [live-build] two step lock acquisition

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

lock acquisition in every script is a two step process - check then
create. it is unnecessary to be split like this in scripts, it creates
opportunity for mistakes such as of of these steps to be lost or done
in the wrong order for instance.

it would be ideal to have a wrapper that makes these two calls which
can be used instead.

patch to be submitted via salsa soon

Bug#952917: [live-build] less than ideal STAGE tests

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

in a few places a loop is performed over LB_CACHE_STAGES, performing an
action if a matching stage is in the list. this code can be
significantly improved with use of In_list().

patch to be submitted via salsa soon

Bug#952916: [live-build] confusing package cache save/restore

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

the Restore_cache() and Save_cache() functions are misleading in their
names; they are specifically for handling **packages** kept in the
cache. they could do with renaming to help understandability of the
code.

furthermore their use is overly verbose. **every** use is with a param
of the form "cache/packages.binary" or "cache/packages.chroot". there
is obviously a common prefix here which could be eliminated.

patch(es) to be submitted via salsa soon

Bug#952915: [live-build] overly complex In_list function

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

the In_list function actually supports multiple needles to be searched
for at a single time. nothing uses this function to find more than one
needle at a time and such functionality is highly questionable in its
usefulness.

this function is thus needlessly more complex than it needs to be.

patch to be submitted via salsa soon

Bug#952914: [live-build] udeb handling issues

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are notable issues with the way udebs are handled in the
installer code:
 - in rare but possible scenarios it could be possible for both a
parent and derived copy of a package to end up included, due to the
lazy way things are handled.
 - the bundling of parent and derived sets are simply bundled together
in a single list and then an attempt is made to download from the
derived mirror, falling back to the parent on failure, which leads to a
lot of 404 errors, as pointed out by an log message that gets printed
out to advise users to not worry about them.

it is not hard and is desirable for the necessary robustness to be
implemented here such that any packages that are being obtained from
the derived source are excluded from being obtained from the parent; so
that these two lists are kept separate and udebs in each lists obtained
from the actual correct location; and that files only be taken from the
cache when they really are supposed to be.

patches to be submitted via salsa soon

Bug#952911: [live-build] make use of cache for firmware list determination

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

as mentioned in #952907 and #952910, the content archives files used in
determining a list of firmware packages available are always downloaded
afresh, deleting any existing file that had been saved to the cache.
this is inefficient, even just within a single build (the same file
might be processed up to four times - chroot_firmware and
installer_debian-installer, and twice each in each if done for both
parent and derived without the #952909 fix). then we must consider
multiple runs, especially important when developing LB. it takes time
to download these files.

it also has implications wrt. offline building, should anyone be
interested in that.

consideration should be given to actually making use of cached files.

patch implementing use of cached files to be submitted via salsa soon

Bug#952910: [live-build] save compressed contents file to disk

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

as pointed out in #952907, the archive contents file is not cached in
an efficient way. #952907 concerns itself with fixing the small aspect
of not pointlessly leaving the file hanging around once it has been
finished with since caching is not actually being exploited.

here we concern ourselves with taking things further in another respect
- instead of storing the decompressed file in the cache, let's tweak
things such that it is the compressed file that is saved to disk.

note that as discussed before, the file for the 'main' archive area is
by far the largest, and is over 600MiB currently for amd64 whilst the
compressed file is ~30MiB.

we currently download the compressed file, piping it into gunzip and
saving the decompressed inner file to disk, parse the file, then delete
it (per #952907 the last used hangs around pointlessly which that
proposes fixing). we could instead save the compressed file to disk,
then pipe the decompression of that (it only holds one file) through
awk to get the list.

this would mean much less disk IO. it also means that if/when we do
change things to properly take advantage of caching then we require
much less disk space to do so.

patch to be submitted via salsa soon

Bug#952909: [live-build] duplicate work in firmware list construction

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

firmware list construction can involve duplicate work for derivative
builds, as noted in a long term fixme.

parent and derived have separate archive area lists; if the
distribution of parent and derived be the same, then any archive area
that exists in both lists would result in duplicated work.

patch to be submitted via salsa soon

Bug#952908: [live-build] duplication of firmware list construction code

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

there are four duplicate blocks of code for constructing a list of
firmware packages, which is terrible for maintainability.

patch to be submitted via salsa soon

Bug#952907: [live-build] cache pointlessly retained and potentially large (~600MB) file

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

in handling firmware, archive content files are downloaded and
extracted in order to obtain a list of firmware packages. the
uncompressed file is saved in the cache. it is not removed from the
cache once finished with. this makes sense since the whole point of a
cache is to reuse stuff, but the fact is that it never actually gets
re-used, the code always deletes any existing file and replaces it with
a fresh copy.

this might not be so bad if building with more than just the main
archive area and main is not the last in the list, since contrib and
non-free are much smaller files than main, but otherwise this could be
somewhat significant to users. The main file, currently, for amd64, is
a little over 600MiB!

there are several improvements that could be made, but we can implement
a very simple initial fix of simply by deleting this file once we've
finished with it.

patch to be submitted via salsa soon

Bug#952906: [live-build] inefficiency in FIRMWARE_PACKAGES list construction

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

the logic used to construct FIRMWARE_PACKAGES suffers from an
inefficiency.

where multiple archive areas are used, the code on each per-archive-
area loop is:
 1) fetching the archive area contents file (compressed)
 2) **appending** the output of decompressing to a file
 3) searching the file for firmware references, adding to the list

this means that obviously there will be duplicates in the final list.
not that it means anything is broken, but it is flawed in terms of
efficiency.

patch to be submitted via salsa soon

Bug#952891: [live-build] start-stop-daemon dpkg hack can be simplified with ln

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

...in the same way as for flash-kernel

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952892: [live-build] rename --architectures to --architecture

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

--architectures only takes a single architecture, so should be renamed
to no longer be plural to avoid user confusion.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952889: [live-build] sources.list generation code duplication

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there is a significant chunk of code for generating an apt sources.list
file that is duplicated in three different places in the codebase. in
two cases it is identical, in the third it only differs in the
variables used for mirrors and such.

this can very easily be extracted to a common function and would be a
notable improvement in terms of maintainability.

specifically bootstrap_archives holds one copy and chroot_archives the
other two.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952890: [live-build] bootloaders ignore LB_DEBIAN_INSTALLER_GUI

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the graphical installer is only bundled if LB_DEBIAN_INSTALLER_GUI
permits it, however the bootloaders ay no attention to this and the
corresponding menu entries end up in the image anyway which will
obviously be non-functional.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952887: [live-build] overly complex script description handling

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

every single script (those under scripts/build/) uses a subcmd to
inject a newline to the end of DESCRIPTION string which is used by
Help() or Usage() if called.

this is rediculous; the scripts can just hold a plain simple string
with these two functions outputting the wanted newline.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952885: [live-build] redundant usage line

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

...in chroot_install-packages

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952883: [live-build] binarie_onie lacks newline before errors

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

binary_onie takes the unusual (with respect to all other scripts) step
of outputting a series of dots as it progresses through various parts
of its script. these dots are all printed on the same line and finally
are terminated with 'done'. the problem is that if an error occurs, the
error should no doubt be placed upon a new line but is not.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952884: [live-build] wrong command in help/usage output

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

functions/common.sh holds a variable PROGRAM set to "live-build" which
is used in places where both "live-build" AND "lb" should appear.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952882: [live-build] binary_onie lacks use of echo helpers

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

as titled.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952880: [live-build] some of the echo helpers are redundant

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

some of the echo helpers are completely unused and should be removed.
specifically:
 - Echo_status
 - Echo_done
 - Echo_debug_running
 - Echo_message_running
 - Echo_verbose_running

a couple of those functions are furthermore the only users of a couple
of the functions in cursors.sh, with all of the remaining cursor
functions being entirely unused, so this means that with the above echo
helpers gone, we can also entirely remove cursors.sh.

patches to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952881: [live-build] binary_iso using wrong echo helper

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

Echo_message() should be used instead of Echo() for "No EFI boot code
to include in the ISO".

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952879: [live-build] lack of robustness in echo helper output

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the echo helpers almost entirely do not explicitly direct their output
to stdout/stderr, and failing to do so means that in some use cases
(specifically use in functions whose purpose is to return a string (by
echoing it)) things go wrong with log messages (after all these after
effectively all logging functions) not making it to the console as they
should.

this could perhaps have been merged with #952878 which is specifically
about the error echo helper sending part of its output to stderr but
not all...

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952876: [live-build] failure to use echo helpers

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are some places where the echo helpers are not being used when
they should be.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952877: [live-build] unnecessary use of echo helpers in help/usage

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

the Help() and Usage() functions make unnecessary use of echo helpers
which makes them much messier than they need to be.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952878: [live-build] error printing problem

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the error echo printing helper explicitly sends the main part of the
message to stderr, but prints the 'E:' prefix normally meaning that in
some use cases things go wrong such as the prefix not appearing.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952875: [live-build] inconsistent capitalisation for start of messages

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

as titled; several instances of this

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952874: [live-build] error split into two that should not be so

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

...for consistency, no other errors are split like it.

specifically referring to the 'ntfs' related one in defaults.sh.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952873: [live-build] *_archives have wrong comment placement ...

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

...for 'configure custom sources.list'

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952866: [live-build] poor LB_MEMTEST=false handling

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the memtest option takes values of memtest86+|memtest86|none however
there are some parts of the codebase handling a value of "false",
presumably as an old backwards compatibility hack (I've not bothered to
go back in the history to find out why).

the way this value is handled is not ideal; it is done within
individual component scripts, whereas it should be handled within
Set_Defaults(), specifically by translating to "none".

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952865: [live-build] binary_disk refactor

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

the case block in binary_disk involves a lot of repetition and could do
with a refactor.

note, the patch to be submitted builds upon those for 952846 and
952864.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952864: [live-build] true|false are confusing values for --debian-installer

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the --debian-installer option accepts values of
true|cdrom|netinst|netboot|businesscard|live|false. Having 'true' and
'false' here is very confusing. the set of values needs replacing with
cdrom|netinst|netboot|businesscard|live|none.

note that `true` is being treated as an alias for `netinst`. in the new
set of values `none` would obviously be equivalent to the current
`false`.

a patch for this was previously submitted in a large patch set that was
never merged. I looked at it the other day to refresh my mind, though
do not recall the bug number and can't be bothered to dig it up, and I
remember a review comment specifically referring to my patch for this,
not liking the fact that the patch had no backwards compatibility. such
backwards compatibility has been reworked into this resubmission.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952863: [live-build] missing shebangs

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

in multiple places of the scripts generating `.sh` files shebangs are
not written to those files.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952862: [live-build] source_iso performs append instead of replace

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

when writing to chroot/source.sh the source_iso script does so at one
point with an append write instead of replace.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952859: [live-build] Help() appears to be unused

[jnqnfe]

Package: live-build
Version: 1:20191221

Every script defines HELP which is made use of in Help(), but the lb
frontend redirects either to the manpage or Usage(), so Help() along
with all the HELP strings seems redundant and in need of removal.

Bug#952860: [live-build] daily d-i is duplicated

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are two copies of the daily d-i URL in the code, which is not
ideal.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952861: [live-build] unnecessary string conversions of exit codes

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the codebase contains some unnecessary conversions of numeric exit
codes to strings.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952858: [live-build] frontend help/usage fixme

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the 'lb' frontend has a fixme for its help/usage strings. 
 - `HELP` does not actually get used anywhere since the only place that
reads it - Help() - is never called.
 - `USAGE` does get called, for instance with `lb --usage`, where you
currently see "FIXME" appear. the top level commands applicable to this
usage string should at least specify the three top level commands and
thus be "lb {clean|config|build}"

alternatively we could consider something like "lb {clean|config|build}
[OPTIONS]", which is especially relevant to `lb config`, but "lb
{clean|config|build}" is at least a good start.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952857: [live-build] indentation issues

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

lots of indentation issues in the codebase, both in terms of spaces
instead of tabs and other forms of inconsistency.

i've a whole bunch of them (hopefully all of them) wrapped up i a
single commit to be submitted shortly. creating a single bug number to
reference...

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952856: [live-build] manpage issues

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are various issues in the manpages to address
 - parent installer option not specifying that 'daily' is a possible
value
 - the list of component script descriptions is out of date
 - various typos
 - the mixing of primary (config,build,clean) and secondary build
component commands in the same list is confusing, they need separating
into two different lists.
 - acronyms need uppercasing
 - 'installer' missing in list of stages
 - 'build' config file missing in list of config files
 - obsolete ubuntu info
 - wrong description for --firmware-chroot
 - etc...

It's not worth it imo to create an individual bug report for each and
every issue here. I've got a patch set created or it all, and a single
bug number to reference should be more than sufficient.

patches to be submitted via salsa shortly

Bug#952854: [live-build] disks handling for netboot

[jnqnfe]

Package: live-build
Version: 1:20191221

this is an extension of #952846 which concerns netboot being missing in
case statements in binary_disk and source_disk.

i'm making a fresh bug report here because my intention with the former
bug number is to assign a bug number for my patches which just add in
the necessary case entries...

...there is still the matter of what should be done in the binary_disk
case besides creation of the disk info file, if anything. i.e. this bug
concerns addressing a fixme left in my #952846 patches.

I'm submitting this perhaps prematurely, perhaps review of #952846
before it is merged will demand addressing the fixme somehow, but I'm
not certain myself what is required to do so, and so I'm hoping that my
patches will close #952846 and this new report will remain regarding
the fixme.

Bug#952851: [live-build] unquoted string in installer script

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the installer_debian-installer script contains an unquoted "true"
string.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952850: [live-build] rootfs chmod of file only done in one case not other

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the binary_rootfs script allies chmod 644 to the squashfs file in one
case but not another.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952849: [live-build] rootfs deletion of file from wrong location

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the binary_rootfs script incorrectly tries to delete
chroot/chroot/excludes instead of chroot/excludes.

patch to be submitted via salsa shortly (will amend commit with bug
number first)