Bug#1071227: busybox-udeb: provides binaries that are also provided by kmod-udeb (e.g. modprobe)
Package: busybox-udeb Severity: normal User: debian-rele...@lists.debian.org Hi, I notice that busybox-udeb provides the following binaries in /sbin: depmod insmod lsmod modinfo modprobe rmmod while kmod-udeb provides the same, except located in /usr/sbin. It would be better if this were not the case, especially now that D-I is /usr-merged, so one will presumably get to use whichever of those is unpacked last. This suggests to me that the versions from kmod-udeb should be used, and busybox-udeb should be configured to no longer generate these binaries. BTW I'm assuming that these binaries only make sense on Linux, so it's that it's fine that non-linux builds will not have them (kmod-udeb being linux only). Cheers, Phil.
Bug#1070795: xfsprogs-udeb: the udeb is empty (size 904 bytes) so does not contain mkfs.xfs
Package: xfsprogs-udeb Version: 6.7.0-2 Severity: grave User: debian...@lists.debian.org Usertags: openqa Hi, Recent openQA tests show that it is not currently possible to create an XFS filesystem using the latest debian-installer: https://openqa.debian.net/tests/259699#step/install_base/13 Looking into this, I note that the 6.7.0-2 udeb is empty: $ ls -l xfsprogs-udeb_6.7.0-2_amd64.udeb -rw-r--r-- 1 phil phil 904 May 8 00:02 xfsprogs-udeb_6.7.0-2_amd64.udeb $ dpkg-deb -c xfsprogs-udeb_6.7.0-2_amd64.udeb drwxr-xr-x root/root 0 2024-05-07 22:53 ./ which explains why mkfs.xfs is not available in the installer at present. Cheers, Phil.
Bug#1065951: patch applied as MR!6
Hi, Just in case it helps, I've applied Michael's patch, and opened an MR on salsa: https://salsa.debian.org/virtualsquare-team/vde2/-/merge_requests/6 Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Bug#1067516: util-linux: sulogin should not render system inaccessable in single-user/emergency mode
Package: util-linux
Severity: normal
The D-I team are just about to reword the root password prompt in a way that
will likely lead to more people taking the chance to lock root and rely upon
sudo from the initial user. This is something that's already possible, so this
wording change is at most going to increase the popularity of this option.
At present, this results in sulogin becoming useless (unless one reconfigures
it), because it prompts the user for a password that does not exist.
This situation prompted this MR against user-setup (in D-I):
https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6
however it occurs to me that even if we adopt this, it does nothing to address
existing installs.
BTW That MR offers to configure things so that a locked root account will cause
sulogin to fail open, dropping the user into a root shell without asking for a
password.
While thinking about this, it occurs to me that one might be able to add an
option to sudo (-g perhaps) that would allow one to specify a group that should
be treated as a proxy for root when root's password is locked. Then, if that
option were specified, the users in the specified group ('sudo' on Debian) could
be allowed to specify their password instead, and if the password were correct,
be only then given root on the system. I guess one could either just check
against all group members for a match, or add a prompt for the username too.
This bug is therefore in two parts:
1) ask users how they want this configured, if they have a locked root
account, and have not been asked about it yet.
2) implement the mentioned -g option, or come up with some other way of
enabling the user to login during a single/emergency boot, without simply
dropping the user straight into a root shell.
Cheers, Phil.
Bug#1064617: update password selection advice
Holger Wansing writes: > Apparently we have reached something like a consensus on this topic, > should we merge this then? > > <https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7> > > Any objections? None from me. The only reason I've not done it already was that I wanted to check that the wording still works if we were to merge MR !6 [1] or something like it. However the current t64 transition bugs stopped me from building a mini-ISO, and I've been busy since noticing that, so didn't have time to work out how to work round those bugs. That's not a reason to delay this MR though. Cheers, Phil. [1] https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6 > > > Holger > > > -- > Sent from /e/ OS on Fairphone3 > -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Justin B Rye writes: > Philip Hands wrote: >>> Maybe instead of saying "use the system's initial user account to >>> become root" it should say "allow the system's initial user account >>> to gain administrative privileges"? I'm not sure. Oh, and we might >>> even want to mention the word "superuser", or then again we might not. >> >> I think Diederik's suggestion of using 'root' for the account and >> 'super-user' for the privileges might be the way to go. > > Looking at what I end up with after another couple of rounds of > fiddling with it I'm not sure if it's doing quite what you asked for, > but you still might want it so here it is: Thanks for that. > - Some account needs to have system administrative privileges. The > - password/passphrase for that account should be something that > - cannot be guessed. > + Some account needs to be available with administrative super-user > + privileges. The password/passphrase for that account should be > + something that cannot be guessed. > . > To allow direct password-based access via the 'root' account, you > can set the password/passphrase for that account here. > . > - Alternatively, you can lock root's password > + Alternatively, you can lock the root account's password > by leaving this setting empty, and > instead use the system's initial user account > (which will be set up in the next step) > - to become root. This will be enabled for you > - by adding that user to the 'sudo' group. > + to gain administrative privileges. This will be enabled for you by > + adding that initial user to the 'sudo' group. > . > Note: what you type here will be hidden (unless you select to show it). That can be seen here: https://salsa.debian.org/philh/user-setup/-/commit/a684977100e6746725372f8294f271f890c50430 & https://openqa.debian.net/tests/240580#step/passwords/1 I think I prefer the previous version better for some reason. IMO Having the 'password/passphrase' throughout makes it awkward to read, and actually we've got one place where it still just says password, and fixing that would make it slightly worse IMO. How about dropping the passphrase stuff? https://salsa.debian.org/philh/user-setup/-/commit/7c8dd1bd9d5c8596e7b8f82a19a075e0a5572ed7 & https://openqa.debian.net/tests/240582#step/passwords/1 which I think is more readable (and is probably fine now that we've dropped the stuff about password selection which could be read as suggesting that a password is expected to be a single word). Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Justin B Rye writes: ... > Post-coffee (also fixing that wobbly indent): > >Some account needs to have system administrative privileges. The >password/passphrase for that account should be something that >cannot be guessed. >. >To allow direct password-based access via the 'root' account, you >can set the password/passphrase for that account here. >. >Alternatively, you can lock root's password >by leaving this setting empty, and >instead use the system's initial user account >(which will be set up in the next step) >to become root. This will be enabled for you >by adding that user to the 'sudo' group. >. >Note: what you type here will be hidden (unless you select to show it). I like that version better than mine, so commited it[1], and re-ran the test to give a screenshot: https://openqa.debian.net/tests/239766#step/passwords/1 > Maybe instead of saying "use the system's initial user account to > become root" it should say "allow the system's initial user account > to gain administrative privileges"? I'm not sure. Oh, and we might > even want to mention the word "superuser", or then again we might not. I think Diederik's suggestion of using 'root' for the account and 'super-user' for the privileges might be the way to go. Cheers, Phil. [1] https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7/diffs?commit_id=2668d06de4f2de4735404a0671ecfb33f7bbd159 -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Justin B Rye writes: > Philip Hands wrote: >> Justin B Rye writes: >>> Philip Hands wrote: >>>> Justin B Rye writes:> ... >>>> The reason behind that structure was supposed to be that one definitely >>>> needs _a_ password, but not necessarily a root password, so the password >>>> advice applies to whichever password you'll decide to grant root access >>>> to, which might not be set here. >>> >>> This template is specifically about the "Root password/passphrase"; >> >> Well, sort-of, except that the user's response (whether to leave this >> blank or not) modifies what happens with the user account's permissions, >> so it's also about explaining the way that logic works in the installer >> and what that will do to the target system. >> >>> probably I should have quoted the patch I was looking at, which starts >>> with "One needs a password/passphrase that grants access to the 'root' >>> (system administrative) account" but goes on to say "Alternatively, >>> you can lock root's password by leaving this setting empty". >> >> I'm intimately familiar with the patches you're reading, so I feel like >> this comment suggests that we may be talking past one another somehow. > > Yes, this is a common problem: you're so familiar with what we need > it to say that you aren't noticing what the text currently does say. > https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7 > > Template: passwd/root-password > Type: password > # :sl1: > _Description: Root password/passphrase: >One needs a password/passphrase that grants >access to the 'root' (system administrative) account. >Be aware that a malicious or unqualified user >that obtains root access can have disastrous results, >so you should choose a password/passphrase that cannot be guessed. >It should not be a word found in dictionaries, >or something that could be easily associated with you. > > (Summary: You DO need a root password.) No, as I said, what that's trying to say is that there needs to exist a password that one way or the other will let one get access to the root account (since otherwise one is not going to be able to admin the machine), but that is not neccesarily the same thing as a "root password", because the password being refered to might well be the initial user's password, as long as they end up in the sudo group. If it comes across as meaning that there needs to be a "root password", then it's not succeeding in expressing the nuance of the situation correctly, and we probably need to fix that (assuming that we can come up with a better wording that still fits in the space available). >. >To allow direct password-based access to root, >you should set the 'root' password/passphrase here. >. >Alternatively, you can lock root's password >by leaving this setting empty, and >instead use the system's initial user account >(which will be set up in the next step) >to become root. This will be enabled for you >by adding that user to the 'sudo' group. >. >Note: what you type here will be hidden (unless you select to show it). > > (Summary: You DON'T need a root password.) > > Suggested rewrite (short version): > > _Description: Root password/passphrase: > To allow direct password/passphrase-based access to the 'root' > (system administrative) account you can set it up here. > To protect your system you should not use one that can be guessed. > . > Alternatively, you can lock root's password >by leaving this setting empty, and >instead use the system's initial user account >(which will be set up in the next step) >to become root. This will be enabled for you >by adding that user to the 'sudo' group. >. >Note: what you type here will be hidden (unless you select to show it). This is certainly better than good enough, so I'd be fine with this too. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Justin B Rye writes: > Philip Hands wrote: >> Justin B Rye writes: ... >> >> The reason behind that structure was supposed to be that one definitely >> needs _a_ password, but not necessarily a root password, so the password >> advice applies to whichever password you'll decide to grant root access >> to, which might not be set here. > > This template is specifically about the "Root password/passphrase"; Well, sort-of, except that the user's response (whether to leave this blank or not) modifies what happens with the user account's permissions, so it's also about explaining the way that logic works in the installer and what that will do to the target system. > probably I should have quoted the patch I was looking at, which starts > with "One needs a password/passphrase that grants access to the 'root' > (system administrative) account" but goes on to say "Alternatively, > you can lock root's password by leaving this setting empty". I'm intimately familiar with the patches you're reading, so I feel like this comment suggests that we may be talking past one another somehow. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Justin B Rye writes: > Holger Wansing wrote: >> @d-l10n-english: hey guys, we would like to get a proposal reviewed, >> which aims to improve the root/user password screens in the installer. >> >> Please find the related merge request at >> <https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7> > > It needs a small amount of rephrasing, but the most important problem > is that it starts by saying you need to set a password and then goes > on to suggest that you might not need to set a password. Maybe that > can be fixed by rearranging things slightly... > > Template: passwd/root-password > Type: password > # :sl1: > _Description: Root password/passphrase: > To allow direct password/passphrase-based access to the 'root' > (system administrative) account you can set it up here. > The results can be disastrous if a malicious or incompetent user > obtains root access, so you should not set one that can be guessed, > found in dictionaries, or easily associated with you. > . > Alternatively, you can lock root's password > by leaving this setting empty, and > instead use the system's initial user account > (which will be set up in the next step) > to become root. This will be enabled for you > by adding that user to the 'sudo' group. > . > Note: what you type here will be hidden (unless you select to show it). > > Does this still feel like the same advice? The reason behind that structure was supposed to be that one definitely needs _a_ password, but not necessarily a root password, so the password advice applies to whichever password you'll decide to grant root access to, which might not be set here. I'm OK with the way you've phrased it, although my personal preference would be to simply drop the "disastrous" sentence if we use this version, because I think it breaks the straightforward flow of the text laying out the choice we're trying to get the user to make between the two available options. (I also rather doubt that anything we say at this point in the install will have the slightest influence on people's choice of password). > Otherwise the only thing I see is: > > Template: passwd/user-password > Type: password > # :sl1: > _Description: Choose a password/passphrase for the new user: > Make sure to select a strong password/passphrase, that cannot be guessed. > > No comma needed there. Well done -- I kept noticing that, and somehow didn't get round to fixing it. I've now deleted it, so thanks for pointing it out again. :-) Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Cyril Brulebois writes: > Philip Hands (2024-03-05): >> Cool, in that case I'll fix those two things and then use the result >> for the MR[1], and if the openQA test runs look OK, will merge that. > > Only skimmed over it, but that looks sensible, thanks all. > > Is it worth getting d-l-english involved in a final review before > getting that translated? Contrary to a lot of not-so-critical l10n > material, that particular screen is crucial, and I'd hate it if we > wasted translator efforts due to a missed typo or obvious improvement. I'm happy with doing that, and we might as well get it right given that it's been ~12 years since the first bug, so a few more days makes no odds. I'm pretty sympathetic with the idea of simply dropping the password advice (as just mentioned by Diederik) but it seems that Holger prefers to keep it in -- either is fine with me. BTW I don't know much about how the translation side of things works, but given that there are many ways of getting the fine detail of this to be incorrect in various ways, is there a standard method for adding hints for translators, and should that be done? Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Holger Wansing writes: > Hi, > > Am 5. März 2024 15:01:21 MEZ schrieb Philip Hands : >>Here are my latest attempts: > > "Be aware that that a ..." > doubled "that" > > "... (unless you select to show it)" > missing fullstop. Well spotted - Thanks :-) > Otherwise: looks good to me. Cool, in that case I'll fix those two things and then use the result for the MR[1], and if the openQA test runs look OK, will merge that. Cheers, Phil. [1] https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7 -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Holger Wansing writes: > Hi, > > Am 2. März 2024 21:07:34 MEZ schrieb Philip Hands : >> >>This sentence is the thing that prompted me to change things in the >>first place, because it is not true. One does not _need_ to set a root >>password. > > It should be understood as > "If you want to enable login as root, you have to set a root password now." > > And in expert mode it is in fact working this way: > At first, you are asked if you want to enable login as root. If you answer > yes > here, you are prompted to set a root password. > And at that point it is indeed required to set a root password, since you > chose to enable root login in the first question and the installer does not > allow an empty password for root. > > To make it work in default install, we could change the question as > in above citation. > >>I don't actually care very much whether we encourage sudo use. My >>wording ended up (after many variations) quite strongly encouraging it >>mostly as an antidote to the implication that comes from having a >>question dedicated to setting the root password, but I'd be happy with >>any wording that makes sure that people understand that both options are >>totally fine. > > The sudo possibility is also mentioned: > > 'The root user should not have an empty password. If you leave this > empty, the root account will be disabled and the system's initial user > account will be given the power to become root using the "sudo" > command.' > > I have rephrased that a bit, see below. > >>The other thing that I was trying to ensure is that people are reassured >>that they'll get to specify a password that will get them root access even if >>they decide to leave the root password unset. This is because I've seen >>people become quite uncertain about what to expect at this point in the >>install. >> >>I've found that it is not easy to come up with things that include much >>nuance about this, while still fitting in the space available, which is >>why I decided to try a more opinionated approach. >> >>One could soften what I wrote by replacing "generally recommended" with >>something like "often appropriate" -- how does that seem to people? > > Your proposal too much focusses on the sudo way IMO. > We risk getting complains from people, who miss advise regarding the > enabled root login. > > I have rephrased the dialog a bit, to make the sudo way more visible and > better understandable. > >>One can of course tinker with this stuff indefinitely. I actually spent >>a fair amount of time wondering how best to describe not setting a root >>password for instance -- should one say "leave the password unset", "set >>an empty password", "enter no password", or something like "just hit >>"? (and does that last one actually apply to all the available >>UIs?). >> >>The same goes for how you say that the password is not going to get >>shown (unless you ask for it to be shown), which in the GTK UI gets >>characters replaced with dots, IIRC in the text UI its with asterisks, >>and I'd guess it just gets completely hidden in the speech install. > > I think that's not much of a problem. People are used to the situation, > that passwords are not shown, but replaced by asterisks or similar. > And we have the checkbox for showing it in clear text, that should be > enough. > > > Updated patch attached. > > > Holger > > > > diff --git a/debian/user-setup-udeb.templates > b/debian/user-setup-udeb.templates > index cdb6d78..7393511 100644 > --- a/debian/user-setup-udeb.templates > +++ b/debian/user-setup-udeb.templates > @@ -34,21 +34,19 @@ Template: passwd/root-password > Type: password > # :sl1: > _Description: Root password: > - You need to set a password for 'root', the system administrative > - account. A malicious or unqualified user with root access can have > + If you want to allow login as root, you need to set a password for 'root', > + the system administrative account now. > + A malicious or unqualified user with root access can have > disastrous results, so you should take care to choose a root password > - that is not easy to guess. It should not be a word found in dictionaries, > - or a word that could be easily associated with you. > + that cannot be guessed. It should not be a word found in dictionaries, > + or something that could be easily associated with you. > . > - A good password will contain a mixture of letters, numbers and punctuation > - and should be changed at regular intervals. > + You can also leav
Bug#1064617: Passwords should not be changed frequently
Diederik de Haas writes: > Hi, > > On Friday, 1 March 2024 20:46:49 CET Holger Wansing wrote: >> Philip Hands wrote (Fri, 01 Mar 2024 06:46:27 +0100): >> > If you want to make a constructive contribution, how about suggesting a >> > wording that reflects the advice that you think would be most useful to >> > the people that actually read the advice? >> >> I would like to make a proposal, leaving the default setting as is >> (aka: default to an enabled root account, no sudo), with only some wording >> changings. >> >> Patch attached. >> >> What do you think? > > I think it's an improvement and I have some suggestions, which hopefully > makes > it even better. I don't have a git-diff, but hopefully this works too. > > I'm not a native English speaker or particularly good at this, so it's more > the direction then the exact wording that's important. Others can undoubtedly > improve upon it. > > _Description: Root password: > "You need to set a password for 'root', the system administrative account. This sentence is the thing that prompted me to change things in the first place, because it is not true. One does not _need_ to set a root password. I don't actually care very much whether we encourage sudo use. My wording ended up (after many variations) quite strongly encouraging it mostly as an antidote to the implication that comes from having a question dedicated to setting the root password, but I'd be happy with any wording that makes sure that people understand that both options are totally fine. The other thing that I was trying to ensure is that people are reassured that they'll get to specify a password that will get them root access even if they decide to leave the root password unset. This is because I've seen people become quite uncertain about what to expect at this point in the install. I've found that it is not easy to come up with things that include much nuance about this, while still fitting in the space available, which is why I decided to try a more opinionated approach. One could soften what I wrote by replacing "generally recommended" with something like "often appropriate" -- how does that seem to people? One can of course tinker with this stuff indefinitely. I actually spent a fair amount of time wondering how best to describe not setting a root password for instance -- should one say "leave the password unset", "set an empty password", "enter no password", or something like "just hit "? (and does that last one actually apply to all the available UIs?). The same goes for how you say that the password is not going to get shown (unless you ask for it to be shown), which in the GTK UI gets characters replaced with dots, IIRC in the text UI its with asterisks, and I'd guess it just gets completely hidden in the speech install. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Hi Diederik, You're probably right that it deserves a separate bug, but I was trying to avoid wasting the translators time by doing this in two steps, and forcing them to do the work twice. I cannot say that I have read the stuff in these dialogs (except when editing them) for at least 20 years, so tailoring the content of them for people like me seems like a mistake. I was therefore trying to put myself in the position of a person that's reading them for the first time, and perhaps a person that's installing Linux for the first time. Having helped people to install Linux for ~30 years, I'd say that it's the norm for people to be almost incapable of coming up with a decent password if they were not expecting the question. As I said, I'm happy to hear better suggestions, since I've had about 15 attempts at this so far, and every time I see the text rendered in the D-I screenshot, I end up not liking the result very much. If you want to make a constructive contribution, how about suggesting a wording that reflects the advice that you think would be most useful to the people that actually read the advice? If nothing like a consensus is available, then just removing the old advice seems like an OK place to end up too, which is why I went to the effort of splitting the commits. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Bug#1064617: Passwords should not be changed frequently
Pascal Hambourg writes: > On 25/02/2024 at 01:17, Matthew Wilcox wrote: >> >> I just did an installation with the 2024-02-24 >> debian-testing-amd64-netinst.iso image. I forget the exact wording >> used, but when setting up a user, d-i printed advice that user passwords >> should be changed frequently. This is no longer current good advice >> (since 2017): > > This topic has some history, see > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656509> > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868869> > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998408> > <https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7> It had not occured to me until Matthew's suggestion that we might simply remove the obsolete advice, rather than trying to improve the wording. In light of that, I've split the MR into 2 commits, the first of which removes the old advice (which hopefully inflicts the smallest possible load on our translators) and the second of which is an attempt to come up with something better (criticism welcome, I've had multiple attempts at this, so I imagine there's still room for improvement). Depending upon whether we think it's worth using translators' time on this subject, we can then select one or both commits, and finally close these bugs. You can see my latest attempt here: https://openqa.debian.net/tests/238094#step/passwords/1 in which I'm recommending setting no password for root, which then gives the initial user 'sudo' membership[1]. The slightly awkward thing about this recommendation is that it encourages people to put themselves in the situation that: https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6 is trying to address, so if we make this recommendation, we should also deal with that issue (which I think we should do anyway). Cheers, Phil. [1] This strikes me as decent advice for newbies, for whom this sort of guidance is most necessary. The problem with asking a newbie for a root password is that they're likely to choose a poor one. Even if they later realise that they should have choosen better passwords, they may well not at that point remember that they still have a useless password for root that needs updating. On the other hand, now that ssh defaults to not allowing password based logins to root, perhaps the potential presence of a poor password on a sudo enabled account should be of greater concern, since that will still be open to remote logins, so I can see that one could argue this either way. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1064624: Hard to short-stroke an encrypted drive
Matthew Wilcox writes: > Package: debian-installer > > The partitioner "guided partitioning" offers me: > > - use the largest continuous free space > - use entire disk > - use entire disk and set up LVM > - use entire disk and set up encrypted LVM > > I want "use largest contiguous space and set up encrypted LVM". > That would let me reserve 200GB of my SSD as unencrypted free space, > which will improve the write endurance of my SSD. Can one achieve this by telling LVM to allocate less than the full size of the device to the PV one puts on it? If one does that, I would guess that one could later extend the PV to use more/all of the disk using pvresize, so that those that prefer space over endurance could make that decission when they are running out of space. If that's all true, we could have a couple of preseed variables to set the percentage and maximum amount that would be left fallow for this purpose, and (eventually) set non-zero defaults when installing to SSD. Is that something like what you're after? Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'
Michael Tokarev writes: > 09.02.2024 16:58, ca...@allfreemail.net >> Package: console-setup >> Followup-For: Bug #1063518 >> >> Consider making all scripts provided by console-setup >> shellcheck-clean, there are lots of tiny issues that can turn into >> big issues under the right conditions. > > Please do not do this. Shellcheck is a huge problem and we had large amount > of bugs due to people trying to apply its suggestions. It's very difficult > in many cases to spot why shellcheck is wrong (classic is the suggestion to > put $var into double quotes "$var" which breaks badly if $var is supposed to > contain zero or more separate words - this way, even boot scripts has become > buggy leading to system becoming unbootable). > > Shellcheck is a very bad tool. I think the reality is somewhere between these two positions. Shellcheck is not particularly helpful for most of D-I because it doesn't have a shell variant that perfectly matches our busybox sh build. That might have just improved, since I notice that a busybox sh variant has just been merged upstream, so we'll see if that makes things better. On the other hand, if I'd been paying attention at the time, the fact that this change dropped the number of shellcheck reports for setupcon from 189 to 1 should have rung some alarm bells, but it seems that I've learnt to ignore the little '!' in my emacs status bar -- I'll have to keep an eye on that in future. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Anthony Iliopoulos writes:
> On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
...
>> error: invalid XFS directory entry.
...
> This issue exists independently of the large extent counter, and it is
> related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> fuzzing the XFS filesystem"). That's actually the issue described in
> #1051543.
Ah, yes -- good point.
> There's a proposed fix at [1], and it works as expected with that patch
> applied.
...
> [1]
> https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
I can confirm that having applied both patches:
https://salsa.debian.org/philh/grub2/-/pipelines/596346
it now succeeds at both installing grub, and then booting the system:
https://openqa.debian.net/tests/200503#details
Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil
signature.asc
Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Philip Hands writes: > Anthony Iliopoulos writes: > ... >> Yeap it is due to nrext64, I've submitted a patch to grub (should have >> cc'ed linux-xfs..) >> >> https://lore.kernel.org/grub-devel/20231026095339.31802-1-ail...@suse.com/ > > That certainly seems to fix this bug. ... but sadly that may not be the end of the story. I've persuaded D-I to use the patched grub version, and when testing it, it now gets past the previous failure to complete the install, but then fails to boot after the first reboot, as seen here: https://openqa.debian.net/tests/200160#step/_console_wait_login/7 where it drops to the 'grub rescue>' prompt, complaining that: error: file `/boot/grub/i386-pc/normal.mod' not found. if one types `ls (hd0,msdos1)/boot/grub/i386-pc` at that rescue prompt, it lists the files up to msdospart.mod and then says: error: invalid XFS directory entry. (BTW the directory seemed fine before the reboot, because I listed it) This makes me wonder: Could it be that the code within the grub components that get installed onto the disk also needs to be patched to understand the newer directory structure, and without that it is unable to read the whole directory, and thus fails to boot it? Cheers, Phil. P.S. If you want to try this for yourself, the test image used (that pulls in the patched grub) is to be found here: https://salsa.debian.org/philh/grub2/-/jobs/4865564/artifacts/file/debian/output/debian-202306XX+ABI~6.5.0~3+salsaci+20231029+21-amd64-gtkmini.iso and adding `partman/default_filesystem=xfs` on the kernel command line before booting into D-I will get it to default to using XFS. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Anthony Iliopoulos writes: ... > Yeap it is due to nrext64, I've submitted a patch to grub (should have > cc'ed linux-xfs..) > > https://lore.kernel.org/grub-devel/20231026095339.31802-1-ail...@suse.com/ That certainly seems to fix this bug. I tested it by applying that patch to grub, and then getting that version of grub installed into the target just after the initial attempt to run grub had failed, which then allows a retry of the grub install step to succeed. Also, with the patched version: `grub-probe -d /dev/vda1` produces 'xfs' Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
"Darrick J. Wong" writes: ... > Curiously, this log says: > > Oct 24 05:35:32 in-target: Setting up xfsprogs (6.4.0-1) ...^M > > So ... is it running 6.4 and not 6.5? The daily test versions of Debian-Installer draw components from "unstable", which is where the 6.5 version is at present, which then creates the file system with problematic flags. However, the test images normally install "testing" onto the target, to avoid pointless breakage caused by the potential for "unstable" to be, well ... unstable, hence the 6.4 version that gets put in-target. Having 6.4 in the target system doesn't help in this case, because the damage has already been done while creating the file system, by the 6.5 version of the udeb. One can confirm that this is the case by looking for xfsprogs in here: https://openqa.debian.net/tests/198911/logfile?filename=complete_install-DI-installed-pkgs.txt which lists the installed components (udebs) of the installer that's running: xfsprogs-udeb 6.5.0-1 Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Philip Hands writes: ... > Could this be related to #1051543? > > I'll try testing D-I while using the patch from that bug, to see if that > helps. It seems (to me at least) that the patch there does not apply usefully to the version we're talking about, so I'll leave it to people that know more about grub & XFS to look further. =-=-= BTW the jobs where this failure first occured are: (BIOS) https://openqa.debian.net/tests/198911 (UEFI) https://openqa.debian.net/tests/198912 and the immediately previous working jobs are these: (BIOS) https://openqa.debian.net/tests/198840 (UEFI) https://openqa.debian.net/tests/198841 In the jobs you can see a 'Logs & Assets' tab, where you can find e.g. the syslog from the D-I run. Here's the one from the first BIOS failure: https://openqa.debian.net/tests/198911/logfile?filename=DI_syslog.txt One thing I notice when comparing that to the matching successful log: https://openqa.debian.net/tests/198840/logfile?filename=complete_install-DI_syslog.txt is that they both include a block of lines like: grub-installer: Unknown device "/dev/vda1": No such device so that's just noise by the looks of it, since it was also saying that when it was working. I've since slightly reorganised the openQA jobs, to have a job that only differs from the normal minimal install by the selection of XFS, so if you want to see currently failing jobs, they will be the ones called nonGUI_XFS@64bit & nonGUI_XFS (for BIOS & UEFI installs, respectively) in this overview: https://openqa.debian.net/tests/overview?distri=debian=10 HTH Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Package: xfsprogs-udeb Version: 6.5.0-1 Severity: serious User: debian...@lists.debian.org Usertags: openqa While doing openQA testing of Debian-Installer, I notice that XFS installs started failing a few days ago, and comparing the versions of udebs that changed between success and failure, the only likely candidate is xfsprogs-udeb, which has a version of 6.4.0-1 in the last working test, and 6.5.0-1 in the first failing one. I've also built the latest D-I with 6.4.0-1, and that restores it to a working condition. I note that if one runs e.g.: grub-probe -d /dev/vda1 at the moment of failure, the XFS filesystem is not recognised (despite being mounted as XFS at that moment). Could this be related to #1051543? I'll try testing D-I while using the patch from that bug, to see if that helps. Cheers, Phil.
Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1
Luca Boccassi writes: > On Sat, 23 Sept 2023 at 14:29, Simon McVittie wrote: >> >> On Wed, 30 Aug 2023 at 16:27:12 +0100, Simon McVittie wrote: >> > [ Reason ] >> > Part of the transition to merged-/usr, and more specifically, allowing >> > us to stop shipping files in trixie whose physical path on disk does >> > not match their path in the dpkg database due to directory aliasing. >> > >> > This change needs to be in bookworm (and bullseye, and maybe buster) >> > before that process can continue, because official buildds run debootstrap >> > from stable (or older). >> > >> > I also took the opportunity to backport changes that make the autopkgtests >> > pass. >> > >> > [ Impact ] >> > If not accepted, trixie will continue to be stuck in a >> > mostly-but-not-entirely merged-/usr limbo, with the moratorium from >> > #1035831 >> > remaining in place. >> >> I'm aware that we're getting close to the deadline for 12.2 and 11.8, >> so I've uploaded the proposed version to bookworm-proposed-updates for >> easier testing and review. Luca: the proposed version and a signed tag >> are available from my fork on salsa (I am not able to push to the d-i >> repository for debootstrap). I uploaded with dgit, so the git tree and >> the .dsc have been verified to be identical. >> >> If this version is not accepted for whatever reason, then I think we >> should treat version 1.0.128+nmu2+deb12u1 as having been used, and skip >> ahead to 1.0.128+nmu2+deb12u2 for any subsequent bookworm update. >> (And if there is a problem with having this version in bookworm-pu for >> whatever reason, I'm happy to upload a +deb12u2 that is identical to >> 1.0.128+nmu2 except for the changelog.) > > Thank you, pushed both branches. > > Release Team, we are aware that you requested an explicit review from > D-I for this and #1025708, however there are no available reviewers, > so it appears we are deadlocked. Would you please consider waiving > this requirement to break the deadlock? > Philip Hands has confirmed on Salsa that the change has been tested > with OpenQA and everything still works: > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/105#note_429838 Just thought I'd mention that those tests were for current unstable. As mentioned in: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/105#note_430223 my attempts to test the same change in bullseye have not yet worked out, because bullseye's D-I is missing the features that were recently added to D-I in order to allow one to add a test repo from which D-I can obtain modified udebs (such as debootstrap). I'll ought to be able to sort out tweaked versions of net-retriever & anne for bullseye, in which case a test should be possible. I'm somewhat dubious that such a test is going to tell us anything interesting though. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1052448: kmail: Account Assistant window can be covered by main Kmail window
Package: kmail Version: 4:22.12.3-1 Severity: minor Hi, While performing automated tests of KDE with openQA (on openqa.debian.net) it has been observed that Kmail, on first run, can end up looking like this: https://openqa.debian.net/tests/190198#step/kmail/5 in case that link rots at some point, I'll also do some ASCII art: +- Account Assistant --+ | | +- Kmail --+ | | ... | | +--+ |[Help] [Back] [Next] [Finish] [Cancel]| +--+ I guess that for a normal user, it's generally going to be obvious that they need to click the Account Assistant window to get it back on top. For our automated testing, luckily the 'cancel' button is still visible, so we get to click on the lower window to get rid of it, and can continue. Despite that, I'd have thought that it would be better to insist on the account assistant staying on top. Cheers, Phil.
Bug#1052377: gdm3: less than beautiful word-wrap decision seen in failed authentication message.
Package: gdm3 Version: 45~beta-1 Severity: wishlist Hi, While testing Gnome installs using openQA I noticed that if providing the wrong password, one is shown a message that is word-wrapped in an awkward manner: Sorry, password authentication didn't work. Please try again. you can see a screenshot of that here: https://openqa.debian.net/tests/190043#step/_graphical_wait_login/9 I would suggest that whatever is deciding to wrap that text could be improved to prefer balancing the number of words in the two lines somewhat better, and to prefer doing line breaks after punctuation, in order to obtain a result like: Sorry, password authentication didn't work. Please try again. Even if it just did the most simple-minded thing: choosing to wrap as soon after the middle of the string that it finds white-space, that would look better IMO: Sorry, password authentication didn't work. Please try again. I'm sure that this bug actually exists in some library that gdm3 uses, so please reassign it as appropriate. I am aware that this is completely trivial (hence wishlist), but doing QA testing tends to make one notice such things, and I'm sure that whatever is making that line-break decision is making equally poor decisions in many other places, and in other translations, and that the whole user experience might be (very slightly) improved if it did a better job. Cheers, Phil.
Bug#1051468: cannot install BIOS machine with mini.iso, error creating /target/sys/firmware/efi/efivars
Hi Edward, Edward Little writes: > Please remove the following email address: e.little...@gmail.com I guess that you're subscribed to the debian-boot mailing list. If so, you'll have seen copies of the mails seen here: https://lists.debian.org/debian-boot/2023/09/threads.html in which case you can unsubscribe here: https://lists.debian.org/debian-boot/ Since I'm looking at that page, I've done that for you (you should already have a confirmation mail) BTW every email forwarded by the debian mailing list system includes a footer with links to unsubscription instructions, just in case you're on other lists you don't want to be on. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1051468: cannot install BIOS machine with mini.iso, error creating /target/sys/firmware/efi/efivars
Marc Haber writes: > On Fri, Sep 08, 2023 at 03:48:25PM +0200, Pascal Hambourg wrote: >> On 08/09/2023 at 13:56, Marc Haber wrote : >> > I tried installing sid from mini.iso into a libvirt/qemu/kvm VM with >> > BIOS "firmware", choosing mainly default values, and ended up with the >> > system logging "grub-installer: error: Error creating >> > /target/sys/firmware/efi/efivars" and an error message "Failed to mount >> > /target/proc, Mounting the proc file system on /target/proc failed". >> >> This issue has been discussed in #1031183 starting from >> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031183#17> >> (it is a different issue from the original bug report, so a separate bug >> should have been filed) and a merge request is in progress. >> <https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19> > > Loooks like the same issue, happens also with a regular netinst install. If you'd like to test the result of building that merge request into a mini.iso, you can give it a go with this: https://salsa.debian.org/philh/grub-installer/-/jobs/4675763/artifacts/file/debian/output/debian-202306XX+salsaci+20230908+294-amd64-gtkmini.iso which was built in this pipeline: https://salsa.debian.org/philh/grub-installer/-/pipelines/577147 where you will find links to the commit & branch that's from. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#998408: "good password" advice in installer is still bad two years after this was reported
Jonathan Kamens writes: > Oh, I see now that the fact that the installer shouldn't recommend > changing one's password regularly was also reported previously, in bug > #868869. Also, in #656509 (in which Cyril states that the effort of translating a new message outweighs the importance of the change). I've no idea if that justification for inaction still stands, but I thought this would make a nice little example for the use of the salsa-CI pipeline (and my branch2repo variant of that), so here's an MR: https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7 and here's a screenshot of what the change looks like: https://openqa.debian.net/tests/185853#step/passwords/1 I'm not 100% happy with the wording (and the underlines around 'should' need to go) so I'm very likely to tweak it tomorrow. Suggestions for improvement welcome, although be aware that given the resistance to fixing this in the past, it's always possible such a change will also be deemed unjustified now. I think it's probably about time we fixed it, since even the civil servants in the UK have stopped recommending password changes by now, and they tend to make such changes at least a decade late. ;-) Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1050924: dgit: allowed a push-source for a version that already exists in the archive
Package: dgit Version: 10.7 Severity: important Hi, Following on from an IRC chat with Ian, I'm submitting a bug as requested. In a moment of inattention[1], I seem to have found myself in a git "master" branch that was sitting on release 1.109 of the `preseed` package (whereas the latest release is in fact 1.119) I then cherry-picked the changes that I should have been aiming at 1.120, ran gbp dch to generate 1.110, failed to spot anything awry, and since this was to be the first dgit upload of `preseed` (a native package), I then ran: dgit -wgf --deliberately-not-fast-forward push-source as per dgit-main-native(1). This cheerfully did the push, including a `debian/1.110` tag. Of course the thing it tagged as debian/1.110 is not the same thing as the actual `1.110` release (which was from Jan 2022). Prior to doing any of this, https://browse.dgit.debian.org/?q=preseed showed "No repositories found". I think it _may_ also have said that just after the push. Once I did a dgit clone, the listing appeared, and the git history in the clone showed me that it had stitched together my bogus-1.110 with the 1.119 version that it presumably generated in order to satisfy my clone request. There seems to share some features with https://bugs.debian.org/1050711 Cheers, Phil. [1] perhaps due to a dyslexia-related occasional inability to distinguish things such as: 1.109 vs. 1.119. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (99, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dgit depends on: ii apt2.6.1 ii ca-certificates20230311 ii coreutils 9.1-1 ii curl 7.88.1-10+deb12u1 ii devscripts 2.23.4 ii dpkg-dev 1.21.22 ii dput 1.1.3 ii git [git-core] 1:2.39.2-1.1 ii git-buildpackage 0.9.30 ii libdpkg-perl 1.21.22 ii libjson-perl 4.1-1 ii liblist-moreutils-perl 0.430-2 ii liblocale-gettext-perl 1.07-5 ii libtext-csv-perl 2.02-2 ii libtext-glob-perl 0.11-3 ii libtext-iconv-perl 1.7-8 ii libwww-curl-perl 4.17-10 ii perl [libdigest-sha-perl] 5.36.0-7 Versions of packages dgit recommends: ii distro-info-data 0.58 ii liburi-perl 5.17-1 ii openssh-client [ssh-client] 1:9.2p1-2 Versions of packages dgit suggests: ii sbuild 0.85.0 -- no debconf information
Bug#1050887: endlessh.service includes unhelpful instructions for listening on low ports
Package: endlessh Version: 1.1-5 Severity: normal Dear Maintainer, In `/lib/systemd/system/endlessh.service` there is this comment: ## If you want Endlessh to bind on ports < 1024 ## 1) run: ## setcap 'cap_net_bind_service=+ep' /usr/local/bin/endlessh ## 2) uncomment following line #AmbientCapabilities=CAP_NET_BIND_SERVICE ## 3) comment following line PrivateUsers=true which isn't very helpful, since the README instructs one to do the much preferable: systemctl enable --now endlessh@222.socket BTW I started out this bug pointing out that /usr/local/bin is the wrong path, and suggesting that socket activation would be much preferable, before noticing that actually, that's already what the README's suggesting. The comment should probably just be removed, or replaced with something like: # to run Endlessh on alternative ports, see: /usr/share/doc/endlessh/README.Debian oh, actually, not quite ... I notice that the endlessh@.socket file appears to be missing at present, so that would need to be added to the package first. Cheers, Phil.
Bug#1050001: Unwinding directory aliasing [and 3 more messages]
Helmut Grohne writes: ... > As such, my expectation is that moving from where we are to your idea > is not any easier than moving from a post-DEP-17 state. Therefore, I > do not see any need to delay DEP-17 work. I've been wondering about this possibility too. If a symlink flowerbed is where we decided we wanted to end up, I get the impression that starting from post-DEP-17 would be rather easier than starting from where we are now. DEP-17 provides us with a detailed roadmap for the first leg of that trip, whereas the route via reversion seems to be littered with unknowns at present. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted
Philip Hands writes: ... > However, I am now wondering whether we might not be better off using > `archdetect` to see if we're on an efi system, and then make the attempt > to call mountvirtfs for the efivarfs conditional on that. After a diversion[1], I had a look at the archdetect option, and have discovered that this simple patch: https://salsa.debian.org/philh/grub-installer/-/commit/6f33bd183d7d0ced76958440534407dc9d0ad141 fixes the UEFI boot, without breaking the BIOS boot (on amd64 at least, while doing a minimal install): https://openqa.debian.net/tests/overview?version=testing=--20230820_1958_salsa=debian I hope/assume that all the arches that need this have the good grace to return `efi` as their subarch. If there's any risk that's not the case, we could also apply the previous patch. If you want to do your own tests, the mini.iso can be downloaded via: https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso BTW that's in the artifacts of the `mini-ISO` job, which can be found by looking at the pipeline linked from the commit above[2], and looking to the right for the Downstream pipelines -- further right you can find links to the openQA jobs above. Cheers, Phil. [1] rewriting branch2repo so that it doesn't need a state repo. for many use-cases, which will hopefully allow anyone to run these D-I tests on salsa, without any special setup. [2] https://salsa.debian.org/philh/grub-installer/-/pipelines/567684 -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
Steve McIntyre writes: > On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote: >>Hi Michael, >> >>Cyril Brulebois (2023-06-28): >>> Control: reassign -1 busybox-udeb 1:1.36.1-3 >> >>[…] >> >>> With a local build, confirmed -3 is buggy, and that reverting only >>> busybox-udeb to -1 is sufficient to restore syslog support in the >>> installer. >>> >>> Reassigning there; the GRUB thing can be filed separately once we have >>> actual information via syslog. >> >>A fix would be appreciated, we've got reports piling up about things we >>have no logs for. > > After weeks with this breakage, I've just uploaded a minimal NMU to > fix it, reverting the syslog changes since -1. I've buit and tested > successfully locally. Thanks -- and I agree, it works :-) https://openqa.debian.net/tests/178534/logfile?filename=DI_syslog.txt As it happens, over the weekend it occurred to me that I might be able to pave the way to a fix for this bug by coming up with a test for the failure. Awkwardly, syslogd wants to open /dev/log and bails out if it's already in use, so I resorted to (the somewhat disgusting hack of) using podman: https://salsa.debian.org/philh/busybox/-/commit/2697f7cce81d1a70de202a30e7062dc9f64a94b1 At least it allows syslogd to run well enough to succeed or fail similarly to the behaviour seen in the bug. Here it is going wrong with the -3 code: https://salsa.debian.org/philh/busybox/-/jobs/4523822#L3963 (lines 3969-3975, with the last line showing the entire syslog) and here is an example of it going right: https://salsa.debian.org/philh/busybox/-/jobs/4523808#L3668 Line 3668 here, saying "PASS: syslogd-works" indicates that we succeeded in grepping the test string in /var/log/syslog The difference between these two is simply disabling CONFIG_FEATURE_REMOTE_LOG, as seen here: https://salsa.debian.org/philh/busybox/-/commit/89c253f75690dd41487b6fd6f9356a1e890a6ac2 I'm not proposing that as a fix, but it does seem to indicate where the problem may be located. I'm afraid I've failed to work out what's actually going wrong here (my C's pretty rusty). BTW At one point I thought I'd narrowed it down to the while loop here: https://salsa.debian.org/philh/busybox/-/commit/328fdfbe43cd8d9e4425c3ee1c68aadfa44ee434 but if that did work, it does no longer. Either I was mistaken about it having worked earlier (I'm at least 80% sure that's not the case) or something non-deterministic is going on ... which makes me wonder if the underlying cause might be something to do with using uninitialised data somewhere. Hopefully this will be of some use to those more familiar with the code. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted
Arnaud Rebillout writes: > Tentative fix, for what it's worth: > > https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19 The original code there seems a bit tangled, and the need to check for efivarfs in two places seemed suboptimal, so here's an attempt to improve on it, including making the displayed error less misleading: https://salsa.debian.org/philh/grub-installer/-/commit/f14c5e70 [ It didn't seem worth distinguishing between the mkdir or the mount failing on-screen, so I've just logged that instead, and having done that, since there would only be one call to die() and I'd need to pass extra parameters for the error substutions, I just got rid of die() and put the code inline instead. ] To see what that looks like, I temporarily disabled the efivarfs test: https://salsa.debian.org/philh/grub-installer/-/commit/fcb794f6 then one gets to see this error: https://openqa.debian.net/tests/176310#step/grub/5 =-=- However, I am now wondering whether we might not be better off using `archdetect` to see if we're on an efi system, and then make the attempt to call mountvirtfs for the efivarfs conditional on that. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages
Package: rootskel Version: 1.135 Severity: normal Tags: patch Hi, One can see the symptoms by looking here: https://openqa.debian.net/tests/151286 the orange "Soft Failed" boxes highlight some of the failing screens, where the failure can be seen in the screenshot immediately preceeding the "Soft Failed" I'll attach an example to save people from having to follow that link. Apparently, this MR fixes the problem: https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8 Although this does prompt the question of why aarch64 has TERM set to 'vt102' at this point, rather than 'linux'. Also, I wonder whether there could be other circumstances when $TERM is set to 'vt102' where this change could be problematic (I'm guessing that the $TERM_TYPE checks deal with that, but I'm not sure). BTW This seems to have some overlap with #263137. Cheers, Phil.
Bug#1014943: waybar: fork-awesome alternatives
Package: waybar Version: 0.9.17-2 Followup-For: Bug #1014943 Dear Maintainer, I also hit this bug. As mentioned Fork Awesome is available in Debian, so instead of these: 0xf76b temperature-low 0xf769 temperature-high one can use these: https://forkaweso.me/Fork-Awesome/icon/thermometer-empty/ 0xf2cb fa-thermometer-empty https://forkaweso.me/Fork-Awesome/icon/thermometer-full/ 0xf2c7 fa-thermometer-full For my own setup, I've also changed the brightness config, thus: // "format-icons": ["", "", "", "", "", "", "", "", ""] "format-icons": ["", ""] using these: https://forkaweso.me/Fork-Awesome/icon/sun/ https://forkaweso.me/Fork-Awesome/icon/sun-o/ (I've no idea what the original series of icons were supposed to be indicating, but those two at least give one something that is brightness related, which seems like a step forward.) Oh, and I've just noticed that I'm yet to find an alternative for whatever the symbol is meant to be when one is charging the battery. Cheers, Phil. -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing'), (99, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages waybar depends on: ii init-system-helpers 1.65.2 ii libatkmm-1.6-1v52.28.3-1 ii libc6 2.36-9 ii libcairomm-1.0-1v5 1.14.4-2 ii libdate-tz3 3.0.1+ds-5 ii libdbusmenu-gtk3-4 18.10.20180917~bzr492+repack1-3 ii libevdev2 1.13.0+dfsg-1 ii libfmt9 9.1.0+ds1-2 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-2 ii libglibmm-2.4-1v5 2.66.5-2 ii libgtk-3-0 3.24.37-2 ii libgtk-layer-shell0 0.8.0-1 ii libgtkmm-3.0-1v53.24.7-1 ii libinput10 1.22.1-1 ii libjack-jackd2-0 [libjack-0.125]1.9.21~dfsg-3 ii libjsoncpp251.9.5-4 ii libmpdclient2 2.20-1+b1 ii libnl-3-200 3.7.0-0.2+b1 ii libnl-genl-3-2003.7.0-0.2+b1 ii libpulse0 16.1+dfsg1-2+b1 ii libsigc++-2.0-0v5 2.12.0-1 ii libsndio7.0 1.9.0-0.3+b2 ii libspdlog1.10 [libspdlog1.10-fmt9] 1:1.10.0+ds-0.4 ii libstdc++6 12.2.0-14 ii libudev1252.6-1 ii libupower-glib3 0.99.20-2 ii libwayland-client0 1.21.0-1 ii libwireplumber-0.4-00.4.13-1 ii libxkbregistry0 1.5.0-1 waybar recommends no packages. Versions of packages waybar suggests: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 pn libappindicator3-1 ii sway1.7-6 -- no debconf information
Bug#913431: Debian Installer Bullseye RC 2 release
Hi Vincent,
I've applied your patch and pushed it to to salsa (my fork) to get it
built by CI ... which failed, because of the use of ${X/...} and
${X:...}, which it seems busybox doesn't like.
So I've changed that code, and added a couple of other tweaks, as you
can see here:
https://salsa.debian.org/philh/partman-base/-/commits/bug/913431
Perhaps you can look at the result, and check that it still does what
you intended, and pick anything you like out of the rest.
BTW the working pipeline build includes the creation of a mini-ISO image
(once one kicks branch2repo into action), that should allow this code to
be tested in D-I:
https://salsa.debian.org/installer-team/debian-installer/-/jobs/4087808/artifacts/file/public/gtk-mini.iso
HTH
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#1031195: os-autoinst: FTBFS on several release architectures
Control: reopen -1 It seems that the initial attempt to fix this bug was a failure, so I'm reopening the bug and will attempt to do a proper job shortly. Cheers, Phil.
Bug#1026027: graphical installer: using nano in a installer shell fails
Control: tags -1 + pending Sven Joachim writes: ... > I have attached the obvious patch. Here's your patch: https://salsa.debian.org/philh/debian-installer-utils/-/tree/sven-bug/102602 which generates this mini ISO: https://salsa.debian.org/installer-team/debian-installer/-/jobs/3960725/artifacts/file/public/gtk-mini.iso wherein the bug is fixed. That being the case, I've pushed it into the master branch. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#993155: O: ssh-askpass -- under X, asks user for a passphrase for ssh-add
Control: retitle -1 O: ssh-askpass -- under X, asks user for a passphrase for ssh-add I am now orphaning this package. The previous logic (from this RFA) still applies, but in addition to that, I'm no longer even running X, having switched to Wayland, so my ability to test this package has diminished yet further. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1031220: grub-installer: variable $device_map used without being defined
Source: grub-installer Severity: minor Hi, While looking at the grub-installer script, shellcheck highlighted the fact that we appear to be using the variable $device_map in grub-installer, without it being defined. A grep of the D-I source tree for 'device_map=' found nothing, so it seems it's not being set in an included library either. git history reveals that it used to be set[1], until f97462fcb which was removing a load of device.map related code as a merge from Ubuntu, so I guess this is just some detritus that got missed at that point and happend to cause no problems since. That's presumably because that code only gets executed if the boot device matches ``[hf]d[0-9]*'', which I'm guessing is either never or rarely. If it ever does match, this gets run[2,3]: bootdisk="$(grep -v '^#' $device_map | grep "^ *$bootdev_nopart" \ | sed 's/^ *(.*)[[:space:]]*\(.*\)/\1/')" which I'd expect to hang, waiting on the first grep's STDIN (unless STDIN is redirected from /dev/null, or some such, at the time). If the condition regarding the boot device is ever likely to be true, then this code ought to be fixed, or at least the two cases in question could be changed to throw a meaningful error, so that people can report useful bugs about it. Otherwise, the obsolete code should be removed. I'm happy to create an MR once I know which option is required. Cheers, Phil. [1] https://salsa.debian.org/installer-team/grub-installer/-/commit/f97462fcbb4bbeb4a600c30ddc84a88#ae6e84c2dbfeefe14b039001e1b64254dada292b_81_78 [2] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L1066 [3] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L1077
Bug#1030303: install tmpfiles and sysusers config into correct path
Michael Biebl writes: > I noticed that openqa and openqa-worker install its tmpfiles and > sysusers configuration files into /lib. IIRC Originally the instalation into /lib was done in order to deal with the fact that dh_installsystem seemed not to notice them under /usr/lib. I presumed that would get fixed at some point, and intended to revert to installing them into their upstream location once that's done. However, I was also under the impression that we were supposed to be refraining from moving files between /lib/ and /usr/lib until after usr-merge was sorted out, in order to avoid issues with dpkg, so wasn't planning on touching this until that is all settled, just in case the openqa packages need rearanging at some point (since moving files between packages is what provokes that problem) I'd be happy to be proven wrong on this, as that would allow me to discard the special case from the install file. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1029616: perltidy: please package upstream 20221112 release
Package: perltidy Version: 20220613-1 Severity: normal Hi Don, I notice that upstream has released 20221112 (prompted by the fact that upstream openqa has a versioned depends on that new version) I knocked up a new version of the package, which is visible here: https://salsa.debian.org/philh/perltidy but which provokes lintian to say that there are sources missing: https://philh.pages.debian.net/-/perltidy/-/jobs/3847974/artifacts/debian/output/lintian.html which seems to be because the pod files under ./local-docs/ in the upstream git repo don't make it into the tarballs. I guess one could put them back in, or start basing the package on the git tags instead of the tarballs -- that seems like a decission for the maintaner, so I'll leave it up to you. Regarding tags: I note that they have also used tags of the form 20221112.03 which presumably either mean point releases of 20221112 or pre-releases of the next actual release, but I'm not sure which, or whether that should be considered a version to package. HTH Cheers, Phil.
Bug#748901: fixed in upstream git
Hi, This seems to be the upstream issue relating to this bug: https://github.com/corecode/dma/issues/89 which was closed with this commit: https://github.com/corecode/dma/commit/7024d2e27873598792f095ff832d345388fa4827 which is pretty trivial, so could either be backported or one could perhaps start shipping the unreleased version out of git. I'll be making my own version of dma for local use, as this bug is a bit of a disaster, but for others that are not aware that it's dma that's sabotaging their mail setup, I would say that this bug needs fixing urgently. I'll happily do an NMU with just the single commit applied, if that helps. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1026027: graphical installer: using nano in a installer shell fails
Holger Wansing writes: > Hi, > > Philip Hands wrote (Tue, 13 Dec 2022 20:34:17 +0100): >> On the 11.5 netinst I just tried out, in the Graphical Install's shell, >> TERM=xterm so that's obviously not the cause of the issue, but the >> difference would appear to be that it has: >> >> /usr/share/vte/termcap-0.0/xterm >> >> So I guess the fix for this is either to make sure that that termcap >> file gets installed again, or to set TERM in the Graphical Install's >> shell to something like 'bterm' or 'vt102'. >> >> I suspect restoring the termcap file is the correct fix. > > /usr/share/vte/termcap-0.0/xterm is there on dailies. Oh, so it is. Hmm, I seem not to have checked that bit, sorry. Perhaps the presence of the termcap file is irrelevant, or could it be that nano used to be able to make use of that, and more recently only supports terminfo? > Hmm. Kibi mentioned that this bug comes from ncurses (however I fail to > see any details here), should this be redirected to ncurses then? Well, ncurses-base provides /lib/terminfo/x/xterm (in normal .deb packages), so perhaps that's why, although AFAICS it wasn't including that file in the udeb, even when things were working. Making it ship a terminfo for xterm in the udeb would probably fix things, but I think it would also be quite nice to know why it broke. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1026027: graphical installer: using nano in a installer shell fails
Holger Wansing writes: > - start the installer > - choose 'Graphical expert install' > - 'Execute a shell' > - call 'nano /etc/fstab' > ---> Error opening terminal: xterm. That would seem to be because $TERM is set to 'xterm', whereas there's no terminfo file available for xterm. Under /lib/terminfo/*/ we have: ansi dumb linux screen vt102 and there's also /usr/share/terminfo/b/bterm In the F1-F3 consoles it's set to 'linux' (as expected), in the text installer, TERM is set to 'bterm' -- these work. So as a workaround, one can set e.g: TERM=bterm and then nano works in the graphical install's shell. On the 11.5 netinst I just tried out, in the Graphical Install's shell, TERM=xterm so that's obviously not the cause of the issue, but the difference would appear to be that it has: /usr/share/vte/termcap-0.0/xterm So I guess the fix for this is either to make sure that that termcap file gets installed again, or to set TERM in the Graphical Install's shell to something like 'bterm' or 'vt102'. I suspect restoring the termcap file is the correct fix. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1023468: dgit: the format of --dep14tag tags should be customisable
Philip Hands writes: > So one might have: > > dgit-distro.debian.dgit-tag-filter="sed -ne 's,^debian/1%,,p'" Except of course one wants to be able to set this in the repo somehow, in order that anyone cloning the repo also gets to generate the right sort of tags, so there's no way one should be able to tell other people to execute arbitary commands when running dgit, so I guess the PRETTY FORMAT idea is what's actually required. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1023468: dgit: the format of --dep14tag tags should be customisable
Ian Jackson writes: > I wrote: > >> Hrm. Some of the things that we envisage in the future will rely on >> being able to find the maintainer view tag, as well as the dgit view >> one. BTW in case it matters, I don't think I care whether one ends up with both the default tag that's currently being created (the 'debian/1.2.3' thing), as well as the custom one, but then again DEP-14 does include the idea of not including the distro bit in the tag if one is really the upstream, so erm, well doing both might really be wrong. > So I guess this would be a config option, where you specify a template > (with a %s in it I guess) for the tag you would like dgit to make. If it's supposed to be possible to do the thing where one can ignore the epoch in a version, then I guess it's more than a %s that's required (assuming that the string that's going into the %s was supposed to be the DEP-14 munged version from the changelog). One possibility would be to allow one to specify a command, that is given the current default tag value on STDIN and is expected to spit out the tag to use on STDOUT? So one might have: dgit-distro.debian.dgit-tag-filter="sed -ne 's,^debian/1%,,p'" then one could throw an error if the output is empty (which would be the case here if something unexpected happened, like the epoch being set to 2). Of course, if it's obvious what people might want to do with this, one could perhaps have some sort of PRETTY FORMAT style substitution where e.g. %v is the version, %V is the epoch-free version, %d is the distro bit, and maybe %e is the epoch -- no idea if that's all one needs though. > It should probably be a distro specific one (ie an "access" config > key) so you could do this iff you were uploading to Debian bug skip it > when uploading to Ubuntu, or whatever. > > Presumably it should do this iff > 1. That config option is set > AND > 2. The version number has no Debian revision > ? Seems reasonable. > If the config key is set and the version has a Debian revision, should > it fail or simply not make the tag ? I a inclined to say "fail". Fail, I'd think, as that makes the maintainer read the docs. > And should it apply the usual Debian to git syntax transform (as per > DEP-14) ? Or should it reject version numbers that wouldn't be > unchanged under that transform ? Or what ? If using the filter idea above, I'd insist that the result is a valid tag already, or fail. > With answers to these questions I think this becomes a fairly > straightforward SMOP. Cool. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1025340: xserver-xorg: Xorg segfaults at start-up in recent Debian Live images
Package: xserver-xorg Version: 1:7.7+23 Severity: important Usertags: openqa X-Debbugs-Cc: rclo...@rclobus.nl Hi folks, Debian Live images built in the last day seem not to be able to start X. It segfaults at start-up, thus: [20.784] (EE) Backtrace: [20.785] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x564d21cafc59] [20.787] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f5d44e5af90] [20.788] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.788] (EE) 2: /lib64/ld-linux-x86-64.so.2 (?+0x0) [0x7f5d45a99029] [20.788] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_exception+0x7a) [0x7f5d44f6de9a] [20.789] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (_dl_catch_error+0x2f) [0x7f5d44f6df4f] [20.789] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (dlerror+0x297) [0x7f5d44ea3dc7] [20.790] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (dlclose+0x36) [0x7f5d44ea3b26] [20.820] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d50f4) [0x7f5d4326bf44] [20.821] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (nouveau_drm_screen_create+0x1d4340) [0x7f5d4326b190] [20.821] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.821] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (?+0x0) [0x7f5d4282e179] [20.832] (EE) 10: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ae16) [0x7f5d42e39156] [20.832] (EE) 11: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x60ad84) [0x7f5d42e390c4] [20.832] (EE) 12: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0x6f4) [0x7f5d4282ea34] [20.833] (EE) 13: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (__driDriverGetExtensions_d3d12+0xa175) [0x7f5d428384b5] [20.833] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.833] (EE) 14: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7f5d44b6fd77] [20.833] (EE) unw_get_proc_name failed: no unwind info found [-10] [20.833] (EE) 15: /usr/lib/xorg/modules/extensions/libglx.so (?+0x0) [0x7f5d44b6eb7f] [20.834] (EE) 16: /usr/lib/xorg/Xorg (_CallCallbacks+0x34) [0x564d21b41a24] [20.834] (EE) 17: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x10af) [0x564d21c6da9f] [20.838] (EE) 18: /usr/lib/xorg/Xorg (InitExtensions+0x89) [0x564d21bad2a9] [20.838] (EE) 19: /usr/lib/xorg/Xorg (InitFonts+0x1e8) [0x564d21b404e8] [20.838] (EE) 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f5d44e4618a] [20.839] (EE) 21: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f5d44e46245] [20.839] (EE) 22: /usr/lib/xorg/Xorg (_start+0x21) [0x564d21b29b61] [20.839] (EE) [20.839] (EE) Segmentation fault at address 0x337 [20.839] (EE) Fatal server error: [20.839] (EE) Caught signal 11 (Segmentation fault). Server aborting Full log file is here: https://openqa.debian.net/tests/101031/logfile?filename=Xorg.0.log.txt I'm not sure what's causing this, hence the bug report against xserver-xorg. libglx-mesa0 seems like it _might_ be worth a look, given that the last thing before the segfault in Xorg.0.log is this: [17.912] (II) Initializing extension GLX [17.912] (II) AIGLX: Screen 0 is not DRI2 capable Here is the list of packages that are part of that broken live image: https://openqa.debian.net/tests/101031/logfile?filename=_graphical_wait_login-installed-pkgs.txt and here's a version of that list from a day earlier, when things were still working, for comparison: https://openqa.debian.net/tests/100587/logfile?filename=_collect_data-debs.txt BTW I notice that libglx-mesa0 went from 22.2.4-1 to 22.3.0-1, among many other changes. If you want to give it a try yourself, the most recent version of the live image we're testing comes from here: https://tests.reproducible-builds.org/debian_live_build/artifacts/r00t-me/kde-sid.iso Since the image there is regularly generated anew, you'll probably want to check that it's still causing a problem before testing things yourself, which you can do here: https://openqa.debian.net/tests/latest?arch=x86_64=debian=live-build=64bit=live-build-desktop_browser=sid_kde#next_previous If you want a copy of the image that caused a failing test, just click on the red dot for the failed test, go to the "Logs & Assets" tab, and you'll find a link to the image at the bottom of the list. Cheers, Phil.
Bug#1024361: lintian: complains about bpo version when package built with salsa-CI/pipeline (+salsaci)
Package: lintian
Severity: normal
As one can see here:
https://installer-team.pages.debian.net/-/debootstrap/-/jobs/3528761/artifacts/debian/output/lintian.html
it complains when this bpo version is built:
https://salsa.debian.org/installer-team/debootstrap/-/commit/e2adc51823c1a1179edce2106c870c588e806393
This is a consequence of the default behaviour of the salsa-CI/pipeline, adding
a version-bump:
https://salsa.debian.org/salsa-ci-team/pipeline#debian-release-bump
combined with this pattern only accepting digits after `bpo`:
https://salsa.debian.org/lintian/lintian/-/blob/ea05801918ed0e87824d89bf16a6ee166450b977/lib/Lintian/Check/Fields/Distribution.pm#L95
I suppose replacing that with this:
if ($version=~ /~bpo(\d+)\+(\d+)(\+salsaci)?)$/) {
would fix that.
Cheers, Phil.
Bug#835672: xfce4-power-manager: If installed without xfce4-session, fails to lock screen due to missing xflock4 script
Akbarkhon Variskhanov writes: ... > If you check your ~/.xsession-errors there should be a warning about > setting a LockCommand. The simplest fix is to actually set it via > `xfconf`: I switched from Xmonad/X to Sway/Wayland in the last couple of months, so I'm not able to confirm this, I'm afraid. There's therefore no need to keep the bug open for my benefit, but perhaps you want to leave it open to give others the hint if they stumble across the same behaviour. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1023472: lxqt: lxde pulls in both kwin & xfwm4, when selecting 'lxde' during D-I install
Package: lxqt Severity: normal Hi, Last month install tests started including this prompt: https://openqa.debian.net/tests/91155#step/_graphical_wait_login/9 which is asking the user to decide between Kwin and Xfwm4 as their window manager. I would expect that only one of those should be getting installed by default. The last version of the daily D-I images that didn't do this was built at 2022-10-13 17:21. Cheers, Phil.
Bug#1023468: dgit: the format of --dep14tag tags should be customisable
Package: dgit Version: 10.0 Severity: minor dgit generates tags of the form suggested by DEP-14 (`debian/1.2.3`) when --dep14tag is set, which is of course just as it should be for most cases, but there are times when one wants to vary from that. When one is considering native packages for which one is also upstream, DEP-14 includes this recommendation: > In that specific situation, the upstream vendor should not use the usual > / prefix for their branches and tags so one could perhaps default native packages to not generate the 'debian/' bit, but I'd think that it still needs to be configurable. An example of a repo where a non-standard configuration is required to make dgit fit in with the status quo is apt-setup: https://salsa.debian.org/installer-team/apt-setup/-/tags where one can see that the tags are of the form `0.172`. So, in that case the `debian/` bit is missing (fitting in with the above bit about native packages), but also the version includes an epoch, whereas the tags do not. BTW I note that dgit(1) mentions this config setting: dgit-distro._distro_.dgit-tag-format which encourages the assumption that one ought to be able to set something like: dgit-distro.debian.dgit-tag-format = '%v' and get what I'm asking for, but looking at the code makes me think that nothing's making use of that setting at present. Cheers, Phil.
Bug#1019660: console-setup: grep: warning: stray \ before #
Hi Vincent, Prompted by your patch I've created this MR: https://salsa.debian.org/installer-team/console-setup/-/merge_requests/16 Thanks for the patch, without which I may not have noticed the chance to continue my eternal quest against `grep | sed` pipelines :-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#916681: certainly is reproducible
Hi Jakub, Sorry about that, now that I try that again it certainly is reproducible -- odd that I somehow managed to fail on the first attempt, given that you provided such a nice method to reproduce. Sorry for the noise. That'll teach me not to do drive-by bug tidying ;-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1020417: plasma-vault: encfs security warning during Debian-Installer when KDE desktop selected
Package: plasma-vault Version: 5.25.4-1 Severity: normal Attached is a screenshot from installing Debian with KDE selected as the Desktop Environment. As you can see, it's giving a scarry looking security warning, which is probably not the first impression we want to present. My asumption is that when selecting KDE, one pulls in plasma-vault, which in turn depends upon encfs, which results in this message being presented to the user. Is encfs essential to the operation of plasma-vault? If not, perhaps it could be dropped from a recommends to a suggests? BTW You can see a test install of KDE here, with the warning: https://openqa.debian.net/tests/77193#step/grub/3 Cheers, Phil.
Bug#1015887: debian-installer: Adding https repo doesn't work without manually installing ca-certificates
Control: reassign -1 apt-setup-udeb Control: fixed -1 1:0.169 Hi, I just had a look at this, and it seems to me that this was fixed in apt-setup-udeb 0.169, but the version in the released (Debian 11) installer is only at 0.166, so does not include the fix. Looking at the syslog in this bug, one can see: apt-setup-udeb 1:0.166 which is the version in the release, and is from 2021-07-23. The thing that fixes the bug is: https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/4 which was merged on 2022-01-29, then released as part of 1:0.169. I've reproduced the failure with the release version of D-I, and failed to reproduce it with yesterday's daily image (where one sees the installation of the c-certificates package go past just after selecting the mirror), so it really looks to have been fixed already. If you want to try that for yourself, the daily images can be found here: https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#787279: installation-reports: still present in rootskel-gtk 11.0.2
Followup-For: Bug #787279 Control: reassign -1 rootskel-gtk Having just tested this again, I see that setting `dpms=true` on the kernel command line has no effect, as reported in this bug. In the mean time, I note that we no longer have screen-blanking going on in the text-mode (console) install. This seems to be because the kernel is now defaulting to setting consoleblank=0 as one can see by running: cat /sys/module/kernel/parameters/consoleblank which returns `0` (BTW This is just as it should be IMO) Given that we seem to have decided that there's no danger of burn-in on consoles these days, perhaps we can also agree that there's no danger for X either. The '-s 0' option to Xorg does actually stop X from blanking, as one can demonstrate by specifying this kludge on the kernel command-line: preseed/early_command="echo DPMS=-s\ 0 > /lib/debian-installer.d/S61Xnoblank" which sets $DPMS to "-s 0" which is then used within `debian-installer.d/S62Xorg` to set an option for Xorg. That being the case, I think we should apply the '-s 0' setting by default, and only remove it if someone sets "dpms=true". =-=- This can all be seen here (while the links remain active): Normal Debian-Edu install (which takes long enough to blank the screen) being marked as a soft-fail at the blank screen: https://openqa.debian.net/tests/76944 now with a setting of: GRUB: dpms=false which sets that on the kernel command line, thus: https://openqa.debian.net/tests/77055#step/_boot_to_debianinstaller/2 but still blanks: https://openqa.debian.net/tests/77055#step/grub/36 on the other hand, no screen-blanking is seen in text mode: https://openqa.debian.net/tests/77056 and if one applies the '-s 0' kludge: https://openqa.debian.net/tests/77059#step/_boot_to_debianinstaller/2 which also doesn't blank: https://openqa.debian.net/tests/77059 Cheers, Phil.
Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck
Vagrant Cascadian writes: > On 2022-09-14, Philip Hands wrote: >> Vagrant Cascadian writes: >> >>>> but also >>>> (given that the tests will have passed during the normal build) the tests >>>> failing during the varied build seems unlikely to be identifying faults >>>> that are >>>> worth fixing, and so is just a waste of cycles. >>> >>> How do you know weather the bugs it is identifying are worth fixing? It >>> could also identify non-deterministic failures, or failures triggered by >>> specific build environment configurations... >> >> The point is that if the package is reproducible, then the fact that its >> tests fail when run in a weird environment (that may never be found in >> the wild) seems rather likely to be finding errors in the tests rather >> than errors in the program that gets shipped. > > Fair point! > >> Of course, if the package is not reproducible, the tests may well fail >> because the package ends up containing new bugs that are only present in >> the variant-built package, but then its also going to show up as >> non-reproducible, so does that really make a difference? > > True, though it may make things harder to verify reproducibility in > practice, especially if it is a fairly "normal" variation that triggers > the issue... > > > It is a balancing act... > > I guess I'd be fine with the defaults to go either way, but it would be > important to be able to enable or disable however this gets implemented. Absolutely. That's why I was requesting that it be a variation in its own right, since that should allow one to specify: --variations=-nocheck and get a normal (with checks) build in the varied scenario. BTW If someone can give me a hint where in the code one would define such a variation I'll cheerfully give it a go myself, but sadly it seems that my python is too weak to find the right spot for myself. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck
Vagrant Cascadian writes: >> but also >> (given that the tests will have passed during the normal build) the tests >> failing during the varied build seems unlikely to be identifying faults that >> are >> worth fixing, and so is just a waste of cycles. > > How do you know weather the bugs it is identifying are worth fixing? It > could also identify non-deterministic failures, or failures triggered by > specific build environment configurations... The point is that if the package is reproducible, then the fact that its tests fail when run in a weird environment (that may never be found in the wild) seems rather likely to be finding errors in the tests rather than errors in the program that gets shipped. Even if busybox's du really does have a bug where it miscounts the sizes of files when run under the fileordering variation, I'm not sure that breaking the ability to confirm that the package is reproducible is justified in order to find that bug. I'm afraid I've not yet managed to work out what's behind the mis-counting, but my first guess is that it's more likely to be something in the fuse system presenting the data than in du's counting of it. Of course, if the package is not reproducible, the tests may well fail because the package ends up containing new bugs that are only present in the variant-built package, but then its also going to show up as non-reproducible, so does that really make a difference? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1019742: reprotest: add a variation that sets DEB_BUILD_OPTIONS=nocheck
Package: reprotest Version: 0.7.22 Severity: wishlist I suggest adding a 'nocheck' variation, that sets DEB_BUILD_OPTIONS=nocheck during the build, and enabling it by default. The reason for doing so is that one could imagine that a package produces differing results depending upon whether the tests were run or not, but also (given that the tests will have passed during the normal build) the tests failing during the varied build seems unlikely to be identifying faults that are worth fixing, and so is just a waste of cycles. This idea is prompted by `busybox` where the tests fail in the varied scenario, despite the fact that the package is reproducible. Here they are failing: https://salsa.debian.org/installer-team/busybox/-/jobs/3227197 (among other things, du produces weird results when the `fileordering` variation is active, claiming the 1MB directoy is 2MB so the tests fail, so the varied package is not produced, so we don't get to see that it was reproducible: https://salsa.debian.org/installer-team/busybox/-/blob/master/testsuite/du/du-m-works ) I found a couple of ways of making the issue go away: 1) disabling the 'fileordering' variation, thus: https://salsa.debian.org/installer-team/busybox/-/commit/17387890c73388e1f56a6ae9fbc79783095b4e86 https://salsa.debian.org/installer-team/busybox/-/jobs/3233259 2) telling the package to skip the tests when doing the variations: https://salsa.debian.org/installer-team/busybox/-/commit/5260442e8ceea220fa36bdda169978d15108f781 which is setting this in the salsa-ci.yml: SALSA_CI_REPROTEST_ARGS: --variations=environment.variables+=DEB_BUILD_OPTIONS=nocheck https://salsa.debian.org/installer-team/busybox/-/jobs/3235476 Option 2) is what I'm suggesting making into a default variation. If nothing else it will speed up testing of packages with extensive test suits. Cheers, Phil.
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
Pascal Hambourg writes: > On 03/09/2022 at 06:32, Philip Hands wrote: >> Ansgar writes: >> >>> Source: rescue >>> Version: 1.85 >>> Severity: important >>> >>> I've installed a system using btrfs for the root filesystem with d-i >>> (with disk encryption as well). As grub wasn't properly installed >>> (not registered with EFI), I tried to use the rescue mode to reinstall >>> grub. >>> >>> However, mounting the root filesystem failed: /target contained only a >>> "@rootfs" subdirectory. So running a shell in the target fs failed. >>> Manually mounting the filesystem with `-o subvol=@rootfs` worked. >>> >>> This was with Debian 11.4. > >> I just pushed 1.88 including this MR: >> >>https://salsa.debian.org/installer-team/rescue/-/merge_requests/1 >> >> which seems like it ought to address the problem you're experiencing. > > If I understand correctly, the problem is in mounting a btrfs root > filesystem. Ah, sorry, I saw btrfs and jumped to a conclusion without noticing the rootfs bit -- you are quite right. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
Ansgar writes: > Source: rescue > Version: 1.85 > Severity: important > > I've installed a system using btrfs for the root filesystem with d-i > (with disk encryption as well). As grub wasn't properly installed > (not registered with EFI), I tried to use the rescue mode to reinstall > grub. > > However, mounting the root filesystem failed: /target contained only a > "@rootfs" subdirectory. So running a shell in the target fs failed. > Manually mounting the filesystem with `-o subvol=@rootfs` worked. > > This was with Debian 11.4. I just pushed 1.88 including this MR: https://salsa.debian.org/installer-team/rescue/-/merge_requests/1 which seems like it ought to address the problem you're experiencing. Please try your test again once the daily image picks up on the new version. If you're in a hurry, you could also use this salsa-built test mini-ISO image: https://salsa.debian.org/installer-team/debian-installer/-/jobs/3179168/artifacts/file/public/gtk-mini.iso Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1018802: localechooser: reproducible builds: locale and parallelism trigger reproducibility issues
Vagrant Cascadian writes: > That attached patches fix this by passing --no-parallel to dh (parallism > was probably introduced in the switch from debhelper compat 9 to 13), > and by exporting LC_ALL=C.UTF-8 in debian/rules. I've stuck this onto salsa: https://salsa.debian.org/philh/localechooser/-/commits/bug/1018802 which builds, and passed most of the tests: https://salsa.debian.org/philh/localechooser/-/pipelines/417953 which leads on to an openQA tests, where they also pass (apart from a few that are broken in general at present): https://openqa.debian.net/tests/overview?distri=debian=-salsa-417953%3Aphilh%3Alocalechooser%3Abug%2F1018802=13=salsa_testing and where one can see here that it really is the patched version of localechooser that's in use: https://openqa.debian.net/tests/73247#step/rescue/53 so that all looks fine to me. Of course, the "most" regarding passing tests does not include repotest, which is a bit of a shame, as I had hoped to be able to show a before and after with that test passing, but currently the repotest script includes a '*.deb' that ignores udebs and so finds nothing to test :-/ I'll sort out an upload soon -- just thought I'd mention what I've done so far to save others duplicating effort. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1017725: dgit-maint-native(7) examples should use push-source (rather than push)
Sean Whitton writes:
> Hello,
>
> On Wed 24 Aug 2022 at 10:57PM +01, Ian Jackson wrote:
>
>>
>> Sean Whitton writes ("Bug#1017725: dgit-maint-native(7) examples should use
>> push-source (rather than push)"):
>>> On Fri 19 Aug 2022 at 05:12PM +02, Philip Hands wrote:
>>> > It strikes me that examples that currently show the `push` sub-command:
>>> >
>>> > dgit -wgf --overwrite push
>>> > and
>>> > dgit -wgf push
>>> >
>>> > should show the use of the `push-source` sub-command instead,
>>> > since doing binary uploads to Debian now prevents migration to
>>> > testing, so chances are that's not what most people want to do.
>>>
>>> Yes, that should be updated.
>>>
>>> > One could perhaps also add a `--with-binary` option for `push` and
>>> > gently transition to defaulting to doing source-only uploads unless
>>> > one specified that option via config or options.
>>>
>>> This is an intriguing suggestion, thank you.
>>
>> Given the differences between the behaviour of (what is now) push and
>> of push-source, I'm not really convinced that a mere option is
>> sufficient.
>>
>> But, how about this:
>>
>> * Provide `push-built` which does what `push` does now.
>> * Change `push` to look at a (not distro-dependent) config option.
>> - for bookworm, defaults to "do push-built, warn"
>> - for bookworm+1, defaults to "do push-source"
>>
>> People who have scripts that do "dgit push" and need to work on older
>> releases can safely pass the config option right away since unknown
>> config options are ignored.
>
> Yes, having a 'push-built' like this alongside 'push-source' sounds
> better than the current push and push-source combination. LGTM.
I think that would have given me the hint I required to know what I
needed to do (without having to do it wrong once to find out :-) )
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#1017725: dgit-maint-native(7) examples should use push-source (rather than push)
Package: dgit Version: 9.16 Severity: minor It strikes me that examples that currently show the `push` sub-command: dgit -wgf --overwrite push and dgit -wgf push should show the use of the `push-source` sub-command instead, since doing binary uploads to Debian now prevents migration to testing, so chances are that's not what most people want to do. One could perhaps also add a `--with-binary` option for `push` and gently transition to defaulting to doing source-only uploads unless one specified that option via config or options.
Bug#1017435: debian-installer: georgian text mode fails to render all characters
Package: debian-installer Severity: normal openQA just noticed that the rendering of certain characters just changed, highlighting the fact that the rendering was already broken. For example the prompt for the hostname: msgid "Please enter the hostname for this system." msgstr "გთხოვთ შეიყვანოთ კომპიუტერის სახელი." gets displayed as something like: გთ_ოვთ შეი_ვანოთ კომპიუტერის სა_ელი." so it looks like it's failing to deal with at least these characeters: https://www.compart.com/en/unicode/U+10EE and https://www.compart.com/en/unicode/U+10E7 In the past the _'s would have appeared as blanks, whereas now they are inverted and show as blue squares (which is an improvement, since this makes it obvious that something's wrong, and also caused openQA to notice the change) The old look can be seen here: https://openqa.debian.net/tests/69846#step/hostname/1 The new look here: https://openqa.debian.net/tests/69954#step/hostname/2 and I'll attach screenshots of the same (for when the links rot) Cheers, Phil.
Bug#1016809: [UEFI] Installed (minimal) bookworm system hangs at boot
Philip Hands writes: > Holger Wansing writes: > >> Holger Wansing wrote (Sun, 7 Aug 2022 21:36:43 +0200): >>> Installing Debian on an UEFI-driven QEMU machine (minimal installation, only >>> standard system task) leads to a successful installation, but the newly >>> installed system cannot complete its boot process. >>> It hangs forever (here on linux 5.18.0-3) with this messages >> >> >> I wonder why this is not detected by tests on >> https://openqa.debian.net/group_overview/10 >> I see there are specific runs for UEFI, so it should be possible to detect >> this? >> >> >> The reason for this is, there are no standard-system-only tests there. > > That's true, so I put one together last night, which (on my laptop at least) > seems to work fine, so I guess there's something about your setup that's > different (as kibi & rclobus suggest). Sledge, even anyway, for completeness, here's an openQA test running, showing that it can get to the logged-in shell prompt on the installed system: https://openqa.debian.net/tests/68307#step/_console_wait_login/6 so I'm afraid I'm not reproducing your problem. BTW That is a UEFI (although not secure-boot) boot. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1016809: [UEFI] Installed (minimal) bookworm system hangs at boot
Holger Wansing writes: > Holger Wansing wrote (Sun, 7 Aug 2022 21:36:43 +0200): >> Installing Debian on an UEFI-driven QEMU machine (minimal installation, only >> standard system task) leads to a successful installation, but the newly >> installed system cannot complete its boot process. >> It hangs forever (here on linux 5.18.0-3) with this messages > > > I wonder why this is not detected by tests on > https://openqa.debian.net/group_overview/10 > I see there are specific runs for UEFI, so it should be possible to detect > this? > > > The reason for this is, there are no standard-system-only tests there. That's true, so I put one together last night, which (on my laptop at least) seems to work fine, so I guess there's something about your setup that's different (as kibi & rclobus suggest). Thanks for pointing out that we were missing such tests, which I'd left room for, but never got round to finishing off properly. I just need to tidy up my patch and then I'll enable some new DESKTOP=textmode tests. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#991859: Is a different opinion about a license a case for the ctte?
Hi Andreas, While I think you're right that this is just some example text, and given that it was added in quite a large commit, touching many other files, all of which are presumably under GPL, with no mention of the intent to license that one file differently, it would be quite surprising if that was the way that's supposed to be interpreted. On the other hand, given that it's an example, perhaps the author wanted to make sure people could cheerfully cut it into things that were not GPLed? I'd say the only way to be sure would be to ask the author(he seems pretty active on GitHub, so seems likely to respond in a timely manner). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1013079: installation-reports: GUI install option isn't visible on boot
Holger Wansing writes: > Hi, > >> > - On Jun 17, 2022, at 7:43 AM, Philip Hands p...@hands.com wrote: >> > > >> > > https://openqa.debian.net/tests/60553#step/_boot_to_debianinstaller/2 >> > > >> > > if you look closely in the highlighted box, you can just about see >> > > "Graphical install" as a black font on dark_blue background, but it's >> > > very close to invisible. >> > > >> > > It should have an inverted background on the selected item, which then >> > > makes the black text easily visible, as seen in the last working test, >> > > using a netinst ISO from 2022-06-07 17:27: >> > > >> > > https://openqa.debian.net/tests/59056#step/_boot_to_debianinstaller/1 > > Since the URLs from above are no longer valid, I'm attaching two screenshots > to show the issue (the first one from the last working 2022-06-07 image, > the second from today's installer image). Oh -- There's supposed to be a setting that keeps old tests if they've been refereed to from certain URLs (and I thought I'd set that to include the BTS, and had made a point of doing such an access to tag the build as a keeper) but it seems not to have worked. I shall see what I can do to fix that... Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0
I presume this is also the cause of this failure when installing Debian-EDU: https://openqa.debian.net/tests/64605#step/grub/3 If one looks at the associated syslog, here: https://openqa.debian.net/tests/64605#step/grub/31 one can see various symptoms of libsystemd0's absence: ... Jul 16 14:43:44 anna[2159]: DEBUG: resolver (libsystemd0): package doesn't exist (ignored) ... Jul 16 14:43:58 main-menu[423]: (process:4065): pvs: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory ... resulting in the failure to create the volume group, seen in the initial screenshot above. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1014273: ITP: pastaignore -- makes gitignores easier
Hi, It's not clear to me what this does that makes it more useful than other more-general-purpose commands that we already have packaged, such as find or (for simpler usage) fdfind (from the fd-find package). For instance, the example in your readme of: pastaignore ".*\.o" not "\.\/demo\/important.*\.o" can (unless I'm missing something) be done with fdfind thus: fdfind -E '^demo/important*' ".o$" BTW does pastaignore take the current .gitignore into account, or does it just put out all filenames including the already ignored ones? I only ask becuase fdfind does use .gitignores (optionally) so will only list files that are not already ignored, which seems like a useful feature in such a program. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
Jmkr writes:
> Sorry for the delay, I had to do some work and then forgot that I
> planned to reply to this bug.
No problem, these things happen -- anyway, your timing was great as I
was just about to do something about this anyway.
> > Philip Hands writes:
> > ...
> >
> > Actually, given that we don't care what's in the first field at that
> > point, and it's already matched the start of the country code, I think
> > this ought to work as well:
> >
> > "/^${L%%_*}/"'{s/^[^;]*;\([0-9]\);.*/\1/p;q}'
>
> Yes, it works perfectly when I tested the "sed" command both in a
> terminal and also in my customized DI in the
> "./usr/lib/post-base-installer.d/05localechooser" file.
>
> Although, I did not test the generated ISO and whether the whole locale
> chooser mechanism now works as intended with locales that have level 3+
> (i.e. if DI actually creates the "/target/root/.profile" file for such
> locales). Since I don't use such locales on my systems it would be
> difficult for me to test this. I don't know the languages, so I probably
> would not be able to finish the DI using one of these languages:).
Ah, good to know. I had assumed that you'd come across this by using
one of the affected translations.
Given that isn't the case, I had another look at the list of locales,
and noticed that Georgian is at least right-to-left so is a bit easier
for me to drive, so added that to my tests, and added the collection of
root's .profile as part of the post-install, with the result that we
have this example of the old code failing:
https://openqa.debian.net/tests/60893/logfile?filename=root_dot_profile.txt
Re-running the test with a gtk-mini.iso that includes the patched
localechooser gives us the result we're hoping for, which is nice:
https://openqa.debian.net/tests/60903/logfile?filename=root_dot_profile.txt
I had planned to do a bit more on the salsa scripting side of things to
streamline creating this sort of test, and then to upload a new version
of localechooser including this change, but I find myself a little
distracted by my family members contracting Covid19 over the last couple
of days. Hopefully I'll have chance to finish things off shortly.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#1013079: installation-reports: GUI install option isn't visible on boot
> Initial boot: Default GUI install option wasn't visible. Once I used > the down arrow to move from the highlighted default option, it became > visible and I was able to use the up arrow to return to it. I would guess what you're seeing is the same as the problem with recent daily images, when doing a UEFI boot, as seen here: https://openqa.debian.net/tests/60553#step/_boot_to_debianinstaller/2 if you look closely in the highlighted box, you can just about see "Graphical install" as a black font on dark_blue background, but it's very close to invisible. It should have an inverted background on the selected item, which then makes the black text easily visible, as seen in the last working test, using a netinst ISO from 2022-06-07 17:27: https://openqa.debian.net/tests/59056#step/_boot_to_debianinstaller/1 The first broken version I saw was from 2022-06-13 17:22, although it could be that the breaking change happened earlier but was masked by the kernel mismatch/upgrade that meant that no new ISOs were produced for a few days just before that. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
Jmkr writes:
> I tested Phil's "sed" command in terminal like this (all one line -
> email splits it):
>
> L=cs_CZ.UTF-8; sed -n
> "/^${L%%_*}/"'{s/^[[:alpha:]]*;\([[:digit:]]\);.*/\1/p;q}' languagelist
>
> and it seemed to work - with "cs_CZ.UTF-8" locale it returned 2. But
> some locales still returned wrong level. After using a modified "sed"
> command I think I got it working even for locales like "zh_TW.UTF-8" or
> "nn_NO.UTF-8" etc.:
>
> L=zh_TW.UTF-8; sed -n "/^${L%%_*}/"'{s/^[A-Za-z_]*;\([0-9]\);.*/\1/p;q}'
> languagelist
>
> returns 3 and with "nn_NO.UTF-8" it returns 1. I guess "[[:alpha:]]"
> does not include "_".
Oh, I thought I'd tested that (and remember being surprised that
[:alpha:] had seemed to include '_', so I must have deceived myself
there somehow).
Anyway, well spotted :-)
Actually, given that we don't care what's in the first field at that
point, and it's already matched the start of the country code, I think
this ought to work as well:
"/^${L%%_*}/"'{s/^[^;]*;\([0-9]\);.*/\1/p;q}'
> Anyway it is a nice improvement doing all the work with one "sed"
> process compared to that "wild pipelined bunch of cutting greps and
> heads". So, thanks to what Phil "sed", I am now upgrading my version of
> the script to the "sed" approach:).
:-)
I just pushed that change here:
https://salsa.debian.org/philh/localechooser/-/commit/f4845f6c8bad1ca11886ea2cff94653aa25045bc
which (once the pipeline runs) should generate a new mini-iso for testing.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
Philip Hands writes: > > https://salsa.debian.org/philh/localechooser/-/commit/24206bbaccb9619302bab5ca603fb214841ebf58#63952ea2967253e426478ffea08ddc67c3bff9d8_98_92 I just noticed: that commit's line order was mangled while rebasing. This is what it should have been: https://salsa.debian.org/philh/localechooser/-/commit/1e511957c05724bb417c07a84894bcb999a95b28 The subsequent commits in both versions of that branch did arrive at the same destination, even if the middle bit was a bit tangled. You may prefer to test the image produced from this later version of the branch though, in which case the pipeline that built it can be found here: https://salsa.debian.org/philh/localechooser/-/pipelines/379661 which (after a couple of triggers) gives rise to this mini.iso: https://salsa.debian.org/installer-team/debian-installer/-/jobs/2786465/artifacts/file/public/gtk-mini.iso Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
Michael Tokarev writes:
> 19.05.2022 15:59, Philip Hands wrote:
> ...
>> Actually, I'm unable to resist the urge to remove the redundant use of
>> cat (that was already there), so how about doing it in a single sed:
>>
>>LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }'
>> /usr/share/localechooser/languagelist)
>
> That smells like awk usage, not sed ;)
Doh!
I started out with awk, as it's cleaner for this, and then noticed that
we don't have awk enabled in d-i's busybox, so changed to sed.
I seem to have messed up what I put in the email ... that's not what's
in the commit:
https://salsa.debian.org/philh/localechooser/-/commit/24206bbaccb9619302bab5ca603fb214841ebf58#63952ea2967253e426478ffea08ddc67c3bff9d8_98_92
sed -ne "/^${LOCALE%%_*}/"'{ s/^[[:alpha:]]*;\([[:digit:]]\);.*/\1/p; q}'
/usr/share/localechooser/languagelist
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file
Jmkr writes:
> Package: localechooser
> Version: 2.94
>
> Dear Maintainers,
>
> While working on my customized Debian installer (DI) I noticed that the
> "./usr/lib/post-base-installer.d/05localechooser" file from the
> "localechooser_2.93_*.udeb" package (at least for AMD64 and ARM64
> architectures) contains probably buggy source code for calculating the
> value of the "LEVEL" variable (on lines 87-91). The problems are in
> "cut" commands (on lines 88 and 91) which should probably be:
> cut -f 1-3 -d \;
> cut -f 2 -d \;
>
> Currently the "LEVEL" variable seems to get the empty string value
> because the "grep" command (on line 89) cannot find the language code
> (because the first field is removed by the first "cut" command). Maybe
> the "LANGUAGECODE" variable on line 83 could be avoided and merged into
> the "LEVEL" variable if command substitution is done using "$(...)"
> resulting in this proposed source code:
> LEVEL=$(cat /usr/share/localechooser/languagelist | \
> cut -f 1-3 -d \; | \
> grep $(echo $LOCALE | cut -f 1 -d _) | \
> head -n 1 | \
> cut -f 2 -d \;)
Yes, we were cutting off the LANGUAGECODE column before trying to grep
it, so the old code would never come up with a level of 3 or 4.
BTW I would suggest using:
${LOCALE%%_*} in place of the $(echo ... | cut ...)
Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:
LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }'
/usr/share/localechooser/languagelist)
I've put that into this branch (with a few of other tweaks):
https://salsa.debian.org/philh/localechooser/-/commits/bug1011254
and here is a mini-iso that includes that change:
https://salsa.debian.org/installer-team/debian-installer/-/jobs/2785179/artifacts/file/public/gtk-mini.iso
[note that it's built by infrastructure that's not under our direct
control, so such images should be viewed with a degree of suspicion]
If you'd like to test that, please do, otherwise perhaps you can suggest
a test that would determine that the code is behaving as you'd hope.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#678694: Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu
Diederik de Haas writes: > On Friday, 13 May 2022 09:35:49 CEST Johannes Schauer Marin Rodrigues wrote: >> If I understand the docs of preseed_fetch correctly, then this should fetch >> the setup-testbed script from a path relative to where it got the preseed >> file from. >> >> Unfortunately this results in the following: >> >> May 13 07:26:28 preseed: successfully loaded preseed file from >> http://10.0.2.2:8000/d-i/bullseye/./pres >> May 13 07:26:28 preseed: running preseed command preseed/early_command: >> preseed_fetch setup-testbed /tm >> May 13 07:26:28 log-output: /bin/fetch-url: .: line 35: can't open >> '/usr/lib/fetch-url//setup-testbed': >> >> I'm confused. Shouldn't preseed_fetch try to obtain the setup-testbed >> relative to the preseed file it just obtained? > > Looks rather similar to https://bugs.debian.org/678694 ... True -- it's probably time to fix that ... I my immediate reaction to the suggested patch is that there may well be some problem with always overwriting the file, and if so, that such a problem probably only becomes apparent when combining relative and absolute paths in particular orders. I would assume that even if that is the case, it should be OK to write the file if it does not already exist, which ought to be enough to fix this issue. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1009711: openqa: block migration to testing (awaiting availability of packaged shepherd.js)
Package: openqa Severity: serious Recently upstream, openQA switched to using shepherd.js for its guided tour, which is not yet packaged. I'd prefer to avoid the current version getting into testing, to avoid it somehow sneaking into stable if getting shepherd.js through NEW takes longer than expected, so am reporting this bug to block it for now. Cheers, Phil.
Bug#1003653: Revision of removal of rename.ul from package util-linux
Christoph Berg writes: > Re: Chris Hofstaedtler >> > * which binary package should contain the util-linux rename? >> >- bsdextrautils >> >- something else >> >> util-linux-extra. Unrelatedly, other non-essential binaries from >> util-linux should also move into this package, but this is only >> tangentially related. > > Hi, > > I like that package name. > >> > * where should it be installed? >> >- /usr/bin >> >- something else? >> >> /usr/bin/rename > >> > * should there be a Conflicts or Breaks relation with the perl rename? >> >> I think this will be necessary. > > The problem here is that if ul-extra contains things besides rename, > and it conflicts with the perl rename, people will rightfully complain > that they can't install /usr/bin/fincore-from-ul-extra and > /usr/bin/rename-from-perl at the same time. > > Or would you solve that using alternatives, without the conflicts? Is it possible to have alternatives default to installing neither option by default? I suspect not, but something like that might allow local admins to install either as /usr/bin/rename while not encouraging the use of that path in packaging scripts (which should use either rename.ul or file-rename to get the version they really want). I suppose the same result could be constructed with a shared low-priority debconf question about which to use, defaulting to neither. An approach which strikes me as inelegant, but ought to work, would be for something essential to provide the default alternative as a script that spits out a warning that you should be using whichever of the specific names you really meant, or that you could define 'rename' as an alias in your profile, or even that you might use update-alternetives to install one of them as 'rename' system-wide. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1008258: libjs-bootstrap4: new version available upstream (v4.6.1)
Package: libjs-bootstrap4 Version: 4.5.2+dfsg1-7 Severity: wishlist I note that the latest version (of 4.*) available upstream is 4.6.1: https://github.com/twbs/bootstrap/releases/tag/v4.6.1 released 28 Oct 2021. The only reason I realised this is that openQA just switched to using 4.6.1. https://github.com/os-autoinst/openQA/pull/4579/files I would imagine that openQA should work well enough with 4.6.0 (not tried it yet), so if there's a good reason for not packaging 4.6.1, please say so and I'll feed that back to the openQA folks, and will then try to make sure that openQA supports both versions adequately. Cheers, Phil.
Bug#957514: mailavenger: fixed in salsa 'gcc_10' branch
Source: mailavenger Followup-For: Bug #957514 Control: tags -1 patch Hi Dererk, The reason for this FTBFS is that gcc 10 now defaults to -fno-common, which then throws errors because there are some tentative definitions in .h files, and some definitions of an int `garbage` in several .c files. Here's a branch that fixes that: https://salsa.debian.org/debian/mailavenger/-/commits/gcc_10 by adding `__attribute__((__common__))` to those variables. I separated the patches, because the `garbage` definitions seem a little different in character. Cheers, Phil. P.S. my C programming experience is from the previous millenium, so I could easily have got this wrong. I will not be upset if you point this out :-)
Bug#1005783: xorg-server: "no screens found" when run under: kvm -vga virtio
Philip Hands writes: > However, a UEFI boot still fails (with `-vga std`): > > https://openqa.debian.net/tests/42416#step/_boot_to_debianinstaller/4 Having tested a Feb 9 with UEFI boot, it seems that the reason that I had set `-vga virtio` in the first place was that UEFI boots were already failing with `-vga std`. I just tried `-vga vmware` and `-vga qxl` and they both seem to work, so it's just `virtio` that's broken recently, and if anyone else has been bitten by this they can probably use `qxl` instead. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1005783: xorg-server: "no screens found" when run under: kvm -vga virtio
Source: xorg-server Version: 2:21.1.3-2 Severity: normal Dear Maintainer, [I'm reporting this against the source because I'm not sure which binary is at fault, but this presuambly related to the bits of xorg that gets put into a udeb and it has been seen while testing on amd64.] Daily Debian-Installer images made after Feb 9 are failing to start X, as seen here: https://openqa.debian.net/tests/42033#step/_boot_to_debianinstaller/4 which conicides with 2:21.1.3-2 hitting unstable, which suggests that is what is responsible for the change. Here is that same test, using the version of D-I built at 2022-02-09 22:16: https://openqa.debian.net/tests/41989#step/_boot_to_debianinstaller/3 which, as you can see, gets to run X. If I set things such that it uses `-vga std` instead of `-vga virtio`, and do a BIOS boot, it is again able to start X: https://openqa.debian.net/tests/42370#step/_boot_to_debianinstaller/3 However, a UEFI boot still fails (with `-vga std`): https://openqa.debian.net/tests/42416#step/_boot_to_debianinstaller/4 BTW One can reproduce this behaviour by running kvm thus: kvm -cdrom debian-testing-amd64-netinst.iso -m 1G (which works, because it's defaulting to: -vga std ) and: kvm -cdrom debian-testing-amd64-netinst.iso -m 1G -vga virtio (which fails for recent versions, and works for versions produced up until Feb 9) If you need an earlier copy of a daily image, for comparision purposes, I have copies at present, and can put them somewhere you can get them. Cheers, Phil.
Bug#1003653: Revision of removal of rename.ul from package util-linux
Helmut Grohne writes: > * You take issue with "rename.ul" as a program name, because it is >inconsistent with other Linux distributions. Regarding this, perhaps we ought to ask util-linux's upstream if they'd be willing to install /usr/bin/rename also as /usr/bin/rename.ul[1], thus allowing people to write scripts that are portable across distros. Cheers, Phil. [1] If that is done with a symlink, I presume we'd have a very slight preference for the actual binary to be called `rename.ul`, but it doesn't really matter how it's done as long as people can rely on rename.ul being present, regardless of distro. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1004021: salsa-CI tests pass
Hi, Following on from this conversation: https://lists.debian.org/debian-devel/2022/02/msg00036.html it occurred to me that I could just get on with it, so I cloned this package on salsa, and enabled the salsa-CI team's pipeline, giving this result: https://salsa.debian.org/philh/wireguard-go/-/pipelines/344811 which shows that the package builds, and that all (other than crossbuild) test pass -- most importantly lintian, piuparts & autopkgtest give passes. Hopefully this will save someone on the FTP team some effort. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1003281: ITP: bakunbak -- Easily .bak a file or folder, then restore it.
Michael Webster writes: > - If there are other packages providing similar functionality, >how does it compare? I've found no other packages (though >it's possible something exists in utility/bin package >bundles that doesn't get mentioned in package descriptions. Could you perhaps explain why one might want to use this in preference to any of the alternatives one might think of -- such as: mv mmv borgbackup (or whatever other decent backup system you use anyway) git (perhaps along with git-annex or git-lfs) Also, do you happen to have any impression of how many users there are of your package at present? (e.g. download stats, messages regarding it, issues opened etc.) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#601203: #601203: tested patch for adding support for recursively including recommends (NORECOMMENDS=0)
Hi
Skimming through this thread as a result of your mail, I noticed the
earlier patch replacing the || 1 with defined ... ? ... and was going to
point out that since 2007 perl's had the // operator for this sort of
thing, which should mean that this would do the trick these days:
my $norecommends = $ENV{'NORECOMMENDS'} // 1;
but then I noticed that the latest patch includes this:
> -my $norecommends = read_env('NORECOMMENDS', 1);
> +my $norecommends = (defined $ENV{'NORECOMMENDS'} ? $ENV{'NORECOMMENDS'} : 1);
which replaces the use of read_env() with the earlier fix, which strikes
me as a backwards step, given that read_env is doing exactly what's
needed here:
=-=-=-
sub read_env {
my $env_var = shift;
my $default = shift;
if (exists($ENV{$env_var})) {
return $ENV{$env_var};
}
# else
return $default;
}
=-=-=-
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1000239: Rescue system won't find root partition, but insists on /usr
Pascal Hambourg writes: > Le 08/12/2021 à 10:49, Philip Hands a écrit : >> >> Is it a problem if /home or /usr/share are left unmounted during rescue? > > /usr/share contains architecture-independent files for many programs > such as bash, grub, os-prober, debconf, dpkg, initramfs-tools... > > How common is it to have a separate /usr/share and what is the rationale > for it ? Not common at all, I'd guess. Back in the days when /usr was not needed to boot, I have occasionally moved part or all of /usr/share (most often just /usr/share/doc) onto another partition and then put a symlink in, in order to make space when it turned out that /usr was filling up and it was too painful to resize. If doing that makes things break during a rescue attempt these days, it seems fairly likely to break during normal boot, so doing that seems likely to be the reason for running the rescue system, in which case you're going to have to mount wherever /usr/share is now yourself, and you really ought to remember how you just broke the system, so that seems like no great hardship. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1000239: Rescue system won't find root partition, but insists on /usr
TomK writes: > This sounds correct, based on my experience with the bug. > I suppose now there are zero ways to definitively determine which > partition is actually root. So maybe a hidden flag (empty) file in > root might do the trick. I'd expect that looking for e.g. /etc/fstab on a file system would pretty reliably tell you that it's a Linux root filesystem. One could also/alternatively look for the presence of /sys and /proc as directories. > But the fact that /usr can be automounted, but nothing else can be manually > mounted afterward is also a problem. I'm assuming that by "automounted" you mean: automatically mounted by the rescue system. If your setup is unusual, then you should probably expect to have to do some work when rescuing it, which for hard to guess additional partitions is going to be going into the installer's shell, and mounting things yourself, which doesn't strike me as particularly difficult (but should be documented, if it isn't already). Is it a problem if /home or /usr/share are left unmounted during rescue? I would say no, unless you've done something unwise, like moving /usr/lib to /home/oops_I_ran_out_of_room_on_usr/lib, and symlinked it back to /usr/lib. > If there was a separate script to do the chroot part, and some manual > interface by which to mount; perhaps the mount command in the rescue > system PATH, the whole thing would be more flexible during the > transition to ro mount for /usr in future Debian versions. mount is definitely in the rescue system's PATH, since (as I mentioned before) one could always work round this problem by dropping into the installer's shell and mounting /usr by hand before then using the to-be-rescued system's shell. Actually, I just spun up the latest netinst (with the /usr mount fix) in rescue mode, and not only does it successfully mount a separate /usr (well done Steve :-) ), but it has mount in the PATH, and I am able to umount & mount /boot/efi, so I'm not sure what you're on about here. > I'm not well versed on Debian policy, so just ignore my input if it > makes no sense. If you find it irritating, it's my ignorance at work, > nothing intentional. No worries, but I think you need to fact-check your assumptions in future. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#1000239: Rescue system won't find root partition, but insists on /usr
Simon McVittie writes: >> 2. Reassign to src:rescue, and fix the rescue system. > > I think this will have to be the answer. See also [0]. I'm certainly not against fixing this issue, but I thought I'd point out that even as things are, its pretty trivial to get into rescue mode. Having just tested it with a separate /usr, all one needs to do is select the actual root partition as you'd expect, then when prompted to execute a shell, select the second option (Execute a shell in the installer environment), then the trick is to mount the /usr partition by hand onto /target/usr e.g.: # mount /var/vfa4 /target/mnt Having done that one can exit that shell, and then select the first option (Execute shell in /dev/...) and you're away. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1000961: btrfs-progs: initramfs can't boot with a raid1 btrfs non-root fs
Package: btrfs-progs Version: 5.10.1-2 Severity: normal Tags: patch Hi, I recently upgraded a system to bullseye that has a btrfs raid1. At around the same time, I switched from raid1 to raid1c3 (over 4 disks), but I'm pretty sure this problem started with the bullseye upgrade. Now, when booting with the supplied /usr/share/initramfs-tools/hooks/btrfs in place, during the boot systemd becomes upset at it's inability to find all the components of the btrfs raid, and stops at the emergency prompt. Since I'm talking about a non-root partition, I'm sure it's possible to work around this by configuring the filesystem as being automounted, so that systemd brings it up later, after it's been found, but that does not address the fact that someone who's not noticed this potential behaviour of btrfs in advance could inocently add a disk to a system, and on configuring btrfs to make use it, render their system unbootable without intervention. Instead, inspired by the way that mdadm seems to be dealing with a similar issue, I patched the initramfs hook script (patch attached). With that patch in place, the system boots without problems. BTW I just set it to install both udev rules because it seemed harmless to do so. If you'd like me to check if just one of them would suffice, just ask. It seems possible that this would also fix #964906. I note that #772752 seems like a related issue, and that seems to have been left unaddressed on the basis that udev is optional. I hope that the fact that this code is conditional on the presence of the udev files means that the same objection does not apply in this case. BTW Here's where I grabbed the patch from: https://salsa.debian.org/lechner/mdadm/-/blob/debian/master/debian/mdadm.initramfs-hook#L53 which was part of this commit: https://salsa.debian.org/lechner/mdadm/-/commit/140efd4862d89f9202ee90abcb4b685d6f7e5460#66d9dc38ed0e19d8774c3aa092fa5e111a550dcc which says that it's been there since 4.1-1, which was in "buster", so it's been in prduction use for some time. Cheers, Phil. -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (99, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages btrfs-progs depends on: ii libblkid12.36.1-8 ii libc62.31-13+deb11u2 ii libcom-err2 1.46.2-2 ii libext2fs2 1.46.2-2 ii libgcc-s110.2.1-6 ii liblzo2-22.10-2 ii libmount12.36.1-8 ii libuuid1 2.36.1-8 ii libzstd1 1.4.8+dfsg-2.1 ii zlib1g 1:1.2.11.dfsg-2 btrfs-progs recommends no packages. Versions of packages btrfs-progs suggests: pn duperemove -- no debconf information -- debsums errors found: debsums: changed file /usr/share/initramfs-tools/hooks/btrfs (from btrfs-progs package) >From 030328a4a897a990b8233a0bc30c47c54431fa34 Mon Sep 17 00:00:00 2001 From: Philip Hands Date: Wed, 1 Dec 2021 14:02:30 +0100 Subject: [PATCH] install udev rules in initramfs hook --- debian/local/btrfs.hook | 10 ++ 1 file changed, 10 insertions(+) diff --git a/debian/local/btrfs.hook b/debian/local/btrfs.hook index 9ac26941..6f37c8dd 100644 --- a/debian/local/btrfs.hook +++ b/debian/local/btrfs.hook @@ -25,4 +25,14 @@ then then copy_exec /sbin/fsck.btrfs /sbin fi + + # Copy udev rules, which udev no longer does + for UDEV_RULE in 64-btrfs.rules 64-btrfs-dm.rules; do + for rules_folder in /lib/udev/rules.d /etc/udev/rules.d; do + if [ -f $rules_folder/$UDEV_RULE ]; then + mkdir -p $DESTDIR$rules_folder + cp $rules_folder/$UDEV_RULE $DESTDIR$rules_folder/$UDEV_RULE + fi + done + done fi -- 2.30.2
Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends
Holger Wansing writes: > Hi, > > Fabian Greffrath wrote (Thu, 21 Oct 2021 12:25:35 +0200): >> I just installed Debian stable in a virtual machine. When I was asked >> during the installation process which "meta-packages" to install I >> left "Desktop Environment" selected but explicitly deselected GNOME. I >> expected to end up with a minimal graphical environment, e.g. X with >> twm and xterm or similar. However, I was surprised to find out after >> installation that indeed the entire GNOME desktop was installed albeit >> me explicitly deselecting it during installation. > > Selecting "Desktop Environment", but not choose one of the displayed > possiblities (like "GNOME", "KDE" and so on) is not the way, how this > dialog was designed, I guess. > > If you want a graphical desktop, select "Desktop Environment" and one of > the options under it; or if you dont't want a graphical UI, deselect all > those options. > There is no way in between of these two. The outcome is the same if one does any of: setting just "Desktop Environment"; setting just Gnome; or setting both of them at the same time. The reason being that setting just "Desktop Environment" results in you getting the default desktop, which currently happens to be Gnome. If there was a way of making "Desktop Environment" be a section heading instead, without it having a checkbox next to it, that would have been done, but AFAIK that is not currently possible with the way that the menu is assembled. Sadly, that's rather misleading. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Bug#994268: os-autoinst: new upstream available (as ever ;-) )
Package: os-autoinst Severity: normal Hi Hideki, As mentioned in this MR on salsa: https://salsa.debian.org/debian/os-autoinst/-/merge_requests/4 there's a UI bug that would be nice to have fixed, as it is since this commit: https://github.com/os-autoinst/os-autoinst/commit/25d52a7f602a744ce2ff5e78956afb204c0b9f5c If you fancy doing an upload, that's great. Alternatively, if you're busy, I'd be happy to do an NMU if that's your preference, or I can add myself to the uploaders and do a normal upload (given that this package is essential to the running of openqa.debian.net, its definitely something that I'm likely to continue paying attention to, so would be happy to co-maintain). Of course, I'd be pulling the latest upstream if preparing a new release, given that they have rolling releases, but FYI the version mentioned in the MR has been in use on openqa.debian.net ever since the MR was openned. Cheers, Phil.
Bug#994160: libmojolicious-plugin-assetpack-perl: newer upstream version (2.13) available
gregor herrmann writes: > On Mon, 13 Sep 2021 01:38:26 +0200, Philip Hands wrote: > >> and here: >> https://github.com/mojolicious/mojo-assetpack/commits/main >> mantenance has now resumed under the aegis of the mojolicious team. > > 2.13-1 is already in Git but has a note in d/changelog: > > WAITS-FOR: libmojolicious-perl 9.0 > > so it's "just" waiting for someone to update Mojolicious to a new > major release. Ah, fair enough. Sorry for the noise then. (I should have thought of looking for that ... I will do in future). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#994160: libmojolicious-plugin-assetpack-perl: newer upstream version (2.13) available
Package: libmojolicious-plugin-assetpack-perl Version: 2.11-1 Severity: wishlist Hi, I notice that this package has new upstream maintenance, which is good since it was previously in limbo having been deprecated by the author in favour of webpack. As can be seen here: https://metacpan.org/dist/Mojolicious-Plugin-AssetPack and here: https://github.com/mojolicious/mojo-assetpack/commits/main mantenance has now resumed under the aegis of the mojolicious team. BTW The only reason I noticed this is that I am packaging openQA at present, so was looking at openSUSE's ticketing system, and there was a thread regarding upgrading openQA to use webpack which concluded with the issue being moot when one of the participants appears to have taken on the role of upstream for assetpack. Cheers, Phil.
