Bug#994187: squidguard: Squidguard cannot access DATADIR as a symlink
Hello Joachim, We distribute the configuration of Squidguard to different systems where DATADIR is not always in the same place and therefore we have solved it with a symlink. Have a nice day. Tim On 13.09.21 21:38, Joachim Wiedorn wrote: Hello Tim, Tim Herwig wrote on 2021-09-13 13:55: * The problem exists on Debian 10 and Debian 11 when Squidguard tries to access DATADIR as a symlink. I think it is untypically using a symlink for DATADIR. What is the reason? --- Have a nice day. Joachim (Germany)
Bug#993691: pytest-mpi: autopkgtest regression: Building wheel for mpi4py (PEP 517): finished with status 'error'
On 2021-09-14 03:28, Sandro Tosi wrote: Yeah, there's something right weird going on here. I can't reproduce locally. this package doesnt run tests at buildtime: https://salsa.debian.org/python-team/packages/pytest-mpi/-/blob/master/debian/rules#L22-23 introduced with commit ed09145197737e3f15cfa75df9377604925f97a2 so maybe there's something problematic with this package? I've also recently updated pytest, and that's how i noticed the failure, but it looks like it's unrelated to that. Is re-enabling tests at building be a good idea? We actually can't run tests at build-time, something to do with pytest not being able to use the plugins from the local build dir. At least that's how it was when I tried it, I couldn't get them to run successfully, that's why I left testing in the hands of debci. Note that I do run the tests locally. autopkgtest is passing fine on my own system, including the py39-mpi-oldpt test. It's not attempting to rebuild mpi4py wheels. Can take a closer look at ed09145. Patches (and team uploads) welcome if you find the fix. Drew
Bug#994202: neutron: CVE-2021-40797: Routes middleware memory leak for nonexistent controllers
On 9/13/21 7:31 PM, Salvatore Bonaccorso wrote: > Source: neutron > Version: 2:18.1.0-3 > Severity: important > Tags: security upstream > Forwarded: https://bugs.launchpad.net/neutron/+bug/1942179 > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for neutron. > > CVE-2021-40797[0]: > | An issue was discovered in the routes middleware in OpenStack Neutron > | before 16.4.1, 17.x before 17.2.1, and 18.x before 18.1.1. By making > | API requests involving nonexistent controllers, an authenticated user > | may cause the API worker to consume increasing amounts of memory, > | resulting in API performance degradation or denial of service. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2021-40797 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40797 > [1] https://bugs.launchpad.net/neutron/+bug/1942179 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore > Hi Salvatore, According to the launchpad bug, it feels like the issue is when using Eventlet as web server (ie: the integrated Python web server), but in Debian, the Neutron API is served over uwsgi. In such case, the API process just dies after it serves a query, if I'm not mistaking. Therefore, I don't think Debian would be affected. This is to be confirmed, as I asked in the #openstack-neutron IRC channel (also on OFTC), and I'm still waiting for a reply. Cheers, Thomas Goirand (zigo)
Bug#994160: libmojolicious-plugin-assetpack-perl: newer upstream version (2.13) available
gregor herrmann writes: > On Mon, 13 Sep 2021 01:38:26 +0200, Philip Hands wrote: > >> and here: >> https://github.com/mojolicious/mojo-assetpack/commits/main >> mantenance has now resumed under the aegis of the mojolicious team. > > 2.13-1 is already in Git but has a note in d/changelog: > > WAITS-FOR: libmojolicious-perl 9.0 > > so it's "just" waiting for someone to update Mojolicious to a new > major release. Ah, fair enough. Sorry for the noise then. (I should have thought of looking for that ... I will do in future). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#994225: New upstream version 1.2.0
Package: src:libgit2 Version: 1.1.0+dfsg.1-4 Severity: wishlist Hi maintainers, Please update to libgit2 version 1.2.0, juste released. There is a soname change, and also some struct changes[1]. Going thru experimental is probably needed. [1]: https://github.com/libgit2/libgit2/pull/6051#issuecomment-918337543 Regards -- Mathieu Parent
Bug#994226: tango-starter has an unmet service dependency from some other service
Package: tango-starter Version: 9.3.4+48.93a21d-2~bpo10+1+salsaci Severity: normal Dear Maintainer, tango-starter has an unmet service dependency from some other service (possibly the network), which makes it start incorrectly. Since the classic init scripts are translated automatically by systemd into systemd units, and according to their documentation, the "network" service is no longer honored as a target dependency, see here for all the details: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ So, following their suggestion the $nework-online dependency have to be added in the init script -- System Information: Debian Release: 10.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tango-starter depends on: ii libc6 2.28-10 ii libcos4-2 4.2.2-0.9+b1 ii libgcc1 1:8.3.0-6 ii libomniorb4-2 4.2.2-0.9+b1 ii libomnithread4 4.2.2-0.9+b1 ii libstdc++6 8.3.0-6 ii libtango-tools 9.3.4+48.93a21d-2~bpo10+1+salsaci ii libtango9 9.3.4+48.93a21d-2~bpo10+1+salsaci ii libzmq5 4.3.1-4+deb10u2 ii lsb-base 10.2019051400 tango-starter recommends no packages. Versions of packages tango-starter suggests: pn omninotify -- no debconf information
Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
On Mon, 13 Sep 2021 at 22:59:32 +0200, Aurelien Jarno wrote: > - running the operation on a non-existing user, but as loginctl does a > check that the user exists, it has to be done directly with the dbus > API, for instance "gdbus call --system --dest org.freedesktop.login1 > --object-path /org/freedesktop/login1 --method > org.freedesktop.login1.Manager.SetUserLinger 12345678 true true" > > The latest is more a bit more complex to do (especially that > libglib2.0-bin is not necessarily installed on the system), but has the > advantage of exercising all configured NSS modules. systemd happens to have its own D-Bus implementation sd-bus (a competitor to libdbus and GLib's GDBus) for which it provides busctl(1), an equivalent of gdbus(1) and dbus-send(1). So this could be written as: busctl call --system org.freedesktop.login1 /org/freedesktop/login1 \ org.freedesktop.login1.Manager SetUserLinger ubb $uid true true which does not have dependencies outside systemd.deb. The nonexistent uid should probably be in one of the ranges reserved by Policy §9.2.2: perhaps 4294967294 or (uint32_t) -2, which is reserved as a representation of the anonymous NFS user? smcv
Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)
On Sun, 12 Sep 2021 at 20:17:36 +0100, Simon McVittie wrote: > According to > https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html > it might be necessary to remove > gnome-shell-extension-easyscreencast_1.1.0+git20210116.3252312-1 from > testing if #993061 cannot be fixed soon. The other packages with an upper > limit have already been uploaded to unstable and will hopefully transition > reasonably smoothly. Looking at the migration excuses for gnome-shell, I think we will need something more like this: remove gnome-shell-extension-dashtodock/69-1 remove gnome-shell-extension-desktop-icons/20.04.0+git20200908-8 remove gnome-shell-extension-easyscreencast/1.1.0+git20210116.3252312-1 I'm not sure why the first two would block migration since they don't have an upper limit on their version numbers, but those extensions haven't been ported to gnome-shell 40, so they aren't going to work in practice anyway. Unfortunately this transition has got caught behind glibc, so will likely take a while to migrate. This seems to be a bug in glibc's mipsel symbols file (I'll open a bug for that). smcv
Bug#994229: deepin-qt5dxcb-plugin FTCBFS: uses the build architecture pkg-config
Source: deepin-qt5dxcb-plugin Version: 5.0.17-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs deepin-qt5dxcb-plugin fails to cross build from source, because an upstream .pri file hard codes the build architecture pkg-config, which happens to fail to find cairo. Please consider applying the attached patch to fix that. Helmut --- deepin-qt5dxcb-plugin-5.0.17.orig/xcb/linux.pri +++ deepin-qt5dxcb-plugin-5.0.17/xcb/linux.pri @@ -7,7 +7,8 @@ xcb-damage mtdev egl # Don't link cairo library -QMAKE_CXXFLAGS += $$system(pkg-config --cflags-only-I cairo) +PKG_CONFIG_EXECUTABLE = $$pkgConfigExecutable() +QMAKE_CXXFLAGS += $$system($$PKG_CONFIG_EXECUTABLE --cflags-only-I cairo) greaterThan(QT_MINOR_VERSION, 5): PKGCONFIG += xcb-xinerama
Bug#994230: Krusader Version 2.7.2 is showing no details for file transfer anymore
Package: krusader X-Debbugs-Cc: deb...@decotrain.de Version: 2:2.7.2-2 Severity: minor Hello maintainer, this question has already been asked in a Debian forum without any answer. Since Debian 11 (Bullseye) the Krusader version 2.7.2 "Peace of Mind", as well as a new service for notifications in KDE is standard. There is no option for file operations in the notifications and the Krusader does not appear among the applications there either. In Krusader itself there is no option to reactivate the old copy window. This means that important details such as the current transfer speed and remaining copy time are omitted. There is only a basic progress indicator with not details what is happening. How the old copy window can be reactivated or additional informations be shown? Thanks and best regards karsten -- System Information: Debian Release: 11.0 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 krusader depends on: ii kinit 5.78.0-2 ii kio 5.78.0-5 ii libacl1 2.2.53-10 ii libc6 2.31-13 ii libkf5archive5 5.78.0-2 ii libkf5bookmarks5 5.78.0-2 ii libkf5codecs5 5.78.0-2 ii libkf5completion5 5.78.0-3 ii libkf5configcore5 5.78.0-4 ii libkf5configgui5 5.78.0-4 ii libkf5configwidgets5 5.78.0-2 ii libkf5coreaddons5 5.78.0-4 ii libkf5guiaddons5 5.78.0-3 ii libkf5i18n5 5.78.0-2 ii libkf5iconthemes5 5.78.0-2 ii libkf5itemviews5 5.78.0-2 ii libkf5jobwidgets5 5.78.0-2 ii libkf5kiocore5 5.78.0-5 ii libkf5kiofilewidgets5 5.78.0-5 ii libkf5kiowidgets5 5.78.0-5 ii libkf5notifications5 5.78.0-2 ii libkf5parts5 5.78.0-3 ii libkf5service-bin 5.78.0-2 ii libkf5service5 5.78.0-2 ii libkf5solid5 5.78.0-2 ii libkf5textwidgets5 5.78.0-2 ii libkf5wallet-bin 5.78.0-2 ii libkf5wallet5 5.78.0-2 ii libkf5widgetsaddons5 5.78.0-2 ii libkf5windowsystem5 5.78.0-2 ii libkf5xmlgui5 5.78.0-2 ii libkf5xmlgui5 5.78.0-2 ii libqt5core5a 5.15.2+dfsg-9 ii libqt5dbus5 5.15.2+dfsg-9 ii libqt5gui5 5.15.2+dfsg-9 ii libqt5printsupport5 5.15.2+dfsg-9 ii libqt5widgets5 5.15.2+dfsg-9 ii libqt5xml5 5.15.2+dfsg-9 ii libstdc++6 10.2.1-6 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages krusader recommends: ii kde-cli-tools 4:5.20.5-2 ii keditbookmarks 20.12.0-2 ii kio-extras 4:20.12.2-1 Versions of packages krusader suggests: ii arj 3.10.22-24 ii ark 4:20.12.2-1 ii bzip2 1.0.8-4 ii cpio 2.13+dfsg-4 ii hashdeep [md5deep] 4.4-7 ii kate 4:20.12.2-1 ii kdiff3 1.8.5-1 ii kmail 4:20.08.3-1 ii konsole 4:20.12.3-1 pn krename ii lhasa [lha] 0.3.1-3 ii md5deep 4.4-5 ii okteta 5:0.26.5-2 ii p7zip 16.02+dfsg-8 ii rar 2:5.5.0-1 pn rpm pn unace ii unrar 1:6.0.3-1 ii unzip 6.0-26 ii zip 3.0-12
Bug#994231: ITP: kiwi -- Flexible OS Image and Appliance Builder
Package: wnpp Severity: wishlist Owner: John Paul Adrian Glaubitz X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: kiwi Version : 9.23.56 Upstream Author : Marcus Schäfer , and others * URL : https://osinside.github.io/kiwi * License : GPL-3 Programming Lang: Python Description : Flexible OS Image and Appliance Builder The KIWI Image System provides an operating system image builder for Linux supported hardware platforms as well as for virtualization and cloud systems. This package will be co-maintained by Marcus Schäfer. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#994223: lintian-brush crashes with multiple sources
reassign 994223 breezy
severity 994223 normal
fixed 994223 3.2.0+bzr7543-1
thanks
On Tue, Sep 14, 2021 at 08:23:05AM +0200, Yadd wrote:
> when launching lintian-brush on a multiple-sources packages, it crashes:
>
> Traceback (most recent call last):
> File "/usr/bin/lintian-brush", line 33, in
> sys.exit(load_entry_point('lintian-brush==0.111', 'console_scripts',
> 'lintian-brush')())
> File "/usr/lib/python3/dist-packages/lintian_brush/__main__.py", line 328,
> in main
> overall_result = run_lintian_fixers(
> File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 1165,
> in run_lintian_fixers
> check_clean_tree(local_tree, basis_tree, subpath)
> File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 778,
> in check_clean_tree
> changes = local_tree.iter_changes(
> File "/usr/lib/python3/dist-packages/breezy/tree.py", line 269, in
> iter_changes
> return intertree.iter_changes(include_unchanged, specific_files, pb,
> File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 971, in
> iter_changes
> changes, target_extras = self._iter_git_changes(
> File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 1622, in
> _iter_git_changes
> return changes_between_git_tree_and_working_copy(
> File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 1643, in
> changes_between_git_tree_and_working_copy
> for path, index_entry in target._recurse_index_entries():
> File "/usr/lib/python3/dist-packages/breezy/git/tree.py", line 1266, in
> _recurse_index_entries
> (ctime, mtime, dev, ino, mode, uid, gid, size, sha,
> ValueError: too many values to unpack (expected 10)
>
> You can try for example with node-ws.
> Versions of packages lintian-brush depends on:
> ii devscripts 2.21.4
> ii python3 3.9.2-3
> ii python3-breezy 3.1.0-8
> ii python3-debian 0.1.39
> ii python3-debmutate0.38
> ii python3-distro-info 1.0
> ii python3-dulwich 0.20.23-1
This is an incompatibility between breezy and dulwich. It should be
resolvable by either downgrading dulwich or upgrading breezy.
Cheers,
Jelmer
signature.asc
Description: PGP signature
Bug#994232: libc6: generates unnecessarily tight dependencies on mips, mipsel
Package: libc6 Version: 2.32-2 Severity: normal Tags: patch X-Debbugs-Cc: debian-rele...@lists.debian.org Most architectures' libc6.symbols.$arch have this pattern: > $ cat debian/libc6.symbols.i386 > #include "libc6.symbols.common" > ld-linux.so.2 #PACKAGE# #MINVER# > #include "symbols.wildcards" > libc.so.6 #PACKAGE# #MINVER# > #include "symbols.wildcards" This results in any use of symbols versioned foo@GLIBC_2.23 generating a dependency on libc6 (>= 2.23), and so on. However, libc6:mips and libc6:mipsel are missing the final '#include "symbols.wildcards"', which results in those architectures generating an unnecessarily strict dependency on libc6 (>= 2.32-1) and entangling other transitions with glibc's transition. As far as I can see, this was accidental? libc6-i386:x32 has the same issue. Please consider the attached patch. smcv >From bffb450291513a1486dae6e04b1d126994ba22fe Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 14 Sep 2021 09:25:36 +0100 Subject: [PATCH] Restore versioned symbol tracking for mips, mipsel, libc6-i386:x32 Commit d3f9fade "debian/libc6.symbols.mips, debian/libc6.symbols.mipsel: drop symbol overrides for TLS support" accidentally removed the inclusion of symbols.wildcards, resulting in all symbols in libc.so.6 on the affected architectures generating an unnecessarily tight dependency on libc6 (>= 2.32-1). Commit 5f5dfcb0 caused an equivalent issue for libc6-i386:x32. Fixes: d3f9fade "debian/libc6.symbols.mips, debian/libc6.symbols.mipsel: drop symbol overrides for TLS support." Fixes: 5f5dfcb0 "debian/libc6-i386.symbols.x32, debian/libc6.symbols.i386: drop symbol overrides for TLS support. --- debian/libc6-i386.symbols.x32 | 1 + debian/libc6.symbols.mips | 1 + debian/libc6.symbols.mipsel | 1 + 3 files changed, 3 insertions(+) diff --git a/debian/libc6-i386.symbols.x32 b/debian/libc6-i386.symbols.x32 index 3bd6f8f5..357d2f26 100644 --- a/debian/libc6-i386.symbols.x32 +++ b/debian/libc6-i386.symbols.x32 @@ -2,3 +2,4 @@ ld-linux.so.2 #PACKAGE# #MINVER# #include "symbols.wildcards" libc.so.6 #PACKAGE# #MINVER# +#include "symbols.wildcards" diff --git a/debian/libc6.symbols.mips b/debian/libc6.symbols.mips index 580f72c8..59332301 100644 --- a/debian/libc6.symbols.mips +++ b/debian/libc6.symbols.mips @@ -2,3 +2,4 @@ ld.so.1 #PACKAGE# #MINVER# #include "symbols.wildcards" libc.so.6 #PACKAGE# #MINVER# +#include "symbols.wildcards" diff --git a/debian/libc6.symbols.mipsel b/debian/libc6.symbols.mipsel index 580f72c8..59332301 100644 --- a/debian/libc6.symbols.mipsel +++ b/debian/libc6.symbols.mipsel @@ -2,3 +2,4 @@ ld.so.1 #PACKAGE# #MINVER# #include "symbols.wildcards" libc.so.6 #PACKAGE# #MINVER# +#include "symbols.wildcards" -- 2.33.0
Bug#994233: libc6: breaks python3-iptables (<< 1.0.0-2~)
Package: libc6 Version: 2.32-2 Severity: normal libc6 (>= 2.32) appears to have triggered a regression in python3-iptables, fixed in python3-iptables (= 1.0.0-2). Please consider adding a versioned Breaks to prevent broken partial upgrades. smcv
Bug#994231: ITP: kiwi -- Flexible OS Image and Appliance Builder
Hi, Quoting John Paul Adrian Glaubitz (2021-09-14 10:23:50) > The KIWI Image System provides an operating system image builder for Linux > supported hardware platforms as well as for virtualization and cloud systems. please consider adding the package into https://wiki.debian.org/SystemBuildTools Thanks! cheers, josch signature.asc Description: signature
Bug#993338: octave: Setting up octave fails due to missing libGL.so.1
Control: reassign -1 dpkg 1.20.9 Dear Witold, Le dimanche 12 septembre 2021 à 15:24 +, Witold Baryluk a écrit : > Package: octave > Version: 6.2.0-1 > Followup-For: Bug #993338 > X-Debbugs-Cc: witold.bary...@gmail.com > > After a lof of trial and error and minimizing my package list from ~7000 > to just few, I got it easily reproducible using live-build. It is somehow > related to multiarch. > > Here and attached below is a script that should reproduce the issue. It > uses /tmp-live-build as a scratch space, so be sure to clean it after. > (I cannot use /tmp as it often has nodev / nosuid set). > > I am also attaching compressed output log from the script and live-build, > as well the apt / dpkg logs from inside the target chroot. Thanks for sending a way of reproducing the problem. I have no idea what’s going on. But it seems clear to me that the bug is not in octave. I’m reassign to dpkg, for lack of a better idea, in the hope that its maintainer can give some guidance. Best regards, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#983160: dput-ng: --override doesn't override profile parameters
On Sat, 20 Feb 2021 wrote: Package: dput-ng Version: 1.32 It seems the `--override` option in dput-ng doesn't really override parameters in profiles. Hi, this is just to confirm this issue. I had a look at the dput-ng commit history and I'm failing to see how this was supposed to work even when --override was first implemented [1]. [1] https://salsa.debian.org/debian/dput-ng/-/commit/a283c444ec73780962c3a1e783d5b957999b1f96
Bug#994214: nomad FTBFS in unstable
On Tuesday, 14 September 2021 5:20:03 AM AEST Steve Langasek wrote: > The nomad package fails to build from source in Ubuntu, so in the process > of investigating this build failure I confirmed that it also fails to > build in Debian unstable: Thanks for reporting but most certainly I won't be able to help... The package is up for adoption (RFA) and I'll probably orphan it soon. -- All the best, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- The greatest mistake is to imagine that the human being is an autonomous individual. The secret freedom which you can supposedly enjoy under a despotic government is nonsense, because your thoughts are never entirely your own. Philosophers, writers, artists, even scientists, not only need encouragement and an audience, they need constant stimulation from other people. It is almost impossible to think without talking. ... Take away freedom of speech, and the creative faculties dry up. -- George Orwell --- "A closer look at U.S. deaths due to COVID-19" 2020-11-26, The Johns Hopkins News-Letter -- https://notthebee.com/article/a-few-days-ago-johns-hopkins-published-a-study-saying-corona-is-nbd-they-then-deleted-it-read-it-here-in-its-entirety -- https://web.archive.org/web/20201126223119/https://www.jhunewsletter.com/article/2020/11/a-closer-look-at-u-s-deaths-due-to-covid-19 signature.asc Description: This is a digitally signed message part.
Bug#994234: installation-reports: Would be nice if debbootstrap could recognize a link is already ok instead of failing
Package: installation-reports Severity: wishlist Tags: d-i Boot method: network Image version: https://deb.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/netboot.tar.gz 20210731 Date: Machine: Fujitsu Esprimo Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Didn't want to wipe my root partition, so simply moved away all system directories on the root file system. debbootstrap then stumbles across the links in /, as it tries to create them unconditionally. The wish is here, that debbootstrap recongises the links are there instead of failing. Deleting the links and running the debbootstrap installer step again worked well. As a remark, an EFI shim for grub is installed - is that a necessary step? Thanks for a great distribution! -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux seba 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 (2021-07-28) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers [8086:3ec2] (rev 07) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:124a] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 630 (Desktop) [8086:3e92] lspci -knn: DeviceName: Onboard - Video lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:124a] lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Lake PCH Thermal Controller [8086:a379] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Cannon Lake PCH HECI Controller [8086:a360] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake PCH SATA AHCI Controller [8086:a352] (rev 10) lspci -knn: DeviceName: Onboard - SATA lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:1b.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #21 [8086:a32c] (rev f0) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Q370 Chipset LPC/eSPI Controller [8086:a306] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS [8086:a348] (rev 10) lspci -knn: DeviceName: Onboard - Sound lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1247] lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Cannon Lake PCH SMBus Controller [8086:a323] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller [8086:a324] (rev 10) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1246] lspci -knn: 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (7) I219-LM [8086:15bb] (rev 10) lspci -knn: DeviceName: Onboard - Ethernet lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:1248] lspci -knn: Kernel driver in use: e1000e lspci -knn: Kerne
Bug#994133: libc-bin: [iconv] [fr] [manpage] Missing word in the French manpage of iconv
Hi, On Sun, 12 Sep 2021 20:25:25 +0200 Aurelien Jarno wrote: > control: reassign -1 manpages-fr > control: retitle -1 manpages-fr: [iconv] [fr] [manpage] Missing word in the > French manpage of iconv > > Hi, > > On 2021-09-12 15:36, Nicolas Patrois wrote: > > Package: libc-bin > > Version: 2.32-2 > > Severity: minor > > Tags: l10n > > > > Dear Maintainer, > > > > In the French manpage, the word "forme" is missing in its end. > > > > Les arguments obligatoires ou optionnels pour les options de forme longue > > le sont aussi pour les options de courte. > > > > Just before "courte". > > The French manpage if iconv is not provided by libc-bin, but by > manpages-fr. I am therefore reassigning the bug to the right package. > > Regards, > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net I look for the string throughout the files in French manpages (and especially in the iconv*.po pages), and I don't encountered the string with the word "forme" missing. Can you give more context informations to help finding the file to be fixed. Regards Jean-Pierre Giraud OpenPGP_signature Description: OpenPGP digital signature
Bug#994133: Re : Bug#994133: libc-bin: [iconv] [fr] [manpage] Missing word in the French manpage of iconv
Le 14/09/2021 11:49:51, Jean-Pierre Giraud a écrit : > I look for the string throughout the files in French manpages (and > especially in the iconv*.po pages), and I don't encountered the string > with the word "forme" missing. Can you give more context informations > to help finding the file to be fixed. Hi, It’s in the output of iconv --help. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Bug#971590: rt-tests: bump to a new upstream release
Hellp Punit, On 9/14/21 4:36 AM, Punit Agrawal wrote: Uwe Kleine-König writes: On 9/7/21 4:35 AM, Punit Agrawal wrote: I was looking to update the rt-tests package in Debian as it is lagging behind upstream. Before digging into the task, I wanted to check if you're planning to make any changes or had any patches that haven't been pushed. Pointers to any particular issues to watch out for would also be appreciated. There is nothing pending on my side and if you want to adopt rt-tests that is fine for me. ISTR that Anders Roxell showed some interest in maintaining rt-tests, too, in the past, but I cannot find the corresponding conversation. Thanks. For now I have added myself as an uploader. I am happy to work with Anders (or anybody else interested in the rt-tests package) when / if they reach out. Feel free to drop me from Uploaders. Thanks for taking over maintainace. Best regards Uwe OpenPGP_signature Description: OpenPGP digital signature
Bug#994224: please add pipewire-pulse as option
> please add pulseaudio | pipewire-pulse as other option to plasma-pa > dependencies. Good idea, thanks for reminding me, I am not using pulseaudio myself since quite some time! Added to the plasma 5.22 branch that hopefully will be uploaded sooner or later. Best Norbert -- PREINING Norbert https://www.preining.info Fujitsu Research + IFMGA Guide + TU Wien + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#994235: bind9-dnsutils: Exiting the nslookup tool with ^C causes termainl echo to disappear until reset command is run
Package: bind9-dnsutils Version: 1:9.16.15-1 Severity: normal Dear Maintainer, After upgrading from Debian 10 to 11, the nslookup command misbehaves if it is exited with ^C rather than using the exit command, causing local echo to appear to be switched off. Running /usr/bin/reset restores the terminal. i.e. $ nslookup > www.debian.org Server: ::1 Address:::1#53 Non-authoritative answer: Name: www.debian.org Address: 103.84.224.41 ^C ~$ $ (Now No terminal echo) This behaviour is consistent after testing Using the Linux VT console and various terminal emulators. Expected behaviour is for the terminal to operate correctly if nslookup is exited with ^C as it does after the exit command is issued, as in previous releases. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9-dnsutils depends on: ii bind9-host [host] 1:9.16.15-1 ii bind9-libs 1:9.16.15-1 ii host 1:9.10.3.dfsg.P4-12.3+deb9u5 ii libc6 2.31-13 ii libedit2 3.1-20191231-2+b1 ii libidn2-0 2.3.0-5 ii libkrb5-3 1.18.3-6 ii libprotobuf-c1 1.3.3-1+b2 bind9-dnsutils recommends no packages. bind9-dnsutils suggests no packages. -- no debconf information
Bug#994236: wmctrl: warning message from window manager
Package: wmctrl Version: 1.07-7+b1 Severity: normal X-Debbugs-Cc: none, Francesco Potortì File: /usr/bin/wmctrl After remotely closing some windows with DISPLAY=:0 wmctrl -ic 0x058001b2 I looked into ~/.xsession-errors and discovered these messages: Window manager warning: Receiving a NET_CLOSE_WINDOW message for 0x58001b2 (Indoor pos) without a timestamp! This means some buggy (outdated) application is on the loose! Window manager warning: Tried to ping a window with CurrentTime! Not allowed. I use Mate with Marco on Lightdm, all updated to current testing distribution -- Francesco Potortì (ricercatore)Voice: +39.050.621.3058 ISTI - Area della ricerca CNR Mobile: +39.348.8283.107 via G. Moruzzi 1, I-56124 Pisa Skype: wnlabisti (gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (101, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 wmctrl depends on: ii libc6 2.31-17 ii libglib2.0-0 2.68.4-1 ii libx11-6 2:1.7.2-1 ii libxmu6 2:1.1.2-2+b3 wmctrl recommends no packages. wmctrl suggests no packages. -- no debconf information
Bug#841355: RFP: zammad -- web-based user support/ticketing solution
Hello Looking at https://docs.zammad.org/en/latest/install/source.html It doesn't look like the simple leaf package of software to package. Has anyone tried to package this yet?
Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts
Hi, On Tue, 14 Sep 2021 at 03:39:29 +0200, Christoph Anton Mitterer wrote: > AFAIK, keyscripts are always loaded from /lib/cryptsetup/scripts/, right? > > Likey the check= option, keyscript= should either support to specify a full > path and/or cryptsetup should support alternative location(s). IIRC it works like check= where absolute paths are used as is while relative arguments are taken from /lib/cryptsetup/scripts/ . It ought to be documented though. -- Guilhem. signature.asc Description: PGP signature
Bug#994133: libc-bin: [iconv] [fr] Missing word in the French output of iconv
control: reassign -1 libc-bin control: retitle -1 libc-bin: [iconv] [fr] Missing word in the French output of iconv --help control: tags -1 upstream Hi all, >It’s in the output of iconv --help. So it's not in the manpage, but in the po/fr.po file of the iconv source : https://sources.debian.org/src/glibc/2.32-2/po/fr.po/#L42 introduced in upstream by: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0ffaa7be6ea3649f883248f41a2bea5065383976#patch11 Sorry for the ping-pong and thank you all for the translation work! Baptiste pgpFbulrUofsc.pgp Description: Signature digitale OpenPGP
Bug#994237: fix ftbfs with GCC 11
Package: src:criterion Version: 2.3.3git1-1 Severity: important Tags: sid bookworm patch User: debian-...@lists.debian.org Usertags: ftbfs-gcc-11 criterion ftbfs with GCC 11, patch at http://launchpadlibrarian.net/558337737/criterion_2.3.3git1-1build2.1_2.3.3git1-1ubuntu1.diff.gz
Bug#994238: libvirt-clients: virsh save unexpectedly failed
Package: libvirt-clients Version: 7.6.0-1 Severity: normal Dear Maintainer, I try to save my virtual machine and it failed $ virsh save win10-2 /srv/images/gnome-boxes/images/win10-2.save --verbose Save: [ 92 %]error: Failed to save domain 'win10-2' to /srv/images/gnome-boxes/images/win10-2.save error: operation failed: domain save job: unexpectedly failed Also machines which are not running in background failed to suspend -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 'stable'), (500, 'stable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 5.14.0-trunk-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_DIE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-clients depends on: ii libc6 2.33-0experimental0 ii libgcc-s1 11.2.0-5 ii libglib2.0-02.68.4-1 ii libreadline88.1-2 ii libvirt07.6.0-1 ii libxml2 2.9.12+dfsg-4 ii sensible-utils 0.0.17 libvirt-clients recommends no packages. Versions of packages libvirt-clients suggests: ii libvirt-daemon 7.6.0-1 ii libvirt-login-shell 7.6.0-1 -- no debconf information
Bug#994239: work around ftbfs with GCC 11
Package: src:micropython Version: 1.17+ds-1 Severity: important Tags: sid bookworm User: debian-...@lists.debian.org Usertags: ftbfs-gcc-11 proposed workaround: --- micropython-1.14+ds/debian/rules2021-02-16 09:52:54.0 + +++ micropython-1.17+ds/debian/rules2021-09-14 11:02:24.0 + @@ -3,8 +3,8 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-format -export DEB_CFLAGS_MAINT_APPEND = -Wformat -Werror=format-security -export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed +export DEB_CFLAGS_MAINT_APPEND = -Wformat -Werror=format-security -Wno-error=maybe-uninitialized +export DEB_LDFLAGS_MAINT_APPEND = export BUILD_VERBOSE = 1
Bug#994240: fix ftbfs with GCC 11
Package: src:yosys Version: 0.9-2 Severity: important Tags: sid bookworm patch User: debian-...@lists.debian.org Usertags: ftbfs-gcc-11 patch at http://launchpadlibrarian.net/558340384/yosys_0.9-1build4.1_0.9-1ubuntu1.diff.gz
Bug#992215: rsync: please consider re-adding --copy-devices patch
Hi Samuel, On Sun, 2021-09-12 at 17:52 +0100, Samuel Henrique wrote: > Thanks for the detailed bugreport, > > I agree with it and have just uploaded the fix to unstable. I'm gonna > try to get this into bullseye before the 11.1 release, and > bullseye-backports shall get the fix after it reaches testing. That's great! Thanks for all of your work to re-add the patch and to apply it to bullseye. I really appreciate it! Thanks again, Kevin
Bug#945139: pipenv: update from 11.9 to an usable version
Hi, pipenv 11.9 dates back to Mar 21, 2018 (https://pypi.org/project/pipenv/#history) and this causes a lot of troubles with modern software. For example: https://github.com/SigmaHQ/pySigma/issues/15 Please, upgrade to an usable version. Thanks in advance.
Bug#989092: r-cran-kableextra_1.3.4+dfsg-1_amd64.changes REJECTED
Hi Thorsten, On Fri, Sep 10, 2021 at 12:00:09PM +, Thorsten Alteholz wrote: > at least the bootstrapTable files should be also mentioned in your > debian/coypright. I've re-uploaded with --- a/debian/copyright +++ b/debian/copyright @@ -21,6 +21,14 @@ Copyright: 2016-2021 Hao Zhu, Bill Evans License: MIT +Files: inst/bootstrapTable* +Copyright: 2011-2019 Twitter, Inc. +License: MIT + +Files: inst/lightable* +Copyright: 2020 Hao Zhu +License: MIT + Files: debian/* Copyright: 2021 Andreas Tille License: MIT -- http://fam-tille.de
Bug#994231: ITP: kiwi -- Flexible OS Image and Appliance Builder
Hi Johannes! On 9/14/21 10:58, Johannes Schauer Marin Rodrigues wrote: > Quoting John Paul Adrian Glaubitz (2021-09-14 10:23:50) >> The KIWI Image System provides an operating system image builder for Linux >> supported hardware platforms as well as for virtualization and cloud systems. > > please consider adding the package into > https://wiki.debian.org/SystemBuildTools Sure, will do. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#994170: lintian crashes for some source package
O n Mon, Sep 13, 2021 at 02:47:10PM -0700, Felix Lechner wrote:
> Version: 2.106.0
>
> Hi,
>
> On Mon, Sep 13, 2021 at 1:15 AM Bill Allombert wrote:
> >
> > https://people.debian.org/~ballombe/lintian
>
> Thank you for making the sources available. Lintian's development
> version no longer crashes with them. Instead, it produces the
> following hints:
>
> $ ../../git/bin/lintian gap-gapdoc_1.6.4-1.dsc
Well thanks to have send me that!
> > $ lintian gap-gapdoc_1.6.4-1.dsc
>
> I believe you encountered Bug#994088 ("dsc files from cwd are not
> processed correctly"). From the command you listed above—thank you for
> the attention to detail—you probably ran Lintian on a dsc in your
> current working directory.
I do not know, I also tried
lintian ./gap-gapdoc_1.6.4-1.dsc
and
lintian `pwd`/gap-gapdoc_1.6.4-1.dsc
and it also failed, but I expect you also fixed this bug, since it works
for you:
$ lintian ./gap-gapdoc_1.6.4-1.dsc
remove_tree failed for
/tmp/lintian-pool-wqlv9KrxpL/gap-gapdoc/gap-gapdoc_1.6.4-1_source:
cannot
remove directory: Directory not empty at /usr/share/perl5/Path/Tiny.pm
line 1732.
Path::Tiny::remove_tree(Path::Tiny=ARRAY(0x55de695a53b0)) called
at /usr/share/lintian/bin/../lib/Lintian/Processable.pm line 234
Lintian::Processable::remove(Lintian::Processable::Source=HASH(0x55de68bdaf18))
called at /usr/share/lintian/bin/../lib/Lintian/Group.pm line 463
Lintian::Group::clean_lab(Lintian::Group=HASH(0x55de67e3ed78),
Lintian::Output::EWI=HASH(0x55de67d2e818)) called at
/usr/share/lintian/bin/../lib/Lintian/Group.pm line 440
Lintian::Group::process(Lintian::Group=HASH(0x55de67e3ed78),
HASH(0x55de68c3d310), HASH(0x55de68efad38),
Lintian::Output::EWI=HASH(0x55de67d2e818)) called at
/usr/share/lintian/bin/../lib/Lintian/Pool.pm line 162
Cheers,
Bill.
Bug#992557: r-cran-gstat_2.0-7-1_amd64.changes REJECTED
Hi Thorsten, On Fri, Sep 10, 2021 at 01:00:08PM +, Thorsten Alteholz wrote: > please also mention at least Stanford Center for Reservoir Forecasting in > your debian/copyright. Done, Thanks for thorough checking Andreas. -- http://fam-tille.de
Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts
On Tue, 2021-09-14 at 12:50 +0200, Guilhem Moulin wrote: > It ought > to be documented though. Tell me when it helps you if I provide a patch for the manpage. Cheers, Chris.
Bug#993737: r-cran-clusterr_1.2.5-1_amd64.changes REJECTED
Hi Andreas, this does not look like compatible with DFSG: ClusterR/inst/include/affinity_propagation.h: * Copyright 2007, BJ Frey and Delbert Dueck. This software may be freely used and distributed for non-commercial purposes. Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ R-pkg-team mailing list r-pkg-t...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
Bug#994219: cryptsetup: support and/or document alternative location(s) for keyscripts
On Tue, 14 Sep 2021 at 15:06:22 +0200, Christoph Anton Mitterer wrote: > On Tue, 2021-09-14 at 12:50 +0200, Guilhem Moulin wrote: >> It ought to be documented though. > > Tell me when it helps you if I provide a patch for the manpage. That would have been welcome but I tweaked the text already. Next time :-) Thanks! -- Guilhem. signature.asc Description: PGP signature
Bug#994170: lintian crashes for some source package
Hi, On Tue, Sep 14, 2021 at 5:44 AM Bill Allombert wrote: > > I do not know, I also tried Do you still see the bug? Here is the fix: https://salsa.debian.org/lintian/lintian/-/commit/3fc81b4576fac2b911a59660d19fa1567b90139f Kind regards Felix Lechner
Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)
On Tue, Sep 14, 2021 at 09:12:34AM +0100, Simon McVittie wrote: >... > Looking at the migration excuses for gnome-shell, I think we will need > something more like this: > > remove gnome-shell-extension-dashtodock/69-1 > remove gnome-shell-extension-desktop-icons/20.04.0+git20200908-8 > remove gnome-shell-extension-easyscreencast/1.1.0+git20210116.3252312-1 > > I'm not sure why the first two would block migration since they don't have > an upper limit on their version numbers, but those extensions haven't been > ported to gnome-shell 40, so they aren't going to work in practice anyway. >... Package: gnome-shell Version: 40.4-2 Breaks: ..., gnome-shell-extension-dashtodock (<< 70), gnome-shell-extension-desktop-icons (<< 21.04), ... > smcv cu Adrian
Bug#994241: ruby-lapack autopkgtest needs to be adapted for LAPACK 3.10
Package: ruby-lapack
Version: 1.8.1-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update
Dear Maintainer,
Since the upload of lapack 3.10.0-1, the autopkgtest of ruby-lapack
fails in unstable. See for example:
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-lapack/15155031/log.gz
More precisely, the tests about generalized singular value
decomposition (GSVD) fail.
Mathematically, the GSVD does not have a unique solution. For some
reason, lapack 3.10 now returns a different (still valid) solution, but
the ruby-lapack testsuite hardcodes another, specific, solution.
Please find attached a Fortran 2008 source code through which I
verified that the decomposition given by both lapack 3.9 and 3.10 is
valid, though the Q matrix is different between the two versions. The
code needs to be compiled with gfortran, and linked against -llapack. I
verified only the double float decomposition (dggsvd), but the single
float decomposition test (sggsvd) most likely fails for the same
reason.
The testsuite of ruby-lapack thus needs to be adapted, by allowing
alternative solutions (either accept both the old and the new
solutions, or completely rethink the test by only verifying the the
decomposition is valid as I did in my program).
N.B. : when trying to reproduce the problem, please ensure that your
lapack alternative (as given by “update-alternatives --display
liblapack.so.3-x86_64-linux-gnu) points to /usr/lib/x86_64-linux-
gnu/lapack/liblapack.so.3, and not to the binary provided by either
openblas or atlas (because these two have not yet been recompiled
against lapack 3.10, and thus do not expose the problem).
Best regards,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
program ggsvd
use iso_fortran_env
implicit none
interface
subroutine dggsvd(jobu, jobv, jobq, m, n, p, k, l, a, lda, b, &
ldb, alpha, beta, u, ldu, v, ldv, q, ldq, work, &
iwork, info)
import :: real64
real(real64), dimension(*), intent(inout) :: a, b
real(real64), dimension(*), intent(out) :: alpha, beta, q, u, v, work
character, intent(in) :: jobq, jobu, jobv
integer, intent(in) :: lda, ldb, ldq, ldu, ldv, m, n, p
integer, intent(out) :: info, k, l
integer, dimension(*), intent(out) :: iwork
end subroutine dggsvd
end interface
real(real64) :: a(4,3), b(2,3), alpha(3), beta(3), u(4,4), v(2,2), q(3,3),
work(12), d1(4,3), d2(2,3), a_bak(4,3), b_bak(2,3)
integer :: info, k, l, iwork(3)
a = reshape(source = [ real(real64) :: 1., 3., 4., 7., 2., 2., 5., 8., 3.,
1., 6., 8. ], shape = [4,3])
b = reshape(source = [ real(real64) :: -2., 4., -3., 6., 3., 5. ], shape = [
2, 3 ])
print '("A=",/,4(3es12.4,:,/))', transpose(a)
print '("B=",/,2(3es12.4,:,/))', transpose(b)
a_bak = a
b_bak = b
call dggsvd("U", "V", "Q", 4, 3, 2, k, l, a, 4, b, 2, alpha, beta, u, 4, v,
2, q, 3, work, iwork, info)
print '("U=",/,4(4es12.4,:,/))', transpose(u)
print '("V=",/,2(2es12.4,:,/))', transpose(v)
print '("Q=",/,3(3es12.4,:,/))', transpose(q)
print '("k=",i1)', k
print '("l=",i1)', l
if (k /= 1) stop "k is incorrect"
if (l /= 2) stop "l is incorrect"
! We are in the case where M-K-L>0
! Also note that N-K-L=0
d1 = 0._real64
d1(1,1) = 1._real64
d1(2,2) = alpha(2)
d1(3,3) = alpha(3)
d2 = 0._real64
d2(1,2) = beta(2)
d2(2,3) = beta(3)
associate (r => a(1:3,1:3))
associate (a2 => matmul(u, matmul(d1, matmul(r, transpose(q, &
b2 => matmul(v, matmul(d2, matmul(r, transpose(q)
print '("Error on reconstructed A: ", es12.4)', maxval(abs(a_bak-a2))
print '("Error on reconstructed B: ", es12.4)', maxval(abs(b_bak-b2))
end associate
end associate
end program ggsvd
signature.asc
Description: This is a digitally signed message part
Bug#994242: linux-image-5.10.0-8-amd64: On a DELL Optiplex 5090 the screen goes black on boot
Package: src:linux Version: 5.10.46-4 Severity: important Dear Maintainer, * What led up to the situation? Installed Debian Bullseye on a new DELL Optiplex 5090 PC * What was the outcome of this action? After the initial boot messages the screen goes blank. * What outcome did you expect instead? A nice Gnome greeting. The kernel linux-image-5.14.0-trunk-amd64 (5.14.3-1~exp1) from experimental works OK. -- Package-specific info: ** Version: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=487ddbab-4e6f-4edd-9990-6eca189de994 ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [1.138692] [ cut here ] [1.138693] i915 :00:02.0: drm_WARN_ON(!IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) && !IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)) [1.138730] WARNING: CPU: 3 PID: 171 at drivers/gpu/drm/i915/intel_pch.c:123 intel_pch_type+0x898/0x950 [i915] [1.138731] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper xhci_pci xhci_hcd cec ahci libahci drm libata nvme usbcore e1000e(+) nvme_core scsi_mod t10_pi crc_t10dif crc32_pclmul crc32c_intel ptp i2c_i801 intel_lpss_pci crct10dif_generic pps_core crct10dif_pclmul i2c_smbus crct10dif_common intel_lpss idma64 usb_common wmi video button [1.138744] CPU: 3 PID: 171 Comm: systemd-udevd Not tainted 5.10.0-8-amd64 #1 Debian 5.10.46-4 [1.138745] Hardware name: Dell Inc. OptiPlex 5090/0X4H68, BIOS 1.1.24 05/17/2021 [1.138772] RIP: 0010:intel_pch_type+0x898/0x950 [i915] [1.138774] Code: 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 61 89 dc d4 48 c7 c1 80 c6 9c c0 4c 89 e2 48 c7 c7 75 65 9f c0 48 89 c6 e8 6b 57 02 d5 <0f> 0b e9 19 f9 ff ff 48 8b 7b 18 4c 8b 67 50 4d 85 e4 75 03 4c 8b [1.138774] RSP: 0018:a864805bfb80 EFLAGS: 00010282 [1.138775] RAX: RBX: 959d5068 RCX: 966b33a8 [1.138776] RDX: c000efff RSI: efff RDI: 0247 [1.138777] RBP: 959d0151e000 R08: R09: a864805bf9a0 [1.138777] R10: a864805bf998 R11: 966cb3e8 R12: 959d014c4e40 [1.138778] R13: 4380 R14: 959d50680808 R15: 959d5068 [1.138779] FS: 7f10ed71c8c0() GS:95a07d4c() knlGS: [1.138779] CS: 0010 DS: ES: CR0: 80050033 [1.138780] CR2: 7f10ed707b7a CR3: 0002d822e005 CR4: 003706e0 [1.138781] Call Trace: [1.138808] intel_detect_pch+0x5b/0x2f0 [i915] [1.138833] i915_driver_probe+0x2c1/0xc90 [i915] [1.138837] ? acpi_dev_found+0x63/0x70 [1.138839] ? vga_switcheroo_client_probe_defer+0x1f/0x40 [1.138863] ? i915_pci_probe+0x3f/0x150 [i915] [1.138865] local_pci_probe+0x42/0x80 [1.138867] ? _cond_resched+0x16/0x40 [1.138868] pci_device_probe+0xfd/0x1b0 [1.138870] really_probe+0xf2/0x440 [1.138871] driver_probe_device+0xe1/0x150 [1.138873] device_driver_attach+0xa1/0xb0 [1.138874] __driver_attach+0x8a/0x150 [1.138875] ? device_driver_attach+0xb0/0xb0 [1.138877] ? device_driver_attach+0xb0/0xb0 [1.138878] bus_for_each_dev+0x78/0xc0 [1.138879] bus_add_driver+0x12b/0x1e0 [1.138881] driver_register+0x8b/0xe0 [1.138882] ? 0xc0adf000 [1.138909] i915_init+0x5d/0x70 [i915] [1.138918] do_one_initcall+0x44/0x1d0 [1.138921] ? do_init_module+0x23/0x260 [1.138922] ? kmem_cache_alloc_trace+0xf5/0x200 [1.138924] do_init_module+0x5c/0x260 [1.138925] __do_sys_finit_module+0xb1/0x110 [1.138928] do_syscall_64+0x33/0x80 [1.138930] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1.138931] RIP: 0033:0x7f10edbd59b9 [1.138932] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48 [1.138932] RSP: 002b:7ffc2a995708 EFLAGS: 0246 ORIG_RAX: 0139 [1.138933] RAX: ffda RBX: 56262c355170 RCX: 7f10edbd59b9 [1.138934] RDX: RSI: 7f10edd60e2d RDI: 000e [1.138935] RBP: 0002 R08: R09: 56262c355010 [1.138935] R10: 000e R11: 0246 R12: 7f10edd60e2d [1.138936] R13: R14: 56262c354fc0 R15: 56262c355170 [1.138937] ---[ end trace 5a3b3d1667028c7c ]--- [1.139370] i915 :00:02.0: [drm] VT-d active for gfx access [1.139372] checking generic (40 1fa4000) vs hw (60 100) [1.139372] checking generic (40 1fa4000) vs hw (40 1000) [1.139373] fb0: switching to inteldrmfb from EFI VGA [1.139432] Console: switching to colour dum
Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons
Am 14.09.21 um 15:20 schrieb paul_deg: > What you say makes 0 sense. Helpful. Not. I could have said that for you too, (besides that your "top menu" also didn't make any sense at all given you mean "tool bar".) I didn't, I tried to argue with examples. Like writing black on black. (here it is that beige or whatever that is on Adwaitas default beige background.) > Anyone can choose this icon set, this is what tweaks tool is for. I didn't say otherwise. Of course one can. One can also just set a dark normal UI theme in additon and be done, I also didn't say this wasn't a problem. If I did the bug would be closed. > And Libre office is the only app which has issues with it, likely > because it's incompatible. Maybe, because it's not a native gtk app (tries to look like it, but also has own icons). I still maintain that it would be trivial to also use a black background and then this would be non-issue. Regards, Rene
Bug#994243: ITP: simple-image-filter -- An image processing software
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: simple-image-filter Version : 1.0.9 Upstream Author : dependon * URL : https://github.com/dependon/simple-image-filter * License : GPL-3 Programming Lang: C++ Description : An image processing software, can handle image rotation, clip, basic beautification, filter and other graph functions
Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons
Hi, Am 14.09.21 um 15:54 schrieb paul deg: > Saying it's "not reproducible" is refusing to accept reality. If you actually have read my mails you would have seen that I a) acknowledged the problem (there's a easy workaround, though) b) removed the unreproducible tag already. Regards, Rene
Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons
Hi, Am 14.09.21 um 15:59 schrieb Rene Engelhard: > b) removed the unreproducible tag already. OK, actually I forgot the CC. (This happens if you do it when you actually have more imprtant university stuff to do...) Done manually now. Regards, Rene
Bug#994244: ITP: ilorest -- cli for managing servers over the Redfish API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ilorest Version : 3.2.2 Upstream Author : Rajeev Kallur * URL : https://github.com/HewlettPackard/python-redfish-utility * License : BSD-3-clause Programming Lang: Python Description : cli for managing servers over the Redfish API The Redfish Utility is a command line interface that allows one to manage servers that take advantage of Redfish APIs. In addition to using the utility manually to execute individual commands, you can create scripts to automate tasks.
Bug#994245: nodejs: improve bootstraping nodejs
Package: nodejs Version: 12.22.5~dfsg-2 Severity: important Dear Maintainer, I will like to improve bootstraping new nodejs. It will need to annotate nodejs with correct mutliarch tag and the depends Bastien
Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!
Could we get the patch uploaded to fix the issue? The webkitgtk depends got removed for 2.32 but 2.33 in experimental still has a depends and tests are failing https://ci.debian.net/data/autopkgtest/unstable/amd64/b/balsa/15157874/log.gz On Ubuntu Recommends are installed by default which also makes it fail there so we did upload a patched balsa now but it would be nice to have the fix in Debian since it would be more reliable than having flaky results depending of the installed packages
Bug#994245: [Pkg-javascript-devel] Bug#994245: nodejs: improve bootstraping nodejs
Le mar. 14 sept. 2021 à 16:24, Bastien Roucariès < roucaries.bast...@gmail.com> a écrit : > Package: nodejs > Version: 12.22.5~dfsg-2 > Severity: important > > Dear Maintainer, > > I will like to improve bootstraping new nodejs. > > It will need to annotate nodejs with correct mutliarch tag and the depends > Cool :) Jérémy
Bug#994246: xtensor: arm64 FTBFS: xsimd neon error xsimd::batch_bool does not have any field named ‘simd_complex_batch_bool’
Source: xtensor Version: 0.23.10-5 Severity: normal Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2433 xtensor 0.23.10 FTBFS on arm64 with errors like: [ 4%] Building CXX object test/CMakeFiles/test_xtensor_lib.dir/test_xadaptor_semantic.cpp.o cd /<>/obj-aarch64-linux-gnu/test && /usr/bin/c++ -DXSIMD_ENABLE_XTL_COMPLEX -DXTENSOR_USE_XSIMD -I/<>/include -isystem /<>/obj-aarch64-linux-gnu/test/googletest-src/googletest/include -isystem /<>/obj-aarch64-linux-gnu/test/googletest-src/googletest -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -march=native -std=c++14 -Wunused-parameter -Wextra -Wreorder -Wconversion -Wsign-conversion -Wold-style-cast -Wunused-variable -ftemplate-backtrace-limit=0 -DGTEST_HAS_PTHREAD=1 -o CMakeFiles/test_xtensor_lib.dir/test_xadaptor_semantic.cpp.o -c /<>/test/test_xadaptor_semantic.cpp In file included from /usr/include/xsimd/types/xsimd_types_include.hpp:69, from /usr/include/xsimd/types/xsimd_traits.hpp:17, from /usr/include/xsimd/xsimd.hpp:16, from /<>/include/xtensor/xtensor_config.hpp:75, from /<>/include/xtensor/xbuffer_adaptor.hpp:21, from /<>/include/xtensor/xarray.hpp:19, from /<>/test/test_xjson.cpp:14: /usr/include/xsimd/types/xsimd_neon_complex.hpp:369:15: error: ‘template class xsimd::simd_complex_batch_bool’ used without template arguments 369 | using simd_complex_batch_bool::simd_complex_batch_bool; | ^~~ /usr/include/xsimd/types/xsimd_neon_complex.hpp: In constructor ‘xsimd::batch_bool, 4>::batch_bool(bool, bool, bool, bool)’: /usr/include/xsimd/types/xsimd_neon_complex.hpp:374:15: error: class ‘xsimd::batch_bool, 4>’ does not have any field named ‘simd_complex_batch_bool’ 374 | : simd_complex_batch_bool(real_batch(b0, b1, b2, b3)) | ^~~ /usr/include/xsimd/types/xsimd_neon_complex.hpp: At global scope: /usr/include/xsimd/types/xsimd_neon_complex.hpp:410:26: error: type ‘xsimd::batch, 4>::base_type’ is not a base type for type ‘xsimd::batch, 4>’ 410 | using base_type::base_type; | ^ /usr/include/xsimd/types/xsimd_neon_complex.hpp:419:26: error: type ‘xsimd::batch, 4>::base_type’ is not a base type for type ‘xsimd::batch, 4>’ 419 | using base_type::load_aligned; ... This is after patching with xsimd_xcomplex.patch (see https://github.com/xtensor-stack/xtensor/issues/1898 ) The problem seems to be related to but not the same as upstream Issue#1898. Reported upstream at https://github.com/xtensor-stack/xtensor/issues/2433 but the underlying problem seems to be a bug in neon support in xsimd, https://github.com/xtensor-stack/xsimd/issues/400 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#980068: cmake: Please update to version 3.19.3 before bullseye freeze
Control: retitle 980068 cmake: please backport cmake 3.19.3 or newer to bullseye On Mon, 22 Feb 2021 11:15:10 +0900 ciel wrote: Now I saw libboost 1.74 is migrated to testing (bullseye). boost 1.74 is not compatible with cmake 3.18. As a released version, I do need cmake 3.19 (or later). I'm sorry the bug was not fixed in time. I'll see what I can do about a backport. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#987686: webkit2gtk breaks balsa autopkgtest: xwd: error: No window with name Balsa exists!
On Tue, Sep 14, 2021 at 04:35:35PM +0200, Sebastien Bacher wrote: > Could we get the patch uploaded to fix the issue? The webkitgtk depends > got removed for 2.32 but 2.33 in experimental still has a depends and > tests are failing > https://ci.debian.net/data/autopkgtest/unstable/amd64/b/balsa/15157874/log.gz I don't see a reason not to apply the patch. Berto
Bug#994160: libmojolicious-plugin-assetpack-perl: newer upstream version (2.13) available
On Tue, 14 Sep 2021 09:43:07 +0200, Philip Hands wrote: > > 2.13-1 is already in Git but has a note in d/changelog: > > > > WAITS-FOR: libmojolicious-perl 9.0 > > > > so it's "just" waiting for someone to update Mojolicious to a new > > major release. > > Ah, fair enough. > Sorry for the noise then. > (I should have thought of looking for that ... I will do in future). No worries, it's a welcome reminder / a hint for priorisation of our many pending new releases. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Funny van Dannen: Stell ich mir Politiker beim Wichsen vor signature.asc Description: Digital Signature
Bug#994247: boinc-manager: if manager is closed while event log window is open it wont show up again
Package: boinc-manager Version: 7.16.16+dfsg-1 Severity: normal X-Debbugs-Cc: lorenzobertin...@gmail.com Dear Maintainer, steps to reproduce: 1. open boinc-manager's main window 2. open "tools -> event log..." window 3. close the manager's main window so both windows close 4. main window is now unreachable, neither from the environment's launcher nor terminal 5. a new instance can't be started as this one is already running Might be of importance: I noticed that event log window is is the ONLY window that allows defocus and the main window to be closed while still active, the other secondary windows always have focus and all need to be closed before. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 boinc-manager depends on: ii boinc-client 7.16.16+dfsg-1 ii libboinc7 7.16.16+dfsg-1 ii libc6 2.31-13 ii libgcc-s1 10.2.1-6 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4 ii libnotify40.7.9-3 ii libstdc++610.2.1-6 ii libwxbase3.0-0v5 3.0.5.1+dfsg-2 ii libwxgtk-webview3.0-gtk3-0v5 3.0.5.1+dfsg-2 ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-2 boinc-manager recommends no packages. Versions of packages boinc-manager suggests: ii libgl1-mesa-glx 20.3.5-1 ii libxt6 1:1.2.0-1
Bug#994248: xtensor: build error on i686 with xsimd: incomplete type xsimd::batch
Source: xtensor Version: 0.23.10-5 Severity: normal Control: forwarded -1 https://github.com/xtensor-stack/xtensor/issues/2434 A build of xtensor 0.23.10 is failing on i386 (i686) when xsimd support is activated (xsimd 7.5.0). An excerpt from the build log is, https://buildd.debian.org/status/fetch.php?pkg=xtensor&arch=i386&ver=0.23.10-5&stamp=1631562580&raw=0 [ 4%] Building CXX object test/CMakeFiles/test_xtensor_lib.dir/test_xadaptor_semantic.cpp.o cd /<>/obj-i686-linux-gnu/test && /usr/bin/c++ -DXSIMD_ENABLE_XTL_COMPLEX -DXTENSOR_USE_XSIMD -I/<>/include -isystem /<>/obj-i686-linux-gnu/test/googletest-src/googletest/include -isystem /<>/obj-i686-linux-gnu/test/googletest-src/googletest -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -march=native -std=c++14 -Wunused-parameter -Wextra -Wreorder -Wconversion -Wsign-conversion -Wold-style-cast -Wunused-variable -ftemplate-backtrace-limit=0 -DGTEST_HAS_PTHREAD=1 -o CMakeFiles/test_xtensor_lib.dir/test_xadaptor_semantic.cpp.o -c /<>/test/test_xadaptor_semantic.cpp ... In file included from /<>/include/xtensor/xsemantic.hpp:16, from /<>/include/xtensor/xstrided_view.hpp:25, from /<>/include/xtensor/xgenerator.hpp:27, from /<>/include/xtensor/xbuilder.hpp:31, from /<>/include/xtensor/xmanipulation.hpp:13, from /<>/include/xtensor/xmath.hpp:28, from /<>/include/xtensor/xcontainer.hpp:25, from /<>/include/xtensor/xarray.hpp:20, from /<>/test/test_extended_xsort.cpp:15: /<>/include/xtensor/xassign.hpp: In instantiation of ‘static void xt::strided_loop_assigner::run(E1&, const E2&) [with E1 = xt::xtensor_container >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>; E2 = xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>; bool simd = true]’: /<>/include/xtensor/xassign.hpp:399:60: required from ‘static void xt::xexpression_assigner_base::assign_data(xt::xexpression&, const xt::xexpression&, bool) [with E1 = xt::xtensor_container >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>; E2 = xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>]’ /<>/include/xtensor/xassign.hpp:413:31: required from ‘static void xt::xexpression_assigner::assign_xexpression(E1&, const E2&) [with E1 = xt::xexpression >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag> >; E2 = xt::xexpression, 1, xt::layout_type::row_major, xt::xtensor_expression_tag> >; Tag = xt::xtensor_expression_tag]’ /<>/include/xtensor/xassign.hpp:204:58: required from ‘xt::assign_xexpression >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>, xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag> >:: [with auto:65 = xtl::identity]’ /usr/include/xtl/xmeta_utils.hpp:597:22: required from ‘decltype(auto) xtl::mpl::static_if(std::false_type, const TF&, const FF&) [with TF = xt::assign_xexpression >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>, xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag> >::; FF = xt::assign_xexpression >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>, xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag> >::; std::false_type = std::integral_constant]’ /usr/include/xtl/xmeta_utils.hpp:603:29: required from ‘decltype(auto) xtl::mpl::static_if(const TF&, const FF&) [with bool cond = false; TF = xt::assign_xexpression >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>, xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag> >::; FF = xt::assign_xexpression >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>, xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag> >::]’ /<>/include/xtensor/xassign.hpp:198:58: required from ‘void xt::assign_xexpression(xt::xexpression&, const xt::xexpression&) [with E1 = xt::xtensor_container >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>; E2 = xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>]’ /<>/include/xtensor/xsemantic.hpp:623:31: required from ‘xt::xcontainer_semantic::derived_type& xt::xcontainer_semantic::assign_xexpression(const xt::xexpression&) [with E = xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>; D = xt::xtensor_container >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>; xt::xcontainer_semantic::derived_type = xt::xtensor_container >, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>]’ /<>/include/xtensor/xsemantic.hpp:489:55: required from ‘xt::xsemantic_base::derived_type& xt::xsemantic_base::assign(const xt::xexpression&) [with E = xt::xtensor_view, 1, xt::layout_type::row_major, xt::xtensor_expression_tag>; D = xt::xtenso
Bug#994248: xtensor: build error on i686, x32 with xsimd: incomplete type xsimd::batch
Applies also to x32, https://buildd.debian.org/status/fetch.php?pkg=xtensor&arch=x32&ver=0.23.10-5&stamp=1631538409&raw=0
Bug#993864: ITP: taskserver -- taskwarrior synchronisation server
You're right, the tracker one is a public team. I was just requesting for access to the Salsa team, the way I wrote it was not clear. Anyway, thank you! Sergio Cipriano. On Monday, September 13th, 2021 at 16:33, Gordon Ball wrote: > I thought the tracker one at least is a public team, for which access > > shouldn't need to be approved. In any case, I don't appear to have any > > way to grant access. > > I've granted you access to the Salsa team. Welcome! > > Gordon > > On Sat, Sep 11, 2021 at 08:20:45PM +, Sergio Cipriano wrote: > > > Hi Gordon, > > > > I requested access to the Debian Tasktools Team. > > > > May you accept my request? > > > > Sergio Cipriano. > > > > On Friday, September 10th, 2021 at 06:44, Gordon Ball gor...@chronitis.net > > wrote: > > > > > Hi Sergio > > > > > > In that case, please take over the taskd package. Because I felt the > > > > > > package was abandoned, there has been a "don't migrate to testing" RC > > > > > > bug open for a while, so feel free to close that when you have something > > > > > > in better shape. > > > > > > I don't have a continuing interest in this package, so please remove me > > > > > > from the uploaders. You might want to join the tasktools team on tracker > > > > > > (team+taskto...@tracker.debian.org) and add that as a maintainer. > > > > > > Gordon > > > > > > On Wed, Sep 08, 2021 at 11:14:19AM +, Sergio Cipriano wrote: > > > > > > > Hi Gordon, > > > > > > > > On Wednesday, September 8th, 2021 at 02:16, Gordon Ball > > > > gor...@chronitis.net wrote: > > > > > > > > > Hi Sergio > > > > > > > > > > Note that there is already `taskd` in the archive (former name of > > > > > > > > > > taskserver). It's not been uploaded for a number of years and I > > > > > believed > > > > > > > > > > that it was dead upstream (and I had lost interest in using it). If > > > > > > > > > > you're interested you could either take over that package (and > > > > > introduce > > > > > > > > > > a new binary name), or I can rm it in favour of taskserver. > > > > > > > > > > On Tue, Sep 07, 2021 at 09:24:51AM -0300, Sergio de Almeida Cipriano > > > > > Junior wrote: > > > > > > > > > > > Package: wnpp > > > > > > > > > > > > Severity: wishlist > > > > > > > > > > > > Owner: Sergio de Almeida Cipriano Junior sergios...@protonmail.com > > > > > > > > > > > > X-Debbugs-Cc: debian-de...@lists.debian.org, > > > > > > sergios...@protonmail.com > > > > > > > > > > > > - Package name : taskserver > > > > > > > > > > > > Version : 1.1.0 > > > > > > > > > > > > Upstream Author : Göteborg Bit Factory > > > > > > supp...@gothenburgbitfactory.org > > > > > > > > > > > > - URL : https://github.com/GothenburgBitFactory/taskserver > > > > > > > > > > > > - License : MIT > > > > > > > > > > > > Programming Lang: C++ > > > > > > > > > > > > Description : taskwarrior synchronisation server > > > > > > > > > > > > > > > > > > Taskserver is a daemon or service that will allow you to share > > > > > > tasks among > > > > > > > > > > > > different client applications, primarily Taskwarrior. > > > > > > > > I am interested in taskd and I would be glad to take over the package. > > > > > > > > Cheers Sergio.
Bug#994249: postgresql-client-common: vacuumlo erroneously complains about missing client package
Package: postgresql-client-common Version: 225 Severity: minor When only postgresql client package(s) are installed, the vacuumlo wrapper erroneously reports: Error: You must install at least one postgresql-client- package Even though the client package(s) _are_ installed. This seems to be because the underlying binaries are provided by the postgresql _server_ package(s). Which may also be a bug? The upstream documentation for the vacuumlo package implies that it can be run as a client, it doesn't seem to need to be run directly on/from the server system. -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 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 postgresql-client-common depends on: ii netbase 6.3 Versions of packages postgresql-client-common recommends: ii libreadline8 8.1-1 postgresql-client-common suggests no packages. -- no debconf information
Bug#994250: simple-scan: Brightness and Contrast settings do not have any effect (CanoScan Lide 35)
Package: simple-scan Version: 3.38.1-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I often need b/w scans, but these are always too dark * What exactly did you do (or not do) that was effective (or ineffective)? I tried to set the brightness control to higher levels * What was the outcome of this action? No effect * What outcome did you expect instead? Controllable image brightness/contrast The problem occured both on a upgraded system and on a fresh Debian 11 installation. -- Package-specific info: -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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 simple-scan depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii libc6 2.31-13 ii libcairo2 1.16.0-5 ii libcolord21.4.5-3 ii libgdk-pixbuf2.0-02.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4 ii libgusb2 0.3.5-1 ii libpackagekit-glib2-181.2.2-2 ii libsane1 1.0.31-4.1 ii libwebp6 0.6.1-2.1 ii libwebpmux3 0.6.1-2.1 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.11.dfsg-2 simple-scan recommends no packages. simple-scan suggests no packages. -- no debconf information
Bug#993750: rgtk2: FTBFS on s390x: smoke-test failure: caught segfault
Hi Philipp, Hi Simon, If we have no resolution on this I will have no other way than to re-upload r-cran-rgtk2 with a build exclusion for s390 as I now have an autoremoval notice for it (and another package I look after than depends on it). Or do we have other/better options? Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#985000: nfs-common: auth-rpcgss-module.service fails inside Linux containers (LXC)
Hi Joachim, On Thu, Mar 11, 2021 at 07:37:17PM +0100, Joachim Falk wrote: > Package: nfs-common > Version: 1:1.3.4-5 > Severity: important > Tags: patch > X-Debbugs-Cc: joachim.f...@gmx.de, felix.lech...@lease-up.com > > To fix this problem, the auth_rpcgss kernel module must only be loaded > if it is not already loaded. Otherwise, the auth-rpcgss-module service > will fail inside a Linux container as the loading of kernel modules is > forbidden for the container. Thus, the "/sbin/modprobe -q auth_rpcgss" > call will fail even if the auth_rpcgss kernel module was already loaded. > This has been testesd with kmod up to version 28-1 (current in bullseye > as of 2021-03-11). This situation occurs when the container host already > loaded the auth_rpcgss kernel module to enable kerberized NFS service > for its containers. With the nfs-utils upload to experimental happened and rebasing to 2.5.4 we want to as less as needed diverge from upstream. Can you please report your case upstream and make sure the patch is accepted upstream? 1:1.3.4-6 in the end was too much with Debian keep it maintainable and made it hard to upgrade. Regards, Salvatore
Bug#990674: s2-geometry-library: The Homepage is wrong in metadata
On Mon, Sep 13, 2021 at 10:42 AM Christoph Anton Mitterer < cales...@scientia.net> wrote: > On Mon, 2021-09-13 at 11:32 +0100, Sudip Mukherjee wrote: > > Yes, and what about mentioning in the package description: > > "Additional documents can be found at https://s2geometry.io/"; > > Sounds reasonable :-) > I like it. > > > Google one got its commit after 10 years :) > > Anyways, s2-geometry-library is a dependency of lucene8. I can check > > if it can use the google version. But iirc, upstream lucene8 was > > using > > the non-google port. > > Ah I see :-) > > > Thanks, > Chris. > >
Bug#994006: libc6: NSS modules changes require a restart of systemd-logind, which is not possible
On 2021-09-14 08:56, Simon McVittie wrote: > On Mon, 13 Sep 2021 at 22:59:32 +0200, Aurelien Jarno wrote: > > - running the operation on a non-existing user, but as loginctl does a > > check that the user exists, it has to be done directly with the dbus > > API, for instance "gdbus call --system --dest org.freedesktop.login1 > > --object-path /org/freedesktop/login1 --method > > org.freedesktop.login1.Manager.SetUserLinger 12345678 true true" > > > > The latest is more a bit more complex to do (especially that > > libglib2.0-bin is not necessarily installed on the system), but has the > > advantage of exercising all configured NSS modules. > > systemd happens to have its own D-Bus implementation sd-bus (a competitor > to libdbus and GLib's GDBus) for which it provides busctl(1), an > equivalent of gdbus(1) and dbus-send(1). So this could be written as: > > busctl call --system org.freedesktop.login1 /org/freedesktop/login1 \ > org.freedesktop.login1.Manager SetUserLinger ubb $uid true true > > which does not have dependencies outside systemd.deb. Thanks a lot for the help here, as my knowledge with systemd is relatively limited. That seems to work fine when executed just before the libc6 upgrade in the script I use to trigger the upgrade at boot time. I'll try to insert all pieces into libc6.preinst and see if that still works. > The nonexistent uid should probably be in one of the ranges reserved by > Policy §9.2.2: perhaps 4294967294 or (uint32_t) -2, which is reserved > as a representation of the anonymous NFS user? Yes, that is probably a good pick. I guess we should actually disable lingering (so ... ubb 4294967294 false false) to minimize the damages if this user exists anyway. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#994232: libc6: generates unnecessarily tight dependencies on mips, mipsel
On 2021-09-14 09:28, Simon McVittie wrote: > Package: libc6 > Version: 2.32-2 > Severity: normal > Tags: patch > X-Debbugs-Cc: debian-rele...@lists.debian.org > > Most architectures' libc6.symbols.$arch have this pattern: > > > $ cat debian/libc6.symbols.i386 > > #include "libc6.symbols.common" > > ld-linux.so.2 #PACKAGE# #MINVER# > > #include "symbols.wildcards" > > libc.so.6 #PACKAGE# #MINVER# > > #include "symbols.wildcards" > > This results in any use of symbols versioned foo@GLIBC_2.23 generating a > dependency on libc6 (>= 2.23), and so on. > > However, libc6:mips and libc6:mipsel are missing the final > '#include "symbols.wildcards"', which results in those architectures > generating an unnecessarily strict dependency on libc6 (>= 2.32-1) and > entangling other transitions with glibc's transition. As far as I can see, > this was accidental? Yes, this one indeed accidental, my cleanup to remove the complexity from the linuxthreads to NPTL transition has been too agressive. Thanks a lot for catching that and for the patch. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#994133: libc-bin: [iconv] [fr] Missing word in the French output of iconv
Hi, On 2021-09-14 12:56, Baptiste Jammet wrote: > control: reassign -1 libc-bin > control: retitle -1 libc-bin: [iconv] [fr] Missing word in the French > output of iconv --help > control: tags -1 upstream > > Hi all, > > >It’s in the output of iconv --help. > > So it's not in the manpage, but in the po/fr.po file of the iconv > source : > https://sources.debian.org/src/glibc/2.32-2/po/fr.po/#L42 > introduced in upstream by: > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0ffaa7be6ea3649f883248f41a2bea5065383976#patch11 > > Sorry for the ping-pong and thank you all for the translation work! Oops, sorry about that, I have read manpage in the topic, so I didn't check further as it is a common issue to report those to the wrong package. I have contacted the translator to get it fixed. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#994251: i386 baseline violation
Package: mesa Version: 21.2.1-2 Control: notfound -1 21.1.6-1 Control: found -1 21.2.0-1 The mesa DRI drivers (and possibly other binary packages I haven't tested) appear to violate the i386 baseline by using SSE2 unconditionally, even if the host CPU doesn't support it (tested on a Pentium III), which results in even the simplest programs like glxinfo or glxgears crashing with SIGILL. The solution is simple: rebuild the package with the meson option "sse2" set to false, to follow the Debian baseline.
Bug#914820: nfs-kernel-server: Non-existent path in /etc/exports causes nfs-server systemd unit to refuse to start
Source: nfs-utils
Source-Version: 1:2.5.4-1~exp1
Upstream commit 003000d45183 ("exportfs: Ingnore export failures in
nfs-server.serivce unit") addresses this issue.
Regards,
Salvatore
Bug#994252: Contacts: Retrieve user S/MIME certificate does not work
Package: evolution-ews
Version: 3.36.5-0ubuntu1
Severity: normal
Tags: patch
It's currently not possible to retrieve encryption certificates from GAL when
connecting to o365.
upstream:
- issue: https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/3
- patch: https://gitlab.gnome.org/GNOME/evolution-
ews/uploads/ffa7d7a4934cd6bd8b0f44d8c5a47f8f/ews.patch
The patch has not yet been merged upstream due to hard code freeze.
I've back-ported the patch to evolution-ews 3.38 so it could be shipped with
Debian stable. Would be great if you could integrate that and ship it with
latest Debian stable, so people could benefit already today.
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-84-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages evolution-ews depends on:
ii evolution3.36.5-0ubuntu1
ii evolution-data-server3.36.5-0ubuntu1
ii libc62.31-0ubuntu9.2
ii libcamel-1.2-62 3.36.5-0ubuntu1
ii libebackend-1.2-10 3.36.5-0ubuntu1
ii libebook-1.2-20 3.36.5-0ubuntu1
ii libebook-contacts-1.2-3 3.36.5-0ubuntu1
ii libecal-2.0-13.36.5-0ubuntu1
ii libedata-book-1.2-26 3.36.5-0ubuntu1
ii libedata-cal-2.0-1 3.36.5-0ubuntu1
ii libedataserver-1.2-243.36.5-0ubuntu1
ii libedataserverui-1.2-2 3.36.5-0ubuntu1
ii libevolution 3.36.5-0ubuntu1
ii libglib2.0-0 2.64.6-1~ubuntu20.04.4
ii libgtk-3-0 3.24.20-0ubuntu1
ii libical3 3.0.8-1
ii libmspack0 0.10.1-2
ii libpango-1.0-0 1.44.7-2ubuntu4
ii libsoup2.4-1 2.70.0-1
ii libxml2 2.9.10+dfsg-5ubuntu0.20.04.1
evolution-ews recommends no packages.
evolution-ews suggests no packages.
-- no debconf information
>From b1ef96f7daee840c4695a3ffccb3ea843cbd8068 Mon Sep 17 00:00:00 2001
From: Roger Meier
Date: Mon, 13 Sep 2021 16:32:02 +0200
Subject: [PATCH] Contacts: Retrieve user S/MIME certificate
see https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/3
---
src/EWS/addressbook/e-book-backend-ews.c | 335 +--
src/EWS/addressbook/ews-oab-decoder.c| 54 +++-
src/EWS/common/e-ews-connection.c| 8 +-
src/EWS/common/e-ews-item.c | 65 +
src/EWS/common/e-ews-item.h | 5 +
5 files changed, 431 insertions(+), 36 deletions(-)
diff --git a/src/EWS/addressbook/e-book-backend-ews.c
b/src/EWS/addressbook/e-book-backend-ews.c
index 197d49fd..9bf75100 100644
--- a/src/EWS/addressbook/e-book-backend-ews.c
+++ b/src/EWS/addressbook/e-book-backend-ews.c
@@ -60,6 +60,10 @@
#define X_EWS_CHANGEKEY "X-EWS-CHANGEKEY"
#define X_EWS_GAL_SHA1 "X-EWS-GAL-SHA1"
#define X_EWS_PHOTO_CHECK_DATE "X-EWS-PHOTO-CHECK-DATE" /* MMDD of the
last check for photo */
+#define X_EWS_CERT_KIND "X-EWS-CERT-KIND"
+
+#define E_EWS_CERT_KIND_USER "UserSMIMECertificate"
+#define E_EWS_CERT_KIND_MSEX "MSExchangeCertificate"
#define EWS_MAX_FETCH_COUNT 500
@@ -69,7 +73,19 @@
/* passing field uris for PhysicalAddress, PhoneNumbers causes error, so we
* use Default view to fetch them. Thus the summary props just have attachments
* and some additional properties that are not return with Default view */
-#define CONTACT_ITEM_PROPS "item:Attachments item:HasAttachments item:Body
item:LastModifiedTime contacts:Manager contacts:Department contacts:SpouseName
contacts:AssistantName contacts:BusinessHomePage contacts:Birthday"
+#define CONTACT_ITEM_PROPS "item:Attachments "\
+ "item:HasAttachments "\
+ "item:Body "\
+ "item:LastModifiedTime "\
+ "contacts:Manager "\
+ "contacts:Department "\
+ "contacts:SpouseName "\
+ "contacts:AssistantName "\
+ "contacts:BusinessHomePage "\
+ "contacts:Birthday"
+#define CONTACT_ITEM_PROPS_10SP2 CONTACT_ITEM_PROPS " "\
+ "contacts:UserSMIMECertificate "\
+ "contacts:MSExchangeCertificate"
struct _EBookBackendEwsPrivate {
GRecMutex cnc_lock;
@@ -551,6 +567,238 @@ ebews_populate_photo (EBookBackendEws *bbews,
e_contact_photo_free (photo);
}
+static void
+ebews_populate_cert (EBookBackendEws *bbews,
+EContact *contact,
+EEwsItem *item,
+const gchar *kind,
+GCancellable *
Bug#994252: Acknowledgement (Contacts: Retrieve user S/MIME certificate does not work)
Sorry, I was using an Ubuntu system to report the bug. Nevertheless, this report is for Debian stable and unstable, the provided patch is backported and tested on Debian stable using evolution-ews 3.38.3-1 The patch for evolution-ews on Ubuntu has been submitted here: https://bugs.launchpad.net/ubuntu/+source/evolution-ews/+bug/1943450 best! roger On Tue, 2021-09-14 at 18:09 +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 994252: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994252. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due > course. > > As you requested using X-Debbugs-CC, your message was also forwarded > to > r.me...@siemens.com > (after having been given a Bug report number, if it did not have > one). > > Your message has been sent to the package maintainer(s): > Debian GNOME Maintainers < > pkg-gnome-maintain...@lists.alioth.debian.org> > > If you wish to submit further information on this problem, please > send it to 994...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > smime.p7s Description: S/MIME cryptographic signature
Bug#993553: ITP: myst-parser -- rich and extensible flavor of Markdown meant for technical documentation and publishing
Hi Emmanuel, Great that you are packaging MyST - it seems I will need it. If you need help packaging it, please tell - maybe I can assist... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#994253: golang-github-biogo-hts: FTBFS with Go 1.17
Package: golang-github-biogo-hts
Version: 1.1.0+dfsg1-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch
Dear Maintainer,
Due to a change in the behavior of the csv package in Go 1.17, this package
currently FTBFS with Go 1.17. The included patch pulls in an upstream
change that addresses this failure.
In Ubuntu, the attached patch was applied to achieve the following:
Successfully build the package with Go 1.17
* Cherry pick upstream change to a test case that enables building
with Go 1.17 (LP: #1943629)
Thanks for considering the patch.
-- System Information:
Debian Release: bullseye/sid
APT prefers hirsute-updates
APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500,
'hirsute'), (100, 'hirsute-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.11.0-34-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
golang-github-biogo-hts-1.1.0+dfsg1/debian/patches/0003-cherry-pick-go-1.17-test-fix.patch
golang-github-biogo-hts-1.1.0+dfsg1/debian/patches/0003-cherry-pick-go-1.17-test-fix.patch
---
golang-github-biogo-hts-1.1.0+dfsg1/debian/patches/0003-cherry-pick-go-1.17-test-fix.patch
1969-12-31 18:00:00.0 -0600
+++
golang-github-biogo-hts-1.1.0+dfsg1/debian/patches/0003-cherry-pick-go-1.17-test-fix.patch
2021-09-13 12:54:26.0 -0500
@@ -0,0 +1,83 @@
+Description: Resolve FTBFS with Go 1.17
+ As of Go 1.17, there are changes in the behavior of csv.ParseError that were
+ causing a failure in a build time test of this package.
+Origin: upstream,
https://github.com/biogo/hts/commit/57433369861bc0b56ae7b4416ebab38f40a1c9d6
+Bug-Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/golang-github-biogo-hts/+bug/1943629
+Applied-Upstream:
https://github.com/biogo/hts/commit/57433369861bc0b56ae7b4416ebab38f40a1c9d6
+Last-Update: 2021-09-14
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- /dev/null
b/fai/column_go117_test.go
+@@ -0,0 +1,14 @@
++// Copyright ©2021 The bíogo Authors. All rights reserved.
++// Use of this source code is governed by a BSD-style
++// license that can be found in the LICENSE file.
++
++// TODO(kortschak): Remove this when go1.16 is no longer supported.
++
++// +build go1.17
++
++package fai
++
++// dropCSVColumn is a no-op.
++func dropCSVColumn(err error) error {
++ return err
++}
+--- /dev/null
b/fai/column_prego117_test.go
+@@ -0,0 +1,23 @@
++// Copyright ©2021 The bíogo Authors. All rights reserved.
++// Use of this source code is governed by a BSD-style
++// license that can be found in the LICENSE file.
++
++// +build !go1.17
++
++package fai
++
++import "encoding/csv"
++
++// dropCSVColumn drops Column field information. It is required
++// to harmonise behaviour between Go versions before and after
++// v1.17. The relevant change in the standard library is 6d95e5a4.
++func dropCSVColumn(err error) error {
++ csvErr, ok := err.(*csv.ParseError)
++ if !ok {
++ return err
++ }
++ if csvErr.Err == csv.ErrFieldCount {
++ csvErr.Column = 0
++ }
++ return csvErr
++}
+--- a/fai/fai_test.go
b/fai/fai_test.go
+@@ -81,7 +81,7 @@
+ NODE_19170_length_305_cov_2.147541325 168960 61
+ NODE_23972_length_201_cov_2`,
+ idx: nil,
+- err: parseError(8, 0, csv.ErrFieldCount),
++ err: parseError(8, 1, csv.ErrFieldCount),
+ },
+ {
+ in: `NODE_7194_length_226_cov_2.672566 246 35
60 61
+@@ -107,7 +107,7 @@
+ NODE_53327_length_192_cov_1.854167212 559060 61
+ `,
+ idx: nil,
+- err: parseError(13, 0, csv.ErrFieldCount),
++ err: parseError(13, 1, csv.ErrFieldCount),
+ },
+ {
+ in: `NODE_7194_length_226_cov_2.672566 246 35
60 61
+@@ -163,8 +163,8 @@
+ },
+ } {
+ got, err := ReadFrom(strings.NewReader(test.in))
+- if !reflect.DeepEqual(err, test.err) {
+- t.Errorf("unexpected error: got:%v want:%v", err,
test.err)
++ if !reflect.DeepEqual(err, dropCSVColumn(test.err)) {
++ t.Errorf("unexpected error for test %d: got:%#v
want:%#v", i, err, test.err)
+ }
+ if !reflect.DeepEqual(got, test.idx) {
+ t.Errorf("unexpected result for test %d: got:%#v
want:%#v", i, got, test.idx)
diff -Nru golang-github-biogo-hts-1.1.0+dfsg1/debian/patches/series
golang-github-biogo-h
Bug#994109: scilab FTBFS with hdf5 1.10.7
Julien Puydt a écrit le 13/09/2021 à 08:51 : Excellent! Please commit to salsa but don't upload yet Done. Best, _g.
Bug#969354: lists.debian.org: Use DKIM with lists.debian.org
[This is a repeat of the archived #500966] On Mon, Aug 31, 2020 at 07:30:13PM -0400, Alexander Tait Brotman wrote: > lists.debian.org should use DKIM as part of taking ownership of its > messages. This allows mailbox providers to be reasonably sure that > messages signed by the systems can be attributed to lists.debian.org, > and perhaps assist with domain reputation. This may also help with > forwarding as ARC gains traction as well. This should not have any > major impact on performance, nor on deliverability. I don't think DKIM will help much. But it would really, really help if lists.debian.org could do ARC so that providers can a) do reputation or b) just trust that domain to get it right. Yes, there have been some changes to invalidate DKIM signatures less, but you cannot control what the incoming DKIM signature encompassed. So I found a mail recently where there were various headers included that lists.debian.org modifies by design. ARC solves this problem by just letting you sign the outgoing emails, regardless of prior DKIM status. Kind regards Philipp Kern
Bug#993770: dazzdb: autopkgtest failure with glibc 2.32
On 2021-09-06 11:59, Graham Inggs wrote:
> Source: dazzdb
> Version: 1.0+git20201103.8d98c37-1
> Severity: serious
> Forwarded: https://github.com/thegenemyers/DAZZ_DB/issues/41
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: needs-update
>
> Hi Maintainer
>
> Since the upload of glibc 2.32-1 to unstable, dazzdb's autopkgtests fail [1].
>
> autopkgtest [05:31:22]: test run-unit-test: [---
> /tmp/autopkgtest-lxc.mrzrjkw_/downtmp/build.u1T/src/debian/tests/run-unit-test:
> line 53: 622 Segmentation fault DBstats -mdust G > result
> autopkgtest [05:31:24]: test run-unit-test: ---]
> autopkgtest [05:31:24]: test run-unit-test: - - - - - - - - - -
> results - - - - - - - - - -
> run-unit-testFAIL non-zero exit status 139
>
> The test log shows a segfault in DBstats. Further investigation in
> the upstream bug report shows this is caused by an invalid read which
> could already be detected with glibc 2.31, but did not crash.
As this is one of the blocker of the glibc 2.32 transition (the removal
from testing is only planned on October 20th), I have done an NMU to fix
the issue with the fix I suggested in the upstream BTS.
Please find the debdiff attached.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru dazzdb-1.0+git20201103.8d98c37/debian/changelog dazzdb-1.0+git20201103.8d98c37/debian/changelog
--- dazzdb-1.0+git20201103.8d98c37/debian/changelog 2021-01-19 10:02:03.0 +0100
+++ dazzdb-1.0+git20201103.8d98c37/debian/changelog 2021-09-14 20:53:44.0 +0200
@@ -1,3 +1,10 @@
+dazzdb (1.0+git20201103.8d98c37-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix a use-after-free in DBstats (Closes: #993770)
+
+ -- Aurelien Jarno Tue, 14 Sep 2021 20:53:44 +0200
+
dazzdb (1.0+git20201103.8d98c37-1) unstable; urgency=medium
* New upstream version
diff -Nru dazzdb-1.0+git20201103.8d98c37/debian/patches/series dazzdb-1.0+git20201103.8d98c37/debian/patches/series
--- dazzdb-1.0+git20201103.8d98c37/debian/patches/series 2021-01-19 10:02:03.0 +0100
+++ dazzdb-1.0+git20201103.8d98c37/debian/patches/series 2021-09-14 20:49:54.0 +0200
@@ -2,3 +2,4 @@
compiler-flags.patch
destdir.patch
cross.patch
+use-after-free.patch
diff -Nru dazzdb-1.0+git20201103.8d98c37/debian/patches/use-after-free.patch dazzdb-1.0+git20201103.8d98c37/debian/patches/use-after-free.patch
--- dazzdb-1.0+git20201103.8d98c37/debian/patches/use-after-free.patch 1970-01-01 01:00:00.0 +0100
+++ dazzdb-1.0+git20201103.8d98c37/debian/patches/use-after-free.patch 2021-09-14 20:49:57.0 +0200
@@ -0,0 +1,16 @@
+Description: fix a use-after-free causing a segmentation fault with glibc 2.32
+Author: Aurelien Jarno
+Forwarded: https://github.com/thegenemyers/DAZZ_DB/issues/41
+Last-Update: 2021-09-14
+
+--- dazzdb-1.0+git20201103.8d98c37.orig/DBstats.c
dazzdb-1.0+git20201103.8d98c37/DBstats.c
+@@ -346,8 +346,6 @@ int main(int argc, char *argv[])
+ }
+ }
+ printf("\n");
+-
+-Close_Track(db,track);
+ }
+ }
+
signature.asc
Description: PGP signature
Bug#994254: golang-github-gin-gonic-gin: FTBFS with Go 1.17
Package: golang-github-gin-gonic-gin
Version: 1.6.3-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch
Dear Maintainer,
Due to changes in net/http and multipart handling in Go 1.17, this package
currently FTBFS with Go 1.17. There is an upstream change that resolves
this failure, so I have pulled it in.
In Ubuntu, the attached patch was applied to achieve the following:
Successfully build the package with Go 1.17.
* Cherry Pick upstream patch that fixes FTBFS with Go 1.17
(LP: #1943630)
Thanks for considering the patch.
-- System Information:
Debian Release: bullseye/sid
APT prefers hirsute-updates
APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500,
'hirsute'), (100, 'hirsute-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.11.0-34-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
golang-github-gin-gonic-gin-1.6.3/debian/patches/0004-fix-test-failure-with-go-1.17.patch
golang-github-gin-gonic-gin-1.6.3/debian/patches/0004-fix-test-failure-with-go-1.17.patch
---
golang-github-gin-gonic-gin-1.6.3/debian/patches/0004-fix-test-failure-with-go-1.17.patch
1969-12-31 18:00:00.0 -0600
+++
golang-github-gin-gonic-gin-1.6.3/debian/patches/0004-fix-test-failure-with-go-1.17.patch
2021-09-13 13:52:01.0 -0500
@@ -0,0 +1,102 @@
+Description: Fix FTBFS with Go 1.17
+ Go 1.17 has multiple changes to mime/multipart and net/http that were causing
+ one of the build-time tests to panic rather than exit cleanly as expected.
+ See https://golang.org/doc/go1.17 for more information
+Origin: upstream,
https://github.com/gin-gonic/gin/commit/e4c026e2a101de574c480d390da41b91efb9490e
+Bug-Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/golang-github-gin-gonic-gin/+bug/1943630
+Applied-Upstream: https://github.com/gin-gonic/gin/pull/2856
+Last-Update: 2021-09-13
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- /dev/null
b/context_1.16_test.go
+@@ -0,0 +1,31 @@
++// Copyright 2021 Gin Core Team. All rights reserved.
++// Use of this source code is governed by a MIT style
++// license that can be found in the LICENSE file.
++
++//go:build !go1.17
++// +build !go1.17
++
++package gin
++
++import (
++ "bytes"
++ "mime/multipart"
++ "net/http"
++ "net/http/httptest"
++ "testing"
++
++ "github.com/stretchr/testify/assert"
++)
++
++func TestContextFormFileFailed16(t *testing.T) {
++ buf := new(bytes.Buffer)
++ mw := multipart.NewWriter(buf)
++ mw.Close()
++ c, _ := CreateTestContext(httptest.NewRecorder())
++ c.Request, _ = http.NewRequest("POST", "/", nil)
++ c.Request.Header.Set("Content-Type", mw.FormDataContentType())
++ c.engine.MaxMultipartMemory = 8 << 20
++ f, err := c.FormFile("file")
++ assert.Error(t, err)
++ assert.Nil(t, f)
++}
+--- /dev/null
b/context_1.17_test.go
+@@ -0,0 +1,33 @@
++// Copyright 2021 Gin Core Team. All rights reserved.
++// Use of this source code is governed by a MIT style
++// license that can be found in the LICENSE file.
++
++//go:build go1.17
++// +build go1.17
++
++package gin
++
++import (
++ "bytes"
++ "mime/multipart"
++ "net/http"
++ "net/http/httptest"
++ "testing"
++
++ "github.com/stretchr/testify/assert"
++)
++
++func TestContextFormFileFailed17(t *testing.T) {
++ buf := new(bytes.Buffer)
++ mw := multipart.NewWriter(buf)
++ mw.Close()
++ c, _ := CreateTestContext(httptest.NewRecorder())
++ c.Request, _ = http.NewRequest("POST", "/", nil)
++ c.Request.Header.Set("Content-Type", mw.FormDataContentType())
++ c.engine.MaxMultipartMemory = 8 << 20
++ assert.Panics(t, func() {
++ f, err := c.FormFile("file")
++ assert.Error(t, err)
++ assert.Nil(t, f)
++ })
++}
+--- a/context_test.go
b/context_test.go
+@@ -87,19 +87,6 @@
+ assert.NoError(t, c.SaveUploadedFile(f, "test"))
+ }
+
+-func TestContextFormFileFailed(t *testing.T) {
+- buf := new(bytes.Buffer)
+- mw := multipart.NewWriter(buf)
+- mw.Close()
+- c, _ := CreateTestContext(httptest.NewRecorder())
+- c.Request, _ = http.NewRequest("POST", "/", nil)
+- c.Request.Header.Set("Content-Type", mw.FormDataContentType())
+- c.engine.MaxMultipartMemory = 8 << 20
+- f, err := c.FormFile("file")
+- assert.Error(t, err)
+- assert.Nil(t, f)
+-}
+-
+ func TestContextMultipartForm(t *testing.T) {
+ buf := new(bytes.Buffer)
+ mw := multipart.NewWriter(buf)
diff -Nru golang-github-gin-gonic-gin-1.6.3/debian/patches/series
golan
Bug#994255: djangorestframework: autopkgtest needs update for new version of python-django: error changed
Source: djangorestframework
Version: 3.12.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, python-dja...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python-django
Dear maintainer(s),
With a recent upload of python-django the autopkgtest of
djangorestframework fails in testing when that autopkgtest is run with
the binary packages of python-django from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
python-django from testing2:3.2.7-4
djangorestframeworkfrom testing3.12.1-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing
I copied some of the output at the bottom of this report. It seems to me
that the error handling got improved.
Currently this regression is blocking the migration of python-django to
testing [1]. Of course, python-django shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in python-django was intended and your package needs to update to
the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from python-django should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
python-django/2:3.2.7-4. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=python-django
https://ci.debian.net/data/autopkgtest/testing/amd64/d/djangorestframework/15232622/log.gz
=== FAILURES
===
_
TestNaiveDayLightSavingTimeTimeZoneDateTimeField.test_invalid_inputs _
self =
def test_invalid_inputs(self):
"""
Ensure that invalid values raise the expected validation error.
"""
for input_value, expected_failure in get_items(self.invalid_inputs):
with pytest.raises(serializers.ValidationError) as exc_info:
self.field.run_validation(input_value)
> assert exc_info.value.detail == expected_failure, \
'input value: {}'.format(repr(input_value))
E AssertionError: input value: '2017-03-12T02:30:00'
E assert [ErrorDetail(...de='invalid')] == ['Invalid
dat...a/New_York".']
E At index 0 diff: ErrorDetail(string='Datetime has wrong
format. Use one of these formats instead:
-MM-DDThh:mm[:ss[.uu]][+HH:MM|-HH:MM|Z].', code='invalid') !=
'Invalid datetime for the timezone "America/New_York".'
E Use -v to get the full diff
OpenPGP_signature
Description: OpenPGP digital signature
Bug#994256: django-axes: autopkgtest needs update for new version of python-django: warnings changed
Source: django-axes
Version: 5.4.3-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, python-dja...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python-django
Dear maintainer(s),
With a recent upload of python-django the autopkgtest of django-axes
fails in testing when that autopkgtest is run with the binary packages
of python-django from unstable. It passes when run with only packages
from testing. In tabular form:
passfail
python-django from testing2:3.2.7-4
django-axesfrom testing5.4.3-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing
I copied some of the output at the bottom of this report. It seems to me
that some warnings were added and updated.
Currently this regression is blocking the migration of python-django to
testing [1]. Of course, python-django shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in python-django was intended and your package needs to update to
the new situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from python-django should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
python-django/2:3.2.7-4. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=python-django
https://ci.debian.net/data/autopkgtest/testing/amd64/d/django-axes/15232617/log.gz
=== FAILURES
===
_ CacheCheckTestCase.test_cache_check
__
self =
@override_settings(
AXES_HANDLER="axes.handlers.cache.AxesCacheHandler",
CACHES={
"default": {
"BACKEND": "django.core.cache.backends.db.DatabaseCache",
"LOCATION": "axes_cache",
}
},
)
def test_cache_check(self):
warnings = run_checks()
> self.assertEqual(warnings, [])
E AssertionError: Lists differ: [, id='models.W042'>
E
E Diff is 739 characters long. Set self.maxDiff to None to see it.
axes/tests/test_checks.py:21: AssertionError
_
CacheCheckTestCase.test_cache_check_does_not_produce_check_warnings_with_database_handler
_
self =
@override_settings(
AXES_HANDLER="axes.handlers.database.AxesDatabaseHandler",
CACHES={
"default": {"BACKEND":
"django.core.cache.backends.locmem.LocMemCache"}
},
)
def
test_cache_check_does_not_produce_check_warnings_with_database_handler(self):
warnings = run_checks()
> self.assertEqual(warnings, [])
E AssertionError: Lists differ: [, id='models.W042'>
E
E Diff is 739 characters long. Set self.maxDiff to None to see it.
axes/tests/test_checks.py:45: AssertionError
_ CacheCheckTestCase.test_cache_check_warnings
_
self =
@override_settings(
AXES_HANDLER="axes.handlers.cache.AxesCacheHandler",
CACHES={
"default": {"BACKEND":
"django.core.cache.backends.locmem.LocMemCache"}
},
)
def test_cache_check_warnings(self):
warnings = run_checks()
warning = Warning(
msg=Messages.CACHE_INVALID, hint=Hints.CACHE_INVALID,
id=Codes.CACHE_INVALID
)
> self.assertEqual(warnings, [warning])
E AssertionError: Lists differ: [, , id='models.W042'>
E
E Diff is 2408 characters long. Set self.maxDiff to None to see it.
axes/tests/test_checks.py:35: AssertionError
__ MiddlewareCheckTestCase.test_cache_check_warnings
___
self =
@modify_settings(MIDDLEWARE={"remove":
["axes.middleware.AxesMiddleware"]})
def test_cache_check_warnings(self):
warnings = run_checks()
warning = Warning(
msg=Messages.MIDDLEWARE_INVALID,
hint=Hints.MIDDLEWARE_INVALID,
id=Codes.MIDDLEWARE_INVALID,
)
> self.assertEqual(warnings, [warning])
E AssertionError: Lists differ: [, , id='models.W042'>
E
E Diff is 1320 characters long. Set self.maxDiff to None to see it.
axes/tests/test_checks.py:58: AssertionError
__ BackendCheckTestCase.test_backend_missing
___
self =
@modify_settings(AUTHENTI
Bug#994257: python-django breaks django-ldapdb autopkgtest: 'Field' object has no attribute 'attname'
Source: python-django, django-ldapdb
Control: found -1 python-django/2:3.2.7-4
Control: found -1 django-ldapdb/1.5.1-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of python-django the autopkgtest of django-ldapdb
fails in testing when that autopkgtest is run with the binary packages
of python-django from unstable. It passes when run with only packages
from testing. In tabular form:
passfail
python-django from testing2:3.2.7-4
django-ldapdb from testing1.5.1-2
versioned deps [0] from testingfrom unstable
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 python-django 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
[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
python-django/2:3.2.7-4. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=python-django
https://ci.debian.net/data/autopkgtest/testing/amd64/d/django-ldapdb/15232618/log.gz
==
ERROR: test_exists (examples.tests.GroupTestCase)
--
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.t2ql221m/downtmp/build.9e6/src/examples/tests.py",
line 280, in test_exists
self.assertTrue(qs.exists())
File "/usr/lib/python3/dist-packages/django/db/models/query.py", line
808, in exists
return self.query.has_results(using=self.db)
File "/usr/lib/python3/dist-packages/django/db/models/sql/query.py",
line 552, in has_results
return compiler.has_results()
File
"/tmp/autopkgtest-lxc.t2ql221m/downtmp/build.9e6/src/ldapdb/backends/ldap/compiler.py",
line 267, in has_results
next(iterator)
File
"/tmp/autopkgtest-lxc.t2ql221m/downtmp/build.9e6/src/ldapdb/backends/ldap/compiler.py",
line 246, in results_iter
if e[0].field.attname == 'dn':
AttributeError: 'Field' object has no attribute 'attname'
==
ERROR: test_and (ldapdb.tests.WhereTestCase)
--
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.t2ql221m/downtmp/build.9e6/src/ldapdb/tests.py",
line 240, in test_and
where.add(self._build_lookup("givenName", 'exact', "bar",
field=fields.CharField), AND)
File "/usr/lib/python3/dist-packages/django/utils/tree.py", line 93,
in add
if self.connector == conn_type and data in self.children:
File "/usr/lib/python3/dist-packages/django/db/models/lookups.py",
line 154, in __eq__
return self.identity == other.identity
File "/usr/lib/python3/dist-packages/django/db/models/expressions.py",
line 418, in __eq__
return other.identity == self.identity
File "/usr/lib/python3/dist-packages/django/utils/functional.py", line
48, in __get__
res = instance.__dict__[self.name] = self.func(instance)
File "/usr/lib/python3/dist-packages/django/db/models/expressions.py",
line 406, in identity
if value.name and value.model:
AttributeError: 'CharField' object has no attribute 'model'
==
FAIL: test_slice (examples.tests.GroupTestCase)
--
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.t2ql221m/downtmp/build.9e6/src/examples/tests.py",
line 405, in test_slice
self.assertEqual(objs.count(), 2)
AssertionError: 3 != 2
--
Ran 74 tests in 14.105s
FAILED (failures=1, errors=2)
OpenPGP_signature
Description: OpenPGP digital signature
Bug#988938: RM: 4store -- ROM; dead upstream
Hello Jonas, On Fri 21 May 2021 at 09:00PM +02, Jonas Smedegaard wrote: > Please drop source package 4store from Debian unstable. > > Upstream is dead: Last release was in 2015, source tracker saw no > changes since 2017, and issue tracker was last active in 2018. It doesn't appear to be buggy? Is it perhaps a security-sensitive package? Right now I'm not seeing reasons to remove. -- Sean Whitton signature.asc Description: PGP signature
Bug#988671: RM: acbuild -- RoQA; NPOASR; upstream discontinued 2 years ago
control: tag -1 + moreinfo Hello, On Tue 18 May 2021 at 01:53AM +08, Shengjing Zhu wrote: > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: z...@debian.org, only...@debian.org > > Hi, > > Please remove acbuild from unstable, upstream has discontinued its development > 2 years ago. Users can migrate to buildah[1]. > > [1] https://packages.debian.org/unstable/buildah Does Dmitry concur? The package doesn't seem to be buggy, so perhaps it could be useful to someone trying to get something to build? -- Sean Whitton signature.asc Description: PGP signature
Bug#972467: aom: Please package new upstream stable release (2.0.0)
X-Debbugs-CC: d...@jones.dk jcowg...@debian.org On Sun, 18 Oct 2020 17:21:21 -0400 Boyuan Yang wrote: > Source: aom > Severity: important > Version: 1.0.0.errata1-3 > Tags: sid > X-Debbugs-CC: jcowg...@debian.org > > Dear Debian libaom maintainers, > > There is a new upstream release for libaom (2.0.0). This new release > contains tons of fixes and new features and is needed by libavif. > Please consider packaging it. Now that Debian 11 is out, we are still stuck with aom 1.0 series. I believe it's worthwhile to work on pushing new aom into Debian. I will probably take a fresh start (i.e. use stock upstream source code and drop debian/patches/*) with experimental and later into unstable as team uploads, and add patches when needed. James: if you find any of these steps inappropriate, please let me know immediately. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#994258: python-django breaks lava autopkgtest: PASSWORD_RESET_TIMEOUT_DAYS/PASSWORD_RESET_TIMEOUT are mutually exclusive.
Source: python-django, lava Control: found -1 python-django/2:3.2.7-4 Control: found -1 lava/2020.12-5 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of python-django the autopkgtest of lava fails in testing when that autopkgtest is run with the binary packages of python-django from unstable. It passes when run with only packages from testing. In tabular form: passfail python-django from testing2:3.2.7-4 lava from testing2020.12-5 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. The error message suggests a misconfiguration, but the fact that the test passed until now suggests that python-django used to be more forgiving which isn't nice to give up. Currently this regression is blocking the migration of python-django 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 [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from python-django/2:3.2.7-4. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=python-django https://ci.debian.net/data/autopkgtest/testing/amd64/l/lava/15232624/log.gz lava-server manage migrate --noinput --fake-initial Traceback (most recent call last): File "/usr/bin/lava-server", line 68, in main() File "/usr/bin/lava-server", line 64, in main execute_from_command_line([sys.argv[0]] + options.command) File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 419, in execute_from_command_line utility.execute() File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 413, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 354, in run_from_argv self.execute(*args, **cmd_options) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 398, in execute output = self.handle(*args, **options) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 86, in wrapped saved_locale = translation.get_language() File "/usr/lib/python3/dist-packages/django/utils/translation/__init__.py", line 254, in get_language return _trans.get_language() File "/usr/lib/python3/dist-packages/django/utils/translation/__init__.py", line 57, in __getattr__ if settings.USE_I18N: File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 82, in __getattr__ self._setup(name) File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 69, in _setup self._wrapped = Settings(settings_module) File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 190, in __init__ raise ImproperlyConfigured( django.core.exceptions.ImproperlyConfigured: PASSWORD_RESET_TIMEOUT_DAYS/PASSWORD_RESET_TIMEOUT are mutually exclusive. OpenPGP_signature Description: OpenPGP digital signature
Bug#988709: RM: ooo-thumbnailer -- RoQA; orphaned, abandoned upstream
control: tag -1 + moreinfo Hello, On Tue 18 May 2021 at 04:00PM +02, Stephen Kitt wrote: > Please remove ooo-thumbnailer from unstable. It’s abandoned upstream > (see https://launchpad.net/ooo-thumbnailer), is orphaned in Debian, > and even though its last upstream release was made ten years ago, it > never even made it into Debian. It has a high popcon -- is there any evidence it doesn't work? -- Sean Whitton signature.asc Description: PGP signature
Bug#989005: RM: aewm -- RoQA; dead upstream; unmaintained; very low popcon
control: tag -1 + moreinfo
Hello,
On Sun 23 May 2021 at 08:55AM +02, Pino Toscano wrote:
> aewm has not seen a new upstream release since 2007, and upstream
> seems to have stopped working on it long long time ago.
> Furthermore:
> - the upstream website is not available anymore
> - I cannot find anywhere a potential repository that continues the
> development
> - it has been "maintained" in Debian with NMUs/QA uploads since 2011
> - uses old tech/libs (GTK+ 2)
> - it has a very low popcon count (38 at the time I'm writing this)
> - plenty of alternatives ("minimalist/lightweights" WMs) exist
>
> Hence, it looks to me it would be a better idea to simply remove aewm
> from Debian.
Is there any evidence it doesn't work?
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#990061: RM: libgaminggear -- ROM; depends on deprecated GTK 2 and obsolete
control: tag -1 + moreinfo Hello, On Sat 19 Jun 2021 at 12:23AM +02, Pierre-Elliott Bécue wrote: > I packaged libgaminggear because I was expecting to package roccat > tools. > > But roccat tools contains roccat licensed materials, and despite my > attempts to contact them, I never got any license allowing us to upload > this to nonfree, si it never approached debian at all. > > Now, libgaminggear depends on GTK 2 which is obsolete. > > I'd like to have libgaminggear removed from unstable and testing, as I > think it's of no real use anymore. Hmm, popcon is around 30 -- do you have any idea what those people might be doing with this lib? -- Sean Whitton signature.asc Description: PGP signature
Bug#992973: plib: CVE-2021-38714
Am Wed, Aug 25, 2021 at 09:23:37PM +0200 schrieb Salvatore Bonaccorso: > Source: plib > Version: 1.8.5-8 > Severity: grave > Tags: security upstream > Justification: user security hole > Forwarded: https://sourceforge.net/p/plib/bugs/55/ > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for plib. > > CVE-2021-38714[0]: > | In Plib through 1.85, there is an integer overflow vulnerability that > | could result in arbitrary code execution. The vulnerability is found > | in ssgLoadTGA() function in src/ssg/ssgLoadTGA.cxx file. > > The severity of the this bug is set op purpose higher as it is > probably warranted. There is the following reason for that: plib is > orphaned in Debian for a while, it is obsoleted and unmaintained > upstream as well. Ideally it get's removed from Debian from the next > release, but thee would be some revers dependencies issues to be > solved, making it imposssible for now to remove the package: > > | Checking reverse dependencies... > | # Broken Depends: > | crrcsim: crrcsim [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x] > | flightgear: flightgear > | openuniverse: openuniverse > | stormbaancoureur: stormbaancoureur > | torcs: torcs > | > | # Broken Build-Depends: > | crrcsim: libplib-dev > | flightgear: libplib-dev > | torcs: libplib-dev > | > | Dependency problem found. These are all games, which load their data from a trusted source/the deb (and plib is specifically a game lib). One option to fix this would be to simply disable SSG (a simple scene graph based on OpenGL), OpenSUSE did this by passing --enable-ssg=no --enable-ssgaux=no to the configure flags. I needs to be tested if any of the reverse deps need SSG, though. Cheers, Moritz
Bug#994259: resfinder: autopkgtest regression on armhf and i386: db_resfinder --kmaPath /usr/bin/kma' returned non-zero exit status 1
Source: resfinder Version: 4.1.5-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of resfinder the autopkgtest of resfinder fails in testing on armhf and i386 when that autopkgtest is run with the binary packages of resfinder from unstable. It passes when run with only packages from testing. In tabular form: passfail resfinder from testing4.1.5-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=resfinder https://ci.debian.net/data/autopkgtest/testing/armhf/r/resfinder/15226272/log.gz Indexing files as needed Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Done ['INSTALL.py'] Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Error: 0 (Success) Done ['INSTALL.py'] Running tests .E.E == ERROR: test_on_data_with_just_acquired_resgene_using_kma (__main__.ResFinderRunTest) -- Traceback (most recent call last): File "/tmp/autopkgtest-lxc.3mj3v4rg/downtmp/autopkgtest_tmp/functional_tests.py", line 151, in test_on_data_with_just_acquired_resgene_using_kma procs = run(cmd_acquired, shell=True, stdout=PIPE, stderr=PIPE, File "/usr/lib/python3.9/subprocess.py", line 528, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command 'run_resfinder.py -ifq data/test_isolate_01_1.fq data/test_isolate_01_2.fq -o running_test/test2 -s 'Escherichia coli' --min_cov 0.6 -t 0.8 --acquired --db_path_res /tmp/autopkgtest-lxc.3mj3v4rg/downtmp/autopkgtest_tmp/db_resfinder --kmaPath /usr/bin/kma' returned non-zero exit status 1. == ERROR: test_on_data_with_just_point_mut_using_kma (__main__.ResFinderRunTest) -- Traceback (most recent call last): File "/tmp/autopkgtest-lxc.3mj3v4rg/downtmp/autopkgtest_tmp/functional_tests.py", line 253, in test_on_data_with_just_point_mut_using_kma procs = run(cmd_acquired, shell=True, stdout=PIPE, stderr=PIPE, File "/usr/lib/python3.9/subprocess.py", line 528, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command 'run_resfinder.py -ifq data/test_isolate_05_1.fq data/test_isolate_05_2.fq -o running_test/test4 -s 'Escherichia coli' --min_cov 0.6 --threshold 0.8 --point --db_path_point /tmp/autopkgtest-lxc.3mj3v4rg/downtmp/autopkgtest_tmp/db_pointfinder --db_path_res /tmp/autopkgtest-lxc.3mj3v4rg/downtmp/autopkgtest_tmp/db_resfinder --kmaPath /usr/bin/kma' returned non-zero exit status 1. -- Ran 4 tests in 16.971s FAILED (errors=2) OpenPGP_signature Description: OpenPGP digital signature
Bug#994260: RFS: blop-lv2/1.0.2-1 [ITP] -- Bandlimited LADSPA Oscillator Plugins ported to LV2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "blop-lv2": * Package name : blop-lv2 Version : 1.0.2-1 Upstream Author : David Robillard * URL : https://drobilla.net/software/blop-lv2/ * License : GPL-3+, BSD-3-clause * Vcs : https://salsa.debian.org/multimedia-team/blop-lv2 Section : sound It builds those binary packages: blop-lv2 - Bandlimited LADSPA Oscillator Plugins ported to LV2 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/blop-lv2/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/blop-lv2/blop-lv2_1.0.2-1.dsc Changes for the initial release: blop-lv2 (1.0.2-1) unstable; urgency=medium . * Initial release (Closes: #981304) Best Regards, Dennis OpenPGP_signature Description: OpenPGP digital signature
Bug#992278: RM: neutron-fwaas-dashboard -- ROM; unmaintained upstream
control: tag -1 + moreinfo Hello zigo, On Mon 16 Aug 2021 at 06:53PM +02, Thomas Goirand wrote: > There's no FWaaS support in upstream OpenStack anymore. Please remove this > Horizon plugin from Debian. Just to confirm, it's not just that it's unmaintained but that it doesn't work, right? -- Sean Whitton signature.asc Description: PGP signature
Bug#988938: RM: 4store -- ROM; dead upstream
Quoting Sean Whitton (2021-09-14 21:23:13) > On Fri 21 May 2021 at 09:00PM +02, Jonas Smedegaard wrote: > > > Please drop source package 4store from Debian unstable. > > > > Upstream is dead: Last release was in 2015, source tracker saw no > > changes since 2017, and issue tracker was last active in 2018. > > It doesn't appear to be buggy? Is it perhaps a security-sensitive > package? Right now I'm not seeing reasons to remove. Well, if there are actual users I would tend to weigh in favor of keeping, but I am unaware of any. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#994261: ser2net: trace is wrong when read packets are combined
Package: ser2net
Version: 3.5-2
Severity: normal
Dear Maintainer,
I have been using ser2net to expose a device connected a serial port of
microPC.
As the original host application was showing some spurious errors on
large transfers,
I enabled tracelogs (see config below).
The tracelogs showed strange behaviour: On a certain command, the device
should have responded
with a sequence of 2 replies, but the tracelogs showed basically a
repeat of the first reply.
I assume this is due to the logging function looking at the beginning of
the to-be-sent buffer,
as the reply happened to include a \377 (which is the telnet escape
char) which was duplicated.
Excerpt from strace:
# command below should elicit a 2x5 byte response, starting with 0x35
0x1c and 0x35 0x1b
read(0, "5\32\350\0S", 64) = 5
write(2, "2021/09/14 14:27:18 tcp 35 1a e8 00 53 |5...S|\n",
58) = 58
write(1, "5\32\350\0S", 5) = 5
# so far correct
read(1, "5\34\377\377S", 32) = 5
write(2, "2021/09/14 14:27:18 term 35 1c ff ff 53 |5...S|\n",
58) = 58
# device answers, first packet, logging is correct
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=21545, si_uid=0} ---
read(1, "5\33\0\4S", 28) = 5
write(2, "2021/09/14 14:27:18 term 35 1c ff ff ff |5|\n",
58) = 58
# device answers, second packet. Logging is wrong. Should be 35 1b 00 04 53
# note that we actually see the first packet, and the last 53 is
replaced by ff
# I assume this is due to the already-escaped buffer below being logged
from the
# beginning:
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=21545, si_uid=0} ---
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=21545, si_uid=0} ---
write(0, "5\34\377\377\377\377S5\33\0\4S", 12) = 12
# both answers go over the network in one packet, doubling the \377 = ff
is correct due to telnet escape rules
Unfortunately cannot update the microPC to stable to verify this is not
in the most recent version.
Functionality of the packet is not affected, but it cost me several
hours of debugging time to find the
logging is incorrect, as opposed to the device malfunctioning.
Thanks for your efforts,
Andreas Beck
-- System Information:
Debian Release: 10.10
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ser2net depends on:
ii libc6 2.28-10
ii libwrap0 7.6.q-28
ii lsb-base 10.2019051400
ser2net recommends no packages.
Versions of packages ser2net suggests:
ii telnet 0.17-41.2
-- Configuration Files:
/etc/ser2net.conf changed:
BANNER:banner:\r\nser2net port \p device \d [\s] (Debian GNU/Linux)\r\n\r\n
TRACEFILE:trace:/tmp/ser2net\p.log
4711:telnet:600:/dev/ttyUSB0:38400 8DATABITS NONE 1STOPBIT tb=trace
hexdump timestamp
4712:telnet:600:/dev/pts/0:38400 8DATABITS NONE 1STOPBIT tb=trace
hexdump timestamp
-- no debconf information
Bug#994262: squashfs-tools: CVE-2021-41072
Source: squashfs-tools Version: 1:4.5-2 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 1:4.4-2+deb11u1 Control: found -1 1:4.4-2 Control: found -1 1:4.3-12+deb10u1 Control: found -1 1:4.3-12 Hi, The following vulnerability was published for squashfs-tools. CVE-2021-41072[0]: | squashfs_opendir in unsquash-2.c in Squashfs-Tools 4.5 allows | Directory Traversal, a different vulnerability than CVE-2021-40153. A | squashfs filesystem that has been crafted to include a symbolic link | and then contents under the same filename in a filesystem can cause | unsquashfs to first create the symbolic link pointing outside the | expected directory, and then the subsequent write operation will cause | the unsquashfs process to write through the symbolic link elsewhere in | the filesystem. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-41072 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41072 [1] https://github.com/plougher/squashfs-tools/commit/e0485802ec72996c20026da320650d8362f555bd [2] https://github.com/plougher/squashfs-tools/commit/19fcc9365dcdb2c22d232d42d11012940df64b7c (Makefile fix) [3] https://github.com/plougher/squashfs-tools/issues/72#issuecomment-913833405 Regards, Salvatore
Bug#994263: RM: ruby-rexml/experimental -- ROM; duplicate package, included in libruby2.7
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: car...@debian.org,prav...@onenetbeyond.org As ruby-rexml was removed from unstable the same reason applies as well for the experimental upload as for #987101. Can you remove ruby-rexml as well from experimental? Regards, Salvatore
Bug#994264: tex-common fails configuration (fmtutil failed) after texlive installation
Package: tex-common
Version: 6.16
Severity: normal
Dear Maintainer,
After installing texlive, apt shows the following:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LC_TIME = "en_ZA.UTF-8",
LC_MONETARY = "en_US.UTF-8",
LC_ADDRESS = "en_GB.UTF-8",
LC_TELEPHONE = "en_GB.UTF-8",
LC_NAME = "en_GB.UTF-8",
LC_MEASUREMENT = "en_ZA.UTF-8",
LC_IDENTIFICATION = "en_GB.UTF-8",
LC_NUMERIC = "en_GB.UTF-8",
LC_PAPER = "en_GB.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up tex-common (6.16) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.DCKXFCvl
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
tex-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
The output file /tmp/fmtutil.DCKXFCvl is long; I've attached the full file, but
the lines which are showing errors are as follows:
fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/metafont/mf.log
fmtutil [INFO]: /var/lib/texmf/web2c/metafont/mf.base installed.
fmtutil [ERROR]: running `luahbtex -ini -jobname=luahbtex -progname=luahbtex
luatex.ini
Versions of packages texlive-base depends on:
ii debconf [debconf-2.0] 1.5.77
ii libpaper-utils 1.1.28+b1
ii sensible-utils 0.0.14
ii texlive-binaries 2020.20200327.54578-7
ii ucf3.0043
ii xdg-utils 1.1.3-4.1
Versions of packages texlive-base recommends:
ii lmodern 2.004.5-6.1
Versions of packages texlive-base suggests:
ii ghostscript [postscript-viewer] 9.53.3~dfsg-7+deb11u1
ii okular [postscript-viewer] 4:20.12.3-2
ii perl-tk 1:804.035-0.1+b1
pn xpdf | pdf-viewer
pn xzdec
Versions of packages texlive-binaries depends on:
ii dpkg1.20.9
ii install-info6.7.0.dfsg.2-6
ii libc6 2.31-13
ii libcairo2 1.16.0-5
ii libfontconfig1 2.13.1-4.2
ii libfreetype62.10.4+dfsg-1
ii libgcc-s1 10.2.1-6
ii libgraphite2-3 1.3.14-1
ii libharfbuzz0b 2.7.4-1
ii libicu6767.1-7
ii libkpathsea62020.20200327.54578-7
ii libmpfr64.1.0-3
ii libpaper1 1.1.28+b1
ii libpixman-1-0 0.40.0-1
ii libpng16-16 1.6.37-3
ii libptexenc1 2020.20200327.54578-7
ii libstdc++6 10.2.1-6
ii libsynctex2 2020.20200327.54578-7
ii libteckit0 2.5.10+ds1-3
ii libtexlua53 2020.20200327.54578-7
ii libtexluajit2 2020.20200327.54578-7
ii libx11-62:1.7.2-1
ii libxaw7 2:1.0.13-1.1
ii libxi6 2:1.7.10-1
ii libxmu6 2:1.1.2-2+b3
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.2.0-1
ii libzzip-0-130.13.62-3.3
ii perl5.32.1-4+deb11u1
ii t1utils 1.41-4
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages texlive-binaries recommends:
ii dvisvgm 2.11.1-1
ii texlive-base 2020.20210202-3
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LC_TIME = "en_ZA.UTF-8",
LC_MONETARY = "en_US.UTF-8",
LC_ADDRESS = "en_GB.UTF-8",
LC_TELEPHONE = "en_GB.UTF-8",
LC_NAME = "en_GB.UTF-8",
LC_MEASUREMENT = "en_ZA.UTF-8",
LC_IDENTIFICATION = "en_GB.UTF-8",
LC_NUMERIC = "en_GB.UTF-8",
LC_PAPER = "en_GB.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil: /usr/share/texmf/web2c/fmtutil.cnf
fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil: /etc/texmf/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
fmtutil [INFO]: --- remaking luatex with luatex
fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ...
Unable to read environment locale: exit now.
fmtutil [INFO]: --- re
Bug#994265: pypy breaks python-virtualenv autopkgtest on ppc64el: RuntimeError: maximum recursion depth exceeded
Source: pypy, python-virtualenv Control: found -1 pypy/7.3.5+dfsg-2 Control: found -1 python-virtualenv/20.4.0+ds-2 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of pypy the autopkgtest of python-virtualenv fails in testing on ppc64el when that autopkgtest is run with the binary packages of pypy from unstable. It passes when run with only packages from testing. In tabular form: passfail pypy from testing7.3.5+dfsg-2 python-virtualenv from testing20.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 of pypy 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=pypy https://ci.debian.net/data/autopkgtest/testing/ppc64el/p/python-virtualenv/15222817/log.gz File "/usr/lib/pypy/lib-python/2.7/sre_parse.py", line 701, in _parse p = _parse_sub(source, state, nested + 1) File "/usr/lib/pypy/lib-python/2.7/sre_parse.py", line 349, in _parse_sub itemsappend(_parse(source, state, nested + 1)) File "/usr/lib/pypy/lib-python/2.7/sre_parse.py", line 701, in _parse p = _parse_sub(source, state, nested + 1) File "/usr/lib/pypy/lib-python/2.7/sre_parse.py", line 349, in _parse_sub itemsappend(_parse(source, state, nested + 1)) File "/usr/lib/pypy/lib-python/2.7/sre_parse.py", line 422, in _parse subpattern = SubPattern(state) File "/usr/lib/pypy/lib-python/2.7/sre_parse.py", line 99, in __init__ def __init__(self, pattern, data=None): RuntimeError: maximum recursion depth exceeded ASSERT:Execute bare pip testSystemPackagesNotAvailable Traceback (most recent call last): File "", line 1, in ImportError: No module named six DEPRECATION: pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality. testSystemPackagesAvailable DEPRECATION: pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality. testSetuptoolsAvailable Ran 4 tests. FAILED (failures=1) OpenPGP_signature Description: OpenPGP digital signature
Bug#994266: pyjwt breaks azure-cli autopkgtest: Could not deserialize key data. The data may be in an incorrect format or it may be encrypted with an unsupported algorithm.
Source: pyjwt, azure-cli
Control: found -1 pyjwt/2.1.0-1
Control: found -1 azure-cli/2.18.0-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of pyjwt the autopkgtest of azure-cli fails in
testing when that autopkgtest is run with the binary packages of pyjwt
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
pyjwt from testing2.1.0-1
azure-cli from testing2.18.0-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 of pyjwt 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=pyjwt
https://ci.debian.net/data/autopkgtest/testing/amd64/a/azure-cli/15220083/log.gz
=== FAILURES
===
_ TestProfile.test_find_subscriptions_in_cloud_console
_
self = , key = b''
def prepare_key(self, key):
if isinstance(key, RSAPrivateKey) or isinstance(key, RSAPublicKey):
return key
if isinstance(key, (bytes, str)):
key = force_bytes(key)
try:
if key.startswith(b"ssh-rsa"):
key = load_ssh_public_key(key)
else:
> key = load_pem_private_key(key, password=None)
/usr/lib/python3/dist-packages/jwt/algorithms.py:256:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
data = b'', password = None
backend =
def load_pem_private_key(data, password, backend=None):
backend = _get_backend(backend)
> return backend.load_pem_private_key(data, password)
/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/serialization/base.py:18:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self =
data = b'', password = None
def load_pem_private_key(self, data, password):
> return self._load_key(
self._lib.PEM_read_bio_PrivateKey,
self._evp_pkey_to_private_key,
data,
password,
)
/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/backend.py:1244:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self =
openssl_read_func =
convert_func = >
data = b'', password = None
def _load_key(self, openssl_read_func, convert_func, data, password):
mem_bio = self._bytes_to_bio(data)
userdata = self._ffi.new("CRYPTOGRAPHY_PASSWORD_DATA *")
if password is not None:
utils._check_byteslike("password", password)
password_ptr = self._ffi.from_buffer(password)
userdata.password = password_ptr
userdata.length = len(password)
evp_pkey = openssl_read_func(
mem_bio.bio,
self._ffi.NULL,
self._ffi.addressof(
self._lib._original_lib, "Cryptography_pem_password_cb"
),
userdata,
)
if evp_pkey == self._ffi.NULL:
if userdata.error != 0:
self._consume_errors()
if userdata.error == -1:
raise TypeError(
"Password was not given but private key is
encrypted"
)
else:
assert userdata.error == -2
raise ValueError(
"Passwords longer than {} bytes are not supported "
"by this backend.".format(userdata.maxsize - 1)
)
else:
> self._handle_key_loading_error()
/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/backend.py:1475:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self =
def _handle_key_loading_error(self):
errors = self._consume_errors()
if not errors:
raise ValueError(
"Could not deserialize key data. The data may be in an "
"incorrect format or it may be encrypted with an
unsupported "
"algorithm."
)
elif errors[0]._lib_reason_match(
self._lib.ERR_LIB_EVP, self._lib.EVP_R_BAD_DECRYPT
) or errors[0]._lib_reason_match(
self._lib.ERR_LIB_PKCS12,
self._lib.PKCS12_R_PKCS12_CIPHERFINAL_ERROR,
):
raise ValueError("Bad decrypt. Incorrect password?
