Bug#1081978: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b9
Scott Talbert (2024-09-16): > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org > Control: affects -1 + src:libalien-wxwidgets-perl > User: release.debian@packages.debian.org > Usertags: binnmu > > NOTE: please make this depwait for libwxgtk3.2-dev 3.2.6+dfsg-1 > > nmu libalien-wxwidgets-perl_0.69+dfsg-6+b9 . ANY . unstable . -m "rebuild for > wxWidgets 3.2.6" Ping, d-i daily builds cannot happen until both requests have been processed, and some users are waiting on bugfixes (that cannot be built/published as a result). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1082137: E: Unimplemented function failure on qemu virtual machine.
Samuel Thibault (2024-09-18): > This is fixed in espeakup 1:0.90-15 and should have been included in > today's daily build, but it seems it didn't get built, I don't know why? Because: The following packages have unmet dependencies: libalien-wxwidgets-perl : Depends: libwxgtk3.2-dev (< 3.2.6~) but 3.2.6+dfsg-1 is to be installed Depends: libwxgtk-media3.2-dev (< 3.2.6~) but 3.2.6+dfsg-1 is to be installed E: Unable to correct problems, you have held broken packages. See the #1081978 / #1081979 pair. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1081934: override: cron:admin/optional
[ Received via debian-boot@ like any other override-related requests, but replying mainly with a random DD/user hat… ] Martin-Éric Racine (2024-09-16): > cron is still at Priority:important even though Lintian has long > warned that packages should migrate to systemd timers before the next > Debian release. I'm not seeing any research showing that that happened… > I therefore propose downgrading cron to Priority:optional and updating > the override to match. … so that looks premature? > Exception: the Hurd port doesn't have systemd and still depends on > traditional cron jobs. cron should therefore remain at > Priority:important, but on Hurd only. Cc-ing debian-hurd@ for that part. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1081698: RM: debian-installer [armel] -- ROM; armel support goes away
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: debian-instal...@packages.debian.org, debian-...@lists.debian.org Control: affects -1 + src:debian-installer Hi, armel is EOL'd as far as linux/debian-installer support goes, and we have nothing to build on armel anymore. Please remove the debian-installer binary on armel. It contains some documentation but mainly records a bunch of packages via Built-Using. This is part 1 (out of 2) of the plan drafted a while back: https://lists.debian.org/debian-boot/2024/03/msg00016.html https://lists.debian.org/debian-boot/2024/03/msg00025.html I have no opinion as to whether (not) cleaning up the installer-armel directory[1] should happen in an arch-specific manner. I'd expect having both initial and current version in the bookworm directory[2] would be sufficient in case someone needs a DeLorean. 1. https://deb.debian.org/debian/dists/unstable/main/installer-armel/ 2. https://deb.debian.org/debian/dists/bookworm/main/installer-armel/ I've Cc'd the ARM porters list in case someone has an opinion about that. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1055016: override: tasksel-data:admin/optional
Sean Whitton (2024-09-13): > On Sun 29 Oct 2023 at 12:54pm +01, Cyril Brulebois wrote: > > > It's probably safe since pkgsel's postinst features: > > > > if db_get pkgsel/run_tasksel && [ "$RET" = true ]; then > > log "starting tasksel" > > db_progress INFO pkgsel/progress/tasksel > > apt-install tasksel # ensure tasksel is installed > > Given this, I'm belatedly going ahead with this. OK, thanks for letting us know. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1018690: override: python3-reportbug:python/optional
Sean Whitton (2024-09-13): > On Sat 03 Sep 2022 at 10:42pm -07, Sean Whitton wrote: > > Hello, > > > > On Sun 28 Aug 2022 at 10:45PM -05, Daniel Lewart wrote: > >> Please change the python3-reportbug Priority from standard to optional. > > > > This sounds right, but could the maintainers chime in? Thanks. > > Ping. I'd like to process this. Thanks. Not the maintainer, but no objections from the d-i side. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1074126: bookworm-pu: ntfs-3g/1:2022.10.3-1+deb12u1
Jonathan Wiltshire (2024-09-03): > Control: tag -1 d-i > > On Tue, Sep 03, 2024 at 08:58:52AM +0100, Jonathan Wiltshire wrote: > > On Sun, Jun 23, 2024 at 03:26:21PM +0200, László Böszörményi wrote: > > > [ Reason ] > > > A use-after-free security issue was found. It is not a severe one, so > > > no DSA will be released. But it would be good to have it fixed. > > > > Please add a "closes: #1073248" to the changelog and go ahead. > > I missed the udeb, sorry. Are there any objections from the d-i side? That seems very fine. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1080269: crowdsec: TestOneShot fail: alctl_test.go:172: Expected log output 'journalctl: invalid option' but got nothing !
Hallo Reinhard, Reinhard Tartler (2024-09-01): > While working on updating the docker.io package in experimental, I've > noticed an autopkgtest failure on arm64 that did not happen on amd64: > > https://ci.debian.net/packages/c/crowdsec/unstable/arm64/51171995/ > > 274s === RUN TestOneShot > 274s journalctl_test.go:172: Expected log output 'journalctl: invalid > option' but got nothing ! > 274s --- FAIL: TestOneShot (0.05s) > > > Looking at the code in question, I don't see anything obvious that > could be attributed into changes of the docker.io package: > > https://sources.debian.org/src/crowdsec/1.4.6-9/pkg/acquisition/modules/journalctl/journalctl_test.go/?hl=104#L104-L178 > > Please have a look at the code and form an opinion whether this > indicates a flaky test (in which case disabling it it might be a good > way to proceed), or whether code changes in either the docker.io > package or crowdsec would be appropriate. I'd suggest taking this specific issue out of your todo list before considering an upload to unstable: I'd rather avoiding diving into unstable + experimental overlay with different results per arch at this point, and deal with whatever happens in unstable. (Of course letting this bug report get an upgraded severity, possibly resulting in crowdsec's getting out of testing for a little while.) Would that approach be sufficient to let you make more progress? Danke dir, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1068898: Tested Martin's installer on OpenRD client and it works.
Martin Michlmayr (2024-09-01): > Anything else needed to apply this patch? > > It seems it didn't make 12.7. That's on me, the back and forth at the time took some time and that wasn't merged as that could have been if things went more hop-pop-pop. Then last weekend I didn't remember the branch (and for some reasons didn't see it in gitk with all the other things in there). Some more distraction popped up as well, on the SB(AT) front — even if I only noticed after the git-side of the point release preparations so that is really no excuse. Just merged the pu/openrd branch into the bookworm one so it cannot be missed next time. Apologies for the missed opportunity. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1079374: debootstrap: Needs to look through Provides
Hi,
Samuel Thibault (2024-08-26):
> Another way that was suggested on irc is to hardcode something this:
>
> diff --git a/scripts/debian-common b/scripts/debian-common
> index 4a25654..cb4dbdd 100644
> --- a/scripts/debian-common
> +++ b/scripts/debian-common
> @@ -75,6 +75,18 @@ work_out_debs () {
> EXCLUDE_DEPENDENCY="$EXCLUDE_DEPENDENCY usrmerge"
> ;;
> esac
> +
> + case $ARCH in
> + hurd-*)
> + # cron-daemon-common depends on systemd-opensysusers
> + # that opensysusers Provides, but debootstrap won't
> + # see that
> + case $base in *" cron "*)
> + required="$required opensysusers"
> + ;;
> + esac
> + ;;
> + esac
> }
>
> first_stage_install () {
>
> That's quite ugly but I currently don't really see another way?
No objections from my side (not that I'm particularly active on the
debootstrap front anyway…).
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1079086: systemd 252.30-1~deb12u1 flagged for acceptance
Adam D Barratt (2024-08-22): > package release.debian.org > tags 1079086 = bookworm pending > thanks > > Hi, > > The upload referenced by this bug report has been flagged for acceptance into > the proposed-updates queue for Debian bookworm. > > Thanks for your contribution! > > Upload details > == > > Package: systemd > Version: 252.30-1~deb12u1 > > Explanation: new upstream stable release Anyone having tweaked journald.conf is going to get a prompt because of the following change: -#MaxRetentionSec= +#MaxRetentionSec=0 That's not really something I'd expect from a point release… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1079175: python3-pkg-resources: pkg_resources cannot be imported: No module named 'packaging'
Control: affects -1 depthcharge-tools Ciao ema, Emanuele Rocca (2024-08-20): > Package: python3-pkg-resources > Version: 72.2.0-1 > Severity: serious > X-Debbugs-CC: debian-b...@lists.debian.org > > [debian-boot added to CC as this issue breaks d-i builds] Thanks for the heads-up, much appreciated. > Importing pkg_resources fails with the following error: > > (sid-amd64-sbuild)ema@ariel:~$ python3 > Python 3.12.5 (main, Aug 7 2024, 13:49:14) [GCC 14.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import pkg_resources > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 95, > in > import packaging.specifiers > ModuleNotFoundError: No module named 'packaging' > > This is a regression in version 72.2.0-1, whereas 70.3.0-2 worked fine. > > For an example of d-i build failure caused by this problem, see: > https://salsa.debian.org/installer-team/debian-installer/-/jobs/6155545 > > It seems that installing python3-packaging, python3-jaraco.text, and > python3-platformdirs fixes it. I couldn't replicate the FTBFS within a devel sid chroot that has tons of extra packages, including python3-packaging, and python3-platformdirs, but not python3-jaraco.text. Purging python3-platformdirs still gives me a successful build. And from the error/call site quoted above, it seems python3-packaging could be sufficient? (It doesn't list anything but python3:any in Depends or Recommends…) I haven't tried just adding python3-packaging under sbuild though, I'm merely a little curious why the two other packages would be necessary. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071970: pcre3 should not be part of trixie
Matthew Vernon (2024-08-07): > On 07/08/2024 06:18, Paul Gevers wrote: > > Please don't do that until you have approval from d-i. I included > > them in the mail chain. If the udeb is used by d-i, that needs to be > > resolved first. > > Noted, although I'm pretty sure d-i moved to pcre2 a while back now. I'm not seeing any reverse dependencies for the libpcre3-udeb package, so we should be good. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076695: debian-installer: /boot partition created by installer isn't big enough
Hi, Jonathan Kamens (2024-07-21): > Something changed recently in testing which caused the size of my > initrd to go up A Lot, e.g., on one computer from 70MB to 248MB. As a > result my boot partition was no longer big enough to handle two extant > kernels plus the new kernel files being built by an install, so I had > to reinstall my laptop from scratch to grow the boot partition. Have you tried comparing before/after to see where this increase comes from? Checking the compression settings would also make sense. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076684: debian-installer: installer adds unrecognized x-initrd.attach option to /etc/crypttab
Hi, Jonathan Kamens (2024-07-21): > After installing from the most recent amd64 testing netinst, I keep > seeing complaints from cryptsetup, e.g., during boot, about ignoring > the unrecognized option "x-initrd.attach". It appears that the > installer inserted this into /etc/crypttab but cryptsetup does not > know what to make of it. Last time this popped up, people got pointed to #1072058. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068898: Tested Martin's installer on OpenRD client and it works.
Rick Thomas (2024-07-19): > Sorry for the long delay in getting to this! > > I have successfully installed Debian 12.6 on my OpenRD "client" > machine using Martin's installer. Great news, thanks. I suppose this means the image is sufficiently self-contained that the installer didn't need to pull e.g. kernel-related udebs from the network? That image was built a while back, and I'd have imagined you might run into troubles if you didn't test it on the spot (as is the case for netboot builds for everyone, not just on arm devices). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076596: bookworm-pu: package gtk+2.0/2.24.33-2+deb12u1
Simon McVittie (2024-07-19): > Sorry, I should have remembered that because GTK 2 is used in the > graphical installer, this update will require a d-i ack. (Full text > and diff quoted below.) Please go ahead, I'll double check once it lands in pu. In the very worst case, we could dodge at the very last moment while building d-i (picking the version in stable instead). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076598: bullseye-pu: package gtk+2.0/2.24.33-2+deb11u1
Simon McVittie (2024-07-19): > I have not yet attempted to build a debian-installer image with the > proposed GTK. > > [ Risks ] > Low risk, straightforward backport of a targeted security fix. > > One risk here is that Debian 11.11 is intended to be its last scheduled > point release, so if this somehow causes a regression, there will be no > more point releases in which the regression can be fixed, and it will > be up to the LTS team to deal with the fallout. > > [ Other info ] > GTK 2 is used in the graphical installer, so this will require a d-i ack. Please go ahead, I'll double check once it lands in opu. In the very worst case, we could dodge at the very last moment while building d-i (picking the version in oldstable instead). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076609: bullseye-pu: package gtk+3.0/3.24.24-4+deb11u4
Simon McVittie (2024-07-19): > GTK 3 produces udebs, so officially it needs a d-i ack (debian-boot cc'd > for this); but in practice the graphical installer is still using GTK 2 > even in testing/unstable, so I believe it would be OK to ship this > change without waiting for the d-i team's approval. Absolutely, and no need to ask in the future. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076603: bookworm-pu: package gtk+3.0/3.24.38-2~deb12u2
Simon McVittie (2024-07-19): > GTK 3 produces udebs, so officially it needs a d-i ack (debian-boot > cc'd for this); but in practice the graphical installer is still using > GTK 2 even in testing/unstable, so I believe it would be OK to ship > this change without waiting for the d-i team's approval. Absolutely, and no need to ask in the future. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076479: nocloud: too-wide permissions on /etc/netplan/90-default.yaml
Noah Meyerhans (2024-07-16): > Control: tags -1 + moreinfo > > > > I'm not sure where this file is coming from, but it'd be great to have > > > those permissions fixed/those warnings go away. Thanks for filing this. > I don't actually see any issues with /etc/netplan/90-default.yaml on the > current sid nocloud images: > > root@localhost:~# cat /etc/cloud-release > ID=nocloud > VERSION="20240716-1810" > > root@localhost:~# journalctl -b | grep -i netplan > Jul 16 22:32:24 localhost systemd[1]: Configuration file > /run/systemd/system/netplan-ovs-cleanup.service is marked world-inaccessible. > This has no effect as configuration data is accessible via APIs without > restrictions. Proceeding anyway. > Jul 16 22:32:24 localhost systemd[1]: netplan-ovs-cleanup.service - > OpenVSwitch configuration for cleanup was skipped because of an unmet > condition check (ConditionFileIsExecutable=/usr/bin/ovs-vsctl). > Jul 16 22:32:26 localhost systemd-networkd[280]: enp0s2: Configuring with > /run/systemd/network/10-netplan-all-en.network. > > The warning regarding netplan-ovs-cleanup.service should probably be > addressed, but that's something different. > > Can you share complete logs? What version of the image are you using? This shows up when toying with the `netplan` command, e.g.: kibi@pirogue-admin:~$ sudo netplan get all ** (process:9739): WARNING **: 23:40:29.398: Permissions for /etc/netplan/90-default.yaml are too open. Netplan configuration should NOT be accessible by others. There's nothing secret in the default configuration for cloud images but since that might contain secrets (e.g. WPA passphrases), Netplan complains. Seen with at least: - debian-12-nocloud-amd64-daily-20240703-1797.qcow2 - debian-sid-nocloud-amd64-daily-20240714-1808.qcow2 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
Tj (2024-07-13): > After reverting the recent sysfb commits: > > linux$ git l -n 15 > e932a4281dfd4 2024-07-13 17:27:49 +0100 N Tj Revert "firmware/sysfb: Set > firmware-framebuffer parent device" > c16bbb2e6863d 2024-07-13 17:27:49 +0100 N Tj Revert "firmware/sysfb: Create > firmware device only for enabled PCI devices" > a0e9d42816f8b 2024-07-13 17:27:49 +0100 N Tj Revert "firmware/sysfb: Update > screen_info for relocated EFI framebuffers" > ccadd360898d6 2024-07-13 17:27:48 +0100 N Tj Revert "firmware/sysfb: fix an > error code in sysfb_init()" > 10b1da91d6e42 2024-07-13 17:27:48 +0100 N Tj Revert "firmware: sysfb: Fix > reference count of sysfb parent device" > 4b3921872d1e1 2024-07-12 09:20:11 +0100 N Tj defconfig: x86 debian+tj clang > 02b5bfe1d3d5a 2024-07-12 09:20:11 +0100 N Tj defconfigs: add x86 > debian+tj_defconfig > 137efe9707741 2024-07-12 09:20:11 +0100 N Tj ath: add module_param > country_default for regulatory domain control > 8f630feb117a2 2024-07-12 09:20:11 +0100 N Tj cfg80211: suppress regdom > warning when phy not ready > 0ebc0f862b706 2024-07-12 09:20:10 +0100 N Tj debian: call > linux-update-symlinks from postinst > 4e2330e67f16f 2024-07-12 09:20:10 +0100 N Tj debian: no -dbg package using > KDEB_NO_DBG=1 > 45970aeccdb2a 2024-07-12 09:20:10 +0100 N Tj firmware: report each loaded > firmware file > 28fdf45184830 2024-07-11 12:51:24 +0200 N Greg Kroah-Hartman Linux 6.9.9 > > This confirms those commits are the cause of the issue; here we have > the same successful result as with v6.8.12 With my d-i hat: thanks for the awesome investigative work! (And for forwarding this to the LKML.) While my usual QEMU-based testing wasn't directly impacted by it, I've just hit this issue in a different environment, and it's nice to know something's already in the works! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076199: www.debian.org: Webpage Debian-Installer add riscv64 other images link
Colin Watson (2024-07-12): > I suspect this is mostly because debian-installer riscv64 support hasn't > been uploaded to unstable yet, so it isn't on > https://deb.debian.org/debian/dists/testing/main/installer-riscv64/ or > https://deb.debian.org/debian/dists/unstable/main/installer-riscv64/. > I'm not sure what the plan for that is; somebody on debian-boot@ > probably knows. > > Once that's done, riscv64 will need to be added to the > devel-images-arches tag (and I suppose also trixie-images-arches) in > webwml:english/template/debian/installer.wml. That'll get sorted out when a release is published, but thanks for mentioning it. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1076099: debian-installer: LVM's activation broken for volumes with the dm-integrity feature
Hi Franco,
Franco (2024-07-10):
> In a VirtualBox virtual machine I've converted a LVM volume with the
> following options:
>
> ~# lvconvert --raidintegrity y --raidintegritymode bitmap ...
>
> When I boot in rescue-mode that machine using the
> "debian-12.5.0-amd64-DVD-1.iso" iso, I follow all configuration steps
> until D-I asks me which device I want to mount as root filesystem (for
> running a shell into), then it happens that the volume is shown but if
> selected an error message it appears on the screen (red) that it says:
>
> ---
> No such device
> The device you entered for your root file system (/dev/vg0/lv1) does not
> exist. Please try again
> ---
>
> Then I choose to run a shell without mount a root filesystem and I try to
> manually activate the LVM's volume, but it fails with this error message:
>
> ~# vgchange -a y vg0
> modprobe: FATAL: Module dm-integrity not found in directory
> /lib/modules/6.1.0-18-amd64
> /sbin/modprobe failed: 1
> Can't process LV vg0/lv1_rimage_0: integrity target support missing from
> kernel?
> 0 logical volume(s) in volume group "vg0" now active
>
> The kernel version of D-I is:
>
> ~# uname -a
> Linux bw12 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
> x86_64 GNU/Linux
>
> I suggest to add "dm-integrity" module to kernel image enabling the
> configuration entry CONFIG_DM_INTEGRITY=m and possibly add the
> "dm-integrity" module's name to /etc/initramfs-tools/modules file in
> order to automatically activate at boot time the LVM volumes with the
> integrity feature enabled.
The first bit has been here for a very long while (linux 4.17.3-1,
back in 2018), but we would need dm-integrity to be added to linux's
debian/installer/modules/md-modules for that to become available in
the installer.
Cc-ing the kernel team for the time being, I have no clue whether it
makes sense to have that included for everyone, or if that's solving
a corner case (as far as I understand it you enabled a feature that's
not turned on by default). {Making,Keeping} rescue mode {more,} useful
is a worthy goal but it's really not meant to compete with a dedicated
rescue-oriented image (or even general-purpose images like live ones).
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
Tj (2024-07-04): > Focusing on just 6.8.12-1 and 6.9.7-1 I cannot see any difference in the > ISO builds. That is, for both: > > * linux-image-*-amd64 does include drivers/gpu/drm/qxl/qxl.ko* > * fb-modules-*-amd64-di.udeb does not > * kernel-image-*-amd64-di does not > * d-i Makefile's DRM_MODULES has/does not list/copy qxl.ko The part I fixed yesterday only covers compressed modules that are listed there, so that's indeed a no-op for qxl. It just seems to me that, at least with qemu packages currently found in Debian 12, earlier versions of the installer (based on 6.8.y) didn't need that particular module to get X up and running, while newer versions of the installer (based on 6.9.y) do. At least based on two spot checks: one with the earliest version available, one with last night's. You can play with netboot/gtk/mini.iso under the following directory: https://d-i.debian.org/daily-images/amd64/ (Timestamped directories, time-limited, ~15 days.) The 20240619-00:13 one boots X under -vga qxl just fine, but you might want to double check its logs (X tries to autoload qxl but finds it missing). > I went on to analyse the ISO package content diff using the attached > awk script. It strips out packages where the only difference is the > version embedded in the package name. The resulting list does not > appear to show anything that would control inclusion of the qxl > modulei although it does seem to indicate a lot of churn: The timestamped directories mentioned above include manifests which makes it easy to diff things. Since all you care about is the very beginning of the installation process, you don't have to worry about kernel modules mismatch between the kernel d-i was built against and what's in the archive at runtime, so I'd suggest concentrating on netboot/gtk/mini.iso, that should make it easier to pinpoint when the change exactly happened (than going through probably much less frequent debian-cd-provided netinst images). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1075713: linux: ISO missing qxl.ko.xz kernel module
Hi, Tj (2024-07-03): > Source: linux > Followup-For: Bug #1075713 > X-Debbugs-Cc: tj.iam...@proton.me debian-b...@lists.debian.org > > I've inspected the arch-latest amd64 ISO from: > > https://get.debian.org/images/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso > > It is missing drivers/gpu/drm/qxl/qxl.ko.xz kernel module. > > We need to review the ISO build log(s) and the Debian Image scripts but > I've been unable to track them down. > > I also noticed that in > > /usr/lib/modules/6.9.7-amd64/kernel/drivers/gpu/drm/ > > all 6 modules there are named *.ko > > but the other 818 modules in the installer image are *.ko.xz > > This may be a clue! Right, it looks like a fumble on my part in the following commit: https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea I'm picking up compressed modules but shipping them without the suffix… and that's not an issue with src:linux. https://salsa.debian.org/installer-team/debian-installer/-/commit/042be38d65ae906574d03ef07be20cbd865fddc6 Still need to find time to actually debug the original issue, but that's another story entirely. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1075718: libvirt-clients: virsh domif-setlink fails to update state
Control: tag -1 patch upstream Cyril Brulebois (2024-07-03): > The same happens with both 'up' and 'down', with or without --interface > and --state, and really looks like some basic logic bug somewhere in the > XML update code? (I haven't looked at the implementation just yet.) There's an upstream fix published between 9.0.0 and 9.1.0: https://gitlab.com/libvirt/libvirt/-/commit/6f3f6c0f763b9ffd8ef93eb124c88dd0b79138fc I've verified it does the trick when added on top of the debian/bookworm branch, and built for bookworm. I've just created an MR for that: https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/224 and I'm also attaching the source debdiff. It'd be nice to include this bugfix alongside the next set of security/stability fixes, should such an upload be needed. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant --- libvirt-9.0.0/debian/patches/backport/virsh-Make-domif-setlink-work-more-than-once.patch 1970-01-01 01:00:00.0 +0100 +++ libvirt-9.0.0/debian/patches/backport/virsh-Make-domif-setlink-work-more-than-once.patch 2024-07-03 18:21:49.0 +0200 @@ -0,0 +1,43 @@ +From: Michal Privoznik +Date: Mon, 30 Jan 2023 10:55:22 +0100 +Subject: virsh: Make domif-setlink work more than once + +In virsh, we have this convenient domif-setlink command, which is +just a wrapper over virDomainUpdateDeviceFlags() and which allows +setting link state of given guest NIC. It does so by fetching +corresponding XML snippet and either putting into it, OR if the element already exists setting the +attribute to desired value. The XML is then fed into the update +API. + +There's, however, a small bug in detecting the pre-existence of +the element and its attribute. The code looks at "link" +attribute, while in fact, the attribute is called "state". + +Resolves: https://gitlab.com/libvirt/libvirt/-/issues/426 +Fixes: e575bf082ed4889280be07c986375f1ca15bb7ee +Signed-off-by: Michal Privoznik +Reviewed-by: Ján Tomko + +Forwarded: non-needed +Origin: https://gitlab.com/libvirt/libvirt/-/commit/6f3f6c0f763b9ffd8ef93eb124c88dd0b79138fc +--- + tools/virsh-domain.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c +index 6b431bd1e5..59b2b3ce60 100644 +--- a/tools/virsh-domain.c b/tools/virsh-domain.c +@@ -3209,7 +3209,7 @@ cmdDomIfSetLink(vshControl *ctl, const vshCmd *cmd) + } + } + +-if (xmlHasProp(linkNode, BAD_CAST "link")) ++if (xmlHasProp(linkNode, BAD_CAST "state")) + stateAttr = xmlSetProp(linkNode, BAD_CAST "state", BAD_CAST state); + else + stateAttr = xmlNewProp(linkNode, BAD_CAST "state", BAD_CAST state); +-- +2.39.2 + --- libvirt-9.0.0/debian/patches/series 2023-05-21 11:31:31.0 +0200 +++ libvirt-9.0.0/debian/patches/series 2024-07-03 18:22:22.0 +0200 @@ -10,6 +10,7 @@ backport/rpc-Don-t-warn-about-max_client_requests-in-single-thread.patch backport/conf-Fix-migration-in-some-firmware-autoselection-scenari.patch backport/virpci-Resolve-leak-in-virPCIVirtualFunctionList-cleanup.patch +backport/virsh-Make-domif-setlink-work-more-than-once.patch forward/Skip-vircgrouptest.patch forward/Reduce-udevadm-settle-timeout-to-10-seconds.patch forward/Pass-GPG_TTY-env-var-to-the-ssh-binary.patch signature.asc Description: PGP signature
Bug#1075718: libvirt-clients: virsh domif-setlink fails to update state
Package: libvirt-clients Version: 9.0.0-4 Severity: normal Hi, Working on some network-oriented tools (https://pts-project.org/), I ended up wanting to down/up some network links from the virtualization host (running libvirt, with the QEMU backend). The first step worked just fine, the second step will surprise you: virsh # domif-setlink ViRogue --interface 52:54:00:03:73:13 --state down Device updated successfully virsh # domif-setlink ViRogue --interface 52:54:00:03:73:13 --state up error: Failed to update interface link state error: (device_definition):6: Attribute state redefined ---^ The same happens with both 'up' and 'down', with or without --interface and --state, and really looks like some basic logic bug somewhere in the XML update code? (I haven't looked at the implementation just yet.) That used to work fine but I couldn't say for sure which version(s) (as I've run Debian 9 and Debian 11 previously, but with some backports); at the time, I used that quite heavily to test bonding on virtualized images with a lot of interfaces, without any such obvious issues. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-22-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 libvirt-clients depends on: ii libc6 2.36-9+deb12u7 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-2+deb12u3 ii libgnutls30 3.7.9-2+deb12u3 ii libreadline88.2-1.3 ii libvirt09.0.0-4 ii libxml2 2.9.14+dfsg-1.3~deb12u1 ii sensible-utils 0.0.17+nmu1 libvirt-clients recommends no packages. Versions of packages libvirt-clients suggests: pn libvirt-clients-qemu ii libvirt-daemon9.0.0-4 pn libvirt-login-shell -- no debconf information
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Cyril Brulebois (2024-06-21): > Rick Thomas (2024-06-20): > > No sweat -- just point me at the image and let me know anything > > special I should be looking out for. > > Pushed pu/openrd, the main part is: > > https://salsa.debian.org/installer-team/debian-installer/-/commit/8e1ba33e175615082b4dfeb6b554ca1ec7669f7d > > Built on amdahl, resulting images tarball published similarly to what > we did last time for bullseye: > https://people.debian.org/~kibi/openrd4bookworm/ > > If positive test results are obtained before the end of the week, that > can be considered for inclusion into 12.6. Thanks already! Timeout; next target is 12.7. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Hi, Rick Thomas (2024-06-20): > No sweat -- just point me at the image and let me know anything > special I should be looking out for. Pushed pu/openrd, the main part is: https://salsa.debian.org/installer-team/debian-installer/-/commit/8e1ba33e175615082b4dfeb6b554ca1ec7669f7d Built on amdahl, resulting images tarball published similarly to what we did last time for bullseye: https://people.debian.org/~kibi/openrd4bookworm/ If positive test results are obtained before the end of the week, that can be considered for inclusion into 12.6. Thanks already! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1064299: console-setup: move files to /usr (DEP17)
Hi, Helmut Grohne (2024-06-20): > My fault. Not sure how I ended up with that version. I normally use > dch --nmu and it would have done the right thing here. OK. And yeah, that's known/verified to work with native packages too. > > NMU canceled, MU re-uploaded (matching what's been pushed to git > > earlier). > > Unfortunately, your MU missed the requested changes. Well, sure, my focus was on an RC bugfix. > Would you prefer me redoing the NMU (correctly versioned) or uploading > it yourself? Ideally someone from debian-boot@ would review/merge/upload those changes but since that hasn't happened yet, I suppose a NMU would work. xkeyboard-config's autopkgtest situation doesn't look like it's going to be a speedy migration to testing, so I'm not sure you need to wait for 1.228 to migrate to testing; going to DELAYED route again might be nice though, to have a chance for those to migrate to testing first, before adding DEP-17 changes on top of them? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1064299: console-setup: move files to /usr (DEP17)
Helmut Grohne (2024-06-12): > I've uploaded a slightly rebased version of the patch to DELAYED/10. Let > me know if I should delay any longer. > > Helmut > diff -Nru console-setup-1.227/CHANGES console-setup-1.228/CHANGES > --- console-setup-1.227/CHANGES 2024-05-30 10:54:36.0 +0200 > +++ console-setup-1.228/CHANGES 2024-02-18 13:51:52.0 +0100 > @@ -1,3 +1,10 @@ > +console-setup (1.228) unstable; urgency=medium > + > + * Non-maintainer upload. > + * DEP17: Move aliased files to /usr. (Closes: #1064299) > + > + -- Helmut Grohne Sun, 18 Feb 2024 13:51:52 +0100 Err, this is not how NMUs are versioned, and the package sitting in DELAYED led to my RC bugfix's getting trashed. NMU canceled, MU re-uploaded (matching what's been pushed to git earlier). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Martin Michlmayr (2024-06-20): > I asked Vagrant for help a few days ago but haven't heard back. I > don't have an armel build environment. > > I'll ping him again. If memory serves, last time I did build stuff on a porter box to make sure the generated images could be verified as working. I can do the former once again, but for the latter I need someone with hardware. (amdahl can be used for that.) We're nowhere Bookworm's EOL so if that can't be checked in time for next week's point release, that can wait until the next one. For the record, d-i is usually uploaded the day following the p-u freeze (i.e. Monday). And we have a double point release, so messing with the usual upload timings is definitely not something I would willingly consider. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Cyril Brulebois (2024-06-16): > If I can get a confirmation a tentative build is working properly, that > could be envisioned. If there are no volunteers though, I won't even try. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1073857: keyboard-configuration: fails to install with xkb-data dependency conflict
Control: severity -1 serious Hi Christian, Christian Stewart (2024-06-19): > Package: keyboard-configuration > Severity: important It's even one step higher. ;) > keyboard-configuration depends on xkb-data < 2.41A but only 2.42-1 is > available in the Debian Sid sources. Thanks for the bug report, just uploaded a package with a few changes that had been staged already, which will pick up updated dependencies when it gets built within unstable: Depends: debconf (>= 0.5) | debconf-2.0, liblocale-gettext-perl, xkb-data (>= 2.42~), xkb-data (<< 2.42A) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1073805: ITS: xdm
Boyuan Yang (2024-06-18): > If I remember correctly, kibi@ said their X-related packages is no > longer being worked on. https://lists.debian.org/debian-x/2013/10/msg00292.html Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1073624: crowdsec-firewall-bouncer: move aliased files from / to /usr (DEP17)
Hi, Helmut Grohne (2024-06-18): > Package: crowdsec-firewall-bouncer > Version: 0.0.25-4 > Severity: important > Tags: patch trixie sid > User: helm...@debian.org > Usertags: dep17m2 dep17dhmovetousr > > This package is part of the /usr-move (DEP17) transition, because it > contains files in aliased locations and should have those files moved to > the corresponding /usr location. The goal of this move is eliminating > bugs arising from aliasing, such as file loss during package upgrades. I think I've mentioned that on an existing bug report but anyway: preps for an RC bugfix in testing/unstable + backport to stable are almost over, and I really want that to get out of the way before considering merging DEP17 things. Even more so if that complicates backporting. That's applicable for all three crowdsec* packages. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Martin Michlmayr (2024-06-13): > * Martin Michlmayr [2024-04-13 14:37]: > > Yes, imho let's add the image for bookworm and let this be the end > > of it. ;) > > I read about the upcoming 12.6. Kibi, what do you think about adding > back the OpenRT images one last time? If I can get a confirmation a tentative build is working properly, that could be envisioned. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1072984: bookworm-pu: package crowdsec-firewall-bouncer/0.0.25-4~deb12u1
Hi Adam, Adam D. Barratt (2024-06-15): > Please go ahead. Thanks, uploaded. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1072983: bookworm-pu: package golang-github-google-nftables/0.1.0-4~deb12u1
Hi Adam, Adam D. Barratt (2024-06-15): > Please go ahead. Thanks, uploaded. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1072984: bookworm-pu: package crowdsec-firewall-bouncer/0.0.25-4~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: crowdsec-firewall-boun...@packages.debian.org Control: affects -1 + src:crowdsec-firewall-bouncer Hi, [ Reason ] I'd like to fix the #1071247/#1071248 pair in bookworm, which results in crowdsec-firewall-bouncer's being broken on little-endian architectures (addresses are getting logged just fine, but they're not passed over correctly to the firewall layer). I've checked with the security team, this doesn't warrant a DSA. This is the daemon part (crowdsec-firewall-bouncer). [ Impact ] If the fix doesn't make it into stable, crowdsec-firewall-bouncer remains broken on little-endian architectures. [ Tests ] Same checks as for unstable when I uploaded the fixes there: - amd64 (LE, baremetal) before: KO - amd64 (LE, baremetal) after: OK - s390x (BE, debvm) before: OK - s390x (BE, debvm) after: OK [ Risks ] Except for a possible regression on s390x (which isn't the case, see previous section), it cannot be worse than it currently is. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable Additionally, that reached testing. [ Changes ] Since there were already binNMUs for this package in p-u, with different versions, I decided to err on the side of caution, and to propose a new revision with a versioned build-dep on golang-github-google-nftables's binary package; alternatively this package could be binNMU'd within p-u once golang-github-google-nftables is available in p-u. [ Other info ] Previous bug report is the golang-github-google-nftables part. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/changelog crowdsec-firewall-bouncer-0.0.25/debian/changelog --- crowdsec-firewall-bouncer-0.0.25/debian/changelog 2023-05-31 18:57:41.0 +0200 +++ crowdsec-firewall-bouncer-0.0.25/debian/changelog 2024-06-11 10:20:58.0 +0200 @@ -1,3 +1,18 @@ +crowdsec-firewall-bouncer (0.0.25-4~deb12u1) bookworm; urgency=medium + + * Rebuild for bookworm. + + -- Cyril Brulebois Tue, 11 Jun 2024 10:20:58 +0200 + +crowdsec-firewall-bouncer (0.0.25-4) unstable; urgency=high + + * Set minimal version for the golang-github-google-nftables-dev build +dependency to ensure a working AddSet() function, i.e. no longer +reversing byte order for IPv4 and IPv6 addresses at the nftables level +on little-endian architectures (Closes: #1071248, See: #1071247). + + -- Cyril Brulebois Tue, 21 May 2024 10:15:36 +0200 + crowdsec-firewall-bouncer (0.0.25-3) unstable; urgency=medium * Fix failure to install if crowdsec is unpacked but not configured diff -Nru crowdsec-firewall-bouncer-0.0.25/debian/control crowdsec-firewall-bouncer-0.0.25/debian/control --- crowdsec-firewall-bouncer-0.0.25/debian/control 2023-03-21 01:03:29.0 +0100 +++ crowdsec-firewall-bouncer-0.0.25/debian/control 2024-05-21 09:53:53.0 +0200 @@ -10,7 +10,7 @@ golang-github-coreos-go-systemd-dev, golang-github-crowdsecurity-crowdsec-dev, golang-github-crowdsecurity-go-cs-bouncer-dev, - golang-github-google-nftables-dev, + golang-github-google-nftables-dev (>= 0.1.0-4~), golang-golang-x-sys-dev, golang-gopkg-natefinch-lumberjack.v2-dev, golang-gopkg-tomb.v2-dev,
Bug#1072983: bookworm-pu: package golang-github-google-nftables/0.1.0-4~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-google-nftab...@packages.debian.org
Control: affects -1 + src:golang-github-google-nftables
Hi,
[ Reason ]
I'd like to fix the #1071247/#1071248 pair in bookworm, which results in
crowdsec-firewall-bouncer's being broken on little-endian architectures
(addresses are getting logged just fine, but they're not passed over
correctly to the firewall layer).
I've checked with the security team, this doesn't warrant a DSA.
This is the library part (golang-github-google-nftables).
[ Impact ]
If the fix doesn't make it into stable, crowdsec-firewall-bouncer
remains broken on little-endian architectures.
[ Tests ]
Same checks as for unstable when I uploaded the fixes there:
- amd64 (LE, baremetal) before: KO
- amd64 (LE, baremetal) after: OK
- s390x (BE, debvm) before: OK
- s390x (BE, debvm) after: OK
[ Risks ]
Except for a possible regression on s390x (which isn't the case, see
previous section), it cannot be worse than it currently is.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
Additionally, that reached testing.
[ Changes ]
The fix is a direct backport from upstream, which adds byte order
information to the function used by crowdsec-firewall-bouncer
(AddSet).
[ Other info ]
Next bug report is the crowdsec-firewall-bouncer part.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff -Nru golang-github-google-nftables-0.1.0/debian/changelog
golang-github-google-nftables-0.1.0/debian/changelog
--- golang-github-google-nftables-0.1.0/debian/changelog2022-12-12
05:07:14.0 +0100
+++ golang-github-google-nftables-0.1.0/debian/changelog2024-06-11
10:22:28.0 +0200
@@ -1,3 +1,18 @@
+golang-github-google-nftables (0.1.0-4~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm.
+
+ -- Cyril Brulebois Tue, 11 Jun 2024 10:22:28 +0200
+
+golang-github-google-nftables (0.1.0-4) unstable; urgency=high
+
+ * Backport upstream fix for the AddSet() function that's been reversing
+byte order on all little-endian architectures (Closes: #1071247),
+breaking crowdsec-firewall-bouncer (See: #1071248):
+ - 0002-Implement-set-KeyByteOrder-226.patch
+
+ -- Cyril Brulebois Tue, 21 May 2024 09:42:17 +0200
+
golang-github-google-nftables (0.1.0-3) unstable; urgency=medium
* Backport fix from upstream to fix the test suite on 32-bit archs (the
diff -Nru
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
---
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
1970-01-01 01:00:00.0 +0100
+++
golang-github-google-nftables-0.1.0/debian/patches/0002-Implement-set-KeyByteOrder-226.patch
2024-05-15 13:08:54.0 +0200
@@ -0,0 +1,42 @@
+From d746ecb0e494e7200180c3886fde9664d9100729 Mon Sep 17 00:00:00 2001
+From: turekt <32360115+tur...@users.noreply.github.com>
+Date: Thu, 18 May 2023 18:05:49 +0200
+Subject: [PATCH] Implement set KeyByteOrder (#226)
+
+Fixes https://github.com/google/nftables/issues/225
+Introduced KeyByteOrder in sets which fills UDATA with endianess information
+---
+ set.go | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/set.go b/set.go
+index 1ef8e89..b1f63e8 100644
+--- a/set.go
b/set.go
+@@ -261,6 +261,9 @@ type Set struct {
+ Timeout time.Duration
+ KeyType SetDatatype
+ DataType SetDatatype
++ // Either host (binaryutil.NativeEndian) or big (binaryutil.BigEndian)
endian as per
++ //
https://git.netfilter.org/nftables/tree/include/datatype.h?id=d486c9e626405e829221b82d738005b26d8a#n109
++ KeyByteOrder binaryutil.ByteOrder
+ }
+
+ // SetElement represents a data point within a set.
+@@ -560,11 +563,11 @@ func (cc *Conn) AddSet(s *Set, vals []SetElement) error {
+ // Marshal concat size description as set description
+ tableInfo = append(tableInfo, netlink.Attribute{Type:
unix.NLA_F_NESTED | unix.NFTA_SET_DESC, Data: concatBytes})
+ }
+- if s.Anonymous || s.Constant || s.Interval {
++ if s.Anonymous || s.Constant || s.Interval || s.KeyByteOrder ==
binaryutil.BigEndian {
+ tableInfo = append(tableInfo,
+ // Semantically useless - kept for binary compatability
with nft
+ netlink.Attribute{Type: unix.NFTA_SET_USERDATA, Data:
[]byte("\x00\x04\x02\x00\x00\x00")})
+- } else if !s.IsMap {
++ } else if s.KeyByteOrder ==
Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr
Chris Hofstaedtler (2024-05-30): > Yes, having migrated enough packages I (we) believe this is safe. > > Please land this in trixie before the transition freeze. Please let me get the security fixes out of the way and I'll look into those issues afterwards. Feel free to ping back in a week or two if that hasn't happened by then (I don't control answer delays from either security or release teams). Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1072501: ITP: systemd-boot-installer -- Install systemd-boot on a hard disk
Hi, Luca Boccassi (2024-06-03): > Package: wnpp > Severity: wishlist > Owner: Luca Boccassi > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: systemd-boot-installer > Version : 0.1 > Upstream Author : Luca Boccassi > * URL : > https://salsa.debian.org/installer-team/systemd-boot-installer > * License : GPL-2.0-or-later > Programming Lang: shell > Description : debian-installer component to install systemd-boot > as the bootloader Could we have some kind of heads-up via X-D-Cc to debian-boot@ for such things, please? Discovering we have a new package under our namespace via a “Processing” mail from ftpmaster is awkward. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1017542: systemd-cryptsetup@vda5_crypt.service: Control process exited, code=exited, status=1/FAILURE
Luca Boccassi (2024-05-27): > I'll upload a D-I fix that adds x-initrd.attach to crypttab by default > shortly. Yes you can ignore the "unknown option" message, as the > Debian-specific initramfs-tools scripts do not know about it, but > that's fine, it's for the shutdown path anyway. And the finalize > messages can also be ignored. Having a cryptsetup warning about an unknown option on the very first line seen by users after the bootloader step doesn't feel appropriate at all to me. Telling users to just ignore it neither. For the record, on a fresh install, that means: cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'x-initrd.attach' Please unlock disk sda5_crypt: _ Looping in the cryptsetup team. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work
Hoi, Roland Clobus (2024-05-25): > Source: hw-detect > Version: 1.160 > Severity: normal > Tags: patch d-i Just to confirm, which linux version was this tested against? > I have an USB wireless adapter that uses the r8712u kernel module and > that requires firmware from non-free-firmware. > > When I run the Debian installer, the missing firmware file is > correctly identified and installed by 'check-missing-firmware.sh'. > However, the kernel module is mis-identified as 'usb'. As you found out, having 'usb' is rather widespread, hence the existence of the function you patched. What seems weird to my (not at all expert in the kernel area) eyes is the unbound thing that led you to introduce that special case. I see that's a module from staging, maybe it's not behaving like it should? At least differently from other modules… I spotted 1422b526fba994cf05fd288a152106563b875fce that fixed a race condition regarding firmware loading (fix available in v6.6-rc1 and v6.1.52), maybe there are other similar issues? > When I disconnect the adapter and reconnect it, the installer is able > to use the adapter properly. > > Attached is a patch that allows the module to be identified correctly. > If desired, I can send the patch instead as a merge request on Salsa. > > However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not sufficient > to enable the adapter, it still needs a physical reconnect. > In the attached screenshot from the installer (sid) the result of the patch > is shown. Also in the QEMU environment, I need to disconnect and reconnect > the USB device from the host. > > I tried several options, but could not get them to work: bind/unbind [1] > authorized, usbreset [2] > Do you know a solution (apart from a physical reconnect)? I'd suggest a search in upstream bugzilla and mailing lists. I'm adding the kernel maintainers in copy, in case they have better ideas. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071873: debian-installer: FTBFS: unsatisfiable build-dependencies
Control: tag -1 patch Santiago Vila (2024-05-25): > Package: src:debian-installer > Version: 20230607+deb12u5 > Severity: serious > Tags: ftbfs master is fine. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071574: bookworm-pu: package netcfg/1.187+deb12u1
Hi Colin, Colin Watson (2024-05-21): > I've just fixed this in unstable, but it would be helpful to have it > in place for installs of bookworm too. ACK on principle; you'll want a dch -r though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Cyril Brulebois (2024-05-17): > I was tempted to open a second bug on crowdsec-firewall-bouncer, > referencing this one, and to upload both packages to unstable (this one > with the upstream patch, the other one with a bumped build-dep to make > sure it cannot be rebuilt against the broken package; there are a lot of > binNMUs flying around already). Then to submit p-u requests to get the > same updates into bookworm. But does that issue warrant a DSA? The crowdsec-firewall-bouncer bug is #1071248. The only other reverse dependency is opensnitch (maintainers Cc'd) but it doesn't seem to use the AddSet() function (in any versions/suites). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071248: crowdsec-firewall-bouncer: blocks wrong IPv4 and IPv6 addresses on LE systems (reversed byte order)
Package: crowdsec-firewall-bouncer Version: 0.0.25-3 Severity: grave Tags: patch security Justification: renders package unusable X-Debbugs-Cc: Debian Security Team , debian.pack...@crowdsec.net Hi, This is the bouncer side of #1071247: golang-github-google-nftables up to version 0.1.0-3 ships a broken AddSet() function, which results in IPv4 and IPv6 addresses to be in reverse byte order at the nftables level on LE systems (i.e. all release architectures but s930x). This issue was confirmed to go away on LE systems once the bouncer gets rebuilt against a fixed golang-github-google-nftables-dev package, and not to regress on BE systems. Grave looks warranted as the package doesn't fulfill its purposes (blocking suspicious addresses), giving a false sense of security… while also blocking potentially harmless addresses. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Control: found -1 0.1.0-3 Control: notfound -1 0.1.0-4 Cyril Brulebois (2024-05-17): > Package: golang-github-google-nftables-dev > Version: 0.1.0-4 > I also verified that applying the golang-github-google-nftables patch > and rebuilding crowdsec-firewall-bouncer against it fixes the problem > on LE systems, and doesn't regress on BE systems. Sorry for the version discrepancy; reportbug warned me but I lost track while thinking about a possible DSA, etc. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1071247: golang-github-google-nftables-dev: broken AddSet() on all little-endian systems
Package: golang-github-google-nftables-dev Version: 0.1.0-4 Severity: serious Tags: upstream security patch Justification: broken feature, security implications X-Debbugs-Cc: Debian Security Team , debian.pack...@crowdsec.net Hi, I was contacted by CrowdSec upstream about a bug report filed against the firewall bouncer, which is in charge of applying rules at the firewall level based on decisions passed on by the crowdsec engine: https://github.com/crowdsecurity/cs-firewall-bouncer/issues/368 I've been able to verify that despite correct IPv4 and IPv6 addresses getting logged by the bouncer (e.g. at debug level), all of them get added in reverse byte order at the nftables level. :( Upstream bug: https://github.com/google/nftables/issues/225 Upstream fix: https://github.com/google/nftables/pull/226 I confirmed that affects LE systems (e.g. amd64), both in stable and in unstable (same versions, modulo binNMUs). That doesn't affect BE systems (i.e. s390x, verified via debvm). I also verified that applying the golang-github-google-nftables patch and rebuilding crowdsec-firewall-bouncer against it fixes the problem on LE systems, and doesn't regress on BE systems. Security team, I've added the security tag (and you to Cc) because the consequence is that admins who installed crowdsec-firewall-bouncer have been thinking they were applying restrictions gathered by crowdsec, while they've actually been (1) not blocking offending addresses and (2) blocking possibly harmless ones. I was tempted to open a second bug on crowdsec-firewall-bouncer, referencing this one, and to upload both packages to unstable (this one with the upstream patch, the other one with a bumped build-dep to make sure it cannot be rebuilt against the broken package; there are a lot of binNMUs flying around already). Then to submit p-u requests to get the same updates into bookworm. But does that issue warrant a DSA? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1070877: debian-installer: xfsprogs not available in the installer, but xfs fs type available, mkfs fails
Hi Witold, And thanks for your report. Witold Baryluk (2024-05-11): > Which is weird, because xfsprogs-udev is there. > > No issues with btrfs, ext2-4, fat, jfs. They are available by default. This is #1070795. Such bug reports would ideally be filed with: X-Debbugs-Cc: debian-b...@lists.debian.org Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1070767: bug report install partman-crypto
Hi, Edson Wolf (2024-05-08): > The package partman-crypto which apparently expects libgcc_s.so.1 to be an > installed library in the installer but lacks dependency to ensure that. It doesn't need to, debian-installer's build/Makefile ensures it's there. > Specifically, it does depend on libc6-udeb rather than libc6 with the > significant difference that it lacks the dependency on libgcc_s.so.1. The > partman-crypto developer(s) need to decide how to handle that. > ralph.ronnquist > > Attached images I'm not seeing anything related to libgcc_s.so.1 in those images. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Hi Simon, Simon McVittie (2024-05-07): > Looking at the d-i Packages.gz for amd64, the only other source > package that has picked up the bad libpng16-16t64-udeb dependency > seems to be matchbox-keyboard, which needs a sourceful upload to fix an > implicit-declarations FTBFS anyway, therefore isn't useful to binNMU. Yeah, I forgot to mention it when I worked on making d-i buildable and runnable again, then decided it didn't matter as it's not used (TTBOMK) at the moment. > After that: do the release/installer teams consider udeb dependencies > on non-udeb packages, by udebs that d-i does not currently need or use, > to be a RC issue or merely a nice-to-have? If udebs are actually used, I call that an RC bug and try to get it fixed swiftly (sometimes NMUing right away when time is of the essence). Otherwise I usually let those fly (without even filing bug reports). See: https://d-i.debian.org/dose/ Some backstory: https://lists.debian.org/debian-boot/2024/03/msg00102.html Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068755: docker.io: FTBFS: failing tests
Hi Santiago, And thanks for the report. Santiago Vila (2024-04-10): > Package: src:docker.io > Version: 20.10.25+dfsg1-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: > > === FAIL: distribution/xfer > TestMaxDownloadAttempts/max-attempts=5,_fail_at_6th_attempt (0.88s) > time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (2/5): > simulating download attempt 2/2" > time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (1/5): > simulating download attempt 1/6" > download_test.go:425: assertion failed: expected error "simulating > download attempt 5/6", got "simulating download attempt 6/6" > time="2024-04-10T10:28:42Z" level=info msg="Download failed, retrying (5/5): > simulating download attempt 5/5" > > === FAIL: distribution/xfer TestMaxDownloadAttempts (0.00s) That FTBFS is easily reproducible via cowbuilder (sid, amd64), and also within an unclean, up-to-date devel schroot (still sid, amd64). I'm adding Tianon to the loop explicitly since I'm definitely no Docker (or Go) expert, in case some time can be spared to look into this problem. Otherwise I'll try and come up with something. Thanks for considering! Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required
Luca Boccassi (2024-05-06): > Pending at: > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8 I'm not sure how often we change template types, but I suppose this particular instance (error → boolean) makes sense and isn't problematic. Please mention “GRUB” (instead of “grub”) for consistency with upstream and the rest of d-i though. (I know this is very minor but better catch that early to avoid another l10n round later on.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1016957: remove kbd-chooser from the archive?
Paul Gevers (2024-05-04): > If you're sure it's not used, I can work around udd and have it at least > removed from testing. I think a bug retitle (or separate bug) would have > been better. The current bug isn't RC. If it's certain that package isn't used/useful anymore, the correct thing to do is to have it removed from the archive, via unstable, sync'd into testing. I don't see what a removal from testing only would achieve, esp. for trumped-up reasons. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069964: debian-installer: Debian LXQt ISO loads all unnecessary proprietary firmware even with firmware=never parameter
Hi, Thanks for the report but wow, that's way too many topics. baptx (2024-04-27): > The following issue is based on the discussion I created on > https://forums.debian.net/viewtopic.php?t=159027 where you can find > attached the content of /var/log/installer/syslog which was generated > on a virtual machine with virt-manager when installing > debian-live-12.5.0-amd64-lxqt.iso with the firmware=never parameter > (the problem was also present on my real computer when I tested with a > previous version debian-live-12.0.0-amd64-lxqt.iso). I also attached > the result of the vrms command after using firmware=never parameter. vrms is irrelevant. > To compare, you can also find attached another installer syslog > without using firmware=never parameter, which also contains the line > "hw-detect: skipping check-missing-firmware as requested by the > caller" and looks like a bug. No, it's not. See check on CHECK_MISSING_FIRMWARE in hw-detect. > The firmware=never parameter did not work at all when using the LXQt > ISO file (maybe the problem also happens on ISO files with other > desktop environments), the non-free firmware packages were installed. That would be a bug in debian-live then, not in debian-installer. Cc-ing accordingly. > And with the LXQt ISO file, the graphical expert install as well as > the text expert install did not ask me if I want the non-free firmware > packages, they were installed automatically. > I noticed the firmware=never parameter only worked with the netinst > ISO file. Well, that's been added for use by debian-installer. What debian-live does or doesn't do with it is outside our control. > For the automatic detection of needed non-free firmware packages, it > only worked with the netinst ISO file as well (the LXQt ISO file > installed all non-free firmware packages). But even with netinst ISO > file, it seems it is only guessing the non-free firmware packages > needed since several were not needed to make my laptop work correctly > (firmware-realtek, firmware-sof-signed) when installed on my real > computer instead of a virtual machine. The lookup is based on what devices are seen during the installation process. If the relevant kernel modules list firmware files, we try to match them to firmware packages, and queue their installation. Unless firmware=never was used of course. That doesn't mean they are absolutely required for those devices to work. There is just no way to know for sure. > It would also be useful to have the firmware=never parameter added in > a menu in the normal graphical installation (for people who don't want > the complexity of the expert installation), since it is more > convenient to have it in a menu and also avoids mistakes when typing > firmware=never (I accidentally typed firmzare due to my AZERTY > keyboard and the QWERTY input). Menu maintenance (esp. across architectures, BIOS vs. UEFI, etc.) is a huge mess already, it might happen but I'm not holding my breath here. > It would be a good idea to warn the user if the entered parameter / > value does not exist, to avoid unwanted results like installing > non-free firmware. There's no absolute list to check against, so that cannot be done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Marco d'Itri (2024-04-26): > On Apr 26, Michael Tokarev wrote: > > > So, should I disable module utils in busybox-udeb now? > I think so. I haven't gotten any requests / seen any reasons to keep it; so, yes, please feel free to remove it whenever is convenient for you. > > Is kmod udeb ready and used in d-i already, or does it need some > > prep first? > AFAIK it works. Absolutely, that's been working since the small xz-utils tweak (the udeb addition, not the backdoor thing). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069099: binNMUs to fix mtdev-using udebs
Cyril Brulebois (2024-04-16): > Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) > on all archs, provided that doesn't interfere with the whole 64-bit time_t > transition: > - libinput10 That ought to read: - libinput Sorry about that. > - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1069099: binNMUs to fix mtdev-using udebs
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-b...@lists.debian.org Hi, mtdev regressed a while back, leading a few udebs to become uninstallable (initially one[1], now two). 1. https://bugs.debian.org/1066071 No response in 1+ month, the package wasn't ready to migrate anyway since it was waiting on dpkg but also regressing on 32-bit arms; I've uploaded an NMU yesterday, built everywhere. I also verified that rebuilding the following two packages gives appropriate dependencies for their udebs. Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2) on all archs, provided that doesn't interfere with the whole 64-bit time_t transition: - libinput10 - xserver-xorg-input-evdev Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1069020: release.debian.org: binNMUs to fix libpng-using udebs
Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-b...@lists.debian.org Hi, libpng1.6 regressed a while back, leading a few key udebs to become uninstallable[1]. That was fixed rather quickly[2] but binNMUs haven't happened yet. We haven't heard back from people driving the 64-bit time_t transition either, it's been a while, so I'm contacting you to see if you could arrange some binNMUs, without disrupting their work. 1. https://bugs.debian.org/1066069 2. https://tracker.debian.org/news/1515481/accepted-libpng16-1643-4-source-into-unstable/ Please consider binNMU-ing the following source package against libpng-dev (>= 1.6.43-4): - cairo - gdk-pixbuf - freetype [armel] That's based on udeb installability checks[3], and I only verified on amd64 that both cairo and gdk-pixbuf get appropriate dependencies for their udebs when rebuilt. 3. https://d-i.debian.org/dose/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1066071: mtdev: broken shlibs, leading to uninstallable udebs
Hi, Cyril Brulebois (2024-03-12): > Your NMU broke this package's shlibs. > > Before: > > libmtdev 1 libmtdev1 > udeb: libmtdev 1 libmtdev1-udeb > > After: > > libmtdev 1 libmtdev1t64 > > At the moment, at least the following package is broken: > > The following packages have unmet dependencies: > libinput10-udeb : Depends: libmtdev1t64 but it is not installable No response in 1+ month, the package isn't ready to migrate anyway since it's waiting on dpkg but also regressing on 32-bit arms. Source debdiff attached for the NMU, which I've verified to generate appropriate shlibs, leading a rebuilt src:libinput10 to have appropriate dependencies as far as libinput10-udeb is concerned. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru mtdev-1.1.6/debian/changelog mtdev-1.1.6/debian/changelog --- mtdev-1.1.6/debian/changelog 2024-02-28 21:51:50.0 +0100 +++ mtdev-1.1.6/debian/changelog 2024-04-15 09:51:44.0 +0200 @@ -1,3 +1,12 @@ +mtdev (1.1.6-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix shlibs entry for the udeb: set DEB_DH_MAKESHLIBS_ARGS_libmtdev1t64 +instead of setting DEB_DH_MAKESHLIBS_ARGS_libmtdev1, to match the +rename of the library (Closes: #1066071). + + -- Cyril Brulebois Mon, 15 Apr 2024 09:51:44 +0200 + mtdev (1.1.6-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru mtdev-1.1.6/debian/rules mtdev-1.1.6/debian/rules --- mtdev-1.1.6/debian/rules 2020-05-24 06:38:08.0 +0200 +++ mtdev-1.1.6/debian/rules 2024-04-15 09:50:23.0 +0200 @@ -9,7 +9,7 @@ distribution := $(shell lsb_release -is) LDFLAGS += -Wl,-z,defs -Wl,--as-needed -DEB_DH_MAKESHLIBS_ARGS_libmtdev1 = --add-udeb=libmtdev1-udeb +DEB_DH_MAKESHLIBS_ARGS_libmtdev1t64 = --add-udeb=libmtdev1-udeb DEB_INSTALL_MANPAGES_mtdev-tools = debian/mtdev-test.1 signature.asc Description: PGP signature
Bug#1066479: closed by Debian FTP Masters (reply to Cyril Brulebois ) (Bug#1066479: fixed in opendnssec 1:2.1.13-1.1)
Debian Bug Tracking System (2024-03-28): > opendnssec (1:2.1.13-1.1) unstable; urgency=medium > . >* Non-maintainer upload. >* Fix FTBFS due to missing utilities.h include for the clamp declaration > (Closes: #1066479): 0018-fix-missing-include.patch This hasn't reached testing yet because of various transitions. Pinging this bug report to avoid having packages removed from testing, including reverse dependencies, as dpkg itself hasn't migrated either. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Hi Martin, (Replying as much as braindumping to avoid rediscovering this next time around.) Martin Michlmayr (2024-04-13): > I'm sorry to be that guy who shows up every few years to waste > everyone's time... but... I was updating my Kirkwood pages for > bookworm and noticed that the OpenRD images are gone. > > Now you may remember that we had the same situation for bullseye > (#934072) and Cyril kindly restored the netboot images: > https://salsa.debian.org/installer-team/debian-installer/-/commit/3ef30be60ab128f53a0cd16e6c1e91a3123988b4 > > I guess this change never got committed to master/main because > bullseye was going to be the last release for armel. Well, Rick explicitly said he was happy with bullseye or bookworm, so one of them got implemented… > But armel is still in bookworm and Rick confirmed he's running > bookworm on his OpenRD, so I see no reason why d-i wouldn't work if > we apply the same patch to the bookworm d-i. > > Honestly, I'm not sure if it's worth it as Rick is probably the one > Debian on OpenRD left, but since bookworm will probably be the last > release of armel (or not?) it would be nice if the installer was > working on OpenRD. > > Cyril or Vagrant, can you easily apply the patch above and generate a > test image for Rick? I don't mind doing that again, but what's the game plan here? If systems are already installed and working fine, then d-i is irrelevant. For any new systems people might want to deploy, installing bullseye then upgrading to bookworm already works? We don't have anything to support for armel at the moment (as far as master and testing/unstable are concerned), hence the current “let it die altogether” plan from a d-i perspective: https://lists.debian.org/debian-boot/2024/03/msg00016.html I'm not sure we should be encouraging new installations of 32-bit hardware at this stage (look at what's happening for i386…). I don't remember seeing a decision regarding armel's being a release arch for trixie, but kernel support is gone already (same thread): https://lists.debian.org/debian-arm/2024/01/msg8.html So OpenRD has no future in trixie as far as I understand. At least that would mean not having to do that again again, if we were to enable OpenRD images again for bookworm. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Salvatore Bonaccorso (2024-04-10): > 6.7.9-2 in unstable does not exibit the issue. Besides some reverts, the key fix seems to be 321da3dc1f3c92a12e3c5da934090d2992a8814c in master (v6.8-rc6~14^2~5), which was backported as d97e1c3602240bd35c48ef9aa978e0c47a511d03 (v6.7.7~167), so that seems rather consistent with your findings. Just got notified that the two reverts + cherry-pick reached the stable queue for 6.1, so I'd expect this to be fixed upstream by the time v6.1.86 is released. https://lore.kernel.org/linux-scsi/20240411044021.xejk54iznz3cd...@mraw.org/ https://lore.kernel.org/linux-scsi/2024041155-croon-dried-f649@gregkh/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Control: forwarded -1 https://lore.kernel.org/stable/20240410193207.qnb75osxuk4ov...@mraw.org/ Salvatore Bonaccorso (2024-04-10): > Yes, if you prefer to not do the forwarding upstream (stable list, CC > to involved people + regression list), then I can try to take care of > it. Obviously the former would be great, as you are the finder and > have done all the work. Thanks for nudging me into walking those extra few meters. Let's see how that goes… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Cyril Brulebois (2024-04-10): > Of course, since there are companion changes afterwards, it cannot be > simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream). > > > I'd appreciate if someone could carry the ball through the appropriate > channels upstream. And of course I only spotted minutes after sending the previous mail that v6.1.85 got published while I was busy bisecting. It's also affected by this bug. For the sake of completeness: except for the initial report, all tests were performed with the “SATA disk in a VM” setup described in my first follow-up. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Cyril Brulebois (2024-04-10):
> Intermediate results based on upstream stable releases: v6.1.80 is good,
> v6.1.81 is bad. Still ~200 commits to bisect.
Final results:
kibi@genova:~/hack/linux.git ((cf33e6ca12d81...)|BISECTING)$ git bisect bad
cf33e6ca12d814e1be2263cb76960d0019d7fb94 is the first bad commit
commit cf33e6ca12d814e1be2263cb76960d0019d7fb94
Author: Mike Christie
Date: Thu Dec 29 13:01:40 2022 -0600
scsi: core: Add struct for args to execution functions
[ Upstream commit d0949565811f0896c1c7e781ab2ad99d34273fdf ]
Move the SCSI execution functions to use a struct for passing in
optional
args. This commit adds the new struct, temporarily converts
scsi_execute()
and scsi_execute_req() ands a new helper, scsi_execute_cmd(), which
takes
the scsi_exec_args struct.
There should be no change in behavior. We no longer allow users to pass
in
any request->rq_flags value, but they were only passing in RQF_PM which
we
do support by allowing users to pass in the BLK_MQ_REQ flags used by
blk_mq_alloc_request().
Subsequent commits will convert scsi_execute() and scsi_execute_req()
users
to the new helpers then remove scsi_execute() and scsi_execute_req().
Signed-off-by: Mike Christie
Reviewed-by: Bart Van Assche
Reviewed-by: Christoph Hellwig
Reviewed-by: John Garry
Signed-off-by: Martin K. Petersen
Stable-dep-of: 321da3dc1f3c ("scsi: sd: usb_storage: uas: Access media
prior to querying device properties")
Signed-off-by: Sasha Levin
drivers/scsi/scsi_lib.c| 52
++
include/scsi/scsi_device.h | 51
-
2 files changed, 62 insertions(+), 41 deletions(-)
That's one of the 3 commits suggested by Diederik, good hunch.
I know hindsight is always 100% but “There should be no change in
behavior.”… :D
Of course, since there are companion changes afterwards, it cannot be
simply reverted on top of either v6.1.82 (Debian) or v6.1.84 (upstream).
I'd appreciate if someone could carry the ball through the appropriate
channels upstream.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Cyril Brulebois (2024-04-10): > v6.1.84 with stable's .config & bindeb-pkg still does; next up for me: > confirming good/bad and bisecting. Intermediate results based on upstream stable releases: v6.1.80 is good, v6.1.81 is bad. Still ~200 commits to bisect. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Salvatore Bonaccorso (2024-04-10): > 6.7.9-2 in unstable does not exibit the issue. v6.1.84 with stable's .config & bindeb-pkg still does; next up for me: confirming good/bad and bisecting. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Cyril Brulebois (2024-04-10):
> Salvatore Bonaccorso (2024-04-10):
> > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > Does the problem go away if you revert the following commits on top of
> > > -19?
> > >
> > > db6338f45971b4285ea368432a84033690eaf53c
> > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH
> > > handler
> > >
> > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > scsi: core: Move scsi_host_busy() out of host lock if it is for
> > > per-command
> > >
> > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > scsi: core: Add struct for args to execution functions
>
> Preparing that test right now, thanks Diederik.
This doesn't build, but I didn't try very hard:
/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function
‘sd_read_block_zero’:
/home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error:
implicit declaration of function ‘scsi_execute_cmd’; did you mean
‘scsi_execute_req’? [-Werror=implicit-function-declaration]
> > Or if that does not find the culprit, would you be able to bisect the
> > upstrema changes beweeen 6.1.76 and 6.1.82?
I think I'll try and pinpoint when that regression came up, then figure
out what to try to get rid of it. Also testing v6.1.84 while I'm at it.
> > > 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to
> > > standby")
Reverting that one got me a successful build but that didn't help.
I'll need to find some more time to switch from throwing a patch into
the packaging repository to bindeb-pkg'ing from the mainline repository,
and to automate testing as much as possible. I'm familiar with the
exercise with Raspberry Pi thingies, but I'd expect some tweaks to be
required in the amd64 case.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Hi Salvatore,
Salvatore Bonaccorso (2024-04-10):
> On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > Hi Cyril,
> >
> > On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> > > Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> > > leads to losing some SMART information, at least as queried by munin (in
> > > Debian 12) when it comes to sensors.
> >
> > Does the problem go away if you revert the following commits on top of -19?
> >
> > db6338f45971b4285ea368432a84033690eaf53c
> > scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
> >
> > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
> >
> > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > scsi: core: Add struct for args to execution functions
Preparing that test right now, thanks Diederik.
> Or if that does not find the culprit, would you be able to bisect the
> upstrema changes beweeen 6.1.76 and 6.1.82?
>
> There would be for instance the following ata related change:
>
> 4b085736e44d ("ata: libata-core: Do not try to set sleeping devices to
> standby")
>
> If you can test it with other kernels, does the same happens on
> 6.7.7-1 and 6.7.9-2?
I'm not really keen on playing kernel ping-pong on this particular
machine (which is important in my infrastructure), but I've verified
that adding a SATA disk to an existing VM running Debian 12 on a
QEMU/libvirt Debian 12 host gives me similar results with -18 and -19
kernels (some data in the former case, no data at all in the latter
one).
I think I'd rather stay with 6.1.y kernels if at all possible, to avoid
having to figure out other changes that might be possibly required to
cope with newer kernels.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Hi, Marco d'Itri (2024-04-09): > Yes. Nowadays kmod has many more features related to compressed modules > and verification of signatures. > Can we agree that kmod should provide these programs for d-i? > Or can the d-i maintainers just tell us what they want? I meant to come back to this after experimenting, then things happened… I picked kmod at the time because it worked, and because busybox didn't work, which I summed up in: https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145 (plus follow-up commit, woopsie https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07 ) I'm fine with sticking to kmod regarding module support in d-i. I'm not sure we should keep support in two different modules, so dropping it from busybox would work for me. Others might have different views on this, though. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)
Package: src:linux Version: 6.1.82-1 Severity: normal Hi, Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64 leads to losing some SMART information, at least as queried by munin (in Debian 12) when it comes to sensors. I'm getting the following results on the 2 pairs of disks in this machine: - 2×ST4000VN008-2DR1 (sda, sdb) - 2×ST8000VN004-2M21 (sdc, sdd) root@anchorage:~# /usr/sbin/smartctl -A --nocheck=standby -d ata /dev/sda smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-19-amd64] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org Device is in SLEEP mode, exit(2) For some reason, the “S.M.A.R.T values” graphs is still OK, while the “HDD temperature” graph (using the aforementioned command) isn't anymore. The “Device is in SLEEP mode” status getting reported is obviously a lie, since all disks are in use (one pair does system stuff, the other pair does media stuff). Rebooting a couple of time with this version gives consistent negative results. Rebooting into linux-image-6.1.0-18-amd64 gives data back. The trace that appears below seems to happen exactly once per boot (and not even once per disk). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant -- Package-specific info: ** Version: Linux version 6.1.0-19-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.82-1 (2024-03-28) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-19-amd64 root=/dev/mapper/data-root ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 23.726790] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 23.763253] EXT4-fs (dm-13): mounted filesystem with ordered data mode. Quota mode: none. [ 23.764773] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input5 [ 23.765529] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input6 [ 23.765566] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card0/input7 [ 23.765595] input: HDA Intel PCH Line Out as /devices/pci:00/:00:1b.0/sound/card0/input8 [ 23.765626] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input9 [ 23.785394] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 [ 23.786295] ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 23.786473] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10 [ 23.798653] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.801990] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [ 23.823066] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.825531] i915 :00:02.0: [drm] Cannot find any crtc or sizes [ 23.916595] XFS (dm-4): Deprecated V4 format (crc=0) will not be supported after September 2030. [ 23.920456] EXT4-fs (dm-14): mounted filesystem with ordered data mode. Quota mode: none. [ 23.941160] XFS (dm-4): Mounting V4 Filesystem [ 24.076883] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Quota mode: none. [ 24.152240] XFS (dm-4): Ending clean mount [ 24.152258] xfs filesystem being mounted at /data/media supports timestamps until 2038 (0x7fff) [ 24.160691] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota mode: none. [ 24.177491] intel_rapl_common: Found RAPL domain package [ 24.177494] intel_rapl_common: Found RAPL domain core [ 24.177495] intel_rapl_common: Found RAPL domain uncore [ 24.177496] intel_rapl_common: Found RAPL domain dram [ 24.177500] intel_rapl_common: RAPL package-0 domain package locked by BIOS [ 24.177505] intel_rapl_common: RAPL package-0 domain dram locked by BIOS [ 24.415347] audit: type=1400 audit(1712616841.356:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=867 comm="apparmor_parser" [ 24.415751] audit: type=1400 audit(1712616841.356:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=868 comm="apparmor_parser" [ 24.415755] audit: type=1400 audit(1712616841.356:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=868 comm="apparmor_parser" [ 24.430914] audit: type=1400 audit(1712616841.372:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=870 comm="apparmor_parser" [ 24.430919] audit: type=1400 audit(1712616841.372:6): apparmo
Bug#1068197: debian-installer: accesses the internet during build
[ Switching from ML to bug. ] Hi Jonathan, Jonathan Carter (2024-04-01): > On 2024/04/01 18:55, Aurelien Jarno wrote: > > debian-installer attemps network access during build, although only to > > the mirrors listed in /etc/apt/sources.list and in a secure way. This is > > forbidden by Policy 4.9: > > > >For packages in the main archive, required targets must not attempt > >network access, except, via the loopback interface, to services on the > >build host that have been started by the build. > > > > In addition this brings constraints to the build daemons infrastructure. > > As far as I know, this doesn't happen until after d-i asked the question "Do > you want to use a network mirror?" and the user answered "Yes", in which > case I think that would count as informed consent. This isn't about d-i runtime, this is about src:debian-installer's *build* requiring network access, which is a very well known problem (even though there are no obvious solutions, at least that I'm aware of), and that's now getting in the way of changes being considered regarding the buildd network. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1066479: opendnssec: FTBFS: ../../common/scheduler/task.c:137:25: error: implicit declaration of function ‘clamp’ [-Werror=implicit-function-declaration]
Control: tag -1 patch pending Lucas Nussbaum (2024-03-13): > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration > > Relevant part (hopefully): > > ../../common/scheduler/task.c: In function ‘task_perform’: > > ../../common/scheduler/task.c:137:25: error: implicit declaration of > > function ‘clamp’ [-Werror=implicit-function-declaration] > > 137 | task->backoff = clamp(task->backoff * 2, 60, > > ODS_SE_MAX_BACKOFF); > > | ^ > > cc1: some warnings being treated as errors > > make[4]: *** [Makefile:601: scheduler/task.o] Error 1 I thought there would be several things but apparently that's just the one. A quick look upstream shows there are more PRs and more fixups needed for even newer compilers, but I'm limiting my patch to the bare minimum. Since that's been open for 10+ days, and since reverse dependencies could get kicked out of testing, I'm uploading an NMU right now so that I don't forget, but to DELAYED/2 so there's some room to do things differently if desired. I'm happy to reschedule/cancel if needed. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ diff -Nru opendnssec-2.1.13/debian/changelog opendnssec-2.1.13/debian/changelog --- opendnssec-2.1.13/debian/changelog 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/changelog 2024-03-26 14:27:44.0 +0100 @@ -1,3 +1,11 @@ +opendnssec (1:2.1.13-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS due to missing utilities.h include for the clamp declaration +(Closes: #1066479): 0018-fix-missing-include.patch + + -- Cyril Brulebois Tue, 26 Mar 2024 14:27:44 +0100 + opendnssec (1:2.1.13-1) unstable; urgency=medium * New upstream version 2.1.13 diff -Nru opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch --- opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 1970-01-01 01:00:00.0 +0100 +++ opendnssec-2.1.13/debian/patches/0018-fix-missing-include.patch 2024-03-26 14:23:18.0 +0100 @@ -0,0 +1,10 @@ +--- a/common/scheduler/task.c b/common/scheduler/task.c +@@ -41,6 +41,7 @@ + #include "file.h" + #include "util.h" + #include "log.h" ++#include "utilities.h" + + static const char* task_str = "task"; + static pthread_mutex_t worklock = PTHREAD_MUTEX_INITIALIZER; diff -Nru opendnssec-2.1.13/debian/patches/series opendnssec-2.1.13/debian/patches/series --- opendnssec-2.1.13/debian/patches/series 2023-09-22 17:22:55.0 +0200 +++ opendnssec-2.1.13/debian/patches/series 2024-03-26 14:27:32.0 +0100 @@ -8,3 +8,4 @@ 0015-remove-strptime-build-warning.patch 0016-m4-acx_libxml2.m4-use-pkg-config-instead-of-xml2-con.patch 0017-mysql8_my_bool.patch +0018-fix-missing-include.patch signature.asc Description: PGP signature
Bug#1066778: golang-github-containerd-go-runc: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/containerd/go-runc returned exit code 1
Shengjing Zhu (2024-03-14): > On Wed, Mar 13, 2024 at 11:05 PM Lucas Nussbaum wrote: > > > console_test.go:42: mkdir /tmp/foo: not a directory > > > --- FAIL: TestTempConsoleWithXdgRuntimeDir (0.00s) > > I wonder if your chroot doesn't have the /tmp directory? Writing to hardcoded paths under /tmp has never been a good idea in the first place. Alright, this is a test suite but we're not usually trying to write outside the build directory. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#851541: Bug#902668: Draft for rewrite of https://www.debian.org/CD/verify
Hi, Tassia Camoes Araujo (2024-03-25): > I've reviewed the proposed patch, and I think it should be applied as > soon as possible. > > It seems Laura was waiting for a final review before applying this patch > (long overdue!), which IMHO would bring much more clarity to the image > verification process (usually, a big struggle to new users). > > We should make a decision about the long key IDs request (points 1 and 2 > from #851541), and once those changes go online, I think both bugs could > be closed (#902668 and #851541). > > Thanks for all who have invested energy to clarify this process, and I > hope we can benefit from your work very soon! > > Cheers, > > Tassia. Cc += debian-cd@ for information. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1060915: golang-entgo-ent: Flaky tests due to relying on default result ordering
Hi Paul, Paul Mars (2024-01-16): > Here is a patch to fix the issue. Sorry, I didn't spot this bug report right away (its metadata got adjusted along the way). Thanks for the bug report and the patch, on their way to unstable! Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1064588: bookworm-pu: package glibc/2.36-9+deb12u5
Hi, Aurelien Jarno (2024-03-13): > The date of the next point release is slowly approaching, could you > please have a look at this? Sorry, lost track of that one. Feel free to upload. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1066074: ntfs-3g: broken shlibs (deb and udeb)
Source: ntfs-3g
Version: 1:2022.10.3-1.1
Severity: serious
Tags: d-i
Justification: broken shlibs
X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung
Hi,
Here's what debian/libntfs-3g89t64/DEBIAN/shlibs looks like after
a build:
libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 libntfs-3g89
That doesn't match binaries shipped by the source package.
See debian/rules:
SONAME = $(shell objdump -p debian/tmp/lib/*/libntfs-3g.so.*.* | awk -Fso.
'/SONAME/ { print $$2 }')
[…]
override_dh_makeshlibs:
dh_makeshlibs --add-udeb=ntfs-3g-udeb -Vlibntfs-3g$(SONAME)
In the previous version we had:
libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 ntfs-3g-udeb
Adding 't64' at the end of the dh_makeshlibs line quoted above gives:
libntfs-3g 89 libntfs-3g89t64
udeb: libntfs-3g 89 ntfs-3g-udeb
which certainly looks much better. I haven't performed any rebuild test
for the reverse dependencies of the library, nor runtime tests on the
d-i side (other packages are broken right now). The Depends field of
the udeb looks correct now though:
-Depends: libc6-udeb (>= 2.37), libntfs-3g89, fuse3-udeb
+Depends: libc6-udeb (>= 2.37), fuse3-udeb
I'll leave it up to the 64-bit time_t transition drivers to choose how
to address this issue (add t64 on the SONAME line, or just in the
dh_makeshlibs override, or something else), and to track down packages
that might have been rebuilt against the broken library.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Bug#1066073: wireless-tools: nmudiff for the 30~pre9-16.2 upload
Source: wireless-tools Version: 30~pre9-16.2 Severity: normal Tags: d-i patch X-Debbugs-Cc: Steve Langasek , debian-b...@lists.debian.org Hi, The previous upload broke udeb support, pointing to a non-existing udeb in the shlibs file. This made wireless-tools-udeb uninstallable. Seeing how this package is QA-maintained, I decided to just upload a fix without filing a bug report separately. I've verified the Depends field of the wireless-tools-udeb package looks fine; I didn't try and perform any runtime tests (other packages are broken right now). The source debdiff is attached. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru wireless-tools-30~pre9/debian/changelog wireless-tools-30~pre9/debian/changelog --- wireless-tools-30~pre9/debian/changelog 2024-02-29 03:02:19.0 +0100 +++ wireless-tools-30~pre9/debian/changelog 2024-03-12 01:42:45.0 +0100 @@ -1,3 +1,11 @@ +wireless-tools (30~pre9-16.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix shlibs entry for the udeb: it isn't getting renamed for the 64-bit +time_t transition. This makes wireless-tools-udeb installable again. + + -- Cyril Brulebois Tue, 12 Mar 2024 01:42:45 +0100 + wireless-tools (30~pre9-16.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru wireless-tools-30~pre9/debian/libiw30t64.shlibs wireless-tools-30~pre9/debian/libiw30t64.shlibs --- wireless-tools-30~pre9/debian/libiw30t64.shlibs 2024-02-29 03:01:29.0 +0100 +++ wireless-tools-30~pre9/debian/libiw30t64.shlibs 2024-03-12 01:42:42.0 +0100 @@ -1,2 +1,2 @@ libiw 30 libiw30t64 (>= 30~pre1) -udeb: libiw 30 libiw30t64-udeb (>= 30~pre1) +udeb: libiw 30 libiw30-udeb (>= 30~pre1)
Bug#1066071: mtdev: broken shlibs, leading to uninstallable udebs
Source: mtdev Version: 1.1.6-1.1 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung Hi, Your NMU broke this package's shlibs. Before: libmtdev 1 libmtdev1 udeb: libmtdev 1 libmtdev1-udeb After: libmtdev 1 libmtdev1t64 At the moment, at least the following package is broken: The following packages have unmet dependencies: libinput10-udeb : Depends: libmtdev1t64 but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1066070: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable
Source: libpng1.6 Version: 1.6.43-3 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org Hi, Your debian/rules includes this: override_dh_makeshlibs: dh_makeshlibs --add-udeb=libpng16-16-udeb -a and that's indeed the package that's listed in debian/control. However, debian/libpng16-16t64.shlibs has it wrong: libpng16 16 libpng16-16t64 (>= 1.6.2) udeb: libpng16 16 libpng16-udeb (>= 1.6.2) At this point, that breaks at least: The following packages have unmet dependencies: libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1066069: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable
Source: libpng1.6 Version: 1.6.43-3 Severity: serious Tags: d-i Justification: broken shlibs X-Debbugs-Cc: debian-b...@lists.debian.org Hi, Your debian/rules includes this: override_dh_makeshlibs: dh_makeshlibs --add-udeb=libpng16-16-udeb -a and that's indeed the package that's listed in debian/control. However, debian/libpng16-16t64.shlibs has it wrong: libpng16 16 libpng16-16t64 (>= 1.6.2) udeb: libpng16 16 libpng16-udeb (>= 1.6.2) At this point, that breaks at least: The following packages have unmet dependencies: libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not installable Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Santiago Vila (2024-03-06): > I looked at the build log and found the problem: The package has a missing > build-depends on passwd, which is no longer build-essential in trixie/sid. Alright, that's the kind of thing I had in mind initially but I'm pretty sure one of the attempt to reproduce started with a brand new build chroot… Oh well. > I am a member of Debian Go (joined to do QA stuff). > Would it help if I fix this myself by doing a "Team Upload"? Thanks for the offer, but I do have another related FTBFS on my plate (even if it was misfiled in the first place), so I'll probably lump up both uploads together. :) Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Cyril Brulebois (2024-02-15): > Is that problem still current? I cannot reproduce it with a brand new > sid environment, freshly created via either `pbuilder --create` or > `sbuild-createchroot`. For the record, I did receive a proposal to get access to such a system back then (thanks!), but I couldn't get to it just yet. Not sure about this though, received today (2024-03-06) for 3 packages: crowdsec 1.4.6-6 is marked for autoremoval from testing on 2024-03-05 Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1064617: Passwords should not be changed frequently
Philip Hands (2024-03-05): > Cool, in that case I'll fix those two things and then use the result > for the MR[1], and if the openQA test runs look OK, will merge that. Only skimmed over it, but that looks sensible, thanks all. Is it worth getting d-l-english involved in a final review before getting that translated? Contrary to a lot of not-so-critical l10n material, that particular screen is crucial, and I'd hate it if we wasted translator efforts due to a missed typo or obvious improvement. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Hi, Cyril Brulebois (2024-01-17): > Santiago Vila (2023-12-05): > > […] > > Thanks for the report. The relevant part didn't appear in the excerpt > so I'm quoting the full build log below: > > > === RUN TestOneShot/permission_denied > > file_test.go:234: > > Error Trace: > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:25 > > > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/file/file_test.go:234 > > Error: An error is expected but got nil. > > Test: TestOneShot/permission_denied > > === RUN TestOneShot/ignored_directory > > === RUN TestOneShot/glob_syntax_error > > === RUN TestOneShot/no_matching_files > > === RUN TestOneShot/test.log > > === RUN TestOneShot/test.log.gz > > === RUN TestOneShot/unexpected_end_of_gzip_stream > > === RUN TestOneShot/deleted_file > > --- FAIL: TestOneShot (0.00s) > > --- FAIL: TestOneShot/permission_denied (0.00s) > > --- PASS: TestOneShot/ignored_directory (0.00s) > > --- PASS: TestOneShot/glob_syntax_error (0.00s) > > --- PASS: TestOneShot/no_matching_files (0.00s) > > --- PASS: TestOneShot/test.log (0.00s) > > --- PASS: TestOneShot/test.log.gz (0.00s) > > --- PASS: TestOneShot/unexpected_end_of_gzip_stream (0.00s) > > --- PASS: TestOneShot/deleted_file (0.00s) Is that problem still current? I cannot reproduce it with a brand new sid environment, freshly created via either `pbuilder --create` or `sbuild-createchroot`. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
Hi Santiago, Santiago Vila (2023-12-05): > […] Thanks for the report. The relevant part didn't appear in the excerpt so I'm quoting the full build log below: > === RUN TestOneShot/permission_denied > file_test.go:234: > Error Trace: > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/cstest/utils.go:25 > > /<>/_build/src/github.com/crowdsecurity/crowdsec/pkg/acquisition/modules/file/file_test.go:234 > Error: An error is expected but got nil. > Test: TestOneShot/permission_denied > === RUN TestOneShot/ignored_directory > === RUN TestOneShot/glob_syntax_error > === RUN TestOneShot/no_matching_files > === RUN TestOneShot/test.log > === RUN TestOneShot/test.log.gz > === RUN TestOneShot/unexpected_end_of_gzip_stream > === RUN TestOneShot/deleted_file > --- FAIL: TestOneShot (0.00s) > --- FAIL: TestOneShot/permission_denied (0.00s) > --- PASS: TestOneShot/ignored_directory (0.00s) > --- PASS: TestOneShot/glob_syntax_error (0.00s) > --- PASS: TestOneShot/no_matching_files (0.00s) > --- PASS: TestOneShot/test.log (0.00s) > --- PASS: TestOneShot/test.log.gz (0.00s) > --- PASS: TestOneShot/unexpected_end_of_gzip_stream (0.00s) > --- PASS: TestOneShot/deleted_file (0.00s) I'll investigate shortly. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Julian Andres Klode (2023-12-25): > We picked the previous XFS patch for extent parsing but did not pick > this one because it had not been merged at that point yet, the fix > only got merged two weeks or so ago, and we didn't want to take chances > and pick it ahead of time as it's security critical code (filesystem > parsing is where all the security bugs live!). > > The release was supposed to be out 2 weeks ago but got pushed back > another week to last week's release, sadly. Thanks for all the details, and sorry if it appeared I was chasing you down; I just stumbled upon this again while re-testing various things, and was merely wondering whether things were. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Julian Andres Klode (2023-12-25): > The final grub 2.12 that includes the fix should hit unstable in the > middle of January. As you might be aware many are busy with family > stuff and holiday celebrations right now. Sure. I wasn't aware an upstream release was in the pipes, only that patches have existed and been confirmed OK for close to 2 months. > As always though it stands to reason that this is a change that should > (have been) reverted in xfsprogs first until a grub that understands > it has been released in a stable point release such that you can use a > stable grub to inspect an XFS filesystem created by a trixie xfsprogs. The more we tick boxes in the compatibility matrix, the happier, yes. > It seems the bug has been wrongly reassigned instead of being cloned > and reassigned, so I'm cloning it back to xfsprogs. Right, this would have been easier to track if debian-boot@ had been put (and kept) in the loop all along. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
Hi,
Anthony Iliopoulos (2023-10-30):
> On Mon, Oct 30, 2023 at 04:19:32PM +0100, Philip Hands wrote:
> > Anthony Iliopoulos writes:
> >
> > > On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
> > ...
> > >> error: invalid XFS directory entry.
> > ...
> > > This issue exists independently of the large extent counter, and it is
> > > related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> > > fuzzing the XFS filesystem"). That's actually the issue described in
> > > #1051543.
> >
> > Ah, yes -- good point.
> >
> > > There's a proposed fix at [1], and it works as expected with that patch
> > > applied.
> > ...
> > > [1]
> > > https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
> >
> > I can confirm that having applied both patches:
> >
> > https://salsa.debian.org/philh/grub2/-/pipelines/596346
> >
> > it now succeeds at both installing grub, and then booting the system:
> >
> > https://openqa.debian.net/tests/200503#details
>
> Thanks for confirming, perhaps then you can add your tested-by in the
> respective patches upstream.
>
> BTW, another handy way to test if this works is via grub-mount.
Any chance we could have an updated grub2 package to fix this?
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr
Hi, Chris Hofstaedtler (2023-12-19): > If you can reasonably expect that the package in question will not > change name, or split out or move the systemd unit files in any > other way, than strictly from /lib to /usr/lib, then this is safe to > do now. That's very safe to assume, yes. If that's enough to guarantee that I won't actually be generating another problem down the line, I'm happy to implement this change. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
Carsten Schoenert (2023-12-15): > thank you very much for pointing me! > > I did play around a bit and was adding and testing the mentioned approach. > > https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e > > With these small modifications I can currently use the d-i on my X1 G11 > without further issues. A small exception, as the firmware-iwlwifi/testing > can't provide the required firmware files right now they need to get > provided on an additional inserted media. Great, thanks. Do you actual need to modprobe $module at that point? I thought the block right after that should modprobe -r/modprobe iwlwifi on its own? (But it wasn't sufficient before you starting unloading iwlmvm.) > I did also same small s/space/tab modifications with no code changes > afterwards in check-missing firmware.sh so the indentations are now unified > to use tabs again and fixing also a small typo. > > https://salsa.debian.org/tijuca/hw-detect/-/commit/2a3c045a72b4f31fc818b7f639daf5c08b7e2e5a > > If you are fine I can raise a MR for easy pulling in. Otherwise feel free to > comment on my changes. I know mixed stuff isn't too nice, and unifying might be appealing, but that makes cherry-picking stuff harder, so I tend to only unify things when I'm actually changing code… Others might feel differently. Well spotted, for the typo. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
Pascal Hambourg (2023-12-13):
> Wouldn't it be more generic to check /sys/module/${module}/holders
> like is done for mhi ?
I was suggesting a quick and dirty way to get away with this, to see if
it helps, answering the question regarding where in the code one might
want to try something.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)
Carsten Schoenert (2023-12-13): > The "trick" is to unload the iwlmvm module instead and load afterwards > the module iwlwifi again. See the very bottom of check-missing-firmware.sh (hw-detect repository), the loop over $modules. You could try intercepting $module = iwlwifi, and adding a modprobe -r theotherone beforehand. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1051460: crowdsec-custom-bouncer: move systemd units to /usr
Hi, Chris Hofstaedtler (2023-12-08): > On Fri, Sep 08, 2023 at 11:25:24AM +0200, Helmut Grohne wrote: > > Are you fine with uploading this change at this early > > stage of the transition? > > Can we help you out in any way to get the systemd units moved? It's > not so "early stage" anymore and the systemd units can certainly > move now. I haven't been able to keep up with the state of this transition (having been busy with other topics that have been a blocker for it). If it's safe to move things around, I can handle that. At least that particular subject line from last week didn't seem encouraging: Subject: Pause /usr-merge moves See https://lists.debian.org/20231201210412.ga1344...@subdivi.de Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
