Bug#1071739: marked as done (packages.debian.org: Removal of spam domain from download mirror page)
>>>>> On Fri, 24 May 2024 20:02:35 +0200, Holger Wansing >>>>> said: > Hi Thomas, > you fixed this in master branch. > Are you sure about this? > I somehow seem to remember, that debian-master branch is used for packages.d.o ... you are right, debian-master seems to be the correct branch. I will fix it also in debian-master. Do you know if the branch master is used for anything? -- Thomas
Bug#1071581: dialog: stop using libtool-bin
On Wed, May 22, 2024 at 10:34:12AM +0200, Helmut Grohne wrote: > Hi Thomas, > > On Wed, May 22, 2024 at 03:53:43AM -0400, Thomas Dickey wrote: > > I don't use autoheader (though it's present in the fork I've maintained for > > about the past quarter-century). The configure script generates the > > complete > > dlg_config.h without that crutch. Attempting to bypass that will certainly > > lead to unnecessary bug reports. > > I fear it occurred to me late that I should be using autoconf-dickey > instead of the standard autoconf for dialog. Hence my patch makes it > work the "wrong" autoconf and thus runs autoheader. I see how that would > not be necessary with autoconf-dickey. > > > Actually it would be AC_FOREACH, which invokes AH_TEMPLATE > > > > fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999), > > and there are other macros which might use those features. > > Yeah. And if you make dialog work with autoconf-dickey and without > autoheader, then all of this becomes moot anyway. > > Feel free to come up with a different solution as long as we stop > relying on /usr/bin/libtool as that's the component that will go away. > We now have one working solution and I'm happy if that is sufficient to > get the ball rolling for a better solution than mine. thanks (on my to-do list) -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1068250: dracut: Consider switching to the fork dracut-ng
Yes, I already got this information. I think I will also prepare dracut-ng to Debian. It then has to go through the NEW queue. And currently I don't know, when I will start this. >>>>> On Wed, 22 May 2024 20:54:38 +0200, Evgeni Golov said: > FWIW, Fedora switched to this fork starting with Fedora 40 [1]. > [1] https://src.fedoraproject.org/rpms/dracut/ -- viele Grüße Thomas
Bug#1071581: dialog: stop using libtool-bin
On Wed, May 22, 2024 at 08:12:04AM +0200, Helmut Grohne wrote: > Hi Thomas, > > On Tue, May 21, 2024 at 03:06:00PM -0400, Thomas Dickey wrote: > > hmm - there are two sets of changes - I don't see a reason for the > > change to the curses function checks. > > Thank you for reviewing my patch. The curses function check change does > have a reason. It can be solved differently in principle. > > When I ran autoheader, config.hin would lack all the defines that should I don't use autoheader (though it's present in the fork I've maintained for about the past quarter-century). The configure script generates the complete dlg_config.h without that crutch. Attempting to bypass that will certainly lead to unnecessary bug reports. > have come from CF_CURSES_FUNCS while the relevant HAVE_* defines would > still show up in config.log after running configure and therefore the > resulting dlg_config.h would also lack them. That meant that dialog > would perceive a very dysfunctional curses and its shim would fail to > compile. Quite clearly, we shouldn't assume a crippled curses and > config.hin should contain the relevant templates. As it turns out, > autoheader interprets the m4 files and collects the AC_DEFINE and > AC_DEFINE_UNQUOTED invocations, well some of them actually. The > AC_CHECK_FUNCS would be collected whereas CF_CURSES_FUNCS not, even > though both seemed quite similar. The subtle difference is that > AC_CHECK_FUNCS uses AS_FOR (a loop that is evaluated using m4) whereas Actually it would be AC_FOREACH, which invokes AH_TEMPLATE fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999), and there are other macros which might use those features. (I added a to-do to follow up on this) > CF_CURSES_FUNCS uses a shell for loop. Thus, autoheader would only see a > single, bogus AC_DEFINE_UNQUOTED for all of CF_CURSES_FUNCS and ignore > that. Avoiding this shell loop is key here and I went for manually > unrolling it, because AS_FOR didn't work out initially and unrolling > seemed workable to me. The crucial bit here is that you cannot use shell > for control flow here. If you prefer AS_FOR or some other working > mechanism, that's fine. Just do something about it to avoid dialog > failing to build when we remove libtool-bin from Debian. > > Helmut > -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1071581: dialog: stop using libtool-bin
On Tue, May 21, 2024 at 04:00:56PM +0200, Helmut Grohne wrote: > Source: dialog > Version: 1.3-20240307-2 > Severity: normal > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: cross-satisfiability > > Hi Santiago, > > we want to remove the package libtool-bin from the archive, because any > attempt of using it breaks cross compilation. The dialog package is a > bit strange in this regard. It's autoconf stuff attempts to detect > whether there is a libtool.m4 and when there isn't attempts to use a > pre-configured libtool (the one from libtool-bin). Unfortunately, last > time it was autoreconf'ed, that happened without libtool.m4. So > basically, making libtool-bin go away here amounts to autoreconfing > dialog after libtoolizing it. And that's pretty much what I did in the > attached patch. The dialog binary and libdialog.la are bit-identical > with this change. hmm - there are two sets of changes - I don't see a reason for the change to the curses function checks. (as for libtool - I recall commenting on that, recently) -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1071565: autopkgtest: ERROR: cloud-efi.raw is too small: 131 MB. Should be greater 890 MB
The problem was, that a package could not be downloaded: 833s fai.log:W: Couldn't download package libip4tc2 (ver 1.8.9-2 arch amd64) at http://deb.debian.org/debian/pool/main/i/iptables/libip4tc2_1.8.9-2_amd64.deb Another test run passed without any errors. See 46897030 https://ci.debian.net/packages/f/fai/testing/amd64/ Does this solve your problem? Can we close this bug now? -- Thomas
Bug#1069048: live-boot fails to DHCP on all NICs with link up
ping? If nobody really cares about this bug, would it be ok to NMU the fix to Unstable, so that I can later backport it to Bookworm? Cheers, Thomas Goirand (zigo)
Bug#924139: transistion finished
Hi, I've remove the old python2 scripts in english/mirror/timestamps/ The only remaining python2 script is now urlcheck.py in the cron repository, which should not be used any more. Read TODO i nthis directory. Therefore I see no blockers for upgrading www-master to bookworm. Any thoughts? -- regards Thomas
Bug#1071278: systemd 256 breaks dracut
Hi Luca, it breaks the current version in unstable and earlier. So please add Breaks: dracut (<= 060+5-7) -- regards Thomas
Bug#1071182: dracut: requires changes for systemd 256; boot fails otherwise
The related systemd bug is #1071278 -- regards Thomas
Bug#1071182: dracut: requires changes for systemd 256; boot fails otherwise
I also filed a bug against systemd because this problem can be solved by both packages and there are plans to replace dracut by dracut-ng. But that will need more time. regards Thomas
Bug#1071278: systemd 256 breaks dracut
Package: systemd Version: 256~rc2-3 Severity: serious systemd changed it's behaviour and now makes /usr read-only in the initrd. This breaks dracut and vice versa. This bug is releated to #1071182 which says dracut breaks systemd. Please add a Breaks: dracut(<<..) Currently I do not know when I will update dracut, because there are also plans to replace dracut by dracut-ng, which may involve more time. I not sure in which package I will invest my available time. In order to not break the systems of our users, IMO the smalles change would be to add the Breaks: line to systemd. -- Thomas
Bug#1040186: NMU for fixing this bug in Bookworm
Hi, Since there's been very low activity in this bug, and that I cannot see if the current maintainer is willing to fix the bug, I have opened a bug against the Stable release team to fix this issue in Bookworm: https://bugs.debian.org/1071264 You'll find the package debdiff over there. Please let me know if you prefer to fix this yourself, or if it's ok for me to upload the fixed package in Bookworm. Cheers, Thomas Goirand (zigo)
Bug#1071264: autopkgtest fails with networkx 3.2.1
Source: seirsplus Version: 1.0.9-1 Severity: serious Hi, Your package fails autopkgtest with the current version of networkx in Unstable. Please fix it. Cheers, Thomas Goirand (zigo)
Bug#1071216: asahi-btsync: calling of asahi-btsync panics
Package: asahi-btsync Version: 0.2.0-1+b1 Severity: normal Dear Maintainer, calling of asahi-btsync panics. - call asahi-btsync expect: this should show the help page (because it needs parameters) actual: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: VariableNotFound', src/main.rs:52:17 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.8.9-asahi-5-cy8aer0 (SMP w/10 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages asahi-btsync depends on: ii libc6 2.38-10 ii libgcc-s1 14-20240330-1 asahi-btsync recommends no packages. asahi-btsync suggests no packages. -- no debconf information
Bug#1071029: RM: python-randomize -- ROM; nose removal, unused anymore
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-random...@packages.debian.org Control: affects -1 + src:python-randomize Hi, As we're trying to remove nose from Debian, it's time to remove this nose plugin. There's no reverse dependency in unstable anymore. Indeed, I fixed python-influxdb-client, and only the version in testing still has the python3-randomize build-depends. Please remove python-randomize from Debian. Cheers, Thomas Goirand (zigo)
Bug#1067873: close
tag 1067873 = wontfix summary 1067873 0 This is a PEBKAC: iptables was empty but not nftables.
Bug#1070819: Please package latest version of python-googleapi
Source: python-googleapi Version: 1.7.12-1 Severity: important Hi, The current version of python-googleapi still includes old deprecated modules like mock (instead of unittest.mock), or oauth2client. I intend to attempt removing the oauth2client from Debian, as it FTBFS and is deprecated upstream. Please package the latest python-googleapi as it looks up-to-date regarding those things, and then you can probably remove build-depends on mock, six, oauth2client and so on. Also, it'd be nice to get this library in the DPT, as it is used by many. Cheers, Thomas Goirand (zigo)
Bug#1069097: openstack-dashboard: postinst error makes designate-dashboard to FTBFS randomly
Hi Santiago, I wasn't able to reproduce this bug. Can you help? Cheers, Thomas Goirand (zigo)
Bug#1070741: Fixed
Hi Scott, Sorry, I fixed python-openstackclient and removed its build-depends on python3-karborclient today (and removed the moreinfo tag on this bug). FYI, it was there so openstackclient could generate its autocompletion and doc correctly with karborclient support. Cheers, Thomas Goirand (zigo)
Bug#1070775: gnome-shell: Update gnome-shell from testing to unstable looses umlauts
Package: gnome-shell Version: 44.9-1+b1 Severity: normal Dear Maintainer, updating from testing version of gnome-shell to unstable version (44.9-2) looses the umlauts of a german keyboard. - you are in testing with gnome-shell - 44.9-1 - and install unstable version. - Reboot - Log into gnome session (though umlauts do not work in gdm too!) - type uiopüöälß with the german keyboard e.g. in a shell expected: uiopüöälß is shown actual: uiopl is shown. All umlaut keys are ignored Downgrading to the actual testing packages let the umlauts work again. From apt/history: Start-Date: 2024-05-08 20:53:41 Commandline: apt install -t unstable gnome-shell Requested-By: baer (1000) Install: libgirepository-2.0-0:arm64 (2.80.0-10, automatic) Upgrade: libglib2.0-dev-bin:arm64 (2.78.4-7, 2.80.0-10), libglib2.0-bin:arm64 (2.78.4-7, 2.80.0-10), libglib2.0-dev:arm64 (2.78.4-7, 2.80.0-10), gir1.2-glib-2.0:arm64 (1.78.1-15, 2.80.0-10), libglib2.0-data:arm64 (2.78.4-7, 2.80.0-10), gnome-shell:arm64 (44.9-1+b1, 44.9-2), gir1.2-glib-2.0-dev:arm64 (1.78.1-15, 2.80.0-10), gnome-shell-common:arm64 (44.9-1, 44.9-2), gnome-shell-extension-prefs:arm64 (44.9-1+b1, 44.9-2), libglib2.0-0t64:arm64 (2.78.4-7, 2.80.0-10) End-Date: 2024-05-08 20:53:47 -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.8.9-asahi-2-cy8aer0 (SMP w/10 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b2 ii gir1.2-accountsservice-1.0 23.13.9-6.1 ii gir1.2-adw-1 1.5.0-1 ii gir1.2-atk-1.0 2.52.0-1 ii gir1.2-atspi-2.0 2.52.0-1 ii gir1.2-freedesktop 1.78.1-15 ii gir1.2-gcr-4 4.2.0-5 ii gir1.2-gdesktopenums-3.0 46.0-1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-3+b3 ii gir1.2-gdm-1.0 46.0-2+b3 ii gir1.2-geoclue-2.0 2.7.1-2+b1 ii gir1.2-glib-2.0 1.78.1-15 ii gir1.2-gnomebg-4.0 3 44.0-5 ii gir1.2-gnomebluetooth-3.046.0-1 ii gir1.2-gnomedesktop-4.0 44.0-5 ii gir1.2-graphene-1.0 1.10.8-3+b1 ii gir1.2-gstreamer-1.0 1.24.3-1 ii gir1.2-gtk-4.0 4.12.5+ds-3 ii gir1.2-gweather-4.0 4.4.2-1 ii gir1.2-ibus-1.0 1.5.29-2 ii gir1.2-mutter-12 44.8-3.1+b3 ii gir1.2-nm-1.01.46.0-2 ii gir1.2-nma4-1.0 1.10.6-3 ii gir1.2-pango-1.0 1.52.2+ds-1 ii gir1.2-polkit-1.0124-2 ii gir1.2-rsvg-2.0 2.58.0+dfsg-1 ii gir1.2-soup-3.0 3.4.4-5+b1 ii gir1.2-upowerglib-1.01.90.3-1 ii gir1.2-webkit2-4.1 2.44.1-1+b1 ii gnome-backgrounds45.0-1 ii gnome-settings-daemon46.0-1+b3 ii gnome-shell-common 44.9-1 ii gsettings-desktop-schemas46.0-1 ii gstreamer1.0-pipewire1.0.5-1+b3 ii libatk-bridge2.0-0t642.52.0-1 ii libatk1.0-0t64 2.52.0-1 ii libc62.38-7 ii libcairo21.18.0-3+b1 ii libecal-2.0-2t64 3.50.3-2.2+b3 ii libedataserver-1.2-27t64 3.50.3-2.2+b3 ii libgcr-4-4 4.2.0-5 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b3 ii libgirepository-1.0-11.78.1-15 ii libgjs0g 1.80.2-1 ii libgles2 1.7.0-1+b1 ii libglib2.0-0t64 2.78.4-7 ii libglib2.0-bin 2.78.4-7 ii libgnome-autoar-0-0 0.4.4-2+b2 ii libgnome-desktop-4-2t64 44.0-5 ii libgraphene-1.0-01.10.8-3+b1 ii libgtk-3-0t643.24.41-4 ii libgtk-4-1 4.12.5+ds-3 ii libical3t64 3.0.17-1.1+b1 ii libjson-glib-1.0-0 1.8.0-2+b1 ii libmutter-12-0t6444.8-3.1+b3 ii libnm0
Bug#1065652: Needed by python-memcache
Hi, This package is needed by latest version of python-memcache. So I'm therefore doing an ITP instead of the original RFS for this package. Cheers, Thomas Goirand (zigo)
Bug#1070741: RM: python-karborclient -- ROM; unmaintained upstream, leaf package
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-karborcli...@packages.debian.org Control: affects -1 + src:python-karborclient Hi, Please remove python-karborclient from Debian. The upstream project has been dead for a long time already. Cheers, Thomas Goirand (zigo)
Bug#1070739: bookworm-pu: package python-glance-store/4.1.0-4
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: python-glance-st...@packages.debian.org Control: affects -1 + src:python-glance-store [ Reason ] I would like to update python-glance-store/4.1.0-4 to python-glance-store/4.1.1-1+deb12u1 to address CVE-2024-1141 (aka: #1063795). [ Impact ] S3 credentials may otherwise continue to be logged in glance's log if loglevel is set to DEBUG. [ Tests ] The package contains and run unit tests at build time, plus autopkgtest. Upstream runs extensive functional tests, and so do I, doing a full OpenStack deployment with this package. No regression has been found. [ Risks ] Minimum. Only the S3 backend is impacted. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] The point release announcement was published last year: https://lists.openstack.org/archives/list/release-annou...@lists.openstack.org/thread/PY26MG7DBD4UVJDEXWMSIM4TGS52F4VX/ It can be broken down this way: e9d2509 Add force to os-brick disconnect 3d3467d Fix tox4 error 8034cdc Update TOX_CONSTRAINTS_FILE for stable/zed c05c7e5 Update .gitreview for stable/zed Let me explain the commits. e9d2509 contains the fix for CVE-2023-2088 that was already in Bookworm, and that I'm therefore droping. The other 3 commits are to address internal OpenStack CI and Git infra, and are not code change. They can therefore be ignore. So really, this update only contains the fix for CVE-2024-1141 and nothing else, even though the upstream version bumps. Last thing: I rewrote the patch header this way (not shown in the attached debdiff, as I fired-up reporbug -b before realizing the patch header needed some edits): Author: lujie Date: Fri, 19 Jan 2024 13:12:20 +0800 Description: CVE-2024-1141: Do not show access_key in s3 driver Avoid possible leakage of s3 access keys by not including them in log messages. . This patch includes commit d6e531af4821c8466b1e9404f12f89f6216417f2 (change I8dc564bed33d6fc71965f4f573ae9109b410b1d4), which addressed some more log messages that the original patch had missed. . The two commits are squashed here for ease in backporting (and also to make sure that *both* are always backported). Change-Id: I9193df38d613259b61bb369fa1040fb2c51a21d7 Origin: upstream, https://review.opendev.org/c/openstack/glance_store/+/907736 Bug: https://launchpad.net/bugs/2047688 Bug-Debian: https://bugs.debian.org/1063795 Last-Update: 2024-05-08 Please allow me to upload python-glance-store to Bookworm for the next point release. Cheers, Thomas Goirand (zigo) diff -Nru python-glance-store-4.1.0/debian/changelog python-glance-store-4.1.1/debian/changelog --- python-glance-store-4.1.0/debian/changelog 2023-05-12 08:52:34.0 +0200 +++ python-glance-store-4.1.1/debian/changelog 2023-09-01 15:10:49.0 +0200 @@ -1,3 +1,13 @@ +python-glance-store (4.1.1-1+deb12u1) bookworm; urgency=medium + + * New upstream release. + * Drop CVE-2023-2088_Add_force_to_os-brick_disconnect.patch applied +upstream. + * CVE-2024-1141: Glance Store access key logged in DEBUG log level. Add +upstream patch: Do not show access_key in s3 driver (Closes: #1063795). + + -- Thomas Goirand Fri, 01 Sep 2023 15:10:49 +0200 + python-glance-store (4.1.0-4) unstable; urgency=medium * CVE-2023-2088: Unauthorized volume access through deleted volume diff -Nru python-glance-store-4.1.0/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch python-glance-store-4.1.1/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch --- python-glance-store-4.1.0/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch 2023-05-12 08:52:34.0 +0200 +++ python-glance-store-4.1.1/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch 1970-01-01 01:00:00.0 +0100 @@ -1,94 +0,0 @@ -Author: Brian Rosmaita -Date: Tue, 18 Apr 2023 11:22:27 -0400 -Description: CVE-2023-2088: Add force to os-brick disconnect - In order to be sure that devices are being removed from the host, - we should be using the 'force' parameter with os-brick's - disconnect_volume() method. -Bug: https://launchpad.net/bugs/2004555 -Change-Id: I63d09ad9ef465bc154c85a9ea125449c039d1b90 -Bug-Debian: https://bugs.debian.org/1035978 -Origin: upstream, https://review.opendev.org/c/openstack/glance_store/+/882853 -Last-Update: 2023-05-12 - -diff --git a/glance_store/_drivers/cinder.py b/glance_store/_drivers/cinder.py -index 3509348..7405b7a 100644 a/glance_store/_drivers/cinder.py -+++ b/glance_store/_drivers/cinder.py -@@ -831,7 +831,10 @@ - client, attachment.id, volume_id, host, conn, - connection_info, device) - else
Bug#1070682: Please update to inih 58
Source: libinih Version: 57-1 Severity: normal Hi, Please upgrade this package to version 58. It contains the function ini_parse that I need for upgrading to the latest version of lenovolegionlinux. Cheers, Thomas Goirand (zigo)
Bug#1064401: python-requests-kerberos: please package version 0.14
Hi, FYI, version 0.14 needs python-pyspnego that I'm going to package. Cheers, Thomas Goirand (zigo)
Bug#1070477: RM: freezer-api -- ROM; unmaintained upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: freezer-...@packages.debian.org Control: affects -1 + src:freezer-api Hi, freezer was already removed from Debian, let's also remove freezer-api. Cheers, Thomas Goirand (zigo)
Bug#1070292: Dep removed from python-influxdb-client
I've uploaded the fix to python-influxdb-client. Thomas
Bug#1070407: mailman3-web: dpkg --configure mailman3-web fails
Package: mailman3-web Version: 0+20240312-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I am dist-updating my Debian system. I get a failure for the installation of Mailman3-web root@tagol~# dpkg --configure mailman3-web Setting up mailman3-web (0+20240312-1) ... dpkg: error processing package mailman3-web (--configure): installed mailman3-web package post-installation script subprocess returned error exit status 20 Errors were encountered while processing: mailman3-web I tried replacing the set -e with set -x in /var/lib/dpkg/info# e mailman3-web.postinst Then I get root@tagol/var/lib/dpkg/info# dpkg --configure mailman3-web Setting up mailman3-web (0+20240312-1) ... + . /usr/share/debconf/confmodule + [ ! ] + PERL_DL_NONLAZY=1 + export PERL_DL_NONLAZY + [ ] + exec /usr/share/debconf/frontend /var/lib/dpkg/info/mailman3-web.postinst configure 0+20200530-2.1 dpkg: error processing package mailman3-web (--configure): installed mailman3-web package post-installation script subprocess returned error exit status 20 Errors were encountered while processing: mailman3-web Running root@tagol/var/lib/dpkg/info# /usr/share/debconf/frontend /var/lib/dpkg/info/mailman3-web.postinst configure 0+20200530-2.1 yields nothing root@tagol/var/lib/dpkg/info# dpkg --configure mailman3-web |& tee log.dpkg.config.mailman3web.5 Setting up mailman3-web (0+20240312-1) ... + . /usr/share/debconf/confmodule + [ ! ] + PERL_DL_NONLAZY=1 + export PERL_DL_NONLAZY + [ ] + exec /usr/share/debconf/frontend /var/lib/dpkg/info/mailman3-web.postinst configure 0+20200530-2.1 dpkg: error processing package mailman3-web (--configure): installed mailman3-web package post-installation script subprocess returned error exit status 20 Errors were encountered while processing: mailman3-web Same thing. root@tagol~# systemctl restart mailman3-web.service root@tagol~# The web interface page loads https://folks.email/mailman3/postorius/lists/bibnez.folks.email/ but when I go to sign-in I get Internal Server Error: /mailman3/accounts/login/ OfflineGenerationError at /accounts/login/ You have offline compression enabled but key +"5dc9242d199e3c2224564016de526a9d8e46b5d332709d1fde99964e8821452c" is missing from offline +manifest. You may need to run "python manage.py compress". Here is the original content: I go ahead and run root@tagol/usr/share/mailman3-web# ./manage.py compress Compressing... Error parsing template socialaccount/signup.html: socialaccount/base.html done Compressed 2 block(s) from 78 template(s) for 1 context(s). It turns out this issue was discussed on the mailing list https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/MGY6JA6O7BWGR2KNKD3PQTMW7ZY7NHS3/ I tried to downgrade root@tagol~# dpkg -i mailman3-web_0+20200530-2.1_all.deb dpkg: warning: downgrading mailman3-web from 0+20240312-1 to 0+20200530-2.1 (Reading database ... 121410 files and directories currently installed.) Preparing to unpack mailman3-web_0+20200530-2.1_all.deb ... Unpacking mailman3-web (0+20200530-2.1) over (0+20240312-1) ... Setting up mailman3-web (0+20200530-2.1) ... Installing new version of config file /etc/cron.d/mailman3-web ... dpkg: error processing package mailman3-web (--install): installed mailman3-web package post-installation script subprocess returned error exit status 20 Errors were encountered while processing: mailman3-web So I upgrade again root@tagol/usr/share/mailman3-web# apt upgrade The following packages were automatically installed and are no longer required: libabsl20220623 libaio1 linux-image-6.6.15-amd64 python3-editables python3-pyrsistent Use 'apt autoremove' to remove them. Upgrading: mailman3-web Summary: Upgrading: 1, Installing: 0, Removing: 0, Not Upgrading: 0 1 not fully installed or removed. Download size: 25.9 kB Space needed: 2,048 B / 11.2 TB available Continue? [Y/n] y Get:1 http://mirror.hetzner.com/debian/packages testing/main amd64 mailman3-web all 0+20240312-1 [25.9 kB] Fetched 25.9 kB in 0s (141 kB/s) Preconfiguring packages ... mailman3-web failed to preconfigure, with exit status 20 (Reading database ... 121410 files and directories currently installed.) Preparing to unpack .../mailman3-web_0+20240312-1_all.deb ... Unpacking mailman3-web (0+20240312-1) over (0+20200530-2.1) ... Setting up mailman3-web (0+20240312-1) ... Installing new version of config file /etc/cron.d/mailman3-web ... dpkg: error processing package mailman3-web (--configure): installed mailman3-web package post-installation script subprocess returned error exit status 20 Errors were encountered while processing:
Bug#1070385: obs-studio: Plugin fails to load libobs.so because it doesn't exist
Package: obs-studio Version: 30.1.2+dfsg-1 Severity: normal Dear Maintainer, I installed the following obs plugin in my home directory: https://github.com/LiveSplit/obs-livesplit-one Upon starting obs, the plugin did not load and the logs told me libobs.so was not found Typing $ dpkg -L libobs0t64 | grep libobs\\.so allowed me to find the two following files: /usr/lib/x86_64-linux-gnu/libobs.so.30 /usr/lib/x86_64-linux-gnu/libobs.so.0 (symlink to the previous) Adding a symlink libobs.so in that directory fixed the issue, but I am worried as I edited a directory I'm not sure I should according to Debian guidelines (I'm not the most system-savy person) Since others might have the same issue, I'm letting you know and hope my fix is the right one Thank you, Thomas Blanc -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages obs-studio depends on: ii libavcodec60 7:6.1.1-4 ii libavdevice60 7:6.1.1-4 ii libavformat60 7:6.1.1-4 ii libavutil587:6.1.1-4 ii libc6 2.38-7 ii libcurl3t64-gnutls 8.7.1-5 ii libegl11.7.0-1+b1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.2+dfsg-1+b4 ii libgcc-s1 14-20240429-1 ii libglx01.7.0-1+b1 ii libjansson42.14-2+b2 ii libluajit-5.1-22.1.0+openresty20231117-2 ii libmbedcrypto7t64 2.28.8-1 ii libmbedtls14t642.28.8-1 ii libmbedx509-1t64 2.28.8-1 ii libobs0t64 30.1.2+dfsg-1 ii libopengl0 1.7.0-1+b1 ii libpci31:3.12.0-1 ii libpulse0 16.1+dfsg1-5 ii libpython3.11t64 3.11.9-1 ii libqrcodegencpp1 1.8.0-1.2+b1 ii libqt6core6t64 6.4.2+dfsg-21.1+b1 ii libqt6gui6t64 6.4.2+dfsg-21.1+b1 ii libqt6network6t64 6.4.2+dfsg-21.1+b1 ii libqt6svg6 6.4.2-4+b2 ii libqt6widgets6t64 6.4.2+dfsg-21.1+b1 ii libqt6xml6t64 6.4.2+dfsg-21.1+b1 ii librist4 0.2.10+dfsg-2 ii libspeexdsp1 1.2.1-1+b1 ii libsrt1.5-openssl 1.5.3-1+b2 ii libstdc++6 14-20240429-1 ii libswscale77:6.1.1-4 ii libudev1 255.5-1 ii libv4l-0t641.26.1-4+b1 ii libva-drm2 2.20.0-2+b1 ii libva2 2.20.0-2+b1 ii libx11-6 2:1.8.7-1+b1 ii libx264-1642:0.164.3108+git31e19f9-1 ii libxcb-composite0 1.17.0-1 ii libxcb-randr0 1.17.0-1 ii libxcb-shm01.17.0-1 ii libxcb-xfixes0 1.17.0-1 ii libxcb-xinerama0 1.17.0-1 ii libxcb11.17.0-1 ii libxkbcommon0 1.6.0-1+b1 ii python33.11.8-1 ii python3.11 3.11.9-1 ii qt6-image-formats-plugins 6.4.2-5+b1 ii qt6-wayland6.4.2-5+b2 Versions of packages obs-studio recommends: ii obs-plugins 30.1.2+dfsg-1 Versions of packages obs-studio suggests: ii pkexec 124-2 ii policykit-1124-2 pn v4l2loopback-dkms -- no debconf information
Bug#1070223: RM: python-ara -- ROM; unmaintained package
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-...@packages.debian.org Control: affects -1 + src:python-ara Hi, I went to see with Michal Arbet, the current maintainer of the package, how he could fix the current open bugs, and he has no time for it. He agreed for this package to be removed, rather then having it bitrot in Unstable. Please remove python-ara from Debian. Cheers, Thomas Goirand (zigo)
Bug#1070222: RM: sahara -- ROM; unmaintained upstream, RC buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sah...@packages.debian.org Control: affects -1 + src:sahara Hi, Sahara FTBFS (unit tests failures), and is unmaintained upstream. It's time to get it removed from Debian. Cheers, Thomas Goirand (zigo)
Bug#1070174: ruby-actionpack-xml-parser: Typo in package description
Source: ruby-actionpack-xml-parser Version: 2.0.1-4 Severity: minor Dear Maintainer, We noticed a typo in ruby-actionpack-xml-parser's long description when translating it on the DDTP. The description mentions "the Action Packg", while we believe it should be "the Action Pack". Thanks for maintaining ruby-actionpack-xml-parser! Thomas, for the DDTP team. -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) 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
Bug#1070061: RM: python-ospurge -- ROM; unmaintained upstream, RC buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, This package needs to be removed from Debian. Cheers, Thomas Goirand (zigo)
Bug#1070060: RM: networking-mlnx -- ROM; unmaintained upstream, FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, networking-mlnx is unmaintained upstream, probably because there's better options these days (like networking-generic-switch). Please remove networking-mlnx from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, Narcis Garcia wrote: > Could you review this patch for pre-wget phase, so it considers that a > NIC succeeds whet it acquires default gateway address? Checking if a NIC has a default gateway interface is not the right way to check if that nick should be in use. There are some configurations where it's ok that there would be *NO* default gateway. This is a perfectly valid DHCP setup. The only way to check if it worked, is simply what's done right now: check if dhclient gets an IP address. This part isn't even in the patch itself, the only thing that this patch does, is listing the cards with the link up, to pass it to the next step (ie: dhcp), which this patch doesn't touch (it's written properly already, and works with multiple network interface in the DEVICES= variable in /conf/param.conf). So there's IMO nothing more to do in this patch. Cheers, Thomas Goirand (zigo)
Bug#1070045: RM: heat-cfntools -- ROM; unmaintained upstream, RC buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: heat-cfnto...@packages.debian.org Control: affects -1 + src:heat-cfntools Hi, heat-cfntools depends on boto (ie: not boto3, so the version of the lib which is unmaintained), and has lost support from upstream. So it's time to get it removed from Debian. Cheers, Thomas Goirand (zigo)
Bug#1066842: Updating extrepo-offline-data in Debian Stable (debdiff)
Hi Jonathan, I have removed the +1 from version number as you mentioned, and uploaded to bookworm. Please accept the package. Jonathan wrote: > Is this actually a backport of current unstable though? In which case > it should include the changelog from 1.0.4 and be 1.0.4~deb12u1. It is *not* a backport of the entire 1.0.4 package as per in Unstable, as it would have include changes in non-data parts of the package. As I wrote earlier, I've simply copied the "repos" data-only folder from 1.0.4, and made a new 1.0.3+deb12u1 with it, to avoid unwanted / dangerous / untested changes. Thanks for accepting this update, Cheers, Thomas Goirand (zigo)
Bug#1069967: fai-client: install_packages E: Unable to locate package ...
Hi Markus, we had function this in the past. The subroutine mkpackagelist() in install_packages did this. It was removed, because it could not deal with variables in package names. So I need to reimplement it. -- viele Grüße Thomas
Bug#1069898: mariadb-server: Command History is shared for all users
Package: mariadb-server Version: 1:10.11.6-0+deb12u1 Severity: important X-Debbugs-Cc: thomas.schle...@posteo.de Dear Maintainer, on a link via socket between Client and Server there is only one history of Commands. Especially the root history is seen by normal user. Thomas Schlegel
Bug#727656: Status of libpaper fork
On Wed, 24 Apr 2024 at 22:03, Bastian Germann wrote: > > I have seen Simon's post about this. The new gnulib package has a new > README that describes how to use the Debian > package. There is a slight chance that FTP Masters might intervene in > having a git bundle in a package because their > reasoing to forbid the 3.0 (git) source format in the archive is that it > is far easier to confirm that a file set is > legally distributable when it is a plain tar archive. We will see. One might hope that gnulib would be accepted because as a project it is particularly careful about licensing. In particular, gnulib-tool lets you vet the licenses of the modules you install in your package. > > For libpaper, we can think of using the new gnulib package when it has > passed NEW. It is sitting in there waiting for an > ack. OK, thanks for staying up-to-date on this! -- https://rrt.sc3d.org
Bug#727656: Status of libpaper fork
On Tue, 19 Mar 2024 at 21:46, Reuben Thomas wrote: > On Tue, 19 Mar 2024 at 21:37, Bastian Germann wrote: > >> >> As nobody has provided any patch yet and I do not have an idea how to use >> gnulib properly generally and in Debian >> context, I came up with this. I have actually tried to use Debian's >> gnulib but could not get the thing to work. >> > I've just had some information that may help. Simon Josefsson writes in a thread on the gnulib mailing list: The latest gnulib in Debian contains a git bundle of gnulib, so you can Build-Depends on gnulib and via GNULIB_REVISION pick out exactly the gnulib git revision that libpaper needs. This avoids including gnulib files in the tarball that is uploaded to Debian, and there is no risk that you will get gnulib code from a different git commit. It requires an added 'Build-Depends: git' in libpaper, though, which is unfortunate but I don't see how to avoid it. I should write a post to debian-devel describing this pattern on how to use gnulib in Debian packages, but you can infer everything from the links given in my blog post [1] and the latest upload of libntlm into Debian. [1] https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/ [2] https://salsa.debian.org/auth-team/libntlm/-/tree/master/debian
Bug#1069712: RM: murano-dashboard -- ROM; unmaintained, CVE
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: murano-dashbo...@packages.debian.org Control: affects -1 + src:murano-dashboard Hi, As we're removing murano (see the other bug report about it for murano removal), we should also remove murano-dashboard. Cheers, Thomas Goirand (zigo)
Bug#1069711: RM: murano -- ROM; unmaintained, CVE
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: mur...@packages.debian.org Control: affects -1 + src:murano Hi, Murano appears unmaintained upstream, and should be removed asap from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069673: RM: openstack-nose -- ROM; obsolete, nose removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: openstack-n...@packages.debian.org Control: affects -1 + src:openstack-nose Hi, Swift was the only use of this plugin, but I have just uploaded removing that build-depends from Swift, so this package can go. Please remove openstack-nose from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069277: RM: python-nose-exclude -- ROM; obsolete, unused
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nose-excl...@packages.debian.org Control: affects -1 + src:python-nose-exclude Hi, The last reverse dependency for python-nose-exclude was watcher-dashboard, but I fixed this. So python-nose-exclude can be removed from Debian as well, continuing the effort to remove nose from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069276: RM: python-nose-parameterized -- ROM; obsolete, unused
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nose-parameteri...@packages.debian.org Control: affects -1 + src:python-nose-parameterized Hi, Once python-nose-timer is removed from the archive (see its matching bug), then python-nose-parameterized can go as well, continuing the archive-wide effort to remove nose from the archive. Cheers, Thomas Goirand (zigo)
Bug#1069239: RM: python-nosehtmloutput -- ROM; obsolete, nose removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nosehtmlout...@packages.debian.org Control: affects -1 + src:python-nosehtmloutput Hi, As we're trying to remove nose from Debian, this package should be removed as well. Cheers, Thomas Goirand (zigo)
Bug#1069238: RM: python-nose-timer -- ROM; obsolete, nose removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nose-ti...@packages.debian.org Control: affects -1 + src:python-nose-timer Hi, As we're trying to remove nose, and this package has no reverse depends, it's time to remove python-nose-timer. Cheers, Thomas Goirand (zigo)
Bug#1069230: ITP: python-sherlock -- distributed inter-process locks with a choice of backend
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-sherlock Version : 0.4.1 Upstream Contact: Vaidik Kapoor * URL : https://github.com/py-sherlock/sherlock * License : Expat Programming Lang: Python Description : distributed inter-process locks with a choice of backend Sherlock is a library that provides easy-to-use distributed inter-process locks and also allows you to choose a backend of your choice for lock synchronization. Note: this is a new dependency of magnum-cluster-api OpenStack module.
Bug#1069229: ITP: python-haproxyadmin -- work with HAProxy via the stats socket
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-haproxyadmin Version : 0.2.4 Upstream Contact: Pavlos Parissis * URL : https://github.com/unixsurfer/haproxyadmin * License : Apache-2.0 Programming Lang: Python Description : work with HAProxy via the stats socket Haproxyadmin is a Python library for interacting with HAProxy load balancer to perform operations such as enabling/disabling servers. It does that by issuing the appropriate commands over the stats socket provided by HAProxy. It also uses that stats socket for retrieving statistics and changing settings. Note: this is a new dependency of the magnum-cluster-api module for OpenStack.
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, If there's 10 NICs with a working dhcpd, only one will be configured (the first one), so that the live OS can fetch the squashfs. The fact that all 10 NICs will be configured with an IP address depends on what you put in the live image. By default, I believe all will be configured when the system is up, but *not* at the squashfs wget phase. So, what I'm fixing with this patch, is just the pre-wget phase, so that it tries all NICs. When the first one succeeds, the scripts don't attempt to get DHCP from another NIC at this stage. That's not different from the past behavior though. I hope you understood and I explained well enough this time! :) Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, With my patch, the first NIC that gets an IP address from DHCP will be used. All NICs will be tried one by one, with the default 15 seconds timeout. The order of NICs stays the same as before, as in: the first NIC that gets a link up will be tried first. So there's no regression possible. Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi Narcis, The current behavior is that live-boot will attempt DHCP from the first NIC that is detected with link up. Cheers, Thomas Goirand (zigo)
Bug#1069052: FTBFS with SQLAlchemy 2.x
Source: gertty Version: 1.6.0-1 Severity: important Tags: patch Hi, As per subject, there's a patch upstream here to fix this bug: https://review.opendev.org/c/ttygroup/gertty/+/880123 Cheers, Thomas Goirand (zigo)
Bug#1069048: live-boot fails to DHCP on all NICs with link up
Package: live-boot
Version: 1:20230131
Severity: important
Tags: patch
Hi,
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. On each run, as soon as there
is one interface with link up, the script will exit, leaving no time
for other NICs to be up in any eventual subsequent run.
This only works if:
- one is lucky
- if only the interfaces with DHCP have an actual ethernet link.
For cases where there is more than one interface with the link up,
but only one is connected to a DHCPd server, it is possible that it
will fail (depending which card will have the link first).
The attached patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
We've tested this patch in production, with such a case where it
was failing (ie: our 25Gbits/s cards were detected first, but were not
connected to a DHCP server, while the 1Gbits/s cards that were supposed
to be holding the network boot were never tried by live-boot). And
this patch fixed things for us.
Please merge this patch if you feel like it's correct. I also would
like to have it fixed in Stable if possible (once I have the approval
from the team).
Cheers,
Thomas Goirand (zigo)
P.S: If one would like to test it, the easiest way is to build a
Debian live the normal way, then unpack the ramdisk with cpio with
something like this:
zstdcat | | cpio -idmv
Then recompress like this:
find . | cpio --create --format='newc' | zstd >
If running an older version of Debian, replacing zstdcat by zcat and
zstd by "gzip -9" also works.
>From 899aa9e8625570137fc57c4ed675bcb090119ace Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Mon, 15 Apr 2024 15:40:46 +0200
Subject: [PATCH] Do DHCP on multiple interfaces
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. If there is more than one
interface, but only one is found during a run, then it currently
gives-up searching for other interfaces and exits.
This works if one is lucky, or if only the interfaces with DHCP
have an actual ethernet link. For cases where there is more than
one interface with the link up, but only one is connected to a
DHCPd server, it is possible that it will fail (depending which
card will have the link first).
This patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
---
components/9990-select-eth-device.sh | 68
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a/components/9990-select-eth-device.sh
b/components/9990-select-eth-device.sh
index b660a3d..719a234 100755
--- a/components/9990-select-eth-device.sh
+++ b/components/9990-select-eth-device.sh
@@ -93,46 +93,56 @@ Select_eth_device ()
fi
found_eth_dev=""
- while true
+ echo -n "Looking for a connected Ethernet interface."
+
+ for interface in $l_interfaces
do
- echo -n "Looking for a connected Ethernet interface ..."
+ # ATTR{carrier} is not set if this is not done
+ echo -n " $interface ?"
+ ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
+ sleep 1
+ done
+
+ echo ''
+ for step in 1 2 3 4 5
+ do
for interface in $l_interfaces
do
- # ATTR{carrier} is not set if this is not done
- echo -n " $interface ?"
- ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
- sleep 1
- done
-
- echo ''
+ # Skip the interface if it's already found.
+ IN_IT=no
+ for DEV in $found_eth_dev ; do
+ if [ "${DEV}" = "$interface" ] ; then
+ IN_IT=yes
+ fi
+ done
- for step in 1 2 3 4 5
- do
- for interface in $l_interfaces
- do
+ if [ "${IN_IT}" = "no" ] ; then
ip link set $interface up
carrier=$(cat /sys/class/net/$interface/carrier
\
2>/dev/null)
# link detected
-
-
Bug#1068789: nsis: build fails if version number has buildX or ubuntuX suffix
Thanks for making me aware of the issue. I’d like to fix this issue for other Debian derivatives such as Linux Mint as well. Would the following change work for you? VER_REVISION=$(shell echo $(firstword $(subst +, ,$(word 3,$(VERSION_DECOMPOSED | sed 's/[^0-9]//g') Are there any other suffixes beside build and lowercase $(dpkg-vendor --query Vendor) followed by the revision number?
Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
Currently we have a working solution using js and providing multi page html. That's a good solution which is already available. > I did not go deeper into this scenario, I just found > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877337 > which includes a forward-backword-forward dance switching multiple > times between multi-page and single-page html variant requests. A single page html may be an additional option but there's already the single page txt version and the PDF. That's sufficient and I see no need in providing more formats of this manual. Therefore we can close this and I will close 877337. -- regards Thomas
Bug#872944: #872944 www.debian.org: Remove JavaScript from Policy Manual published on web mirrors
>>>>> On Wed, 10 Apr 2024 21:33:50 +0200, Holger Wansing >>>>> said: > The second javascript functionality is the full-text search. > Please note, that I made use of javascript by intend, despite of this bug > requesting to remove all js functionality. Hi holger, in the past we tried to avoid javascript, but that's long time ago (like 7 years) and nowadays I see no reason to do web pages without it if we loose functionality. So please go ahead and use js. I think the search function is very important. I think it's important not to load js code on our pages from an external URL, but to provide it from our web servers (selfhosted). > Please note, that this decision is not only for debian-policy, but for > all sphinx-based manuals on Debian website. > (I hope we don't make different decisions on this question for the > various manuals we have. That would make the implentation once again > more difficult.) All sphinx-based manuals can use js from my point of view. There's no reason to handle some manuals differently. > What should be done now? Close the bug that request to remove all js functionality (#876241). -- regards Thomas
Bug#1068377: python-oslo.messaging: please make the build reproducible
Hi Chris, Thanks for your patch. However, a better patch would be to use the sample_default= directive of oslo.config, which is printing in the generated doc, whatever the value of sample_default, while continuing to keep the default= value that can contain something programmatic. This avoids writing the "if blah is None" as you've put it. I've sent this upstream and patched olso.messaging accordingly. Cheers, Thomas Goirand (zigo)
Bug#1068676: New Upstream Release, Package Problems, vcswatch issues.
Source: edb-debugger Severity: normal Hello. The edb-debugger software is out of date. Upstream has version 1.5.0 as of two weeks ago. [1] The version in the repositories is from December 13, 2020, and is SEVERELY out of date. Note that 1.4.0 was released in July 2023. Additional observations: d/watch: Broken, needs updated to reflect updated GitHub d/watch requirements. [2] d/control: OUTDATED build depends. Replace pkg-config with pkgconf. Per Lintian tags. [3] If this package needs assistance being maintained, I can assist, but for now I will be providing Salsa pull reqs/patches to address the d/watch and d/control issues, however I am not going to handle the outdated software problem. Thomas Ward [1]: https://github.com/eteran/edb-debugger/releases [2]: https://wiki.debian.org/debian/watch#GitHub [3]: https://udd.debian.org/lintian/?packages=edb-debugger
Bug#987943: www.debian.org: Developers Reference: Sphinx search non-functional: searchindex.js missing
>>>>> On Mon, 8 Apr 2024 00:35:46 +0200, Holger Wansing >>>>> said: >> Can be viewed at >> <https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/developers-reference/> >> (also with a different html theme, BTW) >> The search works for me. Thanks a lot. -- regards Thomas
Bug#1063140: mpg123: NMU diff for 64-bit time_t transition
Am Thu, 4 Apr 2024 09:36:37 +0200
schrieb Sebastian Ramacher :
> Now I get the following on arm{hf,el}:
>
> --- debian/libmpg123-0.symbols (libmpg123-0_1.32.6~dev+20240403022201-1_armhf)
> +++ dpkg-gensymbolspYII3c 2024-04-03 09:52:12.863133592 +
> @@ -8,8 +8,8 @@
> mpg123_current_decoder@Base 1.7.2
> mpg123_decode@Base 1.6.2
> mpg123_decode_frame64@Base 1.32.3
> - mpg123_decode_frame@Base 1.6.2
> - (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base 1.13.7
> +#MISSING: 1.32.6~dev+20240403022201-1# mpg123_decode_frame@Base 1.6.2
> +#MISSING: 1.32.6~dev+20240403022201-1#
> (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base 1.13.7
> From your explanation above, this is what I expected. The builds on 64
> bit architectures and i386 are unaffected.
Thanks for confirming.
> If you feel strongly about this, I think the best option would be to
> bump SONAME of the libraries upstream …
I only feel that the subtle breakage with changed behaviour of the
still-existing symbol is to be avoided. My change for 1.32.6 does this.
The remaining symbols are still compatible with the pre-existing ABI
and upstream nothing changed, so an SONAME change from my side is not
really warranted.
This is a specific build configuration that Debian chooses. There are a
number of other options where you can disable library features and make
symbols disappear. So not that much changed from before, from the
upstream POV.
Unless you plan to add some SONAME change to all libraries affected by
the time_t/off_t change, I don't see why mpg123 libs should be singled
out. If this is just done by package name/version suffixes, then so be
it.
I'll release 1.32.6 now to enable a smoother transition.
Alrighty then,
Thomas
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 3/25/24 19:17, Julian Gilbey wrote: Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian Hi, I may not have much available time to help, though I'd love to have Arrow in Debian, as Ceph uses it, and currently use an embedded version. Cheers, Thomas Goirand (zigo)
Bug#1067562: FTBFS: missing symbols on 32-bit architectures
Am Wed, 03 Apr 2024 20:46:29 +0200 schrieb Simon Chopin : > I just uploaded the attached debdiff to Ubuntu to both fix the FTBFS and > start the t64 transition for this package, based on the following > comment: Are you able to test this for the dev snapshot of mpg123 before I do the next release? http://mpg123.org/snapshot/mpg123-1.32.6-dev+20240403022201.tar.bz2 This gets rid of the ambiguous symbols for this type of build (or should, at least), leaving only those with 64 and _64 suffix (where applicable). This at least avoids the subtle memory-corrupting ABI mismatch. Any binaries built with enabled large file support continue to work, anyway. That ABI is stable. If I get an OK that this really fires as supposed on Debian builds, I'll release 1.32.6. Alrighty then, Thomas
Bug#1056428: /usr/sbin/lparstat: Could not open /proc/ppc64/lparcfg when lauch lparstat
Hello, On IBM Power paltform , add cpu entitlement can not be done without LPARCFG=Y , because /proc/ppc64/lparcfg could not open: Logs from drmgr : ## Apr 03 10:54:41 2024 ## drmgr: -c cpu -r -q 10 -p ent_capacity -w 5 -d 1 Validating CPU DLPAR capability...yes. Could not open "/proc/ppc64/lparcfg" No such file or directory CPU entitlement capability is not enabled on this platform. Could not update system parameter ent_capacity ## Apr 03 10:54:41 2024 ## will the LPARCFG option be activated on future versions? Best Regards, Thomas. -Message d'origine- De : John Paul Adrian Glaubitz Envoyé : mercredi 22 novembre 2023 21:06 À : PEPONAS Thomas Cc : 1056...@bugs.debian.org Objet : Re: Bug#1056428: /usr/sbin/lparstat: Could not open /proc/ppc64/lparcfg when lauch lparstat Control: reassign -1 src:linux Control: retitle -1 "linux: Please enable CONFIG_LPARCFG for ppc64 and ppc64el" Hello Thomas! On Wed, 2023-11-22 at 13:02 +0100, peponas wrote: > lparstat report "Could not open /proc/ppc64/lparcfg" exemple : > lparstat 1 1 > Could not open /proc/ppc64/lparcfg > > System Configuration > type=Dedicated mode=Uncapped smt=8 lcpu=- mem=16653440 kB cpus=0 > ent=0.00 > > %user %sys %wait%idlephysc %entc lbusy app vcsw phint > - - --- - - - - - > Could not open /proc/ppc64/lparcfg > 0.12 0.12 0.0099.75 0.00 nan 0.25 0.00 - 350 > > kernel with config LPARCFG=Y resolv problem. Since this is obviously something that needs to be changed in the kernel configuration, the bug should be reported against src:linux and not against the powerpc-utils package. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1064593: issue with Debian-style html theme for sphinx-based documents
Hi Holger, even if things get more complex, this is a working solution. I'm very happy for that and there's no need for spending more time into looking for a perfect solution. >From my side you get a thank you very much and a GO for applying this patch. >>>>> On Tue, 2 Apr 2024 14:47:12 +0200, Holger Wansing >>>>> said: > The 1ftpfiles and 7doc scripts, which need to be adapted for that, and > also the situation on the www mirrors is getting more complex, so I'm unsure > if we want this. > See my patch. > On the other side, I don't see any other solution apart from developing > a new theme. -- regards Thomas
Bug#1063140: mpg123: NMU diff for 64-bit time_t transition
Hi again, (after Easter hiatus … or rather xz backdoor meltdown?) I had a stab at this, detecting a system that forces 64 bit offsets on a 32 bit base in configure. This is to ensure that you do not encounter the same symbol (like mpg123_tell() on two builds of the library on the same platform offering a differing ABI (32 or 64 bit argument or return value). This is supposed to look like that: $ CPPFLAGS=-D_FILE_OFFSET_BITS=64 ./configure […] checking switched off_t size... 8 checking unswitched off_t size... 4 checking size of off_t... 8 configure: Detected system with enforced 64 bit offsets, dropping suffixless symbols for uncryptic ABI breakage. checking if native off_t is already 64 bits... yes […] default offsets . 64 explicit 64 bit offsets . no forced 64 bit offsets ... yes […] This removes the ambiguous symbols from libmpg123.so and libsyn123.so. With unchanged soversion, client code built for the earlier version before the off_t/time_t 64 bit switch will fall in two categories: 1. Built with enabled large file support: Continues to work, no breakage. 2. Built without large file support: Will break early at runtime linking stage. There might be applications that just use API not affected by off_t changes and thus are fine either way. Can you verify that the prospective 1.32.6 (named 1.32.6-dev) under http://mpg123.org/snapshot/mpg123-1.32.6-dev+20240403022201.tar.bz2 works fine in the debian build and meets expectations? I'd do a proper release of it soon, then. It's up to you (Debian) to decide what to do with binary package naming for the transition (it is your business anyway;-), but I feel strongly about the change to avoid an existing symbol changing ABI with subtle breakage. I also think it is reasonable not to invest work into yet another set of wrappers to put 32 bit offsets on life suppport on a system that follows the decision to enforce 64 bits. The setup of wrappers and alias calls in mpg123 code is confusing enough already. Alrighty then, Thomas
Bug#1068250: dracut: Consider switching to the fork dracut-ng
>>>>> On Tue, 02 Apr 2024 19:59:57 +0200, Jörg Behrmann >>>>> said: > Activity in dracut upstream has died down recently and though there is a version > 60 of dracut in sid, upstream has not tagged such a release. The upstream release process changed, so they do not tag the releases any more. > A fork of dracut has been started by some dracut developers at > https://github.com/dracut-ng/dracut-ng > It should be evaluated to switch to this fork. Thanks for the info. I will carefully watch the work on this fork. -- regards Thomas
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
On Sat, Mar 30, 2024 at 08:02:18PM +0100, Sven Joachim wrote:
> On 2024-03-30 12:38 +0100, Santiago Vila wrote:
>
> > El 30/3/24 a las 9:43, Sven Joachim escribió:
> >> I think it would make sense for Debian to follow what Arch and Fedora
> >> are doing, introduce a libdialog15 package with the shared library and a
> >> libdialog-dev package with the .so symlink but without libdialog.a,
> >> because that requires (if I understood you correctly) configuring and
> >> building dialog twice, greatly complicating packaging.
> >> Santiago, do you think this is a good plan?
> >
> > Yes. If we can avoid the static library to keep it simple, that would be
> > better.
> >
> > Simple question: Is that really allowed these days? I wanted to be sure
> > by reading Policy but did not find any statement saying they are required
> > or not.
>
> I could only find the following two sentences in §8.3:
>
> ,
> | The static library ("libraryname.a") is usually provided in addition
> | to the shared version. It is placed into the development package (see
> | below).
> `
>
> So shipping static libraries is recommended but not required, and there
> are certainly quite a few packages where upstream does not support them.
> But see below.
Actually, for development on MacOS, I have to use static libraries,
because there's no useful analog for LD_LIBRARY_PATH :-)
> >> I can work on an updated patch.
> >
> > That would definitely help.
>
> This afternoon I got my hands dirty. The first attempt to simply pass
> --with-shared to configure failed to give me a libdialog.a, and it also
> produced the following odd collection of *.so* files:
>
> libdialog.so -> libdialog.so.15.0.0
> libdialog.so.1.3
> libdialog.so.15.0.0 -> libdialog.so.1.3
fwiw, ncurses, dialog and cdk use the same scripts (and version information)
> Not what you would expect, and it does not match the files shipped in
> the Fedora and Arch packages. A closer look revealed that they both
> configure dialog --with-libtool, and that worked great because it gave
> me not only the expected layout of *.so* files, but also a static
> libdialog.a library. :-)
perhaps - but since aside from Linux, libtool support is not reliable,
it's not going to be of primary concern to me.
--
Thomas E. Dickey
https://invisible-island.net
signature.asc
Description: PGP signature
Bug#1067771: cdk.h file location has changed, breaks application build
On Fri, Mar 29, 2024 at 01:30:58PM -0500, Steven Robbins wrote: > On Thursday, March 28, 2024 8:04:30 P.M. CDT Thomas Dickey wrote: > > > I suppose that I _could_ have made a symlink in /usr/include/cdk, > > to address both old/new locations. You might consider that for > > the package... > > That's a good idea. I've implemented your suggestion and closed the bug. no problem (report bugs) -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1067935: ibus-table-yong: Broken link in package description
Package: ibus-table-yong Severity: minor Dear Maintainer, It looks like in the description of ibus-table-yong, the link to http://yong.uueasy.com/read.php?tid=218 leads to a blank page. Would it be possible to update the description to either fix or remove the link? Thanks for maintaining ibus-table-yong! Thomas -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) 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 ibus-table-yong depends on: pn ibus-table ibus-table-yong recommends no packages. ibus-table-yong suggests no packages.
Bug#1067771: cdk.h file location has changed, breaks application build
On Thu, Mar 28, 2024 at 08:55:04PM -0400, Thomas Dickey wrote: > On Thu, Mar 28, 2024 at 11:15:04AM -0500, Steven Robbins wrote: > > Hello Thomas! > > > > Thanks for chiming in on this issue. I had sent a follow-up at about the > > same > > time you did with a few details on the history as I could reconstruct it. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067771#18 > > > > In summary: I believe you changed the default location from to > > in 2012, adding a configure option at the same time. When this > > version > > was uploaded to Debian (much later), a debian-specific patch was added to > > retain the original location. Four years ago, the previous debian > > maintainer > > removed that patch - but was never uploaded to debian unstable. I took > > over > > maintenance a month ago and inadvertently uploaded to unstable a version > > where > > the header change from 2012 was exposed for the first time. > > ...yes - I didn't record a reason for the change, so likely what prompted it > was noting that cdk.h includes all of the other files, which makes it > inconsistent to put it in the same subdirectory as the others. fwiw, I do the > same for dialog. > > Just in case someone disagreed, I made it configurable. I suppose that I _could_ have made a symlink in /usr/include/cdk, to address both old/new locations. You might consider that for the package... -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1067771: cdk.h file location has changed, breaks application build
On Thu, Mar 28, 2024 at 11:15:04AM -0500, Steven Robbins wrote: > Hello Thomas! > > Thanks for chiming in on this issue. I had sent a follow-up at about the > same > time you did with a few details on the history as I could reconstruct it. > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067771#18 > > In summary: I believe you changed the default location from to > in 2012, adding a configure option at the same time. When this > version > was uploaded to Debian (much later), a debian-specific patch was added to > retain the original location. Four years ago, the previous debian maintainer > removed that patch - but was never uploaded to debian unstable. I took over > maintenance a month ago and inadvertently uploaded to unstable a version > where > the header change from 2012 was exposed for the first time. ...yes - I didn't record a reason for the change, so likely what prompted it was noting that cdk.h includes all of the other files, which makes it inconsistent to put it in the same subdirectory as the others. fwiw, I do the same for dialog. Just in case someone disagreed, I made it configurable. > I can see a valid argument for retaining the Debian practice. But when I > discovered that the upstream change was 12 years old, I figured that there > are > likely other folks long used to the "new" header location and have adapted > their code. So there is also a valid argument to adhering to the upstream > location and harmonizing the landscape for code using libcdk. > > I actually did a search on github and discovered examples of all three cases: > * code using only > * code using only > * code that probes both locations and uses the one found > > I'm wondering whether you have an opinion on the merits of one path versus > the > other. Do you have any information about how much currently-maintained > software is still using ? not really (actually I don't keep track for any of my programs) In a quick check of other packages that I know about, I don't see any using the subdirectory. (I've corrected the configure option, just for tidiness). > At present, I'm leaning towards retaining the default location . I suppose it depends on how many packages have to be tweaked. (actually in the current set of changes for time_t, I'd suppose that changes like this would be less favored) -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1067333: Further investigation
Hi,
I tried rebuilding autosuspend in Sid, and the build lead to this
traceback in Java:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line
223, in html_visit_plantuml
fnames = dict((e, render_plantuml(self, node, e))
File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line
223, in
fnames = dict((e, render_plantuml(self, node, e))
^^
File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line
116, in render_plantuml
raise PlantUmlError('error while running plantuml\n\n' +
serr.decode('utf-8'))
sphinxcontrib.plantuml.PlantUmlError: error while running plantuml
Exception in thread "main" java.lang.InternalError:
java.lang.reflect.InvocationTargetException
at
java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at
java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
at
java.desktop/sun.font.SunFontManager.getInstance(SunFontManager.java:248)
at
java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:266)
at
java.desktop/sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:871)
at net.sourceforge.plantuml.Run.forceOpenJdkResourceLoad(Run.java:230)
at net.sourceforge.plantuml.Run.main(Run.java:137)
Caused by: java.lang.reflect.InvocationTargetException
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at
java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
... 7 more
Caused by: java.lang.RuntimeException: Fontconfig head is null, check
your fonts or fonts configuration
at
java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1271)
at
java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
at
java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
at
java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at java.desktop/sun.font.SunFontManager.(SunFontManager.java:315)
at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35)
at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:56)
... 13 more
so the issue seems to be in PlantUML rather than its sphinxcontrib
wrapper in Python.
Please note that the part that raised the error in Python is probably
broken, but when there's no error when starting PlantUML, the module
should still be ok.
I'm reassigning the bug to PlantUML. Please deal between autosuspend and
PlantUML.
Cheers,
Thomas Goirand (zigo)
Bug#1067873: kdeconnect only uses IPv6 and no IPv4
Package: kdeconnect Version: 23.08.2-1 Severity: important Dear Maintainer, I have been upgrading my system recently, as I do every day since I use testing, and with the advent of the 64b time support I had to reinstall all KDE due to a pebkac. After that kdeconnect refused to connect to my other systems and phones. After a bit of investigations, I found out that it only listen on IPv6 and not on IPv4. As there isn't (as far as I know) a way to configure it to use what I want, I can't make it chat with other kdeconnect instances on my LAN. ```bash thomas@localhost:~$ sudo netstat -tnlp | grep kdeconnect tcp6 0 0 :::1716 :::*LISTEN 13425/kdeconnectd thomas@localhost:~$ sudo netstat -tnlp | grep ssh # as an example of service listening on both protos tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1809/sshd: /usr/sbi tcp6 0 0 :::22 :::*LISTEN 1809/sshd: /usr/sbi thomas@localhost:~$ LC_ALL=C sudo fuser -v -n tcp 1716 USERPID ACCESS COMMAND 1716/tcp:thomas13425 F kdeconnectd thomas@localhost:~$ LC_ALL=C sudo fuser -v -n udp 1716 USERPID ACCESS COMMAND 1716/udp:thomas13425 F kdeconnectd ``` -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kdeconnect depends on: ii fuse3 3.14.0-5 ii kio 5.107.0-1+b1 ii kpeople-vcard 0.1-3+b1 ii libc6 2.37-15 ii libfakekey0 0.3+git20170516-2 ii libglib2.0-02.78.4-1 ii libkf5configcore5 5.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 libkf5guiaddons55.107.0-1+b1 ii libkf5i18n5 5.107.0-1+b1 ii libkf5iconthemes5 5.107.0-1+b1 ii libkf5kcmutils5 5.107.0-2+b1 ii libkf5kiocore5 5.107.0-1+b1 ii libkf5kiofilewidgets5 5.107.0-1+b1 ii libkf5kiogui5 5.107.0-1+b1 ii libkf5kiowidgets5 5.107.0-1+b1 ii libkf5modemmanagerqt6 5.107.0-1+b1 ii libkf5notifications55.107.0-1+b1 ii libkf5people5 5.107.0-1+b1 ii libkf5pulseaudioqt3 1.3-2+b1 ii libkf5service-bin 5.107.0-1+b1 ii libkf5service5 5.107.0-1+b1 ii libkf5solid55.107.0-1+b1 ii libkf5widgetsaddons55.107.0-1+b1 ii libkf5windowsystem5 5.107.0-1+b1 ii libqca-qt5-22.3.8-1 ii libqca-qt5-2-plugins2.3.8-1 ii libqt5core5a5.15.10+dfsg-7 ii libqt5dbus5 5.15.10+dfsg-7 ii libqt5gui5 5.15.10+dfsg-7 ii libqt5multimedia5 5.15.10-2+b1 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 libqt5waylandclient55.15.10-2+b1 ii libqt5widgets5 5.15.10+dfsg-7 ii libqt5x11extras55.15.10-2+b1 ii libstdc++6 14-20240201-3 ii libwayland-client0 1.22.0-2.1+b1 ii libx11-62:1.8.7-1 ii libxkbcommon0 1.6.0-1 ii libxtst62:1.2.3-1.1 ii plasma-framework5.107.0-1+b1 ii qml-module
Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]
On Wed, 27 Mar 2024 at 20:25, Santiago Vila wrote: > > When I had already a bunch of them, I realized there is a macro > STDC_HEADERS which is not properly detected. Ah, I suspect the configure code is too old. Regenerating configure etc. (autoreconf) might help. -#if STDC_HEADERS > +#if STDC_HEADERS || 1 > But this is a good test to see if you've identified the problem. -- https://rrt.sc3d.org
Bug#1067771: cdk.h file location has changed, breaks application build
On Tue, Mar 26, 2024 at 03:37:10PM +0100, Harald Welte wrote: > Package: libcdk5-dev > Version: 5.0.20230201-3 > Severity: normal > > It used to be the case (for probably more than a decade) that the main cdk.h > file > contained in libcdk5-dev is located in /usr/include/cdk/cdk.h odd - I dimly recall some long-ago discussion. But reviewing it, I see that I had implemented a configure option, which doesn't actually work. In configure.in, I see that the option should have set $HDR_SUBDIR, and that if the option was set, the value for HDR_ROOTNAME also is incorrect: 1.53 (tom 20-Mar-12): AC_MSG_CHECKING(if cdk.h should be in header subdirectory) 1.53 (tom 20-Mar-12): AC_ARG_WITH(hdrname, 1.53 (tom 20-Mar-12): [ --enable-hdr-subdir install cdk.h in the header subdirectory], 1.53 (tom 20-Mar-12): [HDR_ROOTNAME=no]) 1.53 (tom 20-Mar-12): AC_MSG_RESULT($HDR_SUBDIR) 1.53 (tom 20-Mar-12): AC_SUBST(HDR_SUBDIR) 1.53 (tom 20-Mar-12): 1.53 (tom 20-Mar-12): if test "$HDR_SUBDIR" = yes 1.53 (tom 20-Mar-12): then 1.53 (tom 20-Mar-12): HDR_SUBDIR="#" 1.53 (tom 20-Mar-12): else 1.53 (tom 20-Mar-12): HDR_SUBDIR= 1.53 (tom 20-Mar-12): fi However, looking at the history for the Debian package, https://salsa.debian.org/debian/libcdk5 I don't see how it worked around the HDR_SUBDIR value. The existing script can be worked-around by setting HDR_SUBDIR to "yes" when running the configure script. (The updates for 2023 fixed the known fail-to-build issues; I have some further unreleased changes, but had overlooked this although I might have stumbled onto this bug by some ongoing work to compare the layout in my test-packages vs Debian). > This is still the case in debian stable as of 5.0.20180306-3 > > However, in currnt unstable (5.0.20230201-3), the location has suddenly > shifted to > /usr/include/cdk.h > > This is breaking applications like osmo-bsc, which is using the following > autoconf macro to test for cdk.h presence: > > AC_CHECK_HEADERS(cdk/cdk.h, [], AC_MSG_ERROR(Unable to find libcdk)) > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libcdk5-dev depends on: > pn libcdk5t64 > ii libncurses-dev 6.4+20240113-1 > > libcdk5-dev recommends no packages. > > libcdk5-dev suggests no packages. > -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Bug#1067649: Verification page is not accessible from the homepage
> So here I adapt my original request: please add the link to /verify at > the /distrib page; and if possible, also consider renaming the link of I've added the link now to the /distrib web page. -- regards Thomas
Bug#1067517: AW: Re: Bug#1067517: found bug in checkdisk
> On Tue, 26 Mar 2024 13:36:44 +, Florian Goth > said: > OK, on my system, in a fai-nfsroot for bookworm > the group of /dev/sda was root, and this was also returned by this stat command. This may happen if you do not use systemd inside the nfsroot for bookworm with FAI 6.2 and newer. You may need to adjust the /etc/fai/NFSROOT config if you are still using an old version. In the past this config disabled systemd inside the nfsroot.
Bug#1067517: found bug in checkdisk
>>>>> On Mon, 25 Mar 2024 11:57:10 +, Florian Goth >>>>> said: > stat -c %G > returns the group of the owner, but nothing related to a device type. And this group is "disk" in case it's a disk. -- viele Grüße Thomas
Bug#1067697: Update Build-Depends for the time64 library renames
For everyone's awareness: this same t64 transition is going on downstream in Ubuntu, and I'm also tracing rebuilds, etc. with changed dependencies there as well which are being done by other core devs there, so those changes may trickle back up into Debian here. Thomas (this email is the one behind my @ubuntu.com address)
Bug#1067697: Update Build-Depends for the time64 library renames
The only package that has a changed name that I can see is `libqt5sql5` to `libqt5sql5t64`. I have already put this in the revisions in Salsa at the moment. If `libqt5help5` has a rename pending to `libqt5help5t64` and that's not yet in Unstable, then I can't make that revision safely. Thomas -Original Message- From: Andrey Rakhmatullin Sent: Monday, March 25, 2024 14:00 To: Debian Bug Tracking System Subject: Bug#1067697: Update Build-Depends for the time64 library renames Source: xca Version: 2.5.0-1 Severity: serious The package explicitly Build-Depends: libqt5sql5, libqt5help5, this needs to be changed to the new names if it's needed at all. -- 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.9-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
Bug#1063140: mpg123: NMU diff for 64-bit time_t transition
Hi Sebastian, thanks for not escalating on the anger that has shown through the end of my last reply. It really seems to be an endless stream of pain that results from once having put off_t into public API. This is the message I have to any developer: Do not put types into your API that could depend on compile-time settings! (Even, and especially, if the libc does that and you _think_ it could be handled.) At least it is clear to me now that time_t is only a minor detail. You are switching system ABI in enabling LFS and 64 bit time_t. This is a decision that Debian made and also, you are planning to make this transition in-place, instead of calling it a new arch. From my point of view, then, the mpg123 build works as designed: It sees a system with fixed 64 bit off_t and drops any 32 bit off_t support from the ABI. Since you do this switch on upgrade of existing systems, you need to handle that in the packaging system, either via versioning or the suffix you designed. Fine, then. But there is a consideration for user-compiled code in the system. The important breakage here is not that the _32 suffix symbols are missing. It is rather that the non-suffixed ABI suddenly changed. If a user program that just was built without _FILE_OFFSET_BITS being set for the old library is started using the replaced libmpg123 binary, it finds the mpg123_tell() symbol, but suddenly faces memory corruption as that function now writes 64 bits instead of 32 bits to the return address. A clean transition, IMHO, would mean that you have to change sonames so that it is clear that the new libraries have a different ABI. Silently breaking user binaries is a bothersome issue to me. Breaking them with 'library not found' errors is obvious. Subtle errors and crashes through memory corruption are not. I'd rather have that situation avoided. One solution would be to have a library mode that drops both mpg123_tell() mpg123_tell_32() and only retains mpg123_tell_64() as well as the recently added actual mpg123_tell64() using int64 instead of off_t. If _FILE_OFFSET_BITS is defined system-wide (in gcc internal headers / spec file), new builds will pick up mpg123_tell_64() and not notice any missing symbols. With this, you only have the missing symbols for clear errors at least. On the other hand, providing the wrappers for 32 bit is a possible option. The code is there … but … thinking … no. It doesn't help. Having a 32 bit mpg123_tell() in a system defaulting to 64 bit off_t is really confusing. Can you do a scan over all depending packages and ensure that they only use _64 suffixed symbols (where there is a pair like mpg123_tell() and mpg123_tell_64())? Even if you change the package name for the transition, I'd like to ensure that the new library does cause controlled failure due to linker errors instead of subtle runtime breakage. Would you be willing to add something along ./configure --disable-suffixless-abi to your builds once I implement that? This would double the count of dropped symbols, but avoid the subtle runtime ABI breakage. Alrighty then, Thomas PS: Please observe my comments about --with-cpu on ARM, bug #1067562.
Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x
Package: wireplumber Version: 0.4.17-1+b1 Severity: normal Dear Maintainer, According to the new api in wireplumber asahi-audio 1.x breaks. The asahi developer tries to fix this upstream in asahi-audio during this week but because of the api change asahi-audio 2.x will break with wireplumber <0.5.0. So there is/will be a direct dependency: wireplumber 0.4.x compatible to asahi-audio 1.x wireplumber >= 0.5.0 comaptible to asahi-audio 2.x Source; fedora-asahi-dev channel on matrix 24.03.2024, @chadmed around 01.24. https://matrix.to/#/#asahi-devel:fedoraproject.org Please consider this -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.6.0-asahi-00915-ge3707768193f (SMP w/10 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireplumber depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.10-4 ii dbus-x11 [dbus-session-bus] 1.14.10-4 ii init-system-helpers 1.66 ii libc6 2.37-15 ii libglib2.0-0t64 [libglib2.0-0]2.78.4-3 ii libpipewire-0.3-0 1.0.3-1 ii libwireplumber-0.4-0 0.4.17-1+b1 ii pipewire 1.0.3-1 Versions of packages wireplumber recommends: ii pipewire-pulse 1.0.3-1 Versions of packages wireplumber suggests: ii libspa-0.2-bluetooth 1.0.3-1 pn libspa-0.2-libcamera pn wireplumber-doc -- no debconf information
Bug#1067649: Verification page is not accessible from the homepage
I don't think we need the link on the startpage, but maybe on the /distrib page where we provide other ISO downloads. But in the end I try to remember whenever I have verified an ISO by myself. I can't remember and I guess I never did it. Maybe I check that I'm using https://www.debian.org. That's all I need to trust. -- regards Thomas
Bug#1067562: FTBFS: missing symbols on 32-bit architectures
Am Sat, 23 Mar 2024 21:59:54 +0500 schrieb Andrey Rakhmatullin : > Source: mpg123 > Version: 1.32.5-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=mpg123=armel=1.32.5-1%2Bb1=1711185338=0 This is being discussued in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063140 The build log shows this: largefile sensitive . no default offsets . 64 The new 64 bit time_t setup also fixes off_t to be 64 bits and so the mpg123 build figures that you don't need 32 bit offset symbols. Also the non-suffixed functions now work with 64 bit offsets, where they formerly worked with 32 bit off_t arguments. This could be considered ABI breakage, too. We should figure out what the desired state is here. Should the ABI stay the same as before? Then the _FILE_OFFSET_BITS=64 needs to be ignored for the libmpg123 build. Also, I notice this: Why do you have --with-cpu=generic_fpu there? You really should either use one of arm_fpu Pack neon and generic[[_dither]] decoders, for ARM processors with FPU and/or NEON arm_nofpuUse code optimized for ARM processors with fixed point arithmetic for 32 bit ARM and aarch64 Pack neon64 and generic[[_dither]] decoders, for 64bit ARM processors for 64 bit ARM. http://mpg123.org/benchmark/mpg123-1.23.8_arm_fpu_BananaPi_Allwinner_H3@1200MHz_bananian-jessie.txt #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s NEON18.06 21.54 generic 35.10 32.39 generic_dither 35.98 33.30 http://mpg123.org/benchmark/mpg123-1.23.8_arm_nofpu_BananaPi_Allwinner_H3@1200MHz_bananian-jessie.txt #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s ARM 36.02 34.32 With NEON, you got a factor of two for 16 bit output. Hm. Generic with FPU doesn't look that bad compared to the plain ARM assembly. But when we are talking about ARMs with NEON, one really should use that. Hm I also have http://mpg123.org/benchmark/mpg123-r3525_Raspberry-Pi_raspian.txt #mpg123 benchmark (user CPU time in seconds for decoding) #decodert_s16/s t_f32/s ARM 86.26 90.66 generic 102.80 100.06 generic_dither 121.10 100.84 So this nofpu build still shows some benefit from the plain ARM assembly, too. Is there a special reason why Debian avoids using the optimized decoders on ARM? Alrighty then, Thomas
Bug#1063140: mpg123: NMU diff for 64-bit time_t transition
tail? Glancing at https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html suggests to me that we're repeating the same mess that already plagued the world with the botched LFS handling. Shape-shifting off_t … now shape-shifting time_t, too. Why do we have to do dual-time configurations? So maybe I'll have to revise large file API/ABI crap for the dozenth time. It's never over, appparently. Should I go full $TRIGGERWORD and always add the _32 symbols using int32_t, regardless of native off_t size (adding senseless bloat on 64 bit systems)? So … now … I _do_ use time_t internally. Once in libout123, for a timeout while reading data (where 32 bits probably are adequate enough), but also in libout123 for clock_gettime(), which also is intended for short sleeps, but does work by subtracting full system time values, so possibly affected post-2038. So, maybe I'll have to change the native off_t size check to also forcibly undefine _FILE_OFFSET_BITS. Then, since I apparently need (?) both _FILE_OFFSET_BITS and _TIME_BITS for working 64 bit time_t on 32 bit platforms, I need to rephrase the LFS wrapper code not to touch off_t at all, but use int32_t instead? This would mean adding the _32 wrappers for anyone specifying _FILE_OFFSET_BITS=64 at mpg123 build time, which does strike me as suboptimal. My assumption so far is that, if the user does specify this during build, it should be taken as a platform property. It should be always on. Right now, this also results in the non-suffixed plain off_t mpg123_tell() returning a 64 bit value. Without that setting, this would be the 32 bit variant and aliased by mpg123_tell_32(). When I ignore _FILE_OFFSET_BITS at build-time for that now, I break ABI with earlier builds where people intended to just get the 64 bit functions. Regardless of how often I revise LFS stuff, I always end up in a mess. Alrighty then, Thomas PS: Will Debian support 32 bit platforms in 2038 and beyond, apart from embedded platforms that could just settle on _one_ time_t size?
Bug#1067497: openstreetmap-carto-common: "openstreetmap-carto-common.install" does not include directory "style"
Package: openstreetmap-carto-common Version: 5.7.0-1 Severity: important Tags: newcomer X-Debbugs-Cc: fisc...@unix-ag.uni-kl.de Hello, The Git repository of openstreetmap-carto [1] contains a directory called "style" with various files that are necessary to work with openstreetmap-carto, e.g. if one wants to use this Debian project package instead of pulling from Git if following the Switch2OSM instructions for Debian 12 [2]. This directory is missing from openstreetmap-carto-common.install, where other 'data' directories like "symbols" are included. This bug can be easily fixed by adding "style" below "symbols" in a similar manner. [1] https://github.com/gravitystorm/openstreetmap-carto/ [2] https://switch2osm.org/serving-tiles/manually-building-a-tile-server-debian-12/ Another minor issue that can be fixed as you touch the package: In "rules" there is this "chmod -x" invocation referring to an upstream bug report from 2021. This problem has been fixed upstream and the chmod is no longer necessary. Simplifies code ... -- 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/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openstreetmap-carto-common depends on: ii curl 7.88.1-10+deb12u5 ii debconf [debconf-2.0] 1.5.82 ii fonts-dejavu-core 2.37-6 ii fonts-noto-cjk 1:20220127+repack1-1 ii fonts-noto-hinted 20201225-1 ii fonts-noto-unhinted20201225-1 ii fonts-unifont 1:15.0.01-2 ii gdal-bin 3.6.2+dfsg-1+b2 ii mapnik-utils 3.1.0+ds-3+b1 ii python33.11.2-1+b1 ii unzip 6.0-28 openstreetmap-carto-common recommends no packages. openstreetmap-carto-common suggests no packages. -- debconf information excluded
Bug#1067451: libzip: please update to 1.10.1
Package: libzip Version: 1.7.3-1.1 Upstream here. The libzip package in Debian is quite outdated (a release from 2020), can you please update it to the latest version (1.10.1 right now, from August 2023)? We take care that libzip is backwards-compatible, so the update should be painless. Let me know if it isn't! Thanks, Thomas
Bug#727656: Status of libpaper fork
On Tue, 19 Mar 2024 at 21:37, Bastian Germann wrote: > > As nobody has provided any patch yet and I do not have an idea how to use > gnulib properly generally and in Debian > context, I came up with this. I have actually tried to use Debian's gnulib > but could not get the thing to work. > Fair enough. From my point of view, I don't think your patch should introduce any functional problem. I think this will end up in syntax errors but you can try. The obvious fix > for me would be putting the quotation marks > around each of the three format strings that the quoted strings are > inserted in. > Ah, you're quite right as the arguments to quote() are variables. Your fix works for me. The result is just a minor cosmetic deficiency compared to upstream. -- https://rrt.sc3d.org
Bug#1067182: node-with: Typo in package description
Package: node-with Severity: minor Dear Maintainer, The second paragraph of node-with description contains a typo. I believe it should be 'The `with` statement' instead of 'The `width` statement' (notice the d). Thanks for maintaining node-with! Thomas -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) 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 node-with depends on: pn node-babel7 node-with recommends no packages. node-with suggests no packages.
Bug#727656: Status of libpaper fork
On Mon, 18 Mar 2024 at 23:33, Bastian Germann wrote: > Hi, > > I have updated the salsa repo to build without gnulib. > Fantastic, thanks for doing this! I am a little puzzled, I thought that the idea was to build with Debian gnulib? I think that could be a simpler patch. Looking at the patches, nothing seems really a problem though, except that `quote(q)` should put single quotation marks around its argument. You could use ASCII apostrophe for this: #define quote(q) "'" q "'" -- https://rrt.sc3d.org
Bug#1067103: libisoburn1t64: should not depend on libburn4 nor libisofs6 after time_t transition
Hi, being the one who usually prepares the releases, i am currently standing in hands-off position until the time_t change is completed. The package tracker is still complaining bitterly about the current intermediate state. Consider to re-open https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062380 "libisoburn: NMU diff for 64-bit time_t transition" and/or to contact its submitter. Have a nice day :) Thomas
Bug#1067107: After installing debian 12.5 no login possible
Package: Debian installer Version: As on Debian live-CD/DVD for Debian 12.5 Severity: critical 1. Download debian live-CD/DVD from: https://cdimage.debian.org/debian-cd/current/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso or https://ftp.gwdg.de/debian-cd/12.5.0-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso 2. Boot from this DVD 3. Doubble click on "Install to harddisk" 4. Select to erase a partitioned harddisk 5. Select "German" 6. For User and Passwort enter Full name: demo Demo Username: de-de Password 1st: start123 Password 2nd: start123 7. Click install 8. Wait until the installer finishes and reboots into this newly installed system 9. Try to login with the credentials given above: User: de-de Password: start123 The newly installed system just tells: unknown user or password, user or password wrong. You wont be able to login. Having a closer look at the system installed: - The system language ist set to en_US, instead, as selected to de_DE. - The keyboard language and layout ist set to en_US, instead, as selected to de_DE. - The user given isn't created at all. - The password isn't entered into /etc/passwd or /etc/shadow. - Root is created, but does not have a password, while passwordless logins are prohibited Conclusion: it is not possible to login to the system. Youl have to hack it to get access. -- Thomas
Bug#1067105: After installing Debian wont let you in with a given User/Password combination
Package: Debian installer Version: As on Debian live-CD/DVD for Debian 12.5 Severity: critical 1. Download debian live-CD/DVD from: https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-12.5.0-amd64-DVD-1.iso or https://ftp.gwdg.de/debian-cd/12.5.0-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso -- Thomas
Bug#1067063: Fix in experimental
Hi, OpenStack Carcal is about to be released, and the fix must be in the package in Experimental already. Cheers, Thomas Goirand (zigo)
Bug#1067014: accesses internet during build
Source: mapclassify Version: 2.6.1-3 Severity: important Hi, During the build, mapclassify is using intersphinx, which is collecting information from the internet during build. Please remove the intersphinx module from docs/conf.py. Cheers, Thomas Goirand (zigo)
Bug#1067011: ITP: python-observabilityclient -- OpenStack Observability Client
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-observabilityclient Version : 0.1.1 Upstream Contact: OpenStack Foundation * URL : https://infrawatch.github.io/documentation/ * License : Apache-2.0 Programming Lang: Python Description : OpenStack Observability Client observabilityclient is an OpenStackClient (OSC) plugin implementation that implements commands for management of Prometheus. This is a new dependency of OpenStack.
Bug#1066927: ITP: python-momepy -- Urban Morphology Measuring Toolkit
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-momepy Version : 0.7.0 Upstream Contact: Martin Fleischmann * URL : https://github.com/pysal/momepy * License : BSD-3-clause Programming Lang: Python Description : Urban Morphology Measuring Toolkit Momepy is a library for quantitative analysis of urban form - urban morphometrics. It is part of PySAL (Python Spatial Analysis Library) and is built on top of GeoPandas, other PySAL modules, and networkX. Note: this is a new dependency of networkx, so we can continue to build its documentation.
