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
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 colou
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
c
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 sub
apparently fixed in upstream master now, just needs packaging :)
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 adw
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
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
- antialias
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.
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/include
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
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
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 f
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;
dis
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 /.dis
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 so
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
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
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: #95
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...
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
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 u
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
> > defau
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`.
Wa
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
>
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 h
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.
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
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 De
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 r
For the record - I also did not realised until it was pointed out that
apt has it's own user account.
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,
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 directo
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 thi
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'
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.
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'
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 nice
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
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
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,
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-
alternati
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
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.
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
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
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/i
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
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
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 ne
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
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
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
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.
pat
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
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 effor
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
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
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.
fu
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
useful
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 h
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
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
finish
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, t
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
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 sens
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)
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)
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)
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 an
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.
patc
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 s
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)
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 te
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
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)
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 onl
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)
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 w
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)
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)
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 sa
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)
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)
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)
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 f
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
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.
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)
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)
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.
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)
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)
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
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
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 (conf
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 ad
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)
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)
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)
1 - 100 of 329 matches
Mail list logo
