Bug#1070836: rust-apple-nvram: Switch from rust-nix 0.26 to 0.27
Hello Jeremy Bicha,
Thanks for explicitly CCing me on this. See below. There's no urgency to
fix this as the relevant rdeps are still stuck in NEW (for 6+ months).
On Fri, May 10, 2024 at 05:31:54AM -0400, Jeremy Bícha wrote:
> Source: rust-apple-nvram
> Version: 0.2.0-1
> Severity: serious
> Tags: ftbfs upstream sid
> X-Debbugs-CC: andr...@fatal.se
>
> rust-apple-nvram Depends and Build-Depends: rust-nix 0.26 but Unstable
> has rust-nix 0.27 instead. I tried doing a simple version bump from
> 0.26 to 0.27 in the package but dh_auto_test failed.
>
> Thank you,
> Jeremy Bícha
I got the following error when trying the same thing.
I have no idea why, since the ioctl_write_ptr and ioctl_read macros are
still supposed to be around. I can't spot any relevant change in nix
that would cause this to happen. Help would be appreciated.
```
error[E0433]: failed to resolve: could not find `ioctl_write_ptr` in `nix`
--> src/mtd.rs:50:6
|
50 | nix::ioctl_write_ptr!(mtd_mem_erase, b'M', 2, EraseInfoUser);
| ^^^ could not find `ioctl_write_ptr` in `nix`
error[E0433]: failed to resolve: could not find `ioctl_read` in `nix`
--> src/mtd.rs:51:6
|
51 | nix::ioctl_read!(mtd_mem_get_info, b'M', 1, MtdInfoUser);
| ^^ could not find `ioctl_read` in `nix`
error[E0425]: cannot find function `mtd_mem_get_info` in this scope
--> src/mtd.rs:54:17
|
54 | if unsafe { mtd_mem_get_info(file.as_raw_fd(),
MtdInfoUser::default()) }.is_err() {
| not found in this scope
error[E0425]: cannot find function `mtd_mem_erase` in this scope
--> src/mtd.rs:62:9
|
62 | mtd_mem_erase(file.as_raw_fd(), _info).unwrap();
| ^ not found in this scope
Some errors have detailed explanations: E0425, E0433.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `apple-nvram` (lib test) due to 4 previous errors
```
Regards,
Andreas Henriksson
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
Hello Dylan, On Mon, Apr 29, 2024 at 11:53:50AM +0200, Dylan Aïssi wrote: > Hello, > > Le dim. 31 mars 2024 à 15:41, Andreas Henriksson a écrit : > > > > PLEASE NOTIFY US WHEN YOU UPLOAD wireplumber 0.5.x to UNSTABLE, so we > > can do a coordinated transition (uploading asahi-audio 2.x to unstable). > > (You might also want to contact release-team to set up a transition > > tracker, even if this might not be a normal transition where binNMUs are > > useful etc.) > > > > The autogenerated tracker for transition was removed (don't know why). > I asked for a new one (#1070043). The only other package (waybar) > affected by this transition has now a compatible version in unstable. We now have asahi-audio 2.x in experimental. Please poke us again when we should upload to unstable (or feel free to NMU asahi-audio to unstable when you upload wireplumber 0.5.x to unstable). > So, I think except the t64 transition nothing else is blocking, I am > waiting the green light from the release team for next step, and I > will ping here before uploading wireplumber 0.5 in unstable. > > Best regards, > Dylan Regards, Andreas Henriksson
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
Control: fixed -1 1.7-2
On Mon, Mar 25, 2024 at 10:13:57AM +0100, Dylan Aïssi wrote:
> Control: reassign -1 asahi-audio
> Control: notfound -1 0.4.17-1
> Control: found -1 1.7-1
why this version? Every asahi-audio version ever
uploaded to the archive is only compatible with
wireplumber << 0.5.0.
> Control: affects -1 wireplumber
>
> Hello,
> Thanks for this bug report, I reassign it to asahi-audio since the versioned
> dependency is on it and not on wireplumber.
[...]
Hmm... wireplumber was the one who changed the configuration language
and thus broke everything using the existing config language. I thus
think it should declare Breaks against everything shipping old config
language files (as well as warn users via debian/NEWS about needing
to manually fix custom config).
FWIW I've just uploaded asahi-audio 1.7-2 with "wireplumber (<< 0.5.0)".
We'll make sure to upload asahi-audio 2.x (with
"wireplumber (>= 0.5.0)") to EXPERIMENTAL as soon as an upstream release
is available.
PLEASE NOTIFY US WHEN YOU UPLOAD wireplumber 0.5.x to UNSTABLE, so we
can do a coordinated transition (uploading asahi-audio 2.x to unstable).
(You might also want to contact release-team to set up a transition
tracker, even if this might not be a normal transition where binNMUs are
useful etc.)
For the future, if you still think it's asahi-audio which should have
strict dependencies on wireplumber - please help figure out which
version we should put in (<< x.y.z) for future breakage. How long does
wireplumber intend to keep compatibility with 0.5.0 config language (or
make other breaking/incompatible changes)?
Regards,
Andreas Henriksson
Bug#1040696: kbd: setfont doesn't set a default font
Control: tags -1 + moreinfo On Sun, Jul 09, 2023 at 04:02:42PM +0200, Sven Grewe wrote: > Package: kbd > Version: 2.5.1-1+b1 > Severity: important > X-Debbugs-Cc: svengr...@posteo.de > > Dear Maintainer, > > If I type setfont into the console, I expect it to use the default font as > the manual says. It gives an error instead: > > $ LANG=CC setfont > Couldn't get a file descriptor referring to the console. Given the $ and the error message, I assume this is a permission problem on your side. Does it not work if you run it as a user that has access to modify the console (eg. root)? Regards, Andreas Henriksson
Bug#979596: Missing fonts from package
Control: tags -1 + wontfix On Fri, Jan 08, 2021 at 03:19:12PM -0500, Phillip Susi wrote: > Package: kbd > Version: 2.3.0-3 > > The t and drdos fonts provided by the upstream kbd package are missing > in the debian binary package. As far as I can tell, this is by design. The console-setup package contains fonts, etc. We only ship tools in kbd package. I'm thus marking this wontfix. (If someone knows better, please update bug report accordingly.) Regards, Andreas Henriksson
Bug#1056576: u-boot: Consider building apple/asahi variant
Hello Vagrant, Thanks for the followup. Comments below. On Fri, Jan 05, 2024 at 01:33:00PM -0800, Vagrant Cascadian wrote: > On 2024-01-05, Vagrant Cascadian wrote: > > On 2023-11-23, Andreas Henriksson wrote: > >> On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote: > >>> On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote: > >>> > On 2023-11-23, Andreas Henriksson wrote: > > ... > >>> > > 3/ do we include patches? > >>> > > 3.1/ No patches. If this is the desired path I can volunteer > >>> > > to test that it boots on my M1 machine. Other machines > >>> > > should probably be considered unsupported for now, > >>> > > even though they might have limited usefulness. > >>> > > 3.2/ Minimal set of patches. We identify what we consider > >>> > > crutial only patches and recruit volunteers to test. > >>> > > M2 keyboard? USB? etc... > >>> > > 3.3/ All asahi patches. We consider it simpler to just sync all > >>> > > patches > >>> > > with the asahi fork (even though some are even unused, like the > >>> > > devicetree patches). We trust the Asahi Linux project in their > >>> > > quest to upstream all their work and that they will rebase on > >>> > > newer > >>> > > releases and make our job easy. > >>> > > >>> > I am inclined towards starting with no patches or a minimal set of > >>> > patches. The asashi folks do seem to generally do a good job of > >>> > upstreaming, so support should improve over time. > >> > >> I'm not against going this route, my only concern is using the asahi > >> name while shipping an "inferior" variant (no patches). The Asahi Linux > >> people have been very good at being end-user focused, fixing all kind of > >> bugs and really go above and beyond to not compromise on end user > >> experience. Not sure they'd appreciate us shipping it under their name > >> while exposing "already fixed" bugs but what do I know. > >> We can always add patches later I guess. The Trixie freeze is not > >> happening soon and we're not providing any installer yet, so it should > >> just be a few #debian-bananas people trying this out for a while still > >> I guess. > > > > This seems like the main blocker at this point; I am hoping to upload at > > least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once > > it releases), and it would be nice to include a u-boot variant > > supporting these boards, but I am nervous about shipping patches. As > > you pointed out an unpatched version with asashi in the name might not > > be appreciated... but ... uh, er. Hrm. I would really like to get this > > in! > > I guess we could include a note in the description? Something like: > > This package does not include all patches shipped by the asahi project, > only patches that have been merged in mainline u-boot. I've been thinking the same thing about just putting info in the description (even if noone ever reads the long description :/). I think we should mention specific which issues to expect, fortunately many changes has already gone upstream for 2024.01 release so these are the high-level ones I can spot are still missing: - keyboard support on m2 models. - multi-os support (eg. multiple linux/bsd installs). - firmware loading (eg. on models with usb type-A ports). (Not sure how important the last one is to mention, could probably be left out.) Hopefully this is all resolved before Trixie freeze (and by then we might want to mention we only support M1/M2 and not M3 and whatever the Apple and Asahi Linux project has been up to in the meantime). FWIW. https://github.com/AsahiLinux/u-boot has already been rebased on latest denx/master (2024.01-rc) and the delta is now down to 20 commits. Devicetree updates is not relevant to us, ignoring those we also don't need the dtc changes - this would lower the number even more. The remaining commits are split up to nicely refactor things for implementing the three above mentioned features. Basically all now touching Apple-specific code/files (except adding a few function prototypes to header files, Kconfig/Makefile hookups and additions to xhci-pci-asmedia). I think we can go ahead with using the u-boot-asahi name and hope we can proceed as planned. > > > live well, > vagrant Regards, Andreas Henriksson
Bug#1058672: lsp-plugins: Bug in msmatrix code can cause speaker damage
On Sat, Dec 23, 2023 at 05:34:55PM +0100, Andreas Henriksson wrote: > Hello again, > > lsp-plugins 1.2.14 is now out according to > https://github.com/lsp-plugins/lsp-plugins/tags I've published updated git repo at: https://salsa.debian.org/ah/lsp-plugins/ arm64 build available from: https://people.debian.org/~ah/lsp-plugins/ Regards, Andreas Henriksson
Bug#1058672: lsp-plugins: Bug in msmatrix code can cause speaker damage
Hello again, lsp-plugins 1.2.14 is now out according to https://github.com/lsp-plugins/lsp-plugins/tags Regards, Andreas Henriksson
Bug#1058672: lsp-plugins: Bug in msmatrix code can cause speaker damage
Hello, Would be awesome with some feedback on this bug report. I'm considering a NMU for this as I'm affected. More details below. On Thu, Dec 14, 2023 at 09:57:48AM -0100, Thomas Renard wrote: > Package: lsp-plugins-lv2 > Version: 1.2.13-1 > Severity: normal > File: lsp-plugins > Tags: upstream > > Dear Maintainer, > > according to upstream merge https://github.com/lsp-plugins/lsp-dsp-lib/pull/20 > a bug in msmatrix code can cause In the mentioned pull request, upstream said: "The release is planned on December, 24th." Thus we can consider two options, cherry-picking the fix or waiting for the new release and uploading that. If I'm going to NMU I'm leaning towards cherry-picking, because: * NMU is supposed to be targeted fixes and I'm not familiar with lsp-plugins since before (but normally I prefer upstream releases over picking and choosing). * The upstream repository situation seems a bit confusing to me. Apparently the debian package is still tracking a mono-repo while upstream has split things into multiple separate repositories (and put them under a different namespace on github). It would be awesome to know how the debian maintainers views things, but if no information is available I'll proceed to NMU probably next week. Even if you prefer me to NMU, it would be appreciated to hear about it! > > "really nasty full-scale buzzing/crackling of the speakers, > the kind of thing that could damage them (and since it is a periodic glitch > and not > continuous, our power/thermal speaker monitoring [speakdersafetyd] > does not catch it as a problem)." > > This mainly concerns aarch64 (Asahi) macs in general but may effect other > aarch64 systems too. FWIW We're currently pushing Asahi components into Debian and for the audio stack we're (apart from this bug) now only waiting for "asahi-audio" to pass new. (We also don't yet have a usable kernel in the archive, so people are using third-party kernels. As can be seen below in the meta-data for the original bug report.) See also https://wiki.debian.org/Teams/Bananas for the official Debian effort. > > Because this will not be fixed soon (waiting for the next upstream > release) it may be useful to fix this bug by already backporting it. > > -- System Information: > Debian Release: trixie/sid > APT prefers testing > APT policy: (900, 'testing') > Architecture: arm64 (aarch64) > > Kernel: Linux 6.6.0-asahi-00901-gd39baf37ae38 (SMP w/10 CPU threads) > Kernel taint flags: TAINT_CPU_OUT_OF_SPEC > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages lsp-plugins-lv2 depends on: > ii libc62.37-12 > ii libcairo21.18.0-1 > ii libfreetype6 2.13.2+dfsg-1 > ii libsndfile1 1.2.2-1 > ii libstdc++6 13.2.0-7 > ii libx11-6 2:1.8.7-1 > ii libxrandr2 2:1.5.2-2+b1 > ii lsp-plugins-r3d-glx 1.2.13-1 > > lsp-plugins-lv2 recommends no packages. > > lsp-plugins-lv2 suggests no packages. > > -- no debconf information Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
On Sun, Nov 26, 2023 at 04:18:33PM +0100, Andreas Henriksson wrote: > Hello Jonas, > [...] > I've now renamed the *binary* package to bankstown-lv2, [...] Oh well, I'm renaming the source as well. I guess we can always rename our git repo to match and pretent like everything is bankstown-lv2. Just for comparison, I downloaded all sources for binary packages called '*-lv2' and 5 of 15 had -lv2 suffix in the orig tarball name (so 1/3). Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Hello Jonas, Thanks for your quick followup and thoughts. On Sun, Nov 26, 2023 at 03:59:34PM +0100, Jonas Smedegaard wrote: [...] > ...but then next year new shiny upstream project "dot" gets packaged not > as "dot-lv2" but "dot" because there is a precedence for lv2 packages to > use no affix. There's no such precedence. I've now renamed the *binary* package to bankstown-lv2, to somewhat align with the precedence of lv2 plugins currently in debian. [...] > Why do you call it mangling to pick another of upstream's multiple > names? They chose one name at crates.io and another at Github. In my experience it is constant hassle to get debian tooling to line up properly with a different name than what the source of the orig tarball calls it. The github tarball is called bankstown. Still not convinced renaming the source is worth it. How strongly do you feel using plain bankstown for source is a problem? (Atleast it's not a three letters acronym, unlike some other recently uploaded packages.) > > And why do you find it important to align source package name with > source package name of (non-derived) distros? If you think derivates are more important to consider than non-derivates you can simply replace Fedora Asahi Remix with Ubuntu Asahi. Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Hello Jonas, On Sun, Nov 26, 2023 at 12:45:02PM +0100, Jonas Smedegaard wrote: > Quoting Andreas Henriksson (2023-11-26 09:27:32) > > Package: wnpp > > Severity: wishlist > > Owner: Andreas Henriksson > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: bankstown > [...] > > Naming > > --- > > Upstream name: bankstown > > crates.io name: bankstown-lv2 > > > > My proposition is that we use the upstream name as debian source name > > (bankstown) and then use `lv2-bankstown` binary package name, as > > bankstown is a lv2 plugin and that would fit generic naming conventions > > in Debian about packages fitting into a particular ecosystem. > > Please consider using "bankstown-lv2" for both source and binary > package, to not needlessly consume multiple global namespaces. I have been considering, but please help convince me. Pro bankstown-lv2: - not needlessly consume multiple global namespaces. This argument is just saying binary and source name should match, right? - matches crates.io name. - matches what atleast some other lv2 plugins are doing in debian. Cons: - (source) does not match the upstream (git repo) name (bankstown). - does not follow the system-subsystem pattern commonly used in debian. - does not match what other distributions are doing (atleast not Fedora Asahi Remix, which is the reference distribution). It is my opinion that the bankstown name, in any form, is unique enough that noone should need to collide with it. My main worry would be if lv2 itself grew a subsystem called bankstown, which would then be lv2-bankstown as well, but see previous statement about the bankstown uniqueness. For me the strongest pro argument is probably that other lv2 plugins in debian seems to point to the pluginname-lv2 pattern, but not really enough to completely convince me (atleast not for source name). For the source name, if we're going to mangle it maybe I should atleast there follow fedora naming of `rust-bankstown-lv2` which would also align with the Debian rust-team naming convention? I really would like to avoid mangling source name though... Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bankstown Version : 1.0.0 Upstream Contact: https://github.com/chadmed/bankstown/issues * URL : https://github.com/chadmed/bankstown * License : MIT Programming Lang: Rust Description : barebones, fast LV2 bass enhancement plugin Description --- Speakers found in small devices have trouble reproducing bass and sub-bass faithfully. This is because they are power and space constrained, and cannot move the amount of air required to reproduce such low frequencies at audible volumes. Designers of modern devices get around this problem by taking advantage of the fact that humans are very easy to fool. We generate harmonics of bass and sub-bass frequencies to trick the human brain into thinking there is more bass than there really is. . This package contains a lv2 plugin implementing halfway-decent three-stage psychoacoustic bass approximation. Team maintenance --- I've discussed both with Debian rust-team and bananas-team and we've concluded that since this package does not yet integrate well with existing debcargo-conf tooling, we'll maintain the package under the bananas-team umbrella. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/bankstown Naming --- Upstream name: bankstown crates.io name: bankstown-lv2 My proposition is that we use the upstream name as debian source name (bankstown) and then use `lv2-bankstown` binary package name, as bankstown is a lv2 plugin and that would fit generic naming conventions in Debian about packages fitting into a particular ecosystem. For reference, fedora packaging: https://src.fedoraproject.org/rpms/rust-bankstown-lv2/blob/rawhide/f/rust-bankstown-lv2.spec
Bug#1056576: u-boot: Consider building apple/asahi variant
On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote: > On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote: > > On 2023-11-23, Andreas Henriksson wrote: > > > I'm opening this bug report to discuss the potential of building another > > > u-boot variant in a new binary package from src:u-boot for "Apple > > > Silicon" machines. > > > > Thanks! I am guessing this class of hardware may represent a much larger > > community than many other boards already supported in u-boot. Potentially, although most users interested in running Linux on their Apple Silicon probably will go with the distro choice that Asahi Linux project heavily promotes (currently Fedora Asahi Remix). We also have a long way to go before debian can offer a complete end-user ready alternative (without third party packages). At the moment Glanzmann provides a usable installer and his own apt repository which works as a stop-gap solution for people who want to run "debian", while we get proper debian in shape. I'm hopefully we'll be able to somehow provide a smooth upgrade from glanzmann installs to plain debian at some point in the future. > > > > > > > # The overall picture of booting Linux on apple silicon > > > > > > A normal users boot procedure would look something like: > > > Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) > > > -> generic distro EFI boot managers (grub, systemd-boot, etc) > > > > > > > > > m1n1 stage1 is installed by the Asahi Linux installer. > > > m1n1 stage2 + u-boot + dtbs are bundled together and installed > > > as boot.bin on the EFI partition. > > > > From u-boot 2023.10 doc/board/apple/m1.rst: > > > > $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho > > > > So, this suggests to me one has to pick exactly which .dtb to use which > > is presumably device-specific? Or is there some other process? I'd like to point out that src:u-boot is only expected to provide u-boot-nodtb.bin Creating the macho variant and installing it in the ESP will be done by `update-m1n1`. The asahi-fwextract + asahi-scripts packages contains all the integration glue for kernel, initramfs and bootloader updates. (Possibly they should also grow triggers for both m1n1 and u-boot-nodtb.bin to automatically launch update-m1n1.) Thus which dtbs will be used isn't really a concern from the src:u-boot maintainer side. However if you want to think about theoretical license compliance, a possibility would indeed be to use the dtbs coming out of u-boot project (although in reality those dtbs are probably the most outdated ones, and atleast at the moment you'd probably want to use something more up to date for better hardware support which likely means the dtbs from the asahi kernel fork). > > > > I am guessing we would not be able to provide all the possible > > "u-boot.macho" permutations out of the box (unless it is a very small > > number of variants), but can probably ship all the relevent components > > as long as they are in debian main. If the .dtb files come from > > somewhere other than debian main, we would probably have to build it as > > a contrib package. > > Not really, including multiple dtbs is possible. In fact the original > Asahi distribution based on Arch and Asahi Fedora both do that (and use > the dtbs provided by the kernel package). > > See: https://github.com/AsahiLinux/asahi-scripts/blob/main/update-m1n1#L20 > > > > > > > > m1n1 stage2 is already in debian, see: > > > https://tracker.debian.org/m1n1 > > > > Great! > > > > > > > I've looked over the 43 patches and here's my *perception* > > > of the current status: > > > > > > The current upstream apple_m1_defconfig should be usable > > > for booting (from internal storage) on M1 machines. > > > > > > The M2 can possibly boot, but keyboard driver is not yet > > > upstream - so no interaction with u-boot possible. > > > > Ok, so worst case, there is at least one supported working platform even > > without patches? > > Indeed, plus some with partial support. > > > > > > > > Some of the patches updates devicetree files (dts) which are > > > completely apple-specific and should not have any chance to affect > > > anything else, but these are also completely unused so does not > > > neccessarily need to be included. > > > The asahi tools to update the EFI boot.bin that combines m1n1, > > > u-boot and dtbs uses the dtbs from the installed kernel, see: > > > https://tracker.
Bug#1056576: u-boot: Consider building apple/asahi variant
On Thu, Nov 23, 2023 at 12:34:03PM +0100, Andreas Henriksson wrote: [...] > Patches to fix these problems has been posted for review (with mostly > positive feedback): > https://lists.denx.de/pipermail/u-boot/2023-October/535517.html > https://lists.denx.de/pipermail/u-boot/2023-October/535529.html > https://lists.denx.de/pipermail/u-boot/2023-October/535534.html > https://lists.denx.de/pipermail/u-boot/2023-October/535535.html > > This is the bulk of the code changes outside apple specific files > in the current 43 patch series living in asahi fork of u-boot. > > There was previously also an attempt to upstream the Apple Type-C PHY > dummy driver: > https://lists.denx.de/pipermail/u-boot/2023-July/522961.html [...] My mistake here, the PHY driver has already been upstreamed: https://source.denx.de/u-boot/u-boot/-/commit/b99c6357877da2829dc7fd73a50048e83abc53e2 What I wanted to mention was the firmware loading patches: https://lists.denx.de/pipermail/u-boot/2023-July/522962.html Regards, Andreas Henriksson
Bug#1056576: u-boot: Consider building apple/asahi variant
Source: u-boot Version: 2023.07+dfsg-1 Severity: wishlist X-Debbugs-CC: Tobias Heider , Andreas Henriksson Dear Maintainer, I'm opening this bug report to discuss the potential of building another u-boot variant in a new binary package from src:u-boot for "Apple Silicon" machines. The Asahi Linux project has been working on bringing Linux to the newer ARM based line of laptops and stationary (mac mini) by Apple, a.k.a. M1, M2 and just released generation M3. # The overall picture of booting Linux on apple silicon A normal users boot procedure would look something like: Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) -> generic distro EFI boot managers (grub, systemd-boot, etc) m1n1 stage1 is installed by the Asahi Linux installer. m1n1 stage2 + u-boot + dtbs are bundled together and installed as boot.bin on the EFI partition. Apple/macOS does not make use of EFI. The purpose of u-boot is to provide the EFI environment to allow "generic distro boot". m1n1 stage2 is already in debian, see: https://tracker.debian.org/m1n1 # Upstream status The Asahi Linux project has already upstreamed most of their work so simply building `apple_m1_defconfig` is already possible. However they also maintain their own fork of it at: https://github.com/AsahiLinux/u-boot/tree/asahi-releng This fork currently contains 43 additional patches (some already upstreamed, some posted for review, some simply defconfig changes, some dts updates, etc). I've looked over the 43 patches and here's my *perception* of the current status: The current upstream apple_m1_defconfig should be usable for booting (from internal storage) on M1 machines. The M2 can possibly boot, but keyboard driver is not yet upstream - so no interaction with u-boot possible. M3 is not yet supported at all by Asahi Linux (the usual notice of expect atleast 6 months before this happens has been announced). Notable here is that Apple iBoot does not support USB booting, so booting from external media will have to be happening with the help of U-Boot. Unfortunately U-Boot USB support has a number of as I understand it generic bugs that pretty much prevents real-world usage, eg. not support >2TB usb drives, etc. Patches to fix these problems has been posted for review (with mostly positive feedback): https://lists.denx.de/pipermail/u-boot/2023-October/535517.html https://lists.denx.de/pipermail/u-boot/2023-October/535529.html https://lists.denx.de/pipermail/u-boot/2023-October/535534.html https://lists.denx.de/pipermail/u-boot/2023-October/535535.html This is the bulk of the code changes outside apple specific files in the current 43 patch series living in asahi fork of u-boot. There was previously also an attempt to upstream the Apple Type-C PHY dummy driver: https://lists.denx.de/pipermail/u-boot/2023-July/522961.html Some of the patches updates devicetree files (dts) which are completely apple-specific and should not have any chance to affect anything else, but these are also completely unused so does not neccessarily need to be included. The asahi tools to update the EFI boot.bin that combines m1n1, u-boot and dtbs uses the dtbs from the installed kernel, see: https://tracker.debian.org/asahi-fwextract https://tracker.debian.org/asahi-scripts # considerations 1/ are we willing to add another binary package to src:u-boot building apple_m1_defconfig? 2/ should we name the binary package u-boot-apple or -asahi? The existing third-party packages of the asahi fork calls theirs u-boot-asahi. 3/ do we include patches? 3.1/ No patches. If this is the desired path I can volunteer to test that it boots on my M1 machine. Other machines should probably be considered unsupported for now, even though they might have limited usefulness. 3.2/ Minimal set of patches. We identify what we consider crutial only patches and recruit volunteers to test. M2 keyboard? USB? etc... 3.3/ All asahi patches. We consider it simpler to just sync all patches with the asahi fork (even though some are even unused, like the devicetree patches). We trust the Asahi Linux project in their quest to upstream all their work and that they will rebase on newer releases and make our job easy. Debian has a bananas-team that can take responsibility for testing and maintaining software, see: https://wiki.debian.org/Teams/Bananas Also worth noting is that the asahi fork of u-boot has been uploaded and currently sitting in NEW as src:u-boot-asahi. https://ftp-master.debian.org/new.html As mentioned already on the ITP, I think it's excessive to duplicate all of u-boot over 43 patches (and hopefully shrinking): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042471 Thanks for considering, Andreas Henriksson -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (400, 'unstable'), (300, 'experime
Bug#1056177: librust-tikv-jemalloc-ctl-dev: depends on missing packages
Hello Jonas, On Sat, Nov 18, 2023 at 10:31:56AM +0100, Jonas Smedegaard wrote: > Package: librust-tikv-jemalloc-ctl-dev > Version: 0.5.4-1 > Severity: grave > Justification: renders package unusable > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Depends on packages librust-tikv-jemalloc-sys-0.5+default-dev and > librust-tikv-jemalloc-sys-0.5+disable-initial-exec-tls-dev that are > missing in Debian. tikv-jemalloc-sys is currently stuck in NEW (since a month, wonder if there's a reason for it taking so long?). Looks like this problem should resolve itself once it's accepted. Regards, Andreas Henriksson
Bug#810018: New Essential package procps-base
Hello, On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote: > Hello, > For quite some time (since 2006!) there has been a discussion at[1] about > changing from the sysvinit-utils version of pidof to the procps one. A > quick scan of the various distributions shows that only Debian and Ubuntu > (and I assume most other downstreams) use the sysvinit-utils version. I support using procps implementation in Debian, to align us with the rest of the world. > > So to rehash some old drafts, here's the proposal. > > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an Essential > package and only contain pidof. I however do not think pidof needs to be part of the Essential set. Instead I think pidof can just be part of procps package. The sysvinit-utils package will then pull in procps via a dependency (once sysvinit-utils stops being Essential), which would smooth the transition for all sysvinit users until LSB pidofproc has been implemented in all init scripts. > > Why: > This would bring the pidof variant in line with other distributions. > sysvinit-utils would no longer need to be Essential (though that's a > separate issue) and would only have init-d-script, fstab-decode, and > killall5. > > The majority of usage of pidof is in init or pre/post scripts, which really > should be using the LSB pidofproc function. That function in turn > optionally uses pidof if the pidfile parameter is not given. That's > probably a way forward for sometime in the future to not need procps-base > Essential, but it is a way off. Additionally most uses of pidof is `if pidof [...]; then` which will expand to false/else when the pidof command is not available (which it should be on all "normal" systems, as procps is already Priority important). A number of years ago I tested booting a regular debootstrapped system (with all priority important packages, etc) with sysvinit-utils excluded and that did not show a single warning about missing pidof. Someone might want to repeat that experiment. > > sysvinit-utils requires only libc6 while procps-base require libproc-2 but > this is the same library used for the ps,top,w etc tools which are > installed on most systems. > > > 1: https://bugs.debian.org/810018 Regards, Andreas Henriksson
Bug#1055897: ITP: speakersafetyd -- speaker protection daemon for embedded Linux systems
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: speakersafetyd Version : 0.1.4 Upstream Contact: https://github.com/AsahiLinux/speakersafetyd/issues * URL : https://github.com/AsahiLinux/speakersafetyd/ * License : MIT Programming Lang: Rust Description : speaker protection daemon for embedded Linux systems Speaker protection for Apple Silicon (and potentially other) laptops with built-in speakers. The Apple M1, M2, etc laptops do not have protection for melting speakers in hardware, so need this (unlike many other laptops). The implementation is generic enough that it could in the future support other systems as well (eg. many embedded systems might be in the same situation if they have speakers). I hope to maintain this package in the rust-team (with the help of the bananas-team). Preliminary packaging available at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/560 See also: https://wiki.debian.org/Teams/Bananas Regards, Andreas Henriksson
Bug#1055634: ITP: asahi-nvram -- NVRAM utilities for Apple Silicon (arm) machines
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: asahi-nvram Version : 0.2.0-1 Upstream Contact: https://github.com/WhatAmISupposedToPutHere/asahi-nvram/issues * URL : https://github.com/WhatAmISupposedToPutHere/asahi-nvram/ * License : MIT Programming Lang: Rust Description : NVRAM utilities for Apple Silicon (arm) machines I intend to package the asahi-nvram utilities that are useful for Apple Silicon (arm) machines, eg. m1 and m2 (probably also m3, etc). The asahi-nvram includes the following tools (which are separate crates and will thus likely be uploaded as separate source packages): * asahi-nvram - generic utility * asahi-btsync - sync MacOS bluetooth settings to bluez * asahi-wifisync - sync MacOS wifi settings to iwd * asahi-bless - select active boot partition (These all use a common apple-nvram crate/library for parsing the nvram content.) The intention is that the packages will be maintained within the rust-team (with support from the bananas-team) and a MR is available for review at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/555 Regards, Andreas Henriksson
Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hello, On Sat, Nov 04, 2023 at 08:47:11PM +0100, Timo Röhling wrote: > Hi, > > * Andreas Henriksson [2023-11-04 18:05]: > > I've previously suggested that maybe it would be better to set a > > debian-specific version (0d?), to avoid the theoretical situation that > > upstream one day ships a different ABI under the 1 so version. > Normally, I would agree, but in this particular case, Fedora already went > ahead and used SOVERSION 1 [1], so that version is "burned" and we might > just as well use it, too. > > [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch Thanks for pointing this out! > > > I would welcome peoples input here on what you think is best from the > > debian perspective. Obviously we're going to be incompatible with > > everyone else. > I don't think that "incompatible" patch you linked creates much of an issue, > because very few (if any) other library consumers will do this rather > unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc > -llzfse" will automatically use the proper SONAME); besides, it is easy to > patch in Debian packages and trivial to work around with "apt install > liblzfse-dev" for everyone else. > > I do have one remark, though: the idea behind SONAME/SOVERSION is that you > have a common name for all versions which are binary backwards compatible. > Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the > SONAME) in your patch defeats that purpose: it will only work with the exact > version 1.0, but not any (hypothetical) future, backwards-compatible > versions. I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Regards, Andreas Henriksson
Bug#1055206: ITP: asahi-fwextract -- Asahi Linux firmware extractor
Hello, Filling out some of the missed information below and also providing some random thoughts of my own on this. On Thu, Nov 02, 2023 at 09:49:51AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: asahi-fwextract > Version : 0.6.12 > Upstream Authors: Asahi Linux Contributors > URL : https://github.com/AsahiLinux/asahi-installer/tree/main/asahi_firmware > * License : MIT > Description : Asahi Linux firmware extractor > > Scripts to extract firmware blobs from an EFI partition set up by the > Asahi Linux installer. > > I am planning to maintain this as part of the bananas team. > The firmware extractor is part of upstreams (custom) installer-repository. It also depends on asahi-scripts[1] which contains the asahi-fwupdate utility, et.al. This also contains initramfs integration to make the firmwares available during early boot and then provided as a tmpfs under /lib/firmware/vendor in the running system. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/asahi-fwextract https://salsa.debian.org/bananas-team/asahi-scripts Some random thoughts: AIUI currently only initramfs-tools integration is shipped, but maybe it would be good to also provide dracut integration (as provided by upstream, if possible to integrate with debians dracut packaging)?! I don't see any asahi-scripts ITP yet. Since asahi-scripts is a dependency of asahi-fwextract I would have expected one to be posted before this. Maybe the multiple-upstream-tarballs feature could be used to package them together? But it's possibly more problems then benefits. Maybe the asahi-scripts should have a less generic binary package name? and split into multiple packages? Regards, Andreas Henriksson [1]: https://github.com/AsahiLinux/asahi-scripts
Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: lzfse > Version : 1.0 > Upstream Authors: > URL : https://github.com/lzfse/lzfse > * License : BSD-3-Clause > Description : LZFSE Compression library > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > State Entropy coding. It targets similar compression rates at higher > compression and decompression speed compared to deflate using zlib. > > I plan to maintain this as part of the bananas team. Calling all SO versioning experts! The upstream project does not have any shared object version set. A downstream patch was introduced to set one: https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch Upstream has seen no activity since 2017, so trying to interact is assumed to not generate much. Also the ABI is unlikely to change (since no changes are being made). I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else[1], unless you install/runtime-depend-on the -dev package for the unversioned so symlink. Please speak now before this is submitted for NEW. FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS containing embedded firmwares. See asahi-fwextract ITP: #1055206 Regards, Andreas Henriksson [1]: https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch
Bug#1055156: /usr/bin/reverse-depends: can't find relationships when Provides is involved
Package: ubuntu-dev-tools Version: 0.193 Severity: normal File: /usr/bin/reverse-depends Dear Maintainer, It seems the `reverse-depends` utility will not find reverse depencies in the following situation: * Package A has Provides: foobar * Package B has Depends: foobar The provides/depends pattern is used by the Debian rust team when packaging rust crates. Here's a real-word example: ``` > apt-cache show librust-cpal-dev | grep -e alsa-sys -e Source: Source: rust-cpal Depends: librust-alsa-sys-0.2+default-dev, librust-failure-0.1+default-dev (>= 0.1.5-~~), librust-lazy-static-1+default-dev (>= 1.3-~~), librust-libc-0.2+default-dev, librust-num-traits-0.2+default-dev (>= 0.2.6-~~) > apt-cache show librust-alsa-sys-dev | grep -e Source -e > librust-alsa-sys-0.2+default-dev Source: rust-alsa-sys Provides: librust-alsa-sys+default-dev (= 0.2.0-2), librust-alsa-sys-0+default-dev (= 0.2.0-2), librust-alsa-sys-0-dev (= 0.2.0-2), librust-alsa-sys-0.2+default-dev (= 0.2.0-2), librust-alsa-sys-0.2-dev (= 0.2.0-2), librust-alsa-sys-0.2.0+default-dev (= 0.2.0-2), librust-alsa-sys-0.2.0-dev (= 0.2.0-2) > reverse-depends -r sid librust-alsa-sys-dev No reverse dependencies found > reverse-depends -r sid librust-alsa-sys-0.2+default-dev b'Package not published in specified release' > apt-cache policy librust-alsa-sys-dev librust-alsa-sys-dev: Installed: (none) Candidate: 0.2.0-2 Version table: 0.2.0-2 500 500 http://deb.debian.org/debian bookworm/main arm64 Packages 400 http://deb.debian.org/debian unstable/main arm64 Packages > reverse-depends -r sid src:rust-alsa-sys No reverse dependencies found > reverse-depends -r sid -b src:rust-alsa-sys No reverse dependencies found > ``` It would ofcourse be best if reverse-depends could simply handle the Provides pattern, but maybe it would be easier to implement just warning when encountering a package which has Provides at all (just to give the user a chance to react that there might actually be reverse dependencies that are just not found). PS. I also tested (latest version of) ubuntu-dev-tools 0.197 and confirmed it behaves the same. -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (400, 'unstable'), (300, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 6.5.0-asahi-00671-g618f14cf48b9 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ubuntu-dev-tools depends on: ii binutils2.40-2 ii dctrl-tools 2.24-3 ii devscripts 2.23.4 ii diffstat1.65-1 ii distro-info 1.5 ii dpkg-dev1.21.22 ii dput1.1.3 ii lsb-release 12.0-1 ii perl5.36.0-7 ii python3 3.11.2-1+b1 ii python3-apt 2.6.0 ii python3-debian 0.1.49 ii python3-debianbts 4.0.1 ii python3-distro-info 1.5 ii python3-httplib20.20.4-3 ii python3-launchpadlib1.11.0-1 ii python3-lazr.restfulclient 0.14.5-1 ii python3-ubuntutools 0.193 ii sensible-utils 0.0.17+nmu1 ii sudo1.9.13p3-1+deb12u1 ii tzdata 2023c-5 Versions of packages ubuntu-dev-tools recommends: ii arch-test0.20-1 ii ca-certificates 20230311 ii debian-archive-keyring 2023.3 ii debian-keyring 2022.12.24 ii debootstrap 1.0.128+nmu2+deb12u1 ii genisoimage 9:1.1.11-3.4 ii lintian 2.116.3 ii patch2.7.6-7 ii pbuilder 0.231 ii python3-dns 3.2.1-2 ii quilt0.67+really0.66-1 ii reportbug12.0.0 pn ubuntu-keyring | ubuntu-archive-keyring Versions of packages ubuntu-dev-tools suggests: ii brz [bzr] 3.3.2-3 ii brz-debian2.8.78 ii bzr 2.7.0+bzr6622+brz ii bzr-builddeb 2.8.12+brz ii qemu-user-static 1:7.2+dfsg-7+deb12u1 -- no debconf information
Bug#1049209: mfgtools build twice fixed in git
Control: tags -1 + pending The problem should be fixed in https://salsa.debian.org/DebianOnMobile-team/mfgtools/-/commit/bbf6e01fba27d959bafc757cdef8d1fe54295dcc and will be part of next uploaded package version. Regards, Andreas Henriksson
Bug#934463: initscripts: consider taking over hwclock policy machinery
Hello Mark, I quickly looked at both initscripts and util-linux branches and my only comment is about the util-linux-extra Breaks: initscript (<< ...). Since initscripts will need (and has) Breaks/Replaces: util-linux-extra the circular nature of util-linux-extra having the same makes me think this is something which might be useful to think about a second time. Additionally, util-linux-extra might not even be installed on users system now that it's no longer pseudo-essential If we want to prevent (sysvinit) users from partially upgrading util-linux-extra and lack the hwclock machinery, then we likely also want to prevent them from deinstalling util-linux-extra which would have the same result. Thus I wonder maybe the Breaks: initscripts (<< ) would be better to have on util-linux (Essential).. IF it's needed at all. The util-linux package is the one which originally carried the hwclock init machinery after all. Hope you see that I've not thought all the way about this and not made up my mind of what I think is the best solution in the end, but hopefully my thoughts above give some food for thought. Just thought this might be something that might deserve a second thought even if nothing changes in the end. Regards, Andreas Henriksson
Bug#934463: initscripts: consider taking over hwclock policy machinery
Hello Mark, Happy to see progress on this. I'm adding zeha to CC as he has taken over the official util-linux debian maintainer role. On Tue, Aug 22, 2023 at 09:58:47AM +0100, Mark Hindley wrote: > Andreas, > > I have prepared the necessary updates to src:sysvinit to incorporate the > hwclock > machinery in initscripts. Specifically the files > > /etc/default/hwclock > /etc/init.d/hwclock.sh > /usr/share/man/man5/hwclock.5 > /usr/lib/udev/hwclock-set > /usr/lib/udev/rules.d/hwclock.rules Looks good to me. HEADS UP: One thought here is that the init script will still need the actual hwclock binary. While util-linux-extra currently is pseudo-essential I think zeha plans to make it a regular package at some point in the future which probably mean you want initscripts to depend on it (or make the scripts handle that hwclock binary is not available, but that sounds less compelling to me). You might want to add the dependency now so that it's not forgotten once util-linux-extra is no longer pseudo-essential. (I'd be happy if I could see the actual diff, but could not spot a relevant branch on salsa/debian/sysvinit.) > > Obviously we need to coordinate the transition and I will add Breaks/Replaces > << the util-linux-extra version which drops the files. Although zeha should probably ack this, I personally think it's better if a single person uploads both packages in a situation like this. I thus propose that you prepare and post a diff for util-linux and then you agree on a time slot where no maintainer uploads are planned (likely after the current version just uploaded has successfully migrated to testing) and then you just NMU util-linux (together with the sysvinit upload). You thus have control over both version numbers used and can set the relationships as needed. (This is how I've done in the past when taking over files from packages maintained by other people and it works best IMHO.) If you'd rather see that someone else some or all of the util-linux poking then please say how you'd like to see it and I'll help out where needed (unless zeha would rather do it himself). Feel free to push a branch to salsa.debian.org/debian/util-linux with proposed changes if you do prepare them. > > If util-linux-extra were to use it, my understanding is that rm_conffile only > removes *unmodified* conffiles so user modifications should be preserved. But > we > might consider synchronised uploads to experimental to test and confirm. Honestly I've forgotten all about how I envisioned this migration to happen. > > Best wishes > > Mark PS. I'd be happy to discuss potential improvements that can be done, but think the first step should only be to get the files moved over. One step at a time. Just don't want to leave you with the impression that I/we are just dumping all the burden on you for old sins. For example the hwclock(5) manpage probably contains questionable information. There's really alot of pretending that userspace is actually in control of the RTCs while the reality is that the kernel has alot of its own policy around this and unfortunetly some information is set at compile-time. //Andreas
Bug#1042471: ITP: u-boot-asahi -- u-boot bootloader for Apple silicon systems
Hello Tobias Heider, While I'm as entusiastic as anyone else here, I have to ask a few questions that might be a bit skeptical below... On Fri, Jul 28, 2023 at 10:00:35PM +0200, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: u-boot-asahi > Version : 2023.04-2 > Upstream Authors: Mark Kettenis > URL : https://github.com/AsahiLinux/u-boot This is a development repository and things are sent upstream to u-boot (mainline). The upstreaming effort is driven by the person you listed as author (while actual authors is usually someone else AFAIK). Is there any other u-boot development forks being packaged in Debian and how viable do you think this is? Is the plan to eventually provide a migration to u-boot-asahi binary package provided by src:u-boot or how do you see the future path of this? Is this targeting Trixie or Experimental? Is there any particular reason you're targeting u-boot? Are you planning on working on any installer? Also planning on packaging linux-asahi development repo? Do you have contact with upstream about this? They have been very vocal about distros shipping things that causes additional problems for (users and then in turn for) the Asahi project in the past. (Also atleast some Asahi team members are already not publishing their development git branches because of fear of people dumping them into distros.) How does this effort compare against Thomas Glanzmann effort[1]? Do you plan to provide a migration path (and why would users migrate over to debian-bananas effort instead of Glansmanns effort)? (IMHO while Glanzmanns effort is not my preferable packaging style, it provides a very good stop gap solution until everything has been mainlined into u-boot, linux, mesa which in turn then and only then makes it ready for proper Debian packaging. Apart from mainlining work which hopefully will happen without any assintance from Debian, the biggest challange is probably to provide a sane installer solution acceptable for Debian. Is this a task the bananas team intends to take on?) Something that I think is missing in Glanzmanns effort is providing https://github.com/AsahiLinux/alsa-ucm-conf-asahi which is needed for audio out on the mic/headphone jack. Would be great if these files found a home in some existing (or possibly new) package in Debian if you're looking for somewhere to invest your time. (The alsa-ucm-conf package currently provides all files currently offered by Debian.) > * License : GPL-2 > Description : A u-boot bootloader for Apple silicon systems > [... snip generic u-boot description ...] > > u-boot is used as a second stage bootloader for Linux on M1/M2 Apple macs. AFAIK and FWIW u-boot is in this case used to provide an EFI(-like) environment (to be able to use generic distro bootloaders as the next step in the boot chain). > This will be maintained by the Debian Bananas team. I'm not familiar with this team, is there anywhere to read up on its purpose and background or maybe you can give an introduction to this team? I found https://salsa.debian.org/bananas-team which links to the InstallingDebianOn/Apple/M1 wiki page which has no information as far as I can see about the Bananas team. Regards, Andreas Henriksson [1]: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian
Bug#981458: vtun systemd service
Hello again, Fear we're sliding off-topic here, but will try to follow up anyway in case my input is in any way helpful. On Tue, Jul 04, 2023 at 12:08:36PM +0200, Francesco P. Lovergine wrote: > First of all, sorry for the use of irritual instead of weird (false friend > term applies > in this case, for non native speakers). I'm not a native speaker myself. > > About the discouraging of EnvironmentFile could you please point where > it is expressed in the Policy? By Policy I assume you mean Debian Policy? My most recent interaction with policy was to to remove policys very detailed description of how sysvinit worked which was forbidding things like startpar and insserv, which has been mandatory for decades in Debian under sysvinit. By then there wasn't a single mention of systemd. Maybe things have changed in the last couple of years, but I would definitely not take Debian Policy as a authoritative source for any systemd related recommendations. > For sure, Debian has impressive use of the /etc/default/ tree > which was and still is Debian specific. The /etc/default pattern is for sure both Debian and sysvinit specific. The same thing exists as /etc/sysconfig in RH/RPM world. I guess unifying this was never useful since init scripts where always very distro specific anyway. Notably /etc/default/foo is posix shell, while EnvironmentFile= takes a key=value file (without executing it in shell context). This means that for example if /etc/default/foo contains: ``` UNAME="`uname -a`" ``` You would get different results with the init script pattern vs systemd EnvironmentFile=. > That is probably the origin of those rumors. > > Indeed, enabling/disabling of services by using an option in /etc/default/ > (as for a lots > of services in the past) is considered a bad practice due to the old init > sysv days. Today, one should enable/disable the unit instead, which is much > more clean. That make sense. Now you are talking about the infamous NOSTART anti-pattern, which is a different problem and should for sure not be used (unrelated ot which init is used). > I disagree with a general deprecation > of Environment entries instead (files or vars), which is optimal mode of > solving > configuration issues without writing whole units or overrides. But on those > regards, > using a non-templated unit as a pseudo-templated is a very strange choice. > > Anyway it is your choice. For sure not my choice. I'm just providing something in the hope that things will move forward as they seem to have been stagnant for this package up until this day. Regards, Andreas Henriksson
Bug#981458: vtun systemd service
Hello Francesco P. Lovergine, Thanks for your feedback on this! On Mon, Jul 03, 2023 at 06:17:20PM +0200, Francesco P. Lovergine wrote: > Uhm, it seems to me quite irritual using a template unit file without a > template variable. Which reflects > the quite strange use of /etc/default/vtun with multiple indexed vars, > instead of multiple configuration files such as: > > /etc/vtun.d/config?.vars (or even under /etc/vtun if you prefer so) > > and of course you can override the env variables by using an > /etc/vtun.d/%i.vars > > where it makes sense in the template file. I think this would be the right > moment to convert the > insane limited number of env var sets in /etc/default/vtun into multiple > ordinary configuration > files and using something like that. > > EnvironmentFile=-/etc/vtun.d/%i.vars > > would override name, host and args variables. > > I'm missing something? While I atleast partially agree with your initial sentence, I'm not onboard with your suggested solution. In my understanding use of EnvironmentFile= is discuraged (and if I'm not mistaken I've even read statements saying it was a mistake to ever add it as an option). It seems to me like you're bending over backwards trying to invent something that actually needs the instance variable. (I'm however fine with anything that gets things moving forward of using native units instead of init script. I'm also not even a user of this package/program as previously stated, so it affects me very little. Use what ever solution you find acceptable!) Regards, Andreas Henriksson
Bug#1000353: [Pkg-utopia-maintainers] Bug#1000353: Downgrade e2fsprogs from Depends to Recommends?
Hello, TL;DR Recommends: e2fsprogs instead of Depends should be fine. On Tue, Nov 23, 2021 at 12:20:29AM +0100, Michael Biebl wrote: > On 22.11.21 01:02, Trent W. Buck wrote: > > Package: libblockdev-fs2 > > Version: 2.25-2 > > Severity: wishlist > > File: /usr/lib/x86_64-linux-gnu/libbd_fs.so.2.0.0 > > > > libblockdev-fs2 Depends e2fsprogs because it calls dumpe2fs > > This was done per https://bugs.debian.org/887270 > > AFAICT there is a run-time check for this: > > > > https://codesearch.debian.net/search?q=bd_fs_ext_is_tech_avail > > > > In other words, dumpe2fs isn't found in $PATH, libblockdev-fs2 will > > print an obvious error, instead of e.g. segfaulting. > > > > Therefore, can you downgrade e2fsprogs from Depends to Recommends? > > Would probably be ok with me, given that libbd_fs also handles other file > systems (and we don't have any hard deps e.g. for xfsprogs, ntfsprogs or > dosfstools) > > Andreas, wdyt? For the record: I stumbled upon this... apparently I missed this 2 years ago even though you CCed me. While it's great that the code has gracefull failure mode when e2fsprogs is missing I'm not entirely convinced the "obvious" error message will be noticed by (all) regular users. However e2fsprogs is still `Priority: required` (and also has `Important: yes` so once you get it, it'll be hard to get rid of). So I think it's very unlikely that a regular user ends up without e2fsprogs installed even if we drop it down to Recommends. We should thus make it easier to support the non-regular usecase (now that I'm aware there is actually such a use-case thanks to the description of this bug report!). Regards, Andreas Henriksson
Bug#1040203: udisks2: should use the systemd-analyze security features
Control: tags -1 + upstream Hello Russel Cooker, On Mon, Jul 03, 2023 at 10:08:18PM +1000, Russell Coker wrote: > Package: udisks2 > Version: 2.9.4-4 > Severity: normal > > I don't think this daemon is a likely target of attack. But I think it's > goot to try and keep the overall score from "systemd-analyze security" as low > as possible. > > My tests show that it seems to work OK with the following settings. I think > that more testing is needed before adding all of them. But some of them are > low risk like restricting to AF_UNIX and restricting capabilities and the > system call architecture. I think this is a good idea, but I think it's a much better idea if we have upstream maintain this along the code changes they make which might influence what settings you need/want. Upstream provides the udisks2.service file after all. Could you create an upstream issue or even pull request? https://github.com/storaged-project/udisks > > [Service] > CapabilityBoundingSet=CAP_SYS_ADMIN > # needs @resources > SystemCallFilter=~@cpu-emulation @debug @raw-io @reboot @swap @obsolete > @privileged > SystemCallArchitectures=native > UMask=077 > NoNewPrivileges=true > ProtectKernelLogs=true > ProtectControlGroups=true > ProtectKernelModules=true > RestrictNamespaces=true > RestrictSUIDSGID=true > LockPersonality=true > ProtectHostname=true > ProtectKernelTunables=true > RestrictAddressFamilies=AF_UNIX > [...] I'm guessing a topic for discussion upstream will be in which systemd version respective option was introduced, what version is the minimum required one upstream thinks is acceptable setting as a requirement and making sure unsupported options is gracefully ignored. If you know the answer to any of this for the above options it might be good to include from the get go. Regards, Andreas Henriksson
Bug#981458: vtun systemd service
Control: forcemerge -1 1039413
Control: severity -1 important
Control: retitle -1 vtun: please provide vtun@.service and mask init script
Hello,
I'm attaching a patch for the vtun debian package that should hopefully
be a good start in migrating to native systemd units.
The patch is COMPLETELY UNTESTED as I'm not myself a user of vtun.
Please make sure to set FIRST_SYSTEMD_SERVICE_VERSION to the correct
debian package version including these changes.
The attached patch adds a vtun@.service as the init script seems to have
used a home-brew template units style.
The /etc/default/vtun CLIENT$i_* variables are broken up into separate
vtun@.service instances, eg CLIENT1_NAME, CLIENT1_HOST, CLIENT1_ARGS
goes to vtun@CLIENT1.service override as NAME, HOST and OPTIONS.
This is done as a one-time migration
(This also lifts the restrictions of having 0-9 instances.)
You most likely also want to make sure vtun.service (without the @)
is a symlink to /dev/null, to mask the init script.
See also:
https://src.fedoraproject.org/rpms/vtun/tree/81e15b3a03b89bffe0e6076a235720d40f343292
You might also want to provide the socket unit
Regards,
Andreas Henriksson
diff '--color=auto' -uriNp vtun-3.0.4/debian/postinst vtun-3.0.4.systemd/debian/postinst
--- vtun-3.0.4/debian/postinst 2019-11-11 01:17:37.0 +0100
+++ vtun-3.0.4.systemd/debian/postinst 2023-07-03 15:47:08.717223223 +0200
@@ -46,6 +46,36 @@ case "$1" in
;;
esac
+# migrate old init.d style settings to systemd
+FIRST_SYSTEMD_SERVICE_VERSION="3.0.4-2.1"
+if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt-nl "$FIRST_SYSTEMD_SERVICE_VERSION~" ; then
+(
+echo "Checking if we need to migrate /etc/default/vtun settings to 'vtun@.service'."
+if [ -e /etc/default/vtun ]; then
+. /etc/default/vtun
+fi
+
+for i in 0 1 2 3 4 5 6 7 8 9; do
+eval name=\$CLIENT${i}_NAME
+eval host=\$CLIENT${i}_HOST
+eval args=\$CLIENT${i}_ARGS
+if [ -n "$name" ] && [ -n "$host" ]; then
+echo "One-time migration of vtun CLIENT$i settings to vtun@CLIENT$i.service"
+mkdir -p "/etc/systemd/system/vtun@CLIENT$i.service.d/"
+echo "[Service]" >> "/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"NAME=$name\"" >> "/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"HOST=$host\"" >> "/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"OPTIONS=$args\"" >> "/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+if [ -n "${RUN_SERVER:-}" ] && [ "${RUN_SERVER:-}" != "no" ]; then
+deb-systemd-helper enable "vtun@CLIENT$i"
+fi
+fi
+
+done
+)
+fi
+
+
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.
diff '--color=auto' -uriNp vtun-3.0.4/debian/vtun@.service vtun-3.0.4.systemd/debian/vtun@.service
--- vtun-3.0.4/debian/vtun@.service 1970-01-01 01:00:00.0 +0100
+++ vtun-3.0.4.systemd/debian/vtun@.service 2023-07-03 15:23:25.513183684 +0200
@@ -0,0 +1,12 @@
+[Unit]
+Description=Virtual Tunnels over TCP/IP networks
+After=network.target
+
+[Service]
+ExecStart=/usr/sbin/vtund -n $OPTIONS $NAME $HOST
+# Reload should be synchronous, but signals are not...
+ExecReload=/usr/bin/kill -HUP $MAINPID
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
Bug#1030087: xinetd: Please provide systemd unit
Control: tags -1 + patch
Hello,
I'm attaching my attempt at fixing this bug. Please note that I'm not
actually an xinetd user myself, so this is virtually untested and
who ever picks this up needs to take responsibility to make sure
this actually works as intended.
Please make sure the FIRST_VERSION_WITH_SYSTEMD_SERVICE is set properly.
See attached debdiff.
Regards,
Andreas Henriksson
diff -Nru xinetd-2.3.15.3/debian/changelog xinetd-2.3.15.3/debian/changelog
--- xinetd-2.3.15.3/debian/changelog2018-02-05 19:31:09.0 +0100
+++ xinetd-2.3.15.3/debian/changelog2023-07-03 12:39:06.0 +0200
@@ -1,3 +1,10 @@
+xinetd (1:2.3.15.3-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add native systemd service (and migrate /etc/default/xinetd settings over)
+
+ -- Andreas Henriksson Mon, 03 Jul 2023 12:39:06 +0200
+
xinetd (1:2.3.15.3-1) unstable; urgency=low
* New upstream release
diff -Nru xinetd-2.3.15.3/debian/xinetd.postinst
xinetd-2.3.15.3/debian/xinetd.postinst
--- xinetd-2.3.15.3/debian/xinetd.postinst 1970-01-01 01:00:00.0
+0100
+++ xinetd-2.3.15.3/debian/xinetd.postinst 2023-07-03 12:38:46.0
+0200
@@ -0,0 +1,80 @@
+#!/bin/sh
+
+FIRST_VERSION_WITH_SYSTEMD_SERVICE="1:2.3.15.3-1.1"
+
+if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt-nl
"$FIRST_VERSION_WITH_SYSTEMD_SERVICE~" ; then
+ echo "Doing one-time migration of /etc/default/xinet to xinetd.service
override (if needed)."
+
+
+(
+if [ -e /etc/default/xinetd ]; then
+ . /etc/default/xinetd
+
+ # Internal state variables
+ DISABLE_IPV6=""
+ DISABLE_INETD_COMPAT=""
+ CHANGE_PIDFILE=""
+ CHANGE_XINETD_OPTS=""
+
+ # Detect which overrides we need to set up
+
+ ## INETD_COMPAT and INETD_IPV6
+ case "${INETD_COMPAT:-}" in
+ [Yy]*)
+ # check we have ipv6 support (one time only)
+ if ! perl -MSocket -e 'exit (!socket($sock, AF_INET6,
SOCK_STREAM, 0))'; then
+ DISABLE_IPV6="y"
+ fi
+ # use shipped defaults
+ ;;
+ *)
+ DISABLE_INETD_COMPAT="y"
+ ;;
+ esac
+
+ ## PIDFILE
+ if [ "${PIDFILE:-}" != "/run/xinetd.pid" ] && [ -n "${PIDFILE:-}" ];
then
+ CHANGE_PIDFILE="y"
+ fi
+
+ ## XINETD_OPTS
+ if [ "${XINETD_OPTS:-}" != "-stayalive" ]; then
+ CHANGE_XINETD_OPTS="y"
+ fi
+
+
+ # Any overrides needed or everything default?
+ if [ -n "$DISABLE_IPV6" ] || \
+ [ -n "$DISABLE_INETD_COMPAT" ] || \
+ [ -n "$CHANGE_PIDFILE" ] || \
+ [ -n "$CHANGE_XINETD_OPTS" ] ; then
+
+ echo "Migrating /etc/default/xinetd settings to xinetd.service
override."
+
+ # Create service overrides
+ mkdir -p /etc/systemd/system/xinetd.service.d/
+ echo "[Service]" >
/etc/systemd/system/xinetd.service.d/override.conf
+
+ if [ -n "$DISABLE_INETD_COMPAT" ]; then
+ echo "Environment=\"INETD_COMPAT=\"" >>
/etc/systemd/system/xinetd.service.d/override.conf
+ echo "Environment=\"INETD_IPV6=\"" >>
/etc/systemd/system/xinetd.service.d/override.conf
+ elif [ -n "$DISABLE_IPV6" ]; then
+ echo "Environment=\"INETD_IPV6=\"" >>
/etc/systemd/system/xinetd.service.d/override.conf
+ fi
+
+ if [ -n "$CHANGE_XINETD_OPTS" ]; then
+ echo "Environment=\"XINETD_OPTS=$XINETD_OPTS\"" >>
/etc/systemd/system/xinetd.service.d/override.conf
+ fi
+
+ if [ -n "$CHANGE_PIDFILE" ]; then
+ echo "Environment=\"XINETD_PIDFILE=$PIDFILE\"" >>
/etc/systemd/system/xinetd.service.d/override.conf
+ echo "PIDFile=$PIDFILE" >>
/etc/systemd/system/xinetd.service.d/override.conf
+ fi
+
+ fi
+fi
+)
+
+fi
+
+#DEBHELPER
diff -Nru xinetd-2.3.15.3/debian/xinetd.service
xinetd-2.3.15.3/debian/xinetd.service
--- xinetd-2.3.15.3/debian/xinetd.service 1970-01-01 01:00:00.0
+0100
+++ xinetd-2.3.15.3/debian/xinetd.service 2023-07-03 12:39:06.0
+0200
@@ -0,0 +1,22 @@
+[Unit]
+Description=powerful inetd replacement
+After=network.target
+Documentation=man:xinetd
+Documentation=man:xinetd.conf
+Documentation=man:xinetd.log
+
+[Service]
+Type=forking
+Environment="XINETD
Bug#877512: slapd: enabled systemd integration (untested patch)
Hello, On Wed, Jun 28, 2023 at 09:53:06AM -0700, Quanah Gibson-Mount wrote: > > > --On Wednesday, June 28, 2023 10:49 AM -0700 Ryan Tandy > wrote: > > > > > > TODO: For unknown reason configure seems to want to use > > > /usr/lib/systemd/system (rather than /lib/systemd/system) despite the > > > precense of systemd.pc ... the configure script has hard-coded fallback > > > paths... > > > > Thanks for noting this, definitely sounds like something we need to look > > into. > > Feel free to file a bug upstream if you think the current configure.ac code > needs adjustment. [...] It's my impression that configure.ac is missing a call to: PKG_PROG_PKG_CONFIG(0.29) Thus the PKG_CONFIG variable will be unset, and thus the PKG_CHECK_* macros will just skip over and do nothing. FWIW you do have this: m4_ifndef([PKG_PREREQ], [m4_fatal([must install pkg-config 0.29 or later before running autoconf/autogen])]) ... but that only seems to check that pkg.m4 is new enough, not that the actual pkg-config binary/utility exists. Adding `PKG_PROG_PKG_CONFIG(0.29)` directly after the m4_ifndef and rebuilding gave me the expected systemdsystemunitdir=/lib/systemd/system (as systemd.pc says on debian) rather than the hardcoded fallbacks. Regards, Andreas Henriksson
Bug#877512: slapd: enabled systemd integration (untested patch)
Hello, I'm attaching a patch which has only been compile-tested as I don't use slapd myself. It would be great if someone who uses slapd could pick it up, test it and finish the remaining work. TODO: For unknown reason configure seems to want to use /usr/lib/systemd/system (rather than /lib/systemd/system) despite the precense of systemd.pc ... the configure script has hard-coded fallback paths... This can possibly cause problems with debhelper integration picking it up properly. Feel free to investigate! :) Regards, Andreas Henriksson >From 2ccd6781e2bb10dda99be0c4d0ad3c599fd96a20 Mon Sep 17 00:00:00 2001 From: Andreas Henriksson Date: Wed, 28 Jun 2023 18:13:45 +0200 Subject: [PATCH] Enable systemd integration Build-dep on: - libsystemd-dev for systemd/sd-daemon.h - systemd-dev for systemd.pc Use configure flag --with-systemd when building services (slapd). --- debian/control | 2 ++ debian/rules | 2 ++ debian/slapd.install | 2 ++ 3 files changed, 6 insertions(+) diff --git a/debian/control b/debian/control index 9b27cf69f..7c0baabb1 100644 --- a/debian/control +++ b/debian/control @@ -15,6 +15,8 @@ Build-Depends: debhelper-compat (= 12), libltdl-dev , libperl-dev (>= 5.8.0) , libsasl2-dev, + libsystemd-dev , + systemd-dev , libwrap0-dev , nettle-dev , openssl , diff --git a/debian/rules b/debian/rules index 7992a133d..94599e108 100755 --- a/debian/rules +++ b/debian/rules @@ -25,6 +25,8 @@ ifeq ($(DEB_HOST_ARCH_OS),hurd) endif ifneq ($(filter pkg.openldap.noslapd,$(DEB_BUILD_PROFILES)),) CONFIG += --disable-slapd +else + CONFIG += --with-systemd endif CONTRIB_MODULES = autogroup lastbind passwd passwd/pbkdf2 passwd/sha2 smbk5pwd diff --git a/debian/slapd.install b/debian/slapd.install index c5f7946cd..e4cde1359 100644 --- a/debian/slapd.install +++ b/debian/slapd.install @@ -1,3 +1,5 @@ +usr/lib/systemd/system/slapd.service + etc/ldap/schema usr/lib/slapd usr/sbin usr/lib/*/libslapi-*.so.* -- 2.39.2
Bug#877512: slapd service fixed-upstream
Control: tags -1 + fixed-upstream https://git.openldap.org/openldap/openldap/-/commit/f3501534d4443a2d241d70291b60be6034761cf1 Regards, Andreas Henriksson
Bug#1037333: libeconf: CVE-2023-32181 CVE-2023-22652
Hello Salvatore, On Sun, Jun 11, 2023 at 05:12:57PM +0200, Salvatore Bonaccorso wrote: > Source: libeconf > Version: 0.5.1+dfsg1-1 > Severity: important > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerabilities were published for libeconf. [...] Thanks for notifying me about this. I've prepared libeconf 0.5.2 packages in git and just uploaded towards unstable. IMHO I think uploading the same to stable would be fine (even though there's one "unrelated" change in new upstream version so maybe not strictly a security-only release), because libeconf has no reverse dependencies in the debian archive yet! The risk of regression should thus be almost non-existant. If by chance you have the SRM dance in muscle memory, please feel free to take over getting 0.5.2 into stable! It's been a while for me and honestly since libeconf is still unused it's very low prio for me. Regards, Andreas Henriksson
Bug#1034213: arno-iptables-firewall: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: arno-iptables-firewall > Version: 2.1.1-7 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package arno-iptables-firewall is shipping files > (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] It seems the package has manually written maintainer scripts (instead of letting debhelper generating the proper code): ``` arno-iptables-firewall-2.1.1> grep -R deb-systemd-helper debian/ debian/postrm: # Remove deb-systemd-helper's state file debian/postrm: deb-systemd-helper purge arno-iptables-firewall.service debian/postinst:deb-systemd-helper enable arno-iptables-firewall.service ``` So while I think manually written maintscript code should be frowned upon (since it's a very common source of bugs), I guess this means this bug is not RC severity?! Regards, Andreas Henriksson
Bug#1034214: tcmu-runner: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: tcmu-runner > Version: 1.5.4-4 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package tcmu-runner is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] tcmu-1.5.4> grep -R systemd.system . ./debian/tcmu-runner.install:debian/tmp/usr/lib/systemd/system/tcmu-runner.service ./README.md:1. If using systemd, copy `org.kernel.TCMUService1.service` to `/usr/share/dbus-1/system-services/` and `tcmu-runner.service` to `/lib/systemd/system`. ./CMakeLists.txt: install(FILES tcmu-runner.service DESTINATION /usr/lib/systemd/system/) These paths are wrong and the culprit of this bug report. You could change them to use the currently correct path, but then you would have to revert that again after bookworm is released when the paths will change again. A better solution would derive the path from systemd.pc, eg. pkg-config --variable=systemdsystemunitdir systemd (Note: this needs pkg-config and systemd in build-deps) Since the upstream build system is CMake, there are plenty of others to look at of how to implement using pkg-config and querying the variable in CMake. This should give you atleast a few hits that could be possible examples to follow: https://codesearch.debian.net/search?q=systemdsystemunitdir+path%3ACMake=0 https://codesearch.debian.net/search?q=systemdsystemunitdir+path%3AFindSystemd=0 Regards, Andreas Henriksson
Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hello again,
On Wed, Apr 12, 2023 at 01:19:52PM +0200, Andreas Henriksson wrote:
> On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> > Package: drkonqi
> > Version: 5.27.2-1
> > Severity: serious
> > Tags: sid bookworm
> > User: debhel...@packages.debian.org
> > Usertags: systemd-files-in-usr-bookworm
> >
> > Dear Maintainer,
> >
> > It seems that your package drkonqi is shipping files (.service, .socket or
> > .timer) in /usr/lib/systemd/system.
> [...]
>
> ```
> $ apt-file show drkonqi | grep systemd/system
> drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
> ```
I forgot to mention that since this is a template unit (@.service)
maybe the severity should not be RC.
As far as I know debhelper will not enable any instance of a template
unit by default anyway, so the consequences that bigon warned about
probably doesn't apply here?
>
> From ./src/coredump/processor/CMakeLists.txt :
>
> ```
> configure_file(
> drkonqi-coredump-processor@.service.cmake
> ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
> )
> install(
> FILES ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
> DESTINATION ${KDE_INSTALL_SYSTEMDUNITDIR}/system
> )
> ```
>
> So apparently KDE_INSTALL_SYSTEMDUNITDIR is not set correctly.
>
> I'm not sure where this variable comes from. The above line is the
> only hit on
> https://codesearch.debian.net/search?q=KDE_INSTALL_SYSTEMDUNITDIR=1
>
> Maybe someone with better understanding of KDE and CMake can help figure this
> out.
>
> If not, I guess you can always add a hack that appends to dh_install to move
> the file into the correct directory as returned by
> `pkg-config --variable=systemdsystemunitdir systemd`.
> (Note: make sure to have systemd.pc available by build-dep on systemd)
Regards,
Andreas Henriksson
Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: drkonqi
> Version: 5.27.2-1
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package drkonqi is shipping files (.service, .socket or
> .timer) in /usr/lib/systemd/system.
[...]
```
$ apt-file show drkonqi | grep systemd/system
drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
```
>From ./src/coredump/processor/CMakeLists.txt :
```
configure_file(
drkonqi-coredump-processor@.service.cmake
${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
)
install(
FILES ${CMAKE_CURRENT_BINARY_DIR}/drkonqi-coredump-processor@.service
DESTINATION ${KDE_INSTALL_SYSTEMDUNITDIR}/system
)
```
So apparently KDE_INSTALL_SYSTEMDUNITDIR is not set correctly.
I'm not sure where this variable comes from. The above line is the
only hit on
https://codesearch.debian.net/search?q=KDE_INSTALL_SYSTEMDUNITDIR=1
Maybe someone with better understanding of KDE and CMake can help figure this
out.
If not, I guess you can always add a hack that appends to dh_install to move
the file into the correct directory as returned by
`pkg-config --variable=systemdsystemunitdir systemd`.
(Note: make sure to have systemd.pc available by build-dep on systemd)
Regards,
Andreas Henriksson
Bug#1034216: boinc-client: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: boinc-client > Version: 7.20.5+dfsg-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package boinc-client is shipping files (.service, .socket > or > .timer) in /usr/lib/systemd/system. [...] So the package already contains this patch: ./debian/patches/systemd-directory.patch where the (currently) wrong path is used. Simply updating the patch would work, but then would have to be reverted again once it's changed in the future (after bookworm release). A better solution would be to use pkg-config and query systemd.pc for the correct path, eg. pkg-config --variable=systemdsystemunitdir systemd Note: that this needs systemd.pc to be available, thus you'll need to build-depend on the systemd package (as you already list pkg-config in build-deps). Regards, Andreas Henriksson
Bug#1034217: qbittorrent-nox: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: qbittorrent-nox
> Version: 4.5.2-1
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package qbittorrent-nox is shipping files (.service,
> .socket or
> .timer) in /usr/lib/systemd/system.
[...]
This package seems to install a template unit (as well as a user unit).
Might be wrong, but as far as I know there's no debhelper code that
automatically enables an instance of a template unit, so maybe this
bug report does not qualify as RC severity.
The CMake build system seems to do things correctly by querying
systemd.pc for the systemdsystemunitdir variable already
(see ./cmake/Modules/FindSystemd.cmake and the use of it in
./dist/unix/CMakeLists.txt )
There's however this in unixconf.pri (which is wrong):
```
# Systemd Service file
nogui:systemd {
systemdService.files = $$DIST_PATH/systemd/qbittorrent-nox@.service
systemdService.path = $$PREFIX/lib/systemd/system
INSTALLS += systemdService
}
```
Regards,
Andreas Henriksson
Bug#1034218: cfengine3: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: cfengine3 > Version: 3.21.0-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package cfengine3 is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] So configure.ac contains this: ``` AC_ARG_WITH(systemd-service, AS_HELP_STRING([--with-systemd-service=PATH], [Install systemd service file in given path. The default is no, but if specified, the default path is /usr/lib/systemd/system.]), ``` So it hard-codes a default path, rather than check with systemd.pc. I think that could be fixed to actually use the path from systemd.pc instead. Alternatively you could ofcourse use the existing mechanism and extend the --with-systemd-service you're already passing in debian/rules to actually include the correct path as an argument. eg. ``` SYSTEMDSYSTEMUNITDIR=$(shell pkg-config --variable=systemdsystemunitdir systemd) [...] --with-systemd-service=$(SYSTEMDSYSTEMUNITDIR) \ [...] ``` Note: do not forget to add pkg-config and systemd (for systemd.pc) to build-deps. Regards, Andreas Henriksson
Bug#1034219: debomatic: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: debomatic > Version: 0.26-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package debomatic is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] debomatic is the second package using the pybuild build system that I look at which has subdirectories `usr/lib/systemd/system/` containing the service file and then no obvious code to install it so I guess all the magic to handle it is in pybuild or some upstream build system not included in the actual source package itself. I'm not sure exactly what the best option is to adress this for pybuild using packages, but my guess would be to have some debian/rules hack that moves the file (if it's not already located in the same path as returned by `pkg-config --variable=systemdsystemunitdir systemd`) after dh_install has run probably. Regards, Andreas Henriksson
Bug#1034220: shadowsocks-libev: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: shadowsocks-libev > Version: 3.3.5+ds-9 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package shadowsocks-libev is shipping files (.service, > .socket or > .timer) in /usr/lib/systemd/system. [...] The incorrect path is in: ./debian/shadowsocks-libev.install (also in ./debian/README.Debian ) Changing it to lib/systemd/system and then in trixie back to usr/lib/systemd/system again seems suboptimal. Rather than duplicating the path everywhere, the best thing would be to simply query systemd.pc for it, eg: pkg-config --variable=systemdsystemunitdir systemd This needs pkg-config and systemd to be in build-depends. To use this command in ./debian/shadowsocks-libev.install you would have to make the file executable and integrate dh-exec. I'll leave it up to you to decide if you think integrating dh-exec is worth it or not (Another option is to make the upstream build system install the file in the correct path.) Regards, Andreas Henriksson
Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hello Max Kellermann,
On Tue, Apr 11, 2023 at 04:13:28PM +0200, Max Kellermann wrote:
> On 2023/04/11 15:11, Andreas Henriksson wrote:
> > The culprit seems to be that mpd falls back on hard-coded path (instead
> > of failing) when systemd.pc is not found!
>
> What does this have to do with systemd.pc? It isn't used anywhere.
Right, I overlooked this which is indeed a problem.
Currently there's only a meson_option.txt you can set which means:
1. implement `pkg-config --variable=systemdsystemunitdir systemd`
in debian/rules and pass it in via the existing option.
2. implement checking systemdsystemunitdir from systemd.pc in meson
and have the build system do the right thing without any options.
I think 2 is better myself and I'm attaching a proof of concept
debdiff to implement it. (You might want to make a cleaner version.)
Regards,
Andreas Henriksson
diff -Nru mpd-0.23.12/debian/changelog mpd-0.23.12/debian/changelog
--- mpd-0.23.12/debian/changelog2023-01-21 21:32:37.0 +0100
+++ mpd-0.23.12/debian/changelog2023-04-11 17:30:42.0 +0200
@@ -1,3 +1,11 @@
+mpd (0.23.12-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add debian/patches/systemdsystemunitdir.patch
+ * Add systemd build-dep for systemd.pc
+
+ -- Andreas Henriksson Tue, 11 Apr 2023 17:30:42 +0200
+
mpd (0.23.12-1) unstable; urgency=medium
* New upstream version 0.23.12
diff -Nru mpd-0.23.12/debian/control mpd-0.23.12/debian/control
--- mpd-0.23.12/debian/control 2023-01-21 21:32:37.0 +0100
+++ mpd-0.23.12/debian/control 2023-04-11 17:30:42.0 +0200
@@ -55,6 +55,7 @@
libsoxr-dev,
libsqlite3-dev,
libsystemd-dev [linux-any],
+ systemd [linux-any],
libupnp-dev (>= 1.8~),
liburing-dev [linux-any],
libvorbis-dev [!armel],
diff -Nru mpd-0.23.12/debian/patches/series mpd-0.23.12/debian/patches/series
--- mpd-0.23.12/debian/patches/series 2021-11-11 15:58:40.0 +0100
+++ mpd-0.23.12/debian/patches/series 2023-04-11 17:25:58.0 +0200
@@ -1,3 +1,4 @@
# Debian-specific
systemd_honor_MPDCONF.patch
mpd.service.documentation.user.patch
+systemdsystemunitdir.patch
diff -Nru mpd-0.23.12/debian/patches/systemdsystemunitdir.patch
mpd-0.23.12/debian/patches/systemdsystemunitdir.patch
--- mpd-0.23.12/debian/patches/systemdsystemunitdir.patch 1970-01-01
01:00:00.0 +0100
+++ mpd-0.23.12/debian/patches/systemdsystemunitdir.patch 2023-04-11
17:30:33.0 +0200
@@ -0,0 +1,16 @@
+Index: mpd-0.23.12/systemd/system/meson.build
+===
+--- mpd-0.23.12.orig/systemd/system/meson.build
mpd-0.23.12/systemd/system/meson.build
+@@ -1,5 +1,11 @@
+ systemd_system_unit_dir = get_option('systemd_system_unit_dir')
+ if systemd_system_unit_dir == ''
++ systemd = dependency('systemd', required: false)
++ if systemd.found()
++ systemd_system_unit_dir =
systemd.get_pkgconfig_variable('systemdsystemunitdir')
++ endif
++endif
++if systemd_system_unit_dir == ''
+ systemd_system_unit_dir = join_paths(get_option('prefix'), 'lib',
'systemd', 'system')
+ endif
+
Bug#1034223: powerman: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hello Laurent Bigonville, On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: powerman > Version: 2.3.27-2 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package powerman is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. > > This is not supported by the version of dh_installsystemd/debhelper currently > in unstable and bookworm (See: #1031695). That means that currently your > service might not be enabled at boot and/or started as expected. [...] Note that debian/rules has: ``` override_dh_installinit: dh_installinit --no-start --no-enable override_dh_installsystemd: dh_installsystemd --no-start --no-enable ``` So do you agree that the severity of this bug report should be downgraded (maybe even closed)? Regards, Andreas Henriksson
Bug#1034226: cloudflare-ddns: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: cloudflare-ddns
> Version: 2.0.0-3
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package cloudflare-ddns is shipping files (.service,
> .socket or
> .timer) in /usr/lib/systemd/system.
[...]
The culprit seems to be hard-coded paths in the upstream build system
at:
https://sources.debian.org/src/cloudflare-ddns/2.0.0-3/exe/meson.build/#L70
Since I wasn't sure about how configure_file directive in meson works
and the documentation at
https://mesonbuild.com/Reference-manual_functions.html#configure_file
says install_dir takes a subdirectory I had to try it out.
The attached debdiff should solve the problem.
While at it I also adressed the hardcoded sysuser directory at:
https://sources.debian.org/src/cloudflare-ddns/2.0.0-3/exe/meson.build/#L90
See attached file which you might want to improve (for example you could
make systemd a build-option even on linux if you care).
Regards,
Andreas Henriksson
diff -Nru cloudflare-ddns-2.0.0/debian/changelog
cloudflare-ddns-2.0.0/debian/changelog
--- cloudflare-ddns-2.0.0/debian/changelog 2023-01-16 22:16:37.0
+0100
+++ cloudflare-ddns-2.0.0/debian/changelog 2023-04-11 16:17:38.0
+0200
@@ -1,3 +1,12 @@
+cloudflare-ddns (2.0.0-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * add debian/patches/systemdsystemunitdir.patch
+ * debian/cloudflare-ddns.install: install lib/systemd/system
+ * Add systemd build-dep, for systemd.pc
+
+ -- Andreas Henriksson Tue, 11 Apr 2023 16:17:38 +0200
+
cloudflare-ddns (2.0.0-3) unstable; urgency=medium
* d/.install: fix build on non-Linux with dh-exec
diff -Nru cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install
cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install
--- cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install2023-01-16
22:10:06.0 +0100
+++ cloudflare-ddns-2.0.0/debian/cloudflare-ddns.install2023-04-11
16:17:38.0 +0200
@@ -1,5 +1,5 @@
#!/usr/bin/dh-exec
-[linux-any] usr/lib/systemd/
+[linux-any] lib/systemd/system
[linux-any] usr/lib/sysusers.d/
etc/
usr/bin/
diff -Nru cloudflare-ddns-2.0.0/debian/control
cloudflare-ddns-2.0.0/debian/control
--- cloudflare-ddns-2.0.0/debian/control2023-01-16 22:10:06.0
+0100
+++ cloudflare-ddns-2.0.0/debian/control2023-04-11 16:17:38.0
+0200
@@ -11,6 +11,7 @@
libsimdjson-dev (>= 0.9.0),
meson (>= 0.53.0),
pkg-config,
+ systemd,
ronn
Standards-Version: 4.6.2
Homepage: https://github.com/Tachi107/cloudflare-ddns
diff -Nru cloudflare-ddns-2.0.0/debian/patches/series
cloudflare-ddns-2.0.0/debian/patches/series
--- cloudflare-ddns-2.0.0/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ cloudflare-ddns-2.0.0/debian/patches/series 2023-04-11 16:13:19.0
+0200
@@ -0,0 +1 @@
+systemdsystemunitdir.patch
diff -Nru cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
--- cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
1970-01-01 01:00:00.0 +0100
+++ cloudflare-ddns-2.0.0/debian/patches/systemdsystemunitdir.patch
2023-04-11 16:17:38.0 +0200
@@ -0,0 +1,37 @@
+Index: cloudflare-ddns-2.0.0/exe/meson.build
+===
+--- cloudflare-ddns-2.0.0.orig/exe/meson.build
cloudflare-ddns-2.0.0/exe/meson.build
+@@ -66,8 +66,10 @@ if ronn.found()
+ )
+ endif
+
+-if host_machine.system() == 'linux'
+- systemddir = 'lib'/'systemd'/'system'
++systemd = dependency('systemd', required: host_machine.system() == 'linux')
++if systemd.found()
++ systemdsystemunitdir =
systemd.get_pkgconfig_variable('systemdsystemunitdir')
++systemdsysusersdir = systemd.get_pkgconfig_variable('sysusersdir')
+
+ configure_file(
+ input: 'systemd'/'cloudflare-ddns.service.in',
+@@ -77,16 +79,16 @@ if host_machine.system() == 'linux'
+ 'libdir': get_option('prefix')/get_option('libdir')
+ },
+ install: true,
+- install_dir: systemddir
++ install_dir: systemdsystemunitdir
+ )
+
+ install_data(
+ 'systemd'/'cloudflare-ddns.timer',
+- install_dir: systemddir
++ install_dir: systemdsystemunitdir
+ )
+
+ install_data(
+ 'sysusers.d'/'cloudflare-ddns.conf',
+- install_dir: 'lib'/'sysusers.d'
++ install_dir: systemdsysusersdir
+ )
+ endif
Bug#1034228: zcfan: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: zcfan > Version: 1.2.1-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package zcfan is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be the wrong path hardcoded at: https://sources.debian.org/src/zcfan/1.2.1-1/Makefile/#L44 Preferably you would find out this path by querying systemd.pc for it, ie. pkg-config --variable=systemdsystemunitdir systemd (Note: You'll also need to build-dep on pkg-config and systemd, for systemd.pc) Regards, Andreas Henriksson
Bug#1034221: caddy: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: caddy > Version: 2.6.2-4 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package caddy is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be wrong path at: https://sources.debian.org/src/caddy/2.6.2-4/debian/caddy.install/#L2-L3 Please note that if you change it to /lib/systemd/system now, you'll likely need to reverse that change again in the future. Preferably the correct path is derived from the value given by pkg-config --variable=systemdsystemunitdir systemd You could use this via making your debian/caddy.install executable and integrating dh-exec. You'll have to decide if you think it's worth it or not. Regards, Andreas Henriksson
Bug#1034229: wsdd2: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: wsdd2 > Version: 1.8.7+dfsg-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package wsdd2 is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be the hard-coded path at: https://sources.debian.org/src/wsdd2/1.8.7%2Bdfsg-1/Makefile/#L31 As this path will change again in the future, please consider finding out the path from the proper source via: pkg-config --variable=systemdsystemunitdir systemd (Note: you'll need to build-dep on pkg-config and systemd, for systemd.pc) Regards, Andreas Henriksson
Bug#1034230: fail2ban: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: fail2ban > Version: 1.0.2-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package fail2ban is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] Wrong path is used at: https://sources.debian.org/src/fail2ban/1.0.2-1/debian/rules/#L50 Note that the path will likely change again in the future, so rather than hard-coding a path please consider finding the path via: pkg-config --variable=systemdsystemunitdir systemd (Note: you'll need to build-dep on pkg-config and systemd, for systemd.pc) Regards, Andreas Henriksson
Bug#1034232: nvme-cli: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: nvme-cli > Version: 2.3-2 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package nvme-cli is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be here: https://sources.debian.org/src/nvme-cli/2.4%2Breally2.3-2/meson.build/#L27 (making the systemddir build option unusable.) The proper solution would involve pkg-config and systemd.pc which should be queried for the systemdsystemunitdir variable. (Note: do not forget to build-dep on pkg-config and systemd.) This should give you a bunch of packages to choose from as examples of how to implement that using meson: https://codesearch.debian.net/search?q=get_option.*systemdsystemunitdir=0=1 Regards, Andreas Henriksson
Bug#1034233: tlp: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: tlp > Version: 1.5.0-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package tlp is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The problem seems to originate from: https://sources.debian.org/src/tlp/1.5.0-1/debian/rules/#L9 The upstream default value is actually correct for Debian (at the moment): https://sources.debian.org/src/tlp/1.5.0-1/Makefile/#L17 However, this will change in the future... so I think a better solution would be to actually retrieve the value from systemd.pc. You should be able to do this by: * build-dep on pkg-config and systemd (for systemd.pc) * Modify debian/rules `export TLP_SYSD=/usr/lib/systemd/system` to: export TLP_SYSD=$(shell pkg-config --variable=systemdsystemunitdir systemd) * Update https://sources.debian.org/src/tlp/1.5.0-1/debian/tlp.install/#L5 Regards, Andreas Henriksson
Bug#1034234: libpam-modules-bin: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: libpam-modules-bin > Version: 1.5.2-6 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package libpam-modules-bin is shipping files (.service, > .socket or > .timer) in /usr/lib/systemd/system. [...] wrong variable name (systemdsystemunitdir): https://sources.debian.org/src/pam/1.5.2-6/configure.ac/?hl=646#L646 overridden by wrong path: https://sources.debian.org/src/pam/1.5.2-6/debian/rules/#L33 Regards, Andreas Henriksson
Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: mpd > Version: 0.23.12-1 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package mpd is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be that mpd falls back on hard-coded path (instead of failing) when systemd.pc is not found! https://sources.debian.org/src/mpd/0.23.12-1/systemd/system/meson.build/#L1-L4 Fixing the problem should be as easy as adding a build-dep on the package that contains systemd.pc (systemd). Regards, Andreas Henriksson
Bug#1034237: gammu-smsd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > Package: gammu-smsd > Version: 1.42.0-7 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package gammu-smsd is shipping files (.service, .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be here: https://sources.debian.org/src/gammu/1.42.0-7/debian/rules/#L32 ``` -DSYSTEMD_SERVICES_INSTALL_DIR=/usr/lib/systemd/system \ ``` By removing this line you'll let cmake auto-detect the correct path via ./cmake/FindSystemD.cmake which uses pkg-config. Make sure you also build-dep on the package containing systemd.pc (you already seem to have pkg-config itself in build-deps). Also note that you need to adjust: https://sources.debian.org/src/gammu/1.42.0-7/debian/gammu-smsd.install/#L5 Regards, Andreas Henriksson
Bug#1034240: pass-extension-tomb: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 10:00:16AM +0200, bi...@debian.org wrote: > Package: pass-extension-tomb > Version: 1.3-2 > Severity: serious > Tags: sid bookworm > User: debhel...@packages.debian.org > Usertags: systemd-files-in-usr-bookworm > > Dear Maintainer, > > It seems that your package pass-extension-tomb is shipping files (.service, > .socket or > .timer) in /usr/lib/systemd/system. [...] The culprit seems to be here: https://sources.debian.org/src/pass-tomb/1.3-2/Makefile/#L21 (and also line 36) ``` @install -Dm0644 pass-close@.service "$(DESTDIR)$(LIBDIR)/systemd/system/pass-close@.service" ``` To get the correct path you could use: ``` pkg-config --variable=systemdsystemunitdir systemd ``` (Note: do not forget to also build-dep on the package containing systemd.pc as well as pkg-config itself.) Regards, Andreas Henriksson
Bug#1034238: fapolicyd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 02:23:32PM +0200, Andreas Henriksson wrote:
> On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> > Package: fapolicyd
> > Version: 1.1.7-3
> > Severity: serious
> > Tags: sid bookworm
> > User: debhel...@packages.debian.org
> > Usertags: systemd-files-in-usr-bookworm
> >
> > Dear Maintainer,
> >
> > It seems that your package fapolicyd is shipping files (.service, .socket or
> > .timer) in /usr/lib/systemd/system.
> [...]
>
> The problem seems to come from the more or less hardcoded path in
> configure.at at:
> https://sources.debian.org/src/fapolicyd/1.1.7-3/configure.ac/#L74
>
> ```
> dnl FIXME some day pass this on the command line
> def_systemdsystemunitdir=${prefix}/lib/systemd/system
> AC_SUBST([systemdsystemunitdir], [$def_systemdsystemunitdir])
> ```
>
> For example how to use value from systemd.pc, see a random example:
> https://sources.debian.org/src/pam/1.5.2-6/configure.ac/?hl=646#L641-L649
> (Note: you'll also need a build-dep on package containing systemd.pc)
Actually this example might be broken ... should probably use
variable=systemdsystemunitdir rather than variable=systemdunitdir
>
> Regards,
> Andreas Henriksson
Bug#1034238: fapolicyd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> Package: fapolicyd
> Version: 1.1.7-3
> Severity: serious
> Tags: sid bookworm
> User: debhel...@packages.debian.org
> Usertags: systemd-files-in-usr-bookworm
>
> Dear Maintainer,
>
> It seems that your package fapolicyd is shipping files (.service, .socket or
> .timer) in /usr/lib/systemd/system.
[...]
The problem seems to come from the more or less hardcoded path in
configure.at at:
https://sources.debian.org/src/fapolicyd/1.1.7-3/configure.ac/#L74
```
dnl FIXME some day pass this on the command line
def_systemdsystemunitdir=${prefix}/lib/systemd/system
AC_SUBST([systemdsystemunitdir], [$def_systemdsystemunitdir])
```
For example how to use value from systemd.pc, see a random example:
https://sources.debian.org/src/pam/1.5.2-6/configure.ac/?hl=646#L641-L649
(Note: you'll also need a build-dep on package containing systemd.pc)
Regards,
Andreas Henriksson
Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1
Hello, On Thu, Apr 06, 2023 at 05:52:32PM +0100, Christopher Obbard wrote: > Hi Andreas, > > On Thu, 2023-04-06 at 18:45 +0200, Andreas Henriksson wrote: [...] > > IMHO it feels much safer to just go with a targeted upload [...] > > Let's go with your NMU, since you've done all of the work already, then I > will upload the new version into unstable once development opens. > > How does that sound? > > PS: Can you push your source to salsa? Pushed to salsa (incl. tag)! dput new version, so should hopefully he accepted for unstable soon! Thanks for the quick followup! Regards, Andreas Henriksson
Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1
Hello Chris, On Thu, Apr 06, 2023 at 04:37:30PM +0100, Christopher Obbard wrote: > Hi Andreas, > > As the upstream maintainer, I can just tag a new version upstream as 1.1.2 & > pick that in Debian. > Then I hope it can flow into bookworm? I wonder if the release team will accept a new upstream release at this point in the freeze We're pretty deep into the hard freeze at this point (but I don't have enough insight into how the release team works these days, it seems much more relaxed than in the old times where I was more involved and basically any extra character would get you a NACK, specially an "unneccessary" upstream version number change). Do you have time to do all the work and still accept a potential NO from the release team? Please be honest to yourself. IMHO it feels much safer to just go with a targeted upload (which is now also already approved), but if you feel strongly about it and also think you have time to pursue a new release then just send me a NACK on the NMU (ASAP! I'm ready to upload *now*) and I will not pursue it. > > The past few months have been... quite crazy in my personal life so I > haven't gotten around to doing this as yet. Huge apologies for that, > it is on my radar this week. > > Hope that is acceptable to you? No need to apologize. We're all busy sometimes and that's why we have NMUs so we can help each other out. (I've also been quite busy or the NMU would have happened much sooner in the release cycle.) Thanks for all the work you have had time to do! > > Thanks, > > Chris Regards, Andreas Henriksson PS. Feel free to ignore my NMU and just upload the new upstream release once we're past the freeze/release and the development opens up again.
Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: de...@packages.debian.org
Control: affects -1 + src:debos
Hello release-team,
I'm looking for a pre-approval for an unblock of my NMU of debos,
which contains 3 commits cherry-picked from upstream.
The main bug to fix is https://bugs.debian.org/1027787
The current version of debos in bookworm is not compatible with
bookworm. The maintainer promised me to deal with this if I
submitted an upstream PR where he merged my patch for it,
but apparently never found the time to update the debian
package.
While at it I also cherry-picked 2 documentation fixes.
I'm attaching a debdiff, but if you'd like to avoid reading
patch-in-patch these are the commits:
https://github.com/go-debos/debos/commit/18998ffaf78321e111d9823b3180eca3fa4593f6
https://github.com/go-debos/debos/commit/f4ff78305513a90eca089e33f7bba35bffa96bd1
https://github.com/go-debos/debos/commit/c8c5075853aab9e1ac6ae07a3a7c2b070aa38a62
unblock debos/1.1.1-2.1
diff -Nru debos-1.1.1/debian/changelog debos-1.1.1/debian/changelog
--- debos-1.1.1/debian/changelog2022-10-31 11:16:08.0 +0100
+++ debos-1.1.1/debian/changelog2023-03-16 10:09:37.0 +0100
@@ -1,3 +1,13 @@
+debos (1.1.1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Cherry-pick upstream commit that unbreaks bookworm (Closes: #1027787)
+ * Cherry-pick upstream doc fix for non-free-firmware
+ * Cherry-pick upstream example fix for interactive password prompt
+(Closes: #1006823)
+
+ -- Andreas Henriksson Thu, 16 Mar 2023 10:09:37 +0100
+
debos (1.1.1-2) unstable; urgency=medium
* Run autopkgtest in an isolated virtual machine
diff -Nru debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
--- debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
1970-01-01 01:00:00.0 +0100
+++ debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
2023-03-16 10:09:37.0 +0100
@@ -0,0 +1,65 @@
+From: Andreas Henriksson
+Date: Tue, 3 Jan 2023 01:12:42 +0100
+Subject: Limit old suite workaround
+
+The workaround for https://github.com/go-debos/debos/issues/361
+that was applied in
https://github.com/go-debos/debos/commit/b3c1f76bcc1dbd55fef584b8ddbda33f12733116
+breaks recipes for bookworm and newer.
+
+Signed-off-by: Andreas Henriksson
+(cherry picked from commit 18998ffaf78321e111d9823b3180eca3fa4593f6)
+---
+ actions/debootstrap_action.go | 26 +-
+ 1 file changed, 25 insertions(+), 1 deletion(-)
+
+diff --git a/actions/debootstrap_action.go b/actions/debootstrap_action.go
+index e354ff4..e7c2587 100644
+--- a/actions/debootstrap_action.go
b/actions/debootstrap_action.go
+@@ -53,6 +53,7 @@ package actions
+ import (
+ "fmt"
+ "io"
++ "log"
+ "os"
+ "path"
+ "strings"
+@@ -158,6 +159,24 @@ func (d *DebootstrapAction) RunSecondStage(context
debos.DebosContext) error {
+ return err
+ }
+
++// Guess if suite is something before usr-is-merged was introduced
++func (d *DebootstrapAction) isLikelyOldSuite() bool {
++ switch strings.ToLower(d.Suite) {
++ case "sid", "unstable":
++ return false
++ case "testing":
++ return false
++ case "bookworm":
++ return false
++ case "trixie":
++ return false
++ case "forky":
++ return false
++ default:
++ return true
++ }
++}
++
+ func (d *DebootstrapAction) Run(context *debos.DebosContext) error {
+ d.LogStart()
+ cmdline := []string{"debootstrap"}
+@@ -204,7 +223,12 @@ func (d *DebootstrapAction) Run(context
*debos.DebosContext) error {
+ cmdline = append(cmdline, fmt.Sprintf("--variant=%s",
d.Variant))
+ }
+
+- cmdline = append(cmdline, "--exclude=usr-is-merged")
++ // workaround for https://github.com/go-debos/debos/issues/361
++ if d.isLikelyOldSuite() {
++ log.Println("excluding usr-is-merged as package is not in
suite")
++ cmdline = append(cmdline, "--exclude=usr-is-merged")
++ }
++
+ cmdline = append(cmdline, d.Suite)
+ cmdline = append(cmdline, context.Rootdir)
+ cmdline = append(cmdline, d.Mirror)
diff -Nru
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
---
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
1970-01-01 01:00:00.0 +0100
+++
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.
Bug#1031640: e2fsprogs generates filesystems which cannot be mounted on systems with older e2fsprogs
Control: forwarded -1 https://github.com/go-debos/debos/issues/78 Seems like the bookworm / metadata_csum_seed problem has happened in the past for a different e2fsprogs feature and is discussed in the above upstream github issue, so I'm marking this as forwarded to have the two issues linked. Regards, Andreas Henriksson
Bug#1032882: [Debian-on-mobile-maintainers] Bug#1032882: Bug#1032882: uuu: New upstream release available
Hello Guido, On Mon, Mar 13, 2023 at 02:20:45PM +0100, Guido Günther wrote: > Hi Andreas, > [..snip..] > > I've forked and updated the packaging at: > > https://salsa.debian.org/ah/mfgtools > > > > The relevant commit (apart from `gbp import-orig --uscan`) is > > https://salsa.debian.org/ah/mfgtools/-/commit/a7a75a60f5e0e923ef1deb1b08469d0a9553a8ed > > (and then updating debian/changelog ofcourse). > > > > It build, installs and runs basic commands fine, but I haven to yet > > tested it against an actual imx target. > > Testing on an imx target would be good before upload ;) I'll be testing tomorrow when I'm at the board I'm working on. Since this is only experimental I might be my usual trigger-happy self and upload in advance. > > > If there's a lack of people interested in maintaing uuu/mfgtools I'd be > > willing to help out. I don't have any particular interest in the Debian > > on Mobile effort (right now), apart from uuu/mfgtools, though. > > Would you be willing to give me access or consider if maybe it's > > better if mfgtools repo live under the "debian" group on salsa? > > I've added you as maintainer to the uuu repo so we keep things > together. As Henry is the maintainer I'd rather not move repos around if > not absolutely needed. O.k.? Thanks. > > > I don't like leaving git repos out of sync, so if I'm given commit > > access I'd also be willing to upload to experimental. > > I could even consider adding myself to Uploaders as I am a semi-regular > > user of uuu and would like to see it be kept up to date. > > Sure, go ahead. Thanks, I've added myself. > > > Please advice on what you think is appropriate. > > (I'm @ah on salsa). > > > > Regards, > > Andreas Henriksson > > > > PS. my personal preference is to include full upstream commit history in > > the upstream branch, if you're also open to making that change in the > > repo please tell me. > > We usually use `gbp import-orig --upstream-vcs-tag=` within DebianMobile > so if that's what you're referring to, that would be a desirable change. Exactly, added and reimported from upstream. Now tagged and pushed. Pending upload. > > Cheers, > -- Guido Regards, Andreas Henriksson
Bug#1032882: [Debian-on-mobile-maintainers] Bug#1032882: uuu: New upstream release available
Hello Guido, Thanks for your quick reply. More below. On Mon, Mar 13, 2023 at 11:50:50AM +0100, Guido Günther wrote: > Hi, > On Mon, Mar 13, 2023 at 11:38:03AM +0100, Andreas Henriksson wrote: > > Package: uuu > > Version: 1.4.193-1 > > Severity: wishlist > > > > Dear Maintainer, > > > > As currently reported on https://tracker.debian.org/pkg/mfgtools > > the latest packaged version of uuu is 1.4.193-1 while as reported > > on the same page the latest upstream version is 1.5.21. [...] > I think Henry isn't very active atm so an upload to experimental would > be fine. I've forked and updated the packaging at: https://salsa.debian.org/ah/mfgtools The relevant commit (apart from `gbp import-orig --uscan`) is https://salsa.debian.org/ah/mfgtools/-/commit/a7a75a60f5e0e923ef1deb1b08469d0a9553a8ed (and then updating debian/changelog ofcourse). It build, installs and runs basic commands fine, but I haven to yet tested it against an actual imx target. If there's a lack of people interested in maintaing uuu/mfgtools I'd be willing to help out. I don't have any particular interest in the Debian on Mobile effort (right now), apart from uuu/mfgtools, though. Would you be willing to give me access or consider if maybe it's better if mfgtools repo live under the "debian" group on salsa? I don't like leaving git repos out of sync, so if I'm given commit access I'd also be willing to upload to experimental. I could even consider adding myself to Uploaders as I am a semi-regular user of uuu and would like to see it be kept up to date. Please advice on what you think is appropriate. (I'm @ah on salsa). Regards, Andreas Henriksson PS. my personal preference is to include full upstream commit history in the upstream branch, if you're also open to making that change in the repo please tell me.
Bug#1032882: uuu: New upstream release available
Package: uuu Version: 1.4.193-1 Severity: wishlist Dear Maintainer, As currently reported on https://tracker.debian.org/pkg/mfgtools the latest packaged version of uuu is 1.4.193-1 while as reported on the same page the latest upstream version is 1.5.21. I'm opening this bug report to discuss around updating the uuu packaging. Are there any known blockers? Lack of volunteers? etc. (As we're currently in freeze for bookworm it might be best to just prepare updates targeting experimental for now. I do volunteer to look into it if the problem is lack of volunteers, but if you do have known issues or blockers then please share!) Regards, Andreas Henriksson -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.2.0-rc3-asahi (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages uuu depends on: ii libbz2-1.01.0.8-5+b1 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libssl3 3.0.8-1 ii libstdc++612.2.0-14 ii libusb-1.0-0 2:1.0.26-1 ii zlib1g1:1.2.13.dfsg-1 uuu recommends no packages. uuu suggests no packages. -- no debconf information
Bug#1031572: librt-extension-commandbymail-perl: Please add a Homepage field in debian/control
Hello Adrian Bunk, On Sat, Feb 18, 2023 at 10:58:33PM +0200, Adrian Bunk wrote: > Source: librt-extension-commandbymail-perl > Version: 3.00-1.1 > Severity: serious > > Homepage: https://metacpan.org/pod/RT::Extension::CommandByMail > would be an option. Could you please provide some additional information here that I'm obviously failing to understand. The Homepage field is an optional field: https://www.debian.org/doc/debian-policy/ch-controlfields.html#binary-package-control-files-debian-control I personally often leave it out even when a homepage exists but contains very little useful information (probably all already available in the package itself). If this is even a bug then it would be at most Severity: wishlist as I see it. What am I missing here that makes Homepage so important for this package to warrant a release-critical severity? Regards, Andreas Henriksson
Bug#1031436: ubuntu-dev-tools: FTBFS: make[1]: *** [debian/rules:10: override_dh_auto_test] Error 1
Control: retitle -1 ubuntu-dev-tools: FTBFS because of ./run-linters during build Hello, On Fri, Feb 17, 2023 at 07:55:22AM +0100, Lucas Nussbaum wrote: > Source: ubuntu-dev-tools > Version: 0.192 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > ./run-linters [...] Running linters during build seems like an equally bad idea as using -Werror in release builds! When ever a linter changes opinion of something the package will start to FTBFS (just like when gcc gains a new warning and code with -Werror starts to FTBFS). I hope removing `./run-linters` from debian/rules is a simple fix for this issue (and future ones). Run the linters *before* release, not on every (re)build after release. (Or possibly catch this via an autopkgtest that would trigger when a new version of a dependency is uploaded. But I don't think linter package maintainers would appreciate you blocking their package from testing migration until you've uploaded a relinted version of your package.) Regards, Andreas Henriksson
Bug#1031473: freebayes: FTBFS: Variant.h:36:10: fatal error: wavefront/wfa.hpp: No such file or directory
Control: reassign -1 libvcflib-dev 1.0.7+dfsg-1 Control: retitle -1 libvcflib-dev lacks dependency on libwfa2-dev Control: affects -1 freebayes Hello, On Fri, Feb 17, 2023 at 08:01:41AM +0100, Lucas Nussbaum wrote: > Source: freebayes > Version: 1.3.6-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > c++ -Ilibfreebayes_common.a.p -I. -I.. -I../src -I../ttmath > > -I/usr/include/vcflib -I/usr/include/smithwaterman -I/usr/include/fastahack > > -I/usr/include/SeqLib -I/usr/include/jsoncpp -fdiagnostics-color=always > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread > > -fpermissive -Wno-reorder -Wno-sign-compare -Wno-unused-variable > > -Wno-unused-but-set-variable -MD -MQ > > libfreebayes_common.a.p/src_DataLikelihood.cpp.o -MF > > libfreebayes_common.a.p/src_DataLikelihood.cpp.o.d -o > > libfreebayes_common.a.p/src_DataLikelihood.cpp.o -c > > ../src/DataLikelihood.cpp > > In file included from ../src/AlleleParser.h:32, > > from ../src/DataLikelihood.h:20, > > from ../src/DataLikelihood.cpp:1: > > /usr/include/vcflib/Variant.h:36:10: fatal error: wavefront/wfa.hpp: No > > such file or directory > >36 | #include "wavefront/wfa.hpp" > > | ^~~ > > compilation terminated. [...] Note than it's not freebayes that includes "wavefront/wfa.hpp", but vcflib. Given that vcflib has had a recent new upload to unstable that makes me think this is actually a problem in vcflib. The new vcflib version has not yet migrated to testing, so reassigning this to add a(n additional) blocker for that to happen and prevent the problem from affecting testing. I notiled that libvcflib-dev does *not* have a dependency on libwfa2-dev (which has wavefront/wfa.hpp). Maybe this is the bug itself. There could possibly be additional problems like cflags (and libs) not propagating properly up the chain. There seems to be no .pc (pkgconfig) file included in libwfa2-dev. Not sure how the needed "-I/usr/include/wfa2lib/" are supposed to be propagated up, but lets first fix the dependency issue and then I'll leave potential additional problems as an excercise for the maintainer(s) to figure out while testing their new package. Please consider adding a simple compile test as an autopkgtest, which would help you catch missing dependencies in the -dev packages. For example see: https://sources.debian.org/src/util-linux/2.38.1-5/debian/tests/libmount-dev/ Regards, Andreas Henriksson
Bug#1031453: sane-frontends: FTBFS: dh_install: error: missing files, aborting
Control: retitle -1 sane-frontends: FTBFS: Couldn't find SANE libraries (sane-backends) Hello, This seems to be a regression caused by the newly uploaded sane-backends. Maybe that should get an RC bug to prevent it from going into testing! Would probably make sense to atleast add a Breaks: sane-fronteds (<< fixed-version) to the new version of sane-backends. Anyway, more about sane-frontends FTBFS below. On Fri, Feb 17, 2023 at 08:04:01AM +0100, Lucas Nussbaum wrote: > Source: sane-frontends > Version: 1.0.14-16 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm [...] > > checking for sane-backends >= 1.0.0... yes > > ** > > ERROR: Couldn't find SANE libraries (sane-backends). Possible reasons: > > - sane-backends isn't installed (install sane-backends before > >sane-frontends) > > - the SANE header files aren't installed (if you installed > >SANE as RPM make sure you also included the sane-devel RPM) > > - the SANE libraries can't be found because /usr/local/lib/ isn't > >searched by the dynamic linker (see INSTALL for details) > > ** ^^ this is the actual error. Unfontunately when this occurs the configure script exits with code 0. https://sources.debian.org/src/sane-frontends/1.0.14-16/configure.in/#L131 It would be much better if it exited with an error code (and printed the error messages to stderr instead of stdout while at it). Then we wouldn't have to proceed to end up with this: > > > >create-stamp debian/debhelper-build-stamp > >dh_prep > >dh_installdirs > >dh_auto_install --destdir=debian/sane/ > >dh_install > > dh_install: warning: Cannot find (any matches for) > > "debian/sane/usr/bin/xscanimage" (tried in ., debian/tmp) [...] The fix would probably be to replace ldflags with libs here (and bump version of libsane-dev build-dep as this would not work with older versions than the one currently in unstable): https://sources.debian.org/src/sane-frontends/1.0.14-16/configure.in/#L117 The sane-backends.pc from unstable (1.2.1-1) has: # grep -e ldflags= -e libs= /usr/lib/x86_64-linux-gnu/pkgconfig/sane-backends.pc libs= -ldl -lm -ltiff -ljpeg -lgphoto2 -lgphoto2_port -lm -lavahi-common -lavahi-client -lusb-1.0 While the sane-backends.pc currently in testing (1.1.1-6) has: # grep -e ldflags= -e libs= usr/lib/x86_64-linux-gnu/pkgconfig/sane-backends.pc ldflags=-Wl,-z,relro -Wl,-z,now libs= Regards, Andreas Henriksson
Bug#1031448: fwupd: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/./obj-x86_64-linux-gnu/meson-private/tmp7p7957mh/testfile.c:17: undefined reference to `gcab_cabinet_add_allowed_compression
Control: reassign -1 libflashrom-dev 1.3.0-2 Control: affects -1 fwupd Control: retitle -1 libfrashrom-dev missing dependency on pkg-config required libraries On Fri, Feb 17, 2023 at 06:34:17AM +0100, Lucas Nussbaum wrote: > Source: fwupd > Version: 1.8.10-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230216 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): [...] I believe this is the actual relevant part: Called `/usr/bin/pkg-config --cflags flashrom` -> 1 pkg-config error with 'flashrom': Could not generate cargs for flashrom: Package libjaylink was not found in the pkg-config search path. Perhaps you should add the directory containing `libjaylink.pc' to the PKG_CONFIG_PATH environment variable Package 'libjaylink', required by 'flashrom', not found > The full build log is available from: > http://qa-logs.debian.net/2023/02/16/fwupd_1.8.10-2_unstable.log [...] grep Requires usr/lib/*-linux-gnu/pkgconfig/flashrom.pc Requires.private: libpci, libusb-1.0, libftdi1, libjaylink The packages containing these .pc needs to be listed in Depends of libflashrom-dev. I'd suggest adding a trivial compile test as an autopkgtest using pkgconfig which I find is the easiest way to spot if the -dev package is missing dependencies listed in the pkg-config file. For example see: https://sources.debian.org/src/util-linux/2.38.1-5/debian/tests/libmount-dev/ Regards, Andreas Henriksson
Bug#1029944: neon27 FTBFS on IPV6-only buildds
Hello again,
On Sat, Feb 11, 2023 at 06:55:13PM +0100, Andreas Henriksson wrote:
> On Sun, Jan 29, 2023 at 02:29:23PM +0100, László Böszörményi (GCS) wrote:
> > Control: tags -1 +confirmed
> >
> > On Sun, Jan 29, 2023 at 12:33 PM Adrian Bunk wrote:
> > > https://buildd.debian.org/status/logs.php?pkg=neon27=amd64
> > >
> > > ...
> > > auth.. 3/20 FAIL - retries (line 311: HTTP error:
> > > Could not resolve hostname `127.0.0.1': Address family for hostname not
> > > supported)
> > Is there a way to detect such buildds as a maintainer? What can I do
> > except notifying upstream and / or disable such tests?
If replacing "127.0.0.1" with "localhost" does not work the attached
(completely untested) patch might be an option instead (simply skip the
test on EAFNOSUPPORT).
(Sorry if the patch is completely broken, but I hope you get the
idea...)
Regards,
Andreas Henriksson
--- test/utils.h.orig 2023-02-11 19:38:52.122713689 +0100
+++ test/utils.h 2023-02-11 19:40:25.601514834 +0100
@@ -25,7 +25,7 @@
#include "child.h"
-#define ONREQ(x) do { int _ret = (x); if (_ret) { t_context("line %d: HTTP error:\n%s", __LINE__, ne_get_error(sess)); return FAIL; } } while (0);
+#define ONREQ(x) do { int _ret = (x); if (_ret) { t_context("line %d: HTTP error:\n%s", __LINE__, ne_get_error(sess)); if (strcmp(ne_get_error(sess), "Could not resolve hostname `127.0.0.1': Address family for hostname not supported") == 0) { return SKIP; } else { return FAIL; } } } while (0);
int single_serve_string(ne_socket *s, void *userdata);
Bug#1030175: libgetdata: FTBFS: dh_install: error: missing files, aborting
On Sun, Feb 05, 2023 at 02:52:49PM +0100, s3v wrote: > Dear Maintainer, > > > dh_install: warning: Cannot find (any matches for) > > "usr/local/lib/python3.10/dist-packages/*" (tried in ., debian/tmp) > > > > dh_install: warning: python3-pygetdata missing files: > > usr/local/lib/python3.10/dist-packages/* > > dh_install: error: missing files, aborting > > make: *** [debian/rules:28: binary-arch] Error 25 > > this is caused by a reference to python 3.10 in this file [1] > > Kind Regards > > [1] > https://sources.debian.org/src/libgetdata/0.11.0-5/debian/python3-pygetdata.install/ I think this is only half the truth. The file explicitly list both 3.10 and 3.11. The second half is that python3-all-dev no longer brings in both 3.10 and 3.11 since (see last bullet): python3-defaults (3.11.1-2) unstable; urgency=medium * Provide python3-supported-min and python3-supported-max versioned virtual packages, to allow modules to easily declare dependencies for all supported versions. * Bump Depends to 3.11.1-1. * Drop support for Python 3.10. -- Stefano Rivera Sat, 28 Jan 2023 09:46:57 -0400 It would however probably be a good idea if libgetdata / python3-pygetdata.install did not hardcode which python versions it expects python3-all-dev to bring in at all?! Is there any specific reason why it explicitly lists both the 3.10 and 3.11 paths rather than just use a wildcard in the path? If it's only to move files from /usr/local/lib to /usr/lib then maybe that would be better to do in debian/rules exectute_after_dh_auto_install target?! (Unless there's a better way to get the upstream install to use prefix /usr instead of /usr/local ofcourse) Oh well... now that I've written all this I see there's already: https://salsa.debian.org/science-team/libgetdata/-/commit/f698db0b309351d8dc66fad194f9462fb5c531ea Might still be worth considering not hardcoding any versions as discussed above though (to avoid repeating this problem once python 3.11 goes out of fashion)... Regards, Andreas Henriksson
Bug#1030186: enigmail: FTBFS (Error: Cannot find module 'chalk')
On Wed, Feb 01, 2023 at 12:32:44AM +0100, Santiago Vila wrote: > Package: src:enigmail > Version: 2:2.2.4-0.3 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I've just noticed that enigmail currently fails to build in bookworm: > > make[1]: Leaving directory '/<>' >dh_auto_test -i > make -j1 test "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 > make[1]: Entering directory '/<>' > static_analysis/eslint package > There was a problem loading formatter: > /usr/share/nodejs/eslint/lib/cli-engine/formatters/stylish > Error: Cannot find module 'chalk' [...] /usr/share/nodejs/eslint/lib/cli-engine/formatters/stylish is part of eslint package. The eslint package (build-depends and) *recommends* node-chalk. This changelog entry seems relevant: eslint (1.3.1~dfsg-3) experimental; urgency=medium * Fix install executable. * Add patch cherry-picked upstream to lazy-load rules. Relax to recommend (not depend on) node-chalk node-inquirer node-strip-ansi node-text-table. Fix explicitly depend on node-escape-string-regexp (previously pulled in by node-chalk). -- Jonas Smedegaard Sat, 12 Oct 2019 15:19:55 +0200 I'm not able to determine if either enigmail should dep on node-chalk itself because it uses supposedly optional components of eslint or if there's a mistake in eslint which should have node-chalk as a depends rather than recommends Hope someone else can figure this out. Regards, Andreas Henriksson
Bug#1029944: neon27 FTBFS on IPV6-only buildds
On Sun, Jan 29, 2023 at 02:29:23PM +0100, László Böszörményi (GCS) wrote: > Control: tags -1 +confirmed > > On Sun, Jan 29, 2023 at 12:33 PM Adrian Bunk wrote: > > https://buildd.debian.org/status/logs.php?pkg=neon27=amd64 > > > > ... > > auth.. 3/20 FAIL - retries (line 311: HTTP error: > > Could not resolve hostname `127.0.0.1': Address family for hostname not > > supported) > Is there a way to detect such buildds as a maintainer? What can I do > except notifying upstream and / or disable such tests? FWIW "127.0.0.1" is hardcoded here: https://sources.debian.org/src/neon27/0.32.5-1/test/utils.c/#L207 Possibly that could be replaced with "localhost" instead, but I'm not sure if using 127.0.0.1 is an attempt at hiding that the code is ipv4-only rather than protocol independent (maybe)... I tried quickly looking at upstream git history if it could confirm my suspicion, but the closest I could find was: https://github.com/notroj/neon/commit/eff6521be537c74511593743bf8665d898e26567 Seems like localhost -> 127.0.0.1 switch was intentional (and done during SVN days?). Maybe someone digging deeper can find "r1910". Regards, Andreas Henriksson
Bug#1030587: strace FTBFS on hppa
Hello Helge Deller, On Sun, Feb 05, 2023 at 12:54:07PM +0100, Helge Deller wrote: > Package: strace > Tags: patch, ftbfs, hppa > Version: 6.1-0.1 > > strace FTBFS on hppa. I just sent a few patches upstream to fix this, > which have been accepted: > https://lists.strace.io/pipermail/strace-devel/2023-January/011135.html > can you please include them, or simply update to latest git head? Thanks for fixing this and getting it merged upstream! Could you please have a look at https://salsa.debian.org/debian/strace/-/commits/wip/hppa and see if it builds (and if you think I cherry-picked the right set of patches)? (I took everything in recent history with your name on it.) BTW, Any chance I could convince you to also look at (mips*) https://github.com/strace/strace/issues/235 ? Regards, Andreas Henriksson
Bug#916596: iptables.postinst failure on link creation
Control: tags -1 + moreinfo On Sun, Feb 05, 2023 at 12:08:32PM +0200, Adrian Bunk wrote: > Control: tags -1 - moreinfo > Control: severity -1 serious > > On Fri, Dec 28, 2018 at 02:59:26PM +0100, Arturo Borrero Gonzalez wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Control: tag -1 moreinfo > > > > On Sun, 16 Dec 2018 13:14:19 +0100 Olivier wrote: > > > Package: iptables Version: 1.8.2-2+b1 Severity: important > > > > > > Dear Maintainer, > > > > > > Issue occure during iptables:i386 1.8.2-2 -> 1.8.2-2+b1 upgrade. > > > > > > /var/lib/dpkg/info/iptables.postinst fail with message: > > > > > > ln: failed to create symbolic link ''$'\t'' > > > /sbin/iptables-save': No such file or directory > > > > > > > I can't reproduce the issue: > >... > > I didn't try in i386 because I don't have any machine (virtual or > > physical) with that arch, maybe is a architecture specific bug in the > > shell? Hard to believe to say the least. > >... > > I can reproduce the problem in a current amd64 unstable chroot. Great, can you provide some information regarding how? Could you for example modify iptables.prerm to check what the content of $IFS is when you reproduce this? Did any other packages maintainer script (which does things with IFS) error out while you reproduce the problem with iptables? I can only speculate about this issue. I don't doubt the original reportes error message actually happened and is real, but I don't see how. The only possibility I see is that IFS was modified to a non-default value which made it no longer include tab- and space-characters. The iptables.prerm script doesn't set IFS itself, so I have to assume it somehow inherited a dirty environment from somewhere. Is it possible that some other packages maintainerscript code messed with IFS without resetting it and then that environment got inherited by iptables.prerm? If so then I think the package needs to be identified and this bug reassigned to it I don't think every package that has maintainerscripts should expect a dirty environment and guard against for example a non-default IFS, but that's kind of the only solution inside iptables that I can see have it explicitly (un)set IFS. I however don't think that's the correct solution, just a solution. > > #1007829 was a similar problem in arptables, > I haven't checked how these are related. I don't see how these two are related at all. #1007829 seems to be a simple logic error. Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
On Wed, Feb 01, 2023 at 04:46:14PM +0100, Guido Günther wrote: > Hi, > On Wed, Feb 01, 2023 at 04:37:37PM +0100, Andreas Henriksson wrote: [...] > > FWIW here are some examples of autopkgtest for checking if pkg-config > > works for your own -dev packages: > > https://sources.debian.org/src/util-linux/2.38.1-4/debian/tests/ > > We have tests for that like ages: > > > https://salsa.debian.org/swaywm-team/wlroots/-/blob/debian/latest/debian/tests/ > > It just won't trigger if you don't need the vulkan renderer. Feel free > to submit a patch that exercises that as well. Not sure why your tests doesn't catch this then. You can reproduce this as simple as this: 1. start with a clean sid chroot (eg. `pbuilder login`) 2. add experimental to /etc/apt/sources.list 3. apt update 4. apt install libwlroots-dev/experimental 5. pkg-config --cflags wlroots Package vulkan was not found in the pkg-config search path. Perhaps you should add the directory containing `vulkan.pc' to the PKG_CONFIG_PATH environment variable Package 'vulkan', required by 'wlroots', not found There's nothing vulkan specific about my clean chroot. Anyone trying to use `pkg-config --cflags wlroots` should see it exit with 1 (error). FWIW here's what I get when I launch your tests in my chroot: ``` # ls -l total 8 -rwxr-xr-x 1 root root 248 Feb 1 16:30 build-test -rw-r--r-- 1 root root 300 Feb 1 16:30 test.c # ./build-test Package vulkan was not found in the pkg-config search path. Perhaps you should add the directory containing `vulkan.pc' to the PKG_CONFIG_PATH environment variable Package 'vulkan', required by 'wlroots', not found gcc test.c -lwlroots -lwayland-server Build test of test.c succeeded WLR_BACKENDS=headless ./a.out 00:00:00.000 [backend/backend.c:297] Loading user-specified backends due to WLR_BACKENDS: headless 00:00:00.000 [backend/headless/backend.c:68] Creating headless backend ``` So it doesn't seem like your test-case actually catches the pkg-config exit code (and apparently the build still succeeds without cflags). Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
On Wed, Feb 01, 2023 at 04:23:00PM +0100, Andreas Henriksson wrote: > On Wed, Feb 01, 2023 at 04:03:47PM +0100, Guido Günther wrote: > > Hi, > > [..snip..] > > > This seems to be caused by wlroots/experimental missing a > > > build-dependency on libvulkan-dev and indeed after installing > > > that package the build works again. > > > > There is a build-dependency on libvulkan-dev. I think what you mean is > > the lack of a dependency in the libwlroots-dev package? > > Exactly... I've already retitled the bug report (again) to remove > my incorrect use of build-dep, when what I mean was -dev package > depending on another -dev package. FWIW here are some examples of autopkgtest for checking if pkg-config works for your own -dev packages: https://sources.debian.org/src/util-linux/2.38.1-4/debian/tests/ Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
On Wed, Feb 01, 2023 at 04:03:47PM +0100, Guido Günther wrote: > Hi, > [..snip..] > > This seems to be caused by wlroots/experimental missing a > > build-dependency on libvulkan-dev and indeed after installing > > that package the build works again. > > There is a build-dependency on libvulkan-dev. I think what you mean is > the lack of a dependency in the libwlroots-dev package? Exactly... I've already retitled the bug report (again) to remove my incorrect use of build-dep, when what I mean was -dev package depending on another -dev package. Regards, Andreas Henriksson
Bug#1030240: wayfire: FTBFS with wlroots 0.16.1
Control: reassign -1 wlroots 0.16.1-1 Control: retitle -1 wlroots/exp: missing build-dep on libvulkan-dev (breaks pkg-config) Control: affects -1 wayfire On Wed, Feb 01, 2023 at 02:15:37PM +0100, Andreas Beckmann wrote: > Source: wayfire > Version: 0.7.5-1~exp1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > Hi, > > wayfire/experimental recently started to FTBFS: [...] > Run-time dependency wlroots found: NO (tried pkgconfig and cmake) [...] > This seems to be related to the wlroots upgrade from 0.16.0 to 0.16.1 in > experimental. Did a build of my own and got some more useful information: Determining dependency 'wlroots' with pkg-config executable '/usr/bin/pkg-config' env[PKG_CONFIG_PATH]: Called `/usr/bin/pkg-config --modversion wlroots` -> 0 0.16.1 env[PKG_CONFIG_PATH]: Called `/usr/bin/pkg-config --cflags wlroots` -> 1 pkg-config error with 'wlroots': Could not generate cargs for wlroots: Package vulkan was not found in the pkg-config search path. Perhaps you should add the directory containing `vulkan.pc' to the PKG_CONFIG_PATH environment variable Package 'vulkan', required by 'wlroots', not found This seems to be caused by wlroots/experimental missing a build-dependency on libvulkan-dev and indeed after installing that package the build works again. Every package listed in pkg-config .pc files Requires* must be available and thus the package holding the .pc file referenced must be a build-dependency... otherwise pkg-config will not work. Adding autopkgtest to run pkg-config --cflags --libs etc. and maybe build a trivial example application is a great way to make sure pkg-config is working as expected (because it's easy to forget to check every .pc file changes and cross-check which package provides that and if it's listed in build-depends on every update). Regards, Andreas Henriksson
Bug#1030000: fontconfig: after upgrade from 2.13.1-4.5 to 2.14.1-3 subpixel is enabled
Hello Thorsten Glaser, Thanks for your bug report. On Mon, Jan 30, 2023 at 03:32:02AM +0100, Thorsten Glaser wrote: > Package: fontconfig > Version: 2.14.1-3 > Severity: serious > Justification: Policy 10.7.3 > X-Debbugs-Cc: t...@mirbsd.de > > > * local changes must be preserved during a package upgrade, and > > After an upgrade, etckeeper reports that > /etc/fonts/conf.d/10-sub-pixel-rgb.conf > shows up again, despite the local admin > choice to not have blurry fonts. Ouch, no relevant changes to maintainer scripts has been done. Have you experienced this problem in previous upgrades? Can you reproduce the problem at all? > > Running dpkg-reconfigure -plow fontconfig-config > shows that the debconf database correctly remembers > the admin-provided setting (subpixel disabled was > pre-selected), By 'disabled' I assume you mean 'Never', right? > and just pressing Enter on every > question makes it remove that file, Did it also create 10-no-sub-pixel.conf ? (Which would be consistent with 'Never'. If neither file exists, that's the 'Automatic' option which is also the default.) > so I believe that some maintainer script errorneously forcibly > creates that file overriding local configuration. Is there any chance you can try to find some additional information on what happened on your system? It sounds weird that you would end up with 'Always' option somehow when default is 'Automatic' and you supposedly selected 'Never'. The relevant code is here: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L93-L116 Note that this is protected by: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L32 https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L13-L23 (Thus it should not have run at all on upgrade.) See also: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.config/#L49-L64 Possibly 'Always' option could have come from here: https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.config/#L56 But then again, the initial/re-configure should not have been run at all because of https://sources.debian.org/src/fontconfig/2.14.1-3/debian/fontconfig-config.postinst/#L32 as mentioned earlier. Regards, Andreas Henriksson
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hello, On Tue, Jan 31, 2023 at 02:26:50AM +0100, Helge Deller wrote: > Hi David & Andreas, > > On 1/28/23 12:10, David Prévot wrote: > > Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit : > > > On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson > > > wrote: > > > > Here's a slightly different patch to implement basically the same thing > > > > > > Unfortunately, even if both patches allow me to build tar on i386, they > > also both lead to an FTBFS on amd64. > > That's right. glibc headers used by configure complains then that > _TIME_BITS=64 can only be > used if FILE_OFFSET_BITS=64 is defined too (which isn't the case on amd64 > as it's not needed there). > > So, please use this hunk instead. It compiles for me on amd64 and 32-bit hppa. In my attempt at https://salsa.debian.org/debian/tar/-/commits/wip/bug1026204 I tried to avoid hardcoding assumptions about flags (and rely on gnulib DTRT), but I agree what I came up with is just to convoluted and it's probably a better idea to just use Helges suggestion below. > > export DEB_BUILD_MAINT_OPTIONS = future=+lfs > export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument Might be useful to add a comment here saying: # Workaround gnulib issue: The below three lines can be dropped once tar >= 1.35 is used. > ifneq ($(shell dpkg-architecture -qDEB_TARGET_ARCH_BITS),64) > export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64 > endif > > DPKG_EXPORT_BUILDFLAGS = 1 > include /usr/share/dpkg/buildflags.mk > --- > Helge I assume you also have no idea how to use src:gnulib when building tar (or maybe it's just too complicated change)? (The problem should already be fixed in the version of src:gnulib we have in debian...) Will you go ahead and upload this Helge? Regards, Andreas Henriksson
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hello taffit, On Sat, Jan 28, 2023 at 12:10:53PM +0100, David Prévot wrote: > Hi, > > Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit : > > On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson > > wrote: > > > Here's a slightly different patch to implement basically the same thing > > > > Yes, I like this patch better too. > > Unfortunately, even if both patches allow me to build tar on i386, they > also both lead to an FTBFS on amd64. Thanks for the feedback. I ran short on time when looking at this and tried to cheap out on just setting `-D_TIME_BITS=64` directly which causes problems. I generally have no clue when it comes to gnulib but I've now made an attempt at backporting the `year2038` gnulib module that upstream has enabled. I've pushed this here: https://salsa.debian.org/debian/tar/-/commits/wip/bug1026204 This time I've build-tested both on a sid amd64 chroot and a sid i386 chroot (on top of amd64). Maybe there's a better/cleaner way of doing this backport. I also have no idea if this impacts the output format of tar in any incompatible way, but hopefully it doesn't since upstream seems to now have it enabled by default in git atleast. Hopefully someone finds this useful... I'm not confident enough to actually upload this myself. Reviews welcome. Also note that the debian gnulib package seems to have the year2038 stuff in largefile.m4 already, so maybe it would be better to try to use that instead of the bundled m4 files in tar?!... (That should hopefully also sort out anyones worry about shipping generated (diff) files without source.) Regards, Andreas Henriksson
Bug#997274: NMU strace 6.1 for unstable?
Hello Steve McIntyre, As you might have noticed I've taken the liberty to NMU strace into *experimental*. I've done so based on my past experience that strace can have many architecture specific problems, to give me a picture of what the situation is for the latest upstream 6.1 release. (And since it's experimental we have the posisibily to just RM it and act like it never happened.) It seems like mips* has test failures (as usual?!). I've filed https://github.com/strace/strace/issues/235 with my limited conclusions about the issues. Given that strace has not been updated for the entire release cycle and that it's currently RC-buggy, I think it would be useful to try to update it before the 12 Feb freeze. The time window is however very small. Additionally ppc64el seems to have a huge build backlog, so if we want to make it during the limited time window before the freeze we can't wait for the results. (I could possibly build on a ppc64el porterbox to see if I can spot any problems there.) I would like to know what you think about a potential NMU of strace 6.1 to unstable at this point. Probably with mips* tests set to not fail the build (`|| true`). Possibly the same for ppc64el just to make sure it doesn't give any surprises once it finally builds (and the upload is old enough to migrate to testing). If I'm going to do the NMU I'll need to proceed very soon so your input on this would be very appreciated if you could give it ASAP! What do you think? Regards, Andreas Henriksson
Bug#999322: Intent to NMU
Hello, I intend to NMU changes to fix the outstanding RC bugs as well as some related changes for bonnie++ in Debian. The changes was made against the git repo and are available as a salsa MR at: https://salsa.debian.org/etbe/bonnie/-/merge_requests/2 Since these bugs seems to have been around for a long time (some including patches) and that we're getting really close to freeze I'm uploading directly into unstable without any delay to have a chance for bonnie++ to make it back into testing. Please feel free to do a maintainer upload to override my upload if there's anything in here that is controversial or wrong, but hopefully there isn't. Regards, Andreas Henriksson
Bug#1029101: Acknowledgement (fontconfig-config: 2.14.1 upload breaks testSimpleText of libreoffice)
Hello Rene Engelhard, On Tue, Jan 17, 2023 at 07:23:17PM +0100, Rene Engelhard wrote: > severity 1029101 important > retitle 1029101 please Enable RGB stripes layout for sub-pixel rendering on > KDE only > thanks > > [ sorry for "spamming" ] [...] Thanks for taking the time to report and follow up on this! Sorry for the wall of text below. I have to admit I'm having a bit of trouble following everything, possibly because of my lack of knowledge in several areas. I'd like to explicitly ask if you still want me to upload any fontconfig change ASAP or if downgrading severity means you think it can/should wait until after release? As I understand the situation something related to subpixel rendering has changed between 2.13.x and 2.14.1. Debian offers debconf choices "Automatic", "Always" and "Never" for which settings to use in /etc/fonts/conf.d/$SYMLINK which are related to the problem you're reporting. Fedora on the other hand seems to use "always/only on KDE" (with no alternatives) as far as I understand the commit you pointed out. Does that mean we should: - offer an additional alternative /or/ patch "Always"? - make then new/patched alternative the default? - get rid of debconf alternatives and provide one consistent configuration for all users? Unless we do the last option, wouldn't it mean any (test) failures still happen if the user uses any of the other options? (Which would suggest this is not actually a bug on the fontconfig side to me.) In the mail where you tagged this patch you suggested to edit the subpixel config file which makes me think you're using the Always alternative, but as I understand the debconf code Automatic is the (current) default... If you think you have a clear picture of exactly what should happen (on the fontconfig side) then I would very much appreciate if you could either send a salsa MR or just NMU (and I'll make sure to import the NMU-diff into the fontconfig packaging repo). As of right now I'm considering removing the patch tag as the exact change needed here is still unclear to me. (but thanks alot for pin-pointing the problematic area!) Regards, Andreas Henriksson
Bug#1027383: xen-tools: FTBFS in bullseye (missing build-depends on mount)
Hello Santiago Vila, While I do consider this a valid (wishlist) bug report, ... On Fri, Dec 30, 2022 at 07:04:32PM +0100, Santiago Vila wrote: > Package: src:xen-tools > Version: 4.9-1 > Severity: serious > Tags: ftbfs patch [...] > CPUs, using a reduced chroot with only build-essential packages (plus > debhelper). [...] This IMHO means you're using an *unsupported* system setup! None of the debootstrap variants lacks `Priority: required` packages and I don't think this warrants a release-critical severity. (You might argue about the exact wording of policy, but I think you should better do that in a policy bug report or their mailing list. This is not a practical problem until you use an unsupported setup, which means you get to keep all the pieces. The name of the priority level should be pretty self-explanatory - *required*, not recommended.) As already mentioned, I think wishlist is the proper severity. (And as said, I don't mind this being considered a bug or fixing it which is simple... however with a relevant severity.) Regards, Andreas Henriksson
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hello, On Fri, Dec 16, 2022 at 09:13:44AM +0100, Helge Deller wrote: > Package: tar > Version: 1.34+dfsg-1.1 > Tags: hppa, patch, ftbfs, lfs [...] > I've found, that changing the line 12 in debian/rules from > CPPFLAGS = `dpkg-buildflags --get CPPFLAGS` > to: > CPPFLAGS = `dpkg-buildflags --get CPPFLAGS` -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -D__USE_TIME_BITS64 > does solve the issue. [...] Thanks for identifying the solution already. Here's a slightly different patch to implement basically the same thing (and I can confirm it builds in an i386 chroot which previously failed). (Note: The initial two lines in debian/rules could also be replaced by `include /usr/share/dpkg/architecture.mk` for further slight modernization.) Regards, Andreas Henriksson --- a/debian/rules 2023-01-14 19:20:32.572449385 + +++ b/debian/rules 2023-01-14 19:19:02.745766528 + @@ -6,10 +6,12 @@ CONFARGS = --host=$(DEB_HOST_GNU_TYPE) endif -CFLAGS = `dpkg-buildflags --get CFLAGS` -CFLAGS += -Wall -Wno-analyzer-null-argument -LDFLAGS += `dpkg-buildflags --get LDFLAGS` -CPPFLAGS = `dpkg-buildflags --get CPPFLAGS` +export DEB_BUILD_MAINT_OPTIONS = future=+lfs +export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument +export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64 + +DPKG_EXPORT_BUILDFLAGS = 1 +include /usr/share/dpkg/buildflags.mk export BUILD_DATE = $(shell dpkg-parsechangelog | sed -n -e 's/^Date: //p')
Bug#1027619: gh: FTBFS: tests fail
Hello Lucas Nussbaum, Could you please provide some additional input? See below. On Sun, Jan 01, 2023 at 03:33:44PM +0100, Lucas Nussbaum wrote: > Source: gh > Version: 2.18.1+dfsg1-1 > Severity: serious > Justification: FTBFS [...] > > === RUN TestStartJupyterServerFailure > > client_test.go:70: error connecting to internal server: failed to share > > remote port 16634: dial tcp 127.0.0.1:50051: connect: connection refused > > --- FAIL: TestStartJupyterServerFailure (0.00s) > > FAIL > > FAILgithub.com/cli/cli/v2/internal/codespaces/grpc 0.039s > > ? github.com/cli/cli/v2/internal/codespaces/grpc/jupyter [no > > test files] > > ? github.com/cli/cli/v2/internal/codespaces/grpc/test [no > > test files] > > ? github.com/cli/cli/v2/internal/config [no test files] [...] Port 16634 is hardcoded at: ./internal/codespaces/grpc/client.go: codespacesInternalPort= 16634 If this port is not available I presume things will just fail. I've rebuilt the package locally and it succeeds for me. It also succeded on the official buildds. If you are able to reproduce the problem it would be great if you could check what is using the port to identify if it's some external program using this port and thus making the test fail or if it possibly is the test-suite racing against itself somehow. As far as I can tell right now, this issue doesn't seem release-critical to me so consider if maybe the severity should be downgraded. Regards, Andreas Henriksson
Bug#1027803: src:fakeroot: fails to migrate to testing for too long: ftbfs on mipsel
Hello, So the mipsel FTBFS is because of a failing test-case that was added in the 1.30-1 version of fakeroot. For more information on this issue see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023286#48 Regards, Andreas Henriksson
Bug#1028278: dh-cmake FTBFS with Python 3.11 as default version
On Mon, Jan 09, 2023 at 08:02:05AM +0200, Adrian Bunk wrote: > Source: dh-cmake > Version: 0.6.1 > Severity: serious > Tags: ftbfs bookworm sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dh-cmake.html [...] > > File "/build/1st/dh-cmake-0.6.1/dhcmake/tests/source_check.py", line 25, in > > self.foreach_py(lambda a, r, c: self.assertEqual(autopep8.fix_code(c), c, > ^ > AssertionError: '# Th[204 chars]\n\n# from unittest import skip\n\nimport > os\n[9838 chars]e)\n' != '# Th[204 chars]\n\n#from unittest import > skip\n\nimport os\nf[9837 chars]e)\n' > Diff is 10430 characters long. Set self.maxDiff to None to see it. : File > dhcmake/tests/common.py is incorrectly formatted [...] So same as above, but in my own words: It seems autopep8.fix_code() has changed it's opinion on formatting and now thinks dhcmake/tests/common.py line 5 should have a space after the hash (#) character (before `from unittest import skip`). The new style looks better IMHO and this might be a bugfix in autopep8.fix_code(), but at the same time changes like these might cause alot of breakage (atleast if used in tests like in this case). Regards, Andreas Henriksson
Bug#1025884: src:ddnet: fails to migrate to testing for too long: FTBFS on s390x
Hello, The upstream PR fixing big endian builds that Adrian Bunk previously set in the forwarded control message is now merged upstream. It would be great if this commit could be cherry-picked as a patch into the ddnet package to fix build os s390x (big endian): https://github.com/ddnet/ddnet/commit/abb1979d20d9a3290442d5d0ed304ce24c0a710e Regards, Andreas Henriksson
Bug#1028146: collectd FTBFS with Python 3.11 as default version
Control: tags -1 + fixed-upstream Control: forwarded -1 https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/11 Hello, The python 3.11 issue is fixed upstream in this commit: https://github.com/collectd/collectd/commit/623e95394e0e62e7f9ced2104b786d21e9c0bf53 A merge-request against the debian collectd packaging git repo has been opened, albeit with a different patch than upstreams: https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/11 Regards, Andreas Henriksson
Bug#1016963: Please test u-boot for rpi_4 rpi_4_32b
On Tue, Jan 03, 2023 at 11:56:51PM +0100, Andreas Henriksson wrote: > On Tue, Jan 03, 2023 at 11:46:31PM +0100, Andreas Henriksson wrote: > > On Wed, Dec 28, 2022 at 04:11:04PM -0800, Vagrant Cascadian wrote: > > > rpi_4 > > > rpi_4_32b [...] Hello again, While I only have the earliest rpi 4B rev A0 (1.1) it has come to my attention that apparently there's a revision C0 (1.4) that has problems booting with u-boot. Apparently in 1.4 revision they changed the hardware in an incompatible way and then cover this up by having the proprietary firmware modify the dtb in ram to change nodes as needed. The issue has been discussed on the rpi forums: https://forums.raspberrypi.com/viewtopic.php?t=315662 There has been seemingly two indenpendent attempts at submitting (very similar) patches upstream to adress this in u-boot: https://lists.denx.de/pipermail/u-boot/2021-November/468322.html https://lists.denx.de/pipermail/u-boot/2021-September/462020.html ... but apparently they've never been merged. NixOS are carrying patches: https://github.com/NixOS/nixpkgs/tree/master/pkgs/misc/uboot which includes some revision of Sjoerds patch. Some info on board revisions can be found at: https://www.raspberrypi-spy.co.uk/2012/09/checking-your-raspberry-pi-board-version/ This issue probably deserves it's own separate bug report, but since I don't have the hardware in question I'm leaving that to who ever else cares and just share the info I have. It might be useful to consider just include NixOS/Sjoerds patch or documenting that RPi 4B hw rev 1.4 will not work. (Hardware revision is visible in /proc/cpuinfo under the Revision: field.) However it maybe best trying to find someone who has the affected hardware revision that can confirm the problem exists and that the patch actually resolves it. Regards, Andreas Henriksson
Bug#1006932: RFC: fontconfig 2.14.1-1 experimental branch on salsa.debian.org
Hello all, As per my previous call for review and testing. New upstream release of fontconfig is now in experimental. (The big endian FTBFS should be fixed in git.) If people who experienced #909750 could help confirm if the problem is fixed or now that feedback would be very welcome! Also general feedback if it's suitable to upload the experimental package to unstable this close to the freeze (which I feel will need to happen ASAP or wait until after the release). If I don't get any feedback, I will likely not upload to unstable. Regards, Andreas Henriksson
Bug#1027787: debos: Unusable with recipes using bookworm suite (or newer)
Control: tags -1 + upstream Control: forwarded -1 https://github.com/go-debos/debos/pull/390 Hello, On Tue, Jan 03, 2023 at 11:34:27AM +0100, Andreas Henriksson wrote: > Package: debos > Version: 1.1.1-2 > Severity: important > > Dear Maintainer, > > Using debos to build a recipe that uses bookworm or newer suite > gives a mysterious apt error that suggest running apt --fix-broken > install. > > This is a symptom of the workaround that was applied for > https://github.com/go-debos/debos/issues/361 > "New debootstrap is unable to bootstrap pre-bookworm debian derivatives" [...] For the record, this first problem was handled upstream at https://github.com/go-debos/debos/pull/390 [...] > 2023/01/03 01:19:51 apt | Setting up linux-image-6.0.0-6-arm64 (6.0.12-1) ... > 2023/01/03 01:19:55 apt | I: /vmlinuz.old is now a symlink to > boot/vmlinuz-6.0.0-6-arm64 > 2023/01/03 01:19:55 apt | I: /initrd.img.old is now a symlink to > boot/initrd.img-6.0.0-6-arm64 > 2023/01/03 01:19:55 apt | I: /vmlinuz is now a symlink to > boot/vmlinuz-6.0.0-6-arm64 > 2023/01/03 01:19:55 apt | I: /initrd.img is now a symlink to > boot/initrd.img-6.0.0-6-arm64 > 2023/01/03 01:19:56 apt | /etc/kernel/postinst.d/initramfs-tools: > 2023/01/03 01:19:56 apt | update-initramfs: Generating > /boot/initrd.img-6.0.0-6-arm64 > 2023/01/03 01:19:56 apt | W: No zstd in /usr/bin:/sbin:/bin, using gzip > 2023/01/03 01:30:32 apt | Container root terminated by signal KILL. > Powering off. > open /tmp/fakemachine-194296958/result: no such file or directory This second problem turned out to be because the default 2Gb memory setting for fakemachine/qemu is apparently no longer enough to run update-initramfs against the bookworm arm64 kernel modules in linux-image-arm64. Using `debos --memory=4Gb ...` resolved this issue for me. Maybe it would be useful to consider bumping the default memory setting? Regards, Andreas Henriksson
