Bug#1065472: tokodon: wish it would take the mastodon address instead of the instance-url at first use
Package: tokodon Version: 23.04.2-1 Severity: minor Tags: upstream The mastodon address is easily distinguished from an instance URL so the entry field could accept either and work out how to respond. I'm sure I'm not the only person who didn't know what their "instance URL" was. -- System Information: Debian Release: trixie/sid Architecture: arm64 (aarch64) Kernel: Linux 6.6-rockchip (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages tokodon depends on: ii kio 5.107.0-1+b1 ii libc6 2.37-15.1 ii libkf5configcore5 5.107.0-1+b1 ii libkf5configgui55.107.0-1+b1 ii libkf5configwidgets55.107.0-2+b1 ii libkf5coreaddons5 5.107.0-1+b1 ii libkf5dbusaddons5 5.107.0-1+b1 ii libkf5i18n5 5.107.0-1+b1 ii libkf5kiocore5 5.107.0-1+b1 ii libkf5kirigami2-5 5.107.0-1+b1 ii libkf5notifications55.107.0-1+b1 ii libkf5windowsystem5 5.107.0-1+b1 ii libqt5core5a5.15.10+dfsg-7 ii libqt5gui5 5.15.10+dfsg-7 ii libqt5network5 5.15.10+dfsg-7 ii libqt5qml5 5.15.10+dfsg-2+b1 ii libqt5quick55.15.10+dfsg-2+b1 ii libqt5quickcontrols2-5 5.15.10+dfsg-2+b1 ii libqt5websockets5 5.15.10-2+b1 ii libqt5widgets5 5.15.10+dfsg-7 ii libstdc++6 14-20240303-1 ii qml-module-org-kde-kirigami-addons-labs-mobileform 0.9.0-1+b1 ii qml-module-org-kde-kirigami25.107.0-1+b1 ii qml-module-org-kde-kitemmodels 5.107.0-1+b1 ii qml-module-org-kde-sonnet 5.107.0-1+b1 ii qml-module-qt-labs-platform 5.15.10+dfsg-2+b1 ii qml-module-qt-labs-qmlmodels5.15.10+dfsg-2+b1 ii qml-module-qtgraphicaleffects 5.15.10-2+b1 ii qml-module-qtmultimedia 5.15.10-2+b1 ii qml-module-qtquick-controls25.15.10+dfsg-2+b1 ii qml-module-qtquick-dialogs 5.15.10-2+b1 ii qml-module-qtquick-layouts 5.15.10+dfsg-2+b1 ii qml-module-qtquick2 5.15.10+dfsg-2+b1 tokodon recommends no packages. tokodon suggests no packages. -- debconf-show failed
Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
On Mon, Mar 04, 2024 at 10:41:50PM +0100, Salvatore Bonaccorso wrote: > Hi, > > On Mon, Mar 04, 2024 at 01:05:09PM -0700, Jonathan Corbet wrote: > > Salvatore Bonaccorso writes: > > > > > Ok. In the sprit of the stable series rules we might try the later and > > > if it's not feasible pick the first variant? > > > > Well, "the spirit of the stable series" is one of Greg's titles, and he > > said either was good...:) > > here we go. Please let me know if you need anything changed in the > commit message to describe the situation better. > > Greg, in the Fixes tag I added the 5.10.y commit as the issue is > specific to the 5.10.y series. Is this the correct form to note this? Looks good, I'll queue this up after the next round of releases goes out, thanks for the patch! greg k-h
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
severity 1065445 important retitle 1065445 pristine-tar: fails if original tarball top directory name is not - thanks On Mon, Mar 04, 2024 at 08:53:21PM +, Julian Gilbey wrote: > Package: pristine-tar > Version: 1.50+nmu1 > Severity: normal > > I discovered that a package I was trying to use with pristine-tar > failed to work. The cause of the issue seems to be that the upstream > tarball's top directory name is capitalised, but pristine-tar > regenerates a tarball with the name lowercased. > > Steps to reproduce using git-buildpackage: > 1. Import the attached minimal working example into git using the command: >gbp import-dsc --pristine-tar hello_1.0-1.dsc > > 2. Change into the build directory: >cd hello > > 3. Regenerate the original tar ball using pristine-tar, for example: >gbp buildpackage -S > > 4. Return to the parent directory, then: > > $ tar ztf hello_1.0.orig.tar.gz > Hello-1.0/ > Hello-1.0/Makefile > Hello-1.0/hello.c > $ tar ztf build-area/hello_1.0.orig.tar.gz > hello-1.0/ > hello-1.0/Makefile > hello-1.0/hello.c > > Note the capitalisation has changed. Also: > > $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 256 Mar 4 20:46 build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 175 Mar 4 20:00 hello_1.0.orig.tar.gz > > Best wishes, > >Julian It turns out it's actually much more general than this: if the original tarball does not have a top directory named - then pristine-tar fails; it *always* creates a tarball with top directory called this, rather than using the name used by the original upstream tarball. So pristine-tar fails on all such cases, including cases where mk-origtargz has been used to exclude some files. Attached is a minimal example, hello2. Julian hello2_1.0.orig.tar.gz Description: application/gzip Format: 3.0 (quilt) Source: hello2 Binary: hello2 Architecture: any Version: 1.0-1 Maintainer: Julian Gilbey Homepage: Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13) Package-List: hello2 deb unknown optional arch=any Checksums-Sha1: 088958090dae03cbf08b77cd3d4f828a5708f1e4 167 hello2_1.0.orig.tar.gz ee6010e1aaee036ac478acf0b435103befd02ebd 2028 hello2_1.0-1.debian.tar.xz Checksums-Sha256: 2c625982f9b41d456f63c8385a3597c2ff02f2a4e535db802bca7426b2d44947 167 hello2_1.0.orig.tar.gz 187551b3d11623c2e2b984a9701f1fad74c532b2e948892a34a4d8dc28f3d901 2028 hello2_1.0-1.debian.tar.xz Files: 323ce17ab35564a9c31a8e0320f7a069 167 hello2_1.0.orig.tar.gz 12bb0fa03c08e92a450065425d0e570f 2028 hello2_1.0-1.debian.tar.xz hello2_1.0-1.debian.tar.xz Description: application/xz
Bug#1065471: screen-shot
Attached is the screen-shot showing the error. You can see the hover text but not the content. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
On Tue, Mar 05, 2024 at 09:22:37AM +0300, Michael Tokarev wrote: > > Package: qemu-system-data > > Version: 1:8.2.2+ds-1 > > Severity: serious > > > > > > Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ... > > Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ... > > dpkg: error processing archive /var/cache/apt/archives/qemu-system- > > data_1%3a8.2.2+ds-1_all.deb (--unpack): > > trying to overwrite '/usr/share/doc/qemu-system- > > common/system/arm/aspeed.html', which is also in package qemu-system-common > > 1:8.2.1+ds-2 > > Hmm. > > In 8.2.2 I moved common docs from arch-dependent package qemu-system-common > to arch-indep package qemu-system-data. Current control fields for the > latter, among others, has: > > Breaks: qemu-system-common (<< 8.2.1+ds-3~), > Replaces: qemu-system-common (<< 8.2.1+ds-3~), > > so... what's going on here? q-s-d 8.2.2 replaces files from q-s-c 8.2.1 Can it be simply because the package has an epoch and relations should include it? -- WBR, wRAR signature.asc Description: PGP signature
Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition
Control: severity -1 normal On Tue, Feb 06, 2024 at 05:43:41PM +, Mark Hindley wrote: > Whilst I am not an expert on this transition or the abi-compliance-checker, a > quick look at the logs[1] suggests this is a tool configuration issue and > src:consolekit2 may not require t64 migration. > > Can you clarify? I would appreciate some help here. Your patch FTBFS and I need to be convinced it is actually required before spending time on it. In the meantime, downgrading severity to prevent autoremoval. Thanks Mark
Bug#956454: gmsh: ... and also with nouveau_dri.so
Package: gmsh Version: 4.12.1+ds1-1 Followup-For: Bug #956454 Dear Maintainer, same bug (or a very similar one) is stil present in gmsh4.12. Opening a fresh gmsh window (without default untitled.geo file in HOME folder), I am able to navigate, zoom, rotate the view, etc... After adding points and lines seems OK too, but adding a 3D object (e.g., a sphere) makes the gmsh application crash. However the library appears usable using the Python API, as long as no graphical rendering is involved. Example of backtrace of crash: (gdb) bt #0 0x7fffe6f30f60 in ?? () from /lib/x86_64-linux-gnu/libLLVM-17.so.1 #1 0x7fffe6f735f7 in LLVMBuildBitCast () from /lib/x86_64-linux-gnu/libLLVM-17.so.1 #2 0x7fffee112402 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #3 0x7fffee113ceb in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #4 0x7fffee11649b in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #5 0x7fffee0e754c in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #6 0x7fffee09810b in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #7 0x7fffee098bfb in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #8 0x7fffee09c358 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #9 0x7fffee0324cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #10 0x7fffee02b386 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #11 0x7fffee02b815 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #12 0x7fffee02bcbd in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #13 0x7fffedde688d in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #14 0x7fffeddecc8b in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #15 0x7fffedcce552 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #16 0x7fffedcfbeb9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #17 0x775bedef in drawContext::drawSphere(double, double, double, double, int) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #18 0x775af5d2 in drawGRegion::operator()(GRegion*) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #19 0x775ad6dc in drawContext::drawGeom() () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #20 0x775a297b in drawContext::select(int, bool, bool, bool, int, int, int, int, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #21 0x774bd136 in openglWindow::_select(int, bool, bool, bool, int, int, int, int, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&, std::vector >&) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #22 0x774bea3f in openglWindow::handle(int) () from /lib/x86_64-linux-gnu/libgmsh.so.4.12 #23 0x767454c9 in ?? () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #24 0x7672d233 in ?? () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #25 0x7672f47a in Fl::handle_(int, Fl_Window*) () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #26 0x767917aa in fl_wait(double) () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #27 0x7672eb66 in Fl::wait(double) () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #28 0x7672ec25 in Fl::run() () from /lib/x86_64-linux-gnu/libfltk.so.1.3 #29 0x768456ca in __libc_start_call_main (main=main@entry=0x5050 , argc=argc@entry=1, argv=argv@entry=0x7fffdf68) at ../sysdeps/nptl/libc_start_call_main.h:58 #30 0x76845785 in __libc_start_main_impl (main=0x5050 , argc=1, argv=0x7fffdf68, init=, fini=, rtld_fini=, stack_end=0x7fffdf58) at ../csu/libc-start.c:360 #31 0x5081 in _start () -- System Information: Debian Release: trixie/sid APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gmsh depends on: ii libc6 2.37-15 ii libgmsh4.12 4.12.1+ds1-1 Versions of packages gmsh recommends: pn gmsh-doc gmsh suggests no packages. -- no debconf information
Bug#1065471: wike shows a blank screen on PinePhonePro
Package: wike Version: 2.1.0-1 Severity: normal I'll attach a screenshot when the bug is active. It just shows a blank screen regardless of searches or a request for random page or main page. Help text shows that the page in question is loaded just not displayed. The same version running on a laptop with a high resolution display works correctly, so this appears related to the Mobian environment on the PinePhonePro. Something about screen resolution, size or something. -- System Information: Debian Release: trixie/sid Architecture: arm64 (aarch64) Kernel: Linux 6.6-rockchip (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages wike depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1 ii gir1.2-adw-1 1.5~beta-1 ii gir1.2-webkit-6.02.42.5-1 ii python3 3.11.8-1 ii python3-requests 2.31.0+dfsg-1 wike recommends no packages. wike suggests no packages. -- debconf-show failed
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
05.03.2024 10:03, Andrey Rahmatullin wrote: Breaks: qemu-system-common (<< 8.2.1+ds-3~), Replaces: qemu-system-common (<< 8.2.1+ds-3~), so... what's going on here? q-s-d 8.2.2 replaces files from q-s-c 8.2.1 Can it be simply because the package has an epoch and relations should include it? AAARGH! Yes, you're exactly right. Sigh :) Fixing it now, thank you! /mjt
Bug#1065470: RM: ceph [armel armhf i386] -- ROM; 32 bits not supported upstream, too hard to maintain
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: c...@packages.debian.org Control: affects -1 + src:ceph Hi there! We tried to retain 32 bits support for as long as it was possible in this package, but at this point, we (ie: myself and bzed) believe it's not reasonable to continue with it. There's no CI upstream supporting it, and it becomes increasingly difficult to support these small platforms that don't have enough address space to compile without many tricks. I already filled bugs against reverse dependencies, that were linked against librados-dev or librbd-dev, and at this point, it should be all fixed already. If not, bugs can be raised to serious. Note that Ceph 18.2.x still doesn't build against mips64el, and at this point, I'm not sure we will continue to support it, as I don't have the skills, upstream doesn't support it, and nobody is volunteering for help. I'm not sure how to reach porters for help btw. Cheers, Thomas Goirand (zigo)
Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space
Hi Andreas, Thanks for the upload. On 04-03-2024 12:26 p.m., Andreas Beckmann wrote: Control: forwarded -1 https://github.com/KhronosGroup/SPIRV-LLVM-Translator/issues/2397 On 03/03/2024 20.52, Paul Gevers wrote: Source: spirv-llvm-translator-14 Version: 14.0.0-10 In the upstream report you mention it's the same across all versions and yesterday we had the same problem with -15. Will you fix the other versions too? Do you want me to clone this bug for that? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 11:04:23PM +0100, Bastian Blank wrote: > At least to show where it breaks. And I actually tried it and can not show the expected breakage from missing /usr/include in the search path. gcc-13-cross builds fine with only linux-libc-dev/6.7.7-1. | -rw-r--r-- 1 bastian bastian 38157 Mar 5 06:40 ../gcc-13-cross_14_amd64.changes Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
Bug#986265: Fixed Upstream
It looks like this bug was fixed in Plasma 6. I had some time to try Plasma 6 and was unable to reproduce this bug. I plan to close this report when it arrives in unstable/sid.
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
05.03.2024 09:10, Andrey Rahmatullin wrote: Package: qemu-system-data Version: 1:8.2.2+ds-1 Severity: serious Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ... Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ... dpkg: error processing archive /var/cache/apt/archives/qemu-system- data_1%3a8.2.2+ds-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/qemu-system- common/system/arm/aspeed.html', which is also in package qemu-system-common 1:8.2.1+ds-2 Hmm. In 8.2.2 I moved common docs from arch-dependent package qemu-system-common to arch-indep package qemu-system-data. Current control fields for the latter, among others, has: Breaks: qemu-system-common (<< 8.2.1+ds-3~), Replaces: qemu-system-common (<< 8.2.1+ds-3~), so... what's going on here? q-s-d 8.2.2 replaces files from q-s-c 8.2.1 Yes, the version it replaces is a bit off (I planned to upload another 8.2.1 but uploaded 8.2.2 instead), but it should work. WTF? /mjt
Bug#1035749: related bug
On Mon, 8 May 2023 10:18:48 -0700 Carter Smithhart wrote: > https://gitlab.gnome.org/GNOME/mutter/-/issues/2723 another related or > possible dup upstream bug https://gitlab.gnome.org/GNOME/mutter/-/issues/2723 "Crash when dragging something from a XWayland window over a Wayland one" last fix was merged upstream in https://gitlab.gnome.org/GNOME/mutter/-/commit/a86900091de30715da5f2f3181cb5314358e8e13 "wayland: Set compositor when creating MetaWaylandDataSourceXWayland" ie mutter 44.1. This confirms your finding that it should be fixed in mutter 44.1 (in case this was the same bug). I don't know if this bug is present in Debian stable 43.9-0+deb12u1 but it should not be in Debian testing 44.9-1. If you have muttrer above 44.1 in ubuntu can you confirm your issue was fixed, in case your bug is another issue? If it is fixed in 44.1 and not present in 43.9 then the issue is fixed in Debian and this bug report should be closed (even if Ubuntu does not yet ship >= 44.1 as then the issue remains solely on the Ubuntu side). Could you close this report if the issue is not present in the mutter releases shjipped by Debian? Cheers, Alban
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
Package: qemu-system-data Version: 1:8.2.2+ds-1 Severity: serious Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ... Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ... dpkg: error processing archive /var/cache/apt/archives/qemu-system- data_1%3a8.2.2+ds-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/qemu-system- common/system/arm/aspeed.html', which is also in package qemu-system-common 1:8.2.1+ds-2 -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 -- debconf-show failed
Bug#596107: mutter: "Move to another workspace" submenu is not working
TO me this bug is long gone. This bug report should be closed. On Wed, 08 Sep 2010 13:30:11 -0400 Eric Cooper wrote: > Package: mutter > Version: 2.29.0-3 > Severity: normal > > I just replaced metacity with mutter on my system. In the window ops > menu, the submenu for "Move to another workspace" pops up (with the > current workspace grayed out) but doesn't react to the mouse -- > none of the entries highlight or react to mouse clicks. > > However, the submenu *does* respond to up and down arrow keys, and > typing enter selects an entry the way a mouse click should. I am using mutter 45.3-2, so one should check if stable 43.9-0+deb12u1 or oldstable 3.38.6-1~deb11u1 is also fixed in this regards. But the "Move to another workspace" submenu is gone in mutter 45. I have a "move to wokspace left" and "Move to workspace right" Seems to have been reported upstream https://bugzilla.gnome.org/show_bug.cgi?id=597763 " Bug 597763 - With >2 workspaces, Window menu "Move to Another Workspace" menu doesn't work" the fix was pushed to upstream master https://gitlab.gnome.org/GNOME/mutter/-/commit/e590cd2 " Don't screw up the event mask when "managing" our own windows " ie first in mutter tag 2.91.0. Could you close the bug report? Cheers, Alban
Bug#1065463: debootstrap can deal with native dpkg file replacement feature
05.03.2024 03:36, Steven Shiau : Package: debootstrap Version: 1.0.134 Severity: wishlist Dear Maintainer, As mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065394#28 For the moment on Mar/5/2024 in the Debian Sid repository, libuuid1 "Provides: libuuid1t64 (= 2.39.3-9)", and an exact version of libuuid1t64 which is not in repos. libuuid1 and libuuid1t64 have "Replaces:" on each other already. debootstrap should be able to solve the libuuid1t64 dependency by installing libuuid1 only. I think we should not add complexity to debootstrap just to be able to perform a transition like this once in 20+ years. /mjt
Bug#1037124: btop: amusingly high CPU temperature shown on 80 core arm64
Hi Philip! Thanks for reporting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037124 in Debian. The bug you describe is not due to anything in the Debian packaging, but most likely a common bug for upstream https://github.com/aristocratos/btop. Do you have experience in C++ development? Do you want to take a stab in the open source spirit to fix this issue yourself? This command-line tool is pretty simple, and building and rebuilding it yourself while testing that your changes work is relatively trivial if you have any C background. If you end up submitting a PR upstream, please mark this Debian bug as "Forwarded".
Bug#1012611: btop: Problems with rounding and locale when the string must be short. E.g. "1.87 GiB" -> " 1,0G"
Hi Marco! Thanks for reporting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012611 in Debian. The bug you describe is not due to anything in the Debian packaging, but most likely a common bug for upstream https://github.com/aristocratos/btop. Do you have experience in C++ development? Do you want to take a stab in the open source spirit to fix this issue yourself? This command-line tool is pretty simple, and building and rebuilding it yourself while testing that your changes work is relatively trivial if you have any C background. If you end up submitting a PR upstream, please mark this Debian bug as "Forwarded".
Bug#1065468: ITP: python-rpcq -- RPC framework and message specification for Rigetti QCS
Package: wnpp Severity: wishlist Owner: Yogeswaran Umasankar X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com * Package name: python-rpcq Version : 3.11.0 Upstream Contact: Rigetti Computing * URL : https://github.com/rigetti/rpcq * License : Apache-2.0 Programming Lang: Python Description : RPC framework and message specification for Rigetti QCS Asynchronous RPC client-server framework and message specification for Rigetti Quantum Cloud Services (QCS). Implements an efficient transport protocol by using ZeroMQ (ZMQ) sockets and MessagePack (msgpack) serialization. Not intended to be a full-featured replacement for other frameworks like gRPC or Apache Thrift. It is depend for other python packages such as pyquil. I planned to maintain it under DPT, and need sponsorship.
Bug#1065461: libreoffice-common: disabling libreoffice-evolution has moved evolocal.odb to libreoffice-common
Hi, Am 05.03.24 um 00:47 schrieb Andreas Beckmann: Preparing to unpack .../libreoffice-common_4%3a24.2.1-3_all.deb ... Unpacking libreoffice-common (4:24.2.1-3) over (4:24.2.0-1) ... dpkg: error processing archive /var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb (--unpack): trying to overwrite '/usr/lib/libreoffice/presets/database/evolocal.odb', which is also in package libreoffice-evolution 4:24.2.0-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/share/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory Errors were encountered while processing: /var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb I'm not sure whether Breaks+Replaces are the correct solution here, or whether -common should rather not ship the file regardless of (not) building -evolution ... The latter, imho. ifeq "$(ENABLE_EVO2)" "y" mkdir -p $(PKGDIR)-evolution/$(OODIR)/presets/database mkdir -p $(PKGDIR)-evolution/$(OODIR)/share/registry mv $(PKGDIR)-common/$(OODIR)/presets/database/evolocal.odb \ $(PKGDIR)-evolution/$(OODIR)/presets/database else rm -f $(PKGDIR)-common/$(OODIR)/presets/database/evolocal.odb endif Added the else part just now. If you add B+R now, you will also need to add them in the opposite direction once -evolutions gets reenabled. libphonenumber is fixed now, so I can re-enable it now and not have it blocking builds. But I need to do the Replaces: libreoffice-common in -evolution anyways now? Regards, Rene
Bug#1065396: ghostscript: Coordinate uploads for German man page transfer
On Monday, March 4, 2024 11:14:37 A.M. CST Helge Kreutzmann wrote: > Hello Steven, > > Am Sun, Mar 03, 2024 at 10:25:45PM -0600 schrieb Steven Robbins: > > Thanks for the note! > > > > On Sun, 3 Mar 2024 19:59:28 + Helge Kreutzmann > > > I will then add > > > Breaks: ghostscript (< > > Replaces: ghostscript (< > > > > > In my debian/control. I'm a bit lost about the correct version, > > > though. So which version is best for "?" > > > > I rarely deal with these situations, so I may be wrong, but > > I would think the best version is the new one: 10.02.1~dfsg-4. > > Ideally it is the first version which stopped shipping the German man > pages. Maybe you can browse your git history? Git says 10.01.2~dfsg-1. > > OK. You titled the bug "coordinate uploads ...". Do we need to do them > > together - on the same day or something? > > Well, this would be a good idea, to choose roughly the same day, to > avoid uninstallable situations for people living on unstable or testing. > > I'm intending to prepare the next upstream release (and then > immediately the Debian release) on 2024-03-23. OK. Let me know when you do the upload and I'll do ghostscript immediately. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1065467: marisa: FTBFS on loongarch64 as the test case fails
Source: marisa Version: 0.2.6-15 Severity: wishlist Tags: ftbfs User: debian-loonga...@lists.debian.org Usertags: loong64 Dear maintainers, Compiling the marisa failed for loong64 in the Debian Package Auto-Building environment. The error messages is as follows, ``` marisa 0.2.6: tests/test-suite.log # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: base-test === ``` The full build log can be found at https://buildd.debian.org/status/logs.php?pkg=marisa=0.2.6-15=loong64. After analyzing the test case failures, I have fixed wordsize detection for loongarch64 architecture. Please consider the patch (my local patch) I have attached. If you have any questions, you can contact me at any time. BTW, the tests results and build results in my local loong64 ENV are as follows, ``` PASS: io-test PASS: trie-test PASS: vector-test PASS: base-test PASS: marisa-test Testsuite summary for marisa 0.2.6 # TOTAL: 5 # PASS: 5 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 .. make[1]: Leaving directory '/home/zdd/marisa/marisa-0.2.6' dh_md5sums dh_builddeb dpkg-deb: building package 'libmarisa-perl' in '../libmarisa-perl_0.2.6-15_loong64.deb'. dpkg-deb: building package 'libmarisa-perl-dbgsym' in '../libmarisa-perl-dbgsym_0.2.6-15_loong64.deb'. dpkg-deb: building package 'libmarisa-dev' in '../libmarisa-dev_0.2.6-15_loong64.deb'. dpkg-deb: building package 'python3-marisa' in '../python3-marisa_0.2.6-15_loong64.deb'. dpkg-deb: building package 'python3-marisa-dbgsym' in '../python3-marisa-dbgsym_0.2.6-15_loong64.deb'. dpkg-deb: building package 'ruby-marisa-dbgsym' in '../ruby-marisa-dbgsym_0.2.6-15_loong64.deb'. dpkg-deb: building package 'marisa' in '../marisa_0.2.6-15_loong64.deb'. dpkg-deb: building package 'libmarisa0' in '../libmarisa0_0.2.6-15_loong64.deb'. dpkg-deb: building package 'libmarisa0-dbgsym' in '../libmarisa0-dbgsym_0.2.6-15_loong64.deb'. dpkg-deb: building package 'ruby-marisa' in '../ruby-marisa_0.2.6-15_loong64.deb'. dpkg-deb: building package 'marisa-dbgsym' in '../marisa-dbgsym_0.2.6-15_loong64.deb'. dpkg-genbuildinfo -O../marisa_0.2.6-15_loong64.buildinfo dpkg-genchanges -O../marisa_0.2.6-15_loong64.changes ``` thanks, Dandan Zhang Description: Fix wordsize detection for loongarch64 architecture Last-Update: 2024-03-05 --- marisa-0.2.6.orig/include/marisa/base.h +++ marisa-0.2.6/include/marisa/base.h @@ -34,7 +34,7 @@ typedef uint64_t marisa_uint64; ( defined(__sparc__) && defined(__arch64__) ) || \ ( defined(__riscv) && (__riscv_xlen == 64) ) || \ defined(__mips64) || defined(__aarch64__) || defined(__s390x__) || \ -defined(__alpha__) +defined(__alpha__) || defined(__loongarch64) #define MARISA_WORD_SIZE 64 #else // defined(_WIN64), etc. #define MARISA_WORD_SIZE 32
Bug#1065466: fwupd-refresh: Can't start as the user is not created during package installation
Package: fwupd Version: 1.9.13-1 Severity: important Tags: patch User: de...@kali.org Usertags: origin-kali Dear Maintainer, Steps to reproduce: on a clean Debian sid system, install fwupd, then try to start the fwupd-refresh service. It fails with: ``` systemd[1]: Starting fwupd-refresh.service - Refresh fwupd metadata and update motd... (fwupdmgr)[3669]: fwupd-refresh.service: Failed to determine user credentials: No such process systemd[1]: fwupd-refresh.service: Main process exited, code=exited, status=217/USER systemd[1]: fwupd-refresh.service: Failed with result 'exit-code'. systemd[1]: Failed to start fwupd-refresh.service - Refresh fwupd metadata and update motd. ``` The issue is that the fwupd-refresh user doesn't exist, as can be seen with `grep fwupd /etc/passwd`. The bug was introduced with commit 6e3af79c on 2023-10-06, where the adduser command in the fwupd.postinst was dropped, and instead a file /usr/lib/sysusers.d/fwupd.conf was introduced. However it's not enough to install a drop-in file in sysusers.d/, one must also call systemd-sysusers in the postinst script, which is achieved thanks to dh_installsysusers. Please find the fix at: https://salsa.debian.org/efi-team/fwupd/-/merge_requests/14 Thanks, Arnaud
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
[But, there are bugs also in pstops ...]
I noticed bugs related to multiple copies in several places:
- filter/pdftopdf (package cups-filters-core-drivers)
- filter/pstops (package cups-core-drivers)
- backend-available/lpd (package cups)
Please see fixes for the sources of each, below.
Maybe the essence of the issue is in the design of CUPS, so maybe cupsd
or libcups.so, in how filters and backend are asked to produce copies.
I did not change that, but only provide some comments in the source file.
(The issue does not fully affect me, since I use cupsManualCopies off.)
Below the patch file, both as plain-text and as attachment (the latter
hopefully preserving blanks and tabs).
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics University of SydneyAustralia
-
--- cups-2.4.2/backend/lpd.c.ORIG 2022-05-26 16:17:21.0 +1000
+++ cups-2.4.2/backend/lpd.c2024-03-05 14:09:07.739682339 +1100
@@ -214,7 +214,14 @@
format= 'l';
order = ORDER_CONTROL_DATA;
reserve = RESERVE_ANY;
- manual_copies = 1;
+ /* PSz 29 Feb 2024
+ * Set default manual_copies "off".
+ * With manual_copies "on", we simply run the copies together.
+ * Then a job of odd number of pages sent to a duplex printer,
+ * the first page of second copy gets printed on the back of the
+ * last page of the first copy.
+ */
+ manual_copies = 0;
timeout = 300;
contimeout= 7 * 24 * 60 * 60;
@@ -305,7 +312,7 @@
else if (!_cups_strcasecmp(name, "mode") && value[0])
{
/*
-* Set control/data order...
+* Set mode...
*/
if (!_cups_strcasecmp(value, "standard"))
@@ -351,6 +358,13 @@
/*
* Set manual copies...
*/
+ /* PSz 28 Feb 24
+* Should not this be
+* cupsGetOption("manual_copies", num_jobopts, jobopts)
+* or maybe some
+* ppd->manual_copies
+* instead?
+*/
manual_copies = !value[0] || !_cups_strcasecmp(value, "on") ||
!_cups_strcasecmp(value, "yes") ||
@@ -397,7 +411,10 @@
}
}
- if (mode == MODE_STREAM)
+ /* PSz 1 Mar 2024
+ * This override needed only if data from STDIN and in STREAM mode
+ */
+ if (argc == 6 && mode == MODE_STREAM)
order = ORDER_CONTROL_DATA;
/*
@@ -499,7 +516,13 @@
* Queue the job...
*/
- if (argc > 6)
+ /* PSz 27 Feb 2024
+ * Do not (needlessly) ignore number of copies requested.
+ * Surely can do when have file, whether named or our temporary.
+ * Can also do when data from STDIN and STREAM mode, though
+ * not in the manual_copies way.
+ */
+ if (argc > 6 || mode == MODE_STANDARD)
{
if (manual_copies)
{
@@ -511,22 +534,16 @@
manual_copies = 1;
copies= atoi(argv[4]);
}
+ }
-status = lpd_queue(hostname, addrlist, resource + 1, fd, snmp_fd, mode,
- username, title, copies, banner, format, order, reserve,
- manual_copies, timeout, contimeout,
- cupsGetOption("job-originating-host-name", num_jobopts,
-jobopts));
+ status = lpd_queue(hostname, addrlist, resource + 1, fd, snmp_fd, mode,
+ username, title, copies, banner, format, order, reserve,
+manual_copies, timeout, contimeout,
+cupsGetOption("job-originating-host-name", num_jobopts,
+ jobopts));
-if (!status)
- fprintf(stderr, "PAGE: 1 %d\n", atoi(argv[4]));
- }
- else
-status = lpd_queue(hostname, addrlist, resource + 1, fd, snmp_fd, mode,
- username, title, 1, banner, format, order, reserve, 1,
- timeout, contimeout,
- cupsGetOption("job-originating-host-name", num_jobopts,
-jobopts));
+ if (!status)
+fprintf(stderr, "PAGE: 1 %d\n", atoi(argv[4]));
/*
* Remove the temporary file if necessary...
@@ -956,6 +973,10 @@
* Next, open the print file and figure out its size...
*/
+/* PSz 1 Mar 2024
+ * Are we sure to get a non-zero print_fd when have file:
+ * do we "really know" that we were invoked with STDIN open?
+ */
if (print_fd)
{
/*
@@ -1019,13 +1040,18 @@
cptr += strlen(cptr);
}
-while (copies > 0)
+/* PSz 28 Feb 2024
+ * Check size remaining, do not blow with too many copies
+ */
+while (copies > 0 && ((sizeof(control) - (size_t)(cptr - control)) > 256))
{
snprintf(cptr, sizeof(control) - (size_t)(cptr - control),
"%cdfA%03d%.15s\n",
format, (int)getpid() % 1000, localhost);
cptr += strlen(cptr);
copies --;
}
+if (copies > 0)
+ fprintf(stderr, "DEBUG: Limited by control size, %d copies
Bug#1065465: sysstat: debian/copyright points to invalid page
Package: sysstat Version: 12.7.5-2 ``` 0 dkg@alice:~$ grep Source /usr/share/doc/sysstat/copyright Source: http://sebastien.godard.pagesperso-orange.fr/ 0 dkg@alice:~$ ``` but when i visit that page, i get redirected to https://end.pagesperso-orange.fr/ , which currently offers the following text: > Arrêt du service Pages perso > > Le service est définitivement fermé depuis le 05 septembre 2023. > La récupération de vos fichiers ainsi que la création de redirections d’URL > est fermée depuis le 09 janvier 2024. > La redirection sera active jusqu'au 05 septembre 2024 sous réserve que vous > soyez toujours client Orange Internet. > > Merci de votre compréhension. Sounds like it should be repointed somewhere like https://sysstat.github.io/ --dkg signature.asc Description: PGP signature
Bug#1064981: Breaks autopkgtest suite of systemd and multipath-tools
Control: severity -1 important Hi On Wed, 28 Feb 2024 18:49:00 +0100 Michael Biebl wrote: Source: lvm2 Version: 2.03.22-1 Severity: serious Hi, filing this issue with severity RC to prevent testing migration. It appears the new LVM release breaks both systemd and multipath-tools's autopkgtest suite https://ci.debian.net/packages/m/multipath-tools/testing/amd64/43382441/ https://github.com/systemd/systemd/issues/31517 After further investigation, the failure in multipath-tools turned out to be a result of https://salsa.debian.org/linux-blocks-team/multipath-tools/-/blob/master/debian/patches/0002-11-dm-mpath-fix-DM_UDEV_RULES_VSN-check.patch?ref_type=heads So far this patch had been necessary, since lvm2 itself had modified the udev rules downstream, but no longer does that thankfully with the latest update. See the remarks in https://github.com/systemd/systemd/issues/31517#issuecomment-1971788035 Chris updated multipath-tools accordingly: https://salsa.debian.org/linux-blocks-team/multipath-tools/-/commit/902a13b2c628d2cfde74cb78fd1ba4425af3d7d4 and uploaded it as 0.9.7-6. With that, multipath-tools and systemd's autopkgtest are unbroken again. I'm still keeping the bug report open, as you might consider adding a versioned breaks against multipath-tools to dmsetup. Downgrading to non-RC now though. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062218: libaio: NMU diff for 64-bit time_t transition
Hi! On Mon, 2024-03-04 at 13:51:19 +0100, Guillem Jover wrote: > I've got all the upstream changes now ready, except that there's still > one test case failing, something wrong with the sigset_t type. I've run > out of time trying to track this down, but I've pushed what I have on > the pu/time64 branch, and will continue later today. In the end this looks like Linux has a broken io_pgetevents_tiem64() syscall on 32-bit userland running on 64-bit kernels. The syscall works fine on 32-bit kernels though. I've disabled this for now given that the time_t usage is for relative timeouts anyway, and because the library ABI now will use proper types, and the underlying implementation can be fixed after a while once I've looked into fixing the compat syscall in Linux. I'm preparing an upload right now with a SONAME bump. Thanks, Guillem
Bug#1064548: tracker-miners: bmp-basic-1 test fails on big-endian
Control: severity -1 important I have skipped this test on big-endian, but this issue still ought to be investigated. Also, we already are skipping audio tests on these architectures. Thank you, Jeremy Bícha
Bug#1065464: tracker: 3.7 failing autopkgtest
Source: tracker Version: 3.5.3-1 Severity: serious Tags: experimental Control: affects -1 src:tracker-miners I believe I have fixed all the blocking issues to update tracker and tracker-miners in Unstable except for its failing autopkgtest. Its autopkgtest has apparently been failing since at least 3.5.3. I am confused because the autopkgtest appears to be nearly identical to what is run during the build by dh_auto_test which does pass. https://ci.debian.net/packages/t/tracker/unstable/amd64/ https://salsa.debian.org/gnome-team/tracker/-/pipelines Thank you, Jeremy Bícha
Bug#1065463: debootstrap can deal with native dpkg file replacement feature
Package: debootstrap Version: 1.0.134 Severity: wishlist Dear Maintainer, As mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065394#28 For the moment on Mar/5/2024 in the Debian Sid repository, libuuid1 "Provides: libuuid1t64 (= 2.39.3-9)", and an exact version of libuuid1t64 which is not in repos. libuuid1 and libuuid1t64 have "Replaces:" on each other already. debootstrap should be able to solve the libuuid1t64 dependency by installing libuuid1 only. Otherwise now if the following command is run: $ sudo debootstrap --verbose --arch=amd64 sid sid-chroot The debootstrap will fail at this: I: Extracting libunistring5... I: Extracting libuuid1... I: Extracting libuuid1t64... E: Tried to extract package, but tar failed. Exit... and the log shows: $ tail sid-chroot/debootstrap/debootstrap.log Saving to: ‘sid-chroot//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb’ 0K .. .. .. .. .. 58% 845K 0s 50K .. .. .. . 100% 2.39M=0.07s 2024-03-03 10:33:06 (1.13 MB/s) - ‘sid-chroot//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb’ saved [87580/87580] tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to ‘libuuid.so.1.3.0’: File exists tar: Exiting with failure status due to previous errors -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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 debootstrap depends on: ii wget 1.21.3-1+b2 Versions of packages debootstrap recommends: ii arch-test 0.20-1 ii debian-archive-keyring 2023.3+deb12u1 ii gnupg 2.2.40-1.1 ii mount 2.38.1-5+b1 Versions of packages debootstrap suggests: ii binutils 2.40-2 pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2020.06.17.1-1 ii xz-utils 5.4.1-0.2 ii zstd 1.5.4+dfsg2-5 -- no debconf information -- Steven Shiau Public Key Server PGP Key ID: 4096R/163E3FB0 Fingerprint: EB1D D5BF 6F88 820B BCF5 356C 8E94 C9CD 163E 3FB0 -- Steven Shiau Public Key Server PGP Key ID: 4096R/163E3FB0 Fingerprint: EB1D D5BF 6F88 820B BCF5 356C 8E94 C9CD 163E 3FB0
Bug#1065462: ITP: netconsd -- The Netconsole Daemon
Package: wnpp Severity: wishlist Owner: Michel Lind X-Debbugs-Cc: debian-de...@lists.debian.org, mic...@michel-slm.name * Package name: netconsd Version : 0.4 Upstream Contact: Dave Jones * URL : https://github.com/facebook/netconsd * License : BSD Programming Lang: C Description : The Netconsole Daemon This is a daemon for receiving and processing logs from the Linux Kernel, as emitted over a network by the kernel's netconsole module. It supports both the old "legacy" text-only format, and the new extended format added in v4.4. The core of the daemon does nothing but process messages and drop them: in order to make the daemon useful, the user must supply one or more "output modules". These modules are shared object files which expose a small ABI that is called by netconsd with the content and metadata for netconsole messages it receives.
Bug#996202: EFI Secure Boot for systemd-boot
On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > > Hey folks, > > On Mon, Mar 04, 2024 at 02:13:25AM +, Luca Boccassi wrote: > >On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank > >wrote: > >> Hi > >> > >> I'm rescinding this request. I've got a working prototype, but I > >don't > >> know where this would go. > >> > >> Bastian > > > >The upstream Shim reviewers group now accepts systemd-boot as a 2nd > >stage bootloader, trusted by Shim builds signed with the UEFI 3rd party > >CA. This clears the way for Debian's CA to sign systemd-boot, so I am > >reopening this bug. > > > >shim-review questionnaire update that allows systemd-boot: > > > >https://github.com/rhboot/shim-review/pull/357 > > > >MR on Salsa to add the usual template package, adapted from Bastian's > >MR from a couple of years ago: > > > >https://salsa.debian.org/systemd-team/systemd/-/merge_requests/252 > > > >Debian Shim maintainers, who do we need to seek approvals for this to > >happen? Shim maintainers first of course, anybody else? Release team? > >FTP team? > > OK, I can see what you're doing with templating here, and it looks > clear and obvious. But: this seems to be for standalone systemd-boot > rather than UKI? I thought UKI was the preferred way forward? When you have a headless system then yeah you can go straight to from a first stage to a UKI - but for any end-user system, sd-boot provides the graphical menu with entry selection and so on, which makes it very desirable for those use cases, so it's the natural first step. UKIs are a mean to ship initrd+kernel, but we need to build the initrd first, and we are quite far from there. I don't know yet how that will look like in details for Debian, we had some ideas, but nothing concrete so far, as it's an infrastructure question. When there's something, it won't be from src:systemd as that just builds the stub component. So I'm starting with the boot menu component, which can already be used with more traditional Type #1 third stages - config file plus signed kernel and ye olde initrd cpio. > I'm a little surprised to see you adding riscv64 stuff - AFAIK there's > nobody (yet) providing any root CA for riscv64? We certainly haven't > done anything with it in Debian yet. We build sd-boot for it, so I added it without thinking - but there's no shim so yeah, there's no point, I've dropped it now, thanks for pointing that out. I see there's an upstream PR for it: https://github.com/rhboot/shim/pull/641 so might add it back if that ends up being built after the next upstream release. > What's your plan for installing as the secondary boot loader for shim > to call? 'bootctl update' already recognises and prefers foo.efi.signed if present, so installing to the ESP is easy (PR still doesn't add the call, will probably add a trigger). But as you know Shim right now compiles in the filename of the second stage, so for now interested testers will have to manually rename the file in the ESP from systemd-bootx64.efi to grubx64.efi, which is of course not ideal - let's call it a technological preview. Fortunately as you might have heard in one of the meetings there's a PR in progress to let Shim be configured at runtime: https://github.com/rhboot/shim/pull/608 I hope we can get that sorted before Trixie freezes, and that's how I see the integration ultimately work. > Modulo those questions, let's talk infrastructure. Off the top of my > head, in no particular order... > > * We'll need to create a new intermediate signing cert for > systemd-boot (and another for UKI, I guess). Given recent > discussions about changing the way we build and sign kernels, we > should also generate a new signer cert for those too. And if we're > going that far, we may as well generate a complete new set of 2024 > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA about > doing this piece. That makes sense to me, I guess DSA owns the machinery to do this? > * We'll probably need to add things to the signing setup for > ftp-master. Nothing earth-shattering, just some config to > recognise the new set of packages IIRC. I'm sure Bastian can > manage this. :-) > > * Are people from the team ready to deal with long-term security > support for the systemd-boot chain? Speaking for myself, yes, I am already part of the team who is responsible for that upstream, and I plan to be very strict about not carrying downstream patches for the signed components outside of security fixes (and even then, prefer upstream stable point releases that I am also responsible for anyway). > That's all I can think of for now, but I wouldn't be surprised if more > comes to mind tomorrow... :-) Thanks for the feedback!
Bug#1065461: libreoffice-common: disabling libreoffice-evolution has moved evolocal.odb to libreoffice-common
Package: libreoffice-common Version: 4:24.2.1-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts fileconflict Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../libreoffice-common_4%3a24.2.1-3_all.deb ... Unpacking libreoffice-common (4:24.2.1-3) over (4:24.2.0-1) ... dpkg: error processing archive /var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb (--unpack): trying to overwrite '/usr/lib/libreoffice/presets/database/evolocal.odb', which is also in package libreoffice-evolution 4:24.2.0-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) rmdir: failed to remove '/var/lib/libreoffice/share/prereg/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/share/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory Errors were encountered while processing: /var/cache/apt/archives/libreoffice-common_4%3a24.2.1-3_all.deb I'm not sure whether Breaks+Replaces are the correct solution here, or whether -common should rather not ship the file regardless of (not) building -evolution ... If you add B+R now, you will also need to add them in the opposite direction once -evolutions gets reenabled. cheers, Andreas libreoffice-evolution=4:24.2.0-1_libreoffice-common=4:24.2.1-3.log.gz Description: application/gzip
Bug#1065460: uwsgi: the package fails to build from source due to missing 'plugins/rack_ruby32'
Source: uwsgi Version: 2.0.22-4 Severity: serious Tags: ftbfs Dear Maintainer, The package fails to build in sid chroot with the following error: -- *** uWSGI building and linking plugin plugins/rack_ruby32 *** Error: unable to find directory 'plugins/rack_ruby32' make: *** [debian/rules:429: debian/stamp-uwsgi-plugin-rack-ruby3.2] Error 1 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Build finished at 2024-03-04T23:36:17Z Finished -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-21-generic (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#996202: EFI Secure Boot for systemd-boot
Hey folks, On Mon, Mar 04, 2024 at 02:13:25AM +, Luca Boccassi wrote: >On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank >wrote: >> Hi >> >> I'm rescinding this request. I've got a working prototype, but I >don't >> know where this would go. >> >> Bastian > >The upstream Shim reviewers group now accepts systemd-boot as a 2nd >stage bootloader, trusted by Shim builds signed with the UEFI 3rd party >CA. This clears the way for Debian's CA to sign systemd-boot, so I am >reopening this bug. > >shim-review questionnaire update that allows systemd-boot: > >https://github.com/rhboot/shim-review/pull/357 > >MR on Salsa to add the usual template package, adapted from Bastian's >MR from a couple of years ago: > >https://salsa.debian.org/systemd-team/systemd/-/merge_requests/252 > >Debian Shim maintainers, who do we need to seek approvals for this to >happen? Shim maintainers first of course, anybody else? Release team? >FTP team? OK, I can see what you're doing with templating here, and it looks clear and obvious. But: this seems to be for standalone systemd-boot rather than UKI? I thought UKI was the preferred way forward? I'm a little surprised to see you adding riscv64 stuff - AFAIK there's nobody (yet) providing any root CA for riscv64? We certainly haven't done anything with it in Debian yet. What's your plan for installing as the secondary boot loader for shim to call? Modulo those questions, let's talk infrastructure. Off the top of my head, in no particular order... * We'll need to create a new intermediate signing cert for systemd-boot (and another for UKI, I guess). Given recent discussions about changing the way we build and sign kernels, we should also generate a new signer cert for those too. And if we're going that far, we may as well generate a complete new set of 2024 certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA about doing this piece. * We'll probably need to add things to the signing setup for ftp-master. Nothing earth-shattering, just some config to recognise the new set of packages IIRC. I'm sure Bastian can manage this. :-) * Are people from the team ready to deal with long-term security support for the systemd-boot chain? That's all I can think of for now, but I wouldn't be surprised if more comes to mind tomorrow... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#1065459: rust-smol - upcoming rust-nix update.
Package: rust-smol
I am currently preparing to update the rust-nix pacakge to version 0.27.
The smol crate has a dev-dependency on the nix crate, which the Debian
packaging translates to build and autopkgtest dependencies. After
relaxing the dependencies to allow the new version.
The new rust-nix package is available in experimental. A debdiff
is attached.diff -Nru rust-smol-1.3.0/debian/changelog rust-smol-1.3.0/debian/changelog
--- rust-smol-1.3.0/debian/changelog2024-02-01 19:28:09.0 +
+++ rust-smol-1.3.0/debian/changelog2024-03-04 23:06:03.0 +
@@ -1,3 +1,10 @@
+rust-smol (1.3.0-5.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Allow building with nix 0.27.
+
+ -- Peter Michael Green Mon, 04 Mar 2024 23:06:03 +
+
rust-smol (1.3.0-5) unstable; urgency=medium
* add patches 2001_async_* to accept older crates;
diff -Nru rust-smol-1.3.0/debian/control rust-smol-1.3.0/debian/control
--- rust-smol-1.3.0/debian/control 2024-02-01 19:14:29.0 +
+++ rust-smol-1.3.0/debian/control 2024-03-04 23:06:00.0 +
@@ -24,7 +24,7 @@
librust-hyper-0.14+stream-dev ,
librust-inotify-0-dev (<< 0.11) ,
librust-native-tls-0.2+default-dev ,
- librust-nix-0+default-dev (<< 0.27) ,
+ librust-nix-0+default-dev (<< 0.28) ,
librust-nix-0+default-dev (>= 0.23) ,
librust-signal-hook-0.3+default-dev ,
librust-tempfile-3+default-dev ,
diff -Nru rust-smol-1.3.0/debian/patches/1001_nix.patch
rust-smol-1.3.0/debian/patches/1001_nix.patch
--- rust-smol-1.3.0/debian/patches/1001_nix.patch 2023-08-20
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/1001_nix.patch 2024-03-04
23:05:13.0 +
@@ -10,7 +10,7 @@
[target.'cfg(target_os = "linux")'.dev-dependencies]
inotify = { version = "0.10", default-features = false }
-nix = "0.24"
-+nix = ">= 0.24, < 0.27"
++nix = ">= 0.24, < 0.28"
timerfd = "1"
[target.'cfg(windows)'.dev-dependencies]
diff -Nru rust-smol-1.3.0/debian/patches/2001_inotify.patch
rust-smol-1.3.0/debian/patches/2001_inotify.patch
--- rust-smol-1.3.0/debian/patches/2001_inotify.patch 2023-08-20
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/2001_inotify.patch 2024-03-04
23:05:51.0 +
@@ -13,5 +13,5 @@
[target.'cfg(target_os = "linux")'.dev-dependencies]
-inotify = { version = "0.10", default-features = false }
+inotify = { version = ">= 0.9, < 0.11", default-features = false }
- nix = ">= 0.24, < 0.27"
+ nix = ">= 0.24, < 0.28"
timerfd = "1"
diff -Nru rust-smol-1.3.0/debian/patches/2001_windows.patch
rust-smol-1.3.0/debian/patches/2001_windows.patch
--- rust-smol-1.3.0/debian/patches/2001_windows.patch 2023-08-20
08:25:51.0 +
+++ rust-smol-1.3.0/debian/patches/2001_windows.patch 2024-03-04
23:05:33.0 +
@@ -8,7 +8,7 @@
+++ b/Cargo.toml
@@ -50,6 +50,3 @@
inotify = { version = "0.10", default-features = false }
- nix = ">= 0.24, < 0.27"
+ nix = ">= 0.24, < 0.28"
timerfd = "1"
-
-[target.'cfg(windows)'.dev-dependencies]
Bug#1065421: extrepo-offline-data: Gitlab GPG key is expired
Hello Maximilian, it's updated in https://salsa.debian.org/extrepo-team/extrepo-data/-/merge_requests/273 And right now, I'm waiting for https://salsa.debian.org/extrepo-team/extrepo-data/-/merge_requests/274 Best Regards, Juri Grabowski
Bug#1065343: closed by Bo YU (Re: #1065343: libuuid1t64 overwrite)
Hi, On Mon, Mar 04, 2024 at 10:45:41AM +0100, Chris Hofstaedtler wrote: debootstrap still has issue: ``` ... tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to ‘libuuid.so.1.3.0’: File exists tar: Exiting with failure status due to previous errors ``` Anyone's help in assessing when this issue(t64 transition break debootstrap on sid) will be resolved would be appreciated! There is nothing we can do now, that is not already on the todo list of the people working on the transition. Just be patient. It is, after all, unstable. Thanks. Not rush, just hope people to be noteed about the issue.:) I just reopen the bug given the currently status. Once fixed, I will close it again. Hope #1036884 helps. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#185 I'm told that other chroot-creation tools might not have this problem (i.e. mmdebstrap). Chris -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1065458: gcc-14-offload-amdgcn: Can't compile anything with x86_64-linux-gnu-accel-amdgcn-amdhsa-gcc-14
Package: gcc-14-offload-amdgcn
Version: 14-20240303-1
Severity: important
X-Debbugs-Cc: sob...@sobkas.io
Dear Maintainer,
When I try to compile cod using gcc amdgpu offload capability I'm
getting:
x86_64-linux-gnu-accel-amdgcn-amdhsa-gcc-14 -march=gfx1030 -
mtune=gfx1030
-fopenmp ./a.c
x86_64-linux-gnu-accel-amdgcn-amdhsa-gcc-14: fatal error: cannot
execute 'cc1':
posix_spawnp: No such file or directory
code:
#include
#include
int main()
{
printf("There are %d devices",omp_get_num_devices());
}
Is this behavior expected?
Thanks
-- System Information:
Debian Release: trixie/sid
APT prefers experimental
APT policy: (502, 'experimental'), (501, 'unstable'), (500,
'unstable-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.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 gcc-14-offload-amdgcn depends on:
ii amdgcn-tools 17
ii gcc-14 14-20240303-1
ii gcc-14-base 14-20240303-1
ii libc6 2.38-6
ii libc6-dev 2.38-6
ii libgmp10 2:6.3.0+dfsg-2+b1
ii libgomp-plugin-amdgcn1 14-20240303-1
ii libmpc3 1.3.1-1+b2
ii libmpfr6 4.2.1-1+b1
ii libzstd1 1.5.5+dfsg2-2
ii zlib1g 1:1.3.dfsg-3.1
gcc-14-offload-amdgcn recommends no packages.
gcc-14-offload-amdgcn suggests no packages.
-- no debconf information
Bug#1065457: openzwave: FTBFS: dh_install: error: missing files, aborting
Source: openzwave Version: 1.6.1914+ds-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org, bdr...@debian.org https://buildd.debian.org/status/fetch.php?pkg=openzwave=amd64=1.6.1914%2Bds-1.1=1709295262=0 # install docs in /usr/share/doc/openzwave/, not openzwave-VERSION install -d debian/libopenzwave-doc/usr/share/doc make[1]: Leaving directory '/<>' dh_install -a install -m0755 -d debian/libopenzwave1.6t64//etc/openzwave cp --reflink=auto -a debian/tmp/etc/openzwave/2gig debian/tmp/etc/openzwave/BeNext debian/tmp/etc/openzwave/Localization.xml debian/tmp/etc/openzwave/Localization.xsd debian/tmp/etc/openzwave/NotificationCCTypes.xml debian/tmp/etc/openzwave/NotificationCCTypes.xsd debian/tmp/etc/openzwave/SensorMultiLevelCCTypes.xml debian/tmp/etc/openzwave/SensorMultiLevelCCTypes.xsd debian/tmp/etc/openzwave/abus debian/tmp/etc/openzwave/act debian/tmp/etc/openzwave/aeotec debian/tmp/etc/openzwave/airlinemechanical debian/tmp/etc/openzwave/alfred debian/tmp/etc/openzwave/assa_abloy debian/tmp/etc/openzwave/august debian/tmp/etc/openzwave/buffalo debian/tmp/etc/openzwave/building36 debian/tmp/etc/openzwave/comfort debian/tmp/etc/openzwave/config-template.xml debian/tmp/etc/openzwave/connecthome debian/tmp/etc/openzwave/cooper debian/tmp/etc/openzwave/danfoss debian/tmp/etc/openzwave/device_classes.xml debian/tmp/etc/openzwave/device_classes.xsd debian/tmp/etc/openzwave/device_configuration.xsd debian/tmp/etc/openzwave/devolo debian/tmp/etc/openzwave/diehlcontrols debian/tmp/etc/openzwave/dlink debian/tmp/etc/openzwave/dome debian/tmp/etc/openzwave/domitech debian/tmp/etc/openzwave/domux debian/tmp/etc/openzwave/dragontech debian/tmp/etc/openzwave/duco debian/tmp/etc/openzwave/duwi debian/tmp/etc/openzwave/ecodim debian/tmp/etc/openzwave/ecolink debian/tmp/etc/openzwave/econet debian/tmp/etc/openzwave/electronicsolutions debian/tmp/etc/openzwave/enblink debian/tmp/etc/openzwave/enerwave debian/tmp/etc/openzwave/eurotronic debian/tmp/etc/openzwave/everspring debian/tmp/etc/openzwave/everspringct debian/tmp/etc/openzwave/evolve debian/tmp/etc/openzwave/fakro debian/tmp/etc/openzwave/fibaro debian/tmp/etc/openzwave/firstalert debian/tmp/etc/openzwave/followgood debian/tmp/etc/openzwave/forest debian/tmp/etc/openzwave/fortrezz debian/tmp/etc/openzwave/frostdale debian/tmp/etc/openzwave/ge debian/tmp/etc/openzwave/gocontrol debian/tmp/etc/openzwave/goodway debian/tmp/etc/openzwave/gr debian/tmp/etc/openzwave/graber debian/tmp/etc/openzwave/greenwave debian/tmp/etc/openzwave/guardtec debian/tmp/etc/openzwave/hab debian/tmp/etc/openzwave/hank debian/tmp/etc/openzwave/heiman debian/tmp/etc/openzwave/heltun debian/tmp/etc/openzwave/homeseer debian/tmp/etc/openzwave/honeywell debian/tmp/etc/openzwave/horstmann debian/tmp/etc/openzwave/icare debian/tmp/etc/openzwave/idlock debian/tmp/etc/openzwave/images debian/tmp/etc/openzwave/ingersoll debian/tmp/etc/openzwave/inovelli debian/tmp/etc/openzwave/intermatic debian/tmp/etc/openzwave/iris debian/tmp/etc/openzwave/iwatsu debian/tmp/etc/openzwave/jasco debian/tmp/etc/openzwave/kaipule debian/tmp/etc/openzwave/kwikset debian/tmp/etc/openzwave/leviton debian/tmp/etc/openzwave/linear debian/tmp/etc/openzwave/logicsoft debian/tmp/etc/openzwave/manufacturer_specific.xml debian/tmp/etc/openzwave/manufacturer_specific.xsd debian/tmp/etc/openzwave/mcohome debian/tmp/etc/openzwave/merten debian/tmp/etc/openzwave/miyakawaelectric debian/tmp/etc/openzwave/namron debian/tmp/etc/openzwave/nei debian/tmp/etc/openzwave/nexia debian/tmp/etc/openzwave/nodon debian/tmp/etc/openzwave/northq debian/tmp/etc/openzwave/oomi debian/tmp/etc/openzwave/options.xml debian/tmp/etc/openzwave/options.xsd debian/tmp/etc/openzwave/permundo debian/tmp/etc/openzwave/philio debian/tmp/etc/openzwave/polycontrol debian/tmp/etc/openzwave/popp debian/tmp/etc/openzwave/prowell debian/tmp/etc/openzwave/q-light debian/tmp/etc/openzwave/qees debian/tmp/etc/openzwave/qolsys debian/tmp/etc/openzwave/qubino debian/tmp/etc/openzwave/quby debian/tmp/etc/openzwave/rcs debian/tmp/etc/openzwave/remotec debian/tmp/etc/openzwave/ring debian/tmp/etc/openzwave/schlage debian/tmp/etc/openzwave/schlagelink debian/tmp/etc/openzwave/sensative debian/tmp/etc/openzwave/sercomm debian/tmp/etc/openzwave/shenzen_neo debian/tmp/etc/openzwave/shenzen_saykey debian/tmp/etc/openzwave/simon debian/tmp/etc/openzwave/smartthings debian/tmp/etc/openzwave/somfy debian/tmp/etc/openzwave/steinel debian/tmp/etc/openzwave/stelpro debian/tmp/etc/openzwave/sunricher debian/tmp/etc/openzwave/swiid debian/tmp/etc/openzwave/technisat debian/tmp/etc/openzwave/telldus debian/tmp/etc/openzwave/there debian/tmp/etc/openzwave/thermofloor debian/tmp/etc/openzwave/trane debian/tmp/etc/openzwave/vera debian/tmp/etc/openzwave/vision debian/tmp/etc/openzwave/vitrum
Bug#1065456: python3.11: Please don't enable dtrace on hurd
Package: python3.11 Version: 3.11.8-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, python3.11 currently fails to build on hurd-any because debian/rules enables dtrace, which is not available on hurd-any. Could you apply the attached patch that fixes this, on python3.11 as well as on python3.12? Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 python3.11 depends on: ii libpython3.11-stdlib 3.11.8-1 ii media-types 10.1.0 ii mime-support 3.66 ii python3.11-minimal3.11.8-1 Versions of packages python3.11 recommends: ii ca-certificates 20240203 Versions of packages python3.11 suggests: ii binutils 2.42-3 pn python3.11-doc ii python3.11-venv 3.11.8-1 -- no debconf information -- Samuel --- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. --- debian/rules.orig 2024-03-03 10:23:40.0 +0100 +++ debian/rules2024-03-04 23:54:06.808627222 +0100 @@ -441,7 +441,6 @@ --with-computed-gotos \ --without-ensurepip \ --with-system-expat \ - --with-dtrace \ --with-ssl-default-suites=openssl \ --with-wheel-pkg-dir=/usr/share/python-wheels/ \ --with-ssl-default-suites=openssl \ @@ -453,6 +452,10 @@ common_configure_args += --with-system-ffi endif +ifeq (,$(filter $(DEB_HOST_ARCH_OS), hurd)) + common_configure_args += --with-dtrace +endif + ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) common_configure_args += --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) common_configure_args += --with-build-python
Bug#1065174: incus: VM agent isn't injected if /etc/environment sets PATH
Control: tags -1 + confirmed pending Thanks for the report -- I've moved setting $PATH from the service files to /etc/default/incus which is then read in via another EnvironmentFile statement. https://salsa.debian.org/go-team/packages/incus/-/commit/33e55353824a7bb0781f362ae3babb8932d84fef Mathias signature.asc Description: This is a digitally signed message part
Bug#1061516: Please add a sshd@.service template for socket activation
On Wed, Feb 28, 2024 at 01:17:32AM +0100, Marco d'Itri wrote: > On Jan 25, Marco d'Itri wrote: > > systemd currently expects the template to be named sshd@.service > > (because that is what Fedora uses), but if you prefer to keep the > > ssh@.service name then I suppose that we could patch systemd as well. > > Is there any way I can help with this? > The major issue is deciding how you want the template to be called. Does this patch look workable? It mostly just resurrects the template unit we used to ship, under a different name. diff --git a/debian/changelog b/debian/changelog index 873dddcfa..78863e039 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,14 @@ +openssh (1:9.6p1-5) UNRELEASED; urgency=medium + + * Restore systemd template unit for per-connection sshd instances, +although without any corresponding .socket unit for now; this is mainly +for use with the forthcoming systemd-ssh-generator (closes: #1061516). +It's now called sshd@.service, since unlike the main service there's no +need to be concerned about compatibility with the slightly confusing +"ssh" service name that Debian has traditionally used. + + -- Colin Watson Sun, 03 Mar 2024 19:49:58 + + openssh (1:9.6p1-4) unstable; urgency=medium * Add sshd_config checksums for 1:9.2p1-1 to ucf reference file, and add a diff --git a/debian/openssh-server.install b/debian/openssh-server.install index cf86dce41..5bf99be16 100755 --- a/debian/openssh-server.install +++ b/debian/openssh-server.install @@ -14,6 +14,7 @@ debian/openssh-server.ufw.profile => etc/ufw/applications.d/openssh-server debian/systemd/ssh.service lib/systemd/system debian/systemd/ssh.socket lib/systemd/system debian/systemd/rescue-ssh.target lib/systemd/system +debian/systemd/sshd@.service lib/systemd/system debian/systemd/ssh-session-cleanup usr/lib/openssh # dh_apport would be neater, but at the time of writing it isn't in unstable diff --git a/debian/systemd/sshd@.service b/debian/systemd/sshd@.service new file mode 100644 index 0..29864a800 --- /dev/null +++ b/debian/systemd/sshd@.service @@ -0,0 +1,12 @@ +[Unit] +Description=OpenBSD Secure Shell server per-connection daemon +Documentation=man:sshd(8) man:sshd_config(5) +After=auditd.service + +[Service] +EnvironmentFile=-/etc/default/ssh +ExecStart=-/usr/sbin/sshd -i $SSHD_OPTS +StandardInput=socket +RuntimeDirectory=sshd +RuntimeDirectoryPreserve=yes +RuntimeDirectoryMode=0755 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1036884: 64-bit time_t: libuuid1t64 -> libuuid1
On 2024-03-04 23:16:02 +0100, Chris Hofstaedtler wrote: > Hi, > > please schedule binNMUs for these source packages to transition back > from libuuid1t64 to libuuid1. Note that I've built this list based > on the amd64 Packages file. I'm not sure if skipping armel, armhf > would be helpful or not at this time. > > The notable thing is e2fsprogs on archs where the ABI didn't change, > to possibly help debootstrap find the correct package set. > > e2fsprogs > gsequencer > hwinfo > lib3mf > netplan.io > obs-studio > ola > optee-client > pacemaker > parted > rasqal > reiserfsprogs > scitokens-cpp > seafile > tpm2-tss > xen > xplc > xrootd Scheduled Cheers -- Sebastian Ramacher
Bug#1065455: libapache-poi-java: FTBFS with default Java 21
Source: libapache-poi-java
Version: 4.0.1-4
Severity: important
Tags: ftbfs
User: debian-j...@lists.debian.org
Usertags: default-java21
Dear Maintainers,
The package libapache-poi-java ftbfs with default Java 21.
The relevant part of the build log:
---
[javac]
/<>/src/ooxml/testcases/org/apache/poi/openxml4j/opc/internal/marshallers/TestZipPackagePropertiesMarshaller.java:61:
error: name clash: putArchiveEntry(ArchiveEntry) in
and putArchiveEntry(ZipArchiveEntry) in ArchiveOutputStream have the same
erasure, yet neither overrides the other
[javac] public void putArchiveEntry(final ArchiveEntry
archiveEntry) throws IOException {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note:
/<>/src/ooxml/testcases/org/apache/poi/sl/TestOleShape.java uses
unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 3 warnings
---
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500,
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-21-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1045805: isc-kea: Fails to build source after successful build
Control -1 tags + confirmed On Sun, 13 Aug 2023 21:20:48 +0200 Lucas Nussbaum wrote: > This package fails to build a source package after a successful build > (dpkg-buildpackage ; dpkg-buildpackage -S). Thanks for this bug report. This is still the case in 2.4.1-2, the clean target leaves the source tree in a very dirty state, with many modified or deleted files. We don't have a low hanging fruit here, unfortunately. Paride
Bug#1036884: 64-bit time_t: libuuid1t64 -> libuuid1
Hi, please schedule binNMUs for these source packages to transition back from libuuid1t64 to libuuid1. Note that I've built this list based on the amd64 Packages file. I'm not sure if skipping armel, armhf would be helpful or not at this time. The notable thing is e2fsprogs on archs where the ABI didn't change, to possibly help debootstrap find the correct package set. e2fsprogs gsequencer hwinfo lib3mf netplan.io obs-studio ola optee-client pacemaker parted rasqal reiserfsprogs scitokens-cpp seafile tpm2-tss xen xplc xrootd Thanks, Chris
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 01:49:24PM +0100, Helmut Grohne wrote: > The packaged gcc cross toolchain uses a sysroot during its own build > still. As it is implemented now, it searches /usr//include, but > not /usr/include/. So quite fundamentally, the Provides that > we two agreed do break the build of cross toolchains right now. Okay, so this problem is about the build of the toolchain, _not_ for everything that comes after. > Arguably, a cross toolchain build should probably search > /usr/include/. I went back and forth a bit with Matthias > about whether we could add this and did not fully understand his > reasons, but there is one technical reason we want to avoid it for now. > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > and these packages can have differing versions. When that happens and we > search both /usr//include and /usr/include/, we'd > mix two glibc versions with usually bad results (been there). But this is a search path. If a file exists in one, the second one is not found. So nothing can happen even from version skew. > The other aspect here is that it is not sufficient to add > /usr/include/ to the search path as you also need > /usr/include to get a complete linux kernel headers experience. We > definitely do not want to add /usr/include, because that is known to > misguide configure tests performed for the target architecture. We are talking about the toolchain itself. What configure tests could that be? Or is that premature optimization of the gcc build? > So at least for now, I am convinced that we will need > /usr//include to be provided by the package providing > linux-libc-dev-arch-cross. You just said that the search path used during the build of the toolchain and the one for everything else are unrelated. So you are free to create $BUILD/tmp-include with symlinks for asm, asm-generic, linux. The toolchain as installed already finds all headers. So I still don't see why we need this in the final system. > That still leaves the question of which package would have to build that > new linux-libc-dev-cross. The two obvious answers are linux and > cross-toolchain-base. Do you have a preference here? No, the gcc build itself, because it is the only part that needs it from what you said here. > I hope this all makes more sense now. At least to show where it breaks. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#1064031: rustc-web 1.70.0+dfsg1-7~deb12u2 flagged for acceptance
package release.debian.org tags 1064031 = 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: rustc-web Version: 1.70.0+dfsg1-7~deb12u2 Explanation: fix build issues and file conflicts
Bug#1064617: Passwords should not be changed frequently
On Monday, 4 March 2024 22:30:57 CET Holger Wansing wrote: > > https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to > > remember URL and we'd have all the space we need to give proper advise? > > Would need to check if that fits in the relevant screens (I want to avoid > having a scroll bar on that screens). I didn't mean importing its contents, but just including a link/URL, which a user can type in a browser on a secondary device. Therefor it needs to be short/memorable. I later realized that putting it in the wiki may be useful, but also dangerous as anyone can edit a wiki (page). So another place where only authorized changes can be made is probably better. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1065454: libcanberra: Correct dpkg-dev build dependency
Source: libcanberra Version: 0.30-10ubuntu4 Severity: important X-Debbugs-Cc: michael.hud...@ubuntu.com Dear maintainer, Yesterday I uploaded an NMU of this package to unstable to add a build dependency on dpkg-dev but I made a mistake in my script and the package is now BD-Uninstallable. I am uploading a fix to unstable now. Apologies for the disruption. Thanks! -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru libcanberra-0.30/debian/changelog libcanberra-0.30/debian/changelog --- libcanberra-0.30/debian/changelog 2024-03-04 23:41:54.0 +1300 +++ libcanberra-0.30/debian/changelog 2024-03-05 10:55:23.0 +1300 @@ -1,3 +1,10 @@ +libcanberra (0.30-12.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build depedency on dpkg-dev to use >= not >> (sorry). + + -- Michael Hudson-Doyle Tue, 05 Mar 2024 10:55:23 +1300 + libcanberra (0.30-12.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libcanberra-0.30/debian/control libcanberra-0.30/debian/control --- libcanberra-0.30/debian/control 2024-03-04 23:41:54.0 +1300 +++ libcanberra-0.30/debian/control 2024-03-05 10:55:23.0 +1300 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian GNOME Maintainers Uploaders: Jeremy Bícha , Josselin Mouette , Laurent Bigonville , Marco Trevisan (Treviño) , Sjoerd Simons -Build-Depends: dpkg-dev (>> 1.22.5), +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), libltdl-dev | libltdl7-dev (>= 2.2.6), libasound2-dev [linux-any],
Bug#1065453: orc: Correct dpkg-dev build dependency
Source: orc Version: 1:0.4.34-3 Severity: important X-Debbugs-Cc: michael.hud...@ubuntu.com Dear maintainer, Yesterday I uploaded an NMU of this package to unstable to add a build dependency on dpkg-dev but I made a mistake in my script and the package is now BD-Uninstallable. I am uploading a fix to unstable now. Apologies for the disruption. Thanks! -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru orc-0.4.34/debian/changelog orc-0.4.34/debian/changelog --- orc-0.4.34/debian/changelog 2024-03-04 23:40:36.0 +1300 +++ orc-0.4.34/debian/changelog 2024-03-05 10:54:56.0 +1300 @@ -1,3 +1,10 @@ +orc (1:0.4.34-4.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build depedency on dpkg-dev to use >= not >> (sorry). + + -- Michael Hudson-Doyle Tue, 05 Mar 2024 10:54:56 +1300 + orc (1:0.4.34-4.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru orc-0.4.34/debian/control orc-0.4.34/debian/control --- orc-0.4.34/debian/control 2024-03-04 23:40:36.0 +1300 +++ orc-0.4.34/debian/control 2024-03-05 10:54:56.0 +1300 @@ -4,7 +4,7 @@ Maintainer: Maintainers of GStreamer packages Uploaders: Sebastian Dröge , Sjoerd Simons -Build-Depends: dpkg-dev (>> 1.22.5), +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), meson, pkg-config,
Bug#1065451: glibmm2.4: Correct dpkg-dev build dependency
Source: glibmm2.4 Version: 2.66.6-2 Severity: important X-Debbugs-Cc: michael.hud...@ubuntu.com Dear maintainer, Yesterday I uploaded an NMU of this package to unstable to add a build dependency on dpkg-dev but I made a mistake in my script and the package is now BD-Uninstallable. I am uploading a fix to unstable now. Apologies for the disruption. Thanks! -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru glibmm2.4-2.66.6/debian/changelog glibmm2.4-2.66.6/debian/changelog --- glibmm2.4-2.66.6/debian/changelog 2024-03-04 23:39:52.0 +1300 +++ glibmm2.4-2.66.6/debian/changelog 2024-03-05 10:51:53.0 +1300 @@ -1,3 +1,10 @@ +glibmm2.4 (2.66.6-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build depedency on dpkg-dev to use >= not >> (sorry). + + -- Michael Hudson-Doyle Tue, 05 Mar 2024 10:51:53 +1300 + glibmm2.4 (2.66.6-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru glibmm2.4-2.66.6/debian/control glibmm2.4-2.66.6/debian/control --- glibmm2.4-2.66.6/debian/control 2024-03-04 23:39:52.0 +1300 +++ glibmm2.4-2.66.6/debian/control 2024-03-05 10:51:53.0 +1300 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian GNOME Maintainers Uploaders: Jeremy Bícha -Build-Depends: dpkg-dev (>> 1.22.5), +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), doxygen, glib-networking ,
Bug#1064824: node-d3: fails to export map and other functions
On Mon, Mar 04, 2024 at 09:18:01PM +, Julian Gilbey wrote: > [...] > So it's specifically "map" that is problematic, and I just happen to > have stumbled upon it: d3 v5 depends on d3-array version 1, but the > version of node-d3-array in unstable is 3.2.0+~cs5.0.6-2, and this is > causing the conflict. > > I don't know the best way to fix this. node-d3-array version was > upgraded from 1.2.4 to 3.x about two years ago, so d3 would have had > this bug since then, but I'm the first one to stumble upon it :-/ > > Perhaps we could package node-d3-array-1 (version 1.2.4) and have > node-d3 build-depends on that? I was just wondering if there's a simpler way than having a new package: have d3-array 1.2.4 being an unexported component of the node-d3 source package, and instead of Build-Depends: node-d3-array, have a Build-Conflicts: node-d3-array. But then I discovered that the binary package node-d3 depends on node-d3-array, as do 7 other packages in testing (I haven't checked unstable). I'm guessing that most of those dependencies probably need version 1.x of d3-array, so it may be that having a node-d3-array-1 (or -v1) package is actually the way forward in this situation. Best wishes, Julian
Bug#1065452: gtkmm3.0: Correct dpkg-dev build dependency
Source: gtkmm3.0 Version: 3.24.8-2 Severity: important X-Debbugs-Cc: michael.hud...@ubuntu.com Dear maintainer, Yesterday I uploaded an NMU of this package to unstable to add a build dependency on dpkg-dev but I made a mistake in my script and the package is now BD-Uninstallable. I am uploading a fix to unstable now. Apologies for the disruption. Thanks! -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru gtkmm3.0-3.24.8/debian/changelog gtkmm3.0-3.24.8/debian/changelog --- gtkmm3.0-3.24.8/debian/changelog2024-03-04 23:41:24.0 +1300 +++ gtkmm3.0-3.24.8/debian/changelog2024-03-05 10:53:03.0 +1300 @@ -1,3 +1,10 @@ +gtkmm3.0 (3.24.8-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build depedency on dpkg-dev to use >= not >> (sorry). + + -- Michael Hudson-Doyle Tue, 05 Mar 2024 10:53:03 +1300 + gtkmm3.0 (3.24.8-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru gtkmm3.0-3.24.8/debian/control gtkmm3.0-3.24.8/debian/control --- gtkmm3.0-3.24.8/debian/control 2024-03-04 23:41:24.0 +1300 +++ gtkmm3.0-3.24.8/debian/control 2024-03-05 10:53:03.0 +1300 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian GNOME Maintainers Uploaders: Jeremy Bícha -Build-Depends: dpkg-dev (>> 1.22.5), +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), doxygen, graphviz,
Bug#1065450: glibmm2.68: Correct dpkg-dev build dependency
Source: glibmm2.68 Version: 2.78.0-1 Severity: important X-Debbugs-Cc: michael.hud...@ubuntu.com Dear maintainer, Yesterday I uploaded an NMU of this package to unstable to add a build dependency on dpkg-dev but I made a mistake in my script and the package is now BD-Uninstallable. I am uploading a fix to unstable now. Apologies for the disruption. Thanks! -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru glibmm2.68-2.78.1/debian/changelog glibmm2.68-2.78.1/debian/changelog --- glibmm2.68-2.78.1/debian/changelog 2024-03-04 23:35:03.0 +1300 +++ glibmm2.68-2.78.1/debian/changelog 2024-03-05 10:49:44.0 +1300 @@ -1,3 +1,10 @@ +glibmm2.68 (2.78.1-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build depedency on dpkg-dev to use >= not >> (sorry). + + -- Michael Hudson-Doyle Tue, 05 Mar 2024 10:49:44 +1300 + glibmm2.68 (2.78.1-2.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru glibmm2.68-2.78.1/debian/control glibmm2.68-2.78.1/debian/control --- glibmm2.68-2.78.1/debian/control2024-03-04 23:35:03.0 +1300 +++ glibmm2.68-2.78.1/debian/control2024-03-05 10:49:44.0 +1300 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian GNOME Maintainers Uploaders: Jeremy Bícha , Michael Biebl -Build-Depends: dpkg-dev (>> 1.22.5), +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), doxygen, glib-networking ,
Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
Hi,
On Mon, Mar 04, 2024 at 01:05:09PM -0700, Jonathan Corbet wrote:
> Salvatore Bonaccorso writes:
>
> > Ok. In the sprit of the stable series rules we might try the later and
> > if it's not feasible pick the first variant?
>
> Well, "the spirit of the stable series" is one of Greg's titles, and he
> said either was good...:)
here we go. Please let me know if you need anything changed in the
commit message to describe the situation better.
Greg, in the Fixes tag I added the 5.10.y commit as the issue is
specific to the 5.10.y series. Is this the correct form to note this?
Regards,
Salvatore
>From ccddb9f4915f0dbf28fb72b6ff4c04977978ed3d Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso
Date: Mon, 4 Mar 2024 22:24:12 +0100
Subject: [PATCH] scripts: kernel-doc: Fix syntax error due to undeclared args
variable
The backport of commit 3080ea5553cc ("stddef: Introduce
DECLARE_FLEX_ARRAY() helper") to 5.10.y (as a prerequisite of another
fix) modified scripts/kernel-doc and introduced a syntax error:
Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
Execution of ./scripts/kernel-doc aborted due to compilation errors.
Note: The issue could be fixed in the 5.10.y series as well by
backporting e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
expressions into variables") but just replacing the undeclared args back
to ([^,)]+) was the most straightforward approach. The issue is specific
to the backport to the 5.10.y series. Thus there is as well no upstream
commit for this change.
Fixes: 443b16ee3d9c ("stddef: Introduce DECLARE_FLEX_ARRAY() helper") # 5.10.y
Reported-by: Ben Hutchings
Link: https://lore.kernel.org/regressions/zehkjjpgoyv_b...@eldamar.lan/T/#u
Link: https://bugs.debian.org/1064035
Signed-off-by: Salvatore Bonaccorso
---
scripts/kernel-doc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 7a04d4c05326..8e3257f1ea2c 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1233,7 +1233,7 @@ sub dump_struct($$) {
# replace DECLARE_KFIFO_PTR
$members =~ s/DECLARE_KFIFO_PTR\s*\(([^,)]+),\s*([^,)]+)\)/$2 \*$1/gos;
# replace DECLARE_FLEX_ARRAY
- $members =~ s/(?:__)?DECLARE_FLEX_ARRAY\s*\($args,\s*$args\)/$1 $2\[\]/gos;
+ $members =~ s/(?:__)?DECLARE_FLEX_ARRAY\s*\(([^,)]+),\s*([^,)]+)\)/$1 $2\[\]/gos;
my $declaration = $members;
# Split nested struct/union elements as newer ones
--
2.43.0
Bug#1064617: Passwords should not be changed frequently
Hi, Diederik de Haas wrote (Mon, 04 Mar 2024 15:57:10 +0100): > On Monday, 4 March 2024 10:43:59 CET Holger Wansing wrote: > > >Regarding the password advice, I ended up concluding that it's pretty > > >unlikely that anything we say at this point will have any effect on > > >people's behaviour, but then I'm probably just an old cynic. Also, I > > >failed when trying to come up with a wording which I was happy with, > > >which is why I ended up discarding the advice entirely. > > > > > >If we want to keep the password advice in then I think what you wrote is > > >(mostly) OK, although I think it implies that one should be choosing a > > >single "password" (although, not a word in any normal sense), which > > >could be argued to steer people away from the perfectly decent xkcd > > >approach of using several dictionary words. Saying "Password or > > >Passphrase" at least once would probably address that. > > > > Ok, makes it a bit longer, but it could be worth it. > > https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to > remember URL and we'd have all the space we need to give proper advise? Would need to check if that fits in the relevant screens (I want to avoid having a scroll bar on that screens). Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1065446: pristine-tar: fails if upstream tarball contains an empty directory
Package: pristine-tar Version: 1.50+nmu1 Severity: normal I discovered that a package I was trying to use with pristine-tar failed to work. The cause of the issue seems to be that the upstream tarball contains an empty directory, which is lost when regenerated by pristine-tar. Steps to reproduce using git-buildpackage: 1. Import the attached minimal working example into git using the command: gbp import-dsc --pristine-tar foobar_1.0-1.dsc 2. Change into the build directory: cd foobar 3. Regenerate the original tar ball using pristine-tar, for example: gbp buildpackage -S 4. Return to the parent directory, then: $ tar ztf foobar_1.0.orig.tar.gz foobar-1.0/ foobar-1.0/foobar.c foobar-1.0/Makefile foobar-1.0/emptydir/ $ tar ztf build-area/foobar_1.0.orig.tar.gz foobar-1.0/ foobar-1.0/Makefile foobar-1.0/foobar.c Note the empty directory has disappeared. Also: $ ls -l foobar_1.0.orig.tar.gz build-area/foobar_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 253 Mar 4 20:51 build-area/foobar_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 193 Mar 4 20:00 foobar_1.0.orig.tar.gz Best wishes, Julian
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
Package: pristine-tar Version: 1.50+nmu1 Severity: normal I discovered that a package I was trying to use with pristine-tar failed to work. The cause of the issue seems to be that the upstream tarball's top directory name is capitalised, but pristine-tar regenerates a tarball with the name lowercased. Steps to reproduce using git-buildpackage: 1. Import the attached minimal working example into git using the command: gbp import-dsc --pristine-tar hello_1.0-1.dsc 2. Change into the build directory: cd hello 3. Regenerate the original tar ball using pristine-tar, for example: gbp buildpackage -S 4. Return to the parent directory, then: $ tar ztf hello_1.0.orig.tar.gz Hello-1.0/ Hello-1.0/Makefile Hello-1.0/hello.c $ tar ztf build-area/hello_1.0.orig.tar.gz hello-1.0/ hello-1.0/Makefile hello-1.0/hello.c Note the capitalisation has changed. Also: $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 256 Mar 4 20:46 build-area/hello_1.0.orig.tar.gz -rw-r--r-- 1 jdg jdg 175 Mar 4 20:00 hello_1.0.orig.tar.gz Best wishes, Julian
Bug#1065447: unneeded libreoffice Build-Depends (libreoffice, ure-java, default-jre), -writer and -calc are enough
Source: winff Severity: normal Hi, I just noticed winff - thanks to your bug report :): I see winff (1.6.2+dfsg-2) unstable; urgency=medium * Temporary home directory to run soffice (Closes: #759980) * Build dependencies (for javaldx) * Escape Dollar signs in file names (Closes: #1053373) -- Peter Blackman Thu, 05 Oct 2023 10:00:00 +0100 in the changelog and chekced. Because that looked extremely fishy. It is. Build-Depends-Indep: libreoffice, ure-java, default-jre, What for? a) The javaldx warning is harmless unless you do run Java stuff. Which you don't if you convert stuff to pdf. You can just ignore this and you don't need to depend on Java stuff (which is not available on all archs)[1] b) I don't believe you need libreoffice-base etc which gets pulled in by the libreoffice *metapackage*. rene@frodo:~/winff-1.6.3+dfsg/winff/docs$ ls *.od? WinFF.ca.odt WinFF.es_AR.odg WinFF.nl.odt WinFF.en.odt WinFF.fr.odt WinFF.pt_BR.odt So you just need libreoffice-writer and libreoffice-draw. Tried in a local build with libreoffice-writer and -draw 4:24.2.1-3. (Actually libreoffice-writer-nogui and libreoffice-draw-nogui would suffice but the fix for #1058653 is blocked by t64 transition. So let's ignore that for now.) Patch: diff -Nru winff-1.6.3+dfsg/debian/changelog winff-1.6.3+dfsg/debian/changelog --- winff-1.6.3+dfsg/debian/changelog 2024-02-19 14:00:00.0 +0100 +++ winff-1.6.3+dfsg/debian/changelog 2024-03-04 21:50:28.0 +0100 @@ -1,3 +1,10 @@ +winff (1.6.3+dfsg-1.1) UNRELEASED; urgency=medium + + * only build-depend on needed libreoffice-draw, libreoffice-writer; +remove extraneous libreoffice, ure-java, default-jre + + -- Rene Engelhard Mon, 04 Mar 2024 20:50:28 + + winff (1.6.3+dfsg-1) unstable; urgency=medium * New Upstream release (Closes: #1053373) (Closes: #1061586) diff -Nru winff-1.6.3+dfsg/debian/control winff-1.6.3+dfsg/debian/control --- winff-1.6.3+dfsg/debian/control 2023-10-04 22:29:34.0 +0200 +++ winff-1.6.3+dfsg/debian/control 2024-03-04 21:50:28.0 +0100 @@ -10,9 +10,8 @@ lcl, lcl-qt5, Build-Depends-Indep: - libreoffice, - ure-java, - default-jre, + libreoffice-draw, + libreoffice-writer, Standards-Version: 4.6.2 Rules-Requires-Root: no Vcs-Browser: https://salsa.debian.org/pascal-team/winff Regards, Rene [1] _all is Built on amd64 anyways, but still.
Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications
On Monday, 4 March 2024 at 22:08, Simon McVittie wrote: > If upgrading libmutter-13-0 (and other packages from the same source) > to 45.3-3 fixes this, then you were experiencing #1063640. If not, > we should open a separate bug. Oh yes I was indeed still on 45.3-2, upgrading to 45.3-3 fixes the crash! I still get the default cursor when dragging, but this seems to be by design: - 45.3 branch uses `dnd-none`: https://gitlab.gnome.org/GNOME/mutter/-/blob/45.3/src/backends/meta-cursor-sprite-xcursor.c?ref_type=tags#L75 - main branch now uses `default`: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/meta-cursor-sprite-xcursor.c?ref_type=heads#L75 Thanks, Markus
Bug#1065446: pristine-tar: fails if upstream tarball contains an empty directory
On Mon, Mar 04, 2024 at 08:53:25PM +, Julian Gilbey wrote: > Package: pristine-tar > Version: 1.50+nmu1 > Severity: normal > > I discovered that a package I was trying to use with pristine-tar > failed to work. The cause of the issue seems to be that the upstream > tarball contains an empty directory, which is lost when regenerated by > pristine-tar. > > Steps to reproduce using git-buildpackage: > 1. Import the attached minimal working example into git using the command: >gbp import-dsc --pristine-tar foobar_1.0-1.dsc > > 2. Change into the build directory: >cd foobar > > 3. Regenerate the original tar ball using pristine-tar, for example: >gbp buildpackage -S > > 4. Return to the parent directory, then: > > $ tar ztf foobar_1.0.orig.tar.gz > foobar-1.0/ > foobar-1.0/foobar.c > foobar-1.0/Makefile > foobar-1.0/emptydir/ > $ tar ztf build-area/foobar_1.0.orig.tar.gz > foobar-1.0/ > foobar-1.0/Makefile > foobar-1.0/foobar.c > > Note the empty directory has disappeared. Also: > > $ ls -l foobar_1.0.orig.tar.gz build-area/foobar_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 253 Mar 4 20:51 build-area/foobar_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 193 Mar 4 20:00 foobar_1.0.orig.tar.gz > > Best wishes, > >Julian I forgot to attach the foobar package, here it is. Julian Format: 3.0 (quilt) Source: foobar Binary: foobar Architecture: any Version: 1.0-1 Maintainer: Julian Gilbey Homepage: Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13) Package-List: foobar deb unknown optional arch=any Checksums-Sha1: 0e2d40b683cd46506364ff326fd7990addcde812 193 foobar_1.0.orig.tar.gz 406c92cd201f9a00f15d6f74cfa04ea2b9ac9501 2024 foobar_1.0-1.debian.tar.xz Checksums-Sha256: 19388ac41515a84a018cf030561f6664a50339ea68db874c470491b18c9bc9cb 193 foobar_1.0.orig.tar.gz bfe8513364dcbe2e7b9a44c6436bf0a48ff482105f5414a852eda8190712e543 2024 foobar_1.0-1.debian.tar.xz Files: c111a679204eda05e4cac4997d0c3dfd 193 foobar_1.0.orig.tar.gz 846524b08e24b0b5b0af3401eaf58e7c 2024 foobar_1.0-1.debian.tar.xz foobar_1.0-1.debian.tar.xz Description: application/xz foobar_1.0.orig.tar.gz Description: application/gzip
Bug#1064824: node-d3: fails to export map and other functions
Hi Nilesh, On Tue, Mar 05, 2024 at 02:06:08AM +0530, Nilesh Patra wrote: > > This gives lots of differences still; stripping down to just the > > differences still has many, many differences: some new exports not in > > the original d3, and some lost exports; the list begins: > > $ diff -u /tmp/d3-npm.exports.trimmed /tmp/d3-debian.exports.trimmed > > > > +exports.Adder = Adder; > > -exports.bisect = bisectRight; > > +exports.bin = bin; > > +exports.bisect = bisect; > > +exports.bisectCenter = bisectCenter; > > +exports.blur2 = blur2; > > +exports.blur = blur; > > +exports.blurImage = blurImage; > > +exports.count = count; > > -exports.csvFormatRow = csvFormatRow; > > -exports.csvFormatValue = csvFormatValue; > > $ cat /tmp/d3-debian.exports.trimmed | egrep --color > '(bisectRight|csvFormatRow|csvFormatValue)' > exports.bisectRight = bisectRight; > exports.csvFormatRows = csvFormatRows; > > Some of the diff entries are false positive -- it is just that entries are > not identical across these > files and despite sorting them, you do not get the exact picture of the diff > in exports. Well spotted, thanks! I'll snip the discussion of csvFormatValue... > [...] > Which is why. Seems the versions of dev dependencies have not been > appropriately tightened by the upstream > so we are running into weird surprises like these. Re-compiling node-d3 again > now should fixup this export however. Great! > These minor deltas in exports are more or less due to > version differences in different d3 plugins. > > ... > > Background to this: I'm trying to package a new package which provides > > a web server to visualise some data. The package includes a few > > precompiled JavaScript libraries obtained from npmjs.com, and the > > server works fine with them. But following Debian policy, I need to > > replace those with the source packages. And the server then doesn't > > work. > > > > The JavaScript libraries which the package uses are: d3 v5.16.0, > > d3-tip, apparently v0.9.1, along with jQuery and bootstrap4. I have > > replaced all of these with the versions in the corresponding Debian > > packages (and I've just uploaded a new version of d3-tip, thinking > > that that was the cause of the bug). > > > > When visiting the served web page, the console log gives the error > > message: > > > > Uncaught (in promise) TypeError: t.map is not a function > >n http://localhost:8080/js/d3/d3-tip.min.js:1 > >main http://localhost:8080/js/index.js:848 > >async* http://localhost:8080/js/index.js:993 > > > > (This has changed from the original bug report as the minimised new > > version of d3-tip has t.map instead of h.map.) > > > > d3-tip.js requires d3-collection, from which it calls a map function. > > I tried replacing d3-tip.min.js with the pre-packaged version rather > > than the (newly built) Debian version, but that did not help. I > > reverted that change and instead replaced d3.v5.min.js (which is a > > copy of /usr/share/nodejs/d3/dist/d3.min.js) with the version provided > > by upstream, which is a verbatim copy of the npmjs.com d3.min.js, and > > the server then worked perfectly. So this told me that it is the > > Debian compiled d3 which is not working correctly. > > Julian, I am very confused by that wording - from what I could gauge, your > target package does not work with debian libs but it does work with npmjs, > yes? I'm sorry I wasn't clear. Yes, that's it: I'm trying to package taskflow for Debian (it's a dependency of something else that I'm trying to package), and it provides a profiler visualisation tool in the form of a webserver. The upstream package (https://github.com/taskflow/taskflow) has d3.v5.min.js and d3-tip.min.js included (in tfprof/js/d3), and these are bitwise identical to the npmjs versions (versions 5.16.0 and 0.9.1). The webserver works using these versions. To satisfy Debian policy, I replaced these with the versions found in libjs-d3-tip and node-d3, but then the webserver fails to produce a usuable visualisation. My exploration, described above, was that "map" was not exported from d3-collection, and that led me to explore whether this was a unique missing export or not; I discovered that it was not. > In that case linking your target package and listing the exact steps to > that error can help someone debug it in more detail as to what might be > missing. I've just rebuilt node-d3 locally from (Debian) source on an unstable schroot, and I think I may have found the source of the bug: the build reads: - dh_auto_build --buildsystem=nodejs No build command found, searching known files No build command found, searching known files Found debian/nodejs/d3-sankey/build cd ./d3-sankey && sh -ex ../debian/nodejs/d3-sankey/build + rollup -c src/index.js → dist/d3-sankey.js... created dist/d3-sankey.js in 120ms src/index.js → dist/d3-sankey.min.js... created dist/d3-sankey.min.js in 561ms Found debian/nodejs/./build cd ./. && sh
Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised
On Mon, Mar 04, 2024 at 08:53:21PM +, Julian Gilbey wrote: > Package: pristine-tar > Version: 1.50+nmu1 > Severity: normal > > I discovered that a package I was trying to use with pristine-tar > failed to work. The cause of the issue seems to be that the upstream > tarball's top directory name is capitalised, but pristine-tar > regenerates a tarball with the name lowercased. > > Steps to reproduce using git-buildpackage: > 1. Import the attached minimal working example into git using the command: >gbp import-dsc --pristine-tar hello_1.0-1.dsc > > 2. Change into the build directory: >cd hello > > 3. Regenerate the original tar ball using pristine-tar, for example: >gbp buildpackage -S > > 4. Return to the parent directory, then: > > $ tar ztf hello_1.0.orig.tar.gz > Hello-1.0/ > Hello-1.0/Makefile > Hello-1.0/hello.c > $ tar ztf build-area/hello_1.0.orig.tar.gz > hello-1.0/ > hello-1.0/Makefile > hello-1.0/hello.c > > Note the capitalisation has changed. Also: > > $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 256 Mar 4 20:46 build-area/hello_1.0.orig.tar.gz > -rw-r--r-- 1 jdg jdg 175 Mar 4 20:00 hello_1.0.orig.tar.gz > > Best wishes, > >Julian I forgot to attach the hello package; here it is. Julian Format: 3.0 (quilt) Source: hello Binary: hello Architecture: any Version: 1.0-1 Maintainer: Julian Gilbey Homepage: Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13) Package-List: hello deb unknown optional arch=any Checksums-Sha1: 13d5ecfcec8a27b9d89ea9e73ad0066fd2ece889 175 hello_1.0.orig.tar.gz 17f6726313b66fe7cecaa22aba10185037f945a1 2028 hello_1.0-1.debian.tar.xz Checksums-Sha256: 5d35cb0e91cbf6597d88d0c9fe4569544c391882ebf82a7754c2edba8bea50fb 175 hello_1.0.orig.tar.gz f23d59003adf6cda9a84c25f3836021781f7df42e1a0037b737d62568d7bf0bd 2028 hello_1.0-1.debian.tar.xz Files: 5f3b5a48f5a653abab7de8852c8380b7 175 hello_1.0.orig.tar.gz eb3450a52485d0bb39416a0e691af913 2028 hello_1.0-1.debian.tar.xz hello_1.0-1.debian.tar.xz Description: application/xz hello_1.0.orig.tar.gz Description: application/gzip
Bug#1065448: libreoffice-common: soffice builds of pdf files are unreproducible
forwarded 1065448 https://bugs.documentfoundation.org/show_bug.cgi?id=160033 thanks Hi, Am 04.03.24 um 21:58 schrieb Rene Engelhard: Package: libreoffice-common Version: 4:24.2.0-1 Severity: normal Tags: upstream Then you should have filed it upstream :). Didn't write the reportbug text for no reason :) Did now: https://bugs.documentfoundation.org/show_bug.cgi?id=160033 When creating pdf files from odt files, soffice writes a CreationDate field which contains the actual build date/time. This varies with every build. For an example, see the bottom of https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/winff.html soffice could use the creation date of the input odt file, or even SOURCE_DATE_EPOCH instead of the current system date. I think there wven was an option to actually not export this at all (or I misremember) but it's probably not exposed to --convert-to etc. unless extra configuration. Anyway, forwarded. Regards, Rene
Bug#1064617: Passwords should not be changed frequently
Hi, Holger Wansing wrote (Mon, 04 Mar 2024 10:43:59 +0100): > Hi, > > Am 4. März 2024 06:17:31 MEZ schrieb Philip Hands : > >I found that there were some phrases that I was avoiding for various > >reasons, a couple of which I see you've used, so I'll say why I was avoiding > >them and see if I have a persuasive argument for doing so. > > > >"allow/deny login/access as root": > > > > The problem here is that not having a password for root only prevents > > one from getting direct access to root by using a password. Indirect > > access is still available via sudo, and direct access is still > > available via key bassed ssh. I was also avoiding saying things like > > "disable the root account" for the same reason. > > > > This is why I ended up with the phrasing: > > > > direct password-based logins to 'root'. > > Ok, seems fair. I would change to that then. > > > > >"using the 'sudo' command": > > > > This I was avoiding becuase it might give the impression that one MUST > > use sudo, whereas most people will actually get their root acces via a > > GUI prompting them for their own pasword (because it's checked that > > they're in the sudo group) when doing things like unlocking their > > network or printer settings. I thought it was worth mentining the > > 'sudo' group explicitly because that gives something to search for if > > they want to find out more, but telling people they need to use the > > sudo command seemed like a step too far. > > Correct so far. Maybe a bit more technical and therefore probably > not the easiest choice for newbies, but I have no problem using that. > > >Regarding the password advice, I ended up concluding that it's pretty > >unlikely that anything we say at this point will have any effect on > >people's behaviour, but then I'm probably just an old cynic. Also, I > >failed when trying to come up with a wording which I was happy with, > >which is why I ended up discarding the advice entirely. > > > >If we want to keep the password advice in then I think what you wrote is > >(mostly) OK, although I think it implies that one should be choosing a > >single "password" (although, not a word in any normal sense), which > >could be argued to steer people away from the perfectly decent xkcd > >approach of using several dictionary words. Saying "Password or > >Passphrase" at least once would probably address that. > > Ok, makes it a bit longer, but it could be worth it. > > I will prepare a new patch with above. Updated patch attached. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates index cdb6d78..437b9d7 100644 --- a/debian/user-setup-udeb.templates +++ b/debian/user-setup-udeb.templates @@ -33,22 +33,21 @@ _Description: Allow login as root? Template: passwd/root-password Type: password # :sl1: -_Description: Root password: - You need to set a password for 'root', the system administrative - account. A malicious or unqualified user with root access can have - disastrous results, so you should take care to choose a root password - that is not easy to guess. It should not be a word found in dictionaries, - or a word that could be easily associated with you. +_Description: Root password/passphrase: + If you want to allow direct password-based login as root, you need to set a + password for 'root', the system administrative account now. + A malicious or unqualified user with root access can have + disastrous results, so you should take care to choose a root + password/passphrase that cannot be guessed. It should not be a word found in + dictionaries, or something that could be easily associated with you. . - A good password will contain a mixture of letters, numbers and punctuation - and should be changed at regular intervals. + You can also leave the password for root empty here, to disable the root + account; the system's initial user account (which will be set up in the next + step) will then be given the power to become root via 'sudo' (by adding it to + the 'sudo' group). . - The root user should not have an empty password. If you leave this - empty, the root account will be disabled and the system's initial user - account will be given the power to become root using the "sudo" - command. - . - Note that you will not be able to see the password as you type it. + Note that you will not be able to see the password as you type it (except if + you choose to show it in clear text). Template: passwd/root-password-again Type: password @@ -109,9 +108,8 @@ _Description: Reserved username Template: passwd/user-password Type: password # :sl1: -_Description: Choose a password for the new user: - A good password will contain a mixture of letters, numbers and punctuation - and should be changed at regular intervals. +_Description: Choose a password/passphrase for the new user: + Make sure to select a strong password/passphrase,
Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications
On Mon, 04 Mar 2024 at 20:21:56 +, Markus Koller wrote: > So it's trying to use the `DND_IN_DRAG` cursor at [1]. That's not a concrete cursor name, it's an alias in libmutter. Depending on version of libmutter, it could end up referring to either "dnd-none" (which is no longer provided) or "no-drop" (which still exists) or perhaps even something else. > I should also mention I'm using gnome-shell 45.3-2 from > experimental. With which version of libmutter-13-0? Locating some cursors with newer adwaita-icon-theme is known to be broken with mutter/45.3-2 but should be fixed with mutter/45.3-3, as far as I know. If upgrading libmutter-13-0 (and other packages from the same source) to 45.3-3 fixes this, then you were experiencing #1063640. If not, we should open a separate bug. Thanks, smcv
Bug#1065449: trapperkeeper-webserver-jetty9-clojure: FTBFS with default Java 21
Source: trapperkeeper-webserver-jetty9-clojure
Version: 4.4.1-5
Severity: important
Tags: ftbfs
User: debian-j...@lists.debian.org
Usertags: default-java21
Dear Maintainers,
The package trapperkeeper-webserver-jetty9-clojure ftbfs with default Java 21.
The relevant part of the build log:
---
lein with-profile -dev pom debian/pom.xml
java.lang.Exception: Error loading /<>/project.clj
at leiningen.core.project$read_raw$fn__8409.invoke (project.clj:1115)
leiningen.core.project$read_raw.invokeStatic (project.clj:1109)
leiningen.core.project$read_raw.invoke (project.clj:1105)
leiningen.core.project$read.invokeStatic (project.clj:1126)
leiningen.core.project$read.invoke (project.clj:1123)
leiningen.core.project$read.invokeStatic (project.clj:1127)
leiningen.core.project$read.invoke (project.clj:1123)
leiningen.core.main$_main$fn__7764.invoke (main.clj:448)
leiningen.core.main$_main.invokeStatic (main.clj:442)
leiningen.core.main$_main.doInvoke (main.clj:439)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.core$apply.invokeStatic (core.clj:667)
clojure.main$main_opt.invokeStatic (main.clj:514)
clojure.main$main_opt.invoke (main.clj:510)
clojure.main$main.invokeStatic (main.clj:664)
clojure.main$main.doInvoke (main.clj:616)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.main.main (main.java:40)
Caused by: clojure.lang.Compiler$CompilerException: Syntax error macroexpanding
at (/<>/project.clj:3:1).
#:clojure.error{:phase :execution, :line 3, :column 1, :source
"/<>/project.clj"}
at clojure.lang.Compiler.load (Compiler.java:7665)
clojure.lang.Compiler.loadFile (Compiler.java:7591)
clojure.lang.RT$3.invoke (RT.java:327)
leiningen.core.project$read_raw$fn__8409.invoke (project.clj:1113)
leiningen.core.project$read_raw.invokeStatic (project.clj:1109)
leiningen.core.project$read_raw.invoke (project.clj:1105)
leiningen.core.project$read.invokeStatic (project.clj:1126)
leiningen.core.project$read.invoke (project.clj:1123)
leiningen.core.project$read.invokeStatic (project.clj:1127)
leiningen.core.project$read.invoke (project.clj:1123)
leiningen.core.main$_main$fn__7764.invoke (main.clj:448)
leiningen.core.main$_main.invokeStatic (main.clj:442)
leiningen.core.main$_main.doInvoke (main.clj:439)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.core$apply.invokeStatic (core.clj:667)
clojure.main$main_opt.invokeStatic (main.clj:514)
clojure.main$main_opt.invoke (main.clj:510)
clojure.main$main.invokeStatic (main.clj:664)
clojure.main$main.doInvoke (main.clj:616)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.main.main (main.java:40)
Caused by: clojure.lang.ExceptionInfo: Unsupported major Java version. Expects
11 or 17.
{:major "21", :minor "0"}
at leiningen.core.project$eval657.invokeStatic (project.clj:100)
leiningen.core.project$eval657.invoke (project.clj:3)
clojure.lang.Compiler.eval (Compiler.java:7194)
clojure.lang.Compiler.load (Compiler.java:7653)
clojure.lang.Compiler.loadFile (Compiler.java:7591)
clojure.lang.RT$3.invoke (RT.java:327)
leiningen.core.project$read_raw$fn__8409.invoke (project.clj:1113)
leiningen.core.project$read_raw.invokeStatic (project.clj:1109)
leiningen.core.project$read_raw.invoke (project.clj:1105)
leiningen.core.project$read.invokeStatic (project.clj:1126)
leiningen.core.project$read.invoke (project.clj:1123)
leiningen.core.project$read.invokeStatic (project.clj:1127)
leiningen.core.project$read.invoke (project.clj:1123)
leiningen.core.main$_main$fn__7764.invoke (main.clj:448)
leiningen.core.main$_main.invokeStatic (main.clj:442)
leiningen.core.main$_main.doInvoke (main.clj:439)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.core$apply.invokeStatic (core.clj:667)
clojure.main$main_opt.invokeStatic (main.clj:514)
clojure.main$main_opt.invoke (main.clj:510)
clojure.main$main.invokeStatic (main.clj:664)
clojure.main$main.doInvoke (main.clj:616)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.lang.Var.applyTo (Var.java:705)
clojure.main.main (main.java:40)
make[1]: *** [debian/rules:20: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:11: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
---
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500,
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-21-generic (SMP w/32 CPU threads;
Bug#1065448: libreoffice-common: soffice builds of pdf files are unreproducible
Package: libreoffice-common Version: 4:24.2.0-1 Severity: normal Tags: upstream X-Debbugs-Cc: pe...@pblackman.plus.com Dear Maintainer, When creating pdf files from odt files, soffice writes a CreationDate field which contains the actual build date/time. This varies with every build. For an example, see the bottom of https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/winff.html soffice could use the creation date of the input odt file, or even SOURCE_DATE_EPOCH instead of the current system date. Regards, Peter -- Package-specific info: Configuration file Package Exists Changed /etc/libreoffice/registry/Langpack-en-US.xcd libreoffice-common Yes No /etc/libreoffice/registry/lingucomponent.xcd libreoffice-common Yes No /etc/libreoffice/registry/main.xcd libreoffice-common Yes No /etc/libreoffice/registry/pdfimport.xcd libreoffice-common Yes No /etc/libreoffice/registry/res/fcfg_langpack_e libreoffice-common Yes No /etc/libreoffice/registry/xsltfilter.xcd libreoffice-common Yes No -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-common depends on: ii libnumbertext-data 1.0.11-4 ii libreoffice-style-colibre 4:24.2.0-1 ii libreoffice-uiconfig-common 4:24.2.0-1 ii ucf 3.0043+nmu1 ii ure 4:24.2.0-1 Versions of packages libreoffice-common recommends: ii apparmor 3.0.12-1+b2 ii fonts-liberation 1:2.1.5-3 ii libexttextcat-data 3.4.7-1 ii poppler-data 0.4.12-1 ii python3-uno 4:24.2.0-1 ii xdg-utils 1.1.3-4.1 Versions of packages libreoffice-common suggests: ii libreoffice-style-colibre [libreoffice-style] 4:24.2.0-1 pn python3-scriptforge -- no debconf information
Bug#1063653: Acknowledgement (anope: Please ship new upstream version)
On Mon, Feb 26, 2024 at 07:56:42PM -0500, Victor Coss wrote: > Now the latest version is 2.0.15 which includes even more bug fixes > including a more concerning race condition. > https://www.anope.org/news/2024/anope-2015-release.html > > Would greatly appreciate it if you can package the updated version. Thanks for letting me know. I have been short on time in recent weeks due to other commitments. I will try and look at this this week, all being well. If any Debian contributor would like to upload a new version, that's also fine with me! Cheers Dominic
Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications
Oh no, sorry I meant to say "46~beta-4" in the first sentence. Copied it from the bottom and forgot to change it :)
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 12:30:09PM +0100, Bastian Blank wrote: > On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > > On 04.03.24 11:29, Bastian Blank wrote: > > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > > > Please be a bit more precise, there are no symlinks in this directory. > > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > > | # find /usr/alpha-linux-gnu/include/ -type l > > > | # > > yes, that is the problem. the cross gcc expects these headers in > > /usr/alpha-linux-gnu/include, not in the header location for the host. > > Please show your problem with a log, my crystal ball is broken. This very much was not obvious to me either. I've now talked to Matthias and believe I can explain the problem. The packaged gcc cross toolchain uses a sysroot during its own build still. As it is implemented now, it searches /usr//include, but not /usr/include/. So quite fundamentally, the Provides that we two agreed do break the build of cross toolchains right now. Arguably, a cross toolchain build should probably search /usr/include/. I went back and forth a bit with Matthias about whether we could add this and did not fully understand his reasons, but there is one technical reason we want to avoid it for now. We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed and these packages can have differing versions. When that happens and we search both /usr//include and /usr/include/, we'd mix two glibc versions with usually bad results (been there). While we might consider adding /usr/include/ to the cross toolchain build search path later, it is not something we can do now and before doing that, we need to better understand Matthias' reasons for keeping these separate as well. The other aspect here is that it is not sufficient to add /usr/include/ to the search path as you also need /usr/include to get a complete linux kernel headers experience. We definitely do not want to add /usr/include, because that is known to misguide configure tests performed for the target architecture. In principle, we could extend the symlink farm in linux-libc-dev to also have a lot of /usr/include//linux -> ../linux symlinks (assuming that no other package ever installs to /usr/include/linux, which is a property violated by aufs-dev and oss4-dev). So at least for now, I am convinced that we will need /usr//include to be provided by the package providing linux-libc-dev-arch-cross. As these are only necessary for building the cross toolchains, we probably don't want these in the main linux-libc-dev package. So how about adding a linux-libc-dev-cross package with yet more symlinks? Then we can move the provides over to the linux-libc-dev-cross package and that way repair the cross toolchain builds. I requested that linux-libc-dev provides these for bootstrapping to know which architectures linux-libc-dev actually supports. I don't need these provides exactly, I just need a mechanism to answer the question "Does linux-libc-dev work for a particular architecture?" from the binary package metadata, so we might just change the Provides there to linux-libc-dev-arch dropping the -cross suffix that traditionally identified packages putting stuff into /usr/. Does that sound reasonable to you? That still leaves the question of which package would have to build that new linux-libc-dev-cross. The two obvious answers are linux and cross-toolchain-base. Do you have a preference here? I hope this all makes more sense now. Helmut
Bug#1065444: gegl: Correct dpkg-dev build dependency
Source: gegl Version: 1:0.4.44-3ubuntu1 Severity: important Dear maintainer, Yesterday I uploaded an NMU of this package to unstable to add a build dependency on dpkg-dev but I made a mistake in my script and the package is now BD-Uninstallable. I am uploading a fix to unstable now. Apologies for the disruption. Thanks! -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ.UTF-8:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru gegl-0.4.48/debian/changelog gegl-0.4.48/debian/changelog --- gegl-0.4.48/debian/changelog2024-03-04 23:38:29.0 +1300 +++ gegl-0.4.48/debian/changelog2024-03-05 09:37:53.0 +1300 @@ -1,3 +1,10 @@ +gegl (1:0.4.48-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix build depedency on dpkg-dev to use >= not >> (sorry). + + -- Michael Hudson-Doyle Tue, 05 Mar 2024 09:37:53 +1300 + gegl (1:0.4.48-2.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru gegl-0.4.48/debian/control gegl-0.4.48/debian/control --- gegl-0.4.48/debian/control 2024-03-04 23:38:29.0 +1300 +++ gegl-0.4.48/debian/control 2024-03-05 09:37:53.0 +1300 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian GNOME Maintainers Uploaders: Emilio Pozuelo Monfort , Jeremy Bícha , Josselin Mouette -Build-Depends: dpkg-dev (>> 1.22.5), +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), dh-sequence-gir, dh-sequence-gnome,
Bug#1064824: node-d3: fails to export map and other functions
> This gives lots of differences still; stripping down to just the
> differences still has many, many differences: some new exports not in
> the original d3, and some lost exports; the list begins:
> $ diff -u /tmp/d3-npm.exports.trimmed /tmp/d3-debian.exports.trimmed
>
> +exports.Adder = Adder;
> -exports.bisect = bisectRight;
> +exports.bin = bin;
> +exports.bisect = bisect;
> +exports.bisectCenter = bisectCenter;
> +exports.blur2 = blur2;
> +exports.blur = blur;
> +exports.blurImage = blurImage;
> +exports.count = count;
> -exports.csvFormatRow = csvFormatRow;
> -exports.csvFormatValue = csvFormatValue;
$ cat /tmp/d3-debian.exports.trimmed | egrep --color
'(bisectRight|csvFormatRow|csvFormatValue)'
exports.bisectRight = bisectRight;
exports.csvFormatRows = csvFormatRows;
Some of the diff entries are false positive -- it is just that entries are not
identical across these
files and despite sorting them, you do not get the exact picture of the diff in
exports.
However I did not find csvFormatValue and I dug a little bit into it. Seems
this is sourced from node-d3-dsv
and exported with index.js: https://github.com/d3/d3/blob/v5.16.0/index.js
And checking on current unstable
| [/tmp/node-d3-dsv]$ git checkout debian/1.2.0+_1.2.3-1
| HEAD is now at 76229a9 releasing package node-d3-dsv version 1.2.0+~1.2.3-1
| [76229a9][/tmp/node-d3-dsv]$ grep -irn csvFormatValue
| types-d3-dsv/index.d.ts:195:// csvFormatValue(...)
| types-d3-dsv/index.d.ts:202:export function csvFormatValue(value: string):
string;
| src/csv.js:11:export var csvFormatValue = csv.formatValue;
| src/index.js:2:export {csvParse, csvParseRows, csvFormat, csvFormatBody,
csvFormatRows, csvFormatRow, csvFormatValue} from "./csv.js";
So this should work, weird. I wanted to dig in, as per the build log:
https://buildd.debian.org/status/fetch.php?pkg=node-d3=all=5.16.0%2B%7Ecs5.28.10-1=1693715544=0
| Selecting previously unselected package node-d3-dsv.
| Preparing to unpack .../317-node-d3-dsv_1.1.1-9_all.deb ...
| Unpacking node-d3-dsv (1.1.1-9) ...
| Selecting previously unselected packa
And
| [76229a9][/tmp/node-d3-dsv]$ git checkout debian/1.1.1-9
| Previous HEAD position was 76229a9 releasing package node-d3-dsv version
1.2.0+~1.2.3-1
| HEAD is now at 84fbfce releasing package node-d3-dsv version 1.1.1-9
| [84fbfce][/tmp/node-d3-dsv]$ grep -irn csvFormatValue | wc -l
| 0
Which is why. Seems the versions of dev dependencies have not been
appropriately tightened by the upstream
so we are running into weird surprises like these. Re-compiling node-d3 again
now should fixup this export however.
:-(
These minor deltas in exports are more or less due to
version differences in different d3 plugins.
> ...
> Background to this: I'm trying to package a new package which provides
> a web server to visualise some data. The package includes a few
> precompiled JavaScript libraries obtained from npmjs.com, and the
> server works fine with them. But following Debian policy, I need to
> replace those with the source packages. And the server then doesn't
> work.
>
> The JavaScript libraries which the package uses are: d3 v5.16.0,
> d3-tip, apparently v0.9.1, along with jQuery and bootstrap4. I have
> replaced all of these with the versions in the corresponding Debian
> packages (and I've just uploaded a new version of d3-tip, thinking
> that that was the cause of the bug).
>
> When visiting the served web page, the console log gives the error
> message:
>
> Uncaught (in promise) TypeError: t.map is not a function
>n http://localhost:8080/js/d3/d3-tip.min.js:1
>main http://localhost:8080/js/index.js:848
>async* http://localhost:8080/js/index.js:993
>
> (This has changed from the original bug report as the minimised new
> version of d3-tip has t.map instead of h.map.)
>
> d3-tip.js requires d3-collection, from which it calls a map function.
> I tried replacing d3-tip.min.js with the pre-packaged version rather
> than the (newly built) Debian version, but that did not help. I
> reverted that change and instead replaced d3.v5.min.js (which is a
> copy of /usr/share/nodejs/d3/dist/d3.min.js) with the version provided
> by upstream, which is a verbatim copy of the npmjs.com d3.min.js, and
> the server then worked perfectly. So this told me that it is the
> Debian compiled d3 which is not working correctly.
Julian, I am very confused by that wording - from what I could gauge, your
target package does not work with debian libs but it does work with npmjs, yes?
In that case linking your target package and listing the exact steps to
that error can help someone debug it in more detail as to what might be missing.
Best,
Nilesh
signature.asc
Description: PGP signature
Bug#1065443: iwd: CVE-2024-28084
Source: iwd Version: 2.15-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for iwd. CVE-2024-28084[0]: | p2putil.c in iNet wireless daemon (IWD) through 2.15 allows | attackers to cause a denial of service (daemon crash) or possibly | have unspecified other impact because of initialization issues in | situations where parsing of advertised service information fails. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-28084 https://www.cve.org/CVERecord?id=CVE-2024-28084 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications
Hello there, Not sure if this is the correct bug to report this, but I ran into a gnome-shell crash with adwaita-icon-theme 46~beta-3 when opening the overview (Super key) and trying to grab one of the windows: ``` No cursor theme available, please install a cursor theme Received an X Window System error. This probably reflects a bug in the program. The error was 'BadCursor (invalid Cursor parameter)'. (Details: serial 13601 error_code 6 request_code 95 (core protocol) minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the MUTTER_SYNC environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the mtk_x_error() function.) == Stack trace for context 0x58854fb38590 == #0 58854fbffa08 i resource:///org/gnome/shell/ui/init.js:21 (13c026970bf0 @ 48) ``` Running with MUTTER_SYNC=1 extends the stack trace a bit: ``` == Stack trace for context 0x631cbba61570 == #0 631cbbb28c18 i resource:///org/gnome/shell/ui/dnd.js:390 (21d3a36f80b0 @ 440) #1 631cbbb28b68 i resource:///org/gnome/shell/ui/dnd.js:168 (21d3a36f2c90 @ 235) #2 631cbbb28ad8 i resource:///org/gnome/shell/ui/init.js:21 (21d3a3670bf0 @ 48) ``` So it's trying to use the `DND_IN_DRAG` cursor at [1]. I also noticed now that this cursor is missing in Firefox when e.g. dragging a link, but at least Firefox is polite enough to not crash (it just displays the default cursor). Downgrading to adwaita-icon-theme 45.0-4 resolves this. I still get the crash with 46~beta-3, so I guess it's not related to the "more minimal set of aliases". I should also mention I'm using gnome-shell 45.3-2 from experimental. [1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/96b91ec62c9c8133eb7b0e76e486a7cea6edebdb/js/ui/dnd.js#L390 Thanks and greetings, Markus
Bug#1065442: RFS: shaderc/2023.8-1 [RC] -- Library API for accessing glslc functionality - shared libraries
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "shaderc": * Package name : shaderc Version : 2023.8-1 Upstream contact : David Neto * URL : https://github.com/google/shaderc/ * License : Apache-2.0, BSD-3-clause * Vcs : https://salsa.debian.org/debian/shaderc Section : libs The source builds the following binary packages: glslc - Command line compiler for GLSL/HLSL to SPIR-V libshaderc-dev - Library API for accessing glslc functionality - static libraries and headers libshaderc1 - Library API for accessing glslc functionality - shared libraries To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shaderc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shaderc/shaderc_2023.8-1.dsc Changes since the last upload: shaderc (2023.8-1) unstable; urgency=medium . * New upstream release - Refresh patches - Add patch to fix name of Python interpreter - Fix FTBFS (Closes: #1058397) - Refresh d/glslc.lintian-overrides * Fix linking of libshaderc.so, add autopkgtest (Closes: #1029939) * Add obj-x86_64-linux-gnu to d/clean * Use printf instead of echo to generate build-version.inc. Thanks to Vagrant Cascadian! (Closes: #1035324) * Build-Depends on pkgconf instead of pkg-config * d/copyright: update copyright year Regards, -- Philippe
Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
Salvatore Bonaccorso writes: > Ok. In the sprit of the stable series rules we might try the later and > if it's not feasible pick the first variant? Well, "the spirit of the stable series" is one of Greg's titles, and he said either was good...:) jon
Bug#1060235: Information about report to upstream
For the lack of reaction, I also reported the error to the upstream maintainers: https://github.com/WayneD/rsync/issues/577
Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
Hi Jonathan,
On Mon, Mar 04, 2024 at 06:39:26AM -0700, Jonathan Corbet wrote:
> Salvatore Bonaccorso writes:
>
> > Hi,
> >
> > Ben Hutchings reported in https://bugs.debian.org/1064035 a problem
> > with the kernel-doc builds once 3080ea5553cc ("stddef: Introduce
> > DECLARE_FLEX_ARRAY() helper") got applied in 5.10.210 (as
> > prerequisite of another fix in 5.10.y):
> >
> >> The backport of commit 3080ea5553cc "stddef: Introduce
> >> DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
> >> introduced a syntax error:
> >>
> >> Global symbol "$args" requires explicit package name (did you forget to
> >> declare "my $args"?) at ./scripts/kernel-doc line 1236.
> >> Global symbol "$args" requires explicit package name (did you forget to
> >> declare "my $args"?) at ./scripts/kernel-doc line 1236.
> >> Execution of ./scripts/kernel-doc aborted due to compilation errors.
> >>
> >> This doesn't stop the documentation build process, but causes the
> >> documentation that should be extracted by kernel-doc to be missing
> >> from linux-doc-5.10.
> >>
> >> We should be able to fix this by eithering backport commit
> >> e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
> >> into variables" or replacing /$args/ with /([^,)]+)/.
> >>
> >> Ben.
> >
> > What would be prefered here from stable maintainers point of view?
> > AFAICS e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
> > expressions into variables") won't apply cleanly and needs some
> > refactoring. The alternative pointed out by Ben would be to replace
> > the /$args/ with /([^,)]+)/.
>
> Hmm...this is the first I see of any of this...
>
> The latter fix seems like the more straightforward of the two. The only
> concern might be if there are other kernel-doc backports that might run
> afoul of the same problem, hopefully not.
Ok. In the sprit of the stable series rules we might try the later and
if it's not feasible pick the first variant?
> But this makes me wonder if there are other stable kernels that are
> affected as well. I guess that, despite all of the testing being done
> on stable updates, nobody is testing the docs build?
Only 5.10.y is affected AFAICT, and the reaso nis that the cherry-pick
of ("stddef: Introduce DECLARE_FLEX_ARRAY() helper") in 5.10.y (as
requisite of the smb fixes) requires as well e86bdb24375a ("scripts:
kernel-doc: reduce repeated regex expressions into variables").
3080ea5553cc ("stddef: Introduce DECLARE_FLEX_ARRAY() helper") is in
5.10.210, 5.15.54 and 5.16-rc1.
e86bdb24375a ("scripts: kernel-doc: reduce repeated regex expressions
into variables") is in 5.14-rc1.
So it's covered for the later series, but causes problems in the
5.10.y.
Regards,
Salvatore
Bug#1065441: dh-python: pybuild's pyproject plugin puts data files in different directory than the distutils plugin
Package: dh-python Version: 6.20231223ubuntu1 Severity: normal Tags: upstream X-Debbugs-Cc: brett.hol...@canonical.com Dear Maintainer, Recently, my project attempted to switch from the distutils pybuild plugin to the pyproject plugin. Upon doing so, files that were previously installed at various locations in the root filesystem started getting installed under a prefix: /usr/lib/python3/dist-packages/// The files were previously installed using the dh-python distutils plugin, and setup()'s `data_files` keyword argument passed the filename. This change in behavior between plugins prevents our project from using the pyproject plugin. Is this change in behavior expected? If so, is there some environment variable override that could be used to override this behavior to match the distutils behavior. I am unfamiliar with the dh-python codebase, but poking around in the source it seems possible that this line[1] is where prepending of Python path prefix is happening. A bit of history: - In the original commit[2] (5317bb85eca) of this plugin there was some uncertainty around the destination of data files with a comment: #FIXME is this the right dest for data? A later update[3] attempted to follow pip's lead, which was the suggested fix by a user[4]. While this approach may "work", it does break expectations from the distutils plugin, and therefore will likely cause breakage in various projects if we do attempt to make this plugin the default[5]. [1] https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dhpython/build/plugin_pyproject.py?ref_type=heads#L148 [2] https://salsa.debian.org/python-team/tools/dh-python/-/commit/afbc167a10c024ce4890a9d520e6a3ba513494f1 [3] https://salsa.debian.org/python-team/tools/dh-python/-/commit/5317bb85ecaa25ec707221d036c783c0d2a7c9de [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025485 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027864 Note: My apologies if this is the wrong place to file a bug, I don't see a way to file against the project in salsa.debian.org. Regards, Brett Holman -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble') Architecture: amd64 (x86_64) Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 dh-python depends on: ii python3 3.12.1-0ubuntu2 ii python3-distutils 3.11.5-1 ii python3-setuptools 68.1.2-2 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.22.4ubuntu5 pn flit ii libdpkg-perl 1.22.4ubuntu5 ii python3-build 1.0.3-2 pn python3-installer ii python3-wheel 0.42.0-1 -- no debconf information
Bug#1060254: mumble: please make the build reproducible
On zondag 11 februari 2024 14:43:49 CET you wrote: > I went ahead and send your patch upstream and that got accepted. > So I'm attaching a/your patch with all the DEP-3 headers set. There's now a new release/tag v1.5.613 which includes this fix :) signature.asc Description: This is a digitally signed message part.
Bug#1063264: reverse dependencies
Control: tags -1 + moreinfo Hi Alexandre, this seems to be a major task, so I am tagging with moreinfo again. Just for information this is the current list of reverse dependencies: Checking reverse dependencies... # Broken Depends: dioptas: dioptas [amd64] flask-autoindex: python3-flask-autoindex mdp: python3-mdp pyferret: python3-ferret tahoe-lafs: tahoe-lafs # Broken Build-Depends: dioptas: python3-future flask-autoindex: python3-future pyferret: python3-future tahoe-lafs: python3-future mdp is still listed here!? In case they matter, this needs to be addressed first. Please remove the moreinfo tag once that is done. Thorsten
Bug#1062371: reverse dependencie
Control: tags -1 + moreinfo Hi Andreas et al, there are still reverse dependencies that need to be taken care of: Checking reverse dependencies... # Broken Depends: emboss: jemboss emboss-explorer: emboss-explorer # Broken Build-Depends: bioperl-run: emboss embassy-domainatrix: emboss-lib (6.6.1~ <) embassy-domalign: emboss-lib (6.6.1~ <) embassy-domsearch: emboss-lib (6.6.0-1~ >=) emboss-lib (6.6.1~ <) python-biopython: emboss In case they matter, this needs to be addressed first. Please remove the moreinfo tag once that is done. Thorsten
Bug#1065440: tomcat10: /etc/cron.daily/tomcat10 breaks tomcat's own deletion of old access logs
Package: tomcat10 Version: 10.1.6-1+deb12u1 Severity: normal X-Debbugs-Cc: jorge.moral...@gmail.com Dear Maintainer, The tomcat10 package installs file '/etc/cron.daily/tomcat10' that encrypts "old" logs in the '/var/log/tomcat10' directory. The problem is that this cron jobs breaks the new mechanism that tomcat10 uses for deleting its own old log files. In particular adding the option 'maxDays="2" in section pn tomcat10-docs pn tomcat10-examples pn tomcat10-user -- Configuration Files: /etc/tomcat10/policy.d/01system.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/01system.policy' /etc/tomcat10/policy.d/02debian.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/02debian.policy' /etc/tomcat10/policy.d/03catalina.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/03catalina.policy' /etc/tomcat10/policy.d/04webapps.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/04webapps.policy' /etc/tomcat10/policy.d/50local.policy [Errno 13] Permission denied: '/etc/tomcat10/policy.d/50local.policy' -- no debconf information
Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)
On 2024-03-04 16:01 +0100, Axel Beckert wrote:
> Source: aptitude
> Version: 0.8.13-5
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: a...@debian.org, z...@debian.org
>
> Citing from https://buildd.debian.org/status/package.php?p=aptitude:
>
> BinNMU changelog for aptitude on amd64, arm64, armel, armhf, i386,
> mips64el, ppc64el, riscv64, s390x, alpha, hppa, hurd-i386, ia64,
> loong64, m68k, powerpc, ppc64, sh4, sparc64 and x32:
>
> Rebuild for time_t
>
> Tail of log for aptitude on armel:
>
> /usr/include/cppunit/TestAssert.h:161:6: note: candidate:
> ‘template void CppUnit::assertEquals(const T&, const T&,
> SourceLine, const std::string&)’
> 161 | void assertEquals( const T& expected,
> | ^~~~
> /usr/include/cppunit/TestAssert.h:161:6: note: template argument
> deduction/substitution failed:
> ../../tests/test_misc.cc:187:5: note: deduced conflicting types for
> parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long
> int’})
> 187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
> | ^
> make[3]: *** [Makefile:869: test_misc.o] Error 1
> make[3]: Leaving directory '/<>/build/tests'
> make[2]: *** [Makefile:1169: check-am] Error 2
> make[2]: Leaving directory '/<>/build/tests'
> /bin/sh: 1: ./cppunit_test: not found
> make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:22: binary-arch] Error 2
>
> Tail of log for aptitude on armhf:
>
> /usr/include/cppunit/TestAssert.h:161:6: note: candidate:
> ‘template void CppUnit::assertEquals(const T&, const T&,
> SourceLine, const std::string&)’
> 161 | void assertEquals( const T& expected,
> | ^~~~
> /usr/include/cppunit/TestAssert.h:161:6: note: template argument
> deduction/substitution failed:
> ../../tests/test_misc.cc:187:5: note: deduced conflicting types for
> parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long
> int’})
> 187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
> | ^
> make[3]: *** [Makefile:869: test_misc.o] Error 1
> make[3]: Leaving directory '/<>/build/tests'
> make[2]: *** [Makefile:1169: check-am] Error 2
> make[2]: Leaving directory '/<>/build/tests'
> /bin/sh: 1: ./cppunit_test: not found
> make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:22: binary-arch] Error 2
>
> Given the time and the architectures failing, this is probably related
> to dpkg switching on -Werror=implicit-function-declaration on these
> architectures (see https://bugs.debian.org/1065371 and a good summary
> of a similar case in https://bugs.debian.org/1065431 against lintian).
Not really, these arches now default to a 64-bit time_t and therefore
you get the conflicting types (suseconds_t is a long int,
__suseconds64_t a long long int). This has nothing to do with implicit
function declarations.
Cheers,
Sven
Bug#1063376: reverse dependenc
Control: tags -1 + moreinfo Hi Andreas, please file one RM bug for each package that needs to be partially removed. This needs to be done even for dependencies of dependencies. Please remove the moreinfo tag once that is done. Thorsten
Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Acknowledgement (Can't connect to Active Directory with openssl)
On 2024-03-04 12:01:55 [+0100], Maciej Bogucki wrote: > I have just attached pcap file. the remote side rude. The client sent a "Client Hello". The remote side didn't like it and just closed the connection. Rude behaviour is rude. My guess is RSA+SHA1 is missing and is the only accepted signature_algorithms algorithm based on the successfull log. Sebastian
Bug#1065439: dpkg-buildflags: add HIPFLAGS to supported flags
Package: dpkg-dev Version: 1.22.5 Severity: wishlist X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org Dear Maintainer, When packaging the AMD ROCm GPU libraries for Debian, we are currently using CXX=hipcc or CXX=clang++ to build libraries written in HIP as if they were written in C++. This necessitates filtering out flags that are not supported when building HIP language code. For example, the rocsparse d/rules include: export CXX=hipcc export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-fortify optimize=-lto # filter incompatible options from affecting device code CXXFLAGS := $(subst -fstack-protector-strong,-Xarch_host -fstack-protector-strong,$(CXXFLAGS)) CXXFLAGS := $(subst -fcf-protection,-Xarch_host -fcf-protection,$(CXXFLAGS)) In the lines above, we are prepending `-Xarch_host` to prevent certain flags from being applied to device code (i.e., GPU code) while still ensuring that they are applied to host code (i.e., CPU code). However, there is HIP language support in CMake. We should use it! dpkg-buildflags should set HIPFLAGS [1]. The CXXFLAGS make a good starting place for the HIPFLAGS values, but `-Xarch_host` should be added to `-fstack-protector-strong` and `-fcf-protection`, like in the example above. Sincerely, Cory Bloor [1]: https://cmake.org/cmake/help/v3.28/envvar/HIPFLAGS.html -- Package-specific info: -- 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/32 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages dpkg-dev depends on: ii binutils 2.42-3 ii bzip2 1.0.8-5+b2 ii libdpkg-perl 1.22.5 ii make 4.3-4.1 ii patch 2.7.6-7 ii perl 5.38.2-3 ii tar 1.35+dfsg-3 ii xz-utils 5.6.0-0.1 Versions of packages dpkg-dev recommends: ii build-essential 12.10 ii clang-17 [c-compiler]1:17.0.6-5 ii fakeroot 1.33-1 ii gcc [c-compiler] 4:13.2.0-7 ii gcc-13 [c-compiler] 13.2.0-16.1 ii gnupg2.2.40-1.1 ii gpgv 2.2.40-1.1+b1 ii libalgorithm-merge-perl 0.08-5 Versions of packages dpkg-dev suggests: ii debian-keyring 2023.12.24 -- no debconf information
Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Can't connect to Active Directory with openssl
On 2024-03-04 11:16:14 [+0100], Maciej Bogucki wrote: > When I invoke `/usr/bin/openssl s_client -connect 192.168.92.95:636` So you get no reply? That is odd. There has to be reply. A "Connected" line is something I would have expected. If there is nothing then I would assume that the port is silently blocked. … > from latest rocky linux it is ok > > [bogucki@nsd-ansible ~]$ /usr/bin/openssl s_client -connect 192.168.92.95:636 > CONNECTED(0003) see, that line is missing. … > No client certificate CA names sent > Client Certificate Types: RSA sign, DSA sign, ECDSA sign > Requested Signature Algorithms: > RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1 > Shared Requested Signature Algorithms: > RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1 > Peer signing digest: SHA1 > Peer signature type: RSA The remote side looks limited. So from all the possibilities it decided to sign with RSA+SHA1. This is something openssl in bookworm rejects if I am not mistaken. But there has to be an error message about this. If *think* if you lower security level then it should work. Out of curiosity, what is the remote side running? Sebastian
Bug#1054393: dns-root-data: New IPs for b.root-servers-net 2023-11-27
hi Marco, On Mon, Jan 22, 2024 at 12:58:02PM +0100, Marco d'Itri wrote: > This is annoying and needs to be fixed in stable too. > Do you want me to make a NMU? I agree with that as I am someone who could fix for myself, but otherwise I am seeing this noise in my and other ppl systems. (Speaking on my behalf without any authority) it would be nice if you prepare an NMU and upload to the delayed queue. Regards, Tamás --
Bug#1065356: Issues in man pages of cron
Hello Georges, Am Mon, Mar 04, 2024 at 11:47:03AM +0100 schrieb Georges Khaznadar: > Helge Kreutzmann a écrit : > > > > > Secondly we translators see the manpages in the neutral po format, > > > > i.e. converted and harmonized, but not the original source (be it man, > > > > groff, xml or other). So we cannot provide a true patch (where > > > > possible), but only an approximation which you need to convert into > > > > your source format. > > > > > > The original format for Debian's manpages regarding cron is groff. > > Would the translators' work become easier if the manpages were rewritten > in some higher-level language than groff? I must admit that I am not at > ease with groff sources, and that I use weird hacks when modifying such > or such part of a manpage when some feature of cron or crontab is > changed. Simple answer: No. In the end, man pages are transformed into groff and this is what we get, and our toolchain po4a handles it quite nicely. Actually, translators do not see groff at all, but some pseudo language they are familiar with. (Thats why I had to double check my groff proposals, I hardly see groff except when i discuss the issues in the man pages of groff themselves …) > The source in groff format often contains very short lines, where more > context would be necessary to grasp the sense. > > So, please tell me whether it would be useful to rewrite the three > manpages in XML format? From my POV it is not necessary. As said earlier, I think the context is sufficient, translators can always build the entire (translated) file to check and shorter paragraphs are easier to handle and reuse. > This would mean writing sensible paragraphs, with lines of seventy or > more characters, containing simple text and elements marked by tags like > or , which > convey more sense than the bare bold/italics directives available in > groff. In the end, this is up to you and we translators follow suite. Please note, howver, that not all translations are maintained. Currently we have (partial) translations for ko, fr, pl, fi, ro, de and id. There are no active translators for ko, fi and id, and I'm not sure how fast the translators for fr and pl will pick it up. So from my POV I would suggest to keep them as is, unless the pain is really large or you intend to add/update lots of content. > > That's usual, but po4a transforms this in a more friendly format for > > us translators. > > Here is what I understood so far, from the first e-mail you sent me > yesterday, and from the enlightenments provided by the second one: > > Each report chunk is divided in two parts, a list of issues and a > context string, which I describe below in some wild meta-language > using square brackets: > > - > Man page: [source file] > Issue #n: [incorrect format] → [fixed format] > ... > > "[some context, extracted by po4a from the source file]" > "..." > -- > - > > Please can you confirm or infirm that the interpretation above can be > trusted? Yes, this is 100% correct. > > I think most of the report boils down that you update the patches by > > using .B instead of .I or sometimes .BI > > This is a particular consequence of a more general guideline, to follow > recommendations provided by `man man-pages`. I would feel more at ease > if this compliance was ensured by an automated process fed by a source > file with high-level syntactic markup. Yes, I see your point. And if you were to write this from scratch, I would suggest doing so. > > P.S. And since there is probably little changes in cron nowadays, most > > likely few if none further reports from my side… > > I began to maintain cron two years ago, and lowered the bug report count > by approximately one half (regarding reports in bugs.debian.org). Some > reports entailed creating new features, and modifying the manuals > accordingly. I fear that the fifty remaining bug reports will slowly, > but surely involve future changes in man pages, so rewriting them in a > high-level language would probably make future changes more consistent. Ok, I see. Then my points from above a moot, if changes are planned or underway at many places. Thanks for handling cron without a responsive upstream! > Please can you consider this proposition? I would rewrite an XML source > for the manpage crontab.1, and send it; then you run your tools > (probably po4a), and send me a feedback to tell me whether I introduced > more inconsistencies than the count of fixes. No need to do so. Once you have the man pages ready (and I mean the man pages, not the XML sources) simply ship them. Of course, if you want I can quickly glance over them to fix obvious oversights, for this I don't need to involve po4a at all. However, please note that I'm rather busy with real life atm, at least through easter. I might
Bug#1064943: libvte-2.91-0: fails to emit bell if on a different workspace
The maintainers pointed me to this commit: https://gitlab.gnome.org/GNOME/vte/-/commit/6581fea7a4450a724ec3a4bc4859156722d1df1d.patch Applying this on top of 0.75.91 indeed fixes the bug.
Bug#1065396: ghostscript: Coordinate uploads for German man page transfer
Hello Steven, Am Sun, Mar 03, 2024 at 10:25:45PM -0600 schrieb Steven Robbins: > Thanks for the note! > > On Sun, 3 Mar 2024 19:59:28 + Helge Kreutzmann > wrote: > > Package: ghostscript > > Version: 10.0.0~dfsg-11+deb12u3 > > Severity: normal > > > > Hello Steve, > > ghostscript used to contain German man pages, however, they were not > > properly maintained. As detailed in [1] ghostscript removed the > > German man pages from its git repository on January 4th 2023. > > > > So the files are gone since Version 10.01.0rc1. > > > > I imported them into manpages-de and will start shipping them with the > > next release. > > > > As per transition rules [2] you will need to add > > Breaks: manpages-l10n (<4.22) > > in your debian/control. > > OK. Committed to git. Will be uploaded as version 10.02.1~dfsg-4. Thanks. > > I will then add > > Breaks: ghostscript (< > Replaces: ghostscript (< > > > In my debian/control. I'm a bit lost about the correct version, > > though. So which version is best for "?" > > I rarely deal with these situations, so I may be wrong, but > I would think the best version is the new one: 10.02.1~dfsg-4. Ideally it is the first version which stopped shipping the German man pages. Maybe you can browse your git history? It's good for partial upgrades, though in the end I simply accept what you will choose. > > I intend to upload around March 23 and I will provide a backport to > > stable (without these translations, of course). > > OK. You titled the bug "coordinate uploads ...". Do we need to do them > together - on the same day or something? Well, this would be a good idea, to choose roughly the same day, to avoid uninstallable situations for people living on unstable or testing. I'm intending to prepare the next upstream release (and then immediately the Debian release) on 2024-03-23. If this is inconvenient for you, we can wait until April. I simply keep the German man pages in deletion (as I did with previous versions) and then I release -2 on a date more convenient to you (and then ship the German man pages). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1065389: RFS: python-click/8.1.7-1 [ITA] -- Wrapper around optparse for command line utilities - documentation
Hi, Thank you for pointing this out. I had a discussion with Peter Pentchev off-list and we decided it would be better if I take it down from mentors so that Peter can package it from Python Team. I am deleting python-click package from mentors and closing the RFS bug. Thanks, Akash Doppalapudi On 3/4/24 07:32, Bo YU wrote: Hi! On Mon, Mar 4, 2024 at 1:51 AM Akash Doppalapudi wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-click": * Package name : python-click Version : 8.1.7-1 Upstream contact : cont...@palletsprojects.com * URL : https://github.com/pallets/click * License : BSD-3-clause * Vcs : https://salsa.debian.org/python-team/packages/python-click Section : python The source builds the following binary packages: python3-click - Wrapper around optparse for command line utilities - Python 3.x python-click-doc - Wrapper around optparse for command line utilities - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-click/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-click/python-click_8.1.7-1.dsc Changes since the last upload: python-click (8.1.7-1) unstable; urgency=medium . * New upstream version 8.1.7 * New Maintainer (Closes: #1065251) I would like to suggest you contact Peter Pentchev as he/she has reported ITA earlier than your ITA. And would you really want to maintain these packages without Debian Python Team? No other meaning, just considering these packages should be maintained under DPT sounds more reasonable. BR, Bo * d/control: - Change Maintainer name - Add python-click-doc in Suggests for python3-click * d/copyright: - Add new maintainer name in copyright stanza Regards, -- Akash Doppalapudi OpenPGP_0xBCBCAE31ECE05007.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065438: O: gnu-which -- Utility to show the full path of commands
Package: wnpp Control: affects -1 + src:gnu-which X-Debbugs-Cc: gnu-wh...@packages.debian.org Severity: normal I intend to orphan the gnu-which package. Its upstream at GNU is not active, and future maintainers should look into patches carried by other Linux distributions. The package description is: This package provides GNU implementation of which command. This tool provides the functionality to show the full path of commands. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Mon, Mar 04, 2024 at 04:08:37PM +, Simon McVittie wrote: > Copying context from elsewhere in the thread, Sam Hartman wrote: > > Are there solutions in the space of having glib2.0-0 continue to exist > > as a package depended on by glib2.0-0t64 or depending on the new library > > allowing you to replace the postrm? > > to which I replied: > > If libglib2.0-0 continues to exist, then packages that expect the affected > entry points to have 32-bit time_t will still have their dependencies > satisfied, but then when they call the affected entry points, they will > crash, because their time_t is not the same size as GLib's. So as far > as I can see, this is functionally equivalent to reverting the rename: > to be correct, it would have to be accompanied by versioned Breaks on > every package that calls into the affected entry points. Sorry, yes, because we're transitioning the package name but not the soname. My mistake.
