Bug#1018924: libgc FTBFS: architecture-specific symbol handling removed
Hi Ivan, On Mon, Sep 05, 2022 at 12:17:10AM +0300, Ivan Maidanski wrote: > Let me go thru all items you warry about. Please be sure both Ian and I pay > attention to the quality of the prepared releases. Sometimes mistakes happen > — it is essential to promptly react and think of the proper fix or workaround > in such situations. Thank you. I concur. Please upload a fixed version quickly. This currently breaks half of the bootstrap ci jobs, which makes me blind to breakage in other packages. Urgency is needed here. > The builds fail because of a change in some mangled names — probably the > reason is changing of noexcept/throw() specification in operator delete > (libgc tries to follow C++ standard but if this breaks some ABI, it could be > configured at build time thru macros). I need more time to check the > situation deeper. That would sound reasonable if the upload had been done to experimental. The combination of urgency and "need more time" is unfortunate. I fear that doing it improperly would be making it worse as symbol issues can have a rippling effect. Admittedly all missing symbols on the most recent upload seem to be C++ symbols. That much is plausible at least. To make your (and my) life easier, I suggest that you use modern symbol features (man deb-src-symbols). In particular, you can restrict symbols to 32bit or 64bit using "(arch-bits=32)symbol..." and you can use C++ symbol mangling using "(c++)unmangled...". > > its symbol handling is essentially stripped of all the > >architecture-specific patterns that we have accumulated over the years > > These stripped symbols are actually «leaked» internal symbols of libgc, > additionally I am not aware of any libgc client S/W which relies on these > internal symbols. Let me know please if someone is using any of the stripped > symbols. There is no practical reason of keeping these symbols in libgc > except for a formal one. Please correct me if I am wrong. I happen to not understand which symbols are internal and which are not. I really cannot tell. I'm more than happy if those really are unused. > > * Lots of symbols were dropped from the symbols file without bumping > >soname. Possibly, this may lead to incorrect dependencies on libgc in > >downstream builds. > > Bumping soname indicates no backward compatibility. This has some negative > drawback (e.g. system should have 2 versions of libraries, client S/W does > not benefit from the new library version until client binary is rebuilt). I > avoid deletion or incompatible changes of API symbols between libgc releases. > (Unfortunately there’s an issues with a mangled name I wrote above.) I’ve > explained the situation about dropping of lots of symbols above. My opinion > this should not lead to incorrect dependencies on libgc but how could we > figure it out practically. If it would turn out later that some of dropped > symbols are nonetheless in use, then I think it would not be complicated to > fix it on the libgc side. If you look into the differences, it's not just C++ symbols that have been dropped. Here is a list of dropped symbols: < GC_FirstDLOpenedLinkMap@Base 1:7.2d < (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d < (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d < (arch=!nios2 !sh4)GC_acquire_mark_lock@Base 1:8.0 < (arch=!nios2 !sh4)GC_active_count@Base 1:8.0 < GC_add_ext_descriptor@Base 1:7.2d < GC_add_map_entry@Base 1:7.2d < GC_add_roots_inner@Base 1:7.2d < GC_add_smashed@Base 1:7.2d < GC_add_to_black_list_normal@Base 1:7.2d < GC_add_to_black_list_stack@Base 1:7.2d < GC_add_to_fl@Base 1:7.2d < GC_add_to_heap@Base 1:7.2d < GC_adj_bytes_allocd@Base 1:7.2d < GC_all_bottom_indices@Base 1:7.2d < GC_all_bottom_indices_end@Base 1:7.2d < GC_alloc_large@Base 1:7.2d < GC_alloc_large_and_clear@Base 1:7.2d < GC_alloc_reclaim_list@Base 1:7.2d < GC_allocate_ml@Base 1:8.0 < GC_allochblk@Base 1:7.2d < GC_allochblk_nth@Base 1:7.2d < GC_allocobj@Base 1:7.2d < GC_apply_to_all_blocks@Base 1:7.2d < GC_approx_sp@Base 1:7.2d < GC_array_kind@Base 1:7.2d < GC_array_mark_proc@Base 1:7.2d < GC_array_mark_proc_index@Base 1:7.2d < GC_avail_descr@Base 1:7.2d < GC_bl_init@Base 1:7.2d < GC_bl_init_no_interiors@Base 1:7.2d < GC_black_list_spacing@Base 1:7.2d < GC_block_empty@Base 1:7.2d < GC_block_nearly_full@Base 1:7.2d < GC_block_was_dirty@Base 1:7.2d < GC_bm_table@Base 1:7.2d < (arch=!kfreebsd-amd64 !kfreebsd-i386)GC_brief_async_signal_safe_sleep@Base 1:7.6.4 < GC_build_fl2@Base 1:7.2d < GC_build_fl4@Base 1:7.2d < GC_build_fl@Base 1:7.2d < GC_build_fl_clear2@Base 1:7.2d < GC_build_fl_clear4@Base 1:7.2d < (arch=!nios2 !sh4)GC_bytes_allocd_tmp@Base 1:8.0 < GC_bytes_found@Base 1:7.2d < GC_check_annotated_obj@Base 1:7.2d < GC_check_finalizer_nested@Base 1:7.2d < GC_check_heap@Base 1:7.2d < GC_check_heap_block@Base 1:7.2d < GC_check_heap_proc@Base 1:7.2d < GC_check_leaked@Base 1:7.2d < GC_clear_a_few_f
Bug#1018893: support for unshare in some form
Hi Johannes, On Mon, Sep 05, 2022 at 07:52:13AM +0200, Johannes Schauer Marin Rodrigues wrote: > I just uploaded mmdebstrap 1.2.0 which adds a few more --skip options. The > ones > that might be useful here are: > > - --skip=chroot/mount -- don't mount anything > - --skip=chroot/mount/proc -- only don't mount /proc > - --skip=chroot/mount/sys -- only don't mount /sys > > Maybe this makes implementing this easier? While that may make the combination simpler, the extra copy involved here is making things inefficient. Why would piuparts need two temporary chroots? It should just be using the one mmdebstrap prepared and be happy with that. So I do think we need a new piuparts option that explains how --existing-chroot should work: * Copy the chroot as a template. * Actually use it directly. While we often want the former, in this case, we want the latter. Without an extra option, piuparts will be unable to tell those two cases apart and always use it as a template. Helmut
Bug#522453: fgconsole doesn't work as user
* Michael Schutte , 2009-04-05 10:41:
This is true. It doesn’t only affect fgconsole, but also chvt, openvt
and any other kbd utility which tries to get a console file descriptor.
These programs do their job by trying to open/ioctl these files (in
this order):
/proc/self/fd/0 (is a pseudo tty in your case)
/dev/tty(also PTY)
/dev/tty0 (only accessible to root)
/dev/vc/0 (doesn’t exist nowadays)
/dev/console(root)
std{in,out,err} (PTY)
As none of these is able to respond to a VT_GETSTATE ioctl, fgconsole
and friends fail. I’m afraid this situation won’t change.
These days there's world-readable /sys/class/tty/tty0/active, so
fgconsole could be patched to use that.
--
Jakub Wilk
Bug#1018893: support for unshare in some form
Hi, Quoting Helmut Grohne (2022-09-01 20:31:56) > piuparts has a --existing-chroot option. Unfortunately, it doesn't exactly do > what we need here. It uses the given directory as a template and tries to > copy it. That is bound to fail as mmdebstrap has kindly mounted /sys and > /proc and such. It would be nice if piuparts got some --use-existing option > that would make it just use that chroot directly. I just uploaded mmdebstrap 1.2.0 which adds a few more --skip options. The ones that might be useful here are: - --skip=chroot/mount -- don't mount anything - --skip=chroot/mount/proc -- only don't mount /proc - --skip=chroot/mount/sys -- only don't mount /sys Maybe this makes implementing this easier? Thanks! cheers, josch signature.asc Description: signature
Bug#967353: freeciv: depends on deprecated GTK 2
On Tue, 30 Aug 2022 09:10:03 +0200 Stephen Kitt wrote: > On Mon, 29 Aug 2022 20:43:01 +0200, Tobias Frost wrote: > > On Mon, Aug 29, 2022 at 08:33:12PM +0200, Stephen Kitt wrote: > > > On Mon, 29 Aug 2022 20:06:12 +0200, Tobias Frost wrote: > > > > On Tue, 04 Aug 2020 11:38:27 +0100 s...@debian.org wrote: > > > > > Source: freeciv > > > > > Severity: normal > > > > > User: pkg-gnome-maintain...@lists.alioth.debian.org > > > > > Usertags: gtk2 oldlibs > > > > > Control: block 947713 by -1 > > > > > > > > > > This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces > > > > > binary packages with a Depends on GTK 2. > > > > > > > > (...) > > > > > > > > Upstream says in 3.0.3 (doc/README.packaging): > > > > > * Gtk2-client is no longer considered maintained client > > > > > > > > So I guess the gtk2 client should not be released with bookworm… > > > > > > > > Any thoughts (question directed to the games team)? > > > > > > It’s gone entirely in 3.0.3, isn’t it? So if you’re upgrading to that > > > release, it seems the freeciv-gtk package should be dropped (or rather, > > > turned into a transitional package pulling freeciv-gtk3). > > > > The client is still there in 3.0.3 (but needs to be enabled manually, > > at least it builds; not yet there to see if it works…) > > Ah yes, I started with the main branch and didn’t check 3.0.3 thoroughly > enough. > > However given that GTK 2 is obsolete in general, and the existence of other > (maintained) Freeciv clients, I don’t think it’s all useful to keep the GTK 2 > client for Bookworm. > After pondering back and forth a bit, I finally made uo my mind and I agree: We should drop the GTK2 support before bookworm. While there is no urgency, we have GTK3 and GTK3.22 directly capable of replacing the GTK2 client, and GTK2 itself is showing its age… Bookworm will be supported ~3 years after its release, with an estimated release of it next summer, this would mean ~mid 2026. While it is not likely that there will be issues, I don't want to put the burden of fixing something upstream stopped actively maintaining on other teams as well. Finally, I think the release of a major version is a good opportunity to clean up stuff. -- tobi
Bug#1019183: librust-uuid+rand-dev: impossible to install package
On Mon, 05 Sep 2022 06:52:57 +0200 Jonas Smedegaard wrote: librust-uuid+rand-dev is impossible to install: Depends on missing package librust-uuid-dev (= 0.8.1-5) Hi Jonas, librust-uuid-dev is now 1.1.2, which has no "rand" feature. You may want to use feature "v4" which is the randomly generated UUID v4, or "fast-rng" that references a "private_rand" feature, using the rand crate rather than getrandom. -- Regards, Blair Noctis OpenPGP_signature Description: OpenPGP digital signature
Bug#1018966: widelands: Crash with layered filesystem error...
Control: tags -1 unreproducible Hi waxhead, thanks for the report! Unfortunatly, I cannot reproduce your issue. At least on this machine, a ls -la /usr/share/games/widelands/data/i18n/fonts/Culmus/TaameyFrankCLM-Medium.ttf yields a result. Wideland starts fine (and also enter Options) without the crash. I've also installed it in a minmimal chroot environment, and all the fonts are pulled in as expected (as widelands-data Depends: on them correctly) Maybe your last apt upgrade did not complete correctly? Can you do a dpkg -l culmus-fancy to see if the font package is installed? -- Thanks, tobi
Bug#1019184: RFS: exif/0.6.22-3 -- command-line utility to show EXIF information in JPEG files
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "exif": * Package name: exif Version : 0.6.22-3 Upstream Author : Dan Fandrich , * URL : https://libexif.github.io/ * License : LGPL-2.1+ * Vcs : https://salsa.debian.org/debian-phototools-team/exif Section : graphics The source builds the following binary packages: exif - command-line utility to show EXIF information in JPEG files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/exif/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/exif/exif_0.6.22-3.dsc Changes since the last upload: exif (0.6.22-3) unstable; urgency=medium . * debian/control: Raise Standards-Version to 4.6.1 (no changes needed). * debian/copyright: Update for 2022. * debian/gbp.conf: Use DEP-14 branch naming; require signed tags. * debian/patches: + Add patch for CVE-2021-27815 (Closes: #1018814). + Prevent NULL pointer dereference with strncpy() in exif/actions.c. Thanks to Aron Xu for forwarding the upstream patch. I currently maintain the related packages libexif and libexif-gtk with DM upload permissions. I would like to take on more responsibility with exif and upload as a DM as well. Regards, -- Hugh McMaster
Bug#1019183: librust-uuid+rand-dev: impossible to install package
Package: librust-uuid+rand-dev Version: 0.8.1-5 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 librust-uuid+rand-dev is impossible to install: Depends on missing package librust-uuid-dev (= 0.8.1-5) - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMVgKYACgkQLHwxRsGg ASH7yA/+OM5w4lxNq/DXpvH1/deH2CUKQ7DD2A3ngwA6EsndGggWCAeyiKmatm78 pWeT0PP7FIVkFBi0ExGmK6/egxTUATC7W1CvWB8N0txrtNoBHtS2O2yeQbrqNV9r Tg9+iQwdbYVHKXuTwh+OEKmZsVufCqGnfvihaICl6mAp6IqAWdD6Y521DlgX8y8R ZadX8SZHKjc3uAhwlU4ENIzkFS+8d9livYBdmrM+m0UK+ITCq4i4+V6TsKOlj4am h9hWy6eagoUKgIPUI9A/j8DWp3IcdaLg2xT4J7MSoF8HcyAGjTDjpv+ZlZOISr3i lvLuUm9oJm7mI8icdxIIUD0pLY49iAn18XDwposAQ+qoRhRUb+o+MfkI2WtcCpi0 /7MTbWCITC+Y0NFq1M7SGHV5yOjEG2xl6I/pTvNOkK1noOtx4oCaHQB+ykm0vst4 7P/40CMs0XDhw+7TJyW2Gf0RtaKf4Qc4ES+T+/1GckGLa4LvnefVAYJkXGMxf/yf zMjeGPjPBvgFUBi4mMGIWWp4ctt5I9/oyjCXY4nOOkt0IfbYoV6d1FlMJnJhCES2 TKnkRad8QABmqEv30R3rXbL5QZp6osT+kuqOosyJ4XA7uPSKO1M3VdP9VCnRsAhL yGNjIczL6K7M8G5/OsFAhUNEQ5bxoIZmYohC02ocBPGxmujMCgE= =ks2S -END PGP SIGNATURE-
Bug#1015044: Not a setuptools-scm issue?
Le lundi 05 septembre 2022 à 08:28 +1000, Brian May a écrit : > On Wed, Aug 03, 2022 at 12:22:32PM +0200, > julien.pu...@gmail.com wrote: > > I'm sorry, but I don't see why you think this is a problem with > > setuptools-scm. > > > > sshuttle's debian/rules asks setuptools-scm to generate a version > > file > > in its clean target. So setuptools-scm does so, and it doesn't look > > invalid. > > > > But it doesn't not correspond to the version file as shipped, so > > dpkg > > protests that the source tree has been modified. > > Please make sure you CC responses to me. Otherwise I won't get them. > > At first glance I thought this was invalid Python code, but oh wait, > I > think this is valid. Problem when dealing with too many languages. > > __version__ = version = '1.1.0' > __version_tuple__ = version_tuple = (1, 1, 0) > > But what seems to be the problem here is that setuptools-scm has > silently changed how it generates this file. Which breaks Debian > packages. > > If you don't agree with me, then assign this bug back to sshuttle and > I > will deal with it. In fact latest upstream sshuttle removes > setuptools-scm support anyway. If I remember well, that generation is done in the clean target: if that's the case, then it's sshuttle's (package's) problem. I see two solutions: - add a patch so the file becomes re-generation invariant ; - add an empty override_dh_whatever_clean in d/rules so the re- generation isn't triggered. Cheers, J.Puydt
Bug#1019182: libthrift-dev: missing /usr/include/thrift/config.h
Package: libthrift-dev Version: 0.16.0-6 Severity: important Line 109 of debian/rules removes config.h so that it no longer gets installed in libthrift-dev. However thrift/Thrift.h includes thrift/thrift-config.h which includes the missing thrift/config.h This causes packages building using thrift to fail. Please restore /usr/include/thrift/config.h as part of the libthrift-dev package. -Maitland
Bug#1019181: Error in KDEConnect desktop file
Package: kdeconnect Version: 21.12.3-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello! The installation of the package "kdeconnect" gives me this error message originated from an error in tis desktop file: - ---error message--- /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "Ein verbundenes Gerät mit KDE Connect öffnen" for key "Comment[de]" in group "Desktop Entry" looks the same as that of key "GenericName[de]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "Abrir en dispositivo conectado a través de KDE Connect" for key "Comment[es]" in group "Desktop Entry" looks the same as that of key "Name[es]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "Avamine ühendatud seadmes KDE Connecti kaudu" for key "Comment[et]" in group "Desktop Entry" looks the same as that of key "Name[et]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "KDE Connect を経由して接続されたデバイスで開く" for key "Comment[ja]" in group "Desktop Entry" looks the same as that of key "Name[ja]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "KDE Connect로 연결된 장치에서 열기" for key "Comment[ko]" in group "Desktop Entry" looks the same as that of key "Name[ko]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "Otwórz na podłączonym urządzeniu przez KDE Connect" for key "Comment[pl]" in group "Desktop Entry" looks the same as that of key "Name[pl]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "கே.டீ.யீ. கனெக்ட் மூலம் இணைந்துள்ள சாதனத்தில் திற" for key "Comment[ta]" in group "Desktop Entry" looks the same as that of key "Name[ta]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "Відкрити на з'єднаному пристрої за допомогою KDE Connect" for key "Comment[uk]" in group "Desktop Entry" looks the same as that of key "Name[uk]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "通过 KDE Connect 在已连接的设备上打开" for key "Comment[zh_CN]" in group "Desktop Entry" looks the same as that of key "GenericName[zh_CN]" /usr/share/applications/org.kde.kdeconnect_open.desktop: warning: value "使用 KDE 連線於連線裝置中開啟" for key "Comment[zh_TW]" in group "Desktop Entry" looks the same as that of key "Name[zh_TW]" /usr/share/applications/org.kde.kdeconnect_open.desktop: error: key "MimeType" is present in group "Desktop Entry", but the type is "Service" while this key is only valid for type "Application" /usr/share/applications/org.kde.kdeconnect_open.desktop: error: key "Exec" is present in group "Desktop Entry", but the type is "Service" while this key is only valid for type "Application" /usr/share/applications/org.kde.kdeconnect_open.desktop: error: key "Terminal" is present in group "Desktop Entry", but the type is "Service" while this key is only valid for type "Application" /usr/share/applications/org.kde.kdeconnect_open.desktop: error: key "Categories" is present in group "Desktop Entry", but the type is "Service" while this key is only valid for type "Application" Error on file "/usr/share/applications/org.kde.kdeconnect_open.desktop": Failed to validate the created desktop file - ---/error message--- Kind regards Joerg Schiermeier - -- System Information: Debian Release: bookworm/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), LANGUAGE=de:en_GB Shell: /bin/sh linked to /usr/bin/dash Init: OpenRC (via /run/openrc), PID 1: init Versions of packages kdeconnect depends on: ii fuse33.11.0-1 ii kio 5.97.0-1 ii kpeople-vcard0.1-2 ii libc62.34-7 ii libfakekey0 0.3+git20170516-2 ii libkf5configcore55.97.0-2 ii libkf5configwidgets5 5.97.0-1 ii libkf5coreaddons55.97.0-1 ii libkf5dbusaddons55.97.0-1 ii libkf5i18n5 5.97.0-1 ii libkf5iconthemes55.97.0-1 ii libkf5kcmutils5 5.97.0+really5.97.0-2 ii libkf5kiocore5 5.97.0-1 ii libkf5kiofilewidgets55.97.0-1 ii libkf5kiogui55.97.0-1 ii libkf5kiowidgets55.97.0-1 ii libkf5notifications5 5.97.0-1 ii libkf5people55.97.0-1 ii libkf5pulseaudioqt3 1.3-2 ii libkf5service-bin5.97.0-1 ii libkf5service5 5.97.0-1 ii libkf5solid5 5.97.0-1 ii libkf5waylandclient5
Bug#1007907: fixed upstream 2.13.1
Any news or plans on this ? Is something blocking progress ? The fix https://github.com/ansible/ansible/pull/77649 went into devel on Jun 7 , ... became release candidate on June 20 ( https://github.com/ansible/ansible/blob/stable-2.13/changelogs/changelog.yaml#L834) and is included in the ansible stable releases since 2.13.1 (also june 20) https://github.com/ansible/ansible/blob/stable-2.13/changelogs/changelog.yaml#L779-L782 Since this https://salsa.debian.org/debian/ansible-core/-/blob/master/debian/patches/0008-support-newer-resolvelib.patch is not even in debian yet .. how about a regular update of ansible-core instead ? Do You need help?
Bug#1003397:
Hi Daichi,
2022年9月3日(土) 15:22 Daichi Fukui :
>
> Hello Iwamatsu-san,
>
> I have drafted a source package of debugbreak.
> I'm doing this because c4core, which you mentioned before, depends on this
> software.
> Kindly find URLs for the ITP below.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017846
> https://mentors.debian.net/package/debugbreak/
>
> I would appreciate it if you review the source package.
This contains a Python script.
/usr/share/debugbreak/gdb/debugbreak-gdb.py
I recommend that you specify gdb for Sugguest.
Best regards,
Nobuhiro
>
> Best,
> Fukui
>
> On Sat, 13 Aug 2022 22:12:35 +0900 Daichi Fukui
> wrote:
> > Hi Iwamatsu-san,
> >
> > > First, This is emedded with C4CORE.
> > > Do you have any plans to package this?
> > > https://github.com/biojppm/c4core
> >
> > I filed an ITP for c4core. For details, take a look at the following.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017088
> >
> > Let's continue discussion about packaging c4core there.
> >
> > Best,
> > Fukui
> >
> > On Mon, 25 Jul 2022 06:58:22 +0900 Nobuhiro Iwamatsu
> > wrote:
> > > Hi Daichi,
> > >
> > > I reviewed your package.
> > >
> > > First, This is emedded with C4CORE.
> > > Do you have any plans to package this?
> > > https://github.com/biojppm/c4core
> > >
> > > debain/control:
> > > development package is required., because this is a library.
> > >
> > > debian/patches:
> > > Currently, this package does not have any patches. so this can delete.
> > >
> > > Best regards,
> > > Nobuhiro
> > >
> > > 2022年7月20日(水) 23:09 Daichi Fukui :
> > >
> > > >
> > > > Hello Iwamatsu-san,
> > > >
> > > > I have drafted a source package of rapidyaml and put it onto my private
> > repository in salsa:
> > > >
> > > > https://salsa.debian.org/dfukui/rapidyaml/-/tree/debian/0.4.1-1
> > > >
> > > > When you have time, can you review the source package and help me
> > upload it to the archive?
> > > >
> > > > Best regards,
> > > > Fukui
> > >
> > >
> > >
> > > --
> > > Nobuhiro Iwamatsu
> > >iwamatsu at {nigauri.org / debian.org}
> > >GPG ID: 40AD1FA6
> > >
> > >
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org / kernel.org}
GPG ID: 5E629EE5232197357B84CF4332247FBB40AD1FA6
Bug#1019173: RM: rust-anymap -- ROM; unmaintained upstream and open CVEs
Package: ftp.debian.org Severity: normal Control: block -1 by 1019171 rust-liquid-derive and rust-liquid-derive are the only users of rust-anymap. Their removal is requested in #1019171.
Bug#1019172: opengrm-ngram FTBFS against libfst 1.7.9
Source: opengrm-ngram
Version: 1.3.2-3
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic
Hi Giulio,
opengrm-ngram fails to build from source in Debian unstable:
[...]
In file included from ./../include/ngram/hist-mapper.h:22,
from ngram-count.cc:17:
./../include/ngram/hist-arc.h:47:16: error: ‘string’ does not name a type; did
you mean ‘stdin’?
47 | static const string &Type() { // Arc type name
|^~
|stdin
[...]
A build log showing this failure in Ubuntu is available at:
https://launchpad.net/ubuntu/+source/opengrm-ngram/1.3.2-3build2/+build/24299140
I attempted to patch the package to make it buildable, but in addition to
the obvious C++ standard fixes, there appear to also be api
incompatibilities with the new libfst which were not straightforwardly
fixable.
[...]
ngram-context.cc:78:8: error: ‘SplitToVector’ is not a member of ‘fst’
78 | fst::SplitToVector(contexts[0], " ", &labels1, true);
|^
[...]
--
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#1019171: RM: rust-liquid-core,rust-liquid-derive -- ROM, NPOASR; relies on unmaintained project and has no rdeps
Package: ftp.debian.org Severity: normal These packages are the only ones relying on rust-anymap, which is unmaintained and has open CVEs. Since the rust-liquid stack wasn't fully packaged, we'd rather just remove it.
Bug#1015044: Not a setuptools-scm issue?
On Wed, Aug 03, 2022 at 12:22:32PM +0200, julien.pu...@gmail.com wrote: > I'm sorry, but I don't see why you think this is a problem with > setuptools-scm. > > sshuttle's debian/rules asks setuptools-scm to generate a version file > in its clean target. So setuptools-scm does so, and it doesn't look > invalid. > > But it doesn't not correspond to the version file as shipped, so dpkg > protests that the source tree has been modified. Please make sure you CC responses to me. Otherwise I won't get them. At first glance I thought this was invalid Python code, but oh wait, I think this is valid. Problem when dealing with too many languages. __version__ = version = '1.1.0' __version_tuple__ = version_tuple = (1, 1, 0) But what seems to be the problem here is that setuptools-scm has silently changed how it generates this file. Which breaks Debian packages. If you don't agree with me, then assign this bug back to sshuttle and I will deal with it. In fact latest upstream sshuttle removes setuptools-scm support anyway. -- Brian May
Bug#1015044: Reassign to sshuttle from setuptools-scm
On Sat, Aug 06, 2022 at 03:57:47PM +0200, julien.pu...@gmail.com wrote: > reassign 1015044 sshutle 1.0.1-1 errr, typo here in the package name. -- Brian May
Bug#1019169: aardvark-dns: fails to build from the source
Source: aardvark-dns Version: 1.0.3-1 Severity: important Tags: ftbfs Dear Maintainer, While rebuilding your package, it pfailed to build from the source at the install-deps stage due to the following error: Unsatisfied APT dependencies: librust-parking-lot-0.11+default-dev:amd64 (>= 0.11.2-~~) To reproduce the failure, use this command: sbuild -d unstable aardvark-dns The full build log is attached for your reference. Please note that this email has been generated semi-automatically. -- Thanks, Andrej sbuild (Debian sbuild) 0.83.2 (29 August 2022) on scw-hardcore-ride +==+ | aardvark-dns (amd64) Sun, 04 Sep 2022 13:31:33 + | +==+ Package: aardvark-dns Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-48c8f5fa-93b4-4833-aba6-1c4264db61fa' with '<>' I: NOTICE: Log filtering will replace 'build/aardvark-dns-vCUvDX/resolver-Tzh5xj' with '<>' +--+ | Update chroot| +--+ Get:1 http://deb.debian.org/debian unstable InRelease [192 kB] Get:2 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB] Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB] Get:4 http://deb.debian.org/debian unstable/main Sources T-2022-09-04-0825.07-F-2022-09-03-1421.07.pdiff [25.3 kB] Get:4 http://deb.debian.org/debian unstable/main Sources T-2022-09-04-0825.07-F-2022-09-03-1421.07.pdiff [25.3 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 Packages T-2022-09-04-0825.07-F-2022-09-03-1421.07.pdiff [53.4 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 Packages T-2022-09-04-0825.07-F-2022-09-03-1421.07.pdiff [53.4 kB] Fetched 398 kB in 2s (231 kB/s) Reading package lists... Reading package lists... Building dependency tree... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Check APT - Checking available source versions... Download source files with APT -- Reading package lists... NOTICE: 'aardvark-dns' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/debian/netavark.git Please use: git clone https://salsa.debian.org/debian/netavark.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 42.2 kB of source archives. Get:1 http://deb.debian.org/debian unstable/main aardvark-dns 1.0.3-1 (dsc) [2473 B] Get:2 http://deb.debian.org/debian unstable/main aardvark-dns 1.0.3-1 (tar) [37.1 kB] Get:3 http://deb.debian.org/debian unstable/main aardvark-dns 1.0.3-1 (diff) [2648 B] Fetched 42.2 kB in 0s (2284 kB/s) Download complete and in download only mode W: Download is performed unsandboxed as root as file 'aardvark-dns_1.0.3-1.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) I: NOTICE: Log filtering will replace 'build/aardvark-dns-vCUvDX/aardvark-dns-1.0.3' with '<>' I: NOTICE: Log filtering will replace 'build/aardvark-dns-vCUvDX' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper-compat (= 13), dh-cargo (>= 25), cargo, librust-anyhow-dev, librust-async-broadcast-dev, librust-chrono-dev, librust-clap+derive-dev, librust-futures-util-dev, librust-resolv-conf-dev, librust-signal-hook-dev, librust-strsim-dev, librust-syslog-dev, librust-termcolor-dev, librust-textwrap-dev, librust-tokio+full-dev, librust-trust-dns-client-dev, librust-trust-dns-proto-dev, librust-trust-dns-server-dev, libstd-rust-dev, rustc, build-essential, fakeroot Filtered Build-Depends: debhelper-compat (= 13), dh-cargo (>= 25), cargo, librust-anyhow-dev, librust-async-broadcast-dev, librust-chrono-dev, librust-clap+derive-dev, librust-futures-util-dev, librust-resolv-conf-dev, librust-signal-hook-dev, librust-strsim-dev, librust-syslog-dev, librust-termcolor-dev, librust-textwrap-dev, librust-tokio+full-dev, librust-trust-dns-client-dev, librust-trust-dns-proto-dev, librust-trust-dns-server-dev, libstd-rust-dev, rustc, build-essential, fa
Bug#1018924: 1018924
> what happend to libgc? It ftbfs on all 32bit architectures and its > symbol handling is essentially stripped of all the architecture-specific > patterns that we have accumulated over the years. I will keep an eye on this with Ivan per his last mail. > * A possibly breaking change for a core package is often done to > experimental first to reduce disruption of development on unstable. > Doing so would have prevented major pain here. Well of course it wasn't supposed to be. I do apologise and there's always something to learn. > * The debian/changelog entry contains duplicates. Mea culpa as I learn gbp's automated changelog generation steps. > * Lots of symbols were dropped from the symbols file without bumping > soname. Possibly, this may lead to incorrect dependencies on libgc in > downstream builds. This was discussed. They were not supposed to be used [1]. We will need to discuss what is happening calmly. > * debian/changelog says that you removed libatomic_ops handling, but > for every new architecture libatomic_ops is still opted in leading to > unnecessary porting work even though built-in atomics generally work > well. This was done with [2]. I agree it's a bug to keep including it as a dependency, which we can handle as a bug [3] > I am also wondering whether this actually is a package hijack as there > is no visible acknowledgement from any existing maintainers to adding > Ian to uploaders. > I am quite disappointed by this upload and the downstream pain it causes > to QA. As if I would just hijack a package [4]. Please consider your tone so we can have a project where we work together instead of throw flames at each other. -i [1] https://salsa.debian.org/debian/libgc/-/merge_requests/3 [2] https://salsa.debian.org/debian/libgc/-/merge_requests/4 [3] https://salsa.debian.org/debian/libgc/-/merge_requests/8 [4] https://salsa.debian.org/debian/libgc/-/merge_requests/7
Bug#1013043: stressapptest: diff for NMU version 1.0.6-2.1
Control: tags 1013043 + patch
Control: tags 1013043 + pending
Dear maintainer,
I've prepared an NMU for stressapptest (versioned as 1.0.6-2.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru stressapptest-1.0.6/debian/changelog stressapptest-1.0.6/debian/changelog
--- stressapptest-1.0.6/debian/changelog 2015-01-21 02:44:51.0 +0200
+++ stressapptest-1.0.6/debian/changelog 2022-09-05 00:42:31.0 +0300
@@ -1,3 +1,10 @@
+stressapptest (1.0.6-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Backport upstream fix for FTBFS with gcc 12. (Closes: #1013043)
+
+ -- Adrian Bunk Mon, 05 Sep 2022 00:42:31 +0300
+
stressapptest (1.0.6-2) unstable; urgency=medium
* Add i586 support patch. (Closes: #775642)
diff -Nru stressapptest-1.0.6/debian/patches/gcc-12 stressapptest-1.0.6/debian/patches/gcc-12
--- stressapptest-1.0.6/debian/patches/gcc-12 1970-01-01 02:00:00.0 +0200
+++ stressapptest-1.0.6/debian/patches/gcc-12 2022-09-05 00:42:31.0 +0300
@@ -0,0 +1,19 @@
+Description: Backport upstream fix for FTBFS with gcc 12
+Author: Adrian Bunk
+Bug-Debian: https://bugs.debian.org/1013043
+Forwarded: https://github.com/stressapptest/stressapptest/commit/2ea87b7996f4f433d5d946eaf8f0d2f6fd18c144
+
+--- stressapptest-1.0.6.orig/src/worker.cc
stressapptest-1.0.6/src/worker.cc
+@@ -2989,8 +2989,9 @@ bool DiskThread::AsyncDiskIO(IoOp op, in
+ errorcount_++;
+ os_->ErrorReport(device_name_.c_str(), operations[op].error_str, 1);
+
+-if (event.res < 0) {
+- switch (event.res) {
++int64 result = static_cast(event.res);
++if (result < 0) {
++ switch (result) {
+ case -EIO:
+ logprintf(0, "Hardware Error: Low-level I/O error while doing %s to "
+"sectors starting at %lld on disk %s (thread %d).\n",
diff -Nru stressapptest-1.0.6/debian/patches/series stressapptest-1.0.6/debian/patches/series
--- stressapptest-1.0.6/debian/patches/series 2015-01-21 02:44:51.0 +0200
+++ stressapptest-1.0.6/debian/patches/series 2022-09-05 00:42:31.0 +0300
@@ -1,3 +1,4 @@
armhf_support
support_i486_builds
support_i586_builds
+gcc-12
Bug#1019168: sysvinit: [INTL:pt] Portuguese translation of MANPAGE
Package: sysvinit Version: 3.04-1 Tags: l10n, patch- Severity: wishlist Updated Portuguese translation for sysvinit's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro sysvinit_3.04-1_sysvinit-man.pt.po.gz Description: application/gzip
Bug#1016710: Update for Buster
Hi, Hopefully this is the right place to ask this. We noticed that CVE-2022-37434 shows no fixed version for Debian buster ( https://security-tracker.debian.org/tracker/CVE-2022-37434 ) Since Bullseye received the fix a >7 days ago we were wondering when Buster would get an updated package. The CVSS score is 9.8, that's why we thought it would also be fixed for Buster. Thanks! Niels __ RootNet B.V. Helpdesk: 024 3500112 (9:00 - 17:30) Service meldingen: rootnet.network Meldingen via Twitter: twitter.com/RootnetNL
Bug#1019158: graphicsmagick breaks gnudatalanguage autopkgtest: undefined symbol: _ZN6Magick5Image12colorMapSizeEv
On Sun, Sep 4, 2022 at 10:27 PM Paul Gevers wrote: > With a recent upload of graphicsmagick the autopkgtest of > gnudatalanguage fails in testing when that autopkgtest is run with the > binary packages of graphicsmagick from unstable. I will check this and see what may cause it. > I copied some of the output at the bottom of this report. It looks like > graphicsmagick dropped a symbol that was actually used. Was that a mistake? According to my double check, no symbol was removed. Quite the opposite, one (IsEventLogged@Base) was added. > Currently this regression is blocking the migration of graphicsmagick to > testing [1]. Can you please investigate the situation? Nope, at least the first reason it's not migrating its FTBFS on mips64el. Already contacted upstream and it's not yet known what causes it. Might be some floating point issue on that architecture. > gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: > undefined symbol: _ZN6Magick5Image12colorMapSizeEv Strange, I might think it's somehow related to GCC 12 changes. Regards, Laszlo/GCS
Bug#1019167: python-selenium: Do not use pypi in d/watch
Source: python-selenium Version: 4.0.0~a1+dfsg1-1.1 Severity: normal X-Debbugs-Cc: jo...@debian.org Hi, selenium 4.4.0 is out: https://github.com/SeleniumHQ/selenium/releases But this is not picked up and displayed as such because selenium stopped distributing source on pypi: https://pypi.org/simple/selenium/ So in turn, pypi.debian.net also doesn't have the latest 4.4.0 release: https://pypi.debian.net/selenium/ Maybe check github releases in d/watch instead? Thanks! cheers, josch
Bug#1018899: gcr-prompter dumps secrets in syslog/journald
On Thu, 01 Sep 2022 at 14:22:45 -0400, Antoine Beaupre wrote: > The bits marked [REDACTED] actually contains what looks like some sort > of secret key. As discussed on IRC, I *think* it's the public part of an asymmetric keypair, which would reduce the severity of this bug, but it still seems like a valid bug (gcr-prompter shouldn't be writing g_debug()-level logging to syslog). > I'm using a weird desktop here: i3wm started from systemd, with *some* > GNOME bits (e.g. network-manager and nm-applet, for example). This bug is probably only applicable in desktop environments that don't provide an integrated libsecret prompt (not GNOME, and possibly also not other major desktop environments like Plasma). smcv
Bug#1019166: pd-lib-builder: bogus build-flags on armel and armhf
Package: pd-lib-builder
Version: 0.6.0-2
Severity: important
Dear Maintainer,
pd-lib-builder adds some optimization flags, depending on which target
architecture it detects.
unfortunately there are a couple of flaws:
- armv6 is detected with 'ifeq ($(shell uname), armv6l)' which i think cannot
work at all (instead if should call $(shell uname -m)
- this obviously fails when cross-compiling, and is not overridable
- the other check for arm ('ifeq ($(target.arch), arm)') is also too generic,
as it will wrongly match the 'armel' architecture (presumable *also* because
of the broken uname-check above), which does not like the '-mfloat-abi=hard'
flag and will fail (when including pthread.h) with
> fatal error: gnu/stubs-hard.h: No such file or directory
- it seems that it also breaks on 'armhf', as the resulting binaries throw a
bus-error...
the full optimization flags injected for "arm" (as found in the GNU-triplet)
are '-march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard'
probably we could use the following to narrow down the arm-architecture:
> gcc -march=native -Q --help=target|egrep "^[[:space:]]*-march="
this gives on the armdahl.debian.org:
| Debian architecture | -march |
|-||
| armel | armv5te|
| armhf | armv7-a+fp |
| arm64 | armv8-a|
or simply use some combination of DEB_HOST_ARCH, `dpkg-architecture
-qDEB_HOST_ARCH` and `dpkg --print-architecture`.
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pd-lib-builder depends on:
ii puredata-dev 0.52.2+ds0-1+exp1
pd-lib-builder recommends no packages.
pd-lib-builder suggests no packages.
-- no debconf information
Bug#1017740: transition: draco
Hi Sebastian, the draco transition looks stuck because of the failing autopkgtest with assimp from testing and draco from unstable. That failure is caused by the renamed CMake target for the draco library (now "draco::draco" instead of "draco_shared"). The target name is hardcoded in the assimp CMake config at package build time and exposed to library users, because it is a public dependency. This means the autopkgtest uses the wrong target name if it tries to build a test program with testing assimp and unstable draco (or vice versa). Unless I'm missing something, this also means that both packages can simply be migrated together to resolve the transition. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1019164: Uninstalling thunar bug report
Package: thunar Version: 4.16.8 When I try to uninstall thunar "sudo apt autoremove thunar" it wants to remove the desktop environment. I am using kernal version Kernel: 5.10.0-17-amd64 and Peppermint OS Version 10. I hope this helps! Transcript: $ sudo apt autoremove thunar [sudo] password for lain: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: libgarcon-gtk3-1-0 libgtop-2.0-11 libgtop2-common libkeybinder-3.0-0 libthunarx-3-0 libxatracker2 libxfce4ui-utils libxfont2 libxpresent1 libxvmc1 light- locker lightdm tango-icon-theme thunar thunar-archive-plugin thunar-data thunar- media-tags-plugin thunar-volman x11-apps x11-session-utils xbitmaps xfce4 xfce4- appfinder xfce4-goodies xfce4-helpers xfce4-panel xfce4-places-plugin xfce4-pulseaudio-plugin xfce4-session xfce4-settings xfdesktop4 xfdesktop4-data xfonts-100dpi xfonts-75dpi xfonts-base xfonts-encodings xfonts-scalable xfonts-utils xfwm4 xiccd xinit xorg xserver-common xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg- input-libinput xserver-xorg-input-wacom xserver-xorg-legacy xserver-xorg-video-all xserver-xorg-video-amdgpu xserver-xorg-video-ati xserver-xorg-video- fbdev xserver-xorg-video-intel xserver-xorg-video-nouveau xserver-xorg- video-qxl xserver-xorg-video-radeon xserver-xorg-video-vesa xserver-xorg-video- vmware 0 upgraded, 0 newly installed, 59 to remove and 0 not upgraded. After this operation, 88.6 MB disk space will be freed. Do you want to continue? [Y/n] n Transcript end:
Bug#1019163: rust-smol - unsatisfiable build-dependency
Package: rust-smol Version: 1.2.5-2 Severity: serious rust-smol build-depends on librust-nix-0.24+default-dev but the nix crate in debian testing/unstable is now at 0.25
Bug#1019158: graphicsmagick breaks gnudatalanguage autopkgtest: undefined symbol: _ZN6Magick5Image12colorMapSizeEv
Source: graphicsmagick Control: found -1 graphicsmagick/1.4+really1.3.38+hg16728-1 Affects: -1 src:gnudatalanguage Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks Dear maintainer(s), With a recent upload of graphicsmagick the autopkgtest of gnudatalanguage fails in testing when that autopkgtest is run with the binary packages of graphicsmagick from unstable. It passes when run with only packages from testing. In tabular form: passfail graphicsmagick from testing1.4+really1.3.38+hg16728-1 gnudatalanguagefrom testing1.0.1-3 all others from testingfrom testing I copied some of the output at the bottom of this report. It looks like graphicsmagick dropped a symbol that was actually used. Was that a mistake? Currently this regression is blocking the migration of graphicsmagick to testing [1]. Can you please investigate the situation? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=graphicsmagick https://ci.debian.net/data/autopkgtest/testing/amd64/g/gnudatalanguage/25681414/log.gz gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Magick5Image12colorMapSizeEv gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: undefined symbol: _ZN6Ma
Bug#1018687: override: perl-modules-5.34:libs/optional perl-modules-5.36:libs/optional
On Sat, Sep 03, 2022 at 11:00:31PM -0700, Russ Allbery wrote: > > On Sun 28 Aug 2022 at 09:28PM -05, Daniel Lewart wrote: > >> Please change perl-modules-5.34 and perl-modules-5.36 from: > >> * Priority: standard > >> to: > >> * Priority: optional > >> > >> perl 5.34.0 is Priority:standard" and Depends on perl-modules-5.34. > >> perl 5.36.0 is Priority:standard" and Depends on perl-modules-5.36. > >> Therefore, perl-modules-5.xx will still be pulled into Standard systems. > > I think the stronger argument here is basically that the perl-modules > package is an internal implementation detail of the perl package, and > therefore only the perl package should have the higher standard priority. > > I'm not sure it makes much difference in practice, and I'm curious what > problem Daniel ran into that motivated filing a bug report, but I think > that logic might make sense? But I'm also not sure we should make changes > here just for the sake of making changes, so I'm curious about the > motivation and what problem this change would fix. Yeah, thanks. I agree on all this. My first thought was that the requested change would be just cosmetic with no effect in practice. However, there's one thing that occurs to me in favour of the change: perl-modules-5.xx will currently stay installed after an upgrade to 5.yy, but is probably not useful anymore on most systems [1]. I'm not sure if the priority affects apt's inclination to remove orphan packages, but it does seem like a possibly useful hint. FWIW libperl5.xx is already Priority: optional and Depends on perl-modules-5.xx. Making their priorities match does feel right to me. [1] Coinstallability between Perl versions was requested so that packages embedding a Perl interpreter (by linking against libperl5.xx) would not be quite as tightly coupled during upgrades as they used to be. The package doing the embedding can now be upgraded separately later, and still has the Perl standard library available in the meantime because the older versions of libperl5.xx and perl-modules-5.xx stay installed. -- Niko Tyni nt...@debian.org
Bug#1019156: nbconvert: autopkgtest regression: SyntaxError: invalid escape sequence
Source: nbconvert
Version: 6.5.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of nbconvert the autopkgtest of nbconvert fails in
testing when that autopkgtest is run with the binary packages of
nbconvert from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
nbconvert from testing6.5.1-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=nbconvert
https://ci.debian.net/data/autopkgtest/testing/amd64/n/nbconvert/25709432/log.gz
[1m= test session starts
==[0m
platform linux -- Python 3.10.6, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /tmp/autopkgtest-lxc.7b1y4lix/downtmp/build.PuB/src,
configfile: pyproject.toml, testpaths: nbconvert/
collected 0 items / 1 error
ERRORS
[31m[1m ERROR collecting test session
_[0m
[1m[31m/usr/lib/python3.10/importlib/__init__.py[0m:126: in import_module
[94mreturn[39;49;00m _bootstrap._gcd_import(name[level:],
package, level)
[1m[31m[0m:1050: in _gcd_import
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:1027: in _find_and_load
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:992: in _find_and_load_unlocked
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:241: in _call_with_frames_removed
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:1050: in _gcd_import
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:1027: in _find_and_load
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:1006: in _find_and_load_unlocked
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:688: in _load_unlocked
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:883: in exec_module
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31m[0m:241: in _call_with_frames_removed
[04m[91m?[39;49;00m[04m[91m?[39;49;00m[04m[91m?[39;49;00m
[1m[31mnbconvert/__init__.py[0m:3: in
[94mfrom[39;49;00m [04m[96m.[39;49;00m [94mimport[39;49;00m
filters, postprocessors, preprocessors, writers
[1m[31mnbconvert/filters/__init__.py[0m:8: in
[94mfrom[39;49;00m
[04m[96m.[39;49;00m[04m[96mmarkdown[39;49;00m [94mimport[39;49;00m *
[1m[31mnbconvert/filters/markdown.py[0m:13: in
[94mfrom[39;49;00m
[04m[96m.[39;49;00m[04m[96mmarkdown_mistune[39;49;00m
[94mimport[39;49;00m markdown2html_mistune
[1m[31mnbconvert/filters/markdown_mistune.py[0m:24: in
[94mimport[39;49;00m
[04m[96mnbconvert[39;49;00m[04m[96m.[39;49;00m[04m[96mfilters[39;49;00m[04m[96m.[39;49;00m[04m[96m_mistune[39;49;00m
[94mas[39;49;00m [04m[96mmistune[39;49;00m
[1m[31mE File
"/tmp/autopkgtest-lxc.7b1y4lix/downtmp/build.PuB/src/nbconvert/filters/_mistune.py",
line 435[0m
[1m[31mE cells[i][c] = re.sub('\|', '|', cell)[0m
[1m[31mE[0m
[1m[31mE SyntaxError: invalid escape sequence '\|'[0m
=== short test summary info
ERROR - File
"/tmp/autopkgtest-lxc.7b1y4lix/downtmp/build.PuB/src/nbconver...
Interrupted: 1 error during collection
[31m=== [31m[1m1 error[0m[31m in
0.22s[0m[31m ===[0m
autopkgtest [14:15:27]: test command1
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1019155: nbconvert breaks nbclient autopkgtest: No module named 'testpath'
Source: nbconvert, nbclient Control: found -1 nbconvert/6.5.1-1 Control: found -1 nbclient/0.6.6-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of nbconvert the autopkgtest of nbclient fails in testing when that autopkgtest is run with the binary packages of nbconvert from unstable. It passes when run with only packages from testing. In tabular form: passfail nbconvert from testing6.5.1-1 nbclient from testing0.6.6-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of nbconvert to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=nbconvert https://ci.debian.net/data/autopkgtest/testing/amd64/n/nbclient/25713974/log.gz = test session starts == platform linux -- Python 3.10.6, pytest-7.1.2, pluggy-1.0.0+repack rootdir: /usr/lib/python3/dist-packages/nbclient collected 5 items / 1 error ERRORS ERROR collecting tests/test_client.py _ ImportError while importing test module '/usr/lib/python3/dist-packages/nbclient/tests/test_client.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3.10/importlib/__init__.py:126: in import_module return _bootstrap._gcd_import(name[level:], package, level) /usr/lib/python3/dist-packages/nbclient/tests/test_client.py:22: in from testpath import modified_env E ModuleNotFoundError: No module named 'testpath' OpenPGP_signature Description: OpenPGP digital signature
Bug#1019145: problem on mirror
On Sep 04, reza bojnordi wrote: > Hi Debian, > I have registered my repository on the Debian mirror but I haven't seen it > on the Debian mirror list. > can you help me or can you explain? Please wait until somebody will process your request. -- ciao, Marco signature.asc Description: PGP signature
Bug#1019154: golang-github-xi2-xz: autopkgtest fails: testdata/other/bad-0-backward_size.xz: no such file or directory
Source: golang-github-xi2-xz Version: 0.0~git20171230.48954b6-1 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), Your package has an autopkgtest, great. However, it fails. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html https://ci.debian.net/packages/g/golang-github-xi2-xz/ https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-xi2-xz/25124641/log.gz dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 in use) cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/xi2/xz === RUN TestBadFiles reader_test.go:445: open testdata/other/bad-0-backward_size.xz: no such file or directory --- FAIL: TestBadFiles (0.00s) === RUN TestGoodFiles reader_test.go:445: open testdata/other/good-0cat-empty.xz: no such file or directory --- FAIL: TestGoodFiles (0.00s) === RUN TestUnsupportedFiles reader_test.go:445: open testdata/other/unsupported-block_header.xz: no such file or directory --- FAIL: TestUnsupportedFiles (0.00s) === RUN TestOtherFiles reader_test.go:445: open testdata/other/good-1-x86-lzma2-offset-2048.xz: no such file or directory --- FAIL: TestOtherFiles (0.00s) === RUN TestMemlimit reader_test.go:528: open testdata/other/words.xz: no such file or directory --- FAIL: TestMemlimit (0.00s) === RUN TestPrematureError reader_test.go:545: open testdata/other/good-2-lzma2-corrupt.xz: no such file or directory --- FAIL: TestPrematureError (0.00s) === RUN TestMultipleBadReads reader_test.go:570: open testdata/other/good-2-lzma2-corrupt.xz: no such file or directory --- FAIL: TestMultipleBadReads (0.00s) === RUN TestByteReads reader_test.go:478: open testdata/other/bad-0-backward_size.xz: no such file or directory --- FAIL: TestByteReads (0.00s) === RUN TestMultistream reader_test.go:624: open testdata/other/good-1-x86-lzma2-offset-2048.xz: no such file or directory --- FAIL: TestMultistream (0.00s) === RUN TestReuseReader reader_test.go:445: open testdata/other/bad-0-backward_size.xz: no such file or directory --- FAIL: TestReuseReader (0.00s) === RUN TestReuseReaderPartialReads reader_test.go:678: open testdata/other/words.xz: no such file or directory --- FAIL: TestReuseReaderPartialReads (0.00s) === RUN ExampleNewReader 2022/08/23 15:26:15 open testdata/xz-utils/good-1-check-sha256.xz: no such file or directory FAILgithub.com/xi2/xz 0.002s FAIL dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/xi2/xz returned exit code 1 make: *** [debian/rules:9: build] Error 25 autopkgtest [15:26:15]: test dh-golang-autopkgtest: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#1019153: php-horde-turba: fatal error: $name must be a string
Package: php-horde-turba Version: 4.2.23-1+deb10u1 Severity: important Dear Maintainer, after updating 'php-horde-turba' on my buster-system to the latest security patch, my users can no longer log into the horde webmail interface. instead they are greeted with an error message after authentication: ``` A fatal error has occurred $name must be a string in /usr/share/php/Horde/Registry.php:1679 1. Horde_Registry::appInit() /usr/share/horde/imp/index.php:19 2. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:298 3. Horde_Registry->_pushAppError() /usr/share/php/Horde/Registry.php:1622 4. Horde_Registry::appInit() /usr/share/horde/imp/index.php:19 5. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:298 6. Horde_Registry->callAppMethod() /usr/share/php/Horde/Registry.php:1617 7. Horde_Registry_Application->authenticated() /usr/share/php/Horde/Registry.php:1197 8. IMP_Application->_authenticated() /usr/share/php/Horde/Registry/Application.php:108 9. IMP_Auth::authenticateCallback() /usr/share/horde/imp/lib/Application.php:134 10. IMP_Imap->doPostLoginTasks() /usr/share/horde/imp/lib/Auth.php:243 11. IMP_Imap->updateFetchIgnore() /usr/share/horde/imp/lib/Imap.php:344 12. IMP_Mailbox::getSpecialMailboxes() /usr/share/horde/imp/lib/Imap.php:354 13. IMP_Mailbox_SessionCache->getSpecialMailboxes() /usr/share/horde/imp/lib/Mailbox.php:1364 14. IMP_Mailbox::getPref() /usr/share/horde/imp/lib/Mailbox/SessionCache.php:268 15. Horde_Prefs->getValue() /usr/share/horde/imp/lib/Mailbox.php:235 16. Horde_Prefs->_getScope() /usr/share/php/Horde/Prefs.php:304 17. Horde_Prefs->_loadScope() /usr/share/php/Horde/Prefs.php:397 18. Horde_Core_Prefs_Storage_Hooks->get() /usr/share/php/Horde/Prefs.php:467 19. Horde_Core_Hooks->callHook() /usr/share/php/Horde/Core/Prefs/Storage/Hooks.php:39 20. IMP_Hooks->prefs_init() /usr/share/php/Horde/Core/Hooks.php:61 21. Horde_Registry->call() /etc/horde/imp/hooks.php:29 22. Horde_Registry->callByPackage() /usr/share/php/Horde/Registry.php:1089 23. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:1128 24. Horde_Registry->_pushAppError() /usr/share/php/Horde/Registry.php:1640 25. Horde_Registry::appInit() /usr/share/horde/imp/index.php:19 26. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:298 27. Horde_Registry->callAppMethod() /usr/share/php/Horde/Registry.php:1617 28. Horde_Registry_Application->authenticated() /usr/share/php/Horde/Registry.php:1197 29. IMP_Application->_authenticated() /usr/share/php/Horde/Registry/Application.php:108 30. IMP_Auth::authenticateCallback() /usr/share/horde/imp/lib/Application.php:134 31. IMP_Imap->doPostLoginTasks() /usr/share/horde/imp/lib/Auth.php:243 32. IMP_Imap->updateFetchIgnore() /usr/share/horde/imp/lib/Imap.php:344 33. IMP_Mailbox::getSpecialMailboxes() /usr/share/horde/imp/lib/Imap.php:354 34. IMP_Mailbox_SessionCache->getSpecialMailboxes() /usr/share/horde/imp/lib/Mailbox.php:1364 35. IMP_Mailbox::getPref() /usr/share/horde/imp/lib/Mailbox/SessionCache.php:268 36. Horde_Prefs->getValue() /usr/share/horde/imp/lib/Mailbox.php:235 37. Horde_Prefs->_getScope() /usr/share/php/Horde/Prefs.php:304 38. Horde_Prefs->_loadScope() /usr/share/php/Horde/Prefs.php:397 39. Horde_Core_Prefs_Storage_Hooks->get() /usr/share/php/Horde/Prefs.php:467 40. Horde_Core_Hooks->callHook() /usr/share/php/Horde/Core/Prefs/Storage/Hooks.php:39 41. IMP_Hooks->prefs_init() /usr/share/php/Horde/Core/Hooks.php:61 42. Horde_Registry->call() /etc/horde/imp/hooks.php:29 43. Horde_Registry->callByPackage() /usr/share/php/Horde/Registry.php:1089 44. Horde_Registry->pushApp() /usr/share/php/Horde/Registry.php:1128 45. Horde_Registry->callAppMethod() /usr/share/php/Horde/Registry.php:1635 46. Horde_Registry_Application->init() /usr/share/php/Horde/Registry.php:1197 47. Turba_Application->_init() /usr/share/php/Horde/Registry/Application.php:117 48. Turba::permissionsFilter() /usr/share/horde/turba/lib/Application.php:122 49. Turba_Factory_Driver->createFromConfig() /usr/share/horde/turba/lib/Turba.php:434 50. Turba_Factory_Driver->_create() /usr/share/horde/turba/lib/Factory/Driver.php:64 51. Turba_Driver_Share->__construct() /usr/share/horde/turba/lib/Factory/Driver.php:141 52. Turba_Factory_Driver->create() /usr/share/horde/turba/lib/Driver/Share.php:47 ``` downgrading to 4.2.23-1 fixes the issue (but of course this is somewhat suboptimal, giving the nature of security-upgrades). -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: armhf (armv7l) Kernel: Linux 4.14.222-odroidxu4 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages php-horde-turba depends on: ii php-cl
Bug#1019152: python-bonsai: flaky autopkgtest on armhf and armel: timeout too short?
Source: python-bonsai
Version: 1.3.0+ds-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky
Dear maintainer(s),
I looked at the results of the autopkgtest of your package. I noticed
that it regularly fails on armel and armhf.
Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.
Don't hesitate to reach out if you need help and some more information
from our infrastructure.
Paul
https://ci.debian.net/data/autopkgtest/testing/armel/p/python-bonsai/24971339/log.gz
=== FAILURES
===
__ test_open
___
client =
def test_open(client):
""" Test opening the pool. """
pool = ConnectionPool(client, minconn=5)
> pool.open()
tests/test_pool.py:35:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/bonsai/pool.py:70: in open
self._idles.add(self._client.connect(self._kwargs))
/usr/lib/python3/dist-packages/bonsai/ldapclient.py:675: in connect
return LDAPConnection(self).open(timeout)
/usr/lib/python3/dist-packages/bonsai/ldapconnection.py:297: in open
return super().open(timeout)
/usr/lib/python3/dist-packages/bonsai/ldapconnection.py:53: in open
return self._evaluate(super().open(), timeout)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = ,
msg_id = -1
timeout = None
def _evaluate(self, msg_id: int, timeout: Optional[float] = None)
-> Any:
"""
It returns the result of the LDAP operation.
:param int msg_id: the ID of the LDAP operation.
:param float timeout: time limit in seconds for the operation.
:return: the result of the operation.
"""
> return self.get_result(msg_id, timeout)
E bonsai.errors.TimeoutError: Timed out. (0xFFFB [-5])
/usr/lib/python3/dist-packages/bonsai/ldapconnection.py:246: TimeoutError
___ test_get
___
self =
def get(self):
"""
Get a connection from the connection pool.
:raises EmptyPool: when the pool is empty.
:raises ClosedPool: when the method is called on a closed pool.
:return: an LDAP connection object.
"""
if self._closed:
raise ClosedPool("The pool is closed.")
try:
> conn = self._idles.pop()
E KeyError: 'pop from an empty set'
/usr/lib/python3/dist-packages/bonsai/pool.py:84: KeyError
During handling of the above exception, another exception occurred:
client =
def test_get(client):
""" Test getting a connection from the pool. """
pool = ConnectionPool(client, minconn=1, maxconn=2)
with pytest.raises(ClosedPool):
_ = pool.get()
pool.open()
assert pool.max_connection == 2
assert pool.idle_connection == 1
assert pool.shared_connection == 0
conn1 = pool.get()
assert conn1 is not None
assert conn1.closed == False
assert pool.idle_connection == 0
assert pool.shared_connection == 1
> conn2 = pool.get()
tests/test_pool.py:66:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/bonsai/pool.py:87: in get
conn = self._client.connect(self._kwargs)
/usr/lib/python3/dist-packages/bonsai/ldapclient.py:675: in connect
return LDAPConnection(self).open(timeout)
/usr/lib/python3/dist-packages/bonsai/ldapconnection.py:297: in open
return super().open(timeout)
/usr/lib/python3/dist-packages/bonsai/ldapconnection.py:53: in open
return self._evaluate(super().open(), timeout)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = ,
msg_id = -1
timeout = None
def _evaluate(self, msg_id: int, timeout: Optional[float] = None)
-> Any:
"""
It returns the result of the LDAP operation.
:param int msg_id: the ID of the LDAP operation.
:param float timeout: time limit in seconds for the operation.
:return: the result of the operation.
"""
> return self.get_result(msg_id, timeout)
E bonsai.errors.TimeoutError: Timed out. (0xFFFB [-5])
/usr/lib/python3/dist-packages/bonsai/ldapconnection.py:246: TimeoutError
___ test_threaded_pool_block
___
client =
def test_threaded_pool_block(client):
""" Test threaded pool blocks when it's empty. """
sleep = 5
pool = ThreadedConnectionPool(client, minconn=1, maxconn=1)
> pool.open()
tests/test_pool.py:123:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Bug#1019151: pydevd: flaky autopkgtest on armel: timeout too short?
Source: pydevd Version: 2.8.0+git20220602.1b1fb8b+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails on armel. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul https://ci.debian.net/packages/p/pydevd/testing/armel/ https://ci.debian.net/data/autopkgtest/testing/armel/p/pydevd/25054651/log.gz OpenPGP_signature Description: OpenPGP digital signature
Bug#960679: fontconfig: strict dependency of arch:any libfontconfig1 on arch:all fontconfig-config going wrong
Hi,
On Fri, 15 May 2020 12:48:14 +0200 Julien Cristau wrote:
> libfontconfig1 Depends on fontconfig-config (>= ${source:Version})
>
> If the arch:amd64 buildd is faster than the arch:all one, as happened
> with 2.13.1-4.1, the new libfontconfig1 becomes uninstallable, and,
> because fontconfig indirectly build-depends on libfontconfig1, that
> situation can't fix itself.
>
> One way around that is to make fontconfig-config arch:any; there may be other
> solutions.
I uploaded an NMU with attached debdiff to DELAYED/10 to fix this bug.
Thanks!
cheers, joschdiff -Nru fontconfig-2.13.1/debian/changelog fontconfig-2.13.1/debian/changelog
--- fontconfig-2.13.1/debian/changelog 2022-01-29 17:05:46.0 +0100
+++ fontconfig-2.13.1/debian/changelog 2022-09-04 18:37:48.0 +0200
@@ -1,3 +1,14 @@
+fontconfig (2.13.1-4.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Make fontconfig-config arch:any. If one of the arch:any buildds is faster
+than the arch:all one, the new libfontconfig1 becomes uninstallable, and,
+because fontconfig indirectly build-depends on libfontconfig1, that
+situation can't fix itself. Turning fontconfig-config from arch:all to
+arch:any prevents this from happening. (closes: #960679)
+
+ -- Johannes Schauer Marin Rodrigues Sun, 04 Sep 2022 18:37:48 +0200
+
fontconfig (2.13.1-4.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fontconfig-2.13.1/debian/control fontconfig-2.13.1/debian/control
--- fontconfig-2.13.1/debian/control 2020-05-15 12:55:02.0 +0200
+++ fontconfig-2.13.1/debian/control 2022-09-04 17:16:52.0 +0200
@@ -42,7 +42,7 @@
available to fontconfig applications.
Package: fontconfig-config
-Architecture: all
+Architecture: any
Depends: ${misc:Depends},
ucf (>= 0.29),
# Bitstream Vera and derivatives
diff -Nru fontconfig-2.13.1/debian/rules fontconfig-2.13.1/debian/rules
--- fontconfig-2.13.1/debian/rules 2022-01-12 07:49:42.0 +0100
+++ fontconfig-2.13.1/debian/rules 2022-09-04 17:17:10.0 +0200
@@ -23,8 +23,7 @@
chmod +w debian/po/*.po
debconf-updatepo
-override_dh_install-indep:
- dh_install -i
+execute_after_dh_install-arch:
cd debian/fontconfig-config/usr/share/fontconfig/conf.avail && \
mv 70-yes-bitmaps.conf 70-force-bitmaps.conf
cp debian/70-yes-bitmaps.conf debian/fontconfig-config/usr/share/fontconfig/conf.avail/
signature.asc
Description: signature
Bug#1018617: rocketcea: build-depends on python3-nose or uses it for autopkgtest
Hi Bdale!
On Mon, Aug 29, 2022 at 10:24:27AM -0600, Bdale Garbee wrote:
> I noticed that upstream is now at 1.1.29 where our package is 1.1.18, so
> I started by freshening the packaging repo to build 1.1.29. Ironically,
> the build fails in the test suite with a probably easy to fix error that
> I just don't have time to work on today.
>
> I note that tox.ini in the upstream source seems to imply either pytest
> or nose can be used, but I'm not familiar enough with python test suites
> to immediately know if this is just left-over boilerplate, or if moving
> to pytest would be as simple as changing the tox.ini content?
>
> If someone else who understands python test suites better than I do has
> time to patch rocketcea to use a supported test suite and get 1.1.29 to
> build to completion, I'd love to have that help.
Upstream uses pure unittest, so there is no need to use nose or pytest.
The attached patch updates Debian packaging to run unittest.
Unfortunately, it does not fix the test failure with 1.1.29 that I get:
Chk: get_eps_at_PcOvPe ALL GOOD:1 --> At line 5462 of file rocketcea/py_cea.f
(unit = 13, file = '/home/dmitry/RocketCEA/temp.dat')
Fortran runtime error: End of file
I know neither Fortran nor format of that file (temp.dat) so I can't say
why it reaches end of file. I notice that version 1.1.18 used temp.csr
instead of temp.dat, but apparently those two files are identical.
The only thing I can suggest is to file an upstream bug about this failure.
But with my patch I can get version 1.1.18 build successfully without nose.
--
Dmitry Shachnev
From 84b13bac134d1e105ef74608179995bf07bd4901 Mon Sep 17 00:00:00 2001
From: Dmitry Shachnev
Date: Sun, 4 Sep 2022 21:04:02 +0300
Subject: [PATCH] Use unittest instead of nose.
---
debian/control | 2 +-
debian/rules | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index a5fdc1d..d22d0f2 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: science
Priority: optional
Maintainer: Bdale Garbee
Build-Depends: debhelper-compat (= 12), dh-python, gfortran, python3-coverage, python3-all-dev, python3-future,
- python3-matplotlib, python3-nose, python3-numpy, python3-scipy, python3-setuptools
+ python3-matplotlib, python3-numpy, python3-scipy, python3-setuptools
Standards-Version: 4.5.0
Homepage: https://rocketcea.readthedocs.io
Vcs-Git: https://salsa.debian.org/debian/rocketcea.git
diff --git a/debian/rules b/debian/rules
index e2f9bd8..c7a48df 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,9 @@ export PYBUILD_NAME=rocketcea
%:
dh $@ --with python3 --buildsystem=pybuild
+override_dh_auto_test:
+ dh_auto_test -- --system custom --test-args 'cd {build_dir}; {interpreter} -m unittest discover -v'
+
execute_after_dh_auto_test:
rm -f .pybuild/cpython3*rocketcea/build/separated_Noz.csv
--
2.35.1
signature.asc
Description: PGP signature
Bug#1019007: rfkill(8): List options for supported device types
September 3, 2022, 8:05 PM, "Andreas Henriksson" wrote: > Your suggested patch changes upstream provided files. Could you please > submit the patch directly to upstream for review/inclusion? Thanks, I took it upstream: https://github.com/util-linux/util-linux/issues/1790 -- Tino
Bug#1014923: riseup-vpn: GUI seems stalled, no icon shown.
Hi Dmitris, I did a new upload "0.21.11+ds1-2" which should fix this -- this was a minor problem in upstream code itself; this upload should appear in a few hours. I have marked this bug as fixed for now, but please reopen/tell me to reopen if you still see the problem. Could you please try if it works fine for you now? Looking forward to hear from you. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1019149: RM: golang-gopkg-dancannon-gorethink.v1 -- RoQA; superseded by golang-gopkg-rethinkdb-rethinkdb-go.v6
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: z...@debian.org Control: clone -1 -2 Control: retitle -2 RM: golang-gopkg-dancannon-gorethink.v2 -- RoQA; superseded by golang-gopkg-rethinkdb-rethinkdb-go.v6 Hi, gorethink.v1 and v2 has been superseded by v6. And no reverse depends for v1/v2.
Bug#1019054: [Pkg-phototools-devel] Bug#1019054: Bug#1019054: darktable: Darktable does not save Metadata in exported jpgs anymore, even author/copyright entries are gone!
Kerstin Hoef-Emden writes: > c) I opened the wheel and Voreinstellungen, went to the global settings > of the meta data editor. It differed from the older darktable version > in, that no percent symbols were visible (Metadaten-Editor_globale > Einstallung.png). I can double-click on "Alle Rechte" and it offers a > field to type something in. But apparently this is only to give a name > ro a setting, rather than to change a setting. Those are the wrong settings. I agree it's a bit confusing, but click on the hamburger menu (≡) for the export, then choose preferences. On the left you will see a set of checkboxes, including metadata. Make sure the metadata one is selected (see attached). If that doesn't help, try deselecting "develop history". There was an old bug (which is supposed to be fixed) that caused metadata export to fail if the develop history stack got too big.
Bug#1019142: systemd-resolved: recent update REMOVES systemd-resolved
Control: tags -1 moreinfo > Dear Maintainer, > > Upon apt updating last night and restarting my computer there is no > DNS > resolution and thus no internet. Not many packages were updated in > the update > but I noticed systemd was updated to 251.3-1 (I don't know if that is > relevant). Upon further investigation systemd-resolved is now gone. > The paths > /lib/systemd/systemd-resolved, /run/systemd/resolve no longer exist > and > /etc/resolv.conf was renamed to /etc/resolv.conf.dkg.bak. I see no > way to fix > this beyond reinstalling Debian. Did you install the systemd-resolved package as the NEWS entry says? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#896083: gdm3: Suspends machine after 20 minutes
On Sun, Sep 4, 2022 at 11:34 AM Xavier Bestel wrote: > FWIW I tried: > > dbus-launch gsettings set org.gnome.settings-daemon.plugins.power > sleep-inactive-ac-type 'nothing' > > as root, but my machine is still suspending with this message: > > Broadcast message from Debian-gdm@inuc on tty1 (Thu 2022-09-01 > 10:34:51 CEST): > > The system is going down for suspend NOW! > > ... which is very inconvenient (this is a freshly installed mostly > headless machine). The user account name is Debian-gdm not root. Thank you, Jeremy Bicha
Bug#1018906: dwarves: FTBFS with libbpf 1.0.0
On Thu, Sep 01, 2022 at 08:57:21PM +0100, Sudip Mukherjee wrote:
>
> Dear Maintainer,
Hi Sudip,
>
> dwarves FTBFS with libbpf 1.0.0 (available in experimental).
> Hopefully this is the error from the build log:
>
> In file included from /home/sudip/test/dwarves-1.23/btf_encoder.c:18:
> /usr/include/bpf/btf.h: In function 'btf_enum64_value':
> /usr/include/bpf/btf.h:496:25: error: invalid use of undefined type 'const
> struct btf_enum64'
> 496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
> | ^~
> /usr/include/bpf/btf.h:496:46: error: invalid use of undefined type 'const
> struct btf_enum64'
> 496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
> | ^~
Which version of linux-libc-dev are you using? I see that struct
btf_enum64 is introduced only in kernel 6.0, not yet packaged.
> /home/sudip/test/dwarves-1.23/btf_encoder.c: In function 'btf__log_err':
> /home/sudip/test/dwarves-1.23/btf_encoder.c:175:39: warning: implicit
> declaration of function 'btf__get_nr_types' [-Wimplicit-function-declaration]
> 175 | fprintf(stderr, "[%u] %s %s", btf__get_nr_types(btf) + 1,
> | ^
> /home/sudip/test/dwarves-1.23/btf_encoder.c: In function
> 'btf_encoder__encode':
> /home/sudip/test/dwarves-1.23/btf_encoder.c:1049:13: error: too many
> arguments to function 'btf__dedup'
> 1049 | if (btf__dedup(encoder->btf, NULL, NULL)) {
> | ^~
> /usr/include/bpf/btf.h:232:16: note: declared here
> 232 | LIBBPF_API int btf__dedup(struct btf *btf, const struct
> btf_dedup_opts *opts);
> |^~
>
These probably require the new dwarves 1.24.
Thanks,
Dom
--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
signature.asc
Description: PGP signature
Bug#1019148: pulseaudio: Chromebook delbin-xhvi: not detecting earphone/headset, no mic input, no headphone output
Package: pulseaudio Version: 15.0+dfsg1-4+b1 Severity: important Dear Maintainer, I installed bullseye on a Asus Chromebook Flip C536E (delbin-xhvi), then upgraded it to Debian/testing to get more things working. Almost everything is working well in bookworm, there are just some audio issues. Sound output via the speakers works well, as does volume control. What does not work is: * No sound output to headphones or headsets * No mic input at all, both on the device mic and headset mics. * No detection when plugging in headphones or a headset (no GNOME prompt). The sound keeps playing out of the speakers. This is a TigerLake Chromebook, so it should be maintained in upstream Linux and ALSA, and source repos are available. I tried the experimental 5.19 kernel, but that didn't change anything. This computer seems closely related to the 'delbin' model, though not exactly the same: Asus Chromebook Flip CX5 (delbin) vs. Asus Chromebook Flip C536E (delbin-xhvi). Both are "volteer" boards. There are a whole range of "delbin" laptops that are well speced and good candidates for solid Debian machines. -- Package-specific info: File '/etc/default/pulseaudio' does not exist -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) 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 pulseaudio depends on: ii adduser 3.128 ii init-system-helpers 1.64 ii libasound2 1.2.7.2-1 ii libasound2-plugins 1.2.7.1-1 ii libc6 2.34-4 ii libcap2 1:2.44-1 ii libdbus-1-3 1.14.0-2 ii libfftw3-single33.3.8-2 ii libgcc-s1 12.2.0-1 ii libglib2.0-02.72.3-1+b1 ii libgstreamer-plugins-base1.0-0 1.20.3-2 ii libgstreamer1.0-0 1.20.3-1 ii libice6 2:1.0.10-1 ii libltdl72.4.7-4 ii liborc-0.4-01:0.4.32-2 ii libpulse0 15.0+dfsg1-4+b1 ii libsm6 2:1.2.3-1 ii libsndfile1 1.0.31-2 ii libsoxr00.1.3-4 ii libspeexdsp11.2.0-1 ii libstdc++6 12.2.0-1 ii libsystemd0 251.3-1 ii libtdb1 1.4.6-3 ii libudev1251.3-1 ii libwebrtc-audio-processing1 0.3-1+b1 ii libx11-62:1.8.1-2 ii libx11-xcb1 2:1.8.1-2 ii libxcb1 1.15-1 ii libxtst62:1.2.3-1.1 ii lsb-base11.2 ii pulseaudio-utils15.0+dfsg1-4+b1 Versions of packages pulseaudio recommends: ii dbus-user-session1.14.0-2 ii libpam-systemd [logind] 251.3-1 ii rtkit0.13-4 Versions of packages pulseaudio suggests: pn paprefs pn pavucontrol pn pavumeter ii udev 251.3-1 Additional packages that might be relevant: ii alsa-topology-conf 1.2.5.1-2 ii alsa-ucm-conf 1.2.7.2-1 ii alsa-utils 1.2.7-1 ii firmware-amd-graphics 20210818-1 ii firmware-intel-sound20210818-1 ii firmware-iwlwifi20210818-1 ii firmware-linux-free 20200122-1 ii firmware-misc-nonfree 20210818-1 ii firmware-sof-signed 2.1.1-1 -- no debconf information $ pactl list short sinks 0 alsa_output.pci-_00_1f.3-platform-tgl_mx98373_rt5682.stereo-fallback module-alsa-card.c s16le 2ch 48000Hz SUSPENDED $ pactl list short sources 0 alsa_output.pci-_00_1f.3-platform-tgl_mx98373_rt5682.stereo-fallback.monitor module-alsa-card.c s16le 2ch 48000Hz SUSPENDED 1 alsa_input.pci-_00_1f.3-platform-tgl_mx98373_rt5682.stereo-fallback module-alsa-card.c s16le 2ch 48000Hz SUSPENDED # aplay -L null Discard all samples (playback) or generate zero samples (capture) lavrate Rate Converter Plugin Using Libav/FFmpeg Library samplerate Rate Converter Plugin Using Samplerate Library speexrate Rate Converter Plugin Using Speex Resampler jack JACK Audio Connection Kit oss Open Sound System pulse PulseAudio Sound Server speex Plugin using Speex DSP (resample, agc, denoise, echo, dereverb) upmix Plugin for channel upmix (4,6,8) vdownmix Plugin for channel downmix (stereo) with a simple spacialization hw:CARD=sofrt5682,DEV=0 sof-rt5682, Direct hardware device without any conversions hw:CARD=sofrt5682,DEV=1 sof-rt5682, Direct hardware device without any conversions hw:CARD=sofrt5682,DEV=2 sof-rt5682,
Bug#1019146: gnome-builder: Update to 43
Source: gnome-builder Version: 42.1-1+b2 Severity: wishlist Control: blocks -1 by 1016765 Control: fixed -1 43~alpha1-1 gnome-builder 43 has switched to GTK4 so it needs webkit2gtk's GTK4 libraries (the 5.0 API) for maximum support. More importantly, it depends on glib 2.73.3 which is stuck in Unstable because of some RC bugs. gnome-builder 43 switches to libsoup3 so devhelp (and therefore anjuta) will need to switch also. Thank you, Jeremy Bicha
Bug#1019128: gnome-builder: libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.
Control: reassign -1 src:devhelp 43~beta-2 Control: affects -1 src:gnome-builder On Sun, Sep 4, 2022 at 11:43 AM Tyler Magee Shields wrote: > (process:46288): libsoup-ERROR **: 09:19:28.122: libsoup2 symbols detected. > Using libsoup2 and libsoup3 in the same process is not supported. Thank you for reporting this bug. There are 2 ways forward: either pushing GNOME Builder 43 to Unstable or revert the devhelp change. GNOME Builder 43 requires glib 2.73 which is unable to migrate to Testing yet. So the only fix is to revert devhelp for now. Jeremy Bicha
Bug#981139: Status
Hi, What is the current status? I did a quick and dirty build with the commit mentioned (https://github.com/FRRouting/frr/commit/4f08c715db6893ff439d0a39bf4506cd26256d13.patch) and this resolves the issue for me. It would be nice to have this bug resolved. Kind regards, Axel Scheepers
Bug#944632: override: color-theme-modern:editors/optional
Replying from my phone: On Tue, 9 Aug 2022, 12:54 Sean Whitton, wrote: > Hello, > > On Tue 12 Nov 2019 at 08:10PM -05, Nicholas D Steeves wrote: > Snip > > > A section change would be very much appreciated :-) Also, please let > > me know if the use of reportbug's "override" submenu for > > ftp.debian.org bugs was appropriate when filing this bug. > > Yup. > Thank you for section change and for the ACK 🙂. Also thank you for going through these old bugs! >
Bug#1018861: adduser --gid fails with "group '-1' does not exist"
Hi, On Sun, Sep 04, 2022 at 05:47:41PM +0200, Marc Haber wrote: > I confirm this behavior as a bug in adduser 3.128 itself. to write a valid testcase, I'd like to see the output of # grep -v '^#' /etc/adduser.conf on your system, if non-empty. If empty, please send a short message indicating that. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#972571: limit package to mmdebstrap, reassign 972571 to dash
On Mon, 29 Aug 2022 03:50:47 +1000 Trent W. Buck wrote: limit package mmdebstrap reassign 972571 dash thanks I don’t think this is correct, there is nothing more to fix in dash as #974825 has been fixed a long time ago. -- Cheers, Andrej
Bug#1018861: adduser --gid fails with "group '-1' does not exist"
Control: tag -1 confirmed On Thu, Sep 01, 2022 at 07:45:24AM +0200, Boris Kolpackov wrote: > I get the following error when first adding a group and then trying > to add a user with this group: > > # addgroup --gid 2000 build > # adduser --uid 2000 --gid 2000 --home /build --gecos "" --disabled-password > build > Adding user `build' ... > Use of uninitialized value $grname in printf at /usr/sbin/adduser line 625. > Adding new user `build' (2000) with group ` (-1)' ... > useradd: group '-1' does not exist > adduser: `/sbin/useradd -d /build -g -1 -s /bin/bash -u 2000 build' returned > error code 6. Exiting. I confirm this behavior as a bug in adduser 3.128 itself. > This is using Debian testing (bookworm) and I see > that the adduser package hasn't changed since stable (bullseye) Debian stable (bullseye) has adduser 3.118. The current version in testing is 3.128, which has migrated from unstable to testing on 2022-08-27. So it is not a big surprise that this behavior is new for you. Sadly, the only workaround currently available is to use --ingroup. When this bug report gets marked as closed by upload of a fixed version, there will be an additional delay before the fix becomes available in testing. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1014867: wolfssl: Update to latest upstream version
I have pinged the maintainer on IRC asking if he's still interested in maintaining WolfSSL (as I've seen a recent email on pkg-haskell-maintainers suggesting he might not be available for it). The newest upstream release 5.5.0 (Aug 30, 2022) adds support to HTTP3: "QUIC support added, for using wolfSSL with QUIC implementations like ngtcp2" https://github.com/wolfSSL/wolfssl/blob/aa036b6ea402e9159d2a9b12c7f05701d44a4f09/ChangeLog.md#new-feature-additions ngtcp2 is packaged on Debian so that opens up the opportunity of having HTTP3 through WolfSSL. Regards, -- Samuel Henrique
Bug#1019144: librust-dialoguer-dev: impossible to install
Package: librust-dialoguer-dev Version: 0.10.1-1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Binary package librust-dialoguer-dev is impossible to install, as it depends on unavailable package librust-fuzzy-matcher-0.3+default-dev - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMUwWQACgkQLHwxRsGg ASFFig/+NpM/heUD2TaGbHpZhmAdIvpWf6iXZ4Q+g/YTUnVXc1YUy9GsG8RrqYn+ YIu3phL//Tj7FCveoxSfWqbk4gXU4oTP12KcIKNkGJFHijqRWn8R1/q16GmfvIxQ A1xIBpwFx8mGWjbpysLGR5lz50mf4A2RmefXy04tkt5+t3ghEXUssPEUWwmYMRKD XSAOhkC9h7U3kNWiJSi7lq9lsV/45gMtaYLSGFU/LEfNpUpMh53OIxb2fYCs4xw0 IsfqkEd+J78IuQ8rqOG3CipVvZfsQqn+MEUtDrPEBdwuSD9bOjUSUQqIvklLQECu 8fYgpTWRM/ICWFQqkr5YIwh9iHk/+Ppk0ssa4UF1pm2XLUXLZZCHvNkjukboQIhu 1DYz1jLgNhrKjpaIWqh+XBb0AvzWfjTWa2f8bbTATI4W1cREiGgA1CpoD7NPZblj FdBQn8p4i33Ls0d88BCXOjaHXe1rE79HAH4ByksXdzQ+J2NocWeYKqBR0xbq0fkE EeVCeMdUM82qBBfH+cR6IfBYQnp909dBQrSWezIq3sDBJHbdd6biJG0zsbOzYU4z A/z/bpz/9nKHHSTZi/v/dBvg8EcF+d1w8EOF1FOAfDpOj+qwZPMlJ2ntHzXIvssZ LzwKRZwNnaSTwWqg4pAULfvNbOaDbPBDNBXtJ8qzPPUCrY0XT5w= =9O94 -END PGP SIGNATURE-
Bug#1016936: dwz: fails while building assaultcube
Package: dwz Version: 0.14-1 Followup-For: Bug #1016936 It also fails for nodejs (gcc 11 on mips64el): https://buildd.debian.org/status/fetch.php?pkg=nodejs&arch=mips64el&ver=18.8.0%2Bdfsg-1&stamp=1662286086&raw=0 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dwz depends on: ii libc62.34-7 ii libelf1 0.187-2 dwz recommends no packages. dwz suggests no packages. -- no debconf information
Bug#1019143: linux: Please enable CONFIG_SND_SOC_RK3288_HDMI_ANALOG
Source: linux Version: 5.10.127-1 Severity: wishlist It would be great if linux-image-armmp* packages compiled this module. It is useful on some chromebooks (at least veyron-speedy c201). Thanks ! -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1017772: OneTBB migration to testing stalled
Control: affects -1 src:onetbb It's due to a regression bug in GCC-12 that caused linker internal error on ppc64el: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017772 Does not look like something I can look into. If you need it soon in testing, please go ahead and downgrade compiler to gcc-11 for ppc64el only. On Sun, 2022-09-04 at 10:50 +0530, Nilesh Patra wrote: > Hi Mo, > > It seems that the migration of oneTBB to testing is stalled (since 16 > days) due > to FTBFS on ppc64el with some linker errors[1] > I am not sure what is up there, could you please take a look? > > [1]: > https://buildd.debian.org/status/fetch.php?pkg=onetbb&arch=ppc64el&ver=2021.5.0-13&stamp=1662266636&raw=0 >
Bug#1017723: bullseye-pu: package nftables/0.9.8-3.2
On 2022-09-03, at 14:53:45 +0100, Adam D. Barratt wrote:
> On Fri, 2022-08-19 at 16:05 +0100, Jeremy Sowden wrote:
> > The related nftables bug is:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017359
> >
> > [ Reason ]
> > nftables uses a fixed-size array containing the locations of the
> > expressions within each rule that it sends to the kernel to provide
> > more informative error-reporting. If the rule is rejected by the
> > kernel, the kernel will provide an ID for the expression which was
> > responsible, and nftables will use this to highlight it when
> > outputting the rule in the error message:
> >
> > # nft add rule t c iif lo reject with icmp 255
> > Error: Could not process rule: Invalid argument
> > add rule t c iif lo reject with icmp 255
> > ^^
> >
> > There is an off-by-one error in the bounds-checking used before
> > adding the details of an expression to this array. The result of
> > this is that if a rule contains enough expressions, nftables will
> > write past the end of the array leading to memory-corruption and
> > possibly crashes.
>
> The debdiff is somewhat confusing.
>
> +nftables (0.9.8-3.2) unstable; urgency=medium
>
> This is an upload to bullseye, not unstable. Additionally, the version
> should be 0.9.8-3.1+deb11u1.
>
> + -- Sven Auhagen Sat, 16 Jul 2022 11:29:27 +0200
>
> Who is this? It's obviously not you, but also doesn't appear to be
> related to the nftables bug report you mentioned.
Whoops. Silly mistakes. Still learning the ropes. I've amended the
change-log entry.
I've also added myself to `Uploaders` (I am already listed as one in
testing and unstable).
New debdiff attached.
Thanks for the pointers,
J.
diff -Nru nftables-0.9.8/debian/changelog nftables-0.9.8/debian/changelog
--- nftables-0.9.8/debian/changelog 2021-07-20 09:01:47.0 +0100
+++ nftables-0.9.8/debian/changelog 2022-09-04 09:34:11.0 +0100
@@ -1,3 +1,14 @@
+nftables (0.9.8-3.1+deb11u1) bullseye; urgency=medium
+
+ * d/p/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
+It fixes a one off for the check for NFT_NLATTR_LOC_MAX
+which leads to double free or corruption (out) error.
+Thanks to Sven Auhagen for
+suggesting the fix (closes: #1017359).
+ * d/control: add myself to uploaders.
+
+ -- Jeremy Sowden Sun, 04 Sep 2022 09:34:11 +0100
+
nftables (0.9.8-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru nftables-0.9.8/debian/control nftables-0.9.8/debian/control
--- nftables-0.9.8/debian/control 2021-07-20 09:01:47.0 +0100
+++ nftables-0.9.8/debian/control 2022-09-04 09:34:11.0 +0100
@@ -2,7 +2,8 @@
Section: net
Priority: important
Maintainer: Debian Netfilter Packaging Team
-Uploaders: Arturo Borrero Gonzalez
+Uploaders: Arturo Borrero Gonzalez ,
+ Jeremy Sowden
Build-Depends: asciidoc-base,
automake,
bison,
diff -Nru
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
---
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
1970-01-01 01:00:00.0 +0100
+++
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
2022-09-04 09:26:53.0 +0100
@@ -0,0 +1,32 @@
+From 2d0a7a9adeb30708d6fbbee57476c0d4b9214dbd Mon Sep 17 00:00:00 2001
+From: Phil Sutter
+Date: Fri, 11 Jun 2021 17:08:34 +0200
+Subject: rule: Fix for potential off-by-one in cmd_add_loc()
+
+Using num_attrs as index means it must be at max one less than the
+array's size at function start.
+
+Fixes: 27362a5bfa433 ("rule: larger number of error locations")
+Signed-off-by: Phil Sutter
+---
+ src/rule.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+(limited to 'src/rule.c')
+
+diff --git a/src/rule.c b/src/rule.c
+index dbbe744e..92daf2f3 100644
+--- a/src/rule.c
b/src/rule.c
+@@ -1275,7 +1275,7 @@ struct cmd *cmd_alloc(enum cmd_ops op, enum cmd_obj obj,
+
+ void cmd_add_loc(struct cmd *cmd, uint16_t offset, const struct location *loc)
+ {
+- if (cmd->num_attrs > NFT_NLATTR_LOC_MAX)
++ if (cmd->num_attrs >= NFT_NLATTR_LOC_MAX)
+ return;
+
+ cmd->attr[cmd->num_attrs].offset = offset;
+--
+cgit v1.2.3
+
diff -Nru nftables-0.9.8/debian/patches/series
nftables-0.9.8/debian/patches/series
--- nftables-0.9.8/debian/patches/series2021-07-20 09:01:47.0
+0100
+++ nftables-0.9.8/debian/patches/series2022-09-04 09:26:53.0
+0100
@@ -1 +1,2 @@
payload-check-icmp-dependency-before-removing-previo.patch
+rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
signature.asc
Description: PGP signature
Bug#1019054: [Pkg-phototools-devel] Bug#1019054: darktable: Darktable does not save Metadata in exported jpgs anymore, even author/copyright entries are gone!
Hi David, Am 03.09.22 um 17:17 schrieb David Bremner: Kerstin Hoef-Emden writes: In oldstable, darktable saved all metadata upon export, even temperature of the camera body etc. I expect those data either not to be lost, so I can choose which ones to delete/maintain with help of exiftool or that the metadata editor offers the major spectrum of entries concerning camera settings including copyright. It would be helpful if you can confirm that the problem is still present in darktable 3.8.0-2~bpo11+1, available from bullseye-backports. I deinstalled darktable from bullseye and installed darktable from bullseye-backports (version 3.8.0-2~bpo11+1). a) I exported a jpg. Exif-data contained only information about rating and time (see attached Exif.png). b) I selected a photo, opened the metadata editor and told it to apply (Metadaten-Editor_lokale_Einstellung.png). After that I exported the jpg. Result was the same as in a). c) I opened the wheel and Voreinstellungen, went to the global settings of the meta data editor. It differed from the older darktable version in, that no percent symbols were visible (Metadaten-Editor_globale Einstallung.png). I can double-click on "Alle Rechte" and it offers a field to type something in. But apparently this is only to give a name ro a setting, rather than to change a setting. Currently I see no way how to activate inclusion of metadata into export of jpgs. Best wishes, Kerstin
Bug#1018735: rtpengine: FTBFS with libwebsockets/4.3+
Control: reopen -1 On Tue, Aug 30, 2022 at 10:14 AM Victor Seva wrote: > version in bookwork is alredy 10.5.1.3-1 and that one has [0] that is the > backport of the > commit you mention. I was wrong then as your package with version 10.5.1.3-1 does fail to build with libwebsockets 4.3.2-1 from experimental. Relevant lines are from its self-testing: -- cut -- test "$(ls fake-daemon-tests-main-sockets)" = "" rmdir fake-daemon-tests-main-sockets EEE == ERROR: testKeepalive (__main__.TestVideoroom) -- Traceback (most recent call last): File "/build/rtpengine-10.5.1.3/t/auto-daemon-tests-websocket.py", line 344, in testKeepalive (token, session) = self.startSession() File "/build/rtpengine-10.5.1.3/t/auto-daemon-tests-websocket.py", line 173, in startSession eventloop.run_until_complete( File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in run_until_complete return future.result() File "/build/rtpengine-10.5.1.3/t/auto-daemon-tests-websocket.py", line 58, in testIOJanus await self._ws.send(json.dumps(msg)) AttributeError: 'TestVideoroom' object has no attribute '_ws' == ERROR: testVideoroomDTLS (__main__.TestVideoroom) -- Traceback (most recent call last): File "/build/rtpengine-10.5.1.3/t/auto-daemon-tests-websocket.py", line 809, in testVideoroomDTLS (token, session, control_handle, room) = self.startVideoroom() File "/build/rtpengine-10.5.1.3/t/auto-daemon-tests-websocket.py", line 206, in startVideoroom (token, session) = self.startSession() File "/build/rtpengine-10.5.1.3/t/auto-daemon-tests-websocket.py", line 173, in startSession eventloop.run_until_complete( File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in run_until_complete return future.result() File "/build/rtpengine-10.5.1.3/t/auto-daemon-tests-websocket.py", line 58, in testIOJanus await self._ws.send(json.dumps(msg)) AttributeError: 'TestVideoroom' object has no attribute '_ws' -- cut -- Please check if the new upstream release of it, versioned 11.0.1.1 fixes this problem or not. Regards, Laszlo/GCS
Bug#1017730: pmix: drop Build-Depends: pandoc
Source: pmix Version: 4.2.0+really.4.1.2-2 Followup-For: Bug #1017730 Hi Alistair, would be useful if the pandoc removal patch could be applied to the 4.2.0+really.4.1.2 versions. Cheers, Drew
Bug#1019141: RFS: mailfilter/0.8.9-1 [RC] -- Program that filters your incoming e-mail to help remove spam
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "mailfilter": * Package name: mailfilter Version : 0.8.9-1 Upstream Author : Andreas Bauer baue...@users.sourceforge.net * URL : https://mailfilter.sourceforge.io/ * License : GPL-2, LPGL-2.1, GPL-2+, permissive, GPL-2+ with OpenSSL exception * Vcs : https://salsa.debian.org/riesebie/mailfilter Section : mail The source builds the following binary packages: mailfilter - Program that filters your incoming e-mail to help remove spam To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mailfilter/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mailfilter/mailfilter_0.8.9-1.dsc Changes since the last upload: mailfilter (0.8.9-1) unstable; urgency=medium . * Import new upstream version. Thanks upstream for cooperation. (Closes: 1018713) * Refresh patches as needed. Regards, -- Excellent day for drinking heavily. Spike the office water cooler;-) signature.asc Description: PGP signature
Bug#1019140: unbound-resolvconf.service will always be in failed state when you set RESOLVCONF=false
Package: unbound Version: 1.16.2-1 Severity: normal Dear Maintainer, I am using unbound as recursive dns resolver for my local network, not just for localhost. My /etc/resolv.conf is mintainted by systemd-resolved and DNS server gets set by systemd-networkd. In the past, unbound-resolvconf.service was skipped: Aug 25 03:51:47 router systemd[1]: Unbound asyncronous resolvconf update helper was skipped because of a failed condition check (ConditionFileIsExecutable=/sbin/resolvconf). Since systemd was upgraded (251.3-1 -> 251.4-3) and systemd-resolved became an own package which now provides /sbin/resolvconf, unit is no longer being skipped and fails now: Sep 04 14:46:59 router resolvconf[1078]: No DNS servers specified, refusing operation. Because DNS server is getting set via systemd-networkd/systemd-resolved on this box, I created $ echo RESOLVCONF=false > /etc/default/unbound However, while resolvconf part is now beeing skipped by /usr/libexec/unbound-helper, unit is still failing: Sep 04 14:50:38 router systemd[1]: Started Unbound asyncronous resolvconf update helper. Sep 04 14:50:38 router systemd[1]: unbound-resolvconf.service: Main process exited, code=exited, status=1/FAILURE Sep 04 14:50:38 router systemd[1]: unbound-resolvconf.service: Failed with result 'exit-code'. This seems to happen because of $ /usr/libexec/unbound-helper resolvconf_start + UNBOUND_CONF=/etc/unbound/unbound.conf + UNBOUND_BASE_DIR=/etc/unbound + unbound-checkconf -o chroot + CHROOT_DIR= + DNS_ROOT_KEY_FILE=/usr/share/dns/root.key + ROOT_TRUST_ANCHOR_FILE=/var/lib/unbound/root.key + RESOLVCONF=true + ROOT_TRUST_ANCHOR_UPDATE=true + [ -f /etc/default/unbound ] + . /etc/default/unbound + RESOLVCONF=false + RESOLVCONF=false + do_resolvconf_start + [ false != false -a -x /sbin/resolvconf ] + return router ~ $ echo $? 1 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unbound depends on: ii adduser 3.128 ii init-system-helpers 1.64 ii libc62.34-7 ii libevent-2.1-7 2.1.12-stable-5+b1 ii libnghttp2-141.49.0-1 ii libprotobuf-c1 1.4.1-1 ii libpython3.103.10.6-1 ii libssl3 3.0.5-2 ii libsystemd0 251.4-3 ii lsb-base 11.2 Versions of packages unbound recommends: ii dns-root-data 2021011101 Versions of packages unbound suggests: ii apparmor 3.0.7-1 ii openssl 3.0.5-2 -- no debconf information
Bug#1019139: ITP: zpaqfranz -- Swiss army knife for backup and disaster recovery
Package: wnpp Severity: wishlist Owner: Franco Corbelli * Package name: zpaqfranz Version : 55.14 Upstream Author : Franco Corbelli * URL : https://github.com/fcorbelli/zpaqfranz * License : MIT Programming Lang: C, C++ Description : Swiss army knife for backup and disaster recovery Like 7z or RAR on steroids,with deduplicated "snapshots" (versions) Conceptually similar to Mac time machine, but much more efficiently Keeps backup always-to-always, no need to ever prune (CryptoLocker) Easily handles millions of files and TBs of data, non-latin support Cloud backups with full encryption, minimal data transfer/bandwidth Data integrity check CRC32+XXHASH|SHA-1|SHA-2|SHA-3|MD5|XXH3|BLAKE3 Thorough data verification, multithread support (real world 1GB+/s) Specific zfs handling functions,full multiplatform interoperability Particularly suitable for minimal space storage of virtual machines Windows, FreeBSD, OpenBSD, Linux, MacOS, Solaris, OmniOS and others __ This is a fork of zpaq 7.15 (already in Debian) which was abandoned by the developer (Matt Mahoney) in 2016. I have integrated innovative features, in particular the compatibility with the zfs filesystem, which is increasingly popular also on Debian, and controls up to the paranoid level. It also works on "weird" platforms (eg PowerPC big endian), but I don't really know how to configure rules :) Basically it is an evolution from a file compressor (zpaq) to an archiver / backup (zpaqfranz) I have attempted to contact the maintainer of zpaq 7.15, and an Italian senior Debian developer, but without answer It is going to be included in the FreeBSD and OpenBSD ports and I get about 70 github stars (of course few, but not zero) I definitely need a sponsor and, even more, advices from those who are more experienced (this is my very first attempt with Debian) for the "packaging" process https://forums.debian.net/viewtopic.php?f=30&t=152620 It is not so easy to disentangle the various versions, warnings and guides that are not always updated
Bug#1019137: FTBFS: FAIL: TestNewCmdCompletion/zsh_completion
Source: gh Version: 2.14.4+dfsg1-1 Severity: serious Tags: ftbfs X-Debbugs-Cc: z...@debian.org --- FAIL: TestNewCmdCompletion (0.00s) --- PASS: TestNewCmdCompletion/no_arguments (0.00s) --- FAIL: TestNewCmdCompletion/zsh_completion (0.00s) --- PASS: TestNewCmdCompletion/fish_completion (0.00s) --- PASS: TestNewCmdCompletion/PowerShell_completion (0.00s) --- PASS: TestNewCmdCompletion/unsupported_shell (0.00s) Caused by golang-github-spf13-cobra 1.5.0 https://salsa.debian.org/go-team/packages/golang-github-spf13-cobra/-/commit/37d481d4
Bug#1016414: abinit: autopkgtest failure
Hi Bas On Sun, 4 Sept 2022 at 14:20, Sebastiaan Couwenberg wrote: > Since no one cares enough about netcdf-fortran, I'll go an have it > removed from the archive as I'm not willing to spend time on issues like > these. I'm sure you are aware, but we have a process [1] for passing packages on to other maintainers. I suggest speaking to Alastair (now added as a recipient). He maintains most of netcdf-fortran's reverse-dependencies. Regards Graham [1] https://wiki.debian.org/Orphaning
Bug#1019136: cmake injects randomly named dummy function to output binary and it breaks reproducible build
Package: cmake
Version: 3.24.1-1
Severity: normal
X-Debbugs-Cc: yokota.h...@gmail.com
Dear Maintainer,
Current CMake (3.24.1) injects randomly named dummy function to output binary.
Output binary works well, but this issue breaks reproducible build.
Injected code can be examine from here:
https://salsa.debian.org/cmake-team/cmake/-/blob/debian/3.24.1-1/Source/cmQtAutoMocUic.cxx#L2177
```c++
// Placeholder content
cmCryptoHash hash(cmCryptoHash::AlgoSHA256);
const std::string hashedPath = hash.HashString(compAbs);
const std::string functionName =
"cmake_automoc_silence_linker_warning" + hashedPath;
content += "// No files found that require moc or the moc files are "
"included\n"
"void " +
functionName + "() {}\n";
```
Randomly named dummy function was generated from absolute path name and SHA256.
Absolute path name might be vary in each development machines because
source code will be placed in each developer's own path.
So, this feature generates non-deterministic output, and breaks
reproducible build.
Here is issue about this feature in upstream:
https://gitlab.kitware.com/cmake/cmake/-/issues/23551
And merge request:
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7558
This bug will break Debian "calibre" package from reproducible build.
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/calibre.html
I want to make Debian "calibre" package to reproducible.
--
YOKOTA Hiroshi
Bug#1016414: abinit: autopkgtest failure
Control: tags -1 wontfix On 9/4/22 13:42, Graham Inggs wrote: You wrote: No other netcdf-fortran rdeps have shown issues which leads me to suspect it is an issue in abinit. Only abinit has a comprehensive autopkgtest. The other reverse dependencies, cdftools, etsf-io, ferret-vis, ncl and oasis3 have no autopkgtests, and pyferret only has a superficial 'import pyferret' test. You also wrote: Rebuilding with netcdf-fortan (4.6.0+ds-1) resolves the issue. If no change in abinit was needed, why do you suspect an issue in abinit? Because only that package has an issue. I don't know any fortran, so I cannot troubleshoot this issue. In your request for a binNMU in #1016496, you were asked if libnetcdff shouldn't have bumped its SONAME. Someone needs to talk to upstream to get this unblocked. I'm not going to be that person. I was hoping that the abinit maintainer would chime in, but they haven't responded to this issue for almost two months. Since no one cares enough about netcdf-fortran, I'll go an have it removed from the archive as I'm not willing to spend time on issues like these. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1019135: O: netcdf-fortran -- creation, access, and sharing of scientific data in Fortran
Package: wnpp Severity: normal Control: affects -1 src:netcdf-fortran netcdf-fortran is RC-buggy. None of its Uploaders are still active in its maintenance. Unmaintained packages should be removed from the archive, but it has several reverse dependencies which block its removal. The package needs someone who knows Fortran and/or cares enough about the package to spend time on issues affecting the package. The package description is: NetCDF (network Common Data Form) is a set of interfaces for array-oriented data access and a freely distributed collection of data access libraries for C, Fortran, C++, Java, and other languages. The netCDF libraries support a machine-independent format for representing scientific data. Together, the interfaces, libraries, and format support the creation, access, and sharing of scientific data. . This package contains headers for the Fortran library.
Bug#1016414: abinit: autopkgtest failure
Control: reassign -1 src:netcdf-fortran 4.6.0+ds-1 Control: affects -1 src:abinit Hi Bas You wrote: > No other netcdf-fortran rdeps have shown issues which leads me to > suspect it is an issue in abinit. Only abinit has a comprehensive autopkgtest. The other reverse dependencies, cdftools, etsf-io, ferret-vis, ncl and oasis3 have no autopkgtests, and pyferret only has a superficial 'import pyferret' test. You also wrote: > Rebuilding with netcdf-fortan (4.6.0+ds-1) resolves the issue. If no change in abinit was needed, why do you suspect an issue in abinit? In your request for a binNMU in #1016496, you were asked if libnetcdff shouldn't have bumped its SONAME. Someone needs to talk to upstream to get this unblocked. Regards Graham
Bug#1019134: firmware-testing-amd64-netinst.iso's content on a FAT32 partition doesn't work anymore
Package: firmware-testing-amd64-netinst.iso Version: Debian GNU/Linux testing "Bookworm" - Unofficial amd64 NETINST with firmware 20220904-09:36 Severity: important Tags: d-i X-Debbugs-Cc: jeremy.bezai...@gmail.com -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-25193-Microsoft Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Hi Although a FAT32 partition with a firmware-testing-amd64-netinst.iso's ( I don't remember its version ) content worked ( https://forums.debian.net/viewtopic.php?f=17&t=152402 , my last post ) , it doesn't work anymore with the current firmware-testing-amd64-netinst.iso : If a SD card plugged : Detect and mount installation media Incorrect installation media detected The detected media cannot be used for installation. Please provide suitable media to continue with the installation. If no SD card plugged : Detect and mount installation media Your installation media couldn't be mounted. When installing from CD-ROM, this probably means that the disk was not in the drive. If so you can insert it and try again. Retry mounting installation media? No Yes I tried FAT32 and FAT partition . I wonder also why firmware-testing-amd64-netinst.iso in https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/daily-builds/sid_d-i/current/amd64/iso-cd/ updated very often ? Thanks for your free and open source work .
Bug#1018689: override: python3:python/standard
On Sat, 03 Sep 2022 at 22:41:36 -0700, Sean Whitton wrote: > On Sun 28 Aug 2022 at 10:33PM -05, Daniel Lewart wrote: > > Currently, python3 is Priority: optional. > > > > The following Buster packages have Priority: standard: > > * python > > * python-minimal > > * python2.7 > > * python3-reportbug > > > > Now the following Priority:standard packages depend on python3 > > (directly or indirectly): > > * apt-listchanges > > * python3-reportbug > > * reportbug > > > > Therefore, I think that python3 should change from: > > Priority: optional > > to: > > Priority: standard > > I don't think these dependency relationships bear directly on the issue? I agree. In Debian Policy versions earlier than 4.0.1, we had the rule that if a Depends on b, then the Priority of a <= the Priority of b. However, that rule was removed in Policy 4.0.1 (2017), for good reasons: briefly, it resulted in supporting packages like obsolete/no-longer-used shared libraries and older versions of gcc-*-base remaining installed when there was no longer any real reason for them to be. The rule in Policy §2.5 is now: The priority of a package is determined solely by the functionality it provides directly to the user. The priority of a package should not be increased merely because another higher-priority package depends on it So python3 should not be elevated to standard priority merely because tools like reportbug depend on it: the dependency system will already ensure that reportbug's dependencies are present. Instead, the decision should be made on this basis: imagine that apt-listchanges and reportbug had been written or rewritten in some other language (perhaps Perl or C). Would we still want the python3 interpreter to be available in a standard Debian installation on its own merits, as an interpreter for user-written scripts and/or an interactive REPL, as part of "a reasonably small but not too limited character-mode system" that "doesn’t include many large applications"? On one hand, it's probably a positive thing for a "standard" Debian installation to include an interpreter for an easy-to-learn programming language with fewer sharp edges than shell script, both as something we can suggest people use to learn more about programming and as something we can encourage people to prefer over writing shell scripts. On the other hand, Python upstream would likely prefer for someone who is interested in learning Python to be expected to install python3-full, and it's difficult to say "python3 should be Priority: standard" without either making subjective value-judgements about the relative quality of various programming languages, or using reasoning that would apply equally to promoting (for example) ruby, nodejs or lua to standard (which seems like an approach that would scale poorly). Looking at other interpreters, we already have bash and perl-base in Essential, awk transitively Essential, and perl in Priority: standard. I would personally lean more towards demoting perl to optional than promoting python3 to standard. smcv
Bug#694320: [gsfonts] Fonts include copyrighted adobe fragment all rights reserved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 unblock 694320 by 694308 The fonts files in fonts-urw-core35 are not built by fontforge anymore. - Fabian -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMUfacACgkQy+qOlwzN Wd9hghAA0ZNlg3JqcZYSOI6XRWCSz22Q8hYKpFdqzXNSkY0O/aA9fFIPN2OC/p2b FIBWEgjZZ0o7aa060fu0hfYTajjQly9vRxZdmynYdxcISjmJ85qyVrkmYY0sMrWT yMpakN52mXK/E5lbwFdI0LNk6OZ9VKcPY09lxfXKZMPKZtBDEtVdnCD+hHOJ6MQs iF7wLB+R9Nf/E7sARv97FqprqIIkCU1pCuqmgD5/YxdcNlqYz3lDCv2IKqk53UFk wAQjedXM+OHAvE0zeo7UmAZraufVxyOC++U6yU0zcSiJlbTEkbVZSn/WsyxXjnk1 bSLl8PBuVfpRFY+ZMNhF6M27PEMa94AiVFaT06ZIFJByoP5BHqho1tJAMIlQAkFk ksaW7dPJz2FYDlDsC6HVVkMYg8t+cqii0vuZK9IabdQ49tF2RxYBYVhTybW+GRw8 Wc6/uW80Z+lqnrQ8l8pViMghQg1CGjShCdDL6J2DMJY4BboGM0Qd+hHONRhRStmX SrCKgBWRZLxYds/Iw3T+2TW1pWf8EZ1ElTAXQRiIMgaeOqMvkzGidD8eKYES5/Qz uwPyXyIQnLPrp2gMc05BC7VF47PR7SpE1E6rldqSESNxjY/PcNeVFDq8YC3ZEdPV RYgQPBwWONma16YHy65UXycrCRIWmru3hs3v+OwnbwMHSrqhzmo= =uJpJ -END PGP SIGNATURE-
Bug#1018957: mmdebstrap fails in proot mode
Hi Christoph, I'm putting the bug back in the CC and snipped your personal note. Quoting Christoph Groth (2022-09-03 23:06:19) > Many thanks for your very detailed answer! I learned a lot (and I still > have to digest it a bit more). > > I’m usually not debugging FTBFS but rather stuff unrelated to Debian and > some time ago I discovered that I could use mmdebstrap in the described > way. It worked for my application and I made myself some notes, but > without getting deep into it. > > Johannes Schauer Marin Rodrigues wrote: > > > it is totally possible to also use it for your use-case but that's > > rather hacky. If you want the functionality of entering a chroot you > > created and do stuff in it, maybe use some software that was meant to > > be used like that? For example you can combine mmdebstrap (for > > creating the chroot) with docker or podman or systemd-nspawn. See the > > man page for examples. > > Somehow, I mostly managed to evade containers so far. (For example the > nginx on my little cubieboard2 home server has simply been installed as > a regular Debian package.) > > If I understand correctly containers provide better encapsulation than > a chroot, and since for my debugging I don’t have any security concerns, > and since pbuilder/cowbuilder uses chroot for building and testing > packages, I thought that using a chroot is an appropriate solution for > my needs. Containers also use chroot but they use a bit more than that: linux user namespaces. Those allow separating entire process, mount and user name spaces from the rest of the system. I think most people do not use this for security purposes but because even with known software this prevents unintended modifications of the outer system. For example the default backend for sbuild is schroot which is just chroot. This means that if strange things happen, the stuff that schroot mounts into the chroot are leftover after a build and need to be manually cleaned up. Or processes can keep running and need to be cleaned up manually (if one even notices that they exist). So I added the unshare backend to sbuild which does chroot but also (like the container managers) uses linux user namespaces to encapsulate more things and thus prevent these kind of subtle bugs that need sudo to clean up. > What would I gain from using proper containers? In your case: you would gain proper file ownership which proot cannot give you. In general, I'm probably the wrong person to ask because I myself am using mmdebstrap --customize-hook='chroot "$1" bash' instead of docker, podman or systemd-nspawn. Honestly I have no clue about how to use docker properly. I can just say that those tools were made for the use-case of "enter a chroot environment" and thus (when used correctly) probably add way better usability than mmdebstrap can. It would not even be much of a security advantage because (just as the unshare mode of mmdebstrap), docker, podman and systemd-nspawn use linux user namespaces in the same way as mmdebstrap does. So if what you want to do work with proot, then I don't think there is a good reason for you to use anything else. > > So in summary, I still don't understand why proot-mode should stay. Even if > > I delete proot mode from mmdebstrap for good your use-case will still > > continue to work because you can create the chroot directory that you need > > for proot with the fakechroot mode. > > > > I would recommend you to use tarballs instead of creating directories > > for the reasons given above. But then again, since you are fine with > > proot it seems that you don't care about preserving ownership > > information. > > > > But then again, going back to your very initial issue (you want to > > debug a Debian FTBFS bug) it seems you do not need neither mmdebstrap > > nor proot and are just making your life more complicated. :) > > > > What do you think? > > I completely agree with your conclusions. Feel free to remove proot > support from mmdebstrap as far as I’m concerned. Thank you, your input was very valuable because proot was essentially broken since 16 August 2021 and I was waiting for somebody to tell me that they are a proot user and why they need it. You are a proot user but it seems that creating the chroot in fakechroot mode instead of proot still lets you do what you need. Now I guess I can remove it for good. > [snipped personal bits] Yes, I understand German but if we exchange messages in German, then most people reading this bug will not be able to understand what's going on. :) My own RCX is also still alive but my daughter is only 19 months old tomorrow, so it'll be some time before she can play with it properly. ^^ Thanks! cheers, josch signature.asc Description: signature
Bug#1019133: ffmpeg: Please disable filter-overlay_yuv420p10 test on all BE targets
Source: ffmpeg Version: 7:5.1.1-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: hppa m68k powerpc ppc64 sparc64 X-Debbugs-Cc: debian-...@lists.debian.org,debian-h...@lists.debian.org,debian-powe...@lists.debian.org,debian-sp...@lists.debian.org Hello! The test filter-overlay_yuv420p10 fails which was disabled for s390x actually fails on all big-endian targets [1][2][3]. I therefore suggest expanding the blacklist to include hppa, m68k, powerpc, ppc64 and sparc64 which are also big-endian. See attached patch. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=hppa&ver=7%3A5.1.1-1&stamp=1662206663&raw=0 > [2] > https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=powerpc&ver=7%3A5.1.1-1&stamp=1662200733&raw=0 > [3] > https://buildd.debian.org/status/fetch.php?pkg=ffmpeg&arch=ppc64&ver=7%3A5.1.1-1&stamp=1662200252&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2022-08-24 14:32:39.0 -0700 +++ debian/rules2022-09-04 03:27:49.417221073 -0700 @@ -219,7 +219,7 @@ CONFIG += --ignore-tests=checkasm-sw_scale,filter-scale2ref_keep_aspect endif # https://trac.ffmpeg.org/ticket/9855 -ifeq (s390x,$(DEB_HOST_ARCH)) +ifneq (,$(filter hppa m68k powerpc ppc64 sparc64 s390x,$(DEB_HOST_ARCH_CPU))) CONFIG += --ignore-tests=filter-overlay_yuv420p10 endif
Bug#1011401: mount: umount bash completion explodes awk on some paths
Control: retitle -1 mount: umount bash completion explodes when HOME/PWD
contains [a-b] in path
Control: tags -1 + confirmed
On Sat, Sep 03, 2022 at 08:30:15PM +0200, наб wrote:
[...]
> -- >8 --
>
> Which I gamed down to:
> -- >8 --
> $ echo | gawk '{print ($0 ~ "[n-2]")}'
> gawk: cmd. line:1: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid range
> end: /[n-2]/
> $ echo | mawk '{print ($0 ~ "[n-2]")}'
> 0
> -- >8 --
>
> So the solution seems to be "don't use paths as regexes lmao".
> The correct spelling of that check would be
> substr($0, 0, length(ENVIRON["PWD"])) == ENVIRON["PWD"]
> and of the subsequent string manipulation as
> reldir = substr($0, length(ENVIRON["PWD"]) + 1)
> sub("^/", "", reldir)
> for the second branch and
> substr($0, 0, length(ENVIRON["HOME"])) == ENVIRON["HOME"]
> with
> homeless = "~" substr($0, length(ENVIRON["HOME"]) + 1)
> for the first (checked on mawk and gawk).
>
> Best,
> наб
Thanks for narrowing this down. Could you please submit your findings
to the upstream mailing list? (util-linux at vger.kernel.org)
(I've confirmed I can reproduce this. Also making bug title more
specific while at it.)
Regards,
Andreas Henriksson
Bug#688228: python-gi: Add README.Debian explaining how to get information on the python bindings
control: retitle -1 Provide doc package on how to use python bindings
control: tags -1 patch
On Sat, 23 Jan 2021 18:40:05 + Stephan Lachnit
wrote:
> Just reading through this issues, and this seems to be fixed a while ago.
>
> 1. The documentation for PyGObject is available now [1].
Ideally this should be build as a -doc package,
for which I've created a WIP MR on salsa [2].
I've also attached it as a patch, but I want to point out again,
that this is not quite working, so any help would be appreciated.
> 2. Gtk bindings are now in a separate package, e.g. gir1.2-gtk-3.0
>
> I think this can be closed by now.
I think this should only be closed once the (proposed) -doc package hits the
archive.
> [1] https://lazka.github.io/pgi-docs/
[2] https://salsa.debian.org/gnome-team/pygobject/-/merge_requests/7
--
Cheers,
Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19
From 97a672f0e2511df76f728e2bad398aeb06219697 Mon Sep 17 00:00:00 2001
From: Evangelos Ribeiro Tzaras
Date: Sun, 4 Sep 2022 11:08:06 +0200
Subject: [PATCH] Install docs in new python-gi-doc package
Closes: #688228
---
debian/control | 19 +++
debian/control.in| 19 +++
debian/python-gi-doc.install | 1 +
debian/rules | 10 ++
4 files changed, 49 insertions(+)
create mode 100644 debian/python-gi-doc.install
diff --git a/debian/control b/debian/control
index 7201034e..c9b5c4e3 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,7 @@ Build-Depends: at-spi2-core ,
debhelper-compat (= 13),
dh-sequence-gnome,
dh-sequence-python3,
+ dia ,
dpkg-dev (>= 1.16.1~),
gir1.2-gtk-3.0 ,
libcairo2-dev,
@@ -25,6 +26,8 @@ Build-Depends: at-spi2-core ,
python3-flake8 ,
python3-pytest ,
python3-setuptools,
+ python3-sphinx ,
+ python3-sphinx-rtd-theme ,
xauth ,
xvfb
Rules-Requires-Root: no
@@ -40,6 +43,7 @@ Depends: gir1.2-glib-2.0 (>= 1.48.0),
${misc:Depends},
${python3:Depends},
${shlibs:Depends}
+Suggests: python-gi-doc
Description: Python 3 bindings for gobject-introspection libraries
GObject is an abstraction layer that allows programming with an object
paradigm that is compatible with many languages. It is a part of Glib,
@@ -96,3 +100,18 @@ Description: Python 3 Cairo bindings for the GObject library
.
This package contains the Python 3 Cairo bindings for GObject. It is mostly
used by other bindings to map their GObjects to Python objects.
+
+Package: python-gi-doc
+Architecture: all
+Section: doc
+Build-Profiles:
+Depends:
+ ${misc:Depends},
+ ${sphinxdoc:Depends},
+Description: Documentation for python3 bindinfs for gobject-introspection libraries
+ GObject is an abstraction layer that allows programming with an object
+ paradigm that is compatible with many languages. It is a part of Glib,
+ the core library used to build GTK+ and GNOME.
+ .
+ This package contains the documentation for how to use the
+ python3 bindings.
diff --git a/debian/control.in b/debian/control.in
index 5ea09bc9..688d4867 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -8,6 +8,7 @@ Build-Depends: at-spi2-core ,
debhelper-compat (= 13),
dh-sequence-gnome,
dh-sequence-python3,
+ dia ,
dpkg-dev (>= 1.16.1~),
gir1.2-gtk-3.0 ,
libcairo2-dev,
@@ -21,6 +22,8 @@ Build-Depends: at-spi2-core ,
python3-flake8 ,
python3-pytest ,
python3-setuptools,
+ python3-sphinx ,
+ python3-sphinx-rtd-theme ,
xauth ,
xvfb
Rules-Requires-Root: no
@@ -36,6 +39,7 @@ Depends: gir1.2-glib-2.0 (>= 1.48.0),
${misc:Depends},
${python3:Depends},
${shlibs:Depends}
+Suggests: python-gi-doc
Description: Python 3 bindings for gobject-introspection libraries
GObject is an abstraction layer that allows programming with an object
paradigm that is compatible with many languages. It is a part of Glib,
@@ -92,3 +96,18 @@ Description: Python 3 Cairo bindings for the GObject library
.
This package contains the Python 3 Cairo bindings for GObject. It is mostly
used by other bindings to map their GObjects to Python objects.
+
+Package: python-gi-doc
+Architecture: all
+Section: doc
+Build-Profiles:
+Depends:
+ ${misc:Depends},
+ ${sphinxdoc:Depends},
+Description: Documentation for python3 bindinfs for gobject-introspection libraries
+ GObject is an abstraction layer that allows programming with an object
+ paradigm that is compatible with many languages. It is a part of Glib,
+ the core library used to build GTK+ and GNOME.
+ .
+ This package contains the documentation for how to use
Bug#1017825: no metadata in dolphin information panel
Otherwise, which config file should I delete in order to reset dophin to a pristine state? On 23/08/22 06:47, r087...@yahoo.it wrote: Hello, I have tried to ``` ~$ mv .local/share/kxmlgui5/dolphin/dolphinui.rc .local/share/kxmlgui5/dolphin/dolphinui.rc.bak ~$ mv .local/share/dolphin/dolphinstaterc .local/share/dolphin/dolphinstaterc.bak ~$ mv .config/dolphinrc .config/dolphinrc.bak ``` but it does not seem to help. What else can it be? Best, Rob
Bug#1019132: pygobject: FTBFS if build twice in a row
control: tags -1 patch On Sun, 04 Sep 2022 11:44:43 +0200 Evangelos Ribeiro Tzaras wrote: > Source: pygobject > Version: 3.42.2-2 > Severity: normal > User: debian...@lists.debian.org > Usertags: qa-doublebuild > > Hi, > > while playing with the package I've noticed that the package FTBFS if > build twice in a row with the following error: > > > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building pygobject using existing ./pygobject_3.42.2.orig.tar.xz [...] > dpkg-source: error: unrepresentable changes to source > dpkg-buildpackage: error: dpkg-source -i -I -b . subprocess returned exit status 1 I've opened a MR on salsa [0] as well as attaching the patch here as I'm not sure how you prefer to receive patches [0] https://salsa.debian.org/gnome-team/pygobject/-/merge_requests/6 -- Cheers, Evangelos PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19 From caea89235bb9e851d34047f4b52e4640e287b7fd Mon Sep 17 00:00:00 2001 From: Evangelos Ribeiro Tzaras Date: Sun, 4 Sep 2022 11:27:56 +0200 Subject: [PATCH] d/rules: Clean up all build files we want to have a pristine directory after running debian/rules clean This patch gets rid of all the files left behind. Closes: #1019132 --- debian/rules | 9 + 1 file changed, 9 insertions(+) diff --git a/debian/rules b/debian/rules index c2a3ef0a..981f6f0e 100755 --- a/debian/rules +++ b/debian/rules @@ -70,3 +70,12 @@ override_dh_makeshlibs: override_dh_installchangelogs: dh_installchangelogs -XChangeLog + +override_dh_clean: + dh_clean + rm -f config.h + rm -f gi/*.so + rm -f tests/*.gir + rm -f tests/*.typelib + rm -f tests/*.so + rm -f tests/gschemas.compiled -- 2.37.2 signature.asc Description: This is a digitally signed message part
Bug#1019132: pygobject: FTBFS if build twice in a row
Source: pygobject Version: 3.42.2-2 Severity: normal User: debian...@lists.debian.org Usertags: qa-doublebuild Hi, while playing with the package I've noticed that the package FTBFS if build twice in a row with the following error: dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building pygobject using existing ./pygobject_3.42.2.orig.tar.xz dpkg-source: error: cannot represent change to gi/_gi.cpython-310-x86_64-linux-gnu.so: binary file contents changed dpkg-source: error: add gi/_gi.cpython-310-x86_64-linux-gnu.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'gi/_gi.cpython-310-x86_64-linux-gnu.so' will not be represented in diff dpkg-source: error: cannot represent change to gi/_gi.cpython-310d-x86_64-linux-gnu.so: binary file contents changed dpkg-source: error: add gi/_gi.cpython-310d-x86_64-linux-gnu.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'gi/_gi.cpython-310d-x86_64-linux-gnu.so' will not be represented in diff dpkg-source: error: cannot represent change to gi/_gi_cairo.cpython-310-x86_64-linux-gnu.so: binary file contents changed dpkg-source: error: add gi/_gi_cairo.cpython-310-x86_64-linux-gnu.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'gi/_gi_cairo.cpython-310-x86_64-linux-gnu.so' will not be represented in diff dpkg-source: error: cannot represent change to gi/_gi_cairo.cpython-310d-x86_64-linux-gnu.so: binary file contents changed dpkg-source: error: add gi/_gi_cairo.cpython-310d-x86_64-linux-gnu.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'gi/_gi_cairo.cpython-310d-x86_64-linux-gnu.so' will not be represented in diff dpkg-source: error: cannot represent change to tests/GIMarshallingTests-1.0.typelib: binary file contents changed dpkg-source: error: add tests/GIMarshallingTests-1.0.typelib in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to tests/Regress-1.0.typelib: binary file contents changed dpkg-source: error: add tests/Regress-1.0.typelib in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to tests/gschemas.compiled: binary file contents changed dpkg-source: error: add tests/gschemas.compiled in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: cannot represent change to tests/libgimarshallingtests.so: binary file contents changed dpkg-source: error: add tests/libgimarshallingtests.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'tests/libgimarshallingtests.so' will not be represented in diff dpkg-source: error: cannot represent change to tests/libregress.so: binary file contents changed dpkg-source: error: add tests/libregress.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'tests/libregress.so' will not be represented in diff dpkg-source: error: cannot represent change to tests/testhelper.cpython-310-x86_64-linux-gnu.so: binary file contents changed dpkg-source: error: add tests/testhelper.cpython-310-x86_64-linux-gnu.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'tests/testhelper.cpython-310-x86_64-linux-gnu.so' will not be represented in diff dpkg-source: error: cannot represent change to tests/testhelper.cpython-310d-x86_64-linux-gnu.so: binary file contents changed dpkg-source: error: add tests/testhelper.cpython-310d-x86_64-linux-gnu.so in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: executable mode 0755 of 'tests/testhelper.cpython-310d-x86_64-linux-gnu.so' will not be represented in diff dpkg-source: error: unrepresentable changes to source dpkg-buildpackage: error: dpkg-source -i -I -b . subprocess returned exit status 1 Thanks for maintaing pygobject!
Bug#1019131: r-bioc-dada2: autopkgtest regression in testing
Source: r-bioc-dada2
Version: 1.24.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime between 2022-06-15 and 2022-06-22, r-bioc-dada2's regressed
in testing [1]. I've copied what I hope is the relevant part of the
log below.
Regards
Graham
[1] https://ci.debian.net/packages/r/r-bioc-dada2/testing/amd64/
> library('dada2')
Loading required package: Rcpp
Error: package or namespace load failed for ‘dada2’ in dyn.load(file,
DLLpath = DLLpath, ...):
unable to load shared object '/usr/lib/R/site-library/dada2/libs/dada2.so':
/usr/lib/R/site-library/dada2/libs/dada2.so: undefined symbol: _ZTIN3tbb4taskE
Execution halted
Bug#1017832: dh-lua causes FTBFS error with glibc 2.35 due to catchsegv removal
Hi Paul, On 2022-09-04 07:52, Paul Gevers wrote: > Hi Aurelien, > > On Sat, 3 Sep 2022 11:36:07 +0200 Aurelien Jarno wrote: > > On 2022-08-21 11:49, Aurelien Jarno wrote: > > > dh-lua uses catchsegv, a binary currently provided by libc-bin when > > > executing the lua tests. This binary has been removed from glibc 2.35, > > > causing debci [1] or FTBFS failures on packages using dh-lua. > > > > I have attached a patch that stops wrapping test commands with > > > catchsegv, fixing the debci and FTBFS issue. Could you please schedule > > > an upload with this patch? > > > > First of all, I am very sorry to be a bit pushy there. This is the last > > fix needed before we can start the glibc 2.35 transition. > > To be honest, I don't think you need to be sorry here. glibc is way to > important to not be allowed to be pushy sometimes. Thanks for take so good > care of it. I really appreciate all the preparation you do before uploading > to unstable. > > > I have uploaded a NMU fixing this issue to DELAYED/15. Please find the > > corresponding debdiff attached. Also please feel free to ask me to delay > > or cancel this NMU. > > With my Release Manager hat on, I think it's quite OK to speed this up 10 > days (and preferably the maintainers just ack the change and you drop the > delay). Thanks for the hint, I have just done that. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#1017905: lowering severity
severity 1017905 normal thanks Lowering the severity until we hear back from ftpmasters.
Bug#1019130: emacs: Please include small patch to fix FTBFS on m68k
Source: emacs
Version: 1:28.1+1-2
Severity: normal
Tags: upstream patch
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org
Hello!
The build on m68k fails due to an alignment issue which can be fixed
by lowering DUMP_RELOC_ALIGNMENT_BITS to 1 in src/pdumper.c which is
what the attached patch does.
Can it be included in the next upload? See also the upstream bug [1].
Thanks,
Adrian
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44531
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--- emacs-28.1+1.orig/src/pdumper.c
+++ emacs-28.1+1/src/pdumper.c
@@ -265,7 +265,11 @@ struct dump_table_locator
enum
{
DUMP_RELOC_TYPE_BITS = 5,
+#ifdef __mc68000__
+ DUMP_RELOC_ALIGNMENT_BITS = 1,
+#else
DUMP_RELOC_ALIGNMENT_BITS = 2,
+#endif
/* Minimum alignment required by dump file format. */
DUMP_RELOCATION_ALIGNMENT = 1 << DUMP_RELOC_ALIGNMENT_BITS,
Bug#1019129: ecb + emacs 28.1: infinite loop start simultaneous emacs --batch
Package: ecb Version: 2.50+git20170628-1 Severity: normal Dear Maintainer, Right after installing ecb, opening a new emacs 28.1, ecb compilation triggers an infinite (I stop at 400) loop of emacs --batch "emacs -q", thus no user config triggers the loop "emacs -Q", thus no site config, does not I stop them with pkill -15 emacs after 400 of them (much larger than the number of .el in ecb): example line (from command part of ps -efl) /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr-- trampoline-64656c6574652d6672616d65_delete_frame_0-4fkX4b.el -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ecb depends on: ii dpkg 1.21.9 ii emacs1:28.1+1-2 ii emacs-gtk [emacsen] 1:28.1+1-2 ii install-info 6.8-6 ecb recommends no packages. ecb suggests no packages. -- no debconf information
Bug#1019128: gnome-builder: libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.
Package: gnome-builder Version: 42.1-1+b2 Severity: grave Tags: upstream Justification: renders package unusable X-Debbugs-Cc: tylermageeshie...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? GNOME Builder no longer works so I can no longer create GNOME apps * What exactly did you do (or not do) that was effective (or ineffective)? Enable backports * What was the outcome of this action? GNOME Builder crashes instantly a split second after launch * What outcome did you expect instead? GNOME Builder displays UI Log: (process:46288): libsoup-ERROR **: 09:19:28.122: libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported. Trace/breakpoint trap In the terminal I cannot use command line flags at all, it throws the same error. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-builder depends on: ii clang1:14.0-55.1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii exuberant-ctags 1:5.9~svn20110310-16 ii gir1.2-dazzle-1.03.44.0-1 ii gir1.2-ggit-1.0 1.1.0-1 ii gir1.2-glib-2.0 1.72.0-1+b1 ii gir1.2-gtk-3.0 3.24.34-3 ii gir1.2-gtksource-4 4.8.3-1 ii gir1.2-jsonrpc-1.0 3.42.0-1 ii gir1.2-peas-1.0 1.32.0-1+b1 ii gir1.2-template-1.0 3.35.0-1 ii gir1.2-vte-2.91 0.69.92-1 ii gir1.2-webkit2-4.0 2.36.7-1 ii libatk1.0-0 2.38.0-1 ii libc62.34-7 ii libcairo-gobject21.16.0-6 ii libcairo21.16.0-6 ii libclang1-14 1:14.0.6-2 ii libcmark0.30.2 0.30.2-5 ii libdazzle-1.0-0 3.44.0-1 ii libdevhelp-3-6 43~beta-2 ii libenchant-2-2 2.3.3-1 ii libflatpak0 1.14.0-1 ii libfontconfig1 2.13.1-4.4 ii libgirepository-1.0-11.72.0-1+b1 ii libgit2-1.3 1.3.0+dfsg.1-3 ii libgit2-glib-1.0-0 1.1.0-1 ii libgladeui-2-13 3.40.0-1 ii libglib2.0-0 2.72.3-1+b1 ii libgspell-1-21.11.1-1 ii libgtk-3-0 3.24.34-3 ii libgtksourceview-4-0 4.8.3-1 ii libhandy-1-0 1.7.90-1 ii libjson-glib-1.0-0 1.6.6-1 ii libjsonrpc-glib-1.0-13.42.0-1 ii libpango-1.0-0 1.50.9+ds-1 ii libpangocairo-1.0-0 1.50.9+ds-1 ii libpangoft2-1.0-01.50.9+ds-1 ii libpcre3 2:8.39-14 ii libpeas-1.0-01.32.0-1+b1 ii libportal-gtk3-1 0.6-2 ii libportal1 0.6-2 ii libsoup2.4-1 2.74.2-3 ii libsysprof-4 3.44.0-1 ii libsysprof-ui-4 3.44.0-1 ii libtemplate-glib-1.0-0 3.35.0-1 ii libvala-0.56-dev [libvala-dev] 0.56.2-1 ii libvte-2.91-00.69.92-1 ii libwebkit2gtk-4.0-37 2.36.7-1 ii libxml2 2.9.14+dfsg-1+b1 ii python3 3.10.6-1 ii python3-gi 3.42.2-2 Versions of packages gnome-builder recommends: ii build-essential12.9 pn flatpak-builder ii gettext0.21-8 ii meson 0.62.2-1 ii pkg-config 0.29.2-1 ii python3-lxml 4.9.1-1+b1 ii valgrind-if-available 3.18.1-1-1 Versions of packages gnome-builder suggests: pn rubocop Versions of packages flatpak depends on: ii adduser 3.128 ii bubblewrap 0.6.2-1 ii dbus [default-dbus-system-bus] 1.14.0-2 ii libappstream4 0.15.5-1 ii libarchive133.6.0-1 ii
Bug#1019127: recoll: FTBFS if systemd is in build environment
Source: recoll Version: 1.32.5-1 Severity: serious Tags: patch Hi Maintainer As can be seen on reproducible builds [1], if systemd is present in the build environment, the build fails with the following output: dh_missing: warning: lib/systemd/system/recollindex@.service exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/systemd/user/recollindex.service exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting This can be avoided by configuring recoll with --without-systemd, as per the patch below. Regards Graham [1] https://tests.reproducible-builds.org/debian/rb-pkg/recoll.html --- a/debian/rules +++ b/debian/rules @@ -21,7 +21,7 @@ dh $@ --with python3 override_dh_auto_configure: - dh_auto_configure -- --enable-recollq --enable-xadump + dh_auto_configure -- --enable-recollq --enable-xadump --without-systemd override_dh_auto_install: dh_auto_install
Bug#1017053: fenics-dolfinx: FTBFS on mips64el
Source: fenics-dolfinx Followup-For: Bug #1017053 I see. I attributed the fault to the pmix problem too quickly. >From the error logs it seems to be coming from xtl. I've just uploaded dolfinx 0.5.0. It might help since it has removed explicit xtl use.
Bug#1016084: transition: petsc
All uploads are done now. Let the binNMUs rip. Drew
Bug#1017249: rheolef: FTBFS: ../../include/rheolef/communicator.h:112:25: error: expected initializer before ‘size’
Dear Lucas, Many thanks for reporting this bug. I've just tried to reproduce it with sid (g++ 12.2.0-1) and bookwork (g++ 12.1.0-3): the package built successfully in both cases. I used pbuilder together with all the up-to-date package versions. So, please could you try to rebuild the rheolef package in Debian (I am not DM) and let me known: probably this bug in rheolef was due to another package (g++?) and could now be closed ? Many thanks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#1019126: emscripten: Emscripten provides obsolete argument to closure-compiler
Package: emscripten Version: 3.1.6~dfsg-5 Severity: normal It is well-known (or quickly becomes known) that if you pass --closure=1 to emcc, you will run up against the issue that Debian's closure-compiler was last updated in 2013. However, if you download your own copy of the jar you can use JAVA_JARPATH to get it to work with Debian's wrapper script, and that's where this bug starts. The Debian patch "1004_acorn_ecmaVersion.patch" changes the --language-in value from ECMASCRIPT_2020 to ECMASCRIPT_NEXT_IN. Unfortunately, the latter is no longer valid: It was documented as such over a year ago in https://github.com/google/closure-compiler/commit/6a8e50ea7847063689fd33417d0a7fe67276a623 , and actually removed 5 months ago in https://github.com/google/closure-compiler/commit/ee4b9d512c323026b975bec9cf5dd2bb7f908a7e The proper value to use here (if you insist on changing these values) would be ECMASCRIPT_NEXT. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (501, 'testing'), (100, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emscripten depends on: ii binaryen108-1 ii clang-141:14.0.6-2 ii lld-14 1:14.0.6-2 ii llvm-14 1:14.0.6-2 ii node-acorn 8.8.0+ds+~cs24.17.6-2 ii nodejs 18.7.0+dfsg-1 ii python3 3.10.6-1 Versions of packages emscripten recommends: ii libjs-d3 3.5.17-4 ii python3-numpy 1:1.21.5-1+b1 Versions of packages emscripten suggests: pn adb ii automake 1:1.16.5-1.3 ii closure-compiler 20130227+dfsg1-10.1 pn cmake pn emscripten-doc ii make 4.3-4.1 pn python3-ply pn scons ii wabt 1.0.29-1 -- no debconf information
Bug#1019125: update: i am having trouble with updating my mx system
Package: update Version: repository Severity: important X-Debbugs-Cc: quinacaldwell2...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? i was updating my mx system when it told me that the repository has an insecure key and download * What exactly did you do (or not do) that was effective (or ineffective)? i tried removing my old repository packages and keys and i couldnt do anything * What was the outcome of this action? vulnerable security prone to being hacked * What outcome did you expect instead? to successfuly update my sysem *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_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: sysvinit (via /sbin/init)
Bug#1019101: resampy: autopkgtest regression on s390x
Dear Paul, On Sat, 3 Sep 2022 23:08:37 +0200 Paul Gevers wrote: Source: resampy Version: 0.4.0+ds-2 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of resampy the autopkgtest of resampy fails in testing when that autopkgtest is run with the binary packages of resampy from unstable on s390x (our only big endian release archive). It passes when run with only packages from testing. In tabular form: passfail resampyfrom testing0.4.0+ds-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=resampy https://ci.debian.net/data/autopkgtest/testing/s390x/r/resampy/25657002/log.gz [...] I have this issue in my radar already. I'm waiting to get access to a s390x porterbox to be able to investigate. kind regards -- Antonio Valentino
Bug#1018102: idle detection failure
On Thu, 2022-08-25 at 13:27 -0400, Antoine Beaupre wrote: > I have xss-lock setup to start xsecurelock automatically after the > delay prescribed by my `xset` configuration. FWIW I've never seen it used with xsecurelock (I use i3lock) but I do `xset b off` in my session (but not the `s 60 3` thing you do) and autolocking does work for me as expected -- although in practice mostly lock via a key binding as I walk away, but if I forget it does lock itself. > I wonder if I'm missing a key service in my session, or how to debug > the screensaver in Xorg I'm afraid I don't know about any of this sort stuff, I just package the tool as a user. As you say `xset s activate` works I'm inclined to suggest the issue is elsewhere in the stack. But here are some random thoughts nonetheless: You pass --verbose but I assume the journald output for xss- lock.service has nothing of use? You could switch xsecurelock out for a wrapper which logs and then forwards to the real thing, at least then you would know if it was being called at all. Have you compared the process lists on the working and non-working systems, that might give a hint about a missing process/service in your session. Perhaps also look for anything which is inhibiting screenlock, e.g. a "Presentation Mode" setting? I think this is logind related functionality so perhaps there is a way to query the underlying setting via that? In the past I've seen these options having different setting for mains power vs battery, which could explain a laptop vs desktop difference. Ian.
