Bug#1065702: krb5-kdc: uninstallable due to hard-coded dependency on libverto-libev1 | libverto-libevent1,
Package: krb5-kdc Version: 1.20.1-5.1 Severity: serious User: debian-...@lists.debian.org Usertag: time-t Hi Sam, I've run into a problem with openldap not being bootstrappable for the time_t transition because it build-depends on krb5-kdc, and krb5-kdc is uninstallable on arm* because of a hard-coded dependency on libverto-libev1 | libverto-libevent1. Both of these library packages have changed names so are now libverto-libev1t64 and libverto-libevent1t64. I don't know why these need to be hard-coded, but if they do they need to be updated, because they conflict with the shlibdeps-generated dependency on libverto1t64. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#772886: your mail
On Thu, 19 May 2022 09:08:09 +0200 (CEST) raphael.jo...@free.fr wrote: > Thorsten Glaser wrote: > > Personally, I’d rather not see more of this environmental pollution > > in Debian, but not speaking for a team. > > +1 > > https://www.researchgate.net/publication/328581842_Bitcoin_emissions_alone_could_push_global_warming_above_2C > Just Western mainstream media's propaganda. Bitcoin is today the greenest industry in the world, and in 5 years might become carbon NEGATIVE. https://www.whatbitcoindid.com/podcast/making-bitcoin-carbon-negative https://gridlesscompute.com/ Don't trust, verify. Carlo -- ,= ,-_-. =./ .-. _ _ ___ ___ _ __ ((_/)o o(\_)) / oo|| | | / __|/ _ \ '__| `-'(. .)`-' / /`'\| |_| \__ \ __/ | \_/ / (\_;/)\__,_|___/\___|_|
Bug#1065072: packagekit spinning cpu
Am Sa., 9. März 2024 um 07:30 Uhr schrieb Joey Hess : > > Joey Hess wrote: > > It may also be relevant somehow that the topmost update was a thinkpad > > AMD firmware update which "requires restart". > > I masked and stopped packagekit again and now in gnome-software, it > displays only the thinkpad amd firmware update, and it's no longer > alternating with the loading updates screen. > This makes me think that firmware update is not related to the problem. > > The other updates gnome-software displays when packagekit is running are > debian package updates. My last upgrade was an apt-get safe-upgrade, > because dist-upgrade wants to remove several packages, including gnome. > (I'm tracking unstable, this is typical transient dependency issues I > suppose. Also I have bluez on hold at an older version due to #1060224) > > So maybe gnome-software gets confused in this kind of situation and keeps > retrying? That is the current hypothesis, yes - the change that broke this was introduced by Fedora, and they do not observe this behavior. So, either GNOME Software is wrong (I think it unconditionally has a problem, it should never retry a cache refresh at that insane frequency), or the APT backend in PackageKit does something wrong and emits package changes for blocked packages when it shouldn't do so. I guess as soon as your system is up-to-date (with no blocked packages), this issue will go away temporarily. TBH, at this point I think there's probably a bug in GS as well as in PK-Apt, but we haven't found the culprit yet (except for the GS patch that caused this issue to appear, https://gitlab.gnome.org/GNOME/gnome-software/-/commit/b8cf52e9c001064eebfe86ce801541ca211e ) Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Bug#1065634: wv: /usr/share/doc wv is a dangling symlink
On Thu, Mar 07, 2024 at 08:00:34PM +0100, Sven Joachim wrote: > On 2024-03-07 18:49 +0100, Sven Joachim wrote: > > > Package: wv > > Version: 1.2.9-6.1 > > Severity: serious > > X-Debbugs-Cc: Sven Joachim , Steve Langasek > > > > > > After renaming the libwv-1.2-4 library package to libwv-1.2-4t64, the > > /usr/share/doc/wv symlink has become dangling. > > > > , > > | $ file /usr/share/doc/wv > > | /usr/share/doc/wv: broken symbolic link to libwv-1.2-4 > > ` > > > > It should point to libwv-1.2-4t64 instead, obviously. > > There is a similar broken symlink in the libwv-dev package (which > I do not have installed). The attached patch takes care of them. > Steve, would you like to upload that? Note that the package is > orphaned, therefore I have created a debian/changelog entry for a QA > upload rather than for another NMU. Thanks, uploaded. > diff -Nru wv-1.2.9/debian/changelog wv-1.2.9/debian/changelog > --- wv-1.2.9/debian/changelog 2024-02-29 06:47:50.0 +0100 > +++ wv-1.2.9/debian/changelog 2024-03-07 19:42:29.0 +0100 > @@ -1,3 +1,10 @@ > +wv (1.2.9-7) unstable; urgency=medium > + > + * QA upload. > + * Fix dangling /usr/share/doc symlinks (Closes: #1065634). > + > + -- Sven Joachim Thu, 07 Mar 2024 19:42:29 +0100 > + > wv (1.2.9-6.1) unstable; urgency=medium > >* Non-maintainer upload. > diff -Nru wv-1.2.9/debian/libwv-dev.links wv-1.2.9/debian/libwv-dev.links > --- wv-1.2.9/debian/libwv-dev.links 2023-09-17 23:45:41.0 +0200 > +++ wv-1.2.9/debian/libwv-dev.links 2024-03-07 19:41:38.0 +0100 > @@ -1 +1 @@ > -usr/share/doc/libwv-1.2-4 usr/share/doc/libwv-dev > +usr/share/doc/libwv-1.2-4t64 usr/share/doc/libwv-dev > diff -Nru wv-1.2.9/debian/wv.links wv-1.2.9/debian/wv.links > --- wv-1.2.9/debian/wv.links 2023-09-17 23:45:41.0 +0200 > +++ wv-1.2.9/debian/wv.links 2024-03-07 19:01:19.0 +0100 > @@ -1 +1 @@ > -usr/share/doc/libwv-1.2-4 usr/share/doc/wv > +usr/share/doc/libwv-1.2-4t64 usr/share/doc/wv -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session
Control: tags -1 upstream Control: forwarded -1 https://josm.openstreetmap.de/ticket/23540 This is a known issue since the update to 18969, the workaround is to add the OSM Carto layer first, and then add the Bing layer. As this is an upstream issue, you're encouraged to report it upstream directly: https://josm.openstreetmap.de/, it is not an issue that we can fix in the packaging. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1065696: Fwd: E: unsupported command: poweroff.no-molly-guard
Control: forcemerge 1059691 -1 On Fri, Mar 08, 2024 at 09:37:05PM -0800, Francois Marier wrote: > Hi Helmut, > > This looks like an unexpected edge case from the recent usr-merge changes: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065696 > > It sounds like a system using sysvinit, instead of systemd, which was > recently upgraded using usrmerge. Yes, I think this is a duplicate of #1059691. Could you give feedback on the contained patch? Helmut
Bug#1065072: packagekit spinning cpu
Joey Hess wrote: > It may also be relevant somehow that the topmost update was a thinkpad > AMD firmware update which "requires restart". I masked and stopped packagekit again and now in gnome-software, it displays only the thinkpad amd firmware update, and it's no longer alternating with the loading updates screen. This makes me think that firmware update is not related to the problem. The other updates gnome-software displays when packagekit is running are debian package updates. My last upgrade was an apt-get safe-upgrade, because dist-upgrade wants to remove several packages, including gnome. (I'm tracking unstable, this is typical transient dependency issues I suppose. Also I have bluez on hold at an older version due to #1060224) So maybe gnome-software gets confused in this kind of situation and keeps retrying? -- see shy jo signature.asc Description: PGP signature
Bug#1065701: rocm_agent_enumerator: crash on systems without AMD GPU
Package: rocminfo Version: 5.7.1-1 Severity: normal X-Debbugs-Cc: c...@slerp.xyz Dear Maintainer, On systems, the rocm_agent_enumerator command may crash with an error: Traceback (most recent call last): File "/usr/bin/rocm_agent_enumerator", line 260, in main() File "/usr/bin/rocm_agent_enumerator", line 244, in main target_list = readFromKFD() ^ File "/usr/bin/rocm_agent_enumerator", line 193, in readFromKFD for node in sorted(os.listdir(topology_dir)): FileNotFoundError: [Errno 2] No such file or directory: '/sys/class/kfd/kfd/topology/nodes/' It's not clear to me exactly why this error is emitted. Perhaps it's because the system does not have an AMD GPU at all. In that case, the expected output would be "gfx000\n". The purpose of rocm_agent_enumerator is to list all AMD GPUs on a system. If there are no AMD GPUs, then it should be an empty list. This behaviour can be seen in the rocm-hipamd autopkgtests [1]. While hipcc should probably not be calling rocm_agent_enumerator when the offload architecture has been manually specified, the rocm_agent_enumerator shouldn't be emiting any output on stderr. Sincerely, Cory Bloor [1]: https://ci.debian.net/data/autopkgtest/testing/amd64/r/rocm-hipamd/43752739/log.gz -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages rocminfo depends on: ii kmod31+20240202-2 ii libc6 2.37-15.1 ii libgcc-s1 14-20240303-1 ii libhsa-runtime64-1 5.7.1-1 ii libstdc++6 14-20240303-1 ii pciutils1:3.11.1-1 ii python3 3.11.8-1 rocminfo recommends no packages. rocminfo suggests no packages. -- no debconf information
Bug#1065072: packagekit spinning cpu
Below is a pkmon while the problem is occurring. Since it points at gnome-software causing the activity, I tried opening that. I noticed that the updates tab had an indicator that there were updates. Switching to it, I saw it continuously alternate between "Loading updates" with a spinner and a list of updates. Each transition back to "Loading updates" corresponds to more pkmon activity. It may also be relevant somehow that the topmost update was a thinkpad AMD firmware update which "requires restart". Transactions: [none] daemon connected=1 network status=online Transactions: 1 /15795_aacdccdd /15795_aacdccdd allow_cancel 1 /15795_aacdccdd percentage -1 /15795_aacdccdd role get-updates /15795_aacdccdd sender /usr/bin/gnome-software /15795_aacdccdd status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:25.371: GTask 0x556f0677f540 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15795_aacdccdd 2 /15796_cadeddaa /15796_cadeddaa allow_cancel 1 /15796_cadeddaa percentage -1 /15796_cadeddaa role get-updates /15796_cadeddaa sender /usr/bin/gnome-software /15796_cadeddaa status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:25.442: GTask 0x556f06783290 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15796_cadeddaa Transactions: [none] Transactions: 1 /15797_cbbadaab Transactions: 1 /15797_cbbadaab 2 /15798_ceeaaabb /15797_cbbadaab allow_cancel 1 /15797_cbbadaab percentage -1 /15797_cbbadaab role get-details /15797_cbbadaab sender /usr/bin/gnome-software /15797_cbbadaab status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:27.100: GTask 0x556f06783390 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. /15798_ceeaaabb allow_cancel 1 /15798_ceeaaabb percentage -1 /15798_ceeaaabb role get-updates /15798_ceeaaabb sender /usr/bin/gnome-software /15798_ceeaaabb status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:27.100: GTask 0x556f06784f30 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15798_ceeaaabb Transactions: [none] Transactions: 1 /15799_eebaebcb /15799_eebaebcb allow_cancel 1 /15799_eebaebcb percentage -1 /15799_eebaebcb role get-updates /15799_eebaebcb sender /usr/bin/gnome-software /15799_eebaebcb status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:31.374: GTask 0x556f06788660 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15799_eebaebcb 2 /15800_caeadeca /15800_caeadeca allow_cancel 1 /15800_caeadeca percentage -1 /15800_caeadeca role get-updates /15800_caeadeca sender /usr/bin/gnome-software /15800_caeadeca status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:31.448: GTask 0x556f06783f90 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15800_caeadeca Transactions: [none] Transactions: 1 /15801_dceaeeeb Transactions: 1 /15801_dceaeeeb 2 /15802_cbacedec /15801_dceaeeeb allow_cancel 1 /15801_dceaeeeb percentage -1 /15801_dceaeeeb role get-details /15801_dceaeeeb sender /usr/bin/gnome-software /15801_dceaeeeb status setup (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:33.169: GTask 0x556f0677ee00 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. /15802_cbacedec allow_cancel 1 /15802_cbacedec percentage -1 /15802_cbacedec role get-updates /15802_cbacedec sender /usr/bin/gnome-software /15802_cbacedec status wait (pkmon:3985472): GLib-GIO-CRITICAL **: 02:02:33.170: GTask 0x556f06788750 (source object: 0x556f0677c360, source tag: 0x7f08eae881c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /15802_cbacedec Transactions: [none] Transactions: 1 /15803_ecbdcdcd /15803_ecbdcdcd allow_cancel 1 /15803_ecbdcdcd percentage -1 /15803_ecbdcdcd role get-updates /15803_ecbdcdcd sender /usr/bin/gnome-software /15803_ecbdcdcd status setup (pkmon:3985472): GLib-GIO-CRITICAL **:
Bug#1065700: mysql-8.0: ftbfs with 64-bit time_t on 32-bit archs
Package: mysql-8.0
Version: 8.0.36-2
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear maintainers,
With the switch to 64-bit time_t on 32-bit archs, mysql-8.0 now fails to
build from source because of a test that *checks* that only 32-bit time is
supported:
[...]
[ 57%] main.func_unixtime_32bitsw4 [ fail ]
Test ended at 2024-03-09 05:01:27
CURRENT_TEST: main.func_unixtime_32bits
--- /<>/mysql-test/r/func_unixtime_32bits.result 2023-12-12
21:09:36.0 +0300
+++ /<>/builddir/mysql-test/var/4/log/func_unixtime_32bits.reject
2024-03-09 08:01:27.450443865 +0300
@@ -12,7 +12,7 @@
2038-01-19 06:14:07
select from_unixtime(2147483648);
from_unixtime(2147483648)
-NULL
+2038-01-19 06:14:08
select from_unixtime(0);
from_unixtime(0)
1970-01-01 03:00:00
@@ -32,26 +32,26 @@
2147483647
select unix_timestamp(from_unixtime(2147483648));
unix_timestamp(from_unixtime(2147483648))
-NULL
+2147483648
[...]
- the logfile can be found in
'/<>/builddir/mysql-test/var/log/main.func_unixtime_32bits/func_unixtime_32bits.log'
Test main.func_unixtime_32bits has failed 2 times, no more retries.
[...]
(https://launchpad.net/ubuntu/+source/mysql-8.0/8.0.36-2/+build/27892969)
Please find attached a patch for this issue which I have uploaded to Ubuntu.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru mysql-8.0-8.0.36/debian/patches/64bit_time_everywhere.patch
mysql-8.0-8.0.36/debian/patches/64bit_time_everywhere.patch
--- mysql-8.0-8.0.36/debian/patches/64bit_time_everywhere.patch 1969-12-31
16:00:00.0 -0800
+++ mysql-8.0-8.0.36/debian/patches/64bit_time_everywhere.patch 2024-03-08
21:59:20.0 -0800
@@ -0,0 +1,22 @@
+Description: fix test for 64-bit time_t
+ i386 is the only architecture where we don't have 64-bit time_t now.
+ Update the tests accordingly.
+Author: Steve Langasek
+Forwarded: no
+Last-Update: 2024-03-08
+
+Index: mysql-8.0-8.0.36/mysql-test/include/have_32bits_time.inc
+===
+--- mysql-8.0-8.0.36.orig/mysql-test/include/have_32bits_time.inc
mysql-8.0-8.0.36/mysql-test/include/have_32bits_time.inc
+@@ -1,8 +1,7 @@
+ # see also have_64bits_time.inc
+
+-let $have_64bit = `SELECT @@version_compile_machine IN
+- ('x86_64', 'amd64', 'sparc', 'sparc64', 'arm64',
'aarch64',
+- 'ppc64', 'ppc64le', 's390x')`;
++let $have_64bit = `SELECT @@version_compile_machine != 'i686'`;
++
+ if ($have_64bit) {
+ --skip Doesn't support 32 bits UNIX time, only 64 bits
+ }
diff -Nru mysql-8.0-8.0.36/debian/patches/series
mysql-8.0-8.0.36/debian/patches/series
--- mysql-8.0-8.0.36/debian/patches/series 2024-03-05 06:26:25.0
-0800
+++ mysql-8.0-8.0.36/debian/patches/series 2024-03-08 21:55:11.0
-0800
@@ -9,3 +9,4 @@
disable_timestamping_test.patch
mysql_secure_installation-remove-root-pw-creation.patch
suppress_armhf_test_warning.patch
+64bit_time_everywhere.patch
Bug#1065699: ITP: hyprpaper -- Wallpaper utility for Hyprland
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-de...@lists.debian.org, a...@digistorm.in * Package name: hyprpaper Version : 0.6.0 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/hyprpaper * License : BSD-3-Clause Programming Lang: C++ Description : Wallpaper utility for Hyprland Hyprpaper is a blazing fast wallpaper utility for Hyprland (or any wlroots-based compositors) with the ability to dynamically change wallpapers through sockets. This program is suggested by Hyprland[1][2] and is created by the same team. [1] https://github.com/hyprwm/Hyprland [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971
Bug#1065696: Fwd: E: unsupported command: poweroff.no-molly-guard
Hi Helmut, This looks like an unexpected edge case from the recent usr-merge changes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065696 It sounds like a system using sysvinit, instead of systemd, which was recently upgraded using usrmerge. Francois -- https://fmarier.org/
Bug#1065072: packagekit spinning cpu
Hi! Am Sa., 9. März 2024 um 04:09 Uhr schrieb Joey Hess : > > I'm confident I saw this same problem today, with packagekit repeatedly > updating and spinning a CPU for 10 minutes. It only stopped at that > point because I stopped and masked it. (Stopping it was not enough, > something was restarting the service every time I stopped it.) See > attached log. > > I did not capture the trigger for that pkmon, but just before it started I > had used window+s in gnome and typed in "paperwm", before remembering that > doesn't find anything and pressing escape. > > When I repeat that with pkmon open, I see it does trigger packagekit: > > root@darkstar:/home/joey>pkmon > Transactions: > [none] > daemon connected=1 > network status=online > Transactions: > 1 /14317_cdeeebeb > /14317_cdeeebeb allow_cancel 1 > /14317_cdeeebeb percentage -1 > /14317_cdeeebeb role resolve > /14317_cdeeebeb sender /usr/bin/gnome-software > /14317_cdeeebeb status setup Unfortunately there isn't much we can do - this is GNOME Software polling PackageKit again and again, and other than adding more rate limitations, we can't fix that in PK and PK is behaving correctly. The real solution would be to make the tool that is causing this stop its behavior and not ask PackageKit to update the cache every second. I reassigned it to GS, which already had a bug describing this issue exactly. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Bug#1013361: ITP: ruptime -- poor man's ruptime
> On Mar 9, 2024, at 06:09, Petter Reinholdtsen wrote: > > [Gürkan Myczko 2022-10-26] >> ruptime/ruptimed has ben released long ago under the AGPL-3.0 >> >> there's no reason for it to go into non-free, it's software for main > > What is the background for the licensing confusion? I was not sure what license to take, but that has been settled client and server are free software to be selfhosted. > The original ruptime had serious security problems. The original not from me? It had no security problems it was just transferring data clear text, but was also only limited to local network. Usually your network is trusted. Well.. YMMV > It is unclear from > the upstream README how this is solved in this new version. Can you > explain how this new system is kept secure and avoid privacy problems? My versions always have been secure. All Debian packages uploaded to ftp-master did NOT suffer privacy problems as they patched upstream tarball setting SERVER=localhost This software is meant to be selfhosted. You can find the latest version on salsa.debian.org by searching ruptime. > I notice the package has been in NEW for 10 months already. Is there a > git repo with the draft packaging for this package? Yes, and packages are available at github downloads (debian amd64 and arm64) You can also find it installed on http://bananas.debian.net (contact me for account) and its upcoming web interface http://bananas.debian.net/ruptime Best, Alex > > -- > Happy hacking > Petter Reinholdtsen
Bug#1013361: ITP: ruptime -- poor man's ruptime
[Gürkan Myczko 2022-10-26] > ruptime/ruptimed has ben released long ago under the AGPL-3.0 > > there's no reason for it to go into non-free, it's software for main What is the background for the licensing confusion? The original ruptime had serious security problems. It is unclear from the upstream README how this is solved in this new version. Can you explain how this new system is kept secure and avoid privacy problems? I notice the package has been in NEW for 10 months already. Is there a git repo with the draft packaging for this package? -- Happy hacking Petter Reinholdtsen
Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'
On Fri, Mar 08, 2024 at 08:04:59PM -0800, Ryan Tandy wrote: > > This does fix the build failure. I was about to push such a change to the > > repo and do a maintainer upload, since I've never been removed from the > > uploaders field after all these years ;) Do you want me to do this, or > > would you be able to do it tonight? Getting openldap to build is a priority > > wrt rebootstrapping 32-bit archs for time_t. > I wasn't sure where openldap was on the priority list for arm* since it's > still BD-Uninstallable on the buildds. Yes, it's BD-Uninstallable there because it needs manually built to address build loops (ldap->cyrus-sasl2->krb5). > Yes, I can upload it tonight, in a couple of hours from now. Is that OK? Works for me! > > WARNING! > > Running as root! > > There's a fair chance slapd will fail to start. > > Check file permissions! > > > > Starting slapd on TCP/IP port 9011... > > Testing slapd searching... > > Creating a dynamic entry... > > ldapadd failed (255)! > > ../../../tests/scripts/test046-dds: 93: kill: No such process > > > > > > > > > test046-dds failed for mdb after 2 seconds > > (exit 255) > > make[4]: *** [Makefile:303: mdb-mod] Error 255 > I have not seen this failure. Ran it again just now and it passed. But I > only run amd64... I wouldn't be able to dig into that tonight, even if I > could reproduce it. Do you think I should disable the test proactively? Rather than disabling the test in the package, I can do a DEB_BUILD_OPTIONS=nocheck build to help get things bootstrapped in the archive. I'm interested to know if it also shows up on hppa, since that would definitely point to it being time_t related. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1065698: update-initramfs: -k all stopped working
Package: initramfs-tools Version: 0.142 The update-initramfs manpage documents -k all, and I know I used that in Kubuntu hardy times several times, but it does not work any longer, it just does nothing. Calling without -k of course only updates the image for the current kernel. Feel free to downgrade severity if needed. -- Package-specific info: -- initramfs sizes -rw-r--r-- 2 root root 7.4M Mar 9 00:27 /boot/initrd.img-4.19.0-4-m68k -rw-r--r-- 1 root root 5.3M Mar 9 04:21 /boot/initrd.img-6.6.15-m68k -- /proc/cmdline root=/dev/nfhd8p1 console=nfcon devtmpfs.mount=1 BOOT_IMAGE=vmlinux -- resume RESUME=none -- /proc/filesystems fuseblk ext3 ext2 ext4 -- lsmod Module Size Used by evdev 16384 0 mac_hid12288 0 sg 20480 0 ext4 380928 1 crc16 12288 1 ext4 mbcache12288 1 ext4 jbd2 49152 1 ext4 crc32c_generic 12288 1 sd_mod 45056 0 t10_pi 12288 1 sd_mod crc64_rocksoft 12288 1 t10_pi crc64 16384 1 crc64_rocksoft crc_t10dif 12288 1 t10_pi crct10dif_generic 12288 1 crct10dif_common 12288 2 crct10dif_generic,crc_t10dif pata_falcon12288 0 atari_scsi 20480 0 libata139264 1 pata_falcon -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf # Kernel Image management overrides # See kernel-img.conf(5) for details do_symlinks = No -- /etc/initramfs-tools/initramfs.conf MODULES=dep BUSYBOX=auto KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto RUNSIZE=10% FSTYPE=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- /sys/block nfhd8 sda -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: early-rng-init-tools fsck keymap klibc-utils kmod resume thermal udev zz-busybox -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 6.6.15-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.142 ii linux-base4.5 initramfs-tools recommends no packages. Versions of packages initramfs-tools suggests: pn bash-completion -- no debconf information
Bug#1065697: trash-cli causes irresponsive system from 100% cpu load
Package: trash-cli Version: 0.17.1.14-5 Severity: important Issue description: Sending files to trash using trash-cli causes system to stall and renders it irresponsive, if original filename of the file to be trashed exceeds a particular length. Happened with some files downloaded from a website, which have been cut by the browser automatically to match the file name length restrictions of the file system (ext4). Some testing turned out trash-cli tries obviously to append something to the filename, what clearly must fail if filename already has the max. length allowed. Depending of the character set used, and depending whether special characters are involved, different length of names causes trouble in trash-cli. Steps to reproduce: touch files named precisely as follows, make sure to use the full line. (These are testing names merely for reproducing the issue) touch 'АБВГДЕЁЖЗИЙКЛМНОПРЦТУФХЦШЩЪЫЬЭЮЯабвгдеёжзийклмнопрстуфхцшщъыьэюяАБВГДЕЁЖЗИЙКЛМНОПРЦТУФХЦШЩЪЫЬЭЮЯабвгдеёжзийклмнопрстуфхцшщъыьэю' touch '123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345' These test file names are accepted by default ext4 file systems. In case you have a different max allowed file name length on your ext4 file system make sure the names of the files to be trashed have the maximal length allowed or some few characters less. Please note that the issue in a foreign character set (in the example this is Cyrillic, arbitrary choosen) the issue already present in half file name length as in English. Now trash them using the default trash command provided by this package. This will cause the system to stall with 100% CPU load and no longer respond to any input. Single way out seems to be a hard reset. (This might be depending on your hardware, on multi-core sytems this might only cause one of the cores to stall, so the system stays responsive in this case) Expected behaviour: Trash cli should not stall the system when trashing one or more files thats filename has the max. length allowed by the file system. Proposal for solution: _Replace_ the end of the filename in these cases rather than appending something, so the limit for file name length of the file system is observed by trash-cli. trash-cli Version: $ apt-cache policy trash-cli trash-cli: Installiert: 0.17.1.14-5 Installationskandidat: 0.17.1.14-5 Versionstabelle: *** 0.17.1.14-5 500 500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages 500 http://ftp.de.debian.org/debian bookworm/main i386 Packages 100 /var/lib/dpkg/status System: antiX 23.1 runit full 64 bit $ uname -r 6.1.60-antix.1-amd64-smp $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 12 (bookworm) Release:12 Codename: bookworm
Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'
On Fri, Mar 08, 2024 at 07:33:59PM -0800, Steve Langasek wrote: This bug is also reproducible on the armel and armhf release archs as a result of the time_t transition, so bumping this to serious. ACK. This does fix the build failure. I was about to push such a change to the repo and do a maintainer upload, since I've never been removed from the uploaders field after all these years ;) Do you want me to do this, or would you be able to do it tonight? Getting openldap to build is a priority wrt rebootstrapping 32-bit archs for time_t. I wasn't sure where openldap was on the priority list for arm* since it's still BD-Uninstallable on the buildds. Yes, I can upload it tonight, in a couple of hours from now. Is that OK? BTW there's also a reproducible test failure that I'm seeing on armhf in both Debian and Ubuntu which is new; I'm not sure if it's related to time_t, or if it affects other archs? Starting test046-dds for mdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... WARNING! Running as root! There's a fair chance slapd will fail to start. Check file permissions! Starting slapd on TCP/IP port 9011... Testing slapd searching... Creating a dynamic entry... ldapadd failed (255)! ../../../tests/scripts/test046-dds: 93: kill: No such process test046-dds failed for mdb after 2 seconds (exit 255) make[4]: *** [Makefile:303: mdb-mod] Error 255 I have not seen this failure. Ran it again just now and it passed. But I only run amd64... I wouldn't be able to dig into that tonight, even if I could reproduce it. Do you think I should disable the test proactively? thanks, Ryan
Bug#1065696: E: unsupported command: poweroff.no-molly-guard
Package: molly-guard Version: 0.8.3 Severity: grave Justification: renders package unusable Severity chosen both because this makes the package unusable (I will have to remove it now) and because it breaks the whole system (boot). root@aranym:/var/cache/apt/archives # poweroff W: molly-guard: SSH session detected! Please type in hostname of the machine to poweroff: aranym E: unsupported command: poweroff.no-molly-guard 1|root@aranym:/var/cache/apt/archives # which poweroff.no-molly-guard /usr/sbin/poweroff.no-molly-guard root@aranym:/var/cache/apt/archives # dpkg -S /usr/sbin/poweroff.no-molly-guard diversion by molly-guard from: /usr/sbin/poweroff diversion by molly-guard to: /usr/sbin/poweroff.no-molly-guard root@aranym:/var/cache/apt/archives # dpkg -S /usr/sbin/poweroff diversion by molly-guard from: /usr/sbin/poweroff diversion by molly-guard to: /usr/sbin/poweroff.no-molly-guard molly-guard, sysvinit-core: /usr/sbin/poweroff At this point, I thought this was somehow a bug in sysvinit-core, but… root@aranym:/var/cache/apt/archives # ll /usr/sbin/poweroff* lrwxrwxrwx 1 root root 30 Dec 22 22:23 /usr/sbin/poweroff -> ../lib/molly-guard/molly-guard* lrwxrwxrwx 1 root root 4 Feb 29 11:22 /usr/sbin/poweroff.no-molly-guard -> halt* root@aranym:/var/cache/apt/archives # less /usr/sbin/poweroff.no-molly-guard #!/bin/sh # # shutdown -- wrapper script to guard against accidental shutdowns […] ME=molly-guard […] … this shows pretty clearly who’s at fault here. The system was just converted to UsrMove in order to be able to install a newer kernel for upgrading. -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 4.19.0-4-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages molly-guard depends on: ii procps 2:3.3.15-2 molly-guard recommends no packages. molly-guard suggests no packages. -- no debconf information
Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'
Control: severity -1 serious Hi Ryan, This bug is also reproducible on the armel and armhf release archs as a result of the time_t transition, so bumping this to serious. On Fri, Mar 08, 2024 at 06:04:45PM -0800, Ryan Tandy wrote: > Would you be willing to test build the attached patch on hppa? I've tested > it on amd64 with -Werror=implicit-function-declaration appended. > From fa0b704371762bdc479a5d8dc6a0a6df4ec3a52e Mon Sep 17 00:00:00 2001 > From: Ryan Tandy > Date: Fri, 8 Mar 2024 17:58:15 -0800 > Subject: [PATCH] Fix implicit declaration of kadm5_s_init_with_password_ctx > > --- > debian/patches/series| 1 + > debian/patches/smbk5pwd-implicit-declaration | 12 > 2 files changed, 13 insertions(+) > create mode 100644 debian/patches/smbk5pwd-implicit-declaration > > diff --git a/debian/patches/series b/debian/patches/series > index a8d57cb99c..7381d0a06b 100644 > --- a/debian/patches/series > +++ b/debian/patches/series > @@ -13,3 +13,4 @@ add-tlscacert-option-to-ldap-conf > fix-build-top-mk > switch-to-lt_dlopenadvise-to-get-RTLD_GLOBAL-set.diff > set-maintainer-name > +smbk5pwd-implicit-declaration > diff --git a/debian/patches/smbk5pwd-implicit-declaration > b/debian/patches/smbk5pwd-implicit-declaration > new file mode 100644 > index 00..a704086286 > --- /dev/null > +++ b/debian/patches/smbk5pwd-implicit-declaration > @@ -0,0 +1,12 @@ > +Description: Fix implicit declaration of kadm5_s_init_with_password_ctx > +Bug-Debian: https://bugs.debian.org/1065633 > +--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c > +@@ -45,6 +45,7 @@ > + #include > + #include > + #include > ++#include > + > + #ifndef HDB_INTERFACE_VERSION > + #define HDB_MASTER_KEY_SET master_key_set > -- > 2.39.2 This does fix the build failure. I was about to push such a change to the repo and do a maintainer upload, since I've never been removed from the uploaders field after all these years ;) Do you want me to do this, or would you be able to do it tonight? Getting openldap to build is a priority wrt rebootstrapping 32-bit archs for time_t. BTW there's also a reproducible test failure that I'm seeing on armhf in both Debian and Ubuntu which is new; I'm not sure if it's related to time_t, or if it affects other archs? > Starting test046-dds for mdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... WARNING! Running as root! There's a fair chance slapd will fail to start. Check file permissions! Starting slapd on TCP/IP port 9011... Testing slapd searching... Creating a dynamic entry... ldapadd failed (255)! ../../../tests/scripts/test046-dds: 93: kill: No such process > test046-dds failed for mdb after 2 seconds (exit 255) make[4]: *** [Makefile:303: mdb-mod] Error 255 In Ubuntu we disabled the tests on armhf to not hold up the bootstrap. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#974924: Plasma 5.19.5.x: Emojis in black and white ( not color and not displayed correctly)
I've recently started seeing this $ fc-match -s emoji Symbola_hint.ttf: "Symbola" "Regular" DejaVuSans.ttf: "DejaVu Sans" "Book" DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique" DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique" NimbusSans-Regular.otf: "Nimbus Sans" "Regular" opens___.ttf: "OpenSymbol" "Regular" DejaVuMathTeXGyre.ttf: "DejaVu Math TeX Gyre" "Regular" DejaVuSerif.ttf: "DejaVu Serif" "Book" LiberationMono-Regular.ttf: "Liberation Mono" "Regular" LiberationSerif-Regular.ttf: "Liberation Serif" "Regular" Lato-Regular.ttf: "Lato" "Regular" NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular" D05L.otf: "D05L" "Regular" DroidSansFallbackFull.ttf: "Droid Sans Fallback" "Regular" StandardSymbolsPS.pfb: "Standard Symbols PS" "Regular" DejaVuSerif-Italic.ttf: "DejaVu Serif" "Italic" LiberationSerif-Italic.ttf: "Liberation Serif" "Italic" Interestingly I don't see NotoColorEmoji.ttf in that list even though I have the package installed $ apt-cache show fonts-noto-color-emoji Package: fonts-noto-color-emoji Version: 2.042-1 Installed-Size: 10455 Maintainer: Debian Fonts Task Force Architecture: all Description-en: color emoji font from Google Noto is a collection of font families, each visually harmonized across scripts. . The name "Noto" is short for "No Tofu", describing the aim of covering all living Unicode scripts. . Tofu (豆腐) is Japanese jargon for unicode replacement character "�" (U+FFFD) often displayed as replacement for unassigned or unknown characters. . This package contains the color emoji font used on "stock" Android devices such as the Google Pixel. Description-md5: a9719702f7fba976902bc66487dd558b Multi-Arch: foreign Homepage: https://fonts.google.com/noto/specimen/Noto+Color+Emoji Section: fonts Priority: optional Filename: pool/main/f/fonts-noto-color-emoji/fonts-noto-color-emoji_2.042-1_all.deb Size: 9626580 MD5sum: c35046d526cd6f8c3ead08bf6f2077ec SHA256: 8bac9ea54e9a2781d488571d0ee78cec101ad899e78473b78f575a61529e8ac4
Bug#1065072: packagekit spinning cpu
I'm confident I saw this same problem today, with packagekit repeatedly updating and spinning a CPU for 10 minutes. It only stopped at that point because I stopped and masked it. (Stopping it was not enough, something was restarting the service every time I stopped it.) See attached log. I did not capture the trigger for that pkmon, but just before it started I had used window+s in gnome and typed in "paperwm", before remembering that doesn't find anything and pressing escape. When I repeat that with pkmon open, I see it does trigger packagekit: root@darkstar:/home/joey>pkmon Transactions: [none] daemon connected=1 network status=online Transactions: 1 /14317_cdeeebeb /14317_cdeeebeb allow_cancel 1 /14317_cdeeebeb percentage -1 /14317_cdeeebeb role resolve /14317_cdeeebeb sender /usr/bin/gnome-software /14317_cdeeebeb status setup (pkmon:3940508): GLib-GIO-CRITICAL **: 22:40:26.794: GTask 0x5621e2846510 (source object: 0x5621e2843330, source tag: 0x7fc2bdc121c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: [none] I found similar bug reports filed on fedora, upstream, etc. Going back years. Also looking back through the journal, it's been doing this on my system for months, every week or two, generally with only a few minutes cpu time wasted per indicent. Also, I notice that when packagekit is masked, it makes apt-get update display a message to that effect. Since this bug makes masking packagekit very appealing, that is not very nice either. -- see shy jo log.gz Description: application/gzip signature.asc Description: PGP signature
Bug#1064338: Bug1064338, RFS: ukui-search/4.0.6.1-1 has be done with no change
Hi. I saw the bug has been done on debian track system. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064338 I haven't seen the package in new package list, and the new package is still in mentors: https://mentors.debian.net/package/ukui-search/ May I ask why the bug has been done? Is there any problem in this package?
Bug#1065633: openldap: FTBFS on hppa - implicit declaration of function 'kadm5_s_init_with_password_ctx'
Would you be willing to test build the attached patch on hppa? I've tested it on amd64 with -Werror=implicit-function-declaration appended. thanks, Ryan >From fa0b704371762bdc479a5d8dc6a0a6df4ec3a52e Mon Sep 17 00:00:00 2001 From: Ryan Tandy Date: Fri, 8 Mar 2024 17:58:15 -0800 Subject: [PATCH] Fix implicit declaration of kadm5_s_init_with_password_ctx --- debian/patches/series| 1 + debian/patches/smbk5pwd-implicit-declaration | 12 2 files changed, 13 insertions(+) create mode 100644 debian/patches/smbk5pwd-implicit-declaration diff --git a/debian/patches/series b/debian/patches/series index a8d57cb99c..7381d0a06b 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -13,3 +13,4 @@ add-tlscacert-option-to-ldap-conf fix-build-top-mk switch-to-lt_dlopenadvise-to-get-RTLD_GLOBAL-set.diff set-maintainer-name +smbk5pwd-implicit-declaration diff --git a/debian/patches/smbk5pwd-implicit-declaration b/debian/patches/smbk5pwd-implicit-declaration new file mode 100644 index 00..a704086286 --- /dev/null +++ b/debian/patches/smbk5pwd-implicit-declaration @@ -0,0 +1,12 @@ +Description: Fix implicit declaration of kadm5_s_init_with_password_ctx +Bug-Debian: https://bugs.debian.org/1065633 +--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c +@@ -45,6 +45,7 @@ + #include + #include + #include ++#include + + #ifndef HDB_INTERFACE_VERSION + #define HDB_MASTER_KEY_SET master_key_set -- 2.39.2
Bug#1063653: Acknowledgement (anope: Please ship new upstream version)
Thanks for the reply. This is just a friendly reminder in case you forgot. IRC software tends to get left behind and not enough eyes on it. I like to occasionally poke maintainers to keep the minor versions updated in unstable/testing so these minor version updates that fix bugs and security issues can become candidates in point releases during the Debian version. Anope has drifted behind on Debian and upstream has fixed quite a lot of bugs including some more concerning ones like race conditions. No breaking changes from upstream, just bug fixes. Thanks again, Victor Coss On 3/4/2024 3:15 PM, Dominic Hargreaves wrote: On Mon, Feb 26, 2024 at 07:56:42PM -0500, Victor Coss wrote: Now the latest version is 2.0.15 which includes even more bug fixes including a more concerning race condition. https://www.anope.org/news/2024/anope-2015-release.html Would greatly appreciate it if you can package the updated version. Thanks for letting me know. I have been short on time in recent weeks due to other commitments. I will try and look at this this week, all being well. If any Debian contributor would like to upload a new version, that's also fine with me! Cheers Dominic
Bug#1065695: libhsa-runtime-dev: endianness detection in fails on arm64 and ppc64el
Package: libhsa-runtime-dev Version: 5.7.1-1 Severity: normal X-Debbugs-Cc: c...@slerp.xyz Dear Maintainer, The endianness detection logic in hsa/hsa.h fails on arm64 and ppc64el, which leads to build failures in rccl on those platforms [1]. The current logic is: // Try to detect CPU endianness #if !defined(LITTLEENDIAN_CPU) && !defined(BIGENDIAN_CPU) #if defined(__i386__) || defined(__x86_64__) || defined(_M_IX86) || \ defined(_M_X64) #define LITTLEENDIAN_CPU #endif #endif This code should probably check if __BYTE_ORDER__ is defined, and if its value is __ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__ before giving up. Sincerely, Cory Bloor [1]: https://buildd.debian.org/status/fetch.php?pkg=rccl=ppc64el=5.4.3-2%7Eexp1=1709357300=0 -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages libhsa-runtime-dev depends on: ii libhsa-runtime64-1 5.7.1-1 libhsa-runtime-dev recommends no packages. libhsa-runtime-dev suggests no packages. -- no debconf information
Bug#1020648: extrepo-data: reproducible builds: "testing" suite resolves differently depending on build date
On 3/8/24 13:20, Wouter Verhelst wrote: I have not yet considered whether we want to provide common updates to stable. Perhaps I should talk to the SRMs about that... If you missed it, I have just opened a thread in debian-release@l.d.o about it. Please join the discussion. Looking at the source of Debian::DistroInfo, there does not currently appear to be a way to ask for information at a given date, but that sounds like a reasonable wishlist for Debian::DistroInfo to provide. Once that's available, updating extrpo-offline-data to use that to build on a source epoch in the past seems like a reasonable course of action to fix this bug. Yes, this sounds like that a better way to fix the issue overall! Indeed. Agreed. Thomas Goirand (zigo)
Bug#1065597: racket: Inclusion of mzdyn.o in the binary package
Rafael Laboissière writes: > At any rate, I wonder why the following mzscheme code: > > (begin > (require dynext/link) > (with-handlers >(((lambda args #t) (lambda args #f))) >(for-each (lambda (x) (printf "~a" x)) > (expand-for-link-variant > (current-standard-link-libraries) > I'm not sure what will come of it, but I have reported this issue as https://github.com/racket/cext-lib/issues/4 I haven't marked this Debian bug as forwarded as I believe they are different bugs.
Bug#1065694: O: kyotocabinet -- Straightforward implementation of DBM
Package: wnpp Control: affects -1 + src:kyotocabinet X-Debbugs-Cc: kyotocabi...@packages.debian.org Severity: normal I intend to orphan the kyotocabinet package. The development of upstream project is almost stalled, and a successor project (tkrzw) is now available. I expect future maintenance needs to be minimal. The package description is: Kyoto Cabinet is a library of routines for managing a database. The database is a simple data file containing records, each is a pair of a key and a value. Every key and value is serial bytes with variable length. Both binary data and character string can be used as a key and a value. Each key must be unique within a database. There is neither concept of data tables nor data types. Records are organized in hash table or B+ tree. . Kyoto Cabinet runs very fast. For example, elapsed time to store one million records is 0.9 seconds for hash database, and 1.1 seconds for B+ tree database. Moreover, the size of database is very small. For example, overhead for a record is 16 bytes for hash database, and 4 bytes for B+ tree database. Furthermore, scalability of Kyoto Cabinet is great. The database size can be up to 8EB (9.22e18 bytes). . Sponsored by the same company, Kyoto Cabinet is "[a] more powerful and convenient library than Tokyo Cabinet [and] surpasses Tokyo Cabinet in every aspect". Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1065693: O: abr2gbr -- Converts PhotoShop brushes to GIMP
Package: wnpp Control: affects -1 + src:abr2gbr X-Debbugs-Cc: abr2...@packages.debian.org Severity: normal I intend to orphan the abr2gbr package since I no longer use it. The package description is: abr2gbr is a tool for converting Adobe PhotoShop ABR and Corel Paint Shop Pro JBR brush files to the GIMP GBR format. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1065692: NMU: 9.1-0.1
Package: frr Version: 9.1-0.1 Severity: normal Hi, please find the diff of the NMU from 8.4.4-1.1 to 9.1-0.1 as patch attached. I noticed that frr could do with some more packaging love, I'd be happy to help out if you need/want any. Regards, Daniel frr_9.1-0.1.patch.gz Description: application/gzip
Bug#1006295: zbar-tools fails to build from source
notfound 1006295 zbar/0.23.90-1 close 1006295 thanks Hi, On Tue, 22 Feb 2022 22:48:38 +0100 Rainer Dorsch wrote: > Package: zbar-tools > Version: 0.23.90-1 > Severity: normal > Tags: ftbfs > > Dear Maintainer, > > I did > > 865 apt-get source zbar-tools > 866 sudo apt-get build-dep zbar-tools > 867 cd zbar-0.23.92/ > 868 dpkg-buildpackage -uc -us > > and ended in > > make[5]: Leaving directory '/home/rd/tmp.nobackup/Debian/zbar-0.23.92' > make[4]: Leaving directory '/home/rd/tmp.nobackup/Debian/zbar-0.23.92' > make[3]: Leaving directory '/home/rd/tmp.nobackup/Debian/zbar-0.23.92' > make[2]: Leaving directory '/home/rd/tmp.nobackup/Debian/zbar-0.23.92' > make[1]: Leaving directory '/home/rd/tmp.nobackup/Debian/zbar-0.23.92' > dh_install > dh_install: warning: Cannot find (any matches for) "usr/lib/*/perl5/*" (tried > in ., debian/tmp) > > dh_install: warning: libbarcode-zbar-perl missing files: usr/lib/*/perl5/* > dh_install: warning: Cannot find (any matches for) > "usr/share/man/man3/Barcode*" (tried in ., debian/tmp) > > dh_install: warning: libbarcode-zbar-perl missing files: > usr/share/man/man3/Barcode* > install -d debian/.debhelper/generated/libbarcode-zbar-perl > install -d debian/.debhelper/generated/libzbar-dev > install -d debian/.debhelper/generated/libzbar0 > install -d debian/.debhelper/generated/libzbargtk-dev > install -d debian/.debhelper/generated/libzbargtk0 > install -d debian/.debhelper/generated/libzbarqt-dev > install -d debian/.debhelper/generated/libzbarqt0 > install -d debian/.debhelper/generated/python3-zbar > install -d debian/.debhelper/generated/zbar-tools > install -d debian/.debhelper/generated/zbarcam-gtk > install -d debian/.debhelper/generated/zbarcam-qt > dh_install: error: missing files, aborting > make: *** [debian/rules:35: binary] Error 255 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > > Please let me know if I made a mistake, but I built many packages like > this before. As the package build is not using Debian's official toolchain (sbuild). I don't have enough time to sort out the exact cause. As a result, I am closing this bug report for now. If you cannot build the package with clean chroot under sbuild/schroot toolchain, please make a separate bug report. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1065691: O: zbar -- QR code / bar code scanner and decoder
Package: wnpp Control: affects -1 + src:zbar X-Debbugs-Cc: z...@packages.debian.org Severity: normal I intend to orphan the zbar package since I don't have enough time on package maintenance. The package description is: ZBar is a library for scanning and decoding bar codes from various sources such as video streams, image files or raw intensity sensors. It supports EAN-13/UPC-A, UPC-E, EAN-8, Code 128, Code 39, Interleaved 2 of 5 and QR Code. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1065690: lldpd: Does not pick correct IP or hostname
The IP address is a global information of the system (so, the same IP address is advertised for all interfaces). The hostname is the result of "getent host $(uname -n)". On 2024-03-09 00:12, Witold Baryluk wrote: Package: lldpd Version: 1.0.18-1 Severity: normal X-Debbugs-Cc: witold.bary...@gmail.com It sends correct IPv6, but IPv4 and hostname are wrong. user@debian:~$ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp7s0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 10:00:00:0d:b0:00 brd ff:ff:ff:ff:ff:ff 3: enp8s0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 10:00:00:00:b0:00 brd ff:ff:ff:ff:ff:ff 8: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:00:00:00:00:90 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 23: enp10s0f0np0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 64:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff 24: enp10s0f1np1: mtu 9000 qdisc fq_pie state UP group default qlen 1000 link/ether 64:00:00:00:00:02 brd ff:ff:ff:ff:ff:ff inet 10.0.0.18/24 brd 10.0.0.255 scope global dynamic noprefixroute enp10s0f1np1 valid_lft 85650sec preferred_lft 85650sec inet6 fe80::0002/64 scope link noprefixroute valid_lft forever preferred_lft forever What I see on the switch (MikroTik RouterOS 7.15beta6, on hw model CRS504-4XQ-IN) connected to directly to enp10s0f1np1: Interface qsfp28-4-1# correct IP Address 172.17.0.1# incorrect IPv6 Addressfe80::0002# correct MAC Address 64:00:00:00:00:02 # correct Identitylocalhost # incorrect Platform Version Board Name Interface Name enp10s0f1np1 # incorrect Regards, Witold
Bug#1065690: lldpd: Does not pick correct IP or hostname
Package: lldpd Version: 1.0.18-1 Severity: normal X-Debbugs-Cc: witold.bary...@gmail.com It sends correct IPv6, but IPv4 and hostname are wrong. user@debian:~$ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp7s0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 10:00:00:0d:b0:00 brd ff:ff:ff:ff:ff:ff 3: enp8s0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 10:00:00:00:b0:00 brd ff:ff:ff:ff:ff:ff 8: docker0: mtu 1500 qdisc noqueue state DOWN group default link/ether 02:00:00:00:00:90 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 23: enp10s0f0np0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 64:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff 24: enp10s0f1np1: mtu 9000 qdisc fq_pie state UP group default qlen 1000 link/ether 64:00:00:00:00:02 brd ff:ff:ff:ff:ff:ff inet 10.0.0.18/24 brd 10.0.0.255 scope global dynamic noprefixroute enp10s0f1np1 valid_lft 85650sec preferred_lft 85650sec inet6 fe80::0002/64 scope link noprefixroute valid_lft forever preferred_lft forever What I see on the switch (MikroTik RouterOS 7.15beta6, on hw model CRS504-4XQ-IN) connected to directly to enp10s0f1np1: Interface qsfp28-4-1# correct IP Address 172.17.0.1# incorrect IPv6 Addressfe80::0002# correct MAC Address 64:00:00:00:00:02 # correct Identitylocalhost # incorrect Platform Version Board Name Interface Name enp10s0f1np1 # incorrect Regards, Witold
Bug#1034311: reprotest: make it easier to compare against an existing build (eg from ftp.d.o)
On 2023-04-12, Holger Levsen wrote: > i guess reprotest maybe should grow an option to do > --control-build /path/to/packages/ > --vary=build_path=/use/this/build/path ... >to make it easier to use reprotest to compare against an existing > build >YES > e.g. there is no way to disable buidl path variations when > comparing > against an arbitrary build >i'm reporting this as a bug to the bts, quoting your words here. > (ok?) > reprotest can control it's own builds ... but if i want to use > reprotest >against the archive packages or an sbuild >or pbuilder build package ... it will always have a different > build path Forgot about this bug, but I have since implemented a proof-of-concept of this: https://salsa.debian.org/reproducible-builds/reprotest/-/commits/wip-specify-build-path?ref_type=heads :) live well, vagrant signature.asc Description: PGP signature
Bug#1065689: nmu: freetype_2.13.2+dfsg-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Please binnmu freetype on armel & armhf for the time_t transition. I am hopeful that this could unblock cairo which is fairly low-level in bootstrapping. https://buildd.debian.org/status/package.php?p=cairo nmu freetype_2.13.2+dfsg-1 . armel armhf . unstable . -m "Rebuild for time_t transition" Thank you, Jeremy Bícha
Bug#1043522: blhc: Please allow -std=gnu++20 inside bin/blhc:L1114 regex exception
Hi Simon, thank you for taking care of this. I can confirm that, using latest build log I have at hand, blhc from Debian repo outputs false positives, while blhc 0.14 built from git outputs nothing. Kind regards Marco On Wed, 28 Feb 2024 09:50:20 +0100 Simon Ruderich wrote: > Hi Marco, > > sorry for the late response. > > On Sat, Aug 12, 2023 at 02:14:37PM +0200, Marco Mattiolo wrote: > > Dear Maintainer, > > > > while building an app (Calindori, calendar for Plasma mobile) to be included > > in Debian, I found what I think is an issue with blhc: in [1] it is found > > > > |/usr/lib/ccache/c++ -std=gnu++20 -dM -E -c > > /usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp| > > This is now fixed in blhc [1] [2]. > > Best, > Simon > > [1]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=766e4499437c6e872cc5870a821c4d10d2d8a63b > [2]: https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=33f9f4721b73fb4789bff5670cbde41b23071106 > -- > + privacy is necessary > + using gnupg http://gnupg.org > + public key id: 0x92FEFDB7E44C32F9
Bug#1065654: mesa ftbfs with time_t64
Il Ven 8 Mar 2024, 11:21 Matthias Klose ha scritto: > On 08.03.24 11:00, Fabio Pedretti wrote: > > Already fixed upstream, the patch will be included since 24.0.3 (will > > be released in 5 days): > > > https://cgit.freedesktop.org/mesa/mesa/commit/?h=staging/24.0=8ea039019761ecc25d49f075aef50de6e81db854 > > no, that commit is only fixing one occurrence. > The other file is not built in Debian, a fix will anyway also be included in 24.0.3. >
Bug#1064617: Passwords should not be changed frequently
On Friday, 8 March 2024 19:58:56 CET Philip Hands wrote: > IMO Having the 'password/passphrase' throughout makes it awkward to > read, and actually we've got one place where it still just says > password, and fixing that would make it slightly worse IMO. > > How about dropping the passphrase stuff? I agree with dropping it. It does look odd and it'll likely raise (more) questions then it answers. And most/all people are familiar with password. Explaining passwords/passphrases is better suited to some educational resource. signature.asc Description: This is a digitally signed message part.
Bug#1065688: python-jwcrypto: CVE-2024-28102
Source: python-jwcrypto Version: 1.5.4-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for python-jwcrypto. CVE-2024-28102[0]: | JWCrypto implements JWK, JWS, and JWE specifications using python- | cryptography. Prior to version 1.5.6, an attacker can cause a denial | of service attack by passing in a malicious JWE Token with a high | compression ratio. When the server processes this token, it will | consume a lot of memory and processing time. Version 1.5.6 fixes | this vulnerability by limiting the maximum token length. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-28102 https://www.cve.org/CVERecord?id=CVE-2024-28102 [1] https://github.com/latchset/jwcrypto/security/advisories/GHSA-j857-7rvv-vj97 [2] https://github.com/latchset/jwcrypto/commit/90477a3b6e73da69740e00b8161f53fea19b831f Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1065687: golang-github-jackc-pgx: CVE-2024-27304
Source: golang-github-jackc-pgx Version: 4.18.1-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for golang-github-jackc-pgx. CVE-2024-27304[0]: | pgx is a PostgreSQL driver and toolkit for Go. SQL injection can | occur if an attacker can cause a single query or bind message to | exceed 4 GB in size. An integer overflow in the calculated message | size can cause the one large message to be sent as multiple messages | under the attacker's control. The problem is resolved in v4.18.2 and | v5.5.4. As a workaround, reject user input large enough to cause a | single query or bind message to exceed 4 GB in size. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-27304 https://www.cve.org/CVERecord?id=CVE-2024-27304 [1] https://github.com/jackc/pgx/security/advisories/GHSA-mrww-27vc-gghv [2] https://github.com/jackc/pgx/commit/f94eb0e2f96782042c96801b5ac448f44f0a81df Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1065686: golang-github-jackc-pgx: CVE-2024-27289
Source: golang-github-jackc-pgx Version: 4.18.1-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for golang-github-jackc-pgx. CVE-2024-27289[0]: | pgx is a PostgreSQL driver and toolkit for Go. Prior to version | 4.18.2, SQL injection can occur when all of the following conditions | are met: the non-default simple protocol is used; a placeholder for | a numeric value must be immediately preceded by a minus; there must | be a second placeholder for a string value after the first | placeholder; both must be on the same line; and both parameter | values must be user-controlled. The problem is resolved in v4.18.2. | As a workaround, do not use the simple protocol or do not place a | minus directly before a placeholder. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-27289 https://www.cve.org/CVERecord?id=CVE-2024-27289 [1] https://github.com/jackc/pgx/security/advisories/GHSA-m7wr-2xf7-cm9p [2] https://github.com/jackc/pgx/commit/826a89229b8b1cdf18e4190afa437d3df9901b9c Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1065685: ITP: raysession -- Session Manager for Audio Software
Package: wnpp Severity: wishlist Owner: s...@debian.org * Package name: raysession Version : 0.14.3 Upstream Author : houston * URL : https://github.com/Houston/RaySession * License : GPL-2 and ISC Programming Lang: Python and Qt5 Description : Ray Session is a GNU/Linux session manager for audio programs as Ardour, Carla, QTractor, Non-Timeline, etc It uses the same API as Non Session Manager, so programs compatible with NSM are also compatible with Ray Session. As Non Session Manager, the principle is to load together audio programs, then be able to save or close all documents together. . Ray Session offers a little more: . - Factory templates for NSM and LASH compatible applications - Possibility to save any client as template - Save session as template - Name files with a prettier way - remember if client was started or not - Abort session almost anytime - Change Main Folder of sessions on GUI - Possibility to KILL client if clean exit is too long - Open Session Folder button (open default file manager) I am preparing this package in salsa, which is based on the version of ubuntu: https://salsa.debian.org/multimedia-team/raysession -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT) 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
Bug#1065684: golang-google-protobuf: CVE-2024-24786
Source: golang-google-protobuf Version: 1.32.0-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for golang-google-protobuf. CVE-2024-24786[0]: | The protojson.Unmarshal function can enter an infinite loop when | unmarshaling certain forms of invalid JSON. This condition can occur | when unmarshaling into a message which contains a | google.protobuf.Any value, or when the | UnmarshalOptions.DiscardUnknown option is set. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-24786 https://www.cve.org/CVERecord?id=CVE-2024-24786 [1] https://go-review.googlesource.com/c/protobuf/+/569356 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1065571: zcfan: Package description mentions non existant "usage" section "below"
Hello! On Wed, Mar 06, 2024 at 09:15:29PM +0100, Beatrice Torracca wrote: > Package: zcfan > Version: 1.3.0-1 > Severity: minor > > Hi! > > the package description of zcfan now has a list item that mentions a > non-existant "usage" section. (it says "(see "usage" below)"). > > It's probably due to some copy-paste from the source documentation. > Thanks for flagging this! It was indeed a copy paste - to fix a lintian nag that the description was too short. I'll update it in the next couple of days. Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature
Bug#1065683: libgcrypt20: CVE-2024-2236
Source: libgcrypt20 Version: 1.10.3-2 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for libgcrypt20. Mainly filling the bug to track the upstream status with respec of libgcrypt's status against the marvin attack. CVE-2024-2236[0]: | A timing-based side-channel flaw was found in libgcrypt's RSA | implementation. This issue may allow a remote attacker to initiate a | Bleichenbacher-style attack, which can lead to the decryption of RSA | ciphertexts. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-2236 https://www.cve.org/CVERecord?id=CVE-2024-2236 [1] https://lists.gnupg.org/pipermail/gcrypt-devel/2024-March/005607.html [2] https://people.redhat.com/~hkario/marvin/ Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1065682: RFS: c-evo-dh/1.11-1 -- Empire Building Game (data files), C-evo: Distant Horizon
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "c-evo-dh": * Package name : c-evo-dh Version : 1.11-1 Upstream contact : Peter * URL : https://sourceforge.net/projects/c-evo-eh/ * License : CC0-1.0, GPL-2+, CC-BY-SA-3.0-US, CC-BY-3.0 * Vcs : https://salsa.debian.org/PeterB/c-evo-dh Section : games The source builds the following binary packages: c-evo-dh-gtk2 - Empire Building Game (GTK2), C-evo: Distant Horizon c-evo-dh-stdai - Empire Building Game (AI module), C-evo: Distant Horizon c-evo-dh-data - Empire Building Game (data files), C-evo: Distant Horizon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/c-evo-dh/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.11-1.dsc Changes since the last upload: c-evo-dh (1.11-1) unstable; urgency=medium . * New Upstream Release * Missing change in changlog for (1.10-1) * Update d/copyright date * Drop lintian override on missing man page for libexec binary * Add source package description in d/control * Strip trailing whitespace from d/c-evo-dh-gtk2.install Regards, -- Peter Blackman
Bug#1065680: cattle-1.0: skip gtk-doc in arch-only build
Source: cattle-1.0 Version: 1.4.0-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs cattle-1.0 fails to cross build from source, because it fails running the gtk-doc scanner. Fortunately, the documentation is split out into an arch:all package, so running the gtk-doc scanner is not necessary. Hence, I am suggesting to skip it entirely in arch-only builds. Using reproducible builds, I verified that this change does not affect binary artifacts. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru cattle-1.0-1.4.0/debian/changelog cattle-1.0-1.4.0/debian/changelog --- cattle-1.0-1.4.0/debian/changelog 2023-02-11 17:46:56.0 +0100 +++ cattle-1.0-1.4.0/debian/changelog 2024-03-08 16:31:26.0 +0100 @@ -1,3 +1,10 @@ +cattle-1.0 (1.4.0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Skip gtk-doc on arch-only build. (Closes: #-1) + + -- Helmut Grohne Fri, 08 Mar 2024 16:31:26 +0100 + cattle-1.0 (1.4.0-2) unstable; urgency=medium * debhelper diff --minimal -Nru cattle-1.0-1.4.0/debian/rules cattle-1.0-1.4.0/debian/rules --- cattle-1.0-1.4.0/debian/rules 2023-02-11 17:46:56.0 +0100 +++ cattle-1.0-1.4.0/debian/rules 2024-03-08 16:31:26.0 +0100 @@ -38,7 +38,7 @@ override_dh_auto_configure: dh_auto_configure -- \ --enable-introspection=yes \ - --enable-gtk-doc=yes + --enable-gtk-doc=$(if $(filter libcattle-1.0-doc,$(shell dh_listpackages)),yes,no) # Prepare files. #
Bug#1065681: openblas: possibly lost empty directory /usr/lib//pkgconfig due to /usr-merge
Package:
libopenblas-openmp-dev,libopenblas-pthread-dev,libopenblas-serial-dev,libopenblas64-openmp-dev,libopenblas64-pthread-dev,libopenblas64-serial-dev
Version: 0.3.26+ds-1
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: dep17p6
Hi,
The openblas packages mentioned above install an empty directory
/usr/lib//pkgconfig. If a different package containing
/lib//pkgconfig were to be removed, dpkg could be lead to think
that /lib//pkgconfig is not owned by any package anymore and
thus delete it. Doing so would delete /usr/lib//pkgconfig due
to the aliasing introduced by /usr-merge. This is only a problem if the
removal happens after unpacking and before running postinst, because the
alternatives prevent dpkg from removing the directory. I therefore
suggest creating the directory in postinst. This mitigation can be
dropped after trixie is released, because we expect that no package will
install files into aliased directories in trixie and later.
Helmut
diff --minimal -Nru openblas-0.3.26+ds/debian/changelog
openblas-0.3.26+ds/debian/changelog
--- openblas-0.3.26+ds/debian/changelog 2024-02-12 22:45:46.0 +0100
+++ openblas-0.3.26+ds/debian/changelog 2024-03-08 21:07:26.0 +0100
@@ -1,3 +1,10 @@
+openblas (0.3.26+ds-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * DEP17: Restore possibly lost /usr/lib/*/pkgconfig. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 08 Mar 2024 21:07:26 +0100
+
openblas (0.3.26+ds-1) unstable; urgency=medium
* New upstream version 0.3.26+ds
diff --minimal -Nru openblas-0.3.26+ds/debian/libopenblas-XXX-dev.postinst
openblas-0.3.26+ds/debian/libopenblas-XXX-dev.postinst
--- openblas-0.3.26+ds/debian/libopenblas-XXX-dev.postinst 2023-07-30
16:52:15.0 +0200
+++ openblas-0.3.26+ds/debian/libopenblas-XXX-dev.postinst 2024-03-08
21:07:24.0 +0100
@@ -1,6 +1,11 @@
#!/bin/sh
set -e
+# begin-remove-after: released:trixie
+# Work around DEP17 P6 via M23
+mkdir -p "${DPKG_ROOT:-}/usr/lib/@DEB_HOST_MULTIARCH@/pkgconfig"
+# end-remove-after
+
update-alternatives --install /usr/lib/@DEB_HOST_MULTIARCH@/libblas.so \
libblas.so-@DEB_HOST_MULTIARCH@ \
/usr/lib/@DEB_HOST_MULTIARCH@/@SUBDIR@/libblas.so \
diff --minimal -Nru openblas-0.3.26+ds/debian/libopenblas64-XXX-dev.postinst
openblas-0.3.26+ds/debian/libopenblas64-XXX-dev.postinst
--- openblas-0.3.26+ds/debian/libopenblas64-XXX-dev.postinst2023-07-30
16:52:15.0 +0200
+++ openblas-0.3.26+ds/debian/libopenblas64-XXX-dev.postinst2024-03-08
21:07:09.0 +0100
@@ -1,6 +1,11 @@
#!/bin/sh
set -e
+# begin-remove-after: released:trixie
+# Work around DEP17 P6 via M23
+mkdir -p "${DPKG_ROOT:-}/usr/lib/@DEB_HOST_MULTIARCH@/pkgconfig"
+# end-remove-after
+#
update-alternatives --install /usr/lib/@DEB_HOST_MULTIARCH@/libblas64.so \
libblas64.so-@DEB_HOST_MULTIARCH@ \
/usr/lib/@DEB_HOST_MULTIARCH@/@SUBDIR@/libblas64.so \
Bug#1065679: RFS: winff/1.6.3+dfsg-2 -- graphical video and audio batch converter using ffmpeg or avconv
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "winff": * Package name : winff Version : 1.6.3+dfsg-2 Upstream contact : Matthew Weatherford * URL : https://github.com/WinFF/winff * License : GFDL-1.3+, GPL-2+, GPL-3+ * Vcs : https://salsa.debian.org/pascal-team/winff Section : video The source builds the following binary packages: winff - graphical video and audio batch converter using ffmpeg or avconv winff-qt - Qt variant of winff winff-data - winff data files winff-doc - winff documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/winff/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/w/winff/winff_1.6.3+dfsg-2.dsc Changes since the last upload: winff (1.6.3+dfsg-2) unstable; urgency=medium . * Drop unneeded build depends (Closes: #1065447) * Clarify libavcodec-extra requirment in long description (d/control) Regards, -- Peter Blackman
Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session
Package: josm
Version: 0.0.svn18969+dfsg-1
Severity: normal
X-Debbugs-Cc: a.t.chadw...@gmail.com
Dear Maintainer,
When JOSM is instructed to download Bing background satellite and aerial
imagery, it hangs the first time JOSM is launched on a day of map editing.
It seems to be a key caching issue. If JOSM is then killed, and
subsequently launched again, it downloads the Bing imagery just fine.
If enough time then elapses without launching JOSM, the situation repeats.
For me this is usually about a day, but the timeframe is probably a lot
shorter.
I would expect Bing background imagery to be downloaded fine every time,
without causing JOSM to hang.
## Minimal Steps to Reproduce
The hang will happen in all ordinary usage when Bing imagry is used, but in
order to rule out config files and settings, you can run JOSM as
$ JAVA_OPTS="-Djosm.home=/tmp/josmhome.$$" josm --skip-plugins --debug
This prevents it from loading your personal config file or any downloaded
plugins. As soon as the main interface loads, add a Bing layer using
Imagery → Bing aerial imagery
If this is the *first* time the josm.home location is being used (i.e. it
didn’t exist before), JOSM will then hang with the final debug messages
shown immediately below. JOSM then hangs and has to be killed with ^C or
using xkill.
---8<--
[...]
2024-03-08 20:12:56.115 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:12:56.120 FINE: Contacting Server...
2024-03-08 20:12:56.120 FINE: REQUEST HEADERS: {Accept=*/*,
Accept-Encoding=gzip, deflate}
2024-03-08 20:12:56.223 INFO: GET
https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?include=ImageryProviders=xml=...stripped...
-> HTTP/1.1 200 (102 ms)
2024-03-08 20:12:56.223 FINE: RESPONSE HEADERS: {Transfer-Encoding=[chunked],
null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE],
x-azure-ref=[20240308T201256Z-39saph36ah08xe5gfvn6y1z8pw00083g01pm],
X-BM-TraceID=[cbf82a8a7dda1cbe233823c5d9cd1a91], Alt-Svc=[h3=":443";
ma=86400], Access-Control-Allow-Origin=[*], Access-Control-Allow-Methods=[POST,
GET, OPTIONS], X-BM-FE-Elapsed=[5], Connection=[keep-alive],
Access-Control-Allow-Headers=[Content-Type,X-FD-Features,X-FD-FLIGHT,PreferAnonymous],
Date=[Fri, 08 Mar 2024 20:12:56 GMT], Cache-Control=[no-cache],
X-AspNet-Version=[4.0.30319], X-BM-Srv=[mapsplatform-frontend-55b6b7bd84-p2lfw,
DU3064], Content-Encoding=[gzip], Vary=[Accept-Encoding],
X-MS-BM-WS-INFO=[0], X-Powered-By=[ASP.NET], Content-Type=[application/xml;
charset=utf-8]}
2024-03-08 20:12:56.223 FINE: Downloading data...
2024-03-08 20:12:56.224 INFO: Successfully loaded Bing attribution data.
[hangs, ^C]
--->8--
If it’s the *second* time around (within some unknown number of minutes),
JOSM does not hang, and goes on to print messages like
---8<--
2024-03-08 20:17:01.005 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:17:01.033 FINE: Reading Bing logo from
https://dev.virtualearth.net/Branding/logo_powered_by.png
2024-03-08 20:17:01.038 FINE: Contacting Server...
2024-03-08 20:17:01.039 FINE: REQUEST HEADERS: {Accept=*/*,
Accept-Encoding=gzip, deflate}
2024-03-08 20:17:01.420 INFO: GET
https://dev.virtualearth.net/Branding/logo_powered_by.png -> HTTP/1.1 200 (381
ms; 1.17 kB)
2024-03-08 20:17:01.420 FINE: RESPONSE HEADERS: {Accept-Ranges=[bytes],
null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE], Alt-Svc=[h3=":443";
ma=86400], Cache-Control=[max-age=86400], ETag=["1da6b47d7e7e12e"],
Last-Modified=[Thu, 29 Feb 2024 19:45:27 GMT],
X-Azure-Ref=[0PXLrZQBRV4dQ4FinSYsXKjq3EwHuTE9OMjFFREdFMTgxMgBmMTI3MDYwYi1mNDk4LTRlMjAtYjVkZi1hZWIyMzczZWM5NWU=],
Content-Length=[1198], Date=[Fri, 08 Mar 2024 20:17:00 GMT],
Content-Type=[image/png]}
2024-03-08 20:17:01.421 FINE: Downloading data...
2024-03-08 20:17:01.480 INFO: AbstractTileSourceLayer: estimated visible tiles:
54, estimated cache size: 466
2024-03-08 20:17:01.484 FINE: zoomChanged(): 2
2024-03-08 20:17:01.580 INFO: AbstractTileSourceLayer: estimated visible tiles:
54, estimated cache size: 466
2024-03-08 20:17:01.629 INFO: AbstractTileSourceLayer: estimated visible tiles:
54, estimated cache size: 466
2024-03-08 20:17:01.631 INFO: Allocate for tile source layer: 116 MB of memory.
Available: 3 914 MB.
2024-03-08 20:17:01.644 FINE: zoomChanged(): 14
2024-03-08 20:17:01.645 FINE: JCS - Submitting job for execution for url:
https://ecn.t2.tiles.virtualearth.net/tiles/a30.jpeg?g=14355=odbl
2024-03-08 20:17:01.646 FINE: JCS - Submitting job for execution for url:
https://ecn.t1.tiles.virtualearth.net/tiles/a21.jpeg?g=14355=odbl
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url:
https://ecn.t2.tiles.virtualearth.net/tiles/a30.jpeg?g=14355=odbl
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url:
Bug#1064041: linux-image-6.1.0-18-amd64: Resuming from suspend keyboard unresponsive (but sysrq OK , touchpad OK) on dell latitude 3340
Hi Jacques, On Mon, Mar 04, 2024 at 10:10:35AM +0100, Jacques wrote: > Hi Salvatore > > Le 03/03/2024 à 16:25, Salvatore Bonaccorso a écrit : > > > > Ok that is great to hear. So firstmost: Then this iwill be fixed in > > the next upload for bookworm, as we do a rebase to at least 6.1.80. > > > > Alternatively if we know which was the fixing commit that would be > > helpful as well now, since we know 6.1.80 fixes the issue. Otherwise > > we simply close later once the upload has happened. > > > > Regards, > > Salvatore > > > Here are the results of my tests on the various upstream kernels. > > The problem appeared with kernel 6.1.74 and has been corrected in kernel > 6.1.78. Then this though is likely the same as #1061521, I'm going to merge those two and the bug will be closed as well once more with the 6.1.y upload containing the fix. Thanks again for all your testing! > If possible, can we leave the bug report open until the next version of > bookworm is released, to allow other users to find the workaround by adding > the atkbd.reset option to the machine boot: I would tend to forget to close the bug separately, but I have merged the two, and the bug will be closed once more once the upload for the 6.1.y happens. That said I as well updated the metadata to make it show that for Debian it affects as well 6.1.76-1 and updated the debian/changelog with a bug-closer: This should have put all in place to correctly resolve it downstream for us. Regards, Salvatore > > edit in /etc/default/grub: > GRUB_CMDLINE_LINUX_DEFAULT="quiet atkbd.reset" FWIW, to not update /etc/default/grub you could as well make it a drop in /etc/default/grub.d/ . Regards, Salvatore
Bug#1065677: rust-quick-xml: please upgrade to branch v0.31
Source: rust-quick-xml Version: 0.27.1-3 Severity: important Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please upgrade to (or separately provide) upstream branch v0.31. raising severity as the newer branch seemingly fix a range of bugs, including a crash when parsing certain input data. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXrbtAACgkQLHwxRsGg ASE4nw//QdjZ4fGB0u2ROL5OnQyASFyPi0GMZ5bCZk/btF3QH6L6NdU8BtjN9FmH 0vvIhbCi9YjcjFabPOZ7AD1k5C65op9ndmOytdJwH/KEixtKxAuR271GsgfZ7sNI EFvb1jCP8yXCZBiSwuTl8zEPFJCT8+AxOAYIftvs9XTfn6yVxnuYjPriczsQcRLD xFkiu3nEag1w4DETfsH0JR9qycwJ9+LebZKKjmhtCMGzMm/rJDCe9H4V75WqE2gi Lk9+qLq+Nh1m/aSiu7YFCpQuAhpCGWNc2vyeUWfJENobqE6JsfsFWHrk96IYs2QM 2UnPwUTJNIScyNEs9SEPbW1It/+M9CAccFDoqht4bEkW/2spdUgc3bZP8+AIrh76 xJstdsXTKt9tsliaibD6clJh4PBIQZH0QPpTGRc1BxOP65Up/b+AORa0YBxjj34k 9wCLgiN4/BaDbaXIWKGF+rPIguvOMHTk7eOChsntVxJJLFtPCDWdeXj+IIZtmFlY p9SFM87YuSCFsIcblIPUBc2LAnygaXIW6pIu23FsksbBvPDdZ3x5km7WD3mLKmKf SHD9wPfkdWpUAogTkkoiOWK/uIU74Fuf+YbqQDvN5ExUxHjVJwDCI+fV+7vcalem vA2sxQXsUrLDjxbgV+lJOVvbtTTIjCXxrMza4Y67ohMVzxbrI7o= =mvuj -END PGP SIGNATURE-
Bug#1063621: bookworm-pu: package clamav/clamav_1.0.5+dfsg-1~deb12u1
On 2024-03-08 07:38:10 [+], Adam D. Barratt wrote: > On Fri, 2024-02-09 at 23:12 +0100, Sebastian Andrzej Siewior wrote: > > This is an update to the latest clamav release in the 1.0.x series. > > One small thing you may want to fix for any follow-up updates: > > +clamav (1.0.5+dfsg-1~deb12u1) bookworm; urgency=medium > + > + * Import 1.0.4 (Closes: #1063479). Indeed, thank you. > Regards, > > Adam Sebastian
Bug#1059094: libxml2mod.cpython-311-x86_64-linux-gnu.so: undefined symbol: xmlParserError
Package: python3-libxml2 Version: 2.12.5+dfsg-0exp1 Followup-For: Bug #1059094 Dear Maintainer, I am afraid the bug is still there or am I missing something? virt-manager Traceback (most recent call last): File "/usr/bin/virt-manager", line 6, in from virtManager import virtmanager File "/usr/share/virt-manager/virtManager/virtmanager.py", line 19, in from virtinst import BuildConfig File "/usr/share/virt-manager/virtinst/__init__.py", line 50, in from virtinst.domain import * # pylint: disable=wildcard-import ^ File "/usr/share/virt-manager/virtinst/domain/__init__.py", line 5, in from .blkiotune import DomainBlkiotune File "/usr/share/virt-manager/virtinst/domain/blkiotune.py", line 8, in from ..xmlbuilder import XMLBuilder, XMLChildProperty, XMLProperty File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 16, in from .xmlapi import XMLAPI File "/usr/share/virt-manager/virtinst/xmlapi.py", line 7, in import libxml2 File "/usr/lib/python3/dist-packages/libxml2.py", line 1, in import libxml2mod ImportError: /usr/lib/python3/dist-packages/libxml2mod.cpython-311- x86_64-linux-gnu.so: undefined symbol: xmlParserError Thanks in advance Renato Gallo -- System Information: Debian Release: trixie/sid APT prefers experimental APT policy: (900, 'experimental'), (899, 'testing'), (500, 'noble'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-libxml2 depends on: ii libc6 2.39-0ubuntu2 ii python3 3.11.6-1 python3-libxml2 recommends no packages. python3-libxml2 suggests no packages. -- no debconf information
Bug#1065529: interimap: Testsuite fails with openssl 3.2
On 2024-03-06 15:27:50 [+0100], Guilhem Moulin wrote: > Hi Sebastian, Hi, > Great to hear OpenSSL 3.2 will soon be entering sid! :-) > > On Wed, 06 Mar 2024 at 07:59:53 +0100, Sebastian Andrzej Siewior wrote: > > I'm currently puzzled where to look at. Could you please have a look? > > It seems openssl-req(1ssl) now generates X.509 version 3 certificates by > default. (A new flag `-509v1` was added to revert back to version 1.) > > interimap's test suite generates a transient CAs, but didn't pass any > X.509 v3 basic constraints as it assumed v1. The resulting “CA” was > therefore generated without CA:TRUE thereby failing peer validation. > > The fix is trivial, I'll simply change the test suite to generate a v3 > CA instead and pass CA:TRUE. But I thought it might be useful to spell > the fix out in case there are other affected packages. Thank for the explanation. > Cheers, Sebastian
Bug#1065676: glome: install library and PAM module into /usr
Source: glome Version: 0.1-2 Severity: normal Tags: patch trixie sid User: helm...@debian.org Usertags: dep17m2 We want to finalize the /usr-merge via DEP17 by moving all files to /usr. glome installs files into /lib; these should be moved into the respective canonical locations in /usr/. Please find a patch attached. It has been build-tested. If your package will change for the t64 transition or otherwise rename/split/move its binaries (packages) during trixie, please then upload to experimental and get in touch with the UsrMerge driver, please see the wiki [1]. Michael [1] https://wiki.debian.org/UsrMerge diff -Nru glome-0.1/debian/changelog glome-0.1/debian/changelog --- glome-0.1/debian/changelog 2024-03-06 23:10:56.0 +0100 +++ glome-0.1/debian/changelog 2024-03-08 20:20:29.0 +0100 @@ -1,3 +1,10 @@ +glome (0.1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install library and PAM module into /usr. (Closes: #-1) + + -- Michael Biebl Fri, 08 Mar 2024 20:20:29 +0100 + glome (0.1-2) unstable; urgency=medium * Add package test for PAM module diff -Nru glome-0.1/debian/libglome0.install glome-0.1/debian/libglome0.install --- glome-0.1/debian/libglome0.install 2022-12-11 18:17:46.0 +0100 +++ glome-0.1/debian/libglome0.install 2024-03-08 20:20:29.0 +0100 @@ -1 +1 @@ -lib/*/libglome.so.* +usr/lib/*/libglome.so.* diff -Nru glome-0.1/debian/libglome-dev.install glome-0.1/debian/libglome-dev.install --- glome-0.1/debian/libglome-dev.install 2022-12-11 18:06:32.0 +0100 +++ glome-0.1/debian/libglome-dev.install 2024-03-08 20:20:29.0 +0100 @@ -1,3 +1,3 @@ -lib/*/libglome.so -lib/*/pkgconfig/glome.pc +usr/lib/*/libglome.so +usr/lib/*/pkgconfig/glome.pc usr/include/glome.h diff -Nru glome-0.1/debian/libpam-glome.install glome-0.1/debian/libpam-glome.install --- glome-0.1/debian/libpam-glome.install 2022-12-11 18:04:33.0 +0100 +++ glome-0.1/debian/libpam-glome.install 2024-03-08 20:20:29.0 +0100 @@ -1 +1 @@ -lib/*/security/pam_glome.so +usr/lib/*/security/pam_glome.so diff -Nru glome-0.1/debian/not-installed glome-0.1/debian/not-installed --- glome-0.1/debian/not-installed 2022-12-11 18:07:42.0 +0100 +++ glome-0.1/debian/not-installed 2024-03-08 20:20:29.0 +0100 @@ -1 +1 @@ -lib/*/pkgconfig/glome-login.pc +usr/lib/*/pkgconfig/glome-login.pc diff -Nru glome-0.1/debian/rules glome-0.1/debian/rules --- glome-0.1/debian/rules 2022-12-11 18:03:18.0 +0100 +++ glome-0.1/debian/rules 2024-03-08 20:20:29.0 +0100 @@ -5,6 +5,3 @@ %: dh $@ --buildsystem=meson - -override_dh_auto_configure: - dh_auto_configure -- --libdir=/lib/$(DEB_HOST_MULTIARCH)
Bug#1065675: network-console: Allow ED25519 host keys
Source: network-console Version: 1.93 Severity: wishlist Tags: d-i X-Debbugs-Cc: 0cf13...@lf.nx.tc
Bug#1063673: ITP: llama.cpp -- Inference of Meta's LLaMA model (and others) in pure C/C++
[Christian Kastner 2024-02-13] > I'll push a first draft soon, though it will definitely not be > upload-ready for the above reasons. Where can I find the first draft? -- Happy hacking Petter Reinholdtsen
Bug#1061894: apr: NMU diff for 64-bit time_t transition
The NMU was buggy because symbols files are in a non-standard location, so
did not get updated by our transition scripts; with the result that packages
rebuilt against libapr1t64 still had a dependency on libapr1. Please find
attached a full NMU debdiff for an updated NMU.
On Wed, Feb 28, 2024 at 01:17:59AM +, Steve Langasek wrote:
> Dear maintainer,
>
> Please find attached a final version of this patch for the time_t
> transition. This patch is being uploaded to unstable.
>
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental backports with a wrong ABI.
>
> Thanks!
>
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> diff -Nru apr-1.7.2/debian/changelog apr-1.7.2/debian/changelog
> --- apr-1.7.2/debian/changelog2023-02-26 20:51:24.0 +
> +++ apr-1.7.2/debian/changelog2024-02-28 01:17:18.0 +
> @@ -1,3 +1,10 @@
> +apr (1.7.2-3.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Rename libraries for 64-bit time_t transition. Closes: #1061894
> +
> + -- Steve Langasek Wed, 28 Feb 2024 01:17:18 +
> +
> apr (1.7.2-3) unstable; urgency=medium
>
>* Add more fixes for atomics from upstream, in particular for
> diff -Nru apr-1.7.2/debian/control apr-1.7.2/debian/control
> --- apr-1.7.2/debian/control 2023-02-03 16:18:13.0 +
> +++ apr-1.7.2/debian/control 2024-02-28 01:17:18.0 +
> @@ -3,7 +3,7 @@
> Priority: optional
> Maintainer: Debian Apache Maintainers
> Uploaders: Stefan Fritsch
> -Build-Depends: debhelper-compat (= 13),
> +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
> autoconf,
> mawk,
> uuid-dev,
> @@ -19,7 +19,10 @@
> Homepage: https://apr.apache.org/
> Rules-Requires-Root: no
>
> -Package: libapr1
> +Package: libapr1t64
> +Provides: ${t64:Provides}
> +Replaces: libapr1
> +Breaks: libapr1 (<< ${source:Version})
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Pre-Depends: ${misc:Pre-Depends}
> @@ -33,7 +36,7 @@
> Package: libapr1-dev
> Architecture: any
> Section: libdevel
> -Depends: libapr1 (= ${binary:Version}), uuid-dev, ${misc:Depends},
> libsctp-dev [linux-any], python3:any
> +Depends: libapr1t64 (= ${binary:Version}), uuid-dev, ${misc:Depends},
> libsctp-dev [linux-any], python3:any
> Conflicts: libapr1.0-dev, libapr0-dev
> Description: Apache Portable Runtime Library - Development Headers
> APR is Apache's Portable Runtime Library, designed to be a support library
> diff -Nru apr-1.7.2/debian/libapr1.docs apr-1.7.2/debian/libapr1.docs
> --- apr-1.7.2/debian/libapr1.docs 2023-02-02 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.docs 1970-01-01 00:00:00.0 +
> @@ -1 +0,0 @@
> -NOTICE
> diff -Nru apr-1.7.2/debian/libapr1.install apr-1.7.2/debian/libapr1.install
> --- apr-1.7.2/debian/libapr1.install 2023-02-02 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.install 1970-01-01 00:00:00.0 +
> @@ -1 +0,0 @@
> -usr/lib/*/libapr-1.so.*
> diff -Nru apr-1.7.2/debian/libapr1.lintian-overrides
> apr-1.7.2/debian/libapr1.lintian-overrides
> --- apr-1.7.2/debian/libapr1.lintian-overrides2023-02-02
> 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.lintian-overrides1970-01-01
> 00:00:00.0 +
> @@ -1 +0,0 @@
> -libapr1: package-name-doesnt-match-sonames libapr-1-0
> diff -Nru apr-1.7.2/debian/libapr1.symbols apr-1.7.2/debian/libapr1.symbols
> --- apr-1.7.2/debian/libapr1.symbols 2023-02-02 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.symbols 1970-01-01 00:00:00.0 +
> @@ -1,2 +0,0 @@
> -here for the purpose of tricking debhelper...bwahahahaha.
> -
> diff -Nru apr-1.7.2/debian/libapr1t64.docs apr-1.7.2/debian/libapr1t64.docs
> --- apr-1.7.2/debian/libapr1t64.docs 1970-01-01 00:00:00.0 +
> +++ apr-1.7.2/debian/libapr1t64.docs 2023-02-02 21:18:42.0 +
> @@ -0,0 +1 @@
> +NOTICE
> diff -Nru apr-1.7.2/debian/libapr1t64.install
> apr-1.7.2/debian/libapr1t64.install
> --- apr-1.7.2/debian/libapr1t64.install 1970-01-01 00:00:00.0
> +
> +++ apr-1.7.2/debian/libapr1t64.install 2023-02-02 21:18:42.0
> +
> @@ -0,0 +1 @@
> +usr/lib/*/libapr-1.so.*
> diff -Nru apr-1.7.2/debian/libapr1t64.lintian-overrides
> apr-1.7.2/debian/libapr1t64.lintian-overrides
> --- apr-1.7.2/debian/libapr1t64.lintian-overrides 1970-01-01
> 00:00:00.0 +
> +++ apr-1.7.2/debian/libapr1t64.lintian-overrides 2024-02-28
> 01:17:10.0 +
> @@ -0,0
Bug#1065674: bugs.debian.org: Disable Shutdown Beep
Package: bugs.debian.org Severity: minor X-Debbugs-Cc: slow_sp...@att.net Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Every time I select Applications
Bug#1065322: RFP: megactl -- LSI Megaraid Control and Monitoring Tools
Control: retitle -1 ITP: megactl -- LSI Megaraid Control and Monitoring Tools The package is now waiting in NEW, with Jérémy Lal and me as maintainers. -- Happy ahcking Petter Reinholdtsen
Bug#1064617: Passwords should not be changed frequently
Justin B Rye writes: > Philip Hands wrote: >>> Maybe instead of saying "use the system's initial user account to >>> become root" it should say "allow the system's initial user account >>> to gain administrative privileges"? I'm not sure. Oh, and we might >>> even want to mention the word "superuser", or then again we might not. >> >> I think Diederik's suggestion of using 'root' for the account and >> 'super-user' for the privileges might be the way to go. > > Looking at what I end up with after another couple of rounds of > fiddling with it I'm not sure if it's doing quite what you asked for, > but you still might want it so here it is: Thanks for that. > - Some account needs to have system administrative privileges. The > - password/passphrase for that account should be something that > - cannot be guessed. > + Some account needs to be available with administrative super-user > + privileges. The password/passphrase for that account should be > + something that cannot be guessed. > . > To allow direct password-based access via the 'root' account, you > can set the password/passphrase for that account here. > . > - Alternatively, you can lock root's password > + Alternatively, you can lock the root account's password > by leaving this setting empty, and > instead use the system's initial user account > (which will be set up in the next step) > - to become root. This will be enabled for you > - by adding that user to the 'sudo' group. > + to gain administrative privileges. This will be enabled for you by > + adding that initial user to the 'sudo' group. > . > Note: what you type here will be hidden (unless you select to show it). That can be seen here: https://salsa.debian.org/philh/user-setup/-/commit/a684977100e6746725372f8294f271f890c50430 & https://openqa.debian.net/tests/240580#step/passwords/1 I think I prefer the previous version better for some reason. IMO Having the 'password/passphrase' throughout makes it awkward to read, and actually we've got one place where it still just says password, and fixing that would make it slightly worse IMO. How about dropping the passphrase stuff? https://salsa.debian.org/philh/user-setup/-/commit/7c8dd1bd9d5c8596e7b8f82a19a075e0a5572ed7 & https://openqa.debian.net/tests/240582#step/passwords/1 which I think is more readable (and is probably fine now that we've dropped the stuff about password selection which could be read as suggesting that a password is expected to be a single word). Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1063752: [Debichem-devel] Bug#1063752: custodian: Inappriate maintainer address
Hi, On Tue, Feb 13, 2024 at 11:24:15AM +0100, Drew Parsons wrote: > Source: custodian > Followup-For: Bug #1063752 > X-Debbugs-Cc: Debichem Team > Control: reassign 1063752 lists.debian.org > Control: affects 1063752 src:custodian > > Scott Kitterman reported that lists.alioth.debian.org is bouncing > emails from debian official addresses (ftpmas...@ftp-master.debian.org > in this case, processing packages for the Debichem team with Maintainer > address debichem-de...@lists.alioth.debian.org) > > Scott filed the bug against src:custodian, but the bug must be in the > mailing list daemon, so I'm reassigning the bug to lists.debian.org I don't think the Debian listmasters are responsible for lists.alioth.debian.org - also, I don't think there is a pseudo package for it :-/ I got another complaint from ftp-master for a NEW processing mail some time ago, so maybe it is related to that. After checking the admin interface, it looks like lists.alioth.debian.org was updated last month and the configuration reset - suspected spam mails were auto-rejected again while they were sent to me previously. I reverted that now and maybe that fixes it already. Michael
Bug#1064077: RFS: qt5ct/1.8-1 -- Qt5 Configuration Utility
Mateusz, Thank you for your work on this package. It is quite impressive and I am happy to sponsor it. As this source package now contains new binary packages, I have done a source upload to the NEW queue. Soren On Thursday, March 7, 2024 12:19:47 PM MST Mateusz Łukasik wrote: > Hi Soren, > > Sorry for delay. I converted the sources into separate libraries in new > mentors upload. The soname will change every new version. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1065673: ITP: httprobe -- Take a list of domains and probe for working HTTP and HTTPS servers
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Aquila Macedo Costa Severity: wishlist * Package name: httprobe Version : 0.2 Upstream Contact: Tom Hudson * URL : https://github.com/tomnomnom/httprobe * License : MIT Programming Lang: Golang Description : Take a list of domains and probe for working HTTP and HTTPS servers httprobe is a versatile tool designed for probing and identifying working HTTP and HTTPS servers from a list of domains. I'm writing to submit an Intention to Package (ITP) for httprobe under the pkg-security team's umbrella.
Bug#1065585: linux-headers-6.7.7-amd64: Depends: linux-compiler-gcc-13-x86 -> linux-image-6.7.7-amd64, gcc-13 => uninstallable on x32
On Fri, Mar 08, 2024 at 06:43:44PM +0100, Bastian Blank wrote: > Control: severity -1 minor > > Because this is an x32 host. > x32 is multi-arch kernel only architecture. Debian still don't have > proper support for multi-arch for compilers. I don't get this. This literally Just fully worked. gcc-13:x32 can produce x32, amd64, and i386 binaries and modules; if you noticed the taints, those are because of ZFS/dkms, which works out-of-box. One could hazard to say that Debian /did/ have proper multi-arch compiler support with linux-headers-6.5.0-5-amd64:amd64 -> linux-compiler-gcc-13-x86:x32 -> gcc-13:x32 and it was freshly broken in the 6.7 packages which seem to be linux-headers-6.5.0-5-amd64:amd64 -> gcc-13:amd64 there's never been a need to install gcc-13:amd64 on an x32 system, and there still isn't. The previous arrangement had worked with no issues for at least the 4 years I've been using this system, and probably longer. Don't really see how "can no longer install kernel infrastructure" is "minor", either. > Just use amd64. Just undo the change that broke x32. signature.asc Description: PGP signature
Bug#1065672: dpkg: Proofread Swedish translation
Package: dpkg Version: 1.22.5 Severity: wishlist Tags: patch l10n Dear Maintainer, In the Swedish translation of the dpkg-source man-page I discovered a small typo - see this patch: diff --git a/man/po/sv.po b/man/po/sv.po index d0a0a5e37..65b029ea5 100644 --- a/man/po/sv.po +++ b/man/po/sv.po @@ -20024,8 +20024,8 @@ msgid "" "control files and directories of the most common revision control systems, " "backup and swap files and Libtool build output directories." msgstr "" -"B<-I> ensamt lägger till satandard B<--exclude>-flaggor som filtrerar ut " -"styrfiler och kataloger från de flesta vanliga versionshanteringssystem, " +"B<-I> ensamt lägger till standard B<--exclude>-flaggor som filtrerar ut " +"styrfiler och kataloger från de flesta vanliga versionshanteringssystemen, " "säkerhetskopior, växlingsfiler och Libtool-byggutdatakataloger." #. type: textblock The first one ( /satandard/standard/) is obvious, the other /versionshanteringssystem/versionshanteringssystemen/ might be a bit more debatable. /Andreas Rönnquist gus...@debian.org -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.9-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 dpkg depends on: ii libbz2-1.0 1.0.8-5+b2 ii libc62.37-15.1 ii liblzma5 5.6.0-0.2 ii libmd0 1.1.0-2 ii libselinux1 3.5-2 ii libzstd1 1.5.5+dfsg2-2 ii tar 1.35+dfsg-3 ii zlib1g 1:1.3.dfsg-3.1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.7.13+b1 pn debsig-verify -- no debconf information
Bug#1065665: [Debian-lego-team] Bug#1065665: nxt-firmware: implicit type conversion from negative float to char gives 0
Am 08.03.24 um 18:42 schrieb Petter Reinholdtsen: No idea about the nxt-firmware status, but just for fun and to show support, I made a C edition: Hi Petter, thank you for the reply. This was fixed upstream with release 1.29.5 https://git.ni.fr.eu.org/nxt-firmware.git/commit/?id=3a3201ff808c1258bd8cea8c6ae471c446dd2ed9 thank you and sorry for the noise. -- Andy
Bug#1065585: linux-headers-6.7.7-amd64: Depends: linux-compiler-gcc-13-x86 -> linux-image-6.7.7-amd64, gcc-13 => uninstallable on x32
Control: severity -1 minor > Because this is an x32 host. x32 is multi-arch kernel only architecture. Debian still don't have proper support for multi-arch for compilers. Just use amd64. Bastian -- Bones: "The man's DEAD, Jim!"
Bug#1065665: [Debian-lego-team] Bug#1065665: nxt-firmware: implicit type conversion from negative float to char gives 0
[Andreas Weber]
> Dear Maintainer, following code debug1.nxc:
No idea about the nxt-firmware status, but just for fun and to show
support, I made a C edition:
% cat > x.c <
int main(int argc, char *argv[])
{
float a = -12.34;
printf("%f\n", a);
char b = a;
printf("%i\n", b);
return 0;
}
EOF
% gcc x.c
% ./a.out
-12.34
-12
%
--
Happy hacking
Petter Reinholdtsen
Bug#1065671: samba: No smbget command after installing samba
Package: samba
Version: 2:4.17.12+dfsg-0+deb12u1
Severity: normal
X-Debbugs-Cc: vincent.poup...@outlook.com
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
sudo apt update
sudo apt dist-upgrade
sudo apt install samba
* What exactly did you do (or not do) that was effective (or
ineffective)?
smbget
* What was the outcome of this action?
bash: smbget : commande introuvable (translation: missing command)
* What outcome did you expect instead?
that the tool smbget is part of the samba package like explained in the
man page
hthttps://manpages.debian.org/bookworm/smbclient/smbget.1.en.htmltps://manpages.debian.org/bookworm/smbclient/smbget.1.en.html
*** End of the template - remove these template lines ***
-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf not present
-- 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/12 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_CA:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages samba depends on:
ii init-system-helpers 1.65.2
ii libbsd0 0.11.7-2
ii libc62.36-9+deb12u4
ii libcups2 2.4.2-3+deb12u5
ii libgnutls30 3.7.9-2+deb12u2
ii libldap-2.5-02.5.13+dfsg-5
ii libldb2 2:2.6.2+samba4.17.12+dfsg-0+deb12u1
ii libpam-modules 1.5.2-6+deb12u1
ii libpam-runtime 1.5.2-6+deb12u1
ii libpopt0 1.19+dfsg-1
ii libtalloc2 2.4.0-f2
ii libtasn1-6 4.19.0-2
ii libtdb1 1.4.8-2
ii libtevent0 0.14.1-1
ii passwd 1:4.13+dfsg1-1+b1
ii procps 2:4.0.2-3
ii python3 3.11.2-1+b1
ii python3-dnspython2.3.0-1
ii python3-samba2:4.17.12+dfsg-0+deb12u1
ii samba-common 2:4.17.12+dfsg-0+deb12u1
ii samba-common-bin 2:4.17.12+dfsg-0+deb12u1
ii samba-libs 2:4.17.12+dfsg-0+deb12u1
ii tdb-tools1.4.8-2
Versions of packages samba recommends:
ii attr1:2.5.1-4
ii logrotate 3.21.0-1
ii python3-markdown3.4.1-2
ii samba-ad-provision 2:4.17.12+dfsg-0+deb12u1
ii samba-dsdb-modules 2:4.17.12+dfsg-0+deb12u1
ii samba-vfs-modules 2:4.17.12+dfsg-0+deb12u1
Versions of packages samba suggests:
pn bind9
pn bind9utils
pn ctdb
pn ldb-tools
pn ntp | chrony
pn ufw
pn winbind
-- no debconf information
#
# Sample configuration file for the Samba suite for Debian GNU/Linux.
#
#
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options most of which
# are not shown in this example
#
# Some options that are often worth tuning have been included as
# commented-out examples in this file.
# - When such options are commented with ";", the proposed setting
#differs from the default Samba behaviour
# - When commented with "#", the proposed setting is the default
#behaviour of Samba but the option is considered important
#enough to be mentioned here
#
# NOTE: Whenever you modify this file you should run the command
# "testparm" to check that you have not made any basic syntactic
# errors.
#=== Global Settings ===
[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = WORKGROUP
Networking
# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
; interfaces = 127.0.0.0/8 eth0
# Only bind to the named interfaces and/or networks; you must use the
# 'interfaces' option above to use this.
# It is recommended that you enable this feature if your Samba machine is
# not protected by a firewall or is a firewall itself. However, this
# option cannot handle dynamic or non-broadcast interfaces correctly.
; bind interfaces only = yes
Debugging/Accounting
# This tells Samba to use a separate log file for each machine
# that connects
log file = /var/log/samba/log.%m
# Cap the size of the individual log files (in KiB).
max log size = 1000
# We want Samba to only log to /var/log/samba/log.{smbd,nmbd}.
# Append syslog@1 if you want important messages to be sent to syslog too.
logging = file
# Do something sensible when Samba crashes: mail the admin a backtrace
panic action = /usr/share/samba/panic-action %d
### Authentication
Bug#1065670: ITP: exiflooter -- finds geolocation on all image urls and directories
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Aquila Macedo Costa Severity: wishlist * Package name: exiflooter Version : 1.0.0+git20231228.22e4700 Upstream Contact: Yunus AYDIN * URL : https://github.com/aydinnyunus/exiflooter * License : Apache-2.0 Programming Lang: Golang Description : finds geolocation on all image urls and directories ExifLooter finds geolocation on all image urls and directories also integrates with OpenStreetMap. I'm writing to submit an Intention to Package (ITP) for exiflooter under the pkg-security team's umbrella.
Bug#1060318: This is a regression: it used to pass with PoCL3.1
Platform Name Portable Computing Language Platform Vendor The pocl project Platform VersionOpenCL 3.0 PoCL 3.1+debian Linux, None+Asserts, RELOC, SPIR, LLVM 15.0.6, SLEEF, DISTRO, POCL_DEBUG Platform ProfileFULL_PROFILE
Bug#1064800: menu: installs same filename to both bin and sbin
On Sun, Feb 25, 2024 at 11:21:26PM +, ca...@allfreemail.net wrote: > Source: menu > Version: 2.1.50 > Severity: normal > > Dear Maintainer, > > your package installs the filenames `install-menu` and `su-to-root` to both > bin and sbin as opposed to just one of those locations. > > This causes a problem on a filesystem layout where bin and sbin are merged > into a single real directory, typically by sbin being a symlink to bin. Such > a filesystem layout has become standard on some distributions now, and others > are moving onto in their next releases. > > Please pick one location and install it only there. /usr/bin is preferred > over any other location. I would suggest you find out why the binaries are in both directories in the first place. Then we can discuss a solution! Cheers, -- Bill. Imagine a large red swirl here.
Bug#1065669: ITP: raven -- A lightweight http file upload service used for penetration testing and incident response.
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Aquila Macedo Costa Severity: wishlist * Package name: raven Version : 1.0.1 Upstream Contact: Tristram * URL : https://github.com/gh0x0st/raven * License : MIT Programming Lang: Python3 Description : A lightweight http file upload service used for penetration testing and incident response. This package contains a Python tool that extends the capabilities of the http.server Python module by offering a self-contained file upload web server. While the common practice is to use python3 -m http.server 80 to serve files for remote client downloads, Raven addresses the need for a similar solution when you need the ability to receive files from remote clients. This becomes especially valuable in scenarios such as penetration testing and incident response procedures when protocols such as SMB may not be a viable option. I'm writing to submit an Intention to Package (ITP) for raven under the pkg-security team's umbrella.
Bug#1065668: google-android-build-tools-30.0.2-installer: Cannot install multiple "build-tools" versions side by side
Package: google-android-build-tools-30.0.2-installer Version: 30.0.2+1707406511 Severity: normal Dear Maintainer, Since I made the switch to testing packages for google-android-* packages, I can no longer install multiple versions of the "build tools" side by side. Here is the log of when I try to install two of them: $ sudo apt install -t testing google-android-build-tools-30.0.3-installer google-android-build-tools-30.0.2-installer Reading package lists... Done Building dependency tree... Done Reading state information... Done google-android-build-tools-30.0.2-installer is already the newest version (30.0.2+1707406511). Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: google-android-build-tools-30.0.2-installer : Conflicts: aapt Conflicts: aidl Conflicts: apksigner Conflicts: dexdump Conflicts: split-select Conflicts: zipalign google-android-build-tools-30.0.3-installer : Conflicts: aapt Conflicts: aidl Conflicts: apksigner Conflicts: dexdump Conflicts: split-select Conflicts: zipalign E: Unable to correct problems, you have held broken packages. And here is the result of apt depends, which feels strange to me: $ apt depends google-android-build-tools-30.0.2-installer google-android-build-tools-30.0.2-installer Depends: google-android-licenses (= 1707406511) Depends: libstdc++6 Depends: zlib1g Depends: wget |Depends: make make-guile |Depends: build-essential Depends: dpkg-dev Depends: unzip Depends: ca-certificates Depends: debconf Depends: po-debconf |Depends: debconf (>= 0.5) Depends: cdebconf debconf Conflicts: aapt google-android-build-tools-19.1.0-installer google-android-build-tools-20.0.0-installer google-android-build-tools-21.1.2-installer google-android-build-tools-22.0.1-installer google-android-build-tools-23.0.1-installer google-android-build-tools-23.0.2-installer google-android-build-tools-23.0.3-installer google-android-build-tools-24.0.0-installer google-android-build-tools-24.0.1-installer google-android-build-tools-24.0.2-installer google-android-build-tools-24.0.3-installer google-android-build-tools-25.0.0-installer google-android-build-tools-25.0.1-installer google-android-build-tools-25.0.2-installer google-android-build-tools-25.0.3-installer google-android-build-tools-26.0.0-installer google-android-build-tools-26.0.1-installer google-android-build-tools-26.0.2-installer google-android-build-tools-26.0.3-installer google-android-build-tools-27.0.0-installer google-android-build-tools-27.0.1-installer google-android-build-tools-27.0.2-installer google-android-build-tools-27.0.3-installer google-android-build-tools-28.0.0-installer google-android-build-tools-28.0.1-installer google-android-build-tools-28.0.2-installer google-android-build-tools-28.0.3-installer google-android-build-tools-29.0.0-installer google-android-build-tools-29.0.1-installer google-android-build-tools-29.0.2-installer google-android-build-tools-29.0.3-installer google-android-build-tools-30.0.0-installer google-android-build-tools-30.0.1-installer google-android-build-tools-30.0.3-installer google-android-build-tools-31.0.0-installer google-android-build-tools-32.0.0-installer google-android-build-tools-33.0.0-installer google-android-build-tools-33.0.1-installer google-android-build-tools-33.0.2-installer google-android-build-tools-33.0.3-installer google-android-build-tools-34.0.0-installer google-android-build-tools-installer Conflicts: aidl google-android-build-tools-19.1.0-installer google-android-build-tools-20.0.0-installer google-android-build-tools-21.1.2-installer google-android-build-tools-22.0.1-installer google-android-build-tools-23.0.1-installer google-android-build-tools-23.0.2-installer google-android-build-tools-23.0.3-installer google-android-build-tools-24.0.0-installer google-android-build-tools-24.0.1-installer google-android-build-tools-24.0.2-installer google-android-build-tools-24.0.3-installer google-android-build-tools-25.0.0-installer
Bug#1065667: RFS: mini-httpd/1.30-9 -- Small HTTP server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mini-httpd": * Package name : mini-httpd Version : 1.30-9 Upstream contact : Jef Poskanzer j...@mail.acme.com * URL : https://www.acme.com/software/mini_httpd * License : BSD-2-clause * Vcs : https://salsa.debian.org/debian/mini-httpd Section : web The source builds the following binary packages: mini-httpd - Small HTTP server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mini-httpd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-9.dsc Changes since the last upload: * Added patch fixing NPH scripts (SSL) getting an additional HTTP/1.0 200 OK header before the actual expected one. This violates the CGI RFC (RFC-3875). (Closes: #1064656) * Merged branch fixing mini-httpd starting too early after reboot. This only happened using the old init.d script. The systemd service is not affected. Thanks, Jean ! Regards, -- Alexandru Mihail signature.asc Description: This is a digitally signed message part
Bug#998627:
On Sat, 17 Feb 2024 22:38:57 +0800 an xiao > Hello, > > Paragon-software is active enough on their subsystem, > and NTFS3 is extremely stable now. > Please consider enabling the NTFS3 driver for sid. > > Thinks and best regards, > Littlewhite Hi, today was a pull request submitted which removes the old ntfs driver from kernel [1]. Ok it's not enabled in Debian. But it also says that ntfs3 is a full replacement and that Archlinux has enabled it since 5.15 Would be nice to have it enabled in Debian too. TIA Felix [1] https://lore.kernel.org/lkml/20240308-vfs-ntfs-ede727d2a142@brauner/
Bug#1065636: kwartz-client: Please review debconf template
Hello Geoges, Am Fri, Mar 08, 2024 at 09:37:26AM +0100 schrieb Georges Khaznadar: > Hello Helge, I modified the debconf template, following your > recommendations, thank you! I still think asking debian-l10n-english is a good idea, but this is of course your preference. > As a side effet, it invalidates the translation you sent me previously; > I am uploading the modified templates, which will close both bug > reports. Well, it does this for all translations. It would have been nice if you could have simply included it, then it's easier for us translators to update it. (Just for next time). You'll receive the updated de.po probably in a few days (pending availability of ressources). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1065345: pipewire-jack: Improve package description
Hello, Le dim. 3 mars 2024 à 10:24, Chris Joelly a écrit : > In my point of view it is not clearly understandable fromthe package > desciptions or package docs how pipewire-jack and libspa-0.2-jack relate. I > understood that pipewire-jack, aside from being a plugin, is a implementation > of a JACK server based on JACK API and pipewire. And, I understood > libspa-0.2-jack is a lib which is needed for pipewire to connect to a JACK > server. These are two different things imho. Looks like a duplicate of https://bugs.debian.org/1062262 Now, we have (only in git for now): pipewire-jack: This package contains a plugin for JACK applications to output via PipeWire. libspa-0.2-jack: This package contains a plugin to make PipeWire able to connect to a JACK server, which will be used for audio playback and recording. I guess it makes things clearer? Feel free to create a merge request to improve the description. > But I learned that JACK client applications can not connect to pipewire-jack > when libspa-0.2-jack is not installed. Thus, libspa-0.2-jack is too needed > when > JACK clients want to connect to pipewire-jack, basically making it a > dependency? Heu no, I just tried to remove libspa-0.2-jack, then run (after a reboot) $ pw-jack sndfile-jackplay my_random_wave_file and it works. Best, Dylan
Bug#1059534: DEP17: handle /usr-move for gzip and its diversions by zutils
On 3/8/24 15:28, Helmut Grohne wrote: > $FILE needs to be used here. thanks. > I was about to NMU zutils. Can you move ahead soonish? Once zutils is > uploaded, I can go ahead with gzip. sure, will upload in ~3h from now. Regards, Daniel
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
Hi This address is listed as a maintainer on the Compiz package search page. 0.8.18 black screens on boot after a recent update when building a iso with livebuild. I have been building the xfce-Compiz iso for about 4 months without issue. The xfce (testing amd64) iso is built without errors, but it is unusable with the black screen. Rebuilding the source package does not fix it. I cant seem to get any more info with the black screen, ctrl+alt+F(any number) stays a black screen and booting into safe mode also results in a black screen. Xfce images without compiz build and work fine. Thanks Jim
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
Not sure if this helps, but I keep package lists of each build. Here is a diff of 2/24 build (works) vs 3/24 (broken). https://spins.tuxfamily.org/package-list-diff.txt I dont know if any changes would break compiz, but at least its more info. Jim On 3/6/24 11:25, Steve Langasek wrote: On Wed, Mar 06, 2024 at 06:19:48PM +0100, Colomban Wendling wrote: Le 06/03/2024 à 17:31, Steve Langasek a écrit : On Wed, Mar 06, 2024 at 03:46:41PM +0100, Colomban Wendling wrote: Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they have extra clues. The only change in the NMU was to rename the libdecoration0 package to libdecoration0t64 for the 64-bit time_t transition. Unless this managed to break the *contents* of that package (i.e. the library has gone missing), this should not have had any effect on the behavior of compiz. So the package has not been rebuilt with different flags or anything? Not *deliberately* as part of this upload. The only change to flags should be on 32-bit architectures, excluding i386. I have assumed you are not trying to run compiz on one of these archs! But the toolchain also evolves over time, so this could certainly be a misbuild due to underlying changes. Anyway, I hardly expect this to be an issue, I just wanted to eliminate the only Compiz-side change that happened in the last months.
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
Le 06/03/2024 à 16:59, James Bielefeldt a écrit : I am using testing. I create Debian spins that are rolling release based on testing. it's the same package in standard testing and unstable to my knowledge. Unstable recently got 2:0.8.18-5.1 -- yet as Steve said, it should not affect anything. they all have the same version number. The package is also seriously outdated. Compiz is at 9.14 but the package is 8 point something. Well, yes and no. Compiz is a complicated beast, and version 0.9 is a C++ rewrite by Ubuntu, that is now basically unmaintained. Compiz 0.8, also known as "compiz reloaded", is the pre-Ubuntu rewrite and has been continued separately. Effectively nowadays it's 2 different (yet similar) software, and 0.9 is mostly discontinued, and 0.8 is maintained albeit not seeing muhc activity lately. I tried to build it from the Ubuntu sources, but they errored out and are beyond me. My main thing is themeing and polishing the desktop. I do have a live build script if you want it. Just not sure how I'd get it to you. I don't think I'd have the time to dive this deep, and it would help immensely if you could try and gather some more information as to why Compiz is having issues. Logs from the kernel, X and the Xfce sessions are likely the most interesting bits where you might find more information to pinpoint the issue. Failing that, one interesting thing you could possibly attempt is to see whether an image with the exact same set of packages work fine if you don't *run* Compiz. Basically build the Compiz image, and simply adjust the configuration not to run it (but use e.g. xfwm4). You could also try and play with the Compiz plugins and configuration to see if one in particular is at fault, or if it's the core itself. Regards, Colomban
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
Hello James, Unfortunately I can't test this for the moment, but: Le 06/03/2024 à 15:03, James Bielefeldt a écrit : This address is listed as a maintainer on the Compiz package search page. 0.8.18 black screens on boot after a recent update when building a iso with livebuild. I have been building the xfce-Compiz iso for about 4 months without issue. The xfce (testing amd64) iso is built without errors, but it is unusable with the black screen. Rebuilding the source package does not fix it. Are you sure you're not using unstable? FWIW, there's no recent changes to the Compiz packages in testing, last ones were from about a year ago. However, there's a large transition currently happening in unstable, which affects Compiz as well. Maybe it could have an unknown side effect you're seeing? I cant seem to get any more info with the black screen, ctrl+alt+F(any number) stays a black screen and booting into safe mode also results in a black screen. Xfce images without compiz build and work fine. Maybe you could try SSHing to the machine to gather more data? Or possibly access the logs any other way? It could possibly be fairly unrelated to Compiz itself, but rather something else in the graphic stack (OpenGL? so maybe mesa, the kernel or something?) that affects Compiz more than others? Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they have extra clues. Note that you probably should report a bug, although it's understandably harder with scarce data to reference. Regards, Colomban
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
Le 06/03/2024 à 17:31, Steve Langasek a écrit : On Wed, Mar 06, 2024 at 03:46:41PM +0100, Colomban Wendling wrote: Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they have extra clues. The only change in the NMU was to rename the libdecoration0 package to libdecoration0t64 for the 64-bit time_t transition. Unless this managed to break the *contents* of that package (i.e. the library has gone missing), this should not have had any effect on the behavior of compiz. So the package has not been rebuilt with different flags or anything? Anyway, I hardly expect this to be an issue, I just wanted to eliminate the only Compiz-side change that happened in the last months. Colomban
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
On Wed, Mar 06, 2024 at 03:46:41PM +0100, Colomban Wendling wrote: > Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they > have extra clues. The only change in the NMU was to rename the libdecoration0 package to libdecoration0t64 for the 64-bit time_t transition. Unless this managed to break the *contents* of that package (i.e. the library has gone missing), this should not have had any effect on the behavior of compiz. > Note that you probably should report a bug, although it's understandably > harder with scarce data to reference. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
On Wed, Mar 06, 2024 at 06:19:48PM +0100, Colomban Wendling wrote: > Le 06/03/2024 à 17:31, Steve Langasek a écrit : > > On Wed, Mar 06, 2024 at 03:46:41PM +0100, Colomban Wendling wrote: > > > Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they > > > have extra clues. > > The only change in the NMU was to rename the libdecoration0 package to > > libdecoration0t64 for the 64-bit time_t transition. Unless this managed to > > break the *contents* of that package (i.e. the library has gone missing), > > this should not have had any effect on the behavior of compiz. > So the package has not been rebuilt with different flags or anything? Not *deliberately* as part of this upload. The only change to flags should be on 32-bit architectures, excluding i386. I have assumed you are not trying to run compiz on one of these archs! But the toolchain also evolves over time, so this could certainly be a misbuild due to underlying changes. > Anyway, I hardly expect this to be an issue, I just wanted to eliminate the > only Compiz-side change that happened in the last months. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1059534: DEP17: handle /usr-move for gzip and its diversions by zutils
Hi Daniel, On Fri, Mar 08, 2024 at 09:38:59AM +0100, Daniel Baumann wrote: > Just to be sure - I think I've found a typo in the latest iteration of > the patch, could you please confirm? > > https://git.progress-linux.org/users/daniel.baumann/debian/packages/zutils/commit/?id=a4f81b9df9543f588c052861426469405603fb1d I confirm that my last patch evidently is not correct and that the use of $TOOL is wrong. Unfortunately, $TRUENAME is also wrong and $FILE needs to be used here. I was about to NMU zutils. Can you move ahead soonish? Once zutils is uploaded, I can go ahead with gzip. Helmut
Bug#1065439: dpkg-buildflags: add HIPFLAGS to supported flags
On Thu, Mar 07, 2024 at 04:00:22AM +0100, Guillem Jover wrote: > > When packaging the AMD ROCm GPU libraries for Debian, we are currently > > using CXX=hipcc or CXX=clang++ to build libraries written in HIP as if > > they were written in C++. > > I guess we should also add HIPCXX (defaulting to -hipcc > and HIPCXX_FOR_BUILD (defaulting to -hipcc when cross > compiling, otherwise to hipcc) like with the other toolchains? An > apt-file query seems to indicate thee hipcc package provides no > triplet-qualified toolchains? Which means automatic cross-compiling > is going to be painful given our current infrastructure. I've tried to read a bit into their faq and my impression is that HIP currently is x86_64-only and when it is not, the use of clang (which notoriously refuse cooperating with cross building efforts) makes it practically impossible to do any cross building. In essence, the HIP ecosystem will opt out of cross building, but then the kind of software that HIP targets requires beefy hardware where cross building isn't very relevant, right? Just make sure to not require HIP for building HIP (i.e. do not cause bootstrapping problems). > If support for this is really missing from the looks of it, we can > always postpone adding the compiler tool variables for now until this > is implemented (we can still add the HIPFLAGS variables though). I'm > CCing the debian-cross list for further insight. I think HIPFLAGS is the right way to go about this. > > This necessitates filtering out flags that are not supported when > > building HIP language code. For example, the rocsparse d/rules include: > > > > export CXX=hipcc > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-fortify optimize=-lto > > > > # filter incompatible options from affecting device code > > CXXFLAGS := $(subst -fstack-protector-strong,-Xarch_host > > -fstack-protector-strong,$(CXXFLAGS)) > > CXXFLAGS := $(subst -fcf-protection,-Xarch_host > > -fcf-protection,$(CXXFLAGS)) > > > > In the lines above, we are prepending `-Xarch_host` to prevent certain > > flags from being applied to device code (i.e., GPU code) while still > > ensuring that they are applied to host code (i.e., CPU code). If dpkg were to provide HIPFLAGS, you could just export CXXFLAGS:=$(HIPFLAGS). Generally, reusing CXX in this way is a really bad idea on the upstream side, but hardly preventable. It is very plausible to eventually have to build an source package containing both C++ code and HIP code and then you have no correct way of setting CXX. So from a dpkg point of view, treating HIP as a new language with new variables makes most sense, but it also means that source packages using these variables will have to do the variable renaming themselves forever (and thus retaining the ability to correctly scope those renames). Helmut
Bug#1065595: cyrus-sasl2: Please add nodoc build profile to allow disabling documentation
On Thu, Mar 07, 2024 at 08:37:12AM +0100, John Paul Adrian Glaubitz wrote: > cyrus-sasl2 is one of the core dependencies required for bootstrapping Debian > but requires the Pyton package Sphinx for building documentation. This can be > easily avoided by removing the "doc-html" target during build. This way, the > python3-sphinx-rtd-theme build dependency can be omitted. Hmm, yes. This has kinda been addressed for the cross case by annotating the relevant dependency :native, but I see how this is still relevant natively. > It would be ideal for a "nodoc" build profile which I am asking to be added > here. Please don't. cyrus-sasl2 has split out its documentation to an Arch:all package. As such, doing an arch-only build should already skip documentation. I see that this is not how cyrus-sasl2 is packaged, but demoting the sphinx dependency to Build-Depends-Indep is a much better solution, because nodoc is a gross mess and you never know what goes missing there. Instead, with the arch/indep split, we have a quite good understanding of what the build output will be. It also means that buildds immediately benefit from the change and you don't have to do a binary upload. So please don't do nodoc. Do a proper arch/indep split instead. Helmut
Bug#1065666: mesa: Upgrading to mesa from testing breaks compiz
Source: mesa Version: 23.3.5-1 Severity: serious Tags: a11y Justification: breaks compiz Hello, When upgrading mesa to the version from testing, compiz does not start any more. I tried both upgrading only mesa (and deps), as well as mesa and the rest of the system, with the same result. compiz gets stuck here: #0 0x7f15fadefa80 in __GI___poll (fds=fds@entry=0x7ffc95974370, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f15facd94d3 in poll (__timeout=-1, __nfds=1, __fds=0x7ffc95974370) at /usr/include/x86_64-linux-gnu/bits/poll2.h:47 #2 read_block (len=8, buf=0x56080e7564e0, fd=4) at ../../src/xcb_in.c:394 #3 _xcb_in_read_block (c=c@entry=0x56080e75ebb0, buf=0x56080e7564e0, len=len@entry=8) at ../../src/xcb_in.c:1087 #4 0x7f15facd6b56 in read_setup (c=0x56080e75ebb0) at ../../src/xcb_conn.c:180 #5 xcb_connect_to_fd (fd=fd@entry=4, auth_info=auth_info@entry=0x7ffc959744b0) at ../../src/xcb_conn.c:384 #6 0x7f15facdb192 in xcb_connect_to_display_with_auth_info (displayname=displayname@entry=0x0, auth=auth@entry=0x0, screenp=screenp@entry=0x7ffc959745ac) at ../../src/xcb_util.c:536 #7 0x7f15facdb30a in xcb_connect (displayname=displayname@entry=0x0, screenp=screenp@entry=0x7ffc959745ac) at ../../src/xcb_util.c:493 #8 0x7f15f83081cd in device_select_find_xcb_pci_default (devices=devices@entry=0x56080e7564c0, device_count=device_count@entry=1) at ../src/vulkan/device-select-layer/device_select_x11.c:72 #9 0x7f15f8307cfb in get_default_device (expose_only_one_dev=, pPhysicalDevices=, physical_device_count=1, selection=, info=) at ../src/vulkan/device-select-layer/device_select_layer.c:498 #10 device_select_EnumeratePhysicalDevices (instance=, pPhysicalDeviceCount=0x7ffc95974740, pPhysicalDevices=0x7ffc95974760) at ../src/vulkan/device-select-layer/device_select_layer.c:594 #11 0x7f15f8350a9c in vkEnumeratePhysicalDevices () from /lib/x86_64-linux-gnu/libvulkan.so.1 #12 0x7f15f64aa37e in choose_pdev (dev_minor=-1, dev_major=-1, screen=0x56080e732cc0) at ../src/gallium/drivers/zink/zink_screen.c:1637 #13 zink_internal_create_screen (config=, dev_major=dev_major@entry=-1, dev_minor=dev_minor@entry=-1) at ../src/gallium/drivers/zink/zink_screen.c:3210 #14 0x7f15f64ab73e in zink_create_screen (winsys=, config=) at ../src/gallium/drivers/zink/zink_screen.c:3557 #15 0x7f15f611a2d5 in pipe_loader_sw_create_screen (dev=, config=, sw_vk=) at ../src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c:426 #16 0x7f15f611a218 in pipe_loader_create_screen_vk (dev=0x56080e72ce20, sw_vk=sw_vk@entry=false) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:184 #17 0x7f15f611a24b in pipe_loader_create_screen (dev=) at ../src/gallium/auxiliary/pipe-loader/pipe_loader.c:190 #18 0x7f15f5ab6c2e in kopper_init_screen (screen=0x56080e729360) at ../src/gallium/frontends/dri/kopper.c:134 #19 0x7f15f5abb6dc in driCreateNewScreen2 (scrn=0, fd=-1, loader_extensions=0x7f15fa8e47e0 , driver_extensions=, driver_configs=0x7ffc95975370, data=0x56080e696910) at ../src/gallium/frontends/dri/dri_util.c:139 #20 0x7f15fa8a3523 in driswCreateScreenDriver (screen=0, priv=0x56080e694430, driver=0x7f15fa8cc31b "zink") at ../src/glx/drisw_glx.c:979 #21 0x7f15fa8a8401 in AllocAndFetchScreenConfigs (dpy=dpy@entry=0x56080e3c0270, priv=priv@entry=0x56080e694430, zink=zink@entry=1) at ../src/glx/glxext.c:798 #22 0x7f15fa8a9385 in __glXInitialize (dpy=dpy@entry=0x56080e3c0270) at ../src/glx/glxext.c:928 #23 0x7f15fa8a61d6 in GetGLXPrivScreenConfig (ppsc=, ppriv=, scrn=0, dpy=0x56080e3c0270) at ../src/glx/glxcmds.c:147 #24 glXGetConfig (dpy=0x56080e3c0270, vis=0x56080e676820, attribute=1, value_return=0x7ffc959754ec) at ../src/glx/glxcmds.c:722 #25 0x56080c4764e2 in addScreen (display=display@entry=0x56080e3beef0, screenNum=screenNum@entry=0, wmSnSelectionWindow=wmSnSelectionWindow@entry=6291457, wmSnAtom=wmSnAtom@entry=436, wmSnTimestamp=wmSnTimestamp@entry=244386) at ./src/screen.c:1984 #26 0x56080c471407 in addDisplay (name=name@entry=0x0) at ./src/display.c:2755 #27 0x56080c46b8e2 in main (argc=, argv=0x7ffc95976278) at ./src/main.c:519 (gdb) info thread Id Target Id Frame * 1Thread 0x7f15fac147c0 (LWP 1034) "compiz" 0x7f15fadefa80 in __GI___poll (fds=fds@entry=0x7ffc95974370, nfds=nfds@entry=1, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 (I'll bounce to this bts the original report from a compiz user) Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500,
Bug#967941: Bug appeared again
Hello, I'm affected by this problem as well on bookworm (and bullseye before that). Sébastien's suggestion did work for me, merci ! Nautilus properly (and promptly) generates all video thumbnails. In my case, I needed to install: * libopenblas0-serial * libopenblas-serial-dev in order to satisfy the dependencies of python3-matplotlib, while removing libopenblas0-pthread. Best regards, Santiago
Bug#1065665: nxt-firmware: implicit type conversion from negative float to char gives 0
Package: nxt-firmware
Version: 1.29.2-1
Severity: important
Tags: upstream
Dear Maintainer, following code debug1.nxc:
task main()
{
float a = -12.34;
NumOut(0, 32, a);
char b = a;
NumOut(0, 24, b);
Wait(3000);
}
using nbc 1.2.1.r4+dfsg-11+b1 from Debian bookworm,
compile with
$ nbc debug1.nxc -O=debug1.rxe
upload with
$ nbc -b -d debug1.rxe
with nxt-firmware 1.29.2-1 from Debian bookworm
a948539b318073287733c618ea8d31f2 nxt_firmware.bin
outputs on LCD:
-12.34
0
same with 1.29.4 from upstream.
with NXT Enhanced Firmware, aka John Hansen Firmware, aka NBC/NXC Firmware
a2a17802cde9bf610944757ab7ca6d92 lms_arm_nbcnxc_132_20120810_0021.rfw
outputs on LCD:
-12.34
-12
as expected.
This currently makes OpenRoberta Lab pretty unusable with this firmware
because many negative float -> char conversions occur
Thank you, Andy
Bug#1065646: Additional information
Control: tags -1 pending Hi Vladimir, Am Fri, Mar 08, 2024 at 07:51:44PM +1300 schrieb Vladimir Petko: > Would it be possible to consider a merge request[1] that addresses this > issue? thanks a lot for the bug report and the patch. I accepted the MR. I intended to update the package at the same time to latest upstream but this failed building. As always in this cases I need to trust the Java insight of Pierre - thus the upload will be done once Pierre found the time he needs to decide whether it is sensible to work on the new ustream version or for the moment to the old one to get this bug fixed quickly. @Pierre: I've created branch 2.17.3 incorporating a few easy patch refreshes for the new version. I did not used master branch since I have no idea how hard this would be: Compiling with JDK Java compiler API. /build/igv-2.17.3+dfsg/src/test/java/org/broad/igv/ucsc/bb/BBFeatureSourceTest.java:102: error: Ignore is not a repeatable annotation type @Ignore ^ /build/igv-2.17.3+dfsg/src/test/java/org/broad/igv/ucsc/bb/BBFeatureSourceTest.java:203: error: Ignore is not a repeatable annotation type @Ignore ^ Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 2 errors :compileTestJava FAILED Kind regards Andreas. -- http://fam-tille.de
Bug#1060318: silx: autopkgtest failure with Python 3.12
In order to reproduce the bug, install python3-silx 2.0.0+dfsg-1 python3-pytest-xvfb pocl-opencl-icd then $ pytest --pyargs silx.image.test.test_medianfilter -v === test session starts === platform linux -- Python 3.11.8, pytest-8.0.2, pluggy-1.4.0 -- /usr/bin/python3 cachedir: .pytest_cache rootdir: /home/picca/debian/science-team/pyvkfft plugins: anyio-4.2.0, dials-data-2.4.0, xvfb-3.0.0 collected 2 items ::TestMedianFilterEngines::testCppMedFilt2d PASSED [ 50%] ::TestMedianFilterEngines::testOpenCLMedFilt2d Abandon the OpenCL test fails
Bug#1065664: ITP: smallerc -- single-pass C compiler for 16- and 32-bit platforms
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: smallerc Version : 1.0.1 Upstream Author : Alexey Frunze * URL : https://github.com/alexfru/SmallerC * License : BSD Programming Lang: C Description : single-pass C compiler for 16- and 32-bit x86/MIPS platforms Smaller C is a simple single-pass C compiler with support for most of C89 and C99. It targets 16- and 32-bit x86, and MIPS, on DOS, Windows, Linux, and older versions of macOS. . Smaller C is primarily useful for building DOS and UEFI binaries. This is a prerequisite for dosemu2.
