Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library
Hi Bastian Thank you very much! I'll get in contact with Manuel and apply your suggestions BR Burak
Bug#1067413: RFP: keydb -- persistent key-value database with network interface
affects 1067413 + redis-server thanks Hi Guillem, > I'm CCing Chris, who might perhaps be interested in replacing Redis with > KeyDB as its spiritual successor and taking this on? Or if not, at least > to perhaps potentially coordinate some kind of transition, even though > we've had issues migrating persistent DBs from newer Redis to KeyDB, so > that might be tricky or not feasible at all. Thanks for including me here. I had not yet looked into potential Redis replacements nor the exact and precise details of the new license etc. and this activity around KeyDB feels like a good start. I thought I'd let the dust settle for a bit before making any decisions — perhaps the change even gets reversed (!), and no doubt there might be new alternatives that will fork the code immediately prior to the license change. My personal and professional usage of Redis has dropped off in the past few years, so it would make more sense for me to help out in a team maintainership role, at least with respect to KeyDB. However, I'd be interested in coordinating around some kind of Redis→KeyDB/something transition if need be. (Incidentally, why did your work switch to KeyDB?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi, Andrey Rakhmatullin wrote (Fri, 22 Mar 2024 15:50:26 +0500): > On Fri, Mar 22, 2024 at 11:29:11AM +0100, Holger Wansing wrote: > > > I cannot reproduce this. I downloaded debian-policy source package and > > > built > > > it in an up-to-date sid chroot. And the built package has this: > > > > > > $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css > > > lrwxrwxrwx root/root 0 2024-02-24 15:39 > > > ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css -> > > > ../../../../../sphinx_rtd_theme/static/css/theme.css > > > > But above output shows a filesize of 0B. > > Shouldn't that be something different? > Not for symlinks. Ok. > > Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any > > useful content, when you open it? > It's a symlink, it can't have content. > It's target does have content, as shown in the quote below: > > > > So, it is a symlink, not an empty file. When resolving the relative path, > > > I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file > > > exists in sphinx-rtd-theme-common and is non-empty. > > > if you open that theme.css file in the debian/debian-policy build path, > > does it have any content? > :-/ > > > Maybe it was bad wording, when I wrote > > "replaces files provided by read-the-doc theme by empty symlinks" in the > > subject of this bug. > > Probably "symlinks pointing to a not-existing file" is more correct? > To which non-existent files? Are they non-existent only when you don't > have sphinx-rtd-theme-common installed? Sure. > > I don't know where's the problem in detail, I only see that in the > > debian-policy binary package that file is empty, and therefore the html > > layout is broken. > It's not empty, it's a symlink that points to a non-existent (on your > system) file. > > > BTW: the same counts for all the symlinks under _static/fonts/: > > > > holgerw@t520:~/debian-policy$ ls -la > > policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/ > > total 64 > > drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 . > > drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 .. > > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.eot -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot > > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.svg -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg > > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf > > lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 fontawesome-webfont.woff -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff > > lrwxrwxrwx 1 holgerw holgerw 70 Mar 22 11:17 fontawesome-webfont.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2 > > lrwxrwxrwx 1 holgerw holgerw 64 Mar 22 11:17 Lato-BoldItalic.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf > > lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 Lato-BoldItalic.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2 > > lrwxrwxrwx 1 holgerw holgerw 58 Mar 22 11:17 Lato-Bold.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf > > lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Bold.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2 > > lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Italic.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf > > lrwxrwxrwx 1 holgerw holgerw 62 Mar 22 11:17 Lato-Italic.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2 > > lrwxrwxrwx 1 holgerw holgerw 61 Mar 22 11:17 Lato-Regular.ttf -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf > > lrwxrwxrwx 1 holgerw holgerw 63 Mar 22 11:17 Lato-Regular.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2 > > lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 RobotoSlab-Bold.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2 > > lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 RobotoSlab-Regular.woff2 -> > > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2 > > > > All those symlinks are pointing to a not-existing target here. > Only because you don't have sphinx-rtd-theme-common installed. That is indeed installed in the latest version here (sid): root@t520:/# dpkg -s sphinx-rtd-theme-common Package: sphinx-rtd-theme-common Status: install ok installed Priority: optional Section: python Installed-Size: 1173 Maintainer: Debian Python Team Architecture: all Multi-Arch: foreign Source: sphinx-rtd-theme Version: 2.0.0+dfsg-1 Depends: fonts-font-awesome, fonts-lato Description: sphinx theme from readthedocs.org (common files) This mobile-friendly sphinx theme was initially created for readthedocs.org,
Bug#1067494: obs-studio: FTBFS on time64_t archs
Package: obs-studio
Version: 30.0.2+dfsg-2.1
Severity: serious
Hello, looks like we got a failure due to time64_t transition.
/usr/bin/cc -DENABLE_HEVC -DHAVE_OBSCONFIG_H -DHAVE_UDEV -Dlinux_v4l2_EXPORTS -I/<>/libobs
-I/<>/obj-arm-linux-gnueabihf/config -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fno-stack-clash-protection
-fdebug-prefix-map=/<>=/usr/src/obs-studio-30.0.2+dfsg-2.1build2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
-Wdate-time -D_FORTIFY_SOURCE=3 -DFFMPEG_MUX_FIXED=\"/usr/lib/arm-linux-gnueabihf/obs-plugins/obs-ffmpeg/obs-ffmpeg-mux\"
-DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -fvisibility=hidden -Wno-error=deprecated-declarations -std=gnu17 -fPIC -Werror -Wextra -Wvla -Wno-error=vla
-Wswitch -Wno-error=switch -Wformat -Wformat-security -Wunused-parameter -Wno-unused-function -Wno-missing-field-initializers -fno-strict-aliasing
-Werror-implicit-function-declaration -Wno-missing-braces -Wno-error=maybe-uninitialized -DSIMDE_ENABLE_OPENMP -fopenmp-simd -MD -MT
plugins/linux-v4l2/CMakeFiles/linux-v4l2.dir/v4l2-input.c.o -MF plugins/linux-v4l2/CMakeFiles/linux-v4l2.dir/v4l2-input.c.o.d -o
plugins/linux-v4l2/CMakeFiles/linux-v4l2.dir/v4l2-input.c.o -c /<>/plugins/linux-v4l2/v4l2-input.c
/<>/plugins/linux-v4l2/v4l2-input.c: In function ‘v4l2_thread’:
/<>/plugins/linux-v4l2/v4l2-input.c:66:43: error: format ‘%ld’
expects argument of type ‘long int’, but argument 4 has type ‘__suseconds64_t’ {aka ‘long
long int’} [-Werror=format=]
66 | #define blog(level, msg, ...) blog(level, "v4l2-input: " msg,
##__VA_ARGS__)
| ^~
/<>/plugins/linux-v4l2/v4l2-input.c:262:17: note: in expansion of
macro ‘blog’
262 | blog(LOG_DEBUG,
| ^~~~
cc1: all warnings being treated as errors
[137/484] /usr/bin/cc -DENABLE_HEVC -DHAVE_OBSCONFIG_H -Dlinux_jack_EXPORTS -I/<>/libobs
-I/<>/obj-arm-linux-gnueabihf/config -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fno-stack-clash-protection
-fdebug-prefix-map=/<>=/usr/src/obs-studio-30.0.2+dfsg-2.1build2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
-Wdate-time -D_FORTIFY_SOURCE=3 -DFFMPEG_MUX_FIXED=\"/usr/lib/arm-linux-gnueabihf/obs-plugins/obs-ffmpeg/obs-ffmpeg-mux\"
-DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -fvisibility=hidden -Wno-error=deprecated-declarations -std=gnu17 -fPIC -Werror -Wextra -Wvla -Wno-error=vla
-Wswitch -Wno-error=switch -Wformat -Wformat-security -Wunused-parameter -Wno-unused-function -Wno-missing-field-initializers -fno-strict-aliasing
-Werror-implicit-function-declaration -Wno-missing-braces -Wno-error=maybe-uninitialized -DSIMDE_ENABLE_OPENMP -fopenmp-simd -MD -MT
plugins/linux-jack/CMakeFiles/linux-jack.dir/linux-jack.c.o -MF plugins/linux-jack/CMakeFiles/linux-jack.dir/linux-jack.c.o.d -o
plugins/linux-jack/CMakeFiles/linux-jack.dir/linux-jack.c.o -c /<>/plugins/linux-jack/linux-jack.c
I did "fix" with an ugly hacky patch, just for armhf platform, but I don't know
how to properly solve it.
diff -Nru obs-studio-30.0.2+dfsg/debian/patches/time64.patch
obs-studio-30.0.2+dfsg/debian/patches/time64.patch
--- obs-studio-30.0.2+dfsg/debian/patches/time64.patch 1970-01-01
01:00:00.0 +0100
+++ obs-studio-30.0.2+dfsg/debian/patches/time64.patch 2024-03-22
13:31:40.0 +0100
@@ -0,0 +1,18 @@
+Description: Use time64_t everywhere
+Author: Gianfranco Costamagna
+Last-Update: 2024-03-21
+
+--- obs-studio-30.0.2+dfsg.orig/plugins/linux-v4l2/v4l2-input.c
obs-studio-30.0.2+dfsg/plugins/linux-v4l2/v4l2-input.c
+@@ -260,7 +260,11 @@ static void *v4l2_thread(void *vptr)
+ }
+
+ blog(LOG_DEBUG,
++#ifndef __arm__
+"%s: ts: %06ld buf id #%d, flags 0x%08X, seq #%d, len %d, used
%d",
++#else
++ "%s: ts: %06lld buf id #%d, flags 0x%08X, seq #%d, len %d, used
%d",
++#endif
+data->device_id, buf.timestamp.tv_usec, buf.index,
+buf.flags, buf.sequence, buf.length, buf.bytesused);
+
Bug#1067493: [INTL:sv] Swedish strings for uif debconf
package: uif severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother# Translation of uif debconf template to Swedish # Copyright (C) 2024 Martin Bagge # This file is distributed under the same license as the XX package. # # Martin Bagge , 2008, 2024 msgid "" msgstr "" "Project-Id-Version: sv\n" "Report-Msgid-Bugs-To: u...@packages.debian.org\n" "POT-Creation-Date: 2022-05-06 19:27+0200\n" "PO-Revision-Date: 2024-03-22 13:18+0100\n" "Last-Translator: Martin Bagge \n" "Language-Team: Swedish \n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: select #. Choices #: ../templates:1001 msgid "don't touch" msgstr "rör inte" #. Type: select #. Choices #: ../templates:1001 msgid "workstation" msgstr "arbetsstation" #. Type: select #. Choices #: ../templates:1001 msgid "debian-edu-router" msgstr "debian-edu-router" #. Type: select #. Description #: ../templates:1002 msgid "Firewall configuration method" msgstr "Metod för konfigurering av brandväggen" #. Type: select #. Description #: ../templates:1002 msgid "" "Please choose whether the firewall should be configured now with a simple " "\"workstation\" setup, given a specialized Debian Edu Router configuration, " "or left unconfigured so that you can manually edit /etc/uif/uif.conf." msgstr "" "Ange om du vill att brandväggen ska ställas in som en enkel " "\"arbetsstation\", som en specialutformad Debian Edu Router eller lämnas " "helt orörd så att du själv kan redigera /etc/uif/uif.conf." #. Type: string #. Description #: ../templates:2001 msgid "Trusted DNS hostnames:" msgstr "Värdnamn i DNS att lita på:" #. Type: string #. Description #: ../templates:2001 msgid "" "In workstation mode, you can specify some DNS hostnames to be globally " "trusted. All incoming traffic coming from these will be allowed. Multiple " "entries must be separated with spaces." msgstr "" "I läget för arbetsstation kan du ange några DNS-baserade värdnamn att lita " "på. All inkommande trafik från dessa kommer att tillåtas. Separera " "värdnamnen med mellanslag." #. Type: string #. Description #: ../templates:2001 msgid "" "Hostnames provided here must be resolvable to both IPv4 and IPv6 addresses." msgstr "Värdnamnen måste gå att nå både över IPv4 och IPv6." #. Type: string #. Description #: ../templates:2001 msgid "Example: trusted-host-v4-and-v6.mydomain.com" msgstr "Exempel: trusted-host-v4-och-v6.example.com" #. Type: string #. Description #: ../templates:3001 msgid "Trusted IPv4 hosts and/or networks:" msgstr "Ange IPv4-värdar eller nätverk att lita på:" #. Type: string #. Description #: ../templates:3001 msgid "" "In workstation mode, you can specify some IPv4 hosts or networks to be " "globally trusted. All incoming traffic coming from these will be allowed. " "Multiple entries must be separated with spaces." msgstr "" "I läget för arbetsstation kan du ange några IPv4-värdar eller nätverk att " "lita på. All inkommande trafik från dessa kommer att tillåtas. Separera " "värdnamnen med mellanslag." #. Type: string #. Description #: ../templates:3001 msgid "" "If you want to trust DNS hostnames that only resolve to an IPv4 address, " "please enter them here." msgstr "" "Om du vill lita på värdnamn i DNS som enbart går att nå via en IPv4-adress " "så ska dessa anges här." #. Type: string #. Description #: ../templates:3001 msgid "Example: 10.1.0.0/16 trusted-host-v4-only.mydomain.com 192.168.1.55" msgstr "Exempel: 198.51.100.0/24 trusted-host-v4-only.example.com 192.0.2.242" #. Type: string #. Description #: ../templates:4001 msgid "Trusted IPv6 hosts and/or networks:" msgstr "Ange IPv6-värdar eller nätverk att lita på:" #. Type: string #. Description #: ../templates:4001 msgid "" "In workstation mode, you can specify some IPv6 hosts or networks to be " "globally trusted. All incoming traffic coming from these will be allowed. " "Multiple entries must be separated with spaces." msgstr "" "I läget för arbetsstation kan du ange några IPv6-värdar eller nätverk att " "lita på. All inkommande trafik från dessa kommer att tillåtas. Separera " "värdnamnen med mellanslag." #. Type: string #. Description #: ../templates:4001 msgid "" "If you want to trust DNS hostnames that only resolve with an IPv6 address, " "please enter them here." msgstr "" "Om du vill lita på värdnamn i DNS som enbart går att nå via en IPv6-adress " "så ska dessa anges här." #. Type: string #. Description #: ../templates:4001 msgid "Example: 2001:1234:ab::1 fe80::1" msgstr "Exempel: 2001:db8:ab::1 fe80::1" #. Type: boolean #. Description #: ../templates:5001 msgid "Allow ping?" msgstr "Tillåt ping?" #. Type: boolean #. Description #: ../templates:5001 msgid "" "Normally an Internet host should be reachable with \"pings\" (ICMP Echo " "requests). Rejecting this option will disable this, which might be somewhat " "confusing when analyzing network problems." msgstr ""
Bug#1059150: No longer works with signing subkeys
Hi! On Wed, 2024-03-20 at 19:05:59 +, Steve McIntyre wrote: > On Wed, Dec 20, 2023 at 11:59:31PM +0100, Guillem Jover wrote: > >On Wed, 2023-12-20 at 15:30:24 +, Steve McIntyre wrote: > >> Package: debsig-verify > >> Version: 0.23+b2 > >> Severity: important > >> Tags: patch > >Ouch, I've been increasingly unhappy with the whole policy thing, > >because it was not functioning as documented, fixing it to do so has > >broken multiple use cases, it seems like unnecessary complexity and in > >a way trying to reimplement some of the checks that should be done by > >the OpenPGP implementation, and it is getting in the way of adding > >other OpenPGP backends due to the insistence of tying the signature > >issuer fingerprint with the policy to apply, which means the primary > >certificate fingerprint cannot be used as would perhaps be usually > >expected. > > Nod. To make everything work reliably here for all cases, we're now > making 4 copies of the policy directory for every key we might use, > using both the long keyid and the full fingerprint for each of the > master key and the signing subkey. Then we're including a keyring with > all of the keys in each of those policy directories. It's not > wonderful... :-/ Ugh. :/ I'd expect that if the keys are new-ish (and they have a fingerprint packet), and the package providing the policy does not need to cater to old debsig-verify packages then just using the fingerprint path would be enough though? In any case yeah, this is all very nasty. > >I recorded part of this in the TODO, and I had in mind asking you > >about how you use this as part of the redesign work, but I'll leave > >that for a later point. :) > > ACK. :-) > > So, I'm curious... > > Debsig-verify does seem to be really quite over-complicated, at least > for our use case. Wouldn't it be much simpler to just have a keyring > per origin, and then (maybe) a system config file to state which > origin(s) are needed. The policy definition files don't seem to add > any value here. IMHO. I don't know what was the thinking in the original design and implementation choices TBH, the only thing I can go by is the specification and design documents from that time. AFAIR this was designed before (or at a similar time) as the repo signing, so there was probably not much experience in this area. And perhaps also to be flexible for unexpected ways people could end up using this. Also when pondering about how to redesign and simply this, my other fear is that I've had zero visibility over how people are using this (if at all) except four your invaluable input! Currently my thinking is that multiple origins and the role-based signing ideas are not bad, and that some kind of stacking would be interesting to support, as you might want to sign .debs taken from somewhere else, or to record the provenance steps where the packages have gone through (but perhaps no one is using that for example, or would ever do, dunno :). As part of this redesign my main motivation would be to be able to integrate this directly into dpkg-deb (so no new external libraries, where in the past I even played with switching from XML to JSON, but that's still unnecessary complexity and dependencies), and being able to use SOP as the primary OpenPGP interface (probably also gpgv in addition). So from the TODO (slightly edited now): * Redesign policies: - Do not require XML. - Do not require fetching the fingerprint for signatures and keys. - Use the origin name as entry point, and role names to refer to keyrings. - Use filesystem as policy declaration? For example: /keyrings//origin.pgp /keyrings//role-maint.pgp /keyrings//role-uploader.pgp /keyrings//role-builder.pgp - Use a deb822 file for a policy file to denote optional/required/reject? I'm not even sure we might need a deb822 file, perhaps if that part is needed/wanted at all it could even be a few text files with just one line each containing a fingerprint. Say: /keyrings//policy/optional /keyrings//policy/reject /keyrings//policy/required or similar. And then the match would be based on the vendor, not the fingerprint, which then should make key rotation, and the OpenPGP verification (even using SOP) easier to implement, to deploy and to reason about, I think. > It would also be lovely if the design was less restricted by > GnuPG. (Yes, I know!) A real problem for me is that debsig-verify > wants to see *every* signature accounted for when verifying a > package. This is opposite to the behaviour of gpgv, which is more like > what we were inititally expecting / hoping for. We're signing packages > with a rolling range of N keys for our releases, similar to Debian's > Release.gpg setup, and now we have to include 4*N policy directories > for debsig-verify, and our keyring files all have to include *all* the > keys. Yes, the current policy seems all backwards to me too. > So, I'd be tempted by something easier to follow: > > * config to
Bug#1065790: libosmo-netif: FTBFS on arm{el,hf}: tests fail
Source: libosmo-netif Followup-For: Bug #1065790 X-Debbugs-Cc: scho...@ubuntu.com Control: tags -1 ftbfs I looked into this, and AFAICT there's a fundamental mismatch between libosmo-netif and libosmocore: libosmocore defines (struct msgb).cb as a `unsigned long[5]`, but -netif interprets cb[0] as a struct timespec in src/osmux.c, while it defines cb[3] as the SCTP PPID and cb[4] as the SCTP Stream ID in include/osmocom/netif/stream.h That works on architectures where sizeof(time_t) == sizeof(long), in which case sizeof(struct timespec) <= sizeof(long[3]), but that's simply not true when on 32-bit archs with 64b time_t.
Bug#1067492: shared library hard-coded as a build-dependency
Package: src:qtfeedback-opensource-src Version: 5.0~git20180903.a14bd0b-5 Severity: serious Tags: sid trixie ftbfs patch a shared library is hard-coded as a build-dependency, which got renamed ... lets the package ftbfs on armhf, armel, ... patch at http://launchpadlibrarian.net/720636912/qtfeedback-opensource-src_5.0~git20180903.a14bd0b-5build1_5.0~git20180903.a14bd0b-5ubuntu1.diff.gz
Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies
Please see the related MR https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/75 By dropping the hand-written maintscript code, we should mitigate this problem, as the problematic code would not be run on upgrades. In addition, the generated maintscript code used "|| true", so would ignore the systemctl/deb-systemd-invoke failure. Unless of course restart-after-upgrade is not actually what you want for mariadb-server. In this case though, the hand-written code should be removed nonetheless but we would need to adjust the dh_installsystemd call in debian/rules to use the old stop-before-upgrade/start-after-upgrade behaviour. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067469: script for generating the UI does not work
Hi Daniel, On Fri, Mar 22, 2024 at 12:14:51PM +0100, Daniel Swarbrick wrote: > The generate-ui.sh script was substantially refactored in June 2023. The the patch only works for the script that ships with bookworm's 0.25 version. I have seen that the script has been completely re-done for 0.27, and it looks like that might work ootb. > Can you try the script from the latest package from sid? > > [1]: > https://salsa.debian.org/go-team/packages/prometheus-alertmanager/-/commits/debian/sid/debian/generate-ui.sh?ref_type=heads Ok, I'll give it a try. Thank you, Toni
Bug#1059150: No longer works with signing subkeys
Hi! On Wed, 2024-03-20 at 18:00:30 +, Steve McIntyre wrote: > On Wed, Mar 20, 2024 at 05:18:08PM +, Steve McIntyre wrote: > >Sorry, I've been swamped with other stuff then ill for the last week > >or so. Looking now... No worries, hope you are doing well now! :) > And I can confirm that your changes work here for our system too. Perfect, thank you! I'll be rechecking the change and merging and uploading during the weekend. Then will prepare a stable update. Thanks, Guillem
Bug#1063085: uhd: NMU diff for 64-bit time_t transition
Control: reopen -1 Control: severity -1 serious I'm reopening this due to the regression (file conflict) #1063324 Both libuhd4.6.0 and libuhd4.6.0-dpdk provide /usr/lib/x86_64-linux-gnu/libuhd.so.4.6.0 and are conflicting with each other. So I'm a bit confused that only libuhd4.6.0 got renamed to libuhd4.6.0t64 ... Even if libuhd4.6.0-dpdk would not need to be renamed, I'd suggest to rename it anyway to not make the logic too complicated. Anyway libuhd4.6.0-dpdk (or libuhd4.6.0t64-dpdk) needs Conflicts: libuhd4.6.0, libuhd4.6.0t64 to solve #1063324. Andreas
Bug#1067491: time_t transition upgrade: failed systemctl call in preinst due to missing pre-dependencies
Package: mariadb-server Version: 1:10.11.7-3 Severity: serious I did a 2G "apt dist-upgrade" to get my way through the time_t transition. This failed halfway through with the following messages: Uitpakken van .../10-mariadb-server_1%3a10.11.7-3_amd64.deb wordt voorbereid... systemctl: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory dpkg: waarschuwing: subproces van het verouderd pakket mariadb-server het script pre-removal gaf de foutwaarde 127 terug dpkg: script uit het nieuwe pakket wordt geprobeerd als alternatief... systemctl: error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory dpkg: fout bij verwerken van archief /tmp/apt-dpkg-install-IuQoIO/10-mariadb-server_1%3a10.11.7-3_amd64.deb (--unpack): subproces van het nieuwe pakket mariadb-server het script pre-removal gaf de foutwaarde 127 terug Here, the Dutch terms translate (approximately) to: "Unpacking .../10-mariadb-..." dpkg: warning: subproces of the old package mariadb-server pre-removal script return error value 127 dpkg: trying script from the new package as alternative... i.e., the prerm script tries to call systemctl, which fails because libcrypto.so.3 is not on the filesystem. The new package's prerm script tries the same, which fails for the same reason. Checking dpkg.log, I see: 2024-03-22 12:12:24 remove libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status half-configured libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status half-installed libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status config-files libssl3:i386 3.1.5-1 2024-03-22 12:12:24 status not-installed libssl3:i386 2024-03-22 12:12:24 remove libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status half-configured libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status half-installed libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status config-files libssl3:amd64 3.1.5-1 2024-03-22 12:12:24 status not-installed libssl3:amd64 2024-03-22 12:12:24 startup archives unpack 2024-03-22 12:12:25 install libssl3t64:i386 3.1.5-1.1 2024-03-22 12:12:25 status half-installed libssl3t64:i386 3.1.5-1.1 2024-03-22 12:12:25 status unpacked libssl3t64:i386 3.1.5-1.1 [...] 2024-03-22 12:18:20 upgrade mariadb-server:amd64 1:10.11.7-1 1:10.11.7-3 2024-03-22 12:18:20 status half-configured mariadb-server:amd64 1:10.11.7-1 2024-03-22 12:18:20 status installed mariadb-server:amd64 1:10.11.7-1 2024-03-22 12:18:20 upgrade mariadb-server-core:amd64 1:10.11.7-1 1:10.11.7-3 2024-03-22 12:18:20 status half-configured mariadb-server-core:amd64 1:10.11.7-1 2024-03-22 12:18:20 status unpacked mariadb-server-core:amd64 1:10.11.7-1 2024-03-22 12:18:20 status half-installed mariadb-server-core:amd64 1:10.11.7-1 2024-03-22 12:18:21 status unpacked mariadb-server-core:amd64 1:10.11.7-3 Full dpkg.log of this run attached. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server depends on: ii adduser3.137 ii debconf [debconf-2.0] 1.5.86 ii galera-4 26.4.16-2+b1 ii gawk 1:5.2.1-2 ii init-system-helpers1.66 ii iproute2 6.8.0-1 ii libc6 2.37-15.1 ii libdbi-perl1.643-4+b1 ii libpam0g 1.5.3-6 ii libssl3t64 3.1.5-1.1 ii libstdc++6 14-20240315-1 ii lsof 4.95.0-1 ii mariadb-client 1:10.11.7-3 ii mariadb-common 1:10.11.7-3 ii mariadb-server-core1:10.11.7-3 ii passwd 1:4.13+dfsg1-4 ii perl 5.38.2-3.2 ii procps 2:4.0.4-4 ii psmisc 23.7-1 ii rsync 3.2.7-1+b1 ii socat 1.8.0.0-4 ii zlib1g 1:1.3.dfsg-3.1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 ii mariadb-plugin-provider-bzip2 1:10.11.7-3 ii mariadb-plugin-provider-lz4 1:10.11.7-3 ii mariadb-plugin-provider-lzma1:10.11.7-3 ii mariadb-plugin-provider-lzo 1:10.11.7-3 ii mariadb-plugin-provider-snappy 1:10.11.7-3 ii pv 1.8.5-2 Versions of packages mariadb-server suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 ii mailutils [mailx] 1:3.17-1.1+b1 pn mariadb-test ii netcat-openbsd 1.226-1 -- debconf information excluded dpkg.log.gz Description: application/gzip
Bug#1067469: script for generating the UI does not work
The generate-ui.sh script was substantially refactored in June 2023. The patch you have supplied would not apply cleanly, and I suspect that some of the issues may have already been resolved anyway[1] Can you try the script from the latest package from sid? [1]: https://salsa.debian.org/go-team/packages/prometheus-alertmanager/-/commits/debian/sid/debian/generate-ui.sh?ref_type=heads OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067490: tracker.debian.org: Display release-team blocks more prominently
Package: tracker.debian.org Severity: wishlist Hi! Currently when a package is blocked by a release-team block hint, that appears at the end of the "Issues preventing migration" list, which can easily be missed if there are also lots of autopkgtest issues, (see the current dpkg tracker page). ,--- Migration status for dpkg (1.22.4 to 1.22.6): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ Updating dpkg would introduce bugs in testing: #1067427 ∙ ∙ autopkgtest for ceilometer/blocked-on-ci-infra: i386: Ignored failure ∙ ∙ autopkgtest for chrony/4.5-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ autopkgtest for dash/0.5.12-6: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ autopkgtest for dpkg/1.22.6: amd64: Pass, arm64: Pass, armel: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ autopkgtest for gsocket/1.4.41-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ autopkgtest for lintian/2.117.0: amd64: Regression or new test ♻ (reference ♻), arm64: Regression or new test ♻ (reference ♻), armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ (reference ♻), s390x: Regression or new test ♻ (reference ♻) ∙ ∙ Not touching package due to block request by sramacher (please contact debian-release if update is needed) Additional info: ∙ ∙ Piuparts tested OK - https://piuparts.debian.org/sid/source/d/dpkg.html ∙ ∙ Reproducible on amd64 - info ♻ ∙ ∙ Reproducible on arm64 - info ♻ ∙ ∙ Waiting for reproducibility test results on armhf - info ♻ ∙ ∙ Reproducible on i386 - info ♻ ∙ ∙ 11 days old (needed 5 days) Not considered `--- The block seems like the most important information there, because even if everything else gets solved that still requires active action by the release-team. So I think it would be better to place it as the first item, also so that it does not get drown by autopkgtest entries that can be many. Also perhaps the autopkgtest entries should be nested? As in: ,--- ∙ ∙ Status for autopkgtest: ∙ ∙ ∙ ceilometer/blocked-on-ci-infra: i386: Ignored failure ∙ ∙ ∙ chrony/4.5-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ ∙ dash/0.5.12-6: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ ∙ dpkg/1.22.6: amd64: Pass, arm64: Pass, armel: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ ∙ gsocket/1.4.41-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ ∙ lintian/2.117.0: amd64: Regression or new test ♻ (reference ♻), arm64: Regression or new test ♻ (reference ♻), armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ (reference ♻), s390x: Regression or new test ♻ (reference ♻) `--- Which would remove repetition and make it visually easier to see? (This has come up recently, I think multiple times, as I've got multiple private queries, and some public ones, where it looks like people missed the main reason for why dpkg is not migrating.) (Also as an aside, perhaps autopkgtest entries that are all-pass, should appear in the “Additional info” part instead?) Thanks, Guillem
Bug#1066314: regina-rexx: FTBFS: ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]
On Sun, Mar 17, 2024 at 21:41:44 +0100, Agustin Martin wrote: > Some time ago I played a bit with upgrading regina-rexx to a recent > upstream version. I think I can find that stuff and try again with > last upstream version. In case of success, I would like to push > changes to regina-rexx salsa repo for further inspection. Let me know > your POV. Hi Agustin, I have an objection to that! Please do not hesitate to NMU Regina packages. Thanks, -- Alen Zekulic signature.asc Description: PGP signature
Bug#1062963: patch is incomplete
Il 22/03/2024 03:31, Matthias Klose ha scritto: Control: reopen -1 Control: tags -1 + ftbfs patch some library names in the symbols file were omitted. patch attached. http://launchpadlibrarian.net/720580389/muffin_6.0.1-1build1_6.0.1-1ubuntu1.diff.gz thanks, I didn't notice that, I just noticed another bad breaks/replaces issue in libmuffin-dev on nmu to unstable was fixed, I'll fix in experimental too OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067489: RFS: python-jsbeautifier/1.15.1-1 -- JavaScript unobfuscator and beautifier
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-jsbeautifier": * Package name : python-jsbeautifier Version : 1.15.1-1 Upstream contact : Liam Newman, Einar Lielmanis, et al. * URL : https://github.com/beautify-web/js-beautify * License : MIT * Vcs : https://salsa.debian.org/debian/python-jsbeautifier Section : python The source builds the following binary packages: python3-jsbeautifier - JavaScript unobfuscator and beautifier (python3) jsbeautifier - JavaScript unobfuscator and beautifier To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-jsbeautifier/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-jsbeautifier/python-jsbeautifier_1.15.1-1.dsc Changes since the last upload: python-jsbeautifier (1.15.1-1) unstable; urgency=medium . * New upstream release. * Add year 2024 to myself. * Update man-page. * Add patch to fix regex warning with Python 3.12 Regards, -- Håvard
Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
On Fri, Mar 22, 2024 at 11:29:11AM +0100, Holger Wansing wrote: > > I cannot reproduce this. I downloaded debian-policy source package and built > > it in an up-to-date sid chroot. And the built package has this: > > > > $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css > > lrwxrwxrwx root/root 0 2024-02-24 15:39 > > ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css -> > > ../../../../../sphinx_rtd_theme/static/css/theme.css > > But above output shows a filesize of 0B. > Shouldn't that be something different? Not for symlinks. > Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any > useful content, when you open it? It's a symlink, it can't have content. It's target does have content, as shown in the quote below: > > So, it is a symlink, not an empty file. When resolving the relative path, > > I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file > > exists in sphinx-rtd-theme-common and is non-empty. > if you open that theme.css file in the debian/debian-policy build path, > does it have any content? :-/ > Maybe it was bad wording, when I wrote > "replaces files provided by read-the-doc theme by empty symlinks" in the > subject of this bug. > Probably "symlinks pointing to a not-existing file" is more correct? To which non-existent files? Are they non-existent only when you don't have sphinx-rtd-theme-common installed? > I don't know where's the problem in detail, I only see that in the > debian-policy binary package that file is empty, and therefore the html > layout is broken. It's not empty, it's a symlink that points to a non-existent (on your system) file. > BTW: the same counts for all the symlinks under _static/fonts/: > > holgerw@t520:~/debian-policy$ ls -la > policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/ > total 64 > drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 . > drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 .. > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.eot -> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.svg -> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg > lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.ttf -> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf > lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 fontawesome-webfont.woff -> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff > lrwxrwxrwx 1 holgerw holgerw 70 Mar 22 11:17 fontawesome-webfont.woff2 -> > ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2 > lrwxrwxrwx 1 holgerw holgerw 64 Mar 22 11:17 Lato-BoldItalic.ttf -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf > lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 Lato-BoldItalic.woff2 -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2 > lrwxrwxrwx 1 holgerw holgerw 58 Mar 22 11:17 Lato-Bold.ttf -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf > lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Bold.woff2 -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2 > lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Italic.ttf -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf > lrwxrwxrwx 1 holgerw holgerw 62 Mar 22 11:17 Lato-Italic.woff2 -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2 > lrwxrwxrwx 1 holgerw holgerw 61 Mar 22 11:17 Lato-Regular.ttf -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf > lrwxrwxrwx 1 holgerw holgerw 63 Mar 22 11:17 Lato-Regular.woff2 -> > ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2 > lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 RobotoSlab-Bold.woff2 -> > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2 > lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 RobotoSlab-Regular.woff2 -> > ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2 > > All those symlinks are pointing to a not-existing target here. Only because you don't have sphinx-rtd-theme-common installed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1055279: tox-current-env: potential bugs on armel
Hi Bo, Thanks for the short reaction time and for spending your time on this bug, much appreciated! On Fri, Mar 22, 2024 at 01:26:35PM +0800, Bo YU wrote: > Thanks your detailed analysis for it. I have uploaded -3 to unstable to > hope to unblock tox migrating. But these are some unexpected maybe. tox has migrated since. Honestly I'm not sure why, given the regression! So there isn't as much urgency as there was when I filed this bug, I'd say. > This will lead a autopkgtest on s390x[0] again from its tracker page[1] to > get the link(UTC+8 13:06 2024/03/22). > > But another retry on s390x it passed on s390x[2]. > > [0]: https://ci.debian.net/packages/t/tox-current-env/testing/s390x/44235641/ > [1]: https://tracker.debian.org/pkg/tox-current-env > [2]: https://ci.debian.net/packages/t/tox-current-env/ Yup, looks like the same bug all over the place, effectively a race. > Do you think I will need to upload it to unstable again with `sorted` > for `test_allenvs_print_deps_to_file` as I analyzed above? It's clearly a bug IMHO, so it'd be good to fix at some point. No urgency with regards to the tox migration as I said, but this will happen again on e.g. the next tox upload. If I were you I'd fix it in git, submit all of these fixes to upstream, wait a month or two so in case upstream releases a new version (hopefully with these), and then upload regardless. Thanks again, Faidon
Bug#1067488: mirror listing update for mirror.lon.macarne.com
Package: mirrors Severity: minor User: mirr...@packages.debian.org Usertags: mirror-list Submission-Type: update Site: mirror.lon.macarne.com Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Arne Country: GB United Kingdom Location: London Sponsor: Macarne LLC https://macarne.com Comment: We've done a tiny firewall hardening and it broke the 80/443 open connections. Please re-enable the mirror on your end ;) Much obliged. eu...@macarne.com Trace Url: http://mirror.lon.macarne.com/debian/project/trace/ Trace Url: http://mirror.lon.macarne.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.lon.macarne.com/debian/project/trace/mirror.lon.macarne.com
Bug#1067487: mercurial-evolve: update for mercurial 6.7
Source: mercurial-evolve Version: 10.5.3-4 Tags: sid trixie X-Debbugs-Cc: jcris...@debian.org Mercurial 6.7 breaks at least the topic extension (https://repo.mercurial-scm.org/evolve/rev/3635782b0290); not sure about evolve. Cheers, Julien
Bug#1067288: pulseaudio: FTBFS on x86: cpu-volume-test fails, segfault in svolume_orc_test
Control: retitle -1 pulseaudio: FTBFS on x86: cpu-volume-test fails, segfault in svolume_orc_test Control: reassign -1 src:orc 1:0.4.38-1 Control: forwarded -1 https://gitlab.freedesktop.org/gstreamer/orc/-/issues/66 Control: tags 1067458 + ftbfs sid trixie Control: merge 1067458 -1 Control: affects 1067458 + src:pulseaudio On Wed, 20 Mar 2024 at 21:48:23 +0100, Lucas Nussbaum wrote: > > === 47/53 > > > > test: cpu-volume-test > > start time: 06:46:56 > > duration: 2.82s > > result: exit status 1 > > command: > > UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 > > > > LD_LIBRARY_PATH=/<>/obj-x86_64-linux-gnu/src/pulse:/<>/obj-x86_64-linux-gnu/src/pulsecore:/<>/obj-x86_64-linux-gnu/src > > MALLOC_PERTURB_=255 MAKE_CHECK=1 > > ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 > > /<>/obj-x86_64-linux-gnu/src/tests/cpu-volume-test > > --- stdout > > --- > > Running suite(s): CPU > > 66%: Checks: 3, Failures: 0, Errors: 1 > > ../src/tests/cpu-volume-test.c:188:E:svolume:svolume_orc_test:0: (after > > this point) Received signal 11 (Segmentation fault) > > == This seems to be the same issue as #1067458. If a fix isn't obvious, could we perhaps roll back orc to 0.4.34 (presumably versioned as 1:0.4.38+really0.4.34), or disable its use in PulseAudio for now? Thanks, smcv
Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi Dmitry,
Dmitry Shachnev wrote (Fri, 22 Mar 2024 00:35:57 +0300):
> I cannot reproduce this. I downloaded debian-policy source package and built
> it in an up-to-date sid chroot. And the built package has this:
>
> $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
> lrwxrwxrwx root/root 0 2024-02-24 15:39
> ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css ->
> ../../../../../sphinx_rtd_theme/static/css/theme.css
But above output shows a filesize of 0B.
Shouldn't that be something different?
Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any
useful content, when you open it?
> So, it is a symlink, not an empty file. When resolving the relative path,
> I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
> exists in sphinx-rtd-theme-common and is non-empty.
As above:
if you open that theme.css file in the debian/debian-policy build path,
does it have any content?
If I open it here, nano shows "New file" in the status bar at the bottom,
so the file does not exist.
Maybe it was bad wording, when I wrote
"replaces files provided by read-the-doc theme by empty symlinks" in the
subject of this bug.
Probably "symlinks pointing to a not-existing file" is more correct?
> The only issue I see is that sphinx-rtd-theme-common is in Recommends of
> debian-policy, not in Depends. But that is because ${sphinxdoc:Depends}
> was put there.
>
> Am I doing something wrong?
I don't know where's the problem in detail, I only see that in the
debian-policy binary package that file is empty, and therefore the html
layout is broken.
BTW: the same counts for all the symlinks under _static/fonts/:
holgerw@t520:~/debian-policy$ ls -la
policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/
total 64
drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 .
drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 ..
lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.eot ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot
lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.svg ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg
lrwxrwxrwx 1 holgerw holgerw 68 Mar 22 11:17 fontawesome-webfont.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf
lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 fontawesome-webfont.woff ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff
lrwxrwxrwx 1 holgerw holgerw 70 Mar 22 11:17 fontawesome-webfont.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2
lrwxrwxrwx 1 holgerw holgerw 64 Mar 22 11:17 Lato-BoldItalic.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf
lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 Lato-BoldItalic.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2
lrwxrwxrwx 1 holgerw holgerw 58 Mar 22 11:17 Lato-Bold.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf
lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Bold.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2
lrwxrwxrwx 1 holgerw holgerw 60 Mar 22 11:17 Lato-Italic.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf
lrwxrwxrwx 1 holgerw holgerw 62 Mar 22 11:17 Lato-Italic.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2
lrwxrwxrwx 1 holgerw holgerw 61 Mar 22 11:17 Lato-Regular.ttf ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf
lrwxrwxrwx 1 holgerw holgerw 63 Mar 22 11:17 Lato-Regular.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2
lrwxrwxrwx 1 holgerw holgerw 66 Mar 22 11:17 RobotoSlab-Bold.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2
lrwxrwxrwx 1 holgerw holgerw 69 Mar 22 11:17 RobotoSlab-Regular.woff2 ->
../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2
All those symlinks are pointing to a not-existing target here.
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed
Package: grub-efi-amd64-signed Version: 1+2.12+1 Severity: serious X-Debbugs-Cc: sweetyf...@deepin.org Hi, grub-efi-amd64-signed seems uninstallable now in sid. This might caused by a binNMU in src:grub2. The following packages have unmet dependencies: grub-efi-amd64-signed : Depends: grub-common (= 2.12-1) but it is not going to be installed $ apt policy grub-common grub-common: Installed: (none) Candidate: 2.12-1+b1 Version table: 2.12-1+b1 500 500 http://mirrors.cernet.edu.cn/debian sid/main amd64 Packages Please upload a new version so grub-efi-amd64-signed can be installable. Thanks! Best regards, Tianyu Chen @ deepin
Bug#1027405: regina-rexx FTCBFS: builds for the build architecture
On Fri, Dec 30, 2022 at 10:46:18PM +0100, Helmut Grohne wrote:
> Source: regina-rexx
> Version: 3.6-2.4
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> regina-rexx fails to cross build from source, because it builds for the
> build architecture. Fixing this is not entirely trivial. The obvious fix
> of passing --build and --host to configure is insufficient. Beyond that,
> the C compiler must be forced via the CC environment variable. Even
> then, the build system fails to transfer this assignment over to make.
> To make matters worse, it skips checking for --version-script (and thus
> symbol versioning) unless the compiler is exactly gcc. I'm attaching a
> patch for your convenience.
Hi, Helmut,
First thanks a lot for the analysis and the fix proposals.
I am not regina-rexx maintainer, but I am preparing a fix proposal (or
a NMU if required) for regina-rexx because of #1066314 FTBFS, which
will include a newer upstream version.
While I am with that, I would also like to address this cross
compilation problem, and looking at your patch I have some questions,
even if only to properly document changes.
About debian/rules changes,
I wonder if passing CC compiler to configure is done just because
otherwise C compiler will not be found because of unusual name during
cross compilation, or there is another reason.
Passing CC to 'make' may not be needed. Another patch changes
Makefile.in to no longer hardcode CC, CFLAGS, RANLIB and LDFLAGS. As a
matter of fact, I woud expect no problems if LDFLAGS is not passed.
CFLAGS is passed only to concat CPPFLAGS (may be CFLAGS += $(CPPFLAGS)
and export CFLAGS could make that useless).
Other changes in debian/rules are clear and very useful, thanks.
About changes in configure{,.in} I would leave a check for GCC, I
guess upstream wants other compilers supported. I would like to have a
change that might be sent upstream, so for portability I would use a
case statement, now written in a very generic way (see attached diff
for that). Which kind of strings are expected as C compiler during
cross compilation?
Thanks again for everything,
Regards,
--
Agustin
Description: Allow a more permissive gcc|g++ check for cross compilation.
Compiler name may have prefix|suffix when cross compiling.
Bug-Debian: http://bugs.debian.org/1027405
Forwarded:
--- a/configure.in
+++ b/configure.in
@@ -416,9 +416,11 @@ fi
AC_SUBST(MY_GETOPT_O)
AC_SUBST(MY_GETOPT_SO_O)
-if test "$ac_cv_prog_CC" = "gcc" -o "$ac_cv_prog_CC" = "g++"; then
- REG_CHECK_GCC_VERSION_SCRIPT
-fi
+case "$ac_cv_prog_CC" in
+ *gcc*|*g++*)
+ REG_CHECK_GCC_VERSION_SCRIPT
+ ;;
+esac
dnl enable_posix_threads="yes"
REG_CHECK_POSIX_THREADS
--- a/configure
+++ b/configure
@@ -6342,7 +6342,8 @@ fi
-if test "$ac_cv_prog_CC" = "gcc" -o "$ac_cv_prog_CC" = "g++"; then
+case "$ac_cv_prog_CC" in
+ *gcc*|*g++*)
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether gcc understands --version-script" >&5
$as_echo_n "checking whether gcc understands --version-script... " >&6; }
@@ -6390,7 +6391,8 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $mh_cv_version_script" >&5
$as_echo "$mh_cv_version_script" >&6; }
-fi
+ ;;
+esac
MH_MT_LIBS=""
Bug#1067147: dcmtk: diff for NMU version 3.6.7-9.2
Hi Aurelien and Michael, On 2024-03-21 08:54, Aurelien Jarno wrote: > On 2024-03-19 11:54, Emanuele Rocca wrote: > > diff -Nru dcmtk-3.6.7/debian/control dcmtk-3.6.7/debian/control > > --- dcmtk-3.6.7/debian/control 2024-02-28 02:17:02.0 +0100 > > +++ dcmtk-3.6.7/debian/control 2024-03-19 11:08:29.0 +0100 > > @@ -16,7 +16,7 @@ > > libxml2-dev, > > zlib1g-dev > > Build-Depends-Indep: doxygen, > > - graphviz > > + graphviz [!armhf !armel] > > This does not look correct. Build-Depends-Indep are only used to build > the arch:all packages, and currently all the arch:all autobuilder run on > amd64. Ah, thanks for spotting this. The change was needed in order to build locally in a clean armel sbuild environment, but as you say is not needed on the buildds. > Therefore it looks to me that this change is not necessary to > help the armel/armhf rebootstrap done as part of the time_t transition. Indeed the main goal of the proposed changes was fixing a FTBFS bug in dcmtk entirely unrelated to the time_t transition (#1060104), but the relevant changelog entry from my NMU mentioning that was forgotten: * Build without stack-clash-protection on armel. See #1060104. Anyways, what matters is that now dcmtk builds fine on armel in sid with stackclash disabled. I've opened https://salsa.debian.org/med-team/dcmtk/-/merge_requests/1 to revert the changes to build-depends-indep. Thanks, Emanuele
Bug#1067485: python-pysaml2: please make the build reproducible
Source: python-pysaml2 Version: 7.4.2-3 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that python-pysaml2 could not be built reproducibly. This is because the tests generate a (nondeterministic) file called eptid.db that is then shipped in the binary package. Incidentally, the file is installed directly to the global /usr/lib/python3/dist-packages directory, which is a likely a bug in itself. (Hm, isn't there a Lintian warning for this?) Anyway, patch attached that removes this file after running the tests. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-22 09:31:42.477985685 + --- b/debian/rules 2024-03-22 09:59:35.122321091 + @@ -21,6 +21,9 @@ for i in $$(find . -type d -iname __pycache__) ; do rm -rf $$i ; done dh_auto_clean +execute_after_dh_auto_test: + find .pybuild -type f -name eptid.db -delete + #override_dh_install: # dh_install # set -e ; set -x ; for i in `ls $(CURDIR)/debian/python3-pysaml2/usr/bin/*.py` ; do \
Bug#1067484: node-function-bind: please make the build reproducible
Source: node-function-bind Version: 1.1.2+~cs2.1.14-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that node-function-bind could not be built reproducibly. This is because it ships test coverage information generated using the run of the testsuite. These files in turn contain nondeterministic dates: │ │ │ ├── ./usr/share/nodejs/has/coverage/index.html │ │ │ │ Code coverage generated by │ │ │ │ https://istanbul.js.org/; target="_blank" rel="noopener noreferrer">istanbul │ │ │ │ -at Thu Apr 24 2025 09:17:32 GMT+ (GMT) │ │ │ │ +at Fri Mar 22 2024 02:58:54 GMT+ (GMT) Patch attached that simply removes these files from the binary package. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-22 09:42:48.097059681 + --- b/debian/rules 2024-03-22 09:51:56.744545540 + @@ -9,6 +9,9 @@ %: dh $@ --with nodejs +execute_after_dh_auto_test: + rm -rf has/coverage + override_dh_installdocs: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES))) dh_installdocs
Bug#1067483: postfix: please make the build reproducible
Source: postfix Version: 3.9.0-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that postfix could not be built reproducibly: /usr/share/doc/postfix/examples/makedefs.out # AUXLIBS=-lssl -lcrypto -lsasl2 -lpthread -# AUXLIBS_CDB=-lcdb +# AUXLIBS_PCRE=-lpcre2-8 +# AUXLIBS_PGSQL=-lpq +# AUXLIBS_MYSQL=-lmysqlclient +# AUXLIBS_SQLITE=-lsqlite3 # AUXLIBS_MONGODB=-lmongoc-1.0 -lbson-1.0 This is caused by printing the output of "env" without piping it through sort(1) — see the attached patch. We don't need to specify LC_ALL=C as this is already done on line 189. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1067112: fangfrisch: missing dependency on clamdscan
severity 1067112 wishlist retitle 1067112 fangfrisch: mention clamdscan in Suggests or Recommends and/or Enhances thanks Op Mon, Mar 18, 2024 at 10:09:34PM -0400 schreef Scott Kitterman: > On Monday, March 18, 2024 11:39:04 AM EDT Joost van Baal-Ilić wrote: > > Package: fangfrisch > > Version: 1.9.0-1 > > Severity: normal > > > > Hi, > > > > Thanks for maintaining fangfrisch! > > > > When running > > > > clamav@donmel:~$ fangfrisch --conf /etc/fangfrisch.conf initdb > > > > , in order to get fangfrisch properly setup, the fangfrisch software fails > > with: > > > > Mar 18 16:01:29 donmel fangfrisch[143542]: ERROR: /bin/sh: 1: clamdscan: > > not found > > > > . Please add clamdscan to fangfrisch's debian/control "Depends: ": that > > should fix this. > > That's not a configuration file provided by Debian, so I don't think this is > a > valid bug in Debian (it's not the upstream default either). It's quite > possible to use fangfrisch to just download data on one machine for further > distribution on an internal network. > > It should at least be Suggests and probably Recommends though. It could also > probably stand to have Enahnces: clamdscan. Indeed, I failed to mention I have specified [DEFAULT] db_url = sqlite:var/lib/fangfrisch/db.sqlite local_directory = /var/lib/clamav max_size = 10MB on_update_exec = clamdscan --reload on_update_timeout = 42 [...] in my /etc/fangfrisch.conf . Suggests / Recommends sounds perfectly fine, as does Enhances: clamdscan. Thanks, Bye, Joost
Bug#1067468: these tests also fail with openmpi on amd64 and ppc64el
Control: severity -1 normal On 22.03.24 01:22, Samuel Thibault wrote: Matthias Klose, le ven. 22 mars 2024 01:11:09 +0100, a ecrit: these tests also fail with openmpi on amd64 and ppc64el ? I can't reproduce this. sorry, only saw that for an Ubuntu build: https://launchpad.net/ubuntu/+source/eztrace/2.1-7ubuntu3 but please could you run all three testsuites, and only then fail the build?
Bug#1067426: Package sponsorship request Qucs-S
On 21/03/2024 13:56, Vadim Kuznetsov wrote: Package: sponsorship-requests Severity: normal I am looking for a sponsor for my package "qucs-s": * Package name : qucs-s Version : 24.1.0-1 Upstream contact : Vadim Kuznetsov * URL : https://github.com/ra3xdh/qucs_s * License : GPL-2.0 * Vcs : https://github.com/ra3xdh/qucs_s.git Section : electronics| Hi Vadim, I'm wondering if you should file an RFP here? https://wiki.debian.org/RFP But please note there are over 3,000 outstanding already! (For a sponsorship request, you need to package yourself, and upload to mentors https://mentors.debian.net/ and use the RFS template to file a sponsorship request. (The VCS field there is for the packaging VCS, not your upstream VCS) Regards, Peter
Bug#1067468: these tests also fail with openmpi on amd64 and ppc64el
Hello, Matthias Klose, le ven. 22 mars 2024 03:29:04 +0100, a ecrit: > On 22.03.24 01:22, Samuel Thibault wrote: > > Matthias Klose, le ven. 22 mars 2024 01:11:09 +0100, a ecrit: > > > these tests also fail with openmpi on amd64 and ppc64el > > > > ? I can't reproduce this. > > sorry, only saw that for an Ubuntu build: > https://launchpad.net/ubuntu/+source/eztrace/2.1-7ubuntu3 Ok. These failures look extremely odd. > Running mpirun.openmpi --oversubscribe -np 2 > /<>/build-openmpi/src/eztrace -p -t openmpi ./mpi_ping 2: Eztrace test Mode 2: Eztrace test Mode 2: Abort(33616) on node 0: Fatal error in internal_Comm_size: Invalid communicator, error stack: 2: internal_Comm_size(30769): MPI_Comm_size(comm=0xb6061990, size=0xb86caa54) failed 2: internal_Comm_size(30723): Invalid communicator The program has basically only called int comm_size = -1; MPI_Init(, ); MPI_Comm_size(MPI_COMM_WORLD, _size); Which is essentially a smoketest for a working mpi implementation. And these error messages are coming from mpich, not from openmpi! I'm wondering if ubuntu is perhaps mixing libmpi from mpich and from openmpi? > but please could you run all three testsuites, and only then fail the build? Done so in the git tree. I have also added a smoketest for working MPI implementations (without any use of eztrace). Samuel
Bug#1067482: libhinawa: please drop runtime glib2.0 hardcoded dependency
Package: libhinawa
Version: 4.0.1-2.1
Severity: normal
Tags: patch
Hello,
I will NMU the removal of glib2.0 hardcoded runtime dependency to ease the
transition
diff -Nru libhinawa-4.0.1/debian/changelog libhinawa-4.0.1/debian/changelog
--- libhinawa-4.0.1/debian/changelog2024-02-28 21:37:13.0 +0100
+++ libhinawa-4.0.1/debian/changelog2024-03-22 09:56:48.0 +0100
@@ -1,3 +1,10 @@
+libhinawa (4.0.1-2.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop glib runtime dependency (Closes: #-1)
+
+ -- Gianfranco Costamagna Fri, 22 Mar 2024
09:56:48 +0100
+
libhinawa (4.0.1-2.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru libhinawa-4.0.1/debian/control libhinawa-4.0.1/debian/control
--- libhinawa-4.0.1/debian/control 2024-02-28 21:35:29.0 +0100
+++ libhinawa-4.0.1/debian/control 2024-03-22 09:56:48.0 +0100
@@ -20,8 +20,7 @@
Provides: ${t64:Provides}
Architecture: linux-any
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends},
-libglib2.0-0 (>= 2.44.0)
+Depends: ${shlibs:Depends}, ${misc:Depends}
Breaks: libhinawa4 (<< ${source:Version}), libhinawa2 (<< 4.0.0)
Replaces: libhinawa4, libhinawa2 (<< 4.0.0)
Multi-Arch: same
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1067481: cups: package (transitively?) conflicts with KDE
Package: cups Version: 2.4.7-1+b1 Severity: normal X-Debbugs-Cc: debianb...@schirmeier.com Dear Maintainer, on 2024-03-19, the following apt dist-upgrade removed -- without me noticing -- cups from my system, leaving me without printing capabilities: Commandline: apt -V dist-upgrade Requested-By: hsc (1000) Install: libqt5xml5t64:amd64 (5.15.10+dfsg-7.2+b1, automatic), libhogweed6t64:amd64 (3.9.1-2.2, automatic), libhogweed6t64:i386 (3.9.1-2.2, automatic), libqt5sql5t64:amd64 (5.15.10+dfsg-7.2+b1, automatic), libgsoap-2.8.132t64:amd64 (2.8.132-2.1+b1, automatic), libcups2t64:amd64 (2.4.7-1.2+b1, automatic), libqt5gui5-gles:amd64 (5.15.10+dfsg-5, automatic), libcurl3t64-gnutls:amd64 (8.6.0-4, automatic), libxt6t64:amd64 (1:1.2.1-1.2, automatic), libqt5printsupport5t64:amd64 (5.15.10+dfsg-7.2+b1, automatic), libqt5widgets5t64:amd64 (5.15.10+dfsg-7.2+b1, automatic), libnextcloudsync0t64:amd64 (3.11.0-1.1+b1, automatic), libprotobuf32t64:amd64 (3.21.12-8.2, automatic), libqt5dbus5t64:amd64 (5.15.10+dfsg-7.2+b1, automatic), libqt5network5t64:amd64 (5.15.10+dfsg-7.2+b1, automatic), libssl3t64:amd64 (3.1.5-1.1, automatic), libqt5quick5-gles:amd64 (5.15.10+dfsg-2+b1, automatic), libpng16-16t64:amd64 (1.6.43-3, automatic), libqt5core5t64:amd64 (5.15.10+dfsg-7.2+b1, automatic), libmtdev1t64:amd64 (1.1.6-1.1, automatic) Upgrade: orca:amd64 (45.2-1, 46.0-1), virtualbox:amd64 (7.0.14-dfsg-4, 7.0.14-dfsg-4+b3), android-liblog:amd64 (1:34.0.4-1, 1:34.0.4-1+b1), dosfstools:amd64 (4.2-1, 4.2-1.1), libidn12:amd64 (1.42-1, 1.42-2), adb:amd64 (1:34.0.4-1, 1:34.0.4-1+b1), libwww-perl:amd64 (6.76-1, 6.77-1), google-chrome-stable:amd64 (122.0.6261.128-1, 123.0.6312.58-1), libsuitesparseconfig7:amd64 (1:7.6.0+dfsg-1, 1:7.6.1+dfsg-1), libbz2-dev:amd64 (1.0.8-5+b2, 1.0.8-5.1), libamd3:amd64 (1:7.6.0+dfsg-1, 1:7.6.1+dfsg-1), libgpm2:amd64 (1.20.7-10+b2, 1.20.7-11), bzip2:amd64 (1.0.8-5+b2, 1.0.8-5.1), libcamd3:amd64 (1:7.6.0+dfsg-1, 1:7.6.1+dfsg-1), python3-wheel:amd64 (0.42.0-1, 0.43.0-1), libfontenc1:amd64 (1:1.1.4-1+b2, 1:1.1.8-1), nextcloud-desktop-cmd:amd64 (3.11.0-1, 3.11.0-1.1+b1), android-libbase:amd64 (1:34.0.4-1, 1:34.0.4-1+b1), libssh2-1t64:amd64 (1.11.0-4.1, 1.11.0-4.1+b1), libcholmod5:amd64 (1:7.6.0+dfsg-1, 1:7.6.1+dfsg-1), python3-pyatspi:amd64 (2.46.0-2, 2.46.0-3), ifupdown:amd64 (0.8.41, 0.8.43), gsettings-desktop-schemas:amd64 (46~beta-3, 46~rc-1), android-libcutils:amd64 (1:34.0.4-1, 1:34.0.4-1+b1), libumfpack6:amd64 (1:7.6.0+dfsg-1, 1:7.6.1+dfsg-1), android-libziparchive:amd64 (1:34.0.4-1, 1:34.0.4-1+b1), gzip:amd64 (1.12-1, 1.12-1.1), libcolamd3:amd64 (1:7.6.0+dfsg-1, 1:7.6.1+dfsg-1), luametatex:amd64 (2.10.08+ds-1+b1, 2.11.01+really2.10.08+ds-1), endless-sky:amd64 (0.10.4-1, 0.10.4-1+b1), libgnutls30t64:amd64 (3.8.3-1.1, 3.8.3-1.1+b1), libgnutls30t64:i386 (3.8.3-1.1, 3.8.3-1.1+b1), virtualbox-qt:amd64 (7.0.14-dfsg-4, 7.0.14-dfsg-4+b3), extra-cmake-modules:amd64 (5.107.0-1, 5.107.0-2), nextcloud-desktop:amd64 (3.11.0-1, 3.11.0-1.1+b1), libbz2-1.0:amd64 (1.0.8-5+b2, 1.0.8-5.1), libbz2-1.0:i386 (1.0.8-5+b2, 1.0.8-5.1), libccolamd3:amd64 (1:7.6.0+dfsg-1, 1:7.6.1+dfsg-1), intel-microcode:amd64 (3.20231114.1, 3.20240312.1), bzip2-doc:amd64 (1.0.8-5, 1.0.8-5.1), libglib2.0-0t64:amd64 (2.78.4-4, 2.78.4-5), libglib2.0-0t64:i386 (2.78.4-4, 2.78.4-5) Remove: libcups2:amd64 (2.4.7-1+b1), libnextcloudsync0:amd64 (3.11.0-1), cups-filters:amd64 (1.28.17-3+b1), libcurl3-gnutls:amd64 (8.5.0-2), cups-bsd:amd64 (2.4.7-1+b1), libpango-1.0-0:i386 (1.52.0+ds-1), libqt5core5a:amd64 (5.15.10+dfsg-7), qtgstreamer-plugins-qt5:amd64 (1.2.0-5.2+b1), libcairo2:i386 (1.18.0-1+b1), bluez-cups:amd64 (5.71-1), cups-client:amd64 (2.4.7-1+b1), libpng-dev:amd64 (1.6.43-1), cups-daemon:amd64 (2.4.7-1+b1), r-base-dev:amd64 (4.3.2-1), libqt5network5:amd64 (5.15.10+dfsg-7), libfreetype6:i386 (2.13.2+dfsg-1+b1), libmtdev1:amd64 (1.1.6-1+b1), librsvg2-common:i386 (2.54.7+dfsg-2), qtdeclarative5-dev:amd64 (5.15.10+dfsg-2+b1), libgsoap-2.8.132:amd64 (2.8.132-2), libasound2-plugins:i386 (1.2.7.1-1+b1), libgdk-pixbuf-2.0-0:i386 (2.42.10+dfsg-3+b1), libqt5dbus5:amd64 (5.15.10+dfsg-7), libmlt7:amd64 (7.22.0-1+b1), libcairo-gobject2:i386 (1.18.0-1+b1), kdenlive:amd64 (23.08.5-1), libopencv-contrib406:amd64 (4.6.0+dfsg-13+b3), libqt5quick5:amd64 (5.15.10+dfsg-2+b1), libfontconfig1:i386 (2.15.0-1.1), libqt5widgets5:amd64 (5.15.10+dfsg-7), cups-filters-core-drivers:amd64 (1.28.17-3+b1), cups-ipp-utils:amd64 (2.4.7-1+b1), libpng16-16:amd64 (1.6.43-1), libpng16-16:i386 (1.6.43-1), libqt5gui5:amd64 (5.15.10+dfsg-7), libssl3:amd64 (3.1.5-1), libpangocairo-1.0-0:i386 (1.52.0+ds-1), libqt5x11extras5-dev:amd64 (5.15.10-2+b1), libqt5printsupport5:amd64 (5.15.10+dfsg-7), libavcodec60:i386 (7:6.1.1-1), libqt5xml5:amd64 (5.15.10+dfsg-7), libqt5opengl5:amd64 (5.15.10+dfsg-7), melt:amd64 (7.22.0-1+b1), libpangoft2-1.0-0:i386 (1.52.0+ds-1), libtheora0:i386 (1.1.1+dfsg.1-16.1+b1), qtbase5-dev:amd64
Bug#1067093: Impacket Patches for PR 1714 and 1715
A small status update: - https://github.com/fortra/impacket/pull/1714 has been merged, thus any patch related to this is now redundant. - https://github.com/fortra/impacket/pull/1715 has been redirected to https://github.com/fortra/impacket/pull/1721 which is pending approval. As a result, once #1721 is merged, I'll be updating this ticket again to ask you to update the impacket's package instead of applying patches. Kind regards.
Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded
Hi Sebastian, Carsten, On Fri, Mar 22, 2024 at 08:34:29AM +0100, Sebastian Andrzej Siewior wrote: > On 2019-03-08 22:10:10 [+0100], Carsten Schoenert wrote: > > Hello Guido, > Hi, > > > On Tue, Jan 30, 2018 at 07:19:48AM +0100, Carsten Schoenert wrote: > > > > We should not do more options. Multi threaded should be on when: > > > > > > > > - not using pristine-tar > > > > - iff pristine-tar can handle it > > > > > > > > The first one is simple but what about the second? > > > > the mentioned issue #888572 was closed some time ago so pristine-tar > > shouldn't be a problem here anymore. > > > > I will try to tweak gbp locally now again while working on a new version > > of kicad-packages3d which will be about 5GB now to archive. ;) > > I got pointed here by Amin. > As mentioned, pristine-tar can handle multi-block xz images so this is > not an issue. Further xz-utils v5.6.0+ (currently in unstable/ testing) > is using multi threaded compression by default. So this *might* be > considered fixed. Thanks a lot for the follow up. Carsten can you confirm with TB if this works as expected? Cheers, -- Guido
Bug#1067480: hostname: fails to change host name inside container; misleading message "you must be root to change the host name" while root
Package: hostname Version: 3.23+nmu1 Dear hostname maintainer, `hostname` fails to set the host name when run inside a container. After it fails it states "you must be root to change the host name" even if called by root. To reproduce: $ sudo podman image pull debian:bookworm Trying to pull docker.io/library/debian:bookworm... [...] $ sudo podman run debian:bookworm bash -c 'whoami; hostname a.b.c' root hostname: you must be root to change the host name Regards, -- Gioele Barabucci
Bug#1067479: texinfo build does not run the test suite
Package: texinfo Version: 7.1-3 Severity: normal X-Debbugs-Cc: ijaaskelai...@outlook.com Cheers, Ilari. -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.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 texinfo depends on: ii libtext-unidecode-perl 1.30-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii perl5.32.1-4+deb11u3 ii tex-common 6.16 ii texinfo-lib 7.1-3 texinfo recommends no packages. Versions of packages texinfo suggests: pn texlive-base pn texlive-fonts-recommended pn texlive-latex-base pn texlive-plain-generic -- no debconf information
Bug#1051205: git grep -F isn't ‒ '(' fails with "fatal: unmatched parenthesis"
Control: tags -1 + upstream
hehe hoho git grep '(' is actually git grep PATTERN_GROUP_START,
because git grep has pattern grouping.
Not a bug per se, but the error message is actively adversarial:
$ git grep \(
fatal: unmatched parenthesis
$ git grep \)
fatal: incomplete pattern expression: )
neither of these explain what the error actually is.
Somehow the one for ) is worse,
since this is a /complete/ pattern (which is a regular expression).
signature.asc
Description: PGP signature
Bug#1067478: texinfo build does not respect user set terminal CFLAGS or CXXFLAGS
Package: texinfo Version: 7.1-3 Severity: wishlist X-Debbugs-Cc: ijaaskelai...@outlook.com Cheers, Ilari. -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.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 texinfo depends on: ii libtext-unidecode-perl 1.30-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii perl5.32.1-4+deb11u3 ii tex-common 6.16 ii texinfo-lib 7.1-3 texinfo recommends no packages. Versions of packages texinfo suggests: pn texlive-base pn texlive-fonts-recommended pn texlive-latex-base pn texlive-plain-generic -- no debconf information
Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links
On Sat, Jan 06, 2024 at 07:31:22AM +, Dale Richards wrote: > Package: wnpp > Severity: wishlist > Owner: Dale Richards > X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dalerichards.net > > * Package name: python-sphinxcontrib-github-alt > Version : 1.2 > Upstream Contact: Jupyter Development Team > * URL : https://github.com/jupyter/sphinxcontrib_github_alt > * License : BSD 2-clause > Programming Lang: Python > Description : Sphinx extension for easy GitHub links > > Link to GitHub issues, pull requests, commits and users for a particular > project. > > I intend to maintain this package within the Debian Python Team. Hi Dale, Thanks for this ITP! Two things: (1) I recommend that this package is called python-sphinxcontrib.github-alt with a dot after "sphinxcontrib" to keep it in line with the names of all the other sphinxcontrib packages in Debian. (2) Have you had any time to work on this? I will probably need this package soon for another Jupyter package (latest version of jupyter-notebook), so I'd be happy to upload it to NEW when I get there if you don't have a chance. Best wishes, Julian
Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded
On 2019-03-08 22:10:10 [+0100], Carsten Schoenert wrote: > Hello Guido, Hi, > On Tue, Jan 30, 2018 at 07:19:48AM +0100, Carsten Schoenert wrote: > > > We should not do more options. Multi threaded should be on when: > > > > > > - not using pristine-tar > > > - iff pristine-tar can handle it > > > > > > The first one is simple but what about the second? > > the mentioned issue #888572 was closed some time ago so pristine-tar > shouldn't be a problem here anymore. > > I will try to tweak gbp locally now again while working on a new version > of kicad-packages3d which will be about 5GB now to archive. ;) I got pointed here by Amin. As mentioned, pristine-tar can handle multi-block xz images so this is not an issue. Further xz-utils v5.6.0+ (currently in unstable/ testing) is using multi threaded compression by default. So this *might* be considered fixed. > Regards > Carsten Sebastian
Bug#1067410: golang-github-go-jose-go-jose-dev: ftbfs on i386 and mips64el due to timeout of test case
Hi, On Thu, Mar 21, 2024 at 11:14:40PM +0530, Nilesh Patra wrote: The 4.0.1-2 still has timeout on test issue, see: https://buildd.debian.org/status/logs.php?pkg=golang-github-go-jose-go-jose=i386 https://buildd.debian.org/status/logs.php?pkg=golang-github-go-jose-go-jose=mips64el So open this to trace it again. ... golang-github-go-jose-go-jose (4.0.1-3) unstable; urgency=medium . * Skip one test on some architectures accurately. (Closes: #1067410) You could instead increase the timeout too with: override_dh_auto_test: dh_auto_test -- -timeout=1h Unless the tests run on those archs forever. Thanks. it works. I plan to upload it again, so reopen the bug again. At first I also thought about how to globally increase the timeout during build(but fail to find this). Another worried is that it will has timeout issue on debci. but it seems the timeout does not affect debci. Thanks again. BR, Bo Best, Nilesh -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1067477: nmu: mesa_23.3.5-1
Package: release.debian.org Severity: normal X-Debbugs-Cc: m...@packages.debian.org Control: affects -1 + src:mesa User: release.debian@packages.debian.org Usertags: binnmu nmu mesa_23.3.5-1 . armel armhf . unstable . -m "Rebuild after a nolibva binary upload"
Bug#1067476: nmu: systemd_255.4-1+b1
Package: release.debian.org Severity: normal X-Debbugs-Cc: syst...@packages.debian.org Control: affects -1 + src:systemd User: release.debian@packages.debian.org Usertags: binnmu nmu systemd_255.4-1+b1 . armel armhf . unstable . -m "Rebuild on buildds"
Bug#1066899: wiki.debian.org: Missing definition (link) about "git-dpm project"
Thanks for reaching out. On 2024-03-19 10:41 Boyuan Yang wrote: > I don't think there is such a definition. That is the problem. > According to my > understanding, the "git-dpm project" solely means ... > [..] > Please feel free to rephrase it, edit the Wiki page as > needed No I don't "feel free" because I am not the expert. Please do it on your site or find an expert how has the expertise to explain that term. In the current state that wiki page harm the project more then it helps. Kind Christian
Bug#1067475: nmu: util-linux_2.39.3-10
Package: release.debian.org Severity: normal X-Debbugs-Cc: util-li...@packages.debian.org Control: affects -1 + src:util-linux User: release.debian@packages.debian.org Usertags: binnmu nmu util-linux_2.39.3-10 . armel armhf . unstable . -m "Rebuild on buildds"
Bug#1067407: graphviz: diff for NMU version 2.42.2-8.1
control: fixed -1 2.42.2-9 control: close -1 On Thu, 21 Mar 2024 17:21:13 +0100 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: Control: tags -1 +moreinfo On Thu, Mar 21, 2024 at 12:39 PM Gianfranco Costamagna wrote: > I've prepared an NMU for graphviz (versioned as 2.42.2-8.1) and > uploaded it to DELAYED/2. Please feel free to cancel it directly if you want to do a maintainer upload. I do not see the point of this. Can you please recheck the current graphviz package state and report back to me? If you see my NMU was called 2.42.2-8.1, reason is that I missed -9 upload due to slow mirrors probably Sorry for the noise, indeed the -8 upload should be fine! (I'll cancel it, but it will be automatically discarded by ftp anyway) thanks Gianfranco Regards, Laszlo/GCS OpenPGP_signature.asc Description: OpenPGP digital signature
