Bug#1065318: mplayer: Package is not installable due to dependency on libsmbclient
Package: mplayer Severity: grave Justification: renders package unusable X-Debbugs-Cc: benjamin.poir...@gmail.com Dear Maintainer, The mplayer package is currently not installable in Sid: root@vsid:/tmp# apt install mplayer Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libsmbclient : Depends: samba-libs (= 2:4.19.5+dfsg-1) but 2:4.19.5+dfsg-3 is to be installed libsmbclient0 : Breaks: libsmbclient (< 2:4.19.5+dfsg-3) but 2:4.19.5+dfsg-1 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. I guess this problem is related to this change noted in the samba changelog: samba (2:4.19.5+dfsg-2) unstable; urgency=medium * rename libsmbclient => libsmbclient0 for 64-bit time_t transition Closes: #1064337 I rebuilt the mplayer package from source (version 1.5+svn38446) without any change. The resulting .deb had a dependency on libsmbclient0 (>= 2:4.0.3+dfsg1) and I was able to install it without further effort. Thank you -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mplayer depends on: ii liba52-0.7.4 0.7.4-20+b1 ii libaa11.4p5-51 ii libasound2t64 [libasound2]1.2.11-1 ii libass9 1:0.17.1-2 ii libaudio2 1.9.4-7+b1 ii libavcodec60 7:6.1.1-2 ii libavformat60 7:6.1.1-2 ii libavutil58 7:6.1.1-2 ii libbluray21:1.3.4-1 ii libbs2b0 3.1.0+dfsg-7 ii libc6 2.37-15.1 ii libcaca0 0.99.beta20-4 ii libcdio-cdda2 10.2+2.0.1-1 ii libcdio-paranoia2 10.2+2.0.1-1 ii libcdio19 2.1.0-4 ii libdca0 0.0.7-2 ii libdv41.0.0-17 ii libdvdnav46.1.1-1 ii libdvdread8 6.1.3-1 ii libegl1 1.7.0-1 pn libenca0 ii libfaad2 2.11.1-1+b1 ii libfontconfig12.15.0-1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libfribidi0 1.0.13-3+b1 ii libgif7 5.2.2-1 ii libgl11.7.0-1 ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-3+b1 ii libjpeg62-turbo 1:2.1.5-2+b2 ii liblirc-client0t64 [liblirc-client0] 0.10.2-0.7 ii libmad0 0.15.1b-10.1+b1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmpeg2-40.5.1-9+b1 ii libmpg123-0 1.32.5-1 ii libogg0 1.3.5-3 ii libopenal11:1.23.1-4+b1 ii libpng16-16t64 [libpng16-16] 1.6.43-3 ii libpostproc57 7:6.1.1-2 ii libpulse0 16.1+dfsg1-3 pn libsdl1.2debian pn libsmbclient ii libsndio7.0 1.9.0-0.3+b3 ii libspeex1 1.2.1-2+b1 ii libswresample47:6.1.1-2 ii libswscale7 7:6.1.1-2 ii libtheora01.1.1+dfsg.1-16.1+b1 ii libtinfo6 6.4+20240113-1 ii libvdpau1 1.5-2 pn libvorbisidec1 ii libx11-6 2:1.8.7-1 ii libxext6 2:1.3.4-1+b1 ii libxinerama1 2:1.1.4-3 ii libxss1 1:1.2.3-1 ii libxv12:1.0.11-1.1 ii libxvidcore4 2:1.3.7-1+b1 ii libxvmc1 2:1.0.12-2 ii libxxf86dga1 2:1.1.5-1 ii libxxf86vm1 1:1.1.4-1+b2 ii zlib1g1:1.3.dfsg-3.1 mplayer recommends
Bug#1063750: firmware-amd-graphics: System with AMD Ryzen 7 PRO 7840U laptop fails to suspend, error from amdgpu
Package: firmware-amd-graphics Version: 20230625-2 Severity: normal X-Debbugs-Cc: benjamin.poir...@gmail.com Dear Maintainer, My laptop, Lenovo ThinkPad P14s Gen 4 with AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics SoC, fails to enter suspend. When I try to suspend, in ~9/10 cases, the suspend "fails" and the machine immediately resumes. I see the following logs at the end of the suspend sequence: Feb 11 20:29:52 f4 kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14 Feb 11 20:29:52 f4 kernel: [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait At boot I see the errors: eb 11 20:27:36 f4 kernel: amdgpu :64:00.0: firmware: failed to load amdgpu/gc_11_0_1_mes_2.bin (-2) Feb 11 20:27:36 f4 kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware Feb 11 20:27:36 f4 kernel: amdgpu :64:00.0: firmware: failed to load amdgpu/gc_11_0_1_mes_2.bin (-2) Feb 11 20:27:36 f4 kernel: amdgpu :64:00.0: Direct firmware load for amdgpu/gc_11_0_1_mes_2.bin failed with error -2 I installed all the firmware files from linux-firmware.git at commit fbef4d38, regenerated the initramfs and rebooted. Suspend worked in 3/3 tries. To narrow things down a bit, I tried to copy only the missing firmware file (amdgpu/gc_11_0_1_mes_2.bin) from the tag of linux-firmware matching the installed version of the firmware-amd-graphics package (20230625). That got rid of the "failed to load" error message of course but suspend still failed with the same error. Then I copied only the firmware files which are loaded by the driver on my machine according to the following logs: Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/psp_13_0_4_toc.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/psp_13_0_4_ta.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/dcn_3_1_4_dmcub.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_pfp.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_me.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_rlc.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_mec.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/vcn_4_0_2.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_mes_2.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_mes1.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/gc_11_0_1_imu.bin Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading firmware amdgpu/sdma_6_0_1.bin I copied the files from linux-firmware.git commit fbef4d38. Somewhat surprisingly, the suspend problem still occurred. Is there another related firmware file that gets loaded? I tested once more by installing all the files from linux-firmware and confirmed that the suspend problem does not occur. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142 -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_mec.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_mec2.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_sjt_mec.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_sjt_mec2.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_smc.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_sos.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_ta.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/arcturus_ta.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/beige_goby_ce.bin (from firmware-amd-graphics package) debsums: changed file /usr/lib/firmware/amdgpu/beige_goby_dmcub.bin (from firmware-amd-graphics package) debsums:
Bug#900244: NVM error information log entry count increase not an error
I also see this issue with the following drive, nvme1 on my system: Model Number: Samsung SSD 970 EVO Plus 1TB Firmware Version: 2B2QEXM7 PCI Vendor/Subsystem ID:0x144d This has been going on for months and until recently the output of `smartctl -l error /dev/nvme1` showed === START OF SMART DATA SECTION === Error Information (NVMe Log 0x01, 16 of 64 entries) No Errors Logged However now it shows === START OF SMART DATA SECTION === Error Information (NVMe Log 0x01, 16 of 64 entries) Num ErrCount SQId CmdId Status PELoc LBA NSIDVS 0 3401 0 0x0006 0x4004 -0 0 - `nvme smart-log /dev/nvme1` shows . Entry[ 0] . error_count : 3401 sqid: 0 cmdid : 0x6 status_field: 0x4004(INVALID_FIELD: A reserved coded value or an unsupported value in a defined field) parm_err_loc: 0x lba : 0 nsid: 0 vs : 0 trtype : The transport type is not indicated or the error is not transport related. cs : 0 trtype_spec_info: 0 . The other entries are not populated, they all have status_field: 0(SUCCESS: The command completed successfully) The same system also has another drive, /dev/nvme0: Model Number: Samsung SSD 980 PRO 1TB Firmware Version: 2B2QGXA7 PCI Vendor/Subsystem ID:0x144d That drive does not show this problem, `smartctl -A /dev/nvme0` remains at Error Information Log Entries: 0 In my case this is a dual boot system; nvme1 is used for Windows 10 and rarely mounted in Linux. However in the past I was also using nvme1 for my linux root partition and the error count was also increasing. Like others have said, the error count on nvme1 seems to increase after reboots though not systematically. I have edited /etc/smartmontools/run.d/10mail to filter out the messages about nvme1 error log entries.
Bug#984495: systemd segfault soon after daemon-reload
On 2021-03-05 10:59 +0100, Michael Biebl wrote: [...] > > Is Scott the user who initially encountered this issue on Cumulus Linux 4? > Scott is another Cumulus employee working on this issue. I asked about involving the original reporter here but no success, unfortunately.
Bug#984495: systemd segfault soon after daemon-reload
On 2021-03-04 13:38 +0100, Michael Biebl wrote: [...] > > This does look like a reasonable candidate for a buster backport. > Have you verified, that this commit fixes the crash you are seeing? I have not been able to reproduce the issue myself. According to the discussion that led to the upstream commit, this problem can be triggered by running `systemctl daemon-reload` concurrently with `systemctl restart `: https://github.com/systemd/systemd/issues/15356#issue-595874386 https://github.com/systemd/systemd/issues/15356#issuecomment-610405337 According to the logs and the core file that I have, in this case it seems that it was `systemctl daemon-reload` and `systemctl reload frr` running around the same time. Somewhat similarly to the example unit file given on Github, frr.service defines Exec* directives which are bash scripts that send signals to other processes, but I don't know if that is really relevant to the problem. Scott (cc'ed) tried simultaneous restarts of frr and daemon reloads in their own loops for an hour but wasn't able to trigger the crash. I tried simultaneous restarts of a simple service with ExecStart, ExecStop commands similar to what's shown on Github and `systemctl daemon-reload` but also didn't reproduce a problem.
Bug#984495: systemd segfault soon after daemon-reload
Package: systemd Version: 241-7~deb10u4 Severity: important Tags: upstream patch Dear Maintainer, A user of Cumulus Linux 4, which uses some Debian Buster packages including systemd, reported a systemd crash: 2021-03-03T20:59:58.426342+00:00 systemd[1]: Reloading. 2021-03-03T20:59:58.459909+00:00 kernel: [ 4344.314153] systemd[1]: segfault at 50 ip 55d419ce7080 sp 7ffcecb91850 error 4 in systemd[55d419c8c000+b1000] 2021-03-03T20:59:58.459955+00:00 kernel: [ 4344.326055] Code: 45 8c 48 8b 4d 90 c7 45 88 00 00 00 00 48 8b 94 c7 a0 04 00 00 48 89 85 70 ff ff ff 48 89 c8 48 39 d1 74 15 31 c9 0f 1f 40 00 <48> 8b 40 50 83 c1 01 48 39 c2 75 f4 89 4d 88 48 8b 45 90 48 8 b 58 2021-03-03T20:59:58.472662+00:00 kernel: [ 4344.359412] systemd: 37 output lines suppressed due to ratelimiting 2021-03-03T20:59:58.472295+00:00 systemd[1]: Caught , dumped core as pid 20486. 2021-03-03T20:59:58.495229+00:00 systemd[1]: Freezing execution. The core file shows the following information: (gdb) info stack #0 0x7f9ac0f4ea97 in kill () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x55d419d3c4f6 in crash (sig=11) at ../src/core/main.c:197 #2 #3 service_exec_command_index (current=0x55d41ab219f0, id=_SERVICE_EXEC_COMMAND_INVALID, u=0x55d41ab20980) at ../src/core/service.c:2442 #4 service_serialize_exec_command (u=u@entry=0x55d41ab20980, f=f@entry=0x55d41ac0cab0, command=0x55d41ab219f0) at ../src/core/service.c:2470 #5 0x55d419ce7557 in service_serialize (u=0x55d41ab20980, f=0x55d41ac0cab0, fds=0x55d41ab59460) at ../src/core/service.c:2534 #6 0x55d419cff0ed in unit_serialize (serialize_jobs=255, fds=0x55d41ab59460, f=0x55d41ac0cab0, u=0x55d41ab20980) at ../src/core/unit.h:582 #7 manager_serialize (m=0x55d41aaa54a0, f=, fds=0x55d41ab59460, switching_root=false) at ../src/core/manager.c:3208 #8 0x55d419d3963d in manager_reload (m=0x55d41aaa54a0) at ../src/core/manager.c:3486 #9 invoke_main_loop (m=0x55d41aaa54a0, ret_reexecute=, ret_retval=, ret_shutdown_verb=0x7ffcecb91b48, ret_fds=0x7ffcecb91b38, ret_switch_root_dir=0x7ffcecb91b58, ret_switch_root_init=0x7ffcecb91b50, ret_error_message=0x7ffcecb91b40) at ../src/core/main.c:1873 #10 0x55d419c91c06 in main (argc=1, argv=) at ../src/core/main.c:2625 Given "id=_SERVICE_EXEC_COMMAND_INVALID" in frame #3, this seems to match the following reports: https://bugzilla.redhat.com/show_bug.cgi?id=1829867 https://github.com/systemd/systemd/issues/15356 The problem in the above reports was fixed upstream in the following pull request https://github.com/systemd/systemd/pull/15546 and especially in commit e9da62b18a core: make sure to restore the control command id, too (v246-rc1) I've checked that there is no patch backporting this commit in the latest version of the systemd package in Buster, 241-7~deb10u6. Would you consider adding this commit? Thank you -Benjamin -- Package-specific info: -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-cl-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-4 ii libapparmor1 2.13.2-10 ii libaudit11:2.8.4-3 ii libblkid12.33.1-0.1 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcryptsetup12 2:2.1.0-5+deb10u2 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.6.7-4+deb10u5 ii libgpg-error01.35-1 ii libidn11 1.33-2.2 ii libip4tc01.8.2-3-cl4u4.2.1 ii libkmod2 26-1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.33.1-0.1 ii libpam0g 1.3.1-5 ii libseccomp2 2.3.3-4 ii libselinux1 2.8-1+b1 ii libsystemd0 241-7~deb10u4 ii mount2.33.1-0.1 ii util-linux 2.33.1-0.1 Versions of packages systemd recommends: ii dbus1.12.20-0+deb10u1 pn libpam-systemd Versions of packages systemd suggests: pn policykit-1 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.133+deb10u1 ii udev 241-7~deb10u4 -- Configuration Files: /etc/systemd/system.conf changed [not included] -- no debconf information
Bug#950597: git-gui "Show History Context" raises "Application Error"
On 2020-09-06 15:43 +0200, Bernhard Übelacker wrote:
> Control: fixed -1 1:2.26.0-1
>
>
> Dear Maintainer,
> I tried to have a look and found that it
> showed the message: Error: can't read "::main_status": no such variable
>
> But starting with version 1:2.26.0-1 I could not see
> this message anymore.
>
> Therefore I guess this bug could be closed?
>
Thanks for looking into it. The issue was resolved by upstream commit
5eb9397e88df ("git-gui: fix error popup when doing blame -> "Show
History Context"")
Bug#963244: Wrong "Bug-Debian" in protobuf_generated_classes_no_inheritance.patch
I think that the wrong "Bug-Debian" tag was inserted in debian/patches/protobuf_generated_classes_no_inheritance.patch: Description: Fix build with latest protobuf Origin: gentoo https://gitweb.gentoo.org/repo/gentoo.git/plain/app-i18n/mozc/files/mozc-2.23.2815.102-protobuf_generated_classes_no_inheritance.patch Bug-Debian: http://bugs.debian.org/265678
Bug#963244: mozc FTBFS with Protobuf 3.12.3
Source: mozc Version: 2.23.2815.102+dfsg-9 Followup-For: Bug #963244 FYI, the following patch fixes the build failure, https://github.com/google/mozc/issues/460#issuecomment-489511210
Bug#698267: fixed in mutt 1.14.5-1
This triggered a regression, I would say. When composing a new message, the realname configuration item is not taken into account to create the "From" address. For example, in my case, it appears as "From: benjamin.poir...@gmail.com". This is a regression from package version 1.14.4-2 where it would appear as "From: Benjamin Poirier ".
Bug#961563: crash: Build failure due to parallel execution
On 2020-05-26 17:10 +0300, Adrian Bunk wrote: > Control: severity -1 normal > Control: tags -1 - ftbfs > > On Tue, May 26, 2020 at 11:58:19AM +0900, Benjamin Poirier wrote: > > Source: crash > > Severity: serious > > Tags: upstream patch ftbfs > > Justification: fails to build from source (but built successfully in the > > past) > > > > Dear Maintainer, > > > > The crash package sometimes fails to build when dpkg-buildpackage is > > invoked with -j > 1: > > > > # dpkg-buildpackage -us -uc -j4 > >... > > You are not the first person to fall into this trap. > >-j, --jobs[=jobs|auto] > Number of jobs allowed to be run simultaneously, number > of jobs matching the number of online processors if auto > is specified (since dpkg 1.17.10), or unlimited number > if jobs is not specified, equivalent to the make(1) > option of the same name (since dpkg 1.14.7, long option > since dpkg 1.18.8). Will add itself to the MAKEFLAGS > environment variable, which should cause all subsequent > make invocations to inherit the option, thus forcing the > parallel setting on the packaging (and possibly the > upstream build system if that uses make) regardless of > their support for parallel builds, which might cause > build failures. > > -J is the correct dpkg-buildpackage option. Thanks for the tip. Indeed, specifying -J avoids the problem. > > > This is because crash's configure rewrites Makefile via a temporary file > > (Makefile.new) and it is now getting invoked multiple times in parallel. > > This is a problem upstream. > > Correct. > > > It can be avoided with the following change: > > --- a/debian/rules > > +++ b/debian/rules > > @@ -12,8 +12,7 @@ include /usr/share/dpkg/buildflags.mk > > dh $@ > > > > override_dh_auto_build: > > - dh_auto_build > > - $(MAKE) extensions lzo snappy > > + dh_auto_build -- all extensions lzo snappy > >... > > This would fix only the "dpkg-buildpackage -j1" case, Since the crash package has debian/compat level 9, dh always invokes make with -j1. So that patch avoided problems from dpkg-buildpackage invocations with -j > 1. > "dh $@ --parallel" would still fail due to > make -j4 all extensions lzo snappy > Yeah... but I wasn't suggesting adding "--parallel". Actually, the intention of the patch I suggested was not to enable parallel building; it was to prevent it (since it's not supported upstream). > > The correct workaround to enable parallel building is: > > %: > dh $@ --parallel > > override_dh_auto_build: > $(MAKE) > $(MAKE) extensions > $(MAKE) lzo > $(MAKE) snappy True, but it doesn't bring any benefit I think because of crash's Makefile: debian/rules build dh build --parallel dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_update_autotools_config -O--parallel dh_auto_configure -O--parallel dh_auto_configure: warning: Compatibility levels before 10 are deprecated (level 9 in use) debian/rules override_dh_auto_build make[1]: Entering directory '/root/crash-7.2.8' /usr/bin/make make[2]: Entering directory '/root/crash-7.2.8' TARGET: X86_64 CRASH: 7.2.8 GDB: 7.6 make[3]: Entering directory '/root/crash-7.2.8' make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. Anyways, if pressed, I would agree that the initially reported failure is due to a user error with regards to -j vs. -J. Please feel free to close this bug.
Bug#961563: crash: Build failure due to parallel execution
Source: crash Severity: serious Tags: upstream patch ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, The crash package sometimes fails to build when dpkg-buildpackage is invoked with -j > 1: # dpkg-buildpackage -us -uc -j4 [...] /usr/bin/make extensions lzo snappy make[2]: Entering directory '/tmp/x/crash-7.2.8' mv: cannot stat 'Makefile.new': No such file or directory Makefile: cannot create new Makefile please copy Makefile.new to Makefile make[2]: *** [Makefile:324: lzo] Error 1 make[2]: *** Waiting for unfinished jobs mv: cannot stat 'Makefile.new': No such file or directory Makefile: cannot create new Makefile please copy Makefile.new to Makefile make[2]: *** [Makefile:328: snappy] Error 1 make[3]: Entering directory '/tmp/x/crash-7.2.8' make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. gcc -Wall -g -shared -rdynamic -o echo.so echo.c -fPIC -DX86_64 -DGDB_7_6 eppic.so: failed to pull eppic code from git repo gcc -Wall -g -shared -rdynamic -o trace.so trace.c -fPIC -DX86_64 -DGDB_7_6 gcc -Wall -g -shared -rdynamic -o dminfo.so dminfo.c -fPIC -DX86_64 -DGDB_7_6 gcc -Wall -g -I. -shared -rdynamic -o snap.so snap.c -fPIC -DX86_64 -DGDB_7_6 make[3]: Leaving directory '/tmp/x/crash-7.2.8' make[2]: Leaving directory '/tmp/x/crash-7.2.8' make[1]: *** [debian/rules:16: override_dh_auto_build] Error 2 make[1]: Leaving directory '/tmp/x/crash-7.2.8' make: *** [debian/rules:12: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This is because crash's configure rewrites Makefile via a temporary file (Makefile.new) and it is now getting invoked multiple times in parallel. This is a problem upstream. It can be avoided with the following change: --- a/debian/rules +++ b/debian/rules @@ -12,8 +12,7 @@ include /usr/share/dpkg/buildflags.mk dh $@ override_dh_auto_build: - dh_auto_build - $(MAKE) extensions lzo snappy + dh_auto_build -- all extensions lzo snappy override_dh_auto_clean: cp $(CURDIR)/Makefile $(CURDIR)/debian/Makefile.ori -- Because the package uses debian/compat level 9, dh forces -j1.
Bug#950597: git-gui "Show History Context" raises "Application Error"
Package: git-gui Version: 1:2.25.0-1 Severity: normal When running `git gui blame` and using "Show history context", git-gui pops up an "Application Error" window which says 'Error: can't read "::main_status": no such variable'. Clicking "OK" closes the window and the rest of the functionality appears unaffected. To reproduce: inside a git repository, for example a clone of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git, run $ git gui blame Makefile After the git-gui status bar show "Annotation complete", right click on a source line (ex. line #1) and choose "Show History Context". `gitk` is started and the window with the error message appears. Using https://snapshot.debian.org/binary/git-gui/ I tested that 1:2.25.0~rc2-1 is bad 1:2.25.0~rc1-1 is good I also tested that the problem is still present in 1:2.25.0+next.20200116-1 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-gui depends on: ii git 1:2.25.0-1 ii tk 8.6.9+1+b1 Versions of packages git-gui recommends: ii gitk 1:2.25.0-1 Versions of packages git-gui suggests: ii aspell 0.60.8-1 pn git-doc pn meld -- no debconf information
Bug#948859: coccinelle: Package is uninstallable
On 2020/01/16 15:11 +0100, Stéphane Glondu wrote: > Le 14/01/2020 à 02:26, Benjamin Poirier a écrit : > > The coccinelle package has been uninstallable for many weeks in unstable: > > > > root@f3:~# apt install coccinelle > > [...] > > The following packages have unmet dependencies: > > coccinelle : Depends: libpcre-ocaml-2h5n2 but it is not installable > > Depends: ocaml-base-nox-4.05.0 but it is not installable > > E: Unable to correct problems, you have held broken packages. > > This is known; the package currently FTBFS in unstable. I've fixed it in > git, but wonder if it is worth an upload because of #885267, which I've > not fixed. In its current state, the package will never migrate to > testing because of #885267. One step at a time? It would be useful to make the package usable in unstable as a first step. Have you brought up the pygtk issue with upstream?
Bug#948859: coccinelle: Package is uninstallable
Source: coccinelle Version: 1.0.4.deb-4 Severity: grave Justification: renders package unusable Dear Maintainer, The coccinelle package has been uninstallable for many weeks in unstable: root@f3:~# apt install coccinelle Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: coccinelle : Depends: libpcre-ocaml-2h5n2 but it is not installable Depends: ocaml-base-nox-4.05.0 but it is not installable E: Unable to correct problems, you have held broken packages. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
On 2020/01/07 10:12, Michael Jeanson wrote:
> On 2020-01-06 7:46 p.m., Benjamin Poirier wrote:
> > I'm not sure if it's related but I saw almost the same error on last
> > upgrade (but for 5.4.0-2):
> >
> > depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not
> > open builtin file
> > '/var/tmp/mkinitramfs_J2sneW/lib/modules/5.4.0-2-amd64/modules.builtin.bin'
> >
> > and I now get:
> >
> > root@vsid:~# lttng list --kernel
> > Error: Unable to list kernel events: Kernel tracer not available
> > root@vsid:~# journalctl -u lttng-sessiond.service
> > [...]
> > Jan 07 09:33:20 vsid lttng-sessiond[403]: Error: Failed to load kmod
> > library resources
> > Jan 07 09:33:20 vsid lttng-sessiond[403]: Warning: No kernel tracer
> > available
> >
> > lttng-modules-dkms is installed. I can load the modules manually but I
> > still get the same error.
> >
>
> Hi,
>
> If you had just installed the lttng-modules-dkms and lttng-tools packages,
> it's possible that the lttng-sessiond deamon was started before the kernel
> modules were built and so it couldn't load them.
Looks like the modules are built before lttng-sessiond is started:
Setting up lttng-modules-dkms (2.11.0-2) ...
Loading new lttng-modules-2.11.0 DKMS files...
Building for 5.4.0-2-amd64
Building initial module for 5.4.0-2-amd64
Done.
lttng-lib-ring-buffer.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/5.4.0-2-amd64/updates/dkms/
[...]
depmod...
DKMS: install completed.
Setting up linux-headers-5.4.0-2-amd64 (5.4.8-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 5.4.0-2-amd64:.
Setting up sudo (1.8.29-1) ...
Setting up babeltrace (1.5.7-2) ...
Setting up liburcu6:amd64 (0.11.1-2) ...
Setting up linux-headers-amd64 (5.4.8-1) ...
Setting up liblttng-ctl0:amd64 (2.11.0-3) ...
Setting up lttng-tools (2.11.0-3) ...
Still, it doesn't work.
> Simply restarting the sessiond should fix this.
I tried restarting lttng-sessiond or rebooting the machine but it was no
help, lttng-sessiond always reports:
Error: Failed to load kmod library resources
Warning: No kernel tracer available
A quick look into the code shows that is:
src/bin/lttng-sessiond/modprobe.c
kmod_set_log_fn(*ctx, log_kmod, NULL);
ret = kmod_load_resources(*ctx);
if (ret < 0) {
ERR("Failed to load kmod library resources");
goto error;
}
I didn't dig into libkmod, but I noticed (using opensnoop.bt) the
following:
8071 lttng-sessiond 2 0
/lib/modules/5.4.0-2-amd64/modules.dep.bin
8071 lttng-sessiond 2 0
/lib/modules/5.4.0-2-amd64/modules.alias.bin
8071 lttng-sessiond 2 0
/lib/modules/5.4.0-2-amd64/modules.symbols.bin
8071 lttng-sessiond 2 0
/lib/modules/5.4.0-2-amd64/modules.builtin.alias.bin
On another machine which I haven't yet updated and where lttng still
works, I see:
193519 lttng-sessiond 2 0
/lib/modules/5.4.0-1-amd64/modules.dep.bin
193519 lttng-sessiond 2 0
/lib/modules/5.4.0-1-amd64/modules.alias.bin
193519 lttng-sessiond 2 0
/lib/modules/5.4.0-1-amd64/modules.symbols.bin
193519 lttng-sessiond 2 0
/lib/modules/5.4.0-1-amd64/modules.builtin.bin
Not sure if /lib/modules/5.4.0-2-amd64/modules.builtin.alias.bin is
relevant but it's an empty file...
After downgrading libkmod2 from
Version: 26+20191223-1
to
Version: 26-3
the issue with lttng is no longer apparent:
root@vsid:/tmp# lttng list --kernel
Kernel events:
-
asoc_snd_soc_bias_level_start (loglevel: TRACE_EMERG (0)) (type:
tracepoint)
asoc_snd_soc_bias_level_done (loglevel: TRACE_EMERG (0)) (type:
tracepoint)
asoc_snd_soc_dapm_start (loglevel: TRACE_EMERG (0)) (type:
tracepoint)
[...]
Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'
I'm not sure if it's related but I saw almost the same error on last upgrade (but for 5.4.0-2): depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_J2sneW/lib/modules/5.4.0-2-amd64/modules.builtin.bin' and I now get: root@vsid:~# lttng list --kernel Error: Unable to list kernel events: Kernel tracer not available root@vsid:~# journalctl -u lttng-sessiond.service [...] Jan 07 09:33:20 vsid lttng-sessiond[403]: Error: Failed to load kmod library resources Jan 07 09:33:20 vsid lttng-sessiond[403]: Warning: No kernel tracer available lttng-modules-dkms is installed. I can load the modules manually but I still get the same error.
Bug#948253: lttng-tools: sysconfdir paths wrong in man pages
Package: lttng-tools Version: 2.11.0-3 Severity: normal The CONFDIR variable (set from `./configure --sysconfdir=/etc [...]`) is not expanded correctly when building the documentation of the lttng-tools packages. For example, lttng-sessiond(8) claims automatic loading of tracing session configurations from "/usr/local/etc/lttng/sessions/auto". This path should be "/etc/lttng/sessions/auto". CONFDIR is set as expected when building the actual lttng-sessiond binary (can be seen using `strings` on it and confirmed in actual operation), only the documentation is wrong. I noticed that if I install the asciidoc package before building the lttng-tools package, the problem goes away. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lttng-tools depends on: ii libc6 2.29-7 ii libkmod2 26-3 ii liblttng-ctl0 2.11.0-3 ii liblttng-ust-ctl4 2.11.0-1 ii libpopt0 1.16-14 ii liburcu6 0.11.1-2 ii libuuid1 2.34-0.1 ii libxml22.9.4+dfsg1-8 ii lsb-base 11.1.0 Versions of packages lttng-tools recommends: ii babeltrace 1.5.7-2 Versions of packages lttng-tools suggests: ii lttng-modules-dkms 2.11.0-2 -- no debconf information
Bug#947921: iputils-ping: glibc ipv4/v6 route check causes ping to fail with certain ip routing policies
Package: iputils-ping
Version: 3:20180629-2
Severity: important
Tags: ipv6 patch
Using `ping -I` on hosts that have routing rules matching on the outgoing
interface may fail when specifying the destination by name because ping tries
to connect via ipv6 while there are only ipv4 routes or vice-versa:
root@vdebian:~# ping -c1 -I eth0 google.com
connect: Network is unreachable
root@vdebian:~# ping -c1 -I eth0 -4 google.com
PING google.com (172.217.174.110) from 192.168.15.102 eth0: 56(84)
bytes of
data.
64 bytes from nrt12s28-in-f14.1e100.net (172.217.174.110): icmp_seq=1
ttl=53
time=16.2 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.223/16.223/16.223/0.000 ms
root@vdebian:~# host google.com
google.com has address 172.217.174.110
google.com has IPv6 address 2404:6800:4004:80d::200e
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
root@vdebian:~# ping -c1 -I eth0 172.217.174.110
PING 172.217.174.110 (172.217.174.110) from 192.168.15.102 eth0: 56(84)
bytes
of data.
64 bytes from 172.217.174.110: icmp_seq=1 ttl=53 time=11.4 ms
--- 172.217.174.110 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 11.435/11.435/11.435/0.000 ms
Patches (that I submitted) have been merged in upstream iputils to address
this issue:
c249e48 ping: fix main loop over multiple addrinfo results
2705c82 ping: try next addrinfo on connect failure
The exact conditions that lead to this problem are detailed in the log of
commit 2705c82.
I've attached a backport of those patches for Debian Buster. I've built a test
package with those packages and confirmed that they fix the issue. Please
consider applying them.
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages iputils-ping depends on:
ii libc6 2.28-10
ii libcap2 1:2.25-2
ii libidn2-0 2.0.5-1
ii libnettle6 3.4.1-1
Versions of packages iputils-ping recommends:
ii libcap2-bin 1:2.25-2
iputils-ping suggests no packages.
-- no debconf information
>From 769a6790437e883d72eebbabd06d33a05a0340ca Mon Sep 17 00:00:00 2001
From: Benjamin Poirier
Date: Thu, 26 Dec 2019 10:44:03 +0900
Subject: [PATCH 1/2] ping: fix main loop over multiple addrinfo results
Despite what the log of commit f68eec0eafad ("ping: perform dual-stack ping
by default") says, main() was not designed to loop over multiple addresses
returned by getaddrinfo(). This is apparent because until commit
db11bc96a68c ("ping: make command to return from main()"), ping{4,6}_run()
never returned (they always exited). After commit db11bc96a68c, we
encounter unexpected situations if getaddrinfo returns multiple results and
ping{4,6}_run() return != 0.
For example (notice echo reply is not received):
root@vsid:/src/iputils# ./builddir/ping/ping -w1 google.com
PING google.com(nrt12s22-in-x0e.1e100.net (2404:6800:4004:80c::200e)) 56
data bytes
--- google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING (216.58.197.142) 56(84) bytes of data.
--- ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time -1002ms
root@vsid:/src/iputils#
Establish the following convention:
* return value >= 0 -> exit with this code (same behavior as before commit
db11bc96a68c)
* return value < 0 -> go on to next addrinfo result
The second case will be used in the following patch.
Fixes: db11bc96a68c ("ping: make command to return from main()")
Signed-off-by: Benjamin Poirier
---
ping.c | 6 +-
ping6_common.c | 1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/ping.c b/ping.c
index 733477f..4d2de0f 100644
--- a/ping.c
+++ b/ping.c
@@ -528,8 +528,11 @@ main(int argc, char **argv)
exit(2);
}
- if (status == 0)
+ if (status >= 0)
break;
+ /* status < 0 means to go on to next addrinfo result, there
+* better be one. */
+ assert(ai->ai_next);
}
freeaddrinfo(r
Bug#946951: workaround
Thanks for your analysis. I have the same problem and a simple workaround for the time being is to do: ln -s /tmp/.wine-1000/ /run/user/1000/wine
Bug#946196: udev: documented way to prevent interface renaming stopped working
On 2019/12/05 11:34, Michael Biebl wrote: [...] > > The old 73-usb-net-by-mac.rules file contained: > > TEST!="/etc/systemd/network/99-default.link", \ > > This check can't be expressed via .link files. > The new 73-usb-net-by-mac.link link file does respect the net.ifnames=0 > kernel command line parameter, though. > > I don't see a good way of fixing this with .link files, aside from > documenting this change. We could say that users have to symlink > 73-usb-net-by-mac.link as well (or symlink 80-net-setup-link.rules, > which does the actual renaming). I think documenting that 73-usb-net-by-mac.link needs to be symlinked as well is the best approach. It diverges from the upstream instructions in eg. https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/#idontlikethishowdoidisablethis but then, Debian diverges from upstream by adding 73-usb-net-by-mac.rules or .link. > > The other alternative would be to revert the changes from #941636, but I > kinda like the new .link based approach and would prefer to keep it. > > Thoughts? Like I pointed out in 941636, that simple TEST for the existence of /etc/systemd/network/99-default.link is too basic and can lead to counterintuitive behavior as well: > This is an incomplete way of reimplementing udev functionality. In > particular, the user will get a different behavior if they do > $ cp /lib/systemd/network/99-default.link /etc/systemd/network/ > even though the naming rules are effectively the same. So I don't think it was good. signature.asc Description: PGP signature
Bug#944641: linux-perf-4.19: Many "perf script" scripts do not work because they lack python3 support
Package: linux-perf-4.19
Version: 4.19.67-2+deb10u2
Severity: normal
Tags: upstream
perf embeds a python interpreter and the debian linux source package has
debian/rules.d/tools/perf/Makefile:MAKE_PERF += PYTHON=/usr/bin/python3
However, many of the scripts in tools/perf/scripts/python, executed via `perf
script [...]`, did not support python3 in the 4.19 release.
For example:
root@vdebian:~# perf script net_dropmonitor
File "/usr/lib/perf_4.19-core/scripts/python/net_dropmonitor.py", line 53
print "%25s %25s %25s" % ("LOCATION", "OFFSET", "COUNT")
^
SyntaxError: invalid syntax
Error running python script
/usr/lib/perf_4.19-core/scripts/python/net_dropmonitor.py
---
This issue was fixed upstream in the following series:
02b03ec383e0 perf script python: Add Python3 support to netdev-times.py
9b2700efc57f perf script python: Add Python3 support to
failed-syscalls-by-pid.py
e4d053ddb4c4 perf script python: Add Python3 support to mem-phys-addr.py
8c42b9600e56 perf script python: Add Python3 support to net_dropmonitor.py
118af5bf799b perf script python: Add Python3 support to powerpc-hcalls.py
ee75a896ae53 perf script python: Add Python3 support to sctop.py
6d22d9991cf3 perf script python: Add Python3 support to stackcollapse.py
e985bf761db7 perf script python: Add Python3 support to stat-cpi.py
1d1b0dbb859d perf script python: Add Python3 support to syscall-counts.py
de667cce7f4f perf script python: Add Python3 support to syscall-counts-by-pid.py
Bug#941636: udev: 73-usb-net-by-mac.rules breaks systemd.link(5) network interface renaming for usb network adapters
On 2019/10/03 13:34, Michael Biebl wrote:
> Hi
>
> Am 03.10.19 um 10:17 schrieb Benjamin Poirier:
> > Package: udev
> > Version: 243-2
> > Severity: normal
> >
> > /lib/udev/rules.d/73-usb-net-by-mac.rules prevents the renaming of network
> > interfaces from usb adapters using the systemd.link(5) mechanism.
> >
> > The latter is implemented using /lib/udev/rules.d/80-net-setup-link.rules
> > which is ineffective because 73-usb-net-by-mac.rules has previously
> > unconditionally set a name (based on the mac address).
>
> Not quite unconditionally. The conditions are
That's right, thanks for correcting me.
> - user has not disabled persistent interface naming via the kernel
> command line (net.ifnames=0)
systemd.link also checks this kernel option:
"NamePolicy= may be disabled by specifying net.ifnames=0 on the kernel
command line."
> - the interface name has not been provided by user space
> ATTR{name_assign_type}=="3"
We can change the 73-usb-net-by-mac.link I gave as an example to add
"keep":
[Link]
NamePolicy=keep mac
> - NAME= is unset
This is also checked by 80-net-setup-link.rules
> - it has a universally administered (stable) MAC address (second bit
> is 0).
net_setup_link implements the same condition:
"ID_NET_NAME_MAC=prefixxAABBCCDDEEFF
[...] It is available if the device has a fixed MAC address. [...]
"
The check is based on addr_assign_type provided by the kernel. See
src/udev/udev-builtin-net_id.c names_mac().
> - the user has no custom /etc/udev/rules.d/80-net-setup-link.rules or
^^ incorrect
> /etc/systemd/network/99-default.link
This is an incomplete way of reimplementing udev functionality. In
particular, the user will get a different behavior if they do
$ cp /lib/systemd/network/99-default.link /etc/systemd/network/
even though the naming rules are effectively the same.
>
> You are correct though, we do not handle the case where a user has a
> arbitrarily named .link file which is used to rename a USB device.
>
> Fwiw, I've run into this issue myself some time ago, where I created a
> .link file which supposedly was not applied. After some head scratching
> it was then clear that the udev rule file had already renamed the interface.
>
> My solution back then was a
> touch /etc/udev/rules.d/73-usb-net-by-mac.rules (basically what you
> figured out as well)
>
>
> > For example
> > ben@f3:~$ cat /etc/systemd/network/10-dock.link
> > [Match]
> > MACAddress=3c:e1:a1:01:02:03
> >
> > [Link]
> > Name=dock
> > does not work (with the related interface being a usb adapter).
> >
> > I believe that /lib/udev/rules.d/73-usb-net-by-mac.rules should be removed.
> > In
> > fact, the same functionality can be provided by the systemd.link mechanism
> > while also allowing users to override the default rule. I tested this by
> > setting up
> > /etc/udev/rules.d/73-usb-net-by-mac.rules -> /dev/null
> > and adding
> > ben@f3:~$ cat /etc/systemd/network/73-usb-net-by-mac.link
> > [Match]
> > Path=*-usb-*
> >
> > [Link]
> > NamePolicy=mac
> >
> > (Ideally the match would be done using something like Type= but DEVTYPE is
> > not
> > an attribute of the network device. Matching on the ID_BUS udev attribute
> > would work but is not supported by net_setup_link I think.)
I just noticed that 73-usb-net-by-mac.rules matches on
'SUBSYSTEMS=="usb"' which "[searches] the devpath upwards for a matching
device subsystem name." [udev(7)]. I think this is equivalent to the
'Path=*-usb-*' expression in the .link file I suggested.
I still think that match is not ideal, but at least its equivalent in
behavior to 73-usb-net-by-mac.rules.
> >
> > This still used a name based on the mac address by default (instead of based
> > on the slot) and also allowed me to change the name by adding a file like
> > the
> > 10-dock.link example above.
>
>
> Using a .link file is an interesting idea but afaics we can't express
> all the conditions I mentioned above.
> So we would trade one set of corner cases where it doesn't behave as
> expected with another set of corner cases.
> Not sure if we can make everyone happy.
>
> Martin, as main author of 73-usb-net-by-mac.rules, what's your take on this?
>
> Michael
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
signature.asc
Description: Digital signature
Bug#941636: udev: 73-usb-net-by-mac.rules breaks systemd.link(5) network interface renaming for usb network adapters
Package: udev Version: 243-2 Severity: normal /lib/udev/rules.d/73-usb-net-by-mac.rules prevents the renaming of network interfaces from usb adapters using the systemd.link(5) mechanism. The latter is implemented using /lib/udev/rules.d/80-net-setup-link.rules which is ineffective because 73-usb-net-by-mac.rules has previously unconditionally set a name (based on the mac address). For example ben@f3:~$ cat /etc/systemd/network/10-dock.link [Match] MACAddress=3c:e1:a1:01:02:03 [Link] Name=dock does not work (with the related interface being a usb adapter). I believe that /lib/udev/rules.d/73-usb-net-by-mac.rules should be removed. In fact, the same functionality can be provided by the systemd.link mechanism while also allowing users to override the default rule. I tested this by setting up /etc/udev/rules.d/73-usb-net-by-mac.rules -> /dev/null and adding ben@f3:~$ cat /etc/systemd/network/73-usb-net-by-mac.link [Match] Path=*-usb-* [Link] NamePolicy=mac (Ideally the match would be done using something like Type= but DEVTYPE is not an attribute of the network device. Matching on the ID_BUS udev attribute would work but is not supported by net_setup_link I think.) This still used a name based on the mac address by default (instead of based on the slot) and also allowed me to change the name by adding a file like the 10-dock.link example above. -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages udev depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libacl1 2.2.53-5 ii libblkid1 2.34-0.1 ii libc6 2.29-2 ii libkmod2 26-3 ii libselinux1 2.9-2+b2 ii libudev1 243-2 ii systemd-sysv 242-7 ii util-linux2.34-0.1 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: ii systemd 242-7 -- no debconf information
