Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
Followup-For: Bug #1029843 X-Debbugs-Cc: a.dalm2...@googlemail.com, p...@akeo.ie, debian-b...@lists.debian.org Control: reassign -1 hw-detect Control: merge -1 1030519 Control: affects -1 raspi-firmware Control: title -1 check-missing-firmware: patch for files with space characters, mediamount and more (with code) Hi Alexander, Thanks for these reports - I was attempting a netboot of the Bookworm RC 2 installer on a Raspberry Pi and ran into the same problem: hw-detect attempting to load firmware files that contain spaces in the filename. I've added Pete on cc - he noticed this issue too a few years ago, while documenting how to install regular Debian 11 on a RPi. Quoting some notes from his guide[1]: > Also, if you did install the Wifi firmware blobs, you may find that you get > the following error during boot: ... > To fix that, simply rename /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry to > /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 > Model B.txt. Let's merge this with your linked bug #1030519 - I agree that the hw-detect package seems to be the location of the relevant scripting[2]. Do you have an account on Salsa[3] to offer fixes back to Debian git repositories? I have some code review / comments about the patches, focusing only on the filename problem to begin with: Do we _need_ to retain the vendor name and model name in the firmware filename? My guess (without being too familiar with the firmware loading process yet) is that it'd be easier to ship a concisely-named file that omit the vendor and model strings, so we'd want a way to map: brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt To the corresponding, already-packaged[4] filename: brcmfmac43455-sdio.txt ...while preferably avoiding adding custom scripting for too many other firmware filenames in future. Where does the long-format filename originate from? It seems unlikely that this should be fixed for Bookworm, but I can offer some assistance with further testing, and hopefully we can improve this for Trixie. And a nitpick: the way this appears in the hw-detect prompt screen in the installer is a bit odd, because spaces in the filenames are replaced with newlines. That might be nice to fix at the same time if we can. Thanks, James [1] - https://forums.raspberrypi.com/viewtopic.php?t=282839 [2] - https://salsa.debian.org/installer-team/hw-detect/-/blob/f76d36b65aa14a14497f5ef57c9721f313ea98e6/check-missing-firmware.sh#L154-187 [3] - https://salsa.debian.org/ [4] - https://packages.debian.org/bookworm/all/raspi-firmware/filelist
Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname
Source: preseed Version: 1.115 Severity: important Tags: d-i Dear Maintainer, This bugreport is a subset/related-to bug #1031643, also in preseed. When the 'hostname' preseed alias for 'netcfg/get_hostname' is provided to Bookworm's RC 2 installer as a kernel command-line argument, the value that it contains unexpectedly takes higher precedence over a hostname received from DHCP, contrary to the Installation Guide documentation[1] in combination with the corresponding netcfg documentation[2]. Conditions: * Preseed alias 'hostname' configured on the kernel command-line * There is a DHCP server on the installation-target's network that will provide a hostname Expected behaviour: * Installer does not ask for installation-target hostname * Installation-target hostname is received and configured using DHCP Actual behaviour: * [good] Installer does not ask for hostname * [bad] Hostname is configured from the command-line, ignoring the DHCP-negotiated hostname. * This is similar to 'netcfg/hostname' -- a different setting from 'netcfg/get_hostname'. Context: Since Linux 6.0, a 'hostname=...' parameter provided in the kernel command-line is no-longer loaded into the init process environment as a variable, but is instead used to set the hostname of the running system (skipping the need for userspace tooling to achieve that). That caused a conflict for the preseed aliases in the Debian Installer, because one of the aliases is also 'hostname', mapped to 'netcfg/get_hostname'. The fix applied in #1031643 loads the 'running system hostname' into the environment if it is non-empty and not equal to '(none)'. This allows unattended installs to work again. The 'netcfg' component that determines the system hostname (prompting for it from the operator if required) to be installed will prefer a non-empty hostname (as long as it is not the literal string '(none)') over one provided by DHCP in this block of code: https://sources.debian.org/src/netcfg/1.185/dhcp.c/#L578 Thanks, James [1] - https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-aliases [2] - https://sources.debian.org/src/netcfg/1.185/debian/netcfg-common.templates/?hl=145#L160
Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname
On Mon, 1 May 2023 at 17:53, Cyril Brulebois wrote: > > James Addison (2023-05-01): > > I understand that line of thinking, but we note that we have already > > received feedback on Salsa[1] from a user whose Bookworm installation > > workflow has been affected, and confirmed that the reported problem > > exists. > > And that user mentioned hostname=unassigned-hostname which would be > addressed if we were to implement what I mentioned? Yep, fair point! > Initially it looked like specific values were expected to lead to a > particular behaviour, but if we've been encouraging people to expect > *any* fallback values specified there, that's indeed another story. > > (I had mentioned before “unassigned-hostname” wasn't to be seen in any > packages but “unassigned-domain”/“unnassigned-domain” definitely have > some specific handling.) I do see that guestfs-tools references[1] them, and I suppose other downstream software could do as well. But within the installer's components, I don't think that they have any special meaning. > I have some pending yet unrelated things to investigate on the preseed > side; I'm not sure I'll want to be testing each and every possible > combination (esp. tweaking the configuration of the DHCP server behind > the virtualization layer), but I should be able to test the water. Totally reasonable, yep. I'll try to get familiar with the process of rebuilding the installer's initrd. Currently I think that a relevant patch should: * Unset the hostname, or set the hostname to '(none)', so that the installer's netcfg ignores[2] and is unaware of an install-time hostname. * Within env2debconf, attempt to find a hostname specified on the kernel command-line: * The parameter may appear as a 'hostname=value', or 'hostname?=value' key=value pair. * The parameter must appear strictly before any '---' delimiter_ in the line. * If a hostname was found: * Create a local 'hostname' variable within the env2debconf' script containing the hostname's value. * Ensure that the 'seen' flag is assigned appropriately: * The value should be empty if the hostname was matched using 'hostname=value'. * The value should be non-empty if the hostname as matched using 'hostname?=value'. * If no hostname was found: * Do nothing. As I wrote up those criteria, they expanded and became more complicated than I initially realized, so perhaps there could be further hidden complexity here. I'll do my best to prepare and test a patch anyway. [1] - https://sources.debian.org/src/guestfs-tools/1.48.3-4/customize/hostname.ml/?hl=125#L129 [2] - https://sources.debian.org/src/netcfg/1.185/dhcp.c/?hl=578#L580
Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname
On Mon, 1 May 2023 at 16:00, Cyril Brulebois wrote: > James Addison (2023-05-01): > > Conditions: > > > > * Preseed alias 'hostname' configured on the kernel command-line > > * There is a DHCP server on the installation-target's network that will > > provide a hostname > > > > Expected behaviour: > > > > * Installer does not ask for installation-target hostname > > * Installation-target hostname is received and configured using DHCP > > > > Actual behaviour: > > > > * [good] Installer does not ask for hostname > > * [bad] Hostname is configured from the command-line, ignoring the > > DHCP-negotiated hostname. > > * This is similar to 'netcfg/hostname' -- a different setting from > > 'netcfg/get_hostname'. > > Given the proximity of the tentative Bookworm release, my gut feeling > would be to special-case the hostname=unassigned-hostname setting that's > been documented since at least 2004, and limit “unsetting hostname” to > this particular case. > > This should: > 1. be good enough for anyone having followed the example preseed from > any point in the past; > 2. and equally importantly: limit possible side-effects. > > If that's not the case for (1), we should get bug reports with details > about what people have actually been doing, and whether it makes sense > to unset it unconditionally. If that's the case, we can let this thing > mature in unstable/testing post-Bookworm, and once we're absolutely > certain this isn't going to regress in some other weird way, we can > consider backporting this to Bookworm, via a point release. I understand that line of thinking, but we note that we have already received feedback on Salsa[1] from a user whose Bookworm installation workflow has been affected, and confirmed that the reported problem exists. One datapoint isn't huge, but it's non-zero - and I'd expect that any installation using the 'hostname' preseed alias in combination with DHCP-as-hostname-provider would be similarly affected. The bug here is essentially that the 'hostname' alias used to provide a fallback value, and in RC 2 d-i is used as the source of the primary value (ignoring DHCP). If we know that that change has taken place, I think that we should either document it, or attempt to restore the existing behaviour. The possibility about introducing other regressions with any further changes is a valid point.. I'm not sure how best to address that, other than testing the results in various configurations. It feels to me like 'installer begins running without its own hostname' was likely a reasonable baseline assumption before Linux 6.0 began reading the same-named 'hostname' parameter, and so as a result it feels like unsetting the hostname early in the installer initialization would be safe (maybe even a good idea, to reduce a source of input variation between install sessions). [1] - https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/25
Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored
Source: preseed Followup-For: Bug #1031643 As requested, the hostname-param-ignores-DHCP regression bug has been filed separately: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035349
Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Mon, 1 May 2023 at 03:00, Cyril Brulebois wrote: > Diederik de Haas (2023-04-30): > > I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that > > is its name in the upstream repo: > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > > Yes please. Agreed. I'm trying to figure out the reason that the kernel module requests the verbose-style firmware filename (that include spaces) in the first place. In the case of the RPi B, the kernel source contains a device-tree file for the brcm2711, the relevant hardware. The 'compatible'[1] field of the brcm2711 device-tree structure file includes the string "raspberrypi,4-model-b" -- matching one of the files in linux-firmware.git's brcm directory -- but the 'model'[2] field, containing "Raspberry Pi 4 Model B", could be the one that's used when the firmware file request is issued when the module loads (?). Also, the brcmfmac kernel module code mentions[3] that it can load board-specific firmware file paths. I'm not yet sure whether that's relevant (either now, or in future). > Diederik de Haas (2023-04-30): > > And that's exactly what happens or will happen. Even though the RPi4 > > filename > > doesn't contain spaces, there are several in the `brcm` directory that do. > > I didn't check other directories, but I'd expect that filenames with a > > space is > > NOT an anomaly. Since more files with that pattern are appearing upstream in linux-firmware.. yes, slightly reluctantly it does seem that this will be needed. On Mon, 1 May 2023 at 03:00, Cyril Brulebois wrote: > We won't rewrite hw-detect for bookworm, nor will we make it “shellcheck > compliant”. Now is definitely not the time to deal with such things, and > yes I'm going to call system files (e.g. package-shipped) with spaces an > anomaly. > > People are much than welcome to put energy into making hw-detect more > robust in the future, but even knowing some bits about it, it's some > kind of a maze and I *really* don't want to lose any feature for the > generic cases (non-crazy filenames). I'd generally agree with all that. For robustness, and when it's safe to, it'd be nice to resolve both issues (firstly to ensure that the correct firmware filename is being requested in these cases -- maybe it already is, I'm still trying to determine whether that's a bug -- and secondly to support spaces in firmware filenames in hw-detect). [1] - https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L9 [2] - https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L10 [3] - https://elixir.bootlin.com/linux/v6.1/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c#L772
Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored
Source: preseed Followup-For: Bug #1031643 X-Debbugs-Cc: car...@debian.org, a...@debian.org, freyerm...@physik.uni-bonn.de Hi folks, This is nitpicky, but I think there is an important-ish further detail to report. The fix applied does repopulate the 'hostname' variable so that env2debconf can read from it and place it into the 'netcfg/get_hostname'[1] preseed variable; so far, so good. However: the hostname in the running Debian installer masks the intended behaviour of 'netcfg/get_hostname', because netcfg's DHCP logic prefers[2] to read the running system's hostname, when it is non-empty. I've confirmed this behaviour by netbooting from the Bookworm RC 2 installer; DHCP configuration of a hostname is ignored when the command-line hostname is present. (note: a similar setting, 'netcfg/hostname' is available that takes precedence over DHCP[2] hostname values, but it's a separate setting, and is not our documented[3] behaviour of the 'hostname' preseed alias) Suggestions: This was found following some related documentation discussion[4] on Salsa. In that discussion, Martin Samuelsson suggests a fix that I think should work: We should (un)set the d-i system's hostname to the 'empty' hostname early in the installer session. That could happen in env2debconf -- or it could be placed even earlier in the installer scripts (since it's only relatively recently that Linux 6.0 began reading a hostname, we should be confident that d-i works OK without one configured). I'm doing some testing to confirm the fix currently. Thanks, James [1] - https://sources.debian.org/src/netcfg/1.185/dhcp.c/#L578 [2] - https://sources.debian.org/src/netcfg/1.185/debian/netcfg-common.templates/?hl=145#L160 [3] - https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-aliases [4] - https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/25
Bug#1035392: installation-reports: Installation Report: Bookworm RC2: Raspberry Pi 400 (netboot)
Package: installation-reports Severity: normal Tags: d-i Boot method: network Image version: [2023-04-28] Bookworm Release Candidate 2 Installer Date: 2023-05-02 Machine: Raspberry Pi 400 Partitions: Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs 1871816 0 1871816 0% /dev tmpfs tmpfs 386544 704385840 1% /run /dev/mmcblk1p2 ext4 14689724 4192988 9728736 31% / tmpfs tmpfs 1932704 0 1932704 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock /dev/mmcblk1p1 vfat524008 119424404584 23% /boot/efi tmpfs tmpfs 386540 44386496 1% /run/user/1000 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [O] Detect media: [E] Load installer modules: [E] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [E] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[O] Comments: Although the list of problems in this report might seem lengthy and arcane, I enjoyed the installation process and think that with a few small fixes, the rough edges can be removed. I am writing this report from an LXDE environment on the installed system. This was largely an experiment to determine how feasible it is to bring up a Raspberry Pi 400 over the network and to install Debian Bookworm from there using the standard Debian Installer process. The TFTP server was dnsmasq with a fairly minimal configuration based on Debian's PXE-boot wiki page[1]. In addition to Debian Bookworm's netboot.tar.gz[2] file (for RC2 at the time of download), the EDK2 UEFI firmware[3] v1.34 was extracted to the /srv/tftp directory. The only customized dnsmasq setting required was: pxe-service=0, "Raspberry Pi Boot" Additional firmware for use during the install session was provided by unpacking a firmware.tar.gz[3] file onto a FAT32-formatted USB drive. Problems: * Firmware for the brcmfmac kernel module was not found on the USB drive (but is present). This may be related to #1029843 * Workaround: extracted the .deb contents on another system, placed them onto the USB drive, and then used one of the available virtual consoles (ctrl-alt-F1 or ctrl-alt-F2) on the install host to mount the USB drive and copy the firmware files to /lib/firmware/brcm before rmmod'ing and modprobe'ing the kernel module. * [minor] The hw-detect/load_firmware dialog box included an extraneous newline within the displayed filename(s) for which loading failed. * The microSD card intended as the installation disk did not appear under /dev/mmc* when the install began. * Workaround: rmmod'd and modprobe'd the sdhci* kernel modules; after doing that, the disk was detected and available under /dev * After completing the installation and rebooting, the first boot from the install disk failed. The Raspberry Pi's diagnostics console showed a 'Firmware not found' message. * Fix: this seemed to be due to a lack of Pi-compatible firmware on the ESP (EFI System Partition) of the install disk. To resolve the problem, the same EDK2 UEFI firmware used on the dnsmasq ntboot server was unpacked into the ESP partition from another system (by removing the SD card from the Pi and placing it into the other machine). * After successfully reaching the EDK2 UEFI boot manager, the system appeared to pause without reaching the expected next-stage GRUB bootloader. * Fix: this appears to be due to the default unpacked EDK2 UEFI bootmanager being unaware of the GRUB install on the same ESP partition. That's understandable, because GRUB was installed before the EDK2 UEFI. The problem was solved by using the built-in boot menu management in the EDK2 UEFI to add an entry to boot into Debian. In particular, this involved creating a file-boot entry that runs 'shimaa64.efi'. That concludes the installer-related issues; with those problems worked-around / resolved, the system booted correctly. There was one more problem that may not be installer-related: * The 'raspi-firmware' package failed to configure correctly during 'apt install', with an exit code 1 and asking whether the /boot/firmware path had been mounted. [1] - https://wiki.debian.org/PXEBootInstall?action=show=DebianInstaller%2FNetbootPXE#Another_Way_-_use_Dnsmasq [2] - https://deb.debian.org/debian/dists/testing/main/installer-arm64/current/images/netboot/netboot.tar.gz [2] - https://github.com/pftf/RPi4/releases/tag/v1.34 [3] - https://cdimage.debian.org/cdimage/firmware/bookworm/20230424/firmware.tar.gz -- Package-specific
Bug#1033294: lintian: detect and warn about Python 2 related paths within packages
Package: lintian Followup-For: Bug #1033294 X-Debbugs-Cc: patrice.dur...@gmail.com, debian...@lists.debian.org As guidance for potential contributors: it looks like the logic for the existing 'python-module-in-wrong-location' check (mentioned in the mailing list thread) is here: https://sources.debian.org/src/lintian/2.116.3/lib/Lintian/Check/Languages/Python.pm/?hl=392#L317-L370 Each lintian check should include accompanying test coverage; there is some Debian package scripting to create good and bad install paths that are suitable for test purposes here: https://sources.debian.org/src/lintian/2.116.3/t/recipes/checks/languages/python/files-python-modules/build-spec/debian/install
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Package: rustc Followup-For: Bug #973414 X-Debbugs-Cc: fierel...@gmail.com After a few false starts, I've built libstd-rust-dev:i386 targeting i686 in the way I'd expected (and to clarify: the interpretation I'm using is to match Debian's baseline and a strict-ish reading of what P6 / i686 was when originally specified). Editing the 'd-rustc-i686-baseline.patch'[1] to specify "i686" instead of the current "pentiumpro" achieved the result I was looking for: absence of NOPL in the libstd libraries included when users compile statically-linked Rust code. I'll double-check the results soon, and go back to see how that result affects the original bugreport here. My hope is that it helps to verify that the rustc target spec is where we should be looking, but further work may be required. Caveats / todo items: * Check that "i686" is a valid CPU (not architecture) target * Ideally, test this on relevant hardware (non-NOPL, non-SSE2?) Apologies, Fierelier - I didn't see your update until after these results arrived. Your links look relevant though, yep. I _think_ Debian has patched both those locations; I'll check in detail within the next day or two. [1] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/patches/d-rustc-i686-baseline.patch/
Bug#1026277: Quadrilateral Cowboy on Debian
Hi Brendon (and with the relevant Debian bug thread on cc), I've uploaded a copy of the packaged quadrilateralcowboy game source - with some small modifications and fixes, including ARM64 support - to the 'mentors.debian.net' pre-review site at https://mentors.debian.net/package/quadrilateralcowboy/ It isn't eligible for inclusion in the upcoming Debian 12 "bookworm" release, but it's possible it could be included in Debian "trixie" (the next release.. each is named after a Toy Story character), if it or another packaging attempt passes review. To confirm: the package contains only the game engine, without any game data; there is, however, separate support provided to make it easier for users with Steam accounts to install the game data if they have already purchased it. Thanks, James
Bug#1021292: dpkg-buildflags: Please add support for pointer authentication on arm64
Package: dpkg-dev Followup-For: Bug #1021292 X-Debbugs-Cc: woo...@wookware.org, debian-de...@lists.debian.org > We decided that the best thing to do was create a new hardening flags > feature called 'branch' to add to the existing set. This enables > -mbranch-protection=standard on arm64, and > -fcf-protection on amd64 After reading various threads (such as this[1] Xen thread, and from there a related[2] Linux kernel thread) about fcf-protection: Could we consider ensuring NOTRACK_EN=0 and -fno-jump-tables if-and-when making this change? (I'm not sure yet, but the CET 'notrack' instruction seems unusual to me, and although I hope to find out and become convinced that it's safe and worthwhile, it seems like a potential loophole in the safety that CET could offer. my understanding is that it's intended to allow certain limited callsites to invoke functions that do not begin with branch-target (endbr64) instructions) [1] - https://lists.xenproject.org/archives/html/xen-devel/2022-03/msg00522.html [2] - https://lkml.org/lkml/2022/3/7/1068
Bug#1033539: RFP: edit-tf -- teletext frame editor for use within web browsers
Package: wnpp Severity: wishlist * Package name: edit-tf Version : 1.0.0 Upstream Contact: Simon Rawles * URL : https://edit.tf/ * License : GPL-3 Programming Lang: HTML, JavaScript Description : teletext frame editor for use within web browsers edit-tf is an editor that helps people to design frames of Teletext content from within a web browser. A hosted version of the application is available at https://edit.tf/ and the source code is available at http://github.com/rawles/edit.tf/
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Followup-For: Bug #973414 X-Debbugs-Cc: fierel...@gmail.com On Mon, 3 Apr 2023 23:07:35 +0200, Fierelier wrote: > * In terms of confusion: I think using the Rust i586 toolchain, and > building for i586 with Rust might be less confusing, because altering > the i686 definitions for rustc will make it act differently compared > to other platforms. People could compile code for i686 on Debian, get > working code, but then if someone else does the same on another > distro, the produced binary would not work on the same devices. That's a fair point, yep; matching upstream behaviour is often the simplest and most understandable approach. It seems the choice is between using an upstream-compatible definition, or an inter-toolchain-compatible definition (are there any other choices? I did notice use of per-extension feature flags in some build configurations. they don't appear widely standardized though, or at least that's my initial sense). > Although, I think changing the i686 definition down, like you did, is > the most accurate way to achieve the goal, and is what I personally > think should be mainline. If the accurate definition proves itself on > Debian, it might find itself in mainline Rust, too, which would be > awesome. Thanks - and thank you for re-stating the intent of the patch. (I confusingly wrote "my personal preference" instead of "my personal opinion" in a previous comment) I wouldn't want Debian's choice to be intended as a way to influence Rust's upstream choices. It'd be more a case of "who is comfortable using a divergent definition of "i686" for longer before their respective communities call them out on it" (in other words: each project can take their own path, and each project can decide how to proceed, as they usually would).
Bug#1033564: pip install changes should be documented
Package: release-notes Followup-For: Bug #1033564 X-Debbugs-Cc: anar...@debian.org Hi Antoine - this seems related to - perhaps an extension of? - some discussion on Salsa: https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/142 (I'll admit that I don't tend to use 'pipx' either. I don't know much about it though)
Bug#998059: sphinx: LANGUAGE environment variable inconsistently affects output of objects.inv
Package: python3-sphinx Followup-For: Bug #998059 X-Debbugs-Cc: la...@debian.org Control: found -1 4.5.0 Control: notfound -1 5.0.0 Dear Maintainer, My updated understanding is that this issue was fixed[1] in version 5.0.0 of Sphinx. I've documented[2] the process I followed using 'git bisect' to determine when the fix was introduced (between versions 4.5.0 and 5.0.0 of sphinx). Since my previous comment, the (I now believe, incorrect) changeset that I'd forwarded to resolve the problem in more recent Sphinx versions was accepted, so I've offered an explanation and revert changeset that I hope may be acceptable before the upcoming 6.2.0 release. Although it could be time-consuming to understand and verify my findings, if someone has time to do that then I'd be grateful (I've confused myself a few times while working on this bug, and I don't trust my findings enough yet to close it). Thank you, James [1] - https://github.com/sphinx-doc/sphinx/commit/e4e58a4f2791e528cdaa861b96636a1e37a558ba [2] - https://github.com/sphinx-doc/sphinx/issues/9778#issuecomment-1501172176
Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
Followup-For: Bug #994274 X-Debbugs-Cc: lu...@schwaighofer.name, pk...@debian.org, timo.lindf...@iki.fi Hi Lukas, Philipp, Timo, Does reverting the removal[1] of 'efisetjmp.h' from 'efi.h' in src:gnu-efi produce successful results? That occurred between gnu-efi versions 3.0.9 and 3.0.13 if I read the upstream history correctly. (revert patch attached for convenience, although I'm not yet going to add the corresponding tag to this bug until we confirm whether it's useful) And if that headerfile does seem relevant: this issue may affect src:shim too. Thanks, James [1] - https://sourceforge.net/u/lslrt/gnu-efi/ci/486ba3c3bdd147b7d98159b9e650be60bce0f027/ --- a/apps/setjmp.c +++ b/apps/setjmp.c @@ -1,7 +1,6 @@ #include #include -#include EFI_STATUS efi_main( --- a/inc/efi.h +++ b/inc/efi.h @@ -75,6 +75,7 @@ #include "efiudp.h" #include "efitcp.h" #include "efipoint.h" +#include "efisetjmp.h" #include "efishell.h" #endif
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Package: rustc Followup-For: Bug #973414 > Today I plan to rebuild rustc on Debian i386 with RUSTC_FLAGS (different to > RUSTFLAGS) configured for i686 during the build. That's inspired by a comment > here: https://github.com/rust-lang/rust/pull/31110#issuecomment-174327810 > > To implement that, I've temporarily added RUSTC_FLAGS to the list of > per-architecture buildflags accepted by dpkg-buildflags on my system. I don't > know whether that's the best place to put that configuration, but it would > allow it to be configured on a per-architecture basis in Debian. That didn't work; the resulting libraries continue to contain NOPL opcodes, indicating that their C components were not compiled to the correct baseline. The environment variable was definitely exported to the build process, so it seems likely that I chose an incorrect environment variable name and/or value.
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: debian-toolch...@lists.debian.org, martin-eric.rac...@iki.fi,
fierel...@gmail.com
Control: severity -1 serious
Control: tags -1 patch
A caution: there's a good chance I'm wasting everyone's time with this patch
and much of the preceding commentary about it.
However, I'd feel more comfortable raising this commotion about it and then
being talked down reasonably than I would if I didn't attempt to apply what I
feel is a fix.
Worth noting: it could still be an incorrect fix; this area is somewhat beyond
my expertise. That's a reasonable reason to reject it too, because I don't
think anyone would want it to be applied and cause long-term problems.
Anyhow: Dear Maintainer, please find attached a patch that may address this
issue that I feel may be release critical for bookworm, per Debian's
architecture policy guidelines.
Description: match rustc i686 specification to Debian 9 i386 baseline
Since Debian 9 (stretch), the baseline architecture specification for
i386 package has been the i686 (Pentium P6), with neither MMX nor SSE
instruction set extensions.
.
This is a lower baseline than the Pentium 4 default in Rust 1.63,
and also lower than the Pentium Pro default previously specified in
Debian's packaging for that version.
.
Upstream's definition of i686 appears to have converged on a
different meaning, so this patch doesn't currently seem to be worth
offering upstream (author's opinion here).
.
There are some downsides to this patch; performance of the Rust
tooling and code built with it on Debian i386 will be suboptimal
when using the defaults. Again, author's opinion: I think it's
worthwhile so that Debian is viable on baseline hardware.
.
Ref: https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
Author: James Addison
Last-Update: Wed 29 Mar 18:24:38 BST 2023
Bug: https://bugs.debian.org/973414
Forwarded: not-needed
X-Not-Forwarded-Because: upstream consensus on i686 differs
---
---
rustc-1.63.0+dfsg1.orig/compiler/rustc_target/src/spec/i686_unknown_linux_gnu.rs
+++ rustc-1.63.0+dfsg1/compiler/rustc_target/src/spec/i686_unknown_linux_gnu.rs
@@ -2,7 +2,7 @@ use crate::spec::{LinkerFlavor, StackPro
pub fn target() -> Target {
let mut base = super::linux_gnu_base::opts();
-base.cpu = "pentium4".into();
+base.cpu = "i686".into();
base.max_atomic_width = Some(64);
base.pre_link_args.entry(LinkerFlavor::Gcc).or_default().push("-m32".into());
// don't use probe-stack=inline-asm until rust#83139 and rust#84667 are
resolved
Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements
Followup-For: Bug #1033065 X-Debbugs-Cc: ballo...@debian.org, p...@debian.org On Mon, 20 Mar 2023 13:31:37 +0800, Paul Wise wrote: > > > Perhaps lintian could add classification tags for the relevant CPU > > > instructions and then the i386 port could have extra autopkgtest nodes > > > that only process the packages detected by lintian. On Mon, 20 Mar 2023 12:05:24 +, James Addison wrote: > > That's not a bad idea. Are there any reasons that that might _not_ be a > > good > > idea before filing a wishlist bug? (performance, implications of scanning > > binary packages, ...) On Mon, 20 Mar 2023 20:58:28 +0100, Bill Allombert wrote: > This seems logistically problematic. > Is lintian actually ran on i386 binaries anymore ? > lintian.debian.org only lists reports for amd64 packages. Yep, some i386 binary package analysis does still take place I believe, based on running an UDD query[1] that found results with a recent version of lintian (since 2023-02-05) including some i386 shared libraries in the output. The data on lintian.debian.org (detagtive) appears out-of-date, though. There is an existing issue report[2] about that. > I am not sure it is worth the trouble, frankly. I do not see what this would > bring us. A lintian check could help to notify maintainers about architecture baseline compatibility issues. Running autopkgtests for those could help to (although is not guaranteed to) confirm whether the identified packages are broken, without rerunning tests across all packages. [1] - https://udd.debian.org/lintian/?email1gcc-12-cross==html_information=on_tag=static-library-has-unneeded-sections#all [2] - https://salsa.debian.org/lintian/detagtive/-/issues/22
Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386
Package: rustc
Followup-For: Bug #973414
X-Debbugs-Cc: fierel...@gmail.com
Hi Fierelier - thanks for your previous comment, here's my reply, slightly
later than I'd hoped:
On Wed, 29 Mar 2023 00:10:52 +0200, Fierelier wrote:
> - issue 1: i386, i486, i586, i686 are considered as Pentium 4 in LLVM,
> which might be relevant if Rust is compiled with it:
> https://github.com/llvm/llvm-project/issues/61347
Yep, this is relevant.
Debian does currently use LLVM for rustc builds, yep. Along the way I found
the rustc build README.Debian[1] that's a very useful explanatory guide.
To be slightly more specific, currently LLVM 14 is in use, and some of the
build options for it (including that version number[2]) are placed into a
config.toml[3] file that's used by the rustc build process (x.py).
Included in Debian's patches for the LLVM 14 toolchain is a patch to adjust
the Pentium 4 target you mention down to i686:
https://sources.debian.org/src/llvm-toolchain-14/1%3A14.0.6-12/debian/patches/clang-baseline-fix-i386.patch
> - issue 2: Rust considers i686 as Pentium 4, and i586 as Pentium:
> https://github.com/rust-lang/rust/issues/82435
Also relevant, yep. Some of the comments, and the current title that I read
for that thread ("i686 target spec disagrees with downstream definitions")
discuss the core of the problem here.
There are reasons for some people to want the definition of i686 to shift
forward, perhaps towards the bulk of the processors within that family that
are in everyday use.
And there are reasons to want to keep the definition to its original, most
compatible specification (although as found on my NOPL learnings, even in the
early days of the P6 there was some divergence there).
I don't like neither wasted CPU time, nor wasted electricity, nor wasted human
time spent reading and understanding these issues, but it's difficult (for me,
at least) to see a remedy that is optimal for all of those. Even writing an
additional paragraph about this introduces overhead for future readers.
> - When building the Rust toolchain itself, if Debian uses LLVM for it,
> it might be a good idea to set the CPU target explicitly to pentiumpro
> in LLVM's flags (fix issue 1) (It could also be a good idea to set
> this for LLVM in general if possible, if not already done so). -- Also
> compile the i586 Rust toolchain, not the i686 one (fix issue 2).
It looks like that CPU target adjustment suggestion was accepted in #908561 in
September Y2018.
For my investigation regarding the presence of NOPL -- an instruction that is
unavailable[4] on a limited number of i686 CPUs -- reducing that target further
to from "pentiumpro" to "i686" appears to resolve the issue.
That, I expect, also has the side-effect of omitting MMX instructions from the
set of valid instructions that the Debian i386 Rust toolchain may output. So
there is at least one downside there.
My personal preference, that may or may not be aligned with Debian, is that
switching to build from the Rust i586 toolchain, while it would be a valid fix,
could cause confusion; it'd be a form of ecosystem fragmentation, and puzzling
for humans in particular to reason about.
Arguably that could be worthwhile puzzlement -- "why do Debian's Rust packages
and libraries refer to i586?", followed by learning about the situation and
knowledge spreading. Is that better than referring to i686 as with other
toolchains within Debian, yet having some divergence from what upstream's i686
means?
In honesty, I don't know. But I would like people who install Debian i386 on
all systems within Debian's i386 baseline to be able to use those computers and
the Debian-packaged software as intended, as completely as possible, and to me
it feels like changing the policy baseline or changing to i586 are beyond my
skills (certainly in time for bookworm), so I'm offering the best option that I
can.
Thanks again,
James
[1] -
https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/README.Debian/#L28-L32
[2] - https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/rules/#L31
[3] -
https://sources.debian.org/src/rustc/1.63.0%2Bdfsg1-2/debian/config.toml.in/#L30-L43
[4] - https://bugzilla.redhat.com/show_bug.cgi?id=579838#c32
Bug#1005863: binutils: invalid opcode for Geode LX on i386
Followup-For: Bug #1005863 X-Debbugs-Cc: ballo...@debian.org Control: reassign -1 binutils 2.38-1 Reassigning this from package 'gcc' to 'binutils': It looks like it is GNU binutils[1] (and in particular, the GNU assembler) that is responsible for producing the assembly opcodes for a binary compiled with gcc. On Mon, 20 Mar 2023 11:27:40 +0100, Bill Allombert wrote: > From a purely engineering perspective, without a way to address this problem, > increasing the severity will not achieve much. Yep, agreed. I'd like to learn more about technical fix feasibility before adjusting the severity. There was a commit[2] in Y2010 of GNU binutils to stop emitting NOPL on (32bit) i686 targets.. I'm wondering if it's possible that a regression since then may have caused the opcodes to reappear. (it continues to be equally likely that I've completely misunderstood and am creating noise without making any useful progress) [1] - https://www.gnu.org/software/binutils/ [2] - https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2210942396dab942a86cb6777c705554b84ebb0e
Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements
Package: release-notes Followup-For: Bug #1033065 X-Debbugs-Cc: p...@debian.org, ballo...@debian.org Dear Maintainer and Éric-Martin (with Bill on carbon copy), Please find linked below a previous release note from Debian 9.0 (stretch) that we could use to provide relevant user guidance: https://www.debian.org/releases/stretch/i386/release-notes/ch-information.html#i386-is-now-almost-i686 (I discovered this while reading a 2019 mailing list discussion[1]) On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote: > Broadly speaking, detecting non-baseline instruction usage isn't > possible without false positives, because the program could use runtime > instruction selection based on the current CPU to avoid currently > unavailable instructions, while the binary would still contain those > instructions for use on other CPUs. > > https://wiki.debian.org/InstructionSelection > > Of course you could do the scanning and then use autopkgtests or manual > tests to find out if the found programs work on the relevant CPUs. Thank you, that makes sense. I've run some ad-hoc script analysis[2] on a recent mirror of the bookworm i386 archive, and it appears that ~20% or so of packages are potentially affected in that (so, in all likelihood, Debian is currently uninstallable and/or unusable on Geode LX). In theory I would like to run a comparative analysis against the snapshot archives from previous points in time, but am not sure whether I'll get around to doing that. On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote: > Perhaps lintian could add classification tags for the relevant CPU > instructions and then the i386 port could have extra autopkgtest nodes > that only process the packages detected by lintian. That's not a bad idea. Are there any reasons that that might _not_ be a good idea before filing a wishlist bug? (performance, implications of scanning binary packages, ...) [1] - https://lists.debian.org/debian-user/2019/04/msg01091.html [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005863#48
Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings
Followup-For: Bug #1032347 Control: archive -1
Bug#1032351: wireplumber.service: fails to start, reporting 'Failed to connect to session bus'
Followup-For: Bug #1032351 Control: archive -1
Bug#1030530: python3.10 should not be in bookworm
Package: python3.10 Followup-For: Bug #1030530 Perhaps a strange or seemingly off-topic question, but: is it fair to assume that Python 3.11's improved (typical) performance characteristics should likely result in similar-scale energy consumption reductions? (I'd be likely, although cannot guarantee, to offer assistance -- outside of the Debian project and packaging process -- upstream to DFSG-compatible Python packages that would consider Debian's removal of Python 3.10 from bookworm a blocker, depending on the circumstances and my own capacity and willingness to help)
Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors
Source: openjfx Followup-For: Bug #1026962 Could the following build-related scripting be something to do with it? - https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm#L494-499 - https://salsa.debian.org/java-team/openjfx/-/blob/debian/11.0.11+1-1.1/modules/javafx.web/src/main/native/Tools/Scripts/build-webkit#L300-305 (perhaps something about the way that numberOfCPUs is being evaluated on s390x hosts isn't matching the expectations of the build script)
Bug#1030678: dhewm3: An additional copyright entry may be appropriate
Package: dhewm3 Version: 1.5.2+dfsg-1 Severity: normal Dear Maintainer, I've recently been looking at some of the dhewm3 upstream source code as part of packaging another game based on dhewm3 (quadrilateralcowboy), and today I've been re-reviewing the copyright entries in my package. There isn't currently a copyright entry for dhewg (the creator and early author of the dhewm3 fork) in either my package or dhewm3. Although dhewg made significant contributions and changes to the codebase, there _are_ some files that they have not modified, and those have a variety of filename extensions and exist in a variety of directories. Suggested resolution: >From comparing commit d57f438db1abb86d5b719abab572420c02f1fc9b (latest upstream at time of writing) to commit 1559fc31d6d9fe0d48848e5c97b07e470b79 (last pre-fork commit), I believe that every 'CMakeLists.txt', '.c', '.cpp', '.h', '.m4', and '.py' file in the codebase was updated by dhewg - and so it may be fair to add a second glob file stanza (after the first, existing iD Software wildcard glob) to attribute files matching those to both iD Software and also dhewg. That won't do a perfect job of attributing all of their changes -- something that could involve lengthy analysis and might result in an excessively detailed copyright file -- but I think that it would be an improvement and should cover the vast majority (if not all) of the elements that produce the resulting dhewm3 binaries distributed in Debian. I'm planning to apply the suggested resolution to my packaging of and could open an equivalent merge request for dhewm3's repository on Salsa too, if that makes sense to you. Thanks, James [1] - https://salsa.debian.org/jayaddison/quadrilateralcowboy/
Bug#1028125: wrong source-contains-prebuilt-windows-binary for GB18030-encoded text file
Package: lintian Followup-For: Bug #1028125 Hi Rene, Do you know whether this is a regression (as in: did lintian/file previously correctly identify the file type for GB18030.txt)? There seems to be some code adjustments in libmagic recently, in particular related to PE32 file types. I didn't manage to understand the reasoning and effect of those changes, but am wondering if they could be related to this bug. Thanks, James
Bug#791506: [www.debian.org] Content negotiation doesn't work properly with pt_BR at the Release Notes web page
Package: www.debian.org Followup-For: Bug #791506 Control: retitle -1 [www.debian.org] Release notes are translated per-language, not per-locale > Content negotiation works well: if you have pt-BR and pt locales enabled in > browser, and go to https://www.debian.org/releases/bullseye/releasenotes you > are presented a "pt" translation of the page (because there is no pt-br > translation of that page) and thus the links to "Português" are in bold > instead of the links to "Português (Brasileiro)". Ah, OK: that makes sense, thank you. I agree that content negotiation is working as expected (and have retitled the bug). > So (correct me if I'm wrong) I think the best is leave things as they are, > suggest users to include both pt-br and pt locales in their browser, and > close this bug. That sounds correct. Before we do that, there is one idea/workaround I had that probably has flaws, but that I would like to mention: We could update the logic here to use lang.startswith instead of lang.equals: - https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/template/debian/release.wml#L216-218 That would mean that when content-negotiation finds the most-relevant available translation for a page (say, 'pt'), we embolden all of the potential translations. (I think it would remain as-cacheable as today, and that any resulting bundling of the release notes HTML into redistributable packages should not increase in variance as a result of it)
Bug#1030535: python-pycdlib: FTBFS (AttributeError: module 'inspect' has no attribute 'getargspec')
Source: python-pycdlib Followup-For: Bug #1030535 Control: tags -1 fixed-upstream Dear Maintainer, This Python3.11 compatibility issue (along with a few similar fixups) is resolved in version 1.13.0 of pycdlib (latest at the time-of-writing is 1.14.0). Thanks, James
Bug#1030736: pytorch-vision: hard-coded dependency on python3.10
Source: pytorch-vision Version: 0.14.1-1 Followup-For: Bug #1030736 For this version, the control file contains[1] 'X-Python3-Version: 3.10, 3.11'. Adding that configuration to the *dh-python* source package (as a test), the 'Depends' entry for the resulting .deb file contains: Depends: python3.10, python3:any, python3-distutils | python3 (<< 3.6.5~rc1-1) (note the hardcoded py3.10 dep) Reconfiguring to use 'X-Python3-Version: >= 3.10, <= 3.11', that becomes: Depends: python3:any (>= 3.10~), python3-distutils | python3 (<< 3.6.5~rc1-1) That's probably closer to the intended behaviour here? Please note: ideally I should have tested that configuration change against the pytorch-vision source package. I wasn't immediately able to build that from source, so I decided to experiment using a quicker-to-build package. As a result, some caution about my findings would be worthwhile. [1] - https://salsa.debian.org/deeplearning-team/pytorch-vision/-/blob/437f50d1d8f15cdcef7e7b670036322031c29e4c/debian/control#L39
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 Hi Thorsten, Are you able to determine whether https://github.com/nodejs/node/issues/41163 (and/or any of the guidance within that thread) seems relevant to this bug? If so, your repro example could be useful to help upstream/contributors to develop and test a solution. Thanks, James
Bug#1030856: debian-i18n: The installer doesn't allow to select freely language and locale
Package: debian-i18n Followup-For: Bug #1030856 Control: tags -1 moreinfo Hi Nicola - please can you provide additional information for this bug report? (for example: what language and locale options are available in the installer, and what is not possible currently in the selection process?)
Bug#1030676: pysdl2: autopkgtest failure on s390x
Source: pysdl2 Followup-For: Bug #1030676 On Tue, 07 Feb 2023 at 21:07:50 +, Simon McVittie wrote: > I have intentionally not uploaded those versions to unstable when doing > team-uploads to stop it from regressing and blocking libsdl2, because > I have no good way to test them: nothing in Debian depends on pysdl2, > and I'm not actively using it for any non-Debian software. Thanks, Simon - I hadn't considered the reasons why it might make sense _not_ for more recent versions to have been uploaded, and wanted to ensure that your investigation work upstream (which I read through) was linked from the bug. Agreed that RC this probably was not (although who knows, perhaps we'll learn of an appreciative s390x gamer some day).
Bug#791506: [www.debian.org] Release notes are translated per-language, not per-locale
Package: www.debian.org Followup-For: Bug #791506 Never mind; I think that my suggestion to place both links in bold-format text was probably quite strange and can be ignored. It was an attempt to find something like a workaround or solution (debatable) within the constraints of what is sensible and without modifying much of the code.
Bug#1024647: trac: The versiuon packaged by debian contain a bug fixed upstream that prevent it to work with python3
Package: trac Followup-For: Bug #1024647 Dear Maintainer, The upload of 1.5.4-1 to unstable should, I think, also allow closing this bug. (the changeset[1] linked in the forwarded-to field for this bug is included[2] in the upstream v1.5.4 release) Thanks, James [1] - https://trac.edgewall.org/changeset/17571 [2] - https://trac.edgewall.org/wiki/1.5/TracChangeLog
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
Source: qemu Followup-For: Bug #1030545 For anyone else looking into this bug: it seemed to me that 'qcow2.c' is a likely candidate for this infinite looping[1] behaviour to originate from. The fact that metadata preallocation is enabled when it occurs could be relevant information too. (my guess is that it is _not_ a kernel-related regression, but I could be wrong about that) [1] - https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/block.c#L574-576
Bug#1029845: harfbuzz: non-distributable font included in source
Source: harfbuzz Followup-For: Bug #1029845 Based on the previous: I think that the font was probably accidentally committed to source control while testing a fix for the issue reported on GitHub - and so following upstream's removal of the font seems to make sense, given that there doesn't appear to be any explicit public permission provided by the owner/successors of the license on the Debian mailing lists.
Bug#1029845: harfbuzz: non-distributable font included in source
Source: harfbuzz Followup-For: Bug #1029845 Potentially relevant context: - https://github.com/flutter/flutter/issues/16886 - https://lists.debian.org/debian-legal/2011/05/msg5.html
Bug#1028454: nsscache: build-depends on python3-mox3, to be removed from Debian
Package: nsscache Followup-For: Bug #1028454 Hi Thomas, It looks like the functionality from python3-mock upstream[1] has been included into Python >= 3.3. Would it make sense for nsswitch to migrate from mox3 to the stdlib implementation instead of python3-mock? Thanks, James [1] - https://github.com/testing-cabal/mock/
Bug#1030835: ITP: ruff -- linter for Python, written in Rust
Package: wnpp Severity: wishlist Owner: James Addison X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ruff Version : 0.0.243 Upstream Contact: Charlie Marsh * URL : https://github.com/charliermarsh/ruff/ * License : MIT Programming Lang: Rust Description : linter for Python, written in Rust Ruff is a linter for Python that includes implementations of many common checks implemented by flake8, flake8 plugins, and pylint.
Bug#922621: Use Salsa's CI capabilities to test-build the Debian website after commits or at will
Package: www.debian.org Followup-For: Bug #922621 Control: forwarded -1 https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/207
Bug#791506: [www.debian.org] Content negotiation doesn't work properly with pt_BR at the Release Notes web page
Package: www.debian.org Followup-For: Bug #791506 Dear Maintainer, When I have *both* pt-BR and pt locales enabled in my browser (Firefox 102), then this bug appears: the 'pt' Release Notes links appear in bold instead of the expected 'pt_BR' links appearing in bold. When I remove pt, then the page is negotiated to a fallback language (en-based with my browser settings). Is it possible that content-negotiation is only enabled currently for two-character language codes, and not for country+locale combinations? Thank you, James
Bug#1030676: pysdl2: autopkgtest failure on s390x
Source: pysdl2 Followup-For: Bug #1030676 Control: forwarded -1 https://github.com/py-sdl/py-sdl2/issues/227 Control: tags -1 fixed-upstream It looks like this has been fixed upstream in version 0.9.12 of the library.
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
Source: qemu Followup-For: Bug #1030545 > In the build logs for libguestfs, I see last successful builds were done > on 5.10.0-20-s390x kernel, and on 5.10.0-21-s390x, all builds fails. > 5.10.0-21-s390x is the one running on zelenka too. Sorry for what I now worry may have been distractions in my previous comments. There is at least one failed build where the cause seem unrelated to qemu-img: https://buildd.debian.org/status/fetch.php?pkg=libguestfs=s390x=1%3A1.48.6-1%2Bb3=1675540466=1 That build (libguestfs 1:1.48.6-1+b3, kernel 5.10.0-21-s390x) passes qemu-img steps, but later fails to find the 'getenforce' binary (from selinux-utils): > SELinux: sh: 1: getenforce: not found Could that mean there's a missing build-dep on selinux-utils? (and perhaps the kernel version upgrade has introduced/exposed that?)
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
Source: qemu Followup-For: Bug #1030545 After further investigation, the absence of the 'getenforce' binary in the libguestfs build-deps appears to be a non-issue (and in hindsight was not relevant in a 'src:qemu' bug thread, anyway). There is a comment[1] in the source mentioning that failures to find and run that command can safely be ignored. Also, I didn't mean to infer in my previous message that the text I quoted was my own words; I'm using reportbug from the command-line and forgot to add an MUA-style author attribution. I think I'll step away from attempts to resolve this issue because I seem to be adding more noise than value. [1] - https://salsa.debian.org/libvirt-team/libguestfs/-/blob/967a8cff7dda94b873d0ec88e5e738f18c50335f/test-tool/test-tool.c#L205-210
Bug#960231: kubernetes: provision of 'kubeadm' command-line utility
Source: kubernetes
Followup-For: Bug #960231
Control: severity -1 wishlist
Hi Janos,
I'm reducing the severity of this report, because I don't think that the
initial severity was correct (my apologies).
Attached is an updated patch; please note:
- This won't be in time for bookworm as I understand it (too far into freeze)
- I'm not sure about the version number I've suggested in the changelog
- The changelog entry is attributed to my work email since it is work-related
The patch should apply with patch options '-Np1' in the Debian source package
directory.
Thank you,
James
diff -Nru a/debian/changelog b/debian/changelog
--- a/debian/changelog 2020-05-03 22:13:17.0 +0100
+++ b/debian/changelog 2023-02-15 18:30:42.0 +0100
@@ -1,3 +1,11 @@
+kubernetes (1.20.5+really1.20.2-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * kubernetes-admin
+- New package containing kubeadm command (Closes: #960231)
+
+ -- James Addison Wed, 15 Feb 2023 18:30:42 +0100
+
kubernetes (1.20.5+really1.20.2-1.1) unstable; urgency=medium
* Non-maintainer upload.
--- a/debian/control2020-05-03 22:12:59.0 +0100
+++ b/debian/control2023-02-15 18:24:28.0 +0100
@@ -6,6 +6,19 @@
Standards-Version: 4.5.0
Homepage: http://kubernetes.io/
+Package: kubernetes-admin
+Architecture: amd64 i386 armel armhf arm64 s390x
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Description: Kubernetes master binaries
+ Kubernetes is a portable, extensible, open-source platform for managing
+ containerized workloads and services, that facilitates both declarative
+ configuration and automation. It has a large, rapidly growing ecosystem.
+ Kubernetes services, support, and tools are widely available.
+ .
+ This package ships the Kubernetes kubeadm binary, which can be used
+ to initialize and configure clusters.
+
Package: kubernetes-client
Architecture: amd64 i386 armel armhf arm64 s390x
Depends: ${shlibs:Depends}, ${misc:Depends}
diff -Nru a/debian/copyright b/debian/copyright
--- a/debian/copyright 2020-03-22 10:53:29.0 +
+++ b/debian/copyright 2023-02-15 18:24:28.0 +0100
@@ -846,6 +846,11 @@
2013 TOML authors
License: Expat
+Files: vendor/sigs.k8s.io/yaml/*
+Copyright: 2014 Sam Ghods
+ 2012, 2013 The Go Authors
+License: Expat and BSD-3-clause-SIGS-YAML
+
Files: vendor/vbom.ml/util/*
Copyright: 2015 Frits van Bommel
License: Expat
@@ -1812,3 +1817,29 @@
.
Creative Commons may be contacted at creativecommons.org.
+License: BSD-3-clause-SIGS-YAML
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are
+ met:
+ .
+ * Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above
+ copyright notice, this list of conditions and the following disclaimer
+ in the documentation and/or other materials provided with the
+ distribution.
+ * Neither the name of Google Inc. nor the names of its
+ contributors may be used to endorse or promote products derived from
+ this software without specific prior written permission.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff -Nru a/debian/kubernetes-admin.bash-completion
b/debian/kubernetes-admin.bash-completion
--- a/debian/kubernetes-admin.bash-completion 1970-01-01 01:00:00.0
+0100
+++ b/debian/kubernetes-admin.bash-completion 2023-02-15 18:24:28.0
+0100
@@ -0,0 +1 @@
+_output/bash-completion/kubeadm
diff -Nru a/debian/kubernetes-admin.docs b/debian/kubernetes-admin.docs
--- a/debian/kubernetes-admin.docs 1970-01-01 01:00:00.0 +0100
+++ b/debian/kubernetes-admin.docs 2023-02-15 18:24:28.0 +0100
@@ -0,0 +1,3 @@
+README.md
+SUPPORT.md
+_output/NOTICE
diff -Nru a/debian/kubernetes-admin.install b/debian/kubernetes-admin.install
--- a/debian/kubernetes-admin.install 1970-01-01 01:00:00.0 +0100
+++ b/debian/kubernetes-admin.install 2023-02-15 18:24:28.0 +0100
@@ -0,0 +1 @@
+_output/bin/kubeadm usr/bin/
diff -Nr
Bug#960231: kubernetes: provision of 'kubeadm' command-line utility
Source: kubernetes Followup-For: Bug #960231 Also: from attempting dpkg-buildpackage with the patch applied, I think that it is incomplete (an additional .install file is required, for example). I'll try to fix that soon.
Bug#1002501: release-notes: Quotes (" and ') in commands in PDF release notes are "smart" (”*” / ’hold$’) so don't copy/paste
Package: release-notes Followup-For: Bug #1002501 X-Debbugs-Cc: 1002501-submit...@bugs.debian.org On Thu, 15 Dec 2022 14:01:49 +0100, Paul Gevers wrote: > The release notes are generated with docbook. I spend about an hour to > find out how to prevent conversion of straight quotes to curly quotes Funny how it's sometimes the seemingly-simple fixes that prove the most infuriating to fix, isn't it? :) I spent a significantly longer amount of time on this one; I learned fairly early on that the 'upquote' LaTeX package was a potential fix (thanks to aerostitch[1] and postgis[2]), but in practice getting that to work with the PDF documentation generation involved various failed attempts. However.. In addition to including the 'upquote' package, it seems that a combination of two additional changes[3] produces the desired result: * Using single straight quotes instead of double quotes * Placing the relevant text within a 'screen' docbook element Fortunately single-quotes is probably a safer and better recommendation anyway since it's generally less prone to globbing, at least in bash. (note: I also had to temporarily rename some font filenames[4] locally in order for the build to succeed when using 'make pdf LINGUA=en architecture=arm64') [1] - https://aerostitch.github.io/misc/asciidoc/asciidoc-pdf_keep_quotes.html [2] - https://github.com/postgis/postgis/pull/128 [3] - https://salsa.debian.org/jayaddison/release-notes/-/commit/4922a80e12db746de8bf8cad45d4fe63d43d9f90 [4] - https://salsa.debian.org/jayaddison/release-notes/-/blob/4922a80e12db746de8bf8cad45d4fe63d43d9f90/Makefile#L82-85
Bug#960231: kubernetes: provision of 'kubeadm' command-line utility
Source: kubernetes Followup-For: Bug #960231 Control: submitter -1 ja...@reciperadar.com
Bug#1030177: pygame-sdl2: FTBFS: pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: '2.1.0-for-renpy-8.0.2'
Source: pygame-sdl2 Followup-For: Bug #1030177 Dear Maintainer, There's an upstream 'setuptools' issue[1] tracking these InvalidVersion exceptions: basically, version parsing is checking for PEP440[2] adherence. Updating the egg_info tag[2] for pygame-sdl2 to match the spec should resolve the problem. (in this case, one way to fix the bug could be: s/-for-renpy/+for-renpy/ ) Thanks, James [1] - https://github.com/pypa/setuptools/issues/3772 [2] - https://peps.python.org/pep-0440/ [3] - https://salsa.debian.org/games-team/pygame-sdl2/-/blob/b1c1d5df2d0095cbed3ade64367b460fa684788a/setup.cfg#L2
Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area
Package: debian-policy Followup-For: Bug #1029211 Hi Gunnar, Please find linked below two edits based on initial proofreading of your patch: - https://salsa.debian.org/jayaddison/policy/-/commit/775f589a7cf0c27ee7103eec7a16b29eccbf3d02 - https://salsa.debian.org/jayaddison/policy/-/commit/0f893cbd70520beba404d56f9c4172e94e3be721 (the former results in duplicate footnotes.. perhaps there's a good way to resolve that, somehow?) Thanks, James
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
Source: qemu Followup-For: Bug #1030545 (ack - that does seem like an unusually-timed coincidence. continuing on with some unrelated investigation, though...) There's a commit[1] from Y2019 that appears to describe a similar set of circumstances - iothreads blocked forever for a bunch of backends, including qcow2. Something potentially relevant in the code diff is that it introduces function calls wrapped within 'assert' as part of the fix (perhaps those are optimized-out by our 'qemu-img' binary build?). [1] - https://gitlab.com/qemu-project/qemu/-/commit/4720cbeea1f42fd905fc69338fd42b191e58b412
Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game
Package: wnpp Followup-For: Bug #1026277 Control: tags -1 pending help bookworm-ignore
Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game
Package: wnpp Followup-For: Bug #1026277 Control: tags -1 -bookworm-ignore
Bug#1034871: podman: "sudo podman system reset" can delete current working directory
Package: containers-storage Followup-For: Bug #1034871 X-Debbugs-Cc: siret...@gmail.com, cy...@debamax.com, deb...@jfarr.cc On Wed, 26 Apr 2023 07:11:50 -0400, Reinhard wrote: > It indeed sounds like a significant papercut. I'm seeking for further > thoughts and opinions: Is this something worth backporting that late in the > release cycle? As a sometimes-podman-user, and because the comment above the setting starts with the word 'Temporary' (leading me to think that users may be tempted to adjust or remove it... the same way I probably would), I'd be cautiously supportive of backporting the patch for bookworm. (I understand that doing so is a maintainence burden, and that it's late-ish release-wise; after becoming aware of this bug, though, I think I'd be more comfortable encouraging use of podman for developers with the fix included) On Wed, 26 Apr 2023 17:47:39 +0200, Cyril wrote: > Please keep in mind I know nothing about podman or containers-storage > and I haven't spotted what would set up /etc/containers/storage.conf, Fortunately the file as shipped in bookworm's containers-storage package is enirely static, and does provide a valid default 'runroot' value: https://sources.debian.org/src/golang-github-containers-storage/1.45.1%2Bds1-2/storage.conf/#L19-L20
Bug#1029843: brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems
Package: src:linux Followup-For: Bug #1029843 X-Debbugs-Cc: p...@akeo.ie, k...@debian.org, didi.deb...@cknow.org, debian-b...@lists.debian.org, 1029...@bugs.debian.org, 1035...@bugs.debian.org, 989...@bugs.debian.org, debian-...@lists.debian.org Control: retitle -1 brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems Thanks, Pete. I added a note[1] on the rpi4-uefi.dev GitHub repository, and from one of your fellow contributors' responses, it seems that in fact the filename-with-spaces format _is_ referenced from linux-firmware.git, in a 'WHENCE' file that is used to create symlinks (I hadn't been aware of that previously). As a result: I feel that maybe this bugreport is not valid. I suppose that some of the confusion stemmed from the fact that a single binary of a kernel module in combination with a single physical hardware device probed different firmware filenames at runtime depending on the context (ACPI vs Devicetree, in this case). (it's code, so yep, I get that it's technically _possible_ for that to happen, and perhaps it's useful to workaround limitations of existing standards, but it's not clear to me whether that's necessary here) > Note that, in case you think there may be something that we can improve > in the SMBIOS data reported by the UEFI firmware (which is currently > generated from the source code at [1], with the full output from a > Raspberry Pi 4, from UEFI Shell's smbiosview command at [2]) we can look > into updating the UEFI firmware to alter the data we output. Thank you - I'll take a look at those to learn more. [1] - https://github.com/pftf/RPi4/issues/76#issuecomment-1533295773
Bug#1030519: hw-detect: firmware file path handling is fragile
Followup-For: Bug #1030519 Control: unmerge -1 Control: reassign -1 hw-detect Control: retitle -1 hw-detect: firmware file path handling is fragile
Bug#1029843: brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems
Control: unmerge 1029843 1030519 Control: reassign 1029843 src:linux Control: retitle 1029843 brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems Control: affects 1029843 firmware-brcm80211 raspi-firmware Dear Maintainer, This bugreport relates to the brcmfmac kernel module and the firmware filename that it probes for during load. It looks like this may have been a cause of some problems reported in bugs #989593, #1029843 (this bug) and #1035392. The last of those three bugs is an installation-report of mine, and as far as I can tell the problem is that when the affected system (an RPi) was configured without devicetree support in its UEFI bootloader, the kernel module was unable to determine a precise filename and used some fallback logic to determine one approximately here: https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487 Please let me know if I can provide any further details to help track this down. Thank you, James
Bug#1035392: installation-reports: Installation Report: Bookworm RC2: Raspberry Pi 400 (netboot)
Package: installation-reports Followup-For: Bug #1035392 > The only customized dnsmasq setting required was: > > pxe-service=0, "Raspberry Pi Boot" Oops, I lied. There was one other relevant dnsmasq setting: dhcp-boot=bootnetaa64.efi (telling the device what EFI filename to retrieve and run from the TFTP server)
Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Mon, 1 May 2023 at 20:03, Cyril Brulebois wrote: > James Addison (2023-05-01): > > Also, the brcmfmac kernel module code mentions[3] that it can load > > board-specific firmware file paths. I'm not yet sure whether that's > > relevant (either now, or in future). > > Yeah, both the function you pointed to and the one handling actual > firmware requests seem to know about some alt_fw semantics, with a > fallback. But I'm not diving into that rabbit hole. :) That's a sensible strategy :) Could either of you (Cyril, Diederik) recommend where I should ask (and/or clone this bug) to follow up on the firmware filename issue, given that the filename(s) seem to be generated from the kernel module? (as a recap: the brcmfmac module attempts to load a file of the format "brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt" instead of "brcmfmac43455-sdio.txt" -- I saw the same thing during my install, with string adjustments for brcmfmac43456 and Pi 400) I think that that's likely to be the cause of the firmware-not-loaded problems in installation-reports #989593 and #1035392 (that second report is from me, earlier today). Even with the 'Contents-firmware' file-to-package mapping, we won't find the relevant firmware file if the name is wrong. > Regarding “plans for the future”, it's worth mentioning #1033921, now > cloned as #1035356. While the former is about license acceptance for > some firmware packages specifically (and about to be fixed for bookworm) > the latter is for longer term, with a proposed patch changing the logic > around iterating over firmware filenames. I'm not saying it's going to > solve spaces-in-filenames as it is, I just thought it'd make sense to > mention it as that touches one relevant part of the hw-detect code. Thank you; yep, I've followed _most_ of that (and arrived back here again). I will admit that most of what I've cognitively loaded from it is "this script could use refactoring post-bookworm", and have not processed the complete details. Regards, James
Bug#932957: Please migrate Release Notes to reStructuredText
Package: release-notes Followup-For: Bug #932957 X-Debbugs-Cc: hwans...@mailbox.org Oops - there were a couple of problems with my most recent message here: * Forgot to cc you on the details, Holger (in short summary: the ReST 'only' directive[1] may be helpful here, and could be used with a '-t ' command-line option to sphinx-build from the Makefile) * I didn't read the documentation! The tags for the 'only' directive must be valid Python identifiers, so 'arch_i386' would work as a tag name, but 'arch-i386' (that I had suggested previously) would not. [1] - https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#including-content-based-on-tags
Bug#932957: Please migrate Release Notes to reStructuredText
Package: release-notes
Followup-For: Bug #932957
> Yes, filtering the content for the different architectures does not work yet.
Ah, and I said I would help with that :)
Although I don't yet know exactly how it's going to interact with the build
process, I _think_ that a feature we could use for this is the 'only'
directive:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-only
Although this could benefit from more thought, initially I suggest we adopt a
tag format something like 'arch-{debarch}' to handle this (so the conditional
clause here would be placed within a '.. only:: arch-i386' block.
>From there, we could pass the corresponding tag on the commandline using the
'-t' option, I guess in the Makefile:
https://salsa.debian.org/holgerw/release-notes/-/blob/a2ba839790573915a80db75405abf8ef9212ac8e/Makefile#L103
Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game
Followup-For: Bug #1026277 On Sun, 28 May 2023 16:50:31 +0100, James wrote: > * My release signing has been inconsistent, partly because I'm not sure I > have a long-term commitment to being a Debian Maintainer/Developer, and > partly because I'm not sure I can reliably keep those keys secure (so, at > best I think they would provide some integrity verification support, but > I don't think they really attest highly that I'm the sole or uncompromised > author). Not a particularly useful mindset to have, some might argue, but > it does lead to me towards using ephemeral keypairs (somewhere, once, I > had > some web-of-trust identity, but I haven't continued to use or maintain > it). In retrospect, I think this is probably an argument for exploring and learning better signing practices rather than a packaging problem. (also, to nitpick / clarify: when referring to authorship there, that was only in reference to the packaging and edits made from the existing published open source game engine code)
Bug#932957: Please migrate Release Notes to reStructuredText
Package: release-notes Followup-For: Bug #932957 X-Debbugs-Cc: hwans...@mailbox.org Hi Holger, I noticed one more problem with the output of the ReST release-notes: Filtering of architecture-specific sections does not seem to be taking place, so the 'Supported Architectures'[1] section for AMD64 currently contains the text: The ARCH-TITLE support (known as the Debian architecture amd64) now requires the “long NOP” instruction. Please refer to Baseline for 64-bit PC is now i686 for more information. (the ARCH-TITLE placeholder is probably a small fixup - the problem I'd like to draw attention to is the reference to 64-bit PC / amd64 as i686) In the Docbook source, there is an 'arch="i386"' annotation[2] on the section's XML element, so perhaps that is used to filter the content. Cheers, James [1] - https://people.debian.org/~holgerw/release-notes_sphinx/en/html/whats-new.html#supported-architectures [2] - https://salsa.debian.org/ddp-team/release-notes/-/blob/698b757e098b7d7ccd7b34b5bb9bda333155fd11/en/whats-new.dbk#L71
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Sun, 14 May 2023 15:21:24 -0400, Ted wrote: > On Sun, May 14, 2023 at 06:03:59PM +0200, Michael Biebl wrote: > > > Please reassign it there together with instructions how to fix it, i.e. > > > what should be done in the maintainer scripts. > > Can someone send the instructions on how to fix this? I think we want to remove the old default.target.wants directory link and replace it with a multi-user.target.wants link at some point during the upgrade process. Would calling the 'reenable' action implemented by deb-systemd-helper[1] (an equivalent to the corresponding action in systemctl[2]) during the e2fsprogs postinst script solve the problem? (the contents of the deb-systemd-helper service state file seem very relevant here. for this to work correctly, I think it needs to contain the old link during the 'disable' step, and then should use the new link during 'enable'. I could be mistaken, however. I have read #717603 while trying to figure out a solution here) [1] - https://manpages.debian.org/bullseye/init-system-helpers/deb-systemd-helper.1p.en.html [2] - https://manpages.debian.org/bullseye/systemd/systemctl.1.en.html
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, jspri...@debian.org, ans...@debian.org, a...@debian.org, debian.bugrep...@wodny.org I've been 'approximately' testing this locally on bookworm by: * Editing the Install.WantedBy in /lib/systemd/system/e2scrub_reap.service * Reconfiguring the package using 'dpkg-reconfigure e2fsprogs' (I know, it's not a comprehensive workflow - but I think that it calls the relevant deb-systemd-helper and e2fsprogs postinst script sections) Also: Marcin's patch[1] from #985787 is also intended to fix a very similar problem (perhaps exactly the same issue). Some puzzles: * Why does the 'deb-systemd-helper disable' invocation not work (as found by Helmut and Jochen)? It seems like it should read the symlink path to remove from the dsh-also state file, so the Install.WantedBy change should not affect it. * Is the /var/lib/systemd/deb-systemd-helper-enabled/ path relevant? This seems to contain a shadow copy of much of the /etc/systemd/system service state. * Is the 'create links unless no links installed' logic correct? (that sounds like it could be incorrect, but I'm not sure) I did manage to get something kinda-working locally with a combination of an 'update-state' call and Marcin's patch. However, I'd like to understand more about the 'deb-systemd-helper disable' call failure before recommending that. And, quoting Andreas: > Actually the difference is between the minimal bullseye chroot upgraded > to bookworm and the bullseye chroot with some packages to be tested > installed (here: systemd) and upgraded to bookworm. Ideally, after > removing the packages to be tested and their dependencies, the two > bookworm chroots should be identical ... I agree on the goals there. Being unhappy about systemd and maintaining a package that has divergent on-filesystem results depending on how users upgraded seems distinctly worse than being unhappy about systemd while maintaining a consistently-deployed package. [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985787#25 [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035543#62
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, jspri...@debian.org, ans...@debian.org, a...@debian.org, debian.bugrep...@wodny.org Would a 'move /etc/systemd/system/default.target.wants/e2scrub_reap.service to /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service if the source file exists' during the postinst be enough to restore consistency here, and satisfy piuparts? If waiting to the point-release is better, then I'm OK with that. I have some slight frustration about the path divergence - because I think consistent results are important for robust packaging - but if there's higher risk of breakage or a sense that it's too late to fix for bookworm, I can accept that.
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Thu, 1 Jun 2023 at 15:48, Theodore Ts'o wrote: > > In addition to Bookworm being hard frozen, I question the importance > of this patch, the bug priority, and whether the title is correct. > After all, at least with respect to e2fsprogs systemd unit *will* > still be enabled. It will just be enabled using > ../multi-user.target/wanted instead of ../default.target/wanted. > > Ok, piuparts whines about it, and I agree that it's ideal if things > are the stame regardless of whether the distro is freshly installed or > uprgaded --- but e2scrub-repeat.service will *still* be enabled, > right? And so the bug title is misleaing, right? > > So it's not a big deal; is that correct so this patch is not worth > trying to shoehorn in beform Bookworm ships, and this particular patch > can be safely downgraded from importanted, right? I think all of that is true, yep. Also, arguing against my own revert-patch: I think it could be said that multi-user is the "better" target to use here, because the default could be "graphical" or some later-reached system state whereas this is a relatively low-level (if small) system cleanup service. It's taken me too long to figure all this out, but retrospectively I suppose my preference order here was: 1. Fix comprehensively in deb-systemd-helper. 2. Revert the original change (but I thought of / suggested that too late). 3. Apply a package-specific workaround (but I didn't find one that I was comfortable with suggesting). I'd agree with downgrading the severity to below RC (and it's your package, so feel free, I think? maybe even close it?). If anyone arrives here/reports other bugs as a result of experiencing it, I think we can let them know that it's safe to remove the legacy 'default.target' symlink (does that sound correct too?). Without getting too much into opinions on systemd itself: I think declarative systems are good, but that managing stateful transitions between multiple declared states can be challenging. Not impossible, and with sufficient bugreporting and fixing, it can be made solid - so that's something to continue on after the release. (and yep, I claimed I wouldn't look at this bug again for a while.. and I was tempted not to.. but I think clearing it from the RC queue is probably worthwhile)
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 On Fri, 05 May 2023 11:04:29 +0200, Andreas wrote: > If I install systemd into the bullseye chroot and upgrade that to > bookworm, both systemd and e2fsprogs are still installed, but > /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service > does *NOT* get created. Is there a way to pause and step through the postinst script for a package when it runs? (similar to an interactive debugging session)
Bug#651280: don't allocate all available disk space in standard LVM partioning scheme
Package: debian-installer Followup-For: Bug #651280 X-Debbugs-Cc: debian-b...@lists.debian.org, skirpic...@gmail.com Control: severity -1 serious After the changes made to address bug #924301 (mountpoints for ext[n] filesystems that have insufficient free blocks are not automatically checked for faults), I think that this bug could be considered more serious. The disk space required for e2scrub[1] snapshots is 256MiB and the default allocation for LVM (encrypted or unecrypted) in the bookworm RC4 installer is 100% (same as originally reported here in Y2011). One-of-two potentially-relevant looking source code areas is https://sources.debian.org/src/partman-auto-lvm/91/lib/auto-lvm.sh/ And the second-of-the-two is https://sources.debian.org/src/partman-partitioning/147/lib/resize.sh/?hl=144#L135 [1] - https://manpages.debian.org/bullseye/e2fsprogs/e2scrub.8.en.html
Bug#1036974: O: bashdb
Package: wnpp Severity: normal The bashdb utility looks useful for interactively debugging bash scripts, but currently lacks a maintainer. It was previously included in Debian and was removed[1] in Y2017. [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870992
Bug#1030519: hw-detect: firmware file path handling is fragile
Source: hw-detect Followup-For: Bug #1030519 X-Debbugs-Cc: a.dalm2...@googlemail.com Hi Alexander, I've been reviewing your patch and would like to suggest extracting the following changes from it to consider and apply individually: 1. Supporting firmware filenames that contain spaces. 2. Removing (or at least reducing) the 5s wait[1] for USB devices to settle. 3. Refactoring the fwfile 'for' loop[2] to use less-complicated parameter expansion (your changes didn't modify this but did highlight it potentially more complicated than necessary). Each of these changes would require some description and a small patch - writing those may require more time, I admit; the reward is that it makes it easier for the maintainer to accept the changes. During review, I considered these as possible other changes: * Loading the 'vfat' kernel module before mountpoint search. * Consulting the 'maybe-usb-floppy' mountmedia device as an origin. However, it seems that mountmedia already handles these? https://sources.debian.org/src/mountmedia/0.26/mountmedia/?hl=20#L69 https://sources.debian.org/src/mountmedia/0.26/mountmedia/?hl=20#L20 Thank you! James [1] - https://sources.debian.org/src/mountmedia/0.26/mountmedia/?hl=20#L82 [2] - https://sources.debian.org/src/hw-detect/1.159/check-missing-firmware.sh/#L210
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 On Wed, 31 May 2023 09:55:13 +0100, James wrote: > On Fri, 05 May 2023 11:04:29 +0200, Andreas wrote: > > If I install systemd into the bullseye chroot and upgrade that to > > bookworm, both systemd and e2fsprogs are still installed, but > > /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service > > does *NOT* get created. > > Is there a way to pause and step through the postinst script for a package > when > it runs? (similar to an interactive debugging session) There is/was-and-may-be-again bashdb[1]; it was removed[2] from Debian in Y2017. [1] - https://bashdb.sourceforge.net [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870992
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Fri, 2 Jun 2023 at 15:24, James Addison wrote: > > > > Also, arguing against my own revert-patch: I think it could be said > > > that multi-user is the "better" target to use here, because the > > > default could be "graphical" or some later-reached system state > > > whereas this is a relatively low-level (if small) system cleanup > > > service. > > > > Right, that's I believe the point of bug #991349; it's possible that > > the system adminsitrator might manually set default.target to point to > > graphical.target, per [1]. And since multi-user.target is a subset of > > graphical.target, it makes sense to make the Wanted-by to be > > multi-user.target. > > > > [1] https://www.baeldung.com/linux/systemd-target-multi-user > > I guess so. However, now that I read it, the manual for > systemd.special[1] does indicate that the target it will load at boot > is default.target -- whatever it's configured to (usually multi-user > or graphical). > > In other words: default.target should be a subset of all of > multi-user.target, graphical.target, and whatever else a system > administrator might configure as the boot target state. Eh, poor phrasing there: default.target isn't a _subset_ of all those targets, but for any given systemd-enabled boot environment, default.target should be guaranteed (as far as systemd lives up to the guarantees it aims to provide) to be on the service startup path between systemd loading as init and systemd reaching the desired boot state. > > In this particular case, since we *always* want it to be > > default.target, since the whole *point* is to clean up after a failed > > e2scrub, it seems really unlikely to me that the system administrator > > would change this. So this is one where it's probably fair for the > > postinstall script to just fix the wanted-by link **always** if the > > the systemd unit file says Wanted-by: default.target, and the symlink > > is inconsistent with it. > > What do you mean by "fix the link" in this context? > > [1] - https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html
Bug#1035871: flare-engine: broken symlink: /usr/share/games/flare/mods/default/fonts/unifont-10.0.06.ttf -> ../../../../../fonts/truetype/unifont/unifont.ttf
Followup-For: Bug #1035871 X-Debbugs-Cc: elb...@debian.org [ not a maintainer, but I have tested the behaviour of this bug ] On Thu, 1 Jun 2023 11:57:46 +0200, Paul wrote: > On Wed, 10 May 2023 13:54:11 +0200 Andreas Beckmann wrote: > > fonts-unifont does no longer ship unifont.ttf or other *.ttf. > > There are only the *.otf variants left in most cases. > > How bad is this in practice? Does flare-engine break completely or is > this mostly an annoyance? (I can imagine either or anything in between) In short: the game remains playable in English-language, but becomes practically unusable in other supported locales (ja, ko, zh, zh_TW). For affected locales, a (non-fatal) error prompt appears and in-game text is absent. Empty labels appear wherever menu/game text is expected, and error messages of the following form are output to stdout: ERROR: FontEngine: Invalid font 'font_'. No fallback available. Workaround: As Andreas mentions, an otf font variant exist. The game does correctly load and display fonts from this file when the symlink is updated to point to that file. Also note: The package 'cataclysm-dda-data' was similarly affected; see bug #1022269 for details.
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
> > Also, arguing against my own revert-patch: I think it could be said > > that multi-user is the "better" target to use here, because the > > default could be "graphical" or some later-reached system state > > whereas this is a relatively low-level (if small) system cleanup > > service. > > Right, that's I believe the point of bug #991349; it's possible that > the system adminsitrator might manually set default.target to point to > graphical.target, per [1]. And since multi-user.target is a subset of > graphical.target, it makes sense to make the Wanted-by to be > multi-user.target. > > [1] https://www.baeldung.com/linux/systemd-target-multi-user I guess so. However, now that I read it, the manual for systemd.special[1] does indicate that the target it will load at boot is default.target -- whatever it's configured to (usually multi-user or graphical). In other words: default.target should be a subset of all of multi-user.target, graphical.target, and whatever else a system administrator might configure as the boot target state. > In this particular case, since we *always* want it to be > default.target, since the whole *point* is to clean up after a failed > e2scrub, it seems really unlikely to me that the system administrator > would change this. So this is one where it's probably fair for the > postinstall script to just fix the wanted-by link **always** if the > the systemd unit file says Wanted-by: default.target, and the symlink > is inconsistent with it. What do you mean by "fix the link" in this context? [1] - https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html
Bug#651280: don't allocate all available disk space in standard LVM partioning scheme
On Wed, 31 May 2023 at 16:38, Cyril Brulebois wrote: > > Control: severity -1 wishlist > > James Addison (2023-05-31): > > After the changes made to address bug #924301 (mountpoints for ext[n] > > filesystems that have insufficient free blocks are not automatically > > checked for faults), I think that this bug could be considered more > > serious. > > How do you figure? Previously, after installation without enough free blocks, system administrators would be notified (perhaps repeatedly) about lack of space encountered by each e2scrub run. For installations after #924301 the administrator is less likely to be aware of the problem (the alarm was silenced, but the cause had not been addressed). In either case, recoverable filesystem errors could occur on the installed system -- the difference is that in the former case, the administrators are more likely to have been aware (and at an earlier point in time) about the risk. > > The disk space required for e2scrub[1] snapshots is 256MiB and the > > default allocation for LVM (encrypted or unecrypted) in the bookworm > > RC4 installer is 100% (same as originally reported here in Y2011). > > That's the default setting. Users who want to use e2scrub can tweak it. The volume group allocation size can be adjusted during an interactive install session, yep - the operator is prompted to input a size, and the default value is the full extent of the block device (my terminology may be a bit wonky). (the 256MiB requirement appears to static, though - it's a fixed size for exactly one snapshot, I suppose)
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
On Fri, Jun 2, 2023, 15:30 James Addison wrote: > On Fri, 2 Jun 2023 at 15:24, James Addison wrote: > > > > > > Also, arguing against my own revert-patch: I think it could be said > > > > that multi-user is the "better" target to use here, because the > > > > default could be "graphical" or some later-reached system state > > > > whereas this is a relatively low-level (if small) system cleanup > > > > service. > > > > > > Right, that's I believe the point of bug #991349; it's possible that > > > the system adminsitrator might manually set default.target to point to > > > graphical.target, per [1]. And since multi-user.target is a subset of > > > graphical.target, it makes sense to make the Wanted-by to be > > > multi-user.target. > > > > > > [1] https://www.baeldung.com/linux/systemd-target-multi-user > > > > I guess so. However, now that I read it, the manual for > > systemd.special[1] does indicate that the target it will load at boot > > is default.target -- whatever it's configured to (usually multi-user > > or graphical). > > > > In other words: default.target should be a subset of all of > > multi-user.target, graphical.target, and whatever else a system > > administrator might configure as the boot target state. > > Eh, poor phrasing there: default.target isn't a _subset_ of all those > targets, but for any given systemd-enabled boot environment, > default.target should be guaranteed (as far as systemd lives up to the > guarantees it aims to provide) to be on the service startup path > between systemd loading as init and systemd reaching the desired boot > state. > > > > In this particular case, since we *always* want it to be > > > default.target, since the whole *point* is to clean up after a failed > > > e2scrub, it seems really unlikely to me that the system administrator > > > would change this. So this is one where it's probably fair for the > > > postinstall script to just fix the wanted-by link **always** if the > > > the systemd unit file says Wanted-by: default.target, and the symlink > > > is inconsistent with it. > > > > What do you mean by "fix the link" in this context? > > > > [1] - > https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html After further thought here: if the change from #991349 to use multi-user.target means slightly earlier invocation of the service when working towards graphical.target, but _also_ means that the service won't be invoked _at all_ on some systemd-enabled systems (whenever default.target is configured to a state that doesn't visit multi-user.target)... then I think rolling back to default.target would be better.
Bug#932957: Please migrate Release Notes to reStructuredText
Followup-For: Bug #932957 X-Debbugs-Cc: hwans...@mailbox.org On Sun, 21 May 2023 10:16:36 +0200, Holger wrote: > There is also a problem using entities (or now called substitutions) in > quoted lines like > deb https://deb.debian.org/debian RELEASENAME main contrib Ok, yep - I understand the problem there now, and have experimented with it a bit locally. Roughly speaking: substitutions aren't possible within literal quote blocks (there is a '::' a couple of lines before the mentioned line, and adding the pipe '|' symbols around the substitution label doesn't make a difference within literal blocks) Not sure what to suggest yet as an alternative, though...
Bug#1035669: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib
Hi Abou, Please find some slightly re-ordered responses below, and with the gtk-gnome list and bug on cc because others are likely to know more than me about this. On Sat, 3 Jun 2023 at 22:40, Abou Al Montacir wrote: ... > However, when starting the conversion, g-ir-generate crashes with an error on > HarfBuzz-0.0. > I've raised a ticket > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035669 to that package, > but I'm not sure it is an issue in HarfBuzz itself, and maybe it is in > g-ir-generate itself. I'd begun looking into the problem - it seems that the g-ir-generate tool determines that the HB_LANGUAGE_INVALID constant (zero) is a GTK 'interface'[1] type instead of a basic type (such as int, utf8, ...). That causes the XML gir serialization failure here[2], because the interface type isn't supported. > Few weeks ago, I started adding support for Gtk3 in FPC and Lazarus as part > of the effort to close bugs related to the deprecation of Gtk2. > My goal was to be able to build binding units (pascal modules) from .typelib > files shipped by Debian. > In order to be able to do that, I use a tool called gir2pas that I'm > maintaining. > I've added support for on the fly converting .typelib files using > g-ir-generate. While developing a patch I'd found it difficult to figure out what the effect of my changes were on the output .typelib binary file. In fact, I filed https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/341 as a feature request for diffoscope. Would any of the code from gir2pas be helpful to mention there? > The reason I'm write to debian-devel is to know if we want to enforce the > fact that typelib files shall be able to regenerate gir files for Bookworm. > If this is the case, shall I raise severity to be release critical? What's the impact of the inability to generate the XML gir files for gir1.2-harfbuzz on other packages? Thanks, James [1] - https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/gitypes.h#L410 [2] - https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/girwriter.c#L784
Bug#1035669: gir1.2-harfbuzz-0.0: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib
Package: gir1.2-harfbuzz-0.0 Followup-For: Bug #1035669 X-Debbugs-Cc: abou.almonta...@sfr.fr Control: tags -1 patch Dear Maintainer and Abou, The attached patch allows me to serialize GIR XML from the HarfBuzz-0.0.typelib file contained in the resulting gir1.2-harfbuzz-0.0 package. For more extensive details, please read the patch description; in short, it removes a C typecast that appears to mislead the gobject build process into treating the 'HB_LANGUAGE_INVALID' constant (value: zero) as an interface, instead of a basic (and serializable) integer type. Please be somewhat skeptical of the patch; I don't know whether it is the best place for a fix, and it would benefit from awareness and discussion upstream. I think it helps identify the approximate area in which the problem occurs, and my hope is that that is helpful at least. Regards, James Description: Remove typecast from HB_LANGUAGE_INVALID definition Author: James Addison The GObject Introspection tooling identifies the HB_LANGUAGE_INVALID constant #define'd in hb-common.h as an interface[1] type, due to the use of a C typecast to a struct type. Subsequently, attempts to serialize the binary typelib database that contains the type entry for HB_LANGUAGE_INVALID into an XML format will fail during serialization[2]. In practice, the value is a constant used for direct comparison purposes (as is evident in test cases that use '==' comparisons between NULL and HB_LANGUAGE_INVALID). Removing the typecast and annotating it explicitly as a constant[3] value should make that clearer and enable serialization to XML. (the annotation is not strictly necessary, but makes it clearer that the change is intentional and part of the API for the library) [1] - https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/gitypes.h#L410 [2] - https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/37bde613a7cb77e7399dafb25731e13208f0ae0b/girepository/girwriter.c#L784 [3] - https://gi.readthedocs.io/en/latest/annotations/giannotations.html --- Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035669 Last-Update: 2023-06-04 --- harfbuzz-6.0.0+dfsg.orig/src/hb-common.h +++ harfbuzz-6.0.0+dfsg/src/hb-common.h @@ -315,13 +315,13 @@ HB_EXTERN const char * hb_language_to_string (hb_language_t language); /** - * HB_LANGUAGE_INVALID: + * HB_LANGUAGE_INVALID: (value 0) * * An unset #hb_language_t. * * Since: 0.6.0 */ -#define HB_LANGUAGE_INVALID ((hb_language_t) 0) +#define HB_LANGUAGE_INVALID 0 HB_EXTERN hb_language_t hb_language_get_default (void);
Bug#1029555: lintian: license-problem-font-adobe-copyrighted-fragment-no-credit false positive
Package: lintian Followup-For: Bug #1029555 X-Debbugs-Cc: rol...@debian.org Dear Maintainer and Roland, Worth noting: there are two programs in the relevant Adobe reference manual[1], appendix three[2], and both programs are, I think, _intended_ to be available under open source licensing. The two programs collectively define four subroutines. So far Debian's lintian checks have looked for the smaller program that relates to type hinting (as this is frequently useful for Type1 fonts). The other program relates to a technology called 'Flex' (that I don't know much about). The published open source code[3] for what appears to be the Flex-related program differs from the originally-published version in one statement that looks significant (note: it _also_ differs in a few non-computationally significant ways*, but those seem like they could be a result of automated transformation, such as during re-reading of the code from storage prior to reproduction for open source distribution). The difference is that the code from the original publication closes with a PostScript 'noaccess'[4] directive, but this is missing from the open sourced version. >From a codesearch, Debian does not include the 'noaccess' version anywhere; only the open source version of the code is in use. I'll report the discrepancy to the upstream repository. I'm working on a patch / merge request to update the lintian check to detect other, non-open source code from the publication instead, as suggested. There is an example (non-appendix) program listing that could be relevant, although also seems relatively unlikely to be copied widely. Thanks, James [ * differences appear to be: style differences in the copyright header comment, two missing comment lines, whitespace/newline differences, and difference in representation of fractional numbers using scientific notation (e.g. 1e-05 vs .1), and differences in whether the leading zero in a decimal representation is included or not ] [1] - https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf [2] - https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf#page=97 [3] - https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/FDK/Tools/Programs/public/lib/source/t1write/t1write_flexothers.h [4] - https://en.wikipedia.org/wiki/PostScript_fonts#Printer_Font_ASCII
Bug#1029555: lintian: license-problem-font-adobe-copyrighted-fragment-no-credit false positive
Package: lintian
Followup-For: Bug #1029555
X-Debbugs-Cc: rol...@debian.org
Dear Maintainer,
Please find attached a potential fix for this lintian check bug.
Thanks,
James
>From 9fe45fdcbbc2fef8771cb049822307c5bbbafd15 Mon Sep 17 00:00:00 2001
From: James Addison
Date: Wed, 7 Jun 2023 15:11:20 +0100
Subject: [PATCH] license-problem-font-adobe-copyrighted-fragment-no-credit:
previously-checked code is now open source, so check for other,
non-open-source code from the same publication
---
lib/Lintian/Check/Fonts/Postscript/Type1.pm | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/lib/Lintian/Check/Fonts/Postscript/Type1.pm
b/lib/Lintian/Check/Fonts/Postscript/Type1.pm
index 87cbef7c6..de5de8992 100644
--- a/lib/Lintian/Check/Fonts/Postscript/Type1.pm
+++ b/lib/Lintian/Check/Fonts/Postscript/Type1.pm
@@ -90,7 +90,25 @@ sub visit_installed_files {
# copyright adobe a few line before the only
# place where the startlock is documented is
# in the black book copyrighted fragment
-if ($line =~ m/startlock\s*get\s*exec/) {
+#
+# 2023-06-05: this check has been adjusted because
+# Adobe's type hint code[1] (including Flex[2]) became
+# open source[3] with an Apache-2.0 license[4] as
+# committed on 2014-09-19, making that check a false
+# positive[7].
+#
+# We continue to check for copyrighted code that is not
+# available under an open source license from the origin
+# publication, "Adobe Type 1 Font Format"[5][6].
+#
+# [1] -
https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/FDK/Tools/Programs/public/lib/source/t1write/t1write_hintothers.h
+# [2] -
https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/FDK/Tools/Programs/public/lib/source/t1write/t1write_flexothers.h
+# [3] -
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1375813.html
+# [4] -
https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/LICENSE.txt
+# [5] -
https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf
+# [6] - https://lccn.loc.gov/90042516
+# [7] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029555
+if ($line =~ m/UniqueID\s*6859/) {
$self->pointed_hint(
'license-problem-font-adobe-copyrighted-fragment-no-credit',
--
2.39.2
Bug#932957: Please migrate Release Notes to reStructuredText
Followup-For: Bug #932957
X-Debbugs-Cc: hwans...@mailbox.org
On Mon, 22 May 2023 23:40:46 +0100, James wrote:
> On Sun, 21 May 2023 10:16:36 +0200, Holger wrote:
> > There is also a problem using entities (or now called substitutions) in
> > quoted lines like
>
> > deb https://deb.debian.org/debian RELEASENAME main contrib
>
> Ok, yep - I understand the problem there now, and have experimented with it a
> bit locally. Roughly speaking: substitutions aren't possible within literal
> quote blocks (there is a '::' a couple of lines before the mentioned line, and
> adding the pipe '|' symbols around the substitution label doesn't make a
> difference within literal blocks)
It looks like the fix for that is to convert those literal ('::') blocks into
parsed-literal[1] ('.. parsed-literal::') blocks.
[1] -
https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
Bug#1036618: RFP: aerofoil -- Multiplatform port of 1994 Macintosh game 'Glider PRO'
Package: wnpp Severity: wishlist * Package name: aerofoil Version : 1.1.2 Upstream Contact: Eric Lasota * URL : https://github.com/elasota/Aerofoil/ * License : GPL-2 Programming Lang: C Description : Multiplatform port of 1994 Macintosh game 'Glider PRO' In this game you are provided with basic control (left-right direction, nose trim) over a paper aeroplane, and must navigate it through a series of comic-book style 2D environments within the available time limits. You'll encounter various home appliances, thermal airflows and powerups during your adventures.
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 Control: tags -1 patch >From 9ad481148456520f15f92973cdd0cf6caa16a088 Mon Sep 17 00:00:00 2001 From: James Addison Date: Thu, 1 Jun 2023 13:20:29 +0100 Subject: [PATCH] Revert "e2scrub: use WantedBy=multi-user.target in e2scrub_reap.service" This reverts commit b42c9788c75de10ee3b6d1a7f9fbc2f529b64889. Signed-off-by: James Addison --- scrub/e2scrub_reap.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scrub/e2scrub_reap.service.in b/scrub/e2scrub_reap.service.in index 58a45656..10d25f06 100644 --- a/scrub/e2scrub_reap.service.in +++ b/scrub/e2scrub_reap.service.in @@ -22,4 +22,4 @@ SyslogIdentifier=%N RemainAfterExit=no [Install] -WantedBy=multi-user.target +WantedBy=default.target -- 2.39.2
Bug#694154: debian-installer: Preseeding isn't possible for partman-crypto (encrypted LVM)
Source: partman-crypto Followup-For: Bug #694154 Control: fixed -1 partman-crypto/77 It looks like this was resolved[1] in partman-crypto version 77 (Debian bug #656710 / Ubuntu launchpad issue #546405 for the same) - can we close this bugreport? [1] - https://salsa.debian.org/installer-team/partman-crypto/-/commit/be0a3afab31ba7a174047289c3aa5df179c6a794
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Followup-For: Bug #1035543 X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, jspri...@debian.org, ans...@debian.org, a...@debian.org, debian.bugrep...@wodny.org, debian-rele...@lists.debian.org [ re-introducing the larger cc list audience, plus debian-release ] Would reverting the Install.WantedBy modification[1][2], restoring e2scrub_reap enablement using 'default.target' on relevant systems, be a sensible approach for bookworm until we can figure out the debhelper-system behaviour when that setting changes? [1] - https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=b42c9788c75de10ee3b6d1a7f9fbc2f529b64889 [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991349
Bug#1037070: RFP: libx1000 -- provides a dynamically-linked workaround for the LOCK prefix bug on Intel X1000 devices
Package: wnpp Severity: wishlist * Package name: libx1000 Version : 0.0.0 Upstream Contact: Ray Kinsella * URL : http://ashroe.eu/x1000/2016/10/21/fixing-lock-prefix-on-x1000.html * License : LGPLv2.1 Programming Lang: C Description : provides a dynamically-linked workaround for the LOCK prefix bug on Intel X1000 devices The Intel X1000 system-on-chip is a 32-bit x86-based system that has a bug related to use of a LOCK instruction that makes Debian somewhat unusable; see bugreport #738575 for some prior discussion. On distributions that can compile and distribute binaries to target specific processors, binutils can be configured to omit the LOCK prefix, preventing the bug from occurring. That isn't possible for Debian, because Debian supports a multitude of x86 systems, including multiprocessor systems where the LOCK instruction is required to provide correct shared-memory locking behaviour. The libx1000 library provides a packaged, runtime software workaround using LD preloading. For more information, see the author's blog post at: http://ashroe.eu/x1000/2016/10/21/fixing-lock-prefix-on-x1000.html
Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked
Followup-For: Bug #952450 X-Debbugs-Cc: 1035...@bugs.debian.org, ty...@mit.edu As an experiment, I recently updated a functional Debian bookworm system to boot into the systemd 'rescue.target' by default, to test the single-user / recovery experience as part of #1035543 bug assessment. My understanding from the relevant manual[1] is that 'emergency.target' is a similar, albeit even more basic systemd state that is automatically selected if early boot preconditions fail and/or when serious errors occur. The system used for testing has a locked root user account, but is essentially a single-user environment, as I think is typical for many individually-operated laptops, smartphones and other consumer computing devices. There are various considerations to balance here, and because some of those are context/usage-specific, I agree with Raphaël that a debconf question to figure out the intended behaviour would make sense. My understanding of it is something like: "when your system breaks for some reason, are you ok with the next person who reboots it -- yourself or anyone else -- being able to access the contents and potentially attempt recovery?" Most of my experience with that scenario has been that either I or some other process has broken my computer, and I'd generally much prefer to be able to get to a recovery prompt without having to use other more time-consuming methods like removing the disk or finding other ways to get back into the system; but I can understand that those kind of choices vary person-to-person and over time. [1] - https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html
Bug#932957: release-notes: document how to make the rescue mode usable if no root password is set (buster)
unarchive 977358 reopen 977358 blocks 977358 by 952450 Although this was documented for bullseye, the underlying cause remains, and I think that it could be valuable for users to continue to have this documentation available. I've tested that the previously-added guidance from the bullseye release notes remains valid and works on a bookworm system, and have pushed a branch[1] to Salsa to restore the documentation. Bugreport #952450 tracks a longer-term fix, and once that is resolved I think it'd be fine to drop this note from the release-notes. (for most other temporary/transitional release note issues, I think it's fine to drop them between releases - this one seems to me like an exception) It's possible that this is too late to be included in the bookworm release notes (and my apologies, if so). If not, though, I'll provide a similar commit for the reStructuredText migration (cc'd). [1] - https://salsa.debian.org/jayaddison/release-notes-docbook/-/tree/bug-977358/retain-issue-note
Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed
Package: e2fsprogs Followup-For: Bug #1035543 X-Debbugs-Cc: jspri...@debian.org On Thu, 1 Jun 2023 13:53:18 +0200, Jochen wrote: > * James Addison [2023-06-01 12:44]: > >Would reverting the Install.WantedBy modification[1][2], restoring > >e2scrub_reap > >enablement using 'default.target' on relevant systems, be a sensible approach > >for bookworm until we can figure out the debhelper-system behaviour when that > >setting changes? > > No, bookworm is frozen and done: > > "In the last week prior to the freeze, testing will be completely > frozen and only emergency bug fixes will be considered in this period." > > https://lists.debian.org/debian-devel-announce/2023/04/msg7.html Drats - but also, thank you for confirming that. I'd read the announcement, and it is clear, but then somehow afterwards forgot, and thought that the relevant closing date was one week before the release itself. I'll return to this after bookworm is out and until then will try to relax and perhaps may even be able to de-serious myself temporarily to allow 'celebration'. Anyway, a revert patch is attached, although naturally it'd be better to determine the cause.
Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game
Followup-For: Bug #1026277 There are a bunch of mistakes that I've made along the way while attempting to package this game. Some that I'd note are: * I could've made more of an effort and waiting longer for upstream contact before listing an upstream email address (sorry for any resulting spam received at the Blendo Games domain!). * Related, I could've made clear that I was the upstream source code provider instead of leaning on an ambiguous Salsa-as-both-origin-and-package-VCS for a while. * The number of package uploads to mentors.debian.net was large and noisy; I was iterating fairly quickly on improvements and adjustments, and had not yet discovered all the linting utilities available and how to run them locally. * Version history is somewhat unclear - there is a mix of what I would call the 'upstream' version numbers (timestamps in the format MMDD) - these are what I have used to tag upstream versions of the code (where no packaging information exists) and 'package' version numbers (these include single-digit prefixes, plus a package-version suffix). This is most relevant in the case of the 20160725 release, which I think could be the point at where my upstream version begins to more-clearly diverge from the original Blendo Games codebase (by the addition of a second architecture). As part of the packaging process, upstream version 20160725 became version 0~20160725-1 of the package, and I'd consider the changes between there and 1~20160725-1 to be Debian-related: they weren't particularly relevant to my identity as upstream developer, but they did help the package become more applicable to Debian's architectures (not all, unfortunately, but I think that adding support for a second runtime architecture can be a big step for compiled software). That change, and the change to add a manual, have been included into the 'upstream' codebase. Strictly speaking, the additional architecture support probably should've been a patch, followed by merge upstream, followed by inclusion and then patch-drop in the package. They have been offered to the 'original upstream' codebase, for possible integration there if that's something that Brendan / Blendo Games would find useful. I guess that some remaining confusion arises from the fact that despite me managing both upstream and Debian packages currently, there are still patches in the 'debian/patches' directory. That does seem odd to me and I should probably take another look at including those into the upstream codebase. I think my original plan with those was to gradually offer them to 'original upstream' and drop them from the Debian package if-and-when accepted. Trying to remember/figure out my logic for why not all of them are offered upstream.. my best guess is that I've only offered ones that I think were unlikely to cause compatibility difficulties (so changing file paths, for example, is _not_ offered upstream) with the original. But I could be retroactively making that up. * Insufficient testing on the second architecture port - I got it running incredibly slowly in an emulator -- enough to confirm that it runs, basically, but not more than that. * My release signing has been inconsistent, partly because I'm not sure I have a long-term commitment to being a Debian Maintainer/Developer, and partly because I'm not sure I can reliably keep those keys secure (so, at best I think they would provide some integrity verification support, but I don't think they really attest highly that I'm the sole or uncompromised author). Not a particularly useful mindset to have, some might argue, but it does lead to me towards using ephemeral keypairs (somewhere, once, I had some web-of-trust identity, but I haven't continued to use or maintain it). All of these are avoidable problems - and in fact most of them are documented, but I found it tricky to find all of those details and to keep them in mind; even now I expect I would notice and learn more when reading through the packaging guidelines again. Generally it's been a good learning experience though. If any of the problems with the package make it ineligible for some reason, that's a shame, but I can manage. Otherwise, I'll be glad to fix things up where required and think about ideas to make those problems less likely for others to encounter (without reducing resulting package quality).
Bug#1030835: [debian] ITP: ruff -- linter for Python, written in Rust
Followup-For: Bug #1030835 X-Debbugs-Cc: charlie.r.ma...@gmail.com Hi Charlie, I'd like for 'ruff' to be packaged in Debian at some point, and am beginning that process, although it could take some time (I'm not all that familiar with Rust yet, and from what I've learned about the Debian rust utilities, automated packaging is available for cargo-installable codebases, but is a more manual process otherwise. I've found and will follow the issuetracker item[1]). Would you be OK with being listed as the upstream contact for a Debian 'ruff' package, if-and-when it becomes available? (as context: generally the Debian package maintainer will handle and filter bugreports from Debian users without any need for your involvement (although you could subscribe to activity if interested). In some cases they could then contact you with details about problems found and/or fixes discovered. When that process is working effectively, it should be mutually beneficial. Cheers, James [1] - https://github.com/RustPython/RustPython/issues/4179
Bug#849400: debian-installer: LUKS on rootfs and boot
Thanks Jinesh - one question in particular inline below: On Sat, 29 Jul 2023 at 01:29, Jinesh Choksi wrote: > > > > Can you provide a series of steps to replicate the failure case reported in > > this bug? > > > Reproduction Steps > > - Boot using debian-12.1.0-amd64-netinst.iso in a VM > > - At the Grub boot menu, select Advanced options > Expert Install > > - Go through the following install steps using defaults or as desired: > > - Choose language > - Configure the keyboard > - Detect and mount installation media > - Load installer components from installation media > - Detect network hardware > - Configure the network > - Set up users and password > - Configure the clocks > - Detect disks > > - When you reach the "Partition disks" step, choose "Manual" disk > partitioning method > > - Setup a GPT partition table > > - Setup an EFI partition (min 100MB), mounted as /boot/efi > > - Setup a DMCRYPT partition using remaining free space. (i.e. use as > "Physical volume for encryption") > > - Choose to "Configure encrypted volumes" > > - Set a password for the encrypted volume (also to speed up the process, set > Erase data to: No) > > - At this point, switch to TTY2, activate console and type in (the following > is needed as it is not possible to select luks version): > > - cryptsetup luksClose sda2_crypt > > - cryptsetup luksFormat --type luks1 /dev/sda2 > > - cryptsetup luksOpen /dev/sda2 sda2_crypt Does replicating this issue require steps where the user switches to a virtual terminal / other TTY? I don't see that mentioned in other previous thread comments. The debian-installer team shouldn't support workflows that require use of custom commandline steps. > - Switch back to TTY1 and select "Go back", and select "Detect Disks" (needed > to refresh partman's state) > > - Select "Partition Disks" again > > - Set the file system for the encrypted volume to "XFS" (i.e. use as XFS > journaling file system) and set the mount point to /. > > - To reduces reproduction steps, we won't set up a swap partition. > > - Finally, select "Finish partitioning and write changes to disk" > > - You will see a dialog saying: > > Encryption configuration failure > > You have selected the root file system to be stored on an encrypted > partition. This feature requires a separate /boot partition on which the > kernel and initrd can be stored. > > You should go back and setup a /boot partition. > > > > - It is not possible to get past this dialog. > > - Note: If it was possible to get past this dialog, then you can proceed with > installation as per normal until you get to the "Install Grub Boot Loader" > stage. You will find that this stage errors at the "grub-install (dummy)" > step. > > - If you look at msgs on TTY4, you will note it says to add the line > "GRUB_ENABLE_CRYPTODISK=y" to the /etc/default/grun file. So, switch console > on TTY2 and edit /target/etc/default/grub file and add this line. > > - Run the "Install Grub Boot Loader" stage again and it will work and rest of > the install will progress normally. > > - The missing "GRUB_ENABLE_CRYPTODISK=y" line is a seperate bug #925134.
Bug#849400: debian-installer: LUKS on rootfs and boot
Package: debian-installer Followup-For: Bug #849400 X-Debbugs-Cc: jin...@onelittlehope.com Hi Jinesh, Can you provide a series of steps to replicate the failure case reported in this bug? I'll try to find time within the next two weeks to confirm the results that you and others have seen here, and to check what we can do from the points of the code that you linked to. Thank you, James
Bug#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)
Package: firmware-brcm80211 Followup-For: Bug #1029843 X-Debbugs-Cc: k...@debian.org, didi.deb...@cknow.org, debian-b...@lists.debian.org, p...@akeo.ie On Mon, 1 May 2023 11:18:03 +0100, James Addison wrote: > > Diederik de Haas (2023-04-30): > > > And that's exactly what happens or will happen. Even though the RPi4 > > > filename > > > doesn't contain spaces, there are several in the `brcm` directory that do. > > > I didn't check other directories, but I'd expect that filenames with a > > > space is > > > NOT an anomaly. > > Since more files with that pattern are appearing upstream in > linux-firmware.. yes, slightly reluctantly it does seem that this will > be needed. FWIW: After learn the root cause of the spaces-in-filenames problem for packages derived from linux-firmware.git -- that is, the contents of the 'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only affected[1] firmware currently. (that surprised me, but does seem to be the case. I'm writing to counteract any sense that the proposed patch[2] could affect and fix many firmwares. it won't, at least not today) [1] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE#n2708 [2] - https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65
Bug#999485: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices
Package: firmware-brcm80211 Followup-For: Bug #999485 X-Debbugs-Cc: gw...@gwolf.org, didi.deb...@cknow.org, 1023...@bugs.debian.org > The other option is that they get included upstream in > linux-firmware.git by upstream? As an update about this: in the past it seems that one of the blockers for upstreaming was an unclear licensing situation for the firmware. The other, maybe more important blocker is that it tends to be (as I understand it) vendors themselves who are expected to offer files to the linux-firmware.git repo. There is now a license available for the brcmfmac43456 firmware: it's included in the relevant RPF package metadata, in the usual copyright file: https://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-nonfree_20221012-1~bpo11+1+rpt1.debian.tar.xz (since we're talking about non-free firmware, I don't think that there is a DFSG compatibility concern with packaging this, although the linux-firmware.git maintainers likely have their own acceptance criteria. even so, if/when we are creating another package, we should probably distribute the same license file now that it's available. I can prepare a patch if that'd be helpful, since I'm risking creating work by mentioning it) There don't appear to be many Synaptics contributors active on the Linux kernel mailing lists re: wireless devices.. so I'm not sure what the best way to approach them to ask about submitting the firmware upstream would be. RPF have also had inbound requests to upload the firmware, but I don't think that it's their responsibility (or right) to do that. And finally a kind of meta-point: I've found the name 'firmware' kinda confusing while trying to install and correctly configure my RPi. It seems to me like we're referring to two types of firmware: firmware used by kernel modules (as in: linux-firmware.git, firmware-brcm80211, brcmfmac, etc), but also boot-time-firmware required during all the weirdness to get the RPi system to load a kernel and initrd. Is there another term for the latter, to disambiguate it when we talk about it and name packages? Software that's like firmware and used to boot the system?
