Bug#992605: libifd-cyberjack6: uses non-existing group pcscd in udev rules
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530
Bug#993864: ITP: taskserver -- taskwarrior synchronisation server
Hi Mattia, On Monday, September 20th, 2021 at 12:39, Mattia Rizzolo wrote: > Hi, > > On Tue, Sep 07, 2021 at 09:24:51AM -0300, Sergio de Almeida Cipriano Junior > wrote: > > > - 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. > > AFAIK that's: https://tracker.debian.org/pkg/taskd which became quite a > > bit abandonend over time. however I'd be interested in reviving it. After talking to Gordon, I started making some changes to the package so it could get back to testing. I haven't uploaded these changes to the main repository yet, but I plan to. > Did the previous domain get taken over by somebody else?! I think so, it is now under the same domain as taswarrior [1]. > I drifted away from the project, but it wouldn't be bad to start on it > > again. Your help would be very welcome. Could you review and sponsor the package when the changes are ready? [1]: https://taskwarrior.org/ -- Regards, Sergio Cipriano.
Bug#424620: reopen / Re: Bug#424620: marked as done (mailman: error.log not re-opened on log rotation)
reopen 424620 thanks was closed by spammer
Bug#994839: ch-upgrading.en.html#sufficient-space: a suggestion.
On Ma, 21 sep 21, 19:41:25, Brian Potkin wrote: > > At > > > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#sufficient-space > > steps 1, 2 and 3 for using a temporary /var/cache/apt/archives work > fine for me. At step 4 I do 'mount' and get > > /dev/sdc1 on /media/usbkeys type ext4 (rw,relatime) > /dev/sdc1 on /var/cache/apt/archives type ext4 (rw,relatime) > > It would seem to me that step 4 should be advising > > umount /var/cache/apt/archives Yes, this would be the correct command. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#994151: youtube-dl: the youtube-dl project seams to have died
Hi, On Thu, Sep 16, 2021 at 03:47:11PM +, okgomdjgbm...@gmail.com wrote: > > I'm not very familiar with Debian's packaging rules I injected yt-dlp into Salsa: https://salsa.debian.org/debian/yt-dlp you can try to build it and test it locally. > Do what you think is best. It is definitely not best if I maintain another package alone. > youtube-dl is not just for youtube, > other sites get constantly fixed or added > And now there's no activity since the 1 of July. > Waiting for youtube to brake is a bit too conservative. > You can also see a declining activity over time. > The forks got created because of this declining activity. I repeat: Why do people forking instead of joining. Did anybody of the people who started the fork considered to contribute to the original first? What about merging the changes of the fork into original youtube-dl? > That they made no statement whatsoever is more concerning > then reassuring. > > Given their hum... toxic attitude, it's unlikely they'll > do any statement. It's practically certain, they will never > clearly say that the project is dead. Who has a toxic attitude and where is the proof for this statement? Kind regards Andreas. -- http://fam-tille.de
Bug#994859: tmispell-voikko FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]
Source: tmispell-voikko Version: 0.7.1-4 Severity: serious Tags: ftbfs tmispell-voikko fails to build from source in unstable on amd64. A build ends as follows: | x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -MT cursesui.o -MD -MP -MF .deps/cursesui.Tpo -c -o cursesui.o `test -f 'ui/cursesui.cc' || echo './'`ui/cursesui.cc | ui/cursesui.cc: In member function ‘void CursesInterface::Pimpl::redraw_minimenu()’: | ui/cursesui.cc:199:41: error: format not a string literal and no format arguments [-Werror=format-security] | 199 | "e(X)it or ? for help")).c_str()); | | ^ | cc1plus: some warnings being treated as errors | make[3]: *** [Makefile:458: cursesui.o] Error 1 | make[3]: Leaving directory '/<>/src' | make[2]: *** [Makefile:292: all] Error 2 | make[2]: Leaving directory '/<>/src' | make[1]: *** [Makefile:368: all-recursive] Error 1 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:31: build-stamp] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 I suspect this is due to ncurses having acquired format string annotations. We've had a pile of similar bugs in curses users. Helmut
Bug#994858: libglib2.0-0: After upgrade to 2.70.0-1, broken nextcloud-desktop
Package: libglib2.0-0 Version: 2.68.4-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** After upgrade from 2.68.4-1 to 2.70.0-1, nextcloud-desktop cannot work anymore, rollback to 2.68.4-1 fixed problem. * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) 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=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libglib2.0-0 depends on: ii libc62.32-4 ii libffi7 3.3-6 ii libmount12.37.2-2 ii libpcre3 2:8.39-13 ii libselinux1 3.1-3 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages libglib2.0-0 recommends: pn libglib2.0-data ii shared-mime-info 2.0-1 ii xdg-user-dirs 0.17-2 libglib2.0-0 suggests no packages. -- no debconf information
Bug#994857: iwatch: Fails to send sendxmpp
Package: iwatch Version: 0.2.2-9 Severity: important Hello, I'm setting up sending xmpp in a test environment and realized that: 1) Running iwatch from the system, sending xmpp does not happen. root@debian11:/var/log# /etc/init.d/iwatch status ● iwatch.service - realtime filesystem monitoring program using inotify Loaded: loaded (/lib/systemd/system/iwatch.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2021-09-21 23:26:11 -03; 4min 2s ago Docs: man:iwatch Process: 537 ExecStart=/usr/bin/iwatch -f $CONFIG_FILE -p /run/iwatch.pid -d (code=exited, status=0/SUCCESS) Main PID: 690 (iwatch) Tasks: 1 (limit: 1133) Memory: 23.3M CPU: 169ms CGroup: /system.slice/iwatch.service └─690 /usr/bin/perl -T /usr/bin/iwatch -f /etc/iwatch/iwatch.xml -p /run/iwatch.pid -d set 21 23:26:10 debian11 systemd[1]: Starting realtime filesystem monitoring program using inotify... set 21 23:26:11 debian11 systemd[1]: Started realtime filesystem monitoring program using inotify. set 21 23:26:11 debian11 su[890]: (to nobody) root on none set 21 23:26:11 debian11 su[890]: pam_unix(su:session): session opened for user nobody(uid=65534) by (uid=0) set 21 23:26:12 debian11 su[890]: pam_unix(su:session): session closed for user nobody 2) Running the same command line shown above with "/etc/init.d/iwatch status", removing the daemon "-d" parameter and inserting the verbose "-v" parameter, the send works. Without changing anything in the configuration file. root@debian11:/var/log# /usr/bin/perl -T /usr/bin/iwatch -f /etc/iwatch/iwatch.xml -p /run/iwatch.pid -v Watch /bin Watch /sbin Watch /etc Watch /lib Watch /tmp [21/set/2021 23:31:45] IN_CREATE /tmp/2 [21/set/2021 23:31:45] * Command: (echo iWatch: IN_CREATE /tmp/2;w;ps -ef)|sendxmpp -t user@example [21/set/2021 23:31:45] * Send email to root@localhost [21/set/2021 23:31:49] IN_CLOSE_WRITE /tmp/2 [21/set/2021 23:31:49] * /tmp/2 is closed [21/set/2021 23:31:49] * Command: (echo iWatch: IN_CLOSE_WRITE /tmp/2;w;ps -ef)|sendxmpp -t user@example [21/set/2021 23:31:49] * Send email to root@localhost Regards -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iwatch depends on: ii exim4-daemon-light [mail-transport-agent] 4.94.2-7 ii init-system-helpers1.60 ii libevent-perl 1.27-1+b2 ii liblinux-inotify2-perl 1:2.2-2+b1 ii libmail-sendmail-perl 0.80-1.1 ii libxml-simpleobject-libxml-perl0.53-3 ii lsb-base 11.1.0 ii perl 5.32.1-4+deb11u1 iwatch recommends no packages. Versions of packages iwatch suggests: ii sendxmpp1.24-3 pn yowsup-cli -- Configuration Files: /etc/iwatch/iwatch.xml changed: Operating System /bin /sbin /etc /lib /lib/modules Apenas um teste /tmp -- no debconf information
Bug#862714: From Mrs. Ameena Essa.
-- Hello, How are you doing today? I sent you an email yesterday, did you receive it? It is a very important message, anyway reply back to confirm that you already got my message to enable me to give you more details.. Best Regards. Mrs. Ameena Essa
Bug#994856: ITP: harmonpy -- An algorithm to help integrate high-dimensional datasets
Package: wnpp Severity: wishlist Owner: Diane Trout X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: harmonpy Version : 0.0.5 Upstream Author : Kamil Slowikowski * URL : https://github.com/slowkow/harmonypy * License : GPL-3+ Programming Lang: Python Description : An algorithm to help integrate high-dimensional datasets Harmony is an algorithm for integrating multiple high-dimensional datasets. . harmonypy is a port of the harmony R package by Ilya Korsunsky. Harmonypy is a package to help integrate high-dimentional datasets, such as found while doing single-cell RNA-seq. The popular bionformatics package Scanpy can use harmonypy for helping integrate multiple datatypes, and some of the scanpy tests require harmonpy to run. As a bioinformatics package it pretty clearly belongs with the debian-med team. Diane Trout
Bug#994855: zfs-dkms: Panic when receiving, fixed upstream
Package: zfs-dkms Version: 2.0.3-9 Severity: grave Tags: patch upstream Justification: causes non-serious data loss With this latest version of the debian package, I've been getting panics receiving datasets. There's a patch already merged upstream. The errors are: VERIFY3(insert_inode_locked(ip) == 0) failed (-16 == 0) PANIC at zfs_znode.c:616:zfs_znode_alloc() The patch is at https://github.com/openzfs/zfs/commit/afa7b3484556d3ae610a34582ce5ebd2c3e27bba Please cherrypick this and add it soon. -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (700, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/32 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages zfs-dkms depends on: ii debconf [debconf-2.0] 1.5.77 ii dkms 2.8.4-3 ii file 1:5.39-3 ii libc6-dev [libc-dev] 2.31-13 ii libpython3-stdlib 3.9.2-3 ii lsb-release11.1.0 ii perl 5.32.1-4 ii python3-distutils 3.9.2-1 Versions of packages zfs-dkms recommends: ii linux-libc-dev 5.10.46-4 ii zfs-zed 2.0.3-9 ii zfsutils-linux 2.0.3-9 Versions of packages zfs-dkms suggests: ii debhelper 13.3.4 -- debconf information excluded >From afa7b3484556d3ae610a34582ce5ebd2c3e27bba Mon Sep 17 00:00:00 2001 From: Paul Zuchowski <31706010+paulz...@users.noreply.github.com> Date: Fri, 11 Jun 2021 20:00:33 -0400 Subject: [PATCH] Do not hash unlinked inodes In zfs_znode_alloc we always hash inodes. If the znode is unlinked, we do not need to hash it. This fixes the problem where zfs_suspend_fs is doing zrele (iput) in an async fashion, and zfs_resume_fs unlinked drain processing will try to hash an inode that could still be hashed, resulting in a panic. Reviewed-by: Brian Behlendorf Reviewed-by: Alan Somers Signed-off-by: Paul Zuchowski Closes #9741 Closes #11223 Closes #11648 Closes #12210 --- module/os/linux/zfs/zfs_znode.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) Index: zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c === --- zfs-linux-2.0.3.orig/module/os/linux/zfs/zfs_znode.c +++ zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c @@ -610,17 +610,24 @@ zfs_znode_alloc(zfsvfs_t *zfsvfs, dmu_bu * number is already hashed for this super block. This can never * happen because the inode numbers map 1:1 with the object numbers. * -* The one exception is rolling back a mounted file system, but in -* this case all the active inode are unhashed during the rollback. +* Exceptions include rolling back a mounted file system, either +* from the zfs rollback or zfs recv command. +* +* Active inodes are unhashed during the rollback, but since zrele +* can happen asynchronously, we can't guarantee they've been +* unhashed. This can cause hash collisions in unlinked drain +* processing so do not hash unlinked znodes. */ - VERIFY3S(insert_inode_locked(ip), ==, 0); + if (links > 0) + VERIFY3S(insert_inode_locked(ip), ==, 0); mutex_enter(>z_znodes_lock); list_insert_tail(>z_all_znodes, zp); zfsvfs->z_nr_znodes++; mutex_exit(>z_znodes_lock); - unlock_new_inode(ip); + if (links > 0) + unlock_new_inode(ip); return (zp); error: >From afa7b3484556d3ae610a34582ce5ebd2c3e27bba Mon Sep 17 00:00:00 2001 From: Paul Zuchowski <31706010+paulz...@users.noreply.github.com> Date: Fri, 11 Jun 2021 20:00:33 -0400 Subject: [PATCH] Do not hash unlinked inodes In zfs_znode_alloc we always hash inodes. If the znode is unlinked, we do not need to hash it. This fixes the problem where zfs_suspend_fs is doing zrele (iput) in an async fashion, and zfs_resume_fs unlinked drain processing will try to hash an inode that could still be hashed, resulting in a panic. Reviewed-by: Brian Behlendorf Reviewed-by: Alan Somers Signed-off-by: Paul Zuchowski Closes #9741 Closes #11223 Closes #11648 Closes #12210 --- module/os/linux/zfs/zfs_znode.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) Index: zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c === --- zfs-linux-2.0.3.orig/module/os/linux/zfs/zfs_znode.c +++ zfs-linux-2.0.3/module/os/linux/zfs/zfs_znode.c @@ -610,17 +610,24 @@ zfs_znode_alloc(zfsvfs_t *zfsvfs, dmu_bu * number is already hashed for this super block. This can never * happen because the inode numbers map 1:1 with the object numbers. * -* The
Bug#994826: synfig: diff for NMU version 1.4.0+dfsg-2.1
On Tuesday, 21 September 2021 10:34:48 PM AEST Jonas Smedegaard wrote: > I've prepared an NMU for synfig (versioned as 1.4.0+dfsg-2.1) and > uploaded it without delay (as it involved an RC bug). Many thanks for your help, Jonas. -- Regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- If you are out to describe the truth, leave elegance to the tailor. -- Albert Einstein --- And how long a lockdown is enough? If we open now, will lockdown recur in autumn? Next year? Whenever authoritarianism so wishes? No dictatorship could imagine a better precedent for absolute control. -- https://www.bmj.com/content/369/bmj.m1924.long :: BMJ 2020;369:m1924 "Should governments continue lockdown to slow the spread of covid-19?" signature.asc Description: This is a digitally signed message part.
Bug#994151: red flags
That's part of the red flags i was trying to tell you. They could have added more maintainers years ago, but they didn't. It's almost 3 months now without a commit and even now still no new maintainer.This is why they forked it. This is not new, this is why they are 800 open PRs that accumulated over years. The project is in serious neglect, yet they are no shortage of willing volunteers. Your guess on what is going through their heads, is as good as mine. This is why i'm saying it's dead. And this is why i called this bug grave, because it's upstream it self that is dead, it's not just a technical issue. It will require packaging a fork, the proposed yt-dlp. Even if it came back to life the general state of neglect will almost certainly continue.
Bug#994854: repro fails to parse some control files
Package: python3-debian
Version: 0.1.41
Severity: normal
The deb822_repro module struggles to parse the control file in
https://salsa.debian.org/go-team/packages/golang-github-suapapa-go-eddystone.git:
...
File
"/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
line 2951, in parse_deb822_file
raise ValueError('Syntax or Parse error on the line:
"{error_as_text}"'.format(
ValueError: Syntax or Parse error on the line: ", dh-golang\n ,
golang-any\n , golang-github-paypal-gatt-dev\n ,
golang-github-google-uuid-dev\n"
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 python3-debian depends on:
ii python3 3.9.2-3
ii python3-chardet 4.0.0-1
ii python3-six 1.16.0-2
Versions of packages python3-debian recommends:
ii python3-apt 2.2.1
Versions of packages python3-debian suggests:
ii gpgv 2.2.27-2
-- no debconf information
Bug#993003: hydroffice.bag: tests fail with h5py 3
Source: hydroffice.bag Followup-For: Bug #993003 Upstream reports (moving the upstream bug to https://github.com/hydroffice/hyo2_bag/issues/1 ) that hyo.bag is deprecated, superseded by hyo2.bag, which has a separate repository at https://github.com/hydroffice/hyo2_bag Current latest release is 1.1.2 -- 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#994853: buster-pu: package proftpd-dfsg/1.3.6-4+deb10u6
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Dear release managers, [ Reason ] Theses issues were found in the 1.3.6 line of the proftp server and fixed in later versions of proftp. The patches solve a few annyoing issues and hence should make it into oldstable. [ Impact ] The version solves at least one crash issue: "mod_sftp crash when using pubkey-auth with DSA keys": This should be a good reason to accept the patch. [ Tests ] All changes were uploaded to Debian (un)stable and tested there. The patches were adapted to the 1.3.6 line of the proftp server. Patch for #993173 and #971742 were tested by the submitter and confirmed that they solves the issue. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable Debdiff is here: [1] [X] the issue is verified as fixed in (un)stable For any reason [2] reports "Not yet fixed in unstable". This is not correct, the patches were (latest) introduced in 1.3.7c. Hilmar [1] https://release.debian.org/proposed-updates/buster_diffs/proftpd-dfsg_1.3.6-4+deb10u6.debdiff [2] https://release.debian.org/proposed-updates/oldstable.html
Bug#917103: dh_elpa_test: test bytecompilability
Hello, On Tue 21 Sep 2021 at 01:26PM -03, David Bremner wrote: > Sean Whitton writes: > >> Hello, >> >> On Mon 20 Sep 2021 at 11:24AM -03, David Bremner wrote: >> >>> By the way, I realized that autopkgtest is already testing byte >>> compilation, even for tests disabled via debian/elpa-test. Maybe that's >>> enough, what do you think? >> >> Could you say more? How exactly is it testing it? >> > > As long as Testsuite: autopkgtest-pkg-elpa is present in debian/control, > the binary packages are installed and hence byte compiled. Until the > upload 20210916git0-2, racket-mode [1] had this configuration with > Testsuite defined, but disabled in debian/elpa-test. > > [1]: > https://ci.debian.net/data/autopkgtest/testing/amd64/r/racket-mode/15323474/log.gz Oh great, and if that installation fails the autopkgtest is considered to fail? -- Sean Whitton signature.asc Description: PGP signature
Bug#994852: RFS: streamlink/2.4.0-1 -- CLI for extracting video streams from various websites to a video player
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "streamlink" for a new upstream version 2.4.0. * Package name: streamlink Version : 2.4.0-1 Upstream Author : Streamlink Team * URL : https://streamlink.github.io/ * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1 Section : python It builds those binary packages: python3-streamlink - Python module for extracting video streams from various websites python3-streamlink-doc - CLI for extracting video streams from various websites (documentation) streamlink - CLI for extracting video streams from various websites to a video player To access further information about this package, please visit the following URL: https://mentors.debian.net/package/streamlink Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_2.4.0-1.dsc Changes since the last upload to unstable: streamlink (2.4.0-1) unstable; urgency=medium * New upstream version 2.4.0 * Update patches * d/control: add new dependency on python3-lxml * Bump Standards-Version to 4.6.0 (no changes) * d/tests/check_docs: fix looking for doc-base files by using install-docs * d/tests/check_docs.sh: check for broken symlinks * Merge changes in experimental to unstable -- Alexis Murzeau Tue, 21 Sep 2021 21:35:26 +0200 Regards, -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#994825: Me Too
#!/usr/bin/env bash
# It probably does a lot more than it needs to... but I tried re-compiling sssd
# from source just in case that was the issue.
#
# Note that it deletes files in /var/lib/sss/db, and removing cache files will
# also remove all of your cached credentials.
TEMPDIR=$(mktemp -d)
chown _apt:root ${TEMPDIR}
cd ${TEMPDIR}
echo "Download source package for SSSD: "
apt-get source sssd
PACKAGES=($(cat sssd-*/debian/control | grep Package | awk '{print $2}'))
declare -a INSTALLED
declare -a HOLD
for PACKAGE in ${PACKAGES[@]}; do
# Check what's installed vs what the sssd src package would build
if dpkg --get-selections | grep -qE "^$PACKAGE[[:space:]]*(install|hold)$"
>/dev/null; then
HOLD+=(${PACKAGE})
INSTALLED+=(${PACKAGE}_2.4.1-2_amd64.deb)
if [[ ! -f ${PACKAGE}_2.4.1-2_amd64.deb ]]; then
curl -O
https://mirrors.xmission.com/debian/pool/main/s/sssd/${PACKAGE}_2.4.1-2_amd64.deb
fi
fi
done
clear
echo "Packages are in ${TEMPDIR}; you will need to clean it up manually."
echo
echo "You will need to remove the old sssd cache by executing:"
echo "# rm /var/lib/sss/db/cache_*"
echo
echo "Once you've done that, you can re-install the old versions using"
echo "# dpkg -i ${INSTALLED[@]}"
echo
echo "Finally, hold the old version using:"
echo "# apt-mark hold ${HOLD[@]}"
echo
echo "You will need to 'apt-mark unhold ${HOLD[@]}' once this bug is fixed.
Bug#994815: exim4: Helo command rejected: need fully-qualified hostname
On Tue, Sep 21, 2021 at 08:31:15PM +0200, Marc Haber wrote: > Please check whether your system is correctly configured to find the > host name. Information can be found on > https://wiki.debian.org/PkgExim4UserFAQ#How_does_exim_find_out_its_host_name_to_use_in_HELO.2FEHLO.3F > > Please report back about your results. It's not quite clear to me what you want me to report, but I will try. We never had a problem of HELO localhost.localdomain, only of HELO . After commenting out the MAIN_HARDCODE_PRIMARY_HOSTNAME line (and running update-exim4.conf and service exim4 restart, I got # exim4 -bP|grep ^primary_hostname primary_hostname = I then did "apt purge libnss-myhostname" (and again update and restart) and now the same command produces: primary_hostname = When trying "telnet smtp", the mail server identifies itself with the longname and replies to "helo bla" with 250 Hello [] So apparently libnss-myhostname bug is at fault. Looking at bug report #756224, it has not been fixed in 7 years, so it is unlikely to be fixed soon, and a conflict between exim4 and libnss-myhostname seems appropriate. I don't remember explicitly installing libnss-myhostname, so it most likely came with some other package; however, removing it did not lead to other package removals, so I don't know how it came in. - anton
Bug#994838: ITP: libregexp-pattern-defhash-perl -- Regexp patterns related to DefHash
Package: wnpp Owner: Étienne Mollier Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libregexp-pattern-defhash-perl Version : 0.001 Upstream Author : perlancar * URL : https://metacpan.org/release/Regexp-Pattern-DefHash * License : Artistic or GPL-1+ Programming Lang: Perl Description : Regexp patterns related to DefHash Regexp::Pattern is a convention for organizing reusable regex patterns. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. This package is needed for updating libhash-defhash-perl. Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/4, please excuse my verbosity. signature.asc Description: PGP signature
Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
control: tag -1 - confirmed
On 2021-09-04 15:08, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
>
> On Sun, 2021-08-22 at 14:58 +0200, Aurelien Jarno wrote:
> > During the upgrade from Buster to Bullseye, the SSH server is not
> > restarted following the libc6 upgrade, causing new SSH connections to
> > get rejected until the SSH server is restarted later in the upgrade.
> >
> > It could be considered as a regression as it didn't happen during the
> > upgrade from Stretch to Buster.
> >
> > [ Impact ]
> > Upgrade might fail or get stuck for remote upgrade using SSH if for
> > some reason the SSH connection breaks. Using screen or tmux doesn't
> > help here as it is not possible to connect again using SSH.
> [...]
> > The change consist in updating the regex getting the list of services
> > in the "installed" state, to also consider openssh-server in
> > 'unpacked' state.
>
> +glibc (2.31-13+deb11u1) unstable; urgency=medium
>
> The distribution there should be "bullseye".
Indeed good catch. dch just reuse the one from the previous entry.
> I realise that the changes don't affect the udeb, but for completeness
> this wants a kibi-ack; CCed and tagging appropriately. Please feel free
> to go ahead on that basis.
In the meantime another issue that would need to be fixed in sid came as
bug#994042.
This time the issue is in the preinst. To summarize, in the case debconf
is not usable to prompt the user about the upgrade, the preinst switches
to text prompt. However as the debconf module has been loaded got
control of the tty, which prevent any input from the user. For skilled
users it still possible to kill the upgrade from another, but other
users will probably try other actions that might have damaging effects
(like rebooting the system).
The fix is to get the debconf configuration without using the debconf
module, as suggested by Colin Watson.
You will find the new debdiff including this fix attached to the mail.
It has been tested by using the reproducer providing by Colin with an
additional repository containing the fixed glibc packages. Two cases
have been tested:
- upgrade + dist-upgrade to reproduce the original issue where the
preinst switches to text prompt and verify that the user input is now
accepted
- dist-upgrade to get a debconf prompt and verify it still works.
Could you please consider this new debdiff for bullseye?
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff --git a/debian/changelog b/debian/changelog
index 138f350a..d19a1d75 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+glibc (2.31-13+deb11u1) bullseye; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debian/script.in/nsscheck.sh: restart openssh-server even if it has been
+deconfigured during the upgrade. Closes: #990069.
+ * debian/debhelper.in/libc.preinst: fix text fallback when debconf is
+unusable, the current debconf configuration should be queried without
+first sourcing the confmodule to avoid losing control of the tty. Big
+thanks to Colin Watson for the help diagnosing the issue and for providing
+an easy reproducer. Closes: #994042.
+
+ -- Aurelien Jarno Sun, 22 Aug 2021 14:38:58 +0200
+
glibc (2.31-13) unstable; urgency=medium
[ Colin Watson ]
diff --git a/debian/debhelper.in/libc.preinst b/debian/debhelper.in/libc.preinst
index d679db4f..f0285832 100644
--- a/debian/debhelper.in/libc.preinst
+++ b/debian/debhelper.in/libc.preinst
@@ -21,23 +21,23 @@ kfreebsd_compare_versions () {
if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
then
-# Load debconf module if available and usable
+# Check if the debconf module is available and usable
+USE_DEBCONF=
if [ -f /usr/share/debconf/confmodule ]; then
# cdebconf has a working fallback mechanism in case dialog
# is not usable, so do not try to do anything smart here
if [ "$DEBCONF_USE_CDEBCONF" ] ; then
-. /usr/share/debconf/confmodule
USE_DEBCONF=1
# debconf requires perl
elif perl -e "" 2>/dev/null ; then
-. /usr/share/debconf/confmodule
# Check that the selected frontend will work
if [ -n "$DEBIAN_FRONTEND" ] ; then
frontend="$DEBIAN_FRONTEND"
else
-db_version 2.0
-db_get debconf/frontend || RET="Dialog"
-frontend="$RET"
+# Query the frontend without first sourcing the confmodule to
avoid
+# losing control of the tty. This snippet must not be copied
blindly.
+frontend="$(echo 'GET debconf/frontend' | debconf-communicate
| sed '/^0 /!d;s/^0 //')"
+frontend="${frontend:-Dialog}"
fi
frontend=`echo $frontend | tr '[:upper:]' '[:lower:]'`
case "$frontend" in
@@ -61,6 +61,11 @@ then
fi
Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade
Hi, On 2021-09-15 21:54, Colin Watson wrote: > On Fri, Sep 10, 2021 at 09:59:44PM +0200, Aurelien Jarno wrote: > > On 2021-09-10 20:39, Colin Watson wrote: > > > On Fri, Sep 10, 2021 at 09:03:32PM +0200, Aurelien Jarno wrote: > > > > I gave a try with debconf-show instead. I have attached a totally > > > > untested patch to check that we agree on the way to do it. > > > > > > I think you forgot to attach the patch? > > > > Dooh. Please find a new version attached. > > The general idea of this looks good to me. I've left some detailed > review comments below, and IMO we should test it against my reproducer > (especially since this preinst patch needs to end up in bullseye). Thanks for the fixes. > > > I managed to reproduce the reported bug by taking Neil's full package > > > list, mangling it to roughly make sense on buster, installing all of > > > that, and then doing "apt upgrade && apt full-upgrade" (my own habit is > > > just to do "apt full-upgrade", but in this case the initial "apt > > > upgrade" is crucial). I'm now trying to more or less bisect the package > > > list to find something rather more minimal; this is a slow process, but > > > no roadblocks so far, and I'll let you know when I have something. > > > > Thanks a lot for your help. > > OK, it took much longer than I expected because I wasn't able to do it > by just bisecting the package list, but here's a reproducer. I ran this > in a fresh container produced by "lxc launch images:debian/buster"; I > expect other container tools can be made to exhibit this too, though it > may be sensitive to exactly which packages are in the base image. > > # apt update && apt -y install gimp libc6-dev postgresql whiptail > # cat >/etc/apt/sources.list < deb http://deb.debian.org/debian bullseye main > deb http://security.debian.org/debian-security bullseye-security main > # apt update && apt -y upgrade && apt -y dist-upgrade Thanks for the reproducer. I have been able to use it to test the fixes, both with upgrade + dist-upgrade to check that the problem is fixed, and with dist-upgrade only to check that things still work when debconf is usable. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade
control: severity -1 serious On 2021-09-10 16:02, Neil Williams wrote: > Package: libc6 > Version: 2.31-13 > Severity: normal > X-Debbugs-Cc: codeh...@debian.org > > This is related to #984533 - in my case, there was no effect on the initramfs. > > I am attaching the section of the apt log. (gzipped) > I am also attaching the dpkg -l output for the package list (after upgrade). > > The apt log includes the details of the --purge autoremove operation I > completed > after a reboot, so those packages were also installed on buster too. > > This was an upgrade from buster to bullseye. > apt upgrade worked fine (first part of the log). > > When dist-upgrade started, I got: [snip] > No matter what I typed to the Do you want to upgrade prompt, the process did > not continue. > I needed to open a terminal tab, find the preinst process & kill it. Not being able to perform the upgrade without having to kill the preinst process from another tab (and having the skills do so) looks a serious issue to me. I am therefore upgrading the severity. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#994851: electronics-radio-dev: add atlc to the list of packages
Package: electronics-radio-dev Version: 0.3 Severity: wishlist X-Debbugs-Cc: dfo...@gmail.com Please consider adding atlc to the list of packages installed by electronics-radio-dev. atlc depends on atlc-examples. atlc - Arbitrary Transmission Line Calculator https://packages.debian.org/sid/atlc thanks, Daniele -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages electronics-radio-dev depends on: ii electronics-tasks 0.3 Versions of packages electronics-radio-dev recommends: ii antennavis 0.3.1-4+b1 ii gsmc1.2.1-1 ii meep1.17.1-1 ii nec2c 1.3-4+b1 ii openems 0.0.35+git20190103.6a75e98+dfsg.1-3 ii transcalc 0.14-7 ii xnec2c 1:4.1.1-2 ii yagiuda 1.19-9+b1 Versions of packages electronics-radio-dev suggests: pn linsmith pn qucs pn xsmc-calc -- no debconf information
Bug#884575: ITP: syncthingtray -- a tray applet, plasmoid, and Dolphin integration for Syncthing
Hi Hannah, Hannah Rittich writes: > Hey Nicholas, > > I wanted to ask whether you are still working on packaging > syncthingtray. If not, I would offer to do the packaging. > > Regards, > Hannah Thank you for your interest, and yes, I would appreciate a comaintainer :-), and agree that it is better to collaborate than to work on something alone. Also, I freely concede that I've taken much too long to fulfill this ITP. How do you propose to solve the C++utilities/cpp-utilities issue? I worry that it's unsuitable for installation to the global/system namespace, and I was unable to limit this using something like: -DCONFIGURATION_NAME:STRING="martchus" \ -DCONFIGURATION_PACKAGE_SUFFIX:STRING="martchus" \ -DCONFIGURATION_TARGET_SUFFIX:STRING="martchus" I also wonder if this might be a use-case for uscan's multiple tarball support, and if it would be better if these upstream dependencies (c++utilities, qtutilities, and qtforkawesome) were bundled. Ie, maybe using uscan's multiple tarball support, plus a Debian-specific variation of: https://github.com/Martchus/syncthingtray/blob/master/README.md#building-this-straight ? Let me know what you think! Regards, Nicholas signature.asc Description: PGP signature
Bug#994850: RFS: lebiniou-data/3.62.2-1 -- datafiles for Le Biniou
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lebiniou-data": * Package name: lebiniou-data Version : 3.62.2-1 Upstream Author : Olivier Girondel * URL : https://biniou.net * License : GPL-2+ Section : graphics It builds this binary package: lebiniou-data - datafiles for Le Biniou The package appears to be lintian-clean. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lebiniou-data Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.62.2-1.dsc Changes since the last upload: * New upstream release 3.62.2. * debian/changelog: Bump urgency to medium. * debian/tests/control: Remove wget. * test/lebiniou-test.sh: Do not send tests results. Regards, -- Olivier Girondel
Bug#994849: RFS: lebiniou/3.62.1-1 -- user-friendly, powerful music visualization / VJing tool
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lebiniou": * Package name: lebiniou Version : 3.62.1-1 Upstream Author : Olivier Girondel * URL : https://biniou.net * License : GPL-2+ Section : graphics It builds this binary package: lebiniou - user-friendly, powerful music visualization / VJing tool The package appears to be lintian-clean. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lebiniou Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.62.1-1.dsc Changes since the last upload: * New upstream release 3.62.1. * debian/changelog: Bump urgency to medium. * debian/tests/control: Remove wget. Regards, -- Olivier Girondel
Bug#994848: xterm: "xterm -e command" should return the exit code of "command"
Package: xterm Version: 368-2 Severity: wishlist Tags: upstream Hi, for test suites of tools which manipulate terminals, it would be nice if "xterm -e command" would return the exit code of "command", e.g. $ xterm -e false should exit with return code 1, but actually does exit with return code 0. This issue might be related with https://bugs.debian.org/427798 as being able to save the contents of the terminal would be nice in the above mentioned use case as well. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), (111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), (105, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.13.0-trunk-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=C.UTF-8, LC_CTYPE=C.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 xterm depends on: ii libc6 2.32-4 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libice6 2:1.0.10-1 ii libtinfo6 6.2+20210905-1 ii libutempter01.2.1-2 ii libx11-62:1.7.2-2+b1 ii libxaw7 2:1.0.13-1.1 ii libxext62:1.3.4-1 ii libxft2 2.3.2-2 ii libxinerama12:1.1.4-2 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.2.0-1 ii xbitmaps1.1.1-2.1 Versions of packages xterm recommends: ii x11-utils 7.7+5 Versions of packages xterm suggests: pn xfonts-cyrillic -- no debconf information
Bug#994741: regression tests: skipped vs failed
On Tue, 21 Sep 2021 18:57:41 +0300 Andrius Merkys wrote: > I cannot reproduce the failure myself on amd64. I tried building on a > machine without a display, and yet the test succeeds. I will try a > porterbox next. If the test succeeds, is the overall build then successful? Is that the cause of the amd64 build failure on the autobuild systems? If so, then cannot this problem be temporarily fixed by ignoring the test result on amd64, also? If it's acceptable to not run the test at all on 32-bit architectures, and to ignore the result on 64-bit BE architectures, then it cannot really be that important for 64-bit LE architectures. By temporarily ignoring the test result, the immediate problem can be solved: Inkscape v1.1 is not currently available for amd64 and other 64-bit LE systems. Having temporarily disabled this test, the actual cause of the failure can then be investigated at anybody's convenience, without further delaying the availability of the Inkscape distribution package. Inkscape v1.0.2 is REALLY buggy. This needs to be fixed soon.
Bug#767442: trscripts: diff for NMU version 1.18+nmu3
On Mon, Sep 20, 2021 at 11:53:48AM +0200, Jochen Sprickerhof wrote: > > Thanks for the maintainer offer, I don't intent to put more work into it > currently Well, perhaps there is no immediate need for more work. > but if you want to pass maintainership I would propose to move it to > the Debian Fonts Task Force (Cced) and have both of us as uploaders. > What do you think? Whatever you decide. However, notice that I won't have much time for work in a group. Anton Zinoviev
Bug#994847: r-cran-parsetools: Unmaintained, has been removed from CRAN
Package: r-cran-parsetools Version: 0.1.3-2 Severity: serious X-Debbugs-Cc: nil...@debian.org Dear Maintainer, r-cran-parsetools has been removed from CRAN[1], and so has its reverse dependencies[2,3] This is currently stalling the migration of r-base, hence filing this bug to remove all three from testing. Note that parsetools has testextra as the only reverse-dep and testextra has purrrogress as the only reverse-dep. So a chain of packages shall not be affected [1]: https://cran.r-project.org/web/packages/parsetools/index.html [2]: https://cran.r-project.org/web/packages/testextra/index.html [3]: https://cran.r-project.org/web/packages/purrrogress/index.html Nilesh -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages r-cran-parsetools depends on: ii r-base-core [r-api-4.0] 4.0.4-1 Versions of packages r-cran-parsetools recommends: pn r-cran-testthat Versions of packages r-cran-parsetools suggests: pn r-cran-covr pn r-cran-knitr pn r-cran-rmarkdown
Bug#994846: toot: Toot cuts off last char of line
Package: toot Version: 0.28.0-2 Severity: normal X-Debbugs-Cc: marathon.duran...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Posting a cut 'n paste' url.Not sure it's bc of that or simply bc it's the last line. A sample of the output returned from one such post. Looks like there is a non breaking space needed in the code? (Between end of url and 'Toot Posted line') -- Sample toot post Write or paste your toot. Press Ctrl-D to post it. Lets trace who's paying these #TrollFarms My bet is that it will be close to the Homeland. https://www.technologyreview.com/2021/09/16/1035851/facebook-troll-farms-report-us-2020-electionToot posted: https://mastodon.online/@marathon/106971530571355280 -- End of Sample Hope this helps. :) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.13.19-xanmod1 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages toot depends on: ii python3 3.9.2-3 ii python3-bs4 4.9.3-1 ii python3-requests 2.25.1+dfsg-2 ii python3-urwid 2.1.2-1 ii python3-wcwidth 0.1.9+dfsg1-2 toot recommends no packages. toot suggests no packages. -- no debconf information
Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash
Hi, I applied the patch and try it on hplip 3.21.6+dfsg0-1. No more stack smashing. But at a random point during the scan, simple-scan stop and display a message : « Failed to scan - Error communicating with scanner ». Nothing in the terminal nor in journald. The random point where it failed is random in the sense of when I scan, I can show the beginning of the scanned picture appear in simple-scan, and at one point (sometimes at the begining, sometimes near the end), the error message appear. Cheers, Florence Le Mon, 20 Sep 2021 19:18:11 +0200, Bernhard Übelacker a écrit : > Hello Florence, dear Maintainer, > then attached patch is growing this buffer from 6 > to 10 usable bytes, making a size around 1 TB possible. > And tries to break the loop before overrunning the buffer. > > Unfortunately I cannot test this patch, > so it is completely untested, just compiles... > > Kind regards, > Bernhard > -- Florence Birée (elle) 06 52 92 15 32 En ces temps d'état policier, ne les laissons pas lire nos mails, chiffrons-les ! https://emailselfdefense.fsf.org/fr/index.html pgpxjlsmlHIlB.pgp Description: Signature digitale OpenPGP
Bug#994845: project changed maintainer (not a fork)
Package: python3-prettytable Version: 0.7.2-5 Hi, PrettyTable is now officially maintained by JazzBand at https://github.com/jazzband/prettytable, see the PyPI page: https://pypi.org/project/prettytable/ Version is now 2.2.0.
Bug#911428: RFA: spice-gtk - spice gtk client
I'd like to adopt spice-gtk. I've started working on it and I've removed all the lintian issues. I noticed there were a lot of open bugs. Since I'm newer to Debian, does anyone have advice on fixing and triaging the bugs? Lin "Lance" Qigang GPG Fingerprint: 8CAD 1250 8EE0 3A41 7223 03EC 7096 F91E D75D 028F signature.asc Description: OpenPGP digital signature
Bug#980957: llvm-toolchain-11 autopkgtest segfaults on armhf
Hi Gianfranco, On Sun, Mar 28, 2021 at 09:11:49PM +0200, Gianfranco Costamagna wrote: > control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27659 > control: affects -1 src:binutils > > Invoking the clang with -V shows a failure in ld.bdf linker, a failure that > doesn't happen with gold linker and with object files (crt*.o) copied on > local directory. > > I opened a bug against binutils people to track it down, hopefully they can > sort what is segfaulting there. > Does the following upstream reverted commit unblock this bug, thus unblocking llvm-toolchain-12 from migrating to testing? https://sourceware.org/bugzilla/show_bug.cgi?id=27659#c17 Regards, Nicholas signature.asc Description: PGP signature
Bug#988923: RFS: distorm3/3.5.2b-1 [ITA] -- powerful disassembler library for x86/AMD64 binary streams (Python3 bindings)
I submitted this as an ITA a bit ago, could someone take a look at this for me? distorm3 (3.5.2b-1) unstable; urgency=medium . * New maintainer (Closes: #951161) * New upstream release. * debian/*.links: Updated symbolic links to new upstream version * debian/not-installed: Accounted for new upstream .so name * debian/patches: - Added patch to update the library version number - Modified fix_init_python patch to work with the new version * debian/libdistorm3-3.symbols: Updated symbols to 3.5.2b * debian/python3-distorm: Account for varying python3 directory naming scheme * debian/rules: - Account for upstream build changes - Removed --as-needed flag * debian/copyright: Updated packaging copyright years * debian/control: - Updated maintainer - Removed libdistorm3-dev Multi-Arch support, since it didn't support it - Added missing python dependencies * Release to unstable The full changes are here: https://mentors.debian.net/package/distorm3/ I re-uploaded with a lintian fix. I'm waiting on the upstream changes and submitted a pull request here Lin "Lance" Qigang GPG Fingerprint: 8CAD 1250 8EE0 3A41 7223 03EC 7096 F91E D75D 028F signature.asc Description: OpenPGP digital signature
Bug#994808: upgrade issue
Hi Sophie, On Tue, Sep 21, 2021 at 05:12:42PM +0200, Sophie Brun wrote: > > I created Merge Request to fix this issue: > > https://salsa.debian.org/debian/atftp/-/merge_requests/1 > > I tested this patch and uploaded it in Kali Linux while waiting for a fix > in Debian. I hope it can be merged so we can drop our fork. Many thanks for the report and your patch; sorry for causing you extra work with this stupid mistake. I merged the patch, however for me it seems not to be sufficient. I installed the -3 package, added the faulty line to the configuration and tried to upgrade with your patch applied: sudo dpkg -i atftpd_0.7.git20210915-2_amd64.deb (Reading database ... 319039 files and directories currently installed.) Preparing to unpack atftpd_0.7.git20210915-2_amd64.deb ... Warning: Stopping atftpd.service, but it can still be activated by: atftpd.socket Unpacking atftpd (0.7.git20210915-2) over (0.7.git20210202-3) ... Setting up atftpd (0.7.git20210915-2) ... /var/lib/dpkg/info/atftpd.config: 2: /etc/default/atftpd: 69: not found dpkg: error processing package atftpd (--install): installed atftpd package post-installation script subprocess returned error exit status 127 Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: atftpd I have to investigate further, but does it really work for you? Best regards, Andi
Bug#993792: iotop-c 1.17-1+deb11u1 flagged for acceptance
package release.debian.org tags 993792 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: iotop-c Version: 1.17-1+deb11u1 Explanation: properly handle UTF-8 process names
Bug#994844: emacs-gtk: Emacs ignores ~/.Xdefaults-HOSTNAME
Package: emacs-gtk
Version: 1:27.1+1-3.1
Severity: normal
Control: tags -1 fixed-upstream
X-Debbugs-Cc: none, Łukasz Stelmach
Dear Maintainer,
After upgrade to Debian 11 Emacs uses default foreground (black) and
background (white) colors instead of those I set in
~/.Xdefaults-myhostname.
strace(8) reveals an attempt to access to a non-existent file
27026 openat(AT_FDCWD, "/home/steelman/.Xdefaults/myhostname", O_RDONLY) =
-1 ENOTDIR[*]
This problem appears (I havn't tested the pathc) to have been
reported[1] and fixed[2] upstream.
The workaround to make Emacs read the file is to set XENVIRONMENT
variable.
XENVIRONMENT=${HOME}/.Xdefaults-myhostname
[*] I've got ~/.Xdefaults file and a bunch of symlinks
to it from ~/.Xdefaults-*
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38495
[2]
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4b118bdca1d8aa130fb67eadb16e08e87e698aa4
-- System Information:
Debian Release: 11.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages emacs-gtk depends on:
ii emacs-bin-common 1:27.1+1-3.1
ii emacs-common 1:27.1+1-3.1
ii libacl1 2.2.53-10
ii libasound2 1.2.4-1.1
ii libc62.31-13
ii libcairo21.16.0-5
ii libdbus-1-3 1.12.20-2
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libgif7 5.1.9-2
ii libglib2.0-0 2.66.8-1
ii libgmp10 2:6.2.1+dfsg-1
ii libgnutls30 3.7.1-5
ii libgpm2 1.20.7-8
ii libgtk-3-0 3.24.24-4
ii libharfbuzz0b2.7.4-1
ii libice6 2:1.0.10-1
ii libjansson4 2.13.1-1.1
ii libjpeg62-turbo 1:2.0.6-4
ii liblcms2-2 2.12~rc1-2
ii libm17n-01.8.0-2
ii libotf0 0.9.13-7
ii libpango-1.0-0 1.46.2-3
ii libpng16-16 1.6.37-3
ii librsvg2-2 2.50.3+dfsg-1
ii libselinux1 3.1-3
ii libsm6 2:1.2.3-1
ii libsystemd0 247.3-6
ii libtiff5 4.2.0-1
ii libtinfo66.2+20201114-2
ii libx11-6 2:1.7.2-1
ii libxext6 2:1.3.3-1.1
ii libxfixes3 1:5.0.3-2
ii libxml2 2.9.10+dfsg-6.7
ii libxrender1 1:0.9.10-1
ii zlib1g 1:1.2.11.dfsg-2
emacs-gtk recommends no packages.
Versions of packages emacs-gtk suggests:
ii emacs-common-non-dfsg 1:27.1+1-2
-- no debconf information
--
Miłego dnia,
Łukasz Stelmach
signature.asc
Description: PGP signature
Bug#994774: Working SysV Init Script
I pulled the SysV init script included in the Ganesha 3.5 source tarball:
nfs-ganesha-3.5/src/scripts/init.d/nfs-ganesha.debian8
I had to make a couple of minor changes in order for it to work. I changed
the LOCK file location from /var/lock/subsys to /var/lock. I changed the
status call to use status_of_proc.
I've attached the working init script.
Chris
#!/bin/bash
#
# chkconfig: 2345 50 50
# description: GANESHA NFS Daemon
#
# processname: /usr/bin/ganesha.nfsd
# config: /etc/ganesha/ganesha.nfsd.conf
# pidfile: /var/run/ganesha.nfsd.pid
#
### BEGIN INIT INFO
# Provides: ganesha
# Required-Start: $local_fs $named $time $network
# Required-Stop: $local_fs $named $time $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop ganesha daemon
# Description: NFS-GANESHA
### END INIT INFO
# source function library
#. /etc/rc.d/init.d/functions
. /lib/lsb/init-functions
PATHPROG=/usr/bin/ganesha.nfsd
# Default Ganesha options
LOGFILE=/var/log/ganesha/ganesha.log
CONFFILE=/etc/ganesha/ganesha.conf
prog=ganesha.nfsd
PID_FILE=${PID_FILE:=/var/run/${prog}.pid}
LOCK_FILE=${LOCK_FILE:=/var/lock/${prog}}
[ -f /etc/sysconfig/ganesha ] && . /etc/sysconfig/ganesha
[ -z "$NOFILE" ] && NOFILE=1048576
OPTIONS="-L $LOGFILE -f $CONFFILE -N NIV_EVENT -p $PID_FILE "
RETVAL=0
start() {
echo -n $"Starting $prog: "
if [ $UID -ne 0 ]; then
RETVAL=1
failure
else
ulimit -n $NOFILE
log_daemon_msg "Starting nfs-ganesha daemon" nfs-ganesha
if ! start-stop-daemon --start --oknodo --quiet --pidfile
$PID_FILE --exec $PATHPROG -- $OPTIONS; then
log_end_msg 1
exit 1
fi
touch $LOCK_FILE
log_end_msg 0
fi
echo
}
stop() {
echo -n $"Stopping $prog: "
if [ $UID -ne 0 ]; then
RETVAL=1
failure
else
log_daemon_msg "Stopping nfs-ganesha daemon" nfs-ganesha
#start-stop-daemon --stop --quiet --pidfile
killproc $PATHPROG
RETVAL=$?
if [ $RETVAL -eq 0 ]; then
log_end_msg 0
rm -rf $LOCK_FILE
else
log_end_msg 1
fi
fi
echo
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
if [ -f $LOCK_FILE ] ; then
stop
#avoid race
sleep 3
fi
start
;;
reload)
echo -n $"Reloading $prog: "
if [ -f $LOCK_FILE ] ; then
killproc -p $PID_FILE $prog -HUP
RETVAL=0
else
RETVAL=1
fi
echo
;;
force-reload)
stop
start
;;
try-restart)
if [ -f $LOCK_FILE ] ; then
stop
#avoid race
sleep 3
start
fi
;;
status)
if [ $RETVAL -eq 5 ] ; then
RETVAL=3
else
status_of_proc -p $PID_FILE $PATHPROG
RETVAL=$?
fi
;;
*)
echo $"Usage: $0 {start|stop|restart|reload|try-restart|status}"
RETVAL=1
esac
exit $RETVAL
Bug#925473: tomcat9: sysvinit script missing
Markus Koschany dixit: >> (maybe some systemd >> fan paid him) > >^^^ >Such malicious allegations are not helpful. You should adjust your humour detector. >> but this is what is, and that GR outcome is interpreted >> as Emmanuel being able to block this indefinitely despite nōn-systemd >> continuing to be a supported way of running Debian (albeit not without >> UsrMove in bookworm/sid). > >The GR outcome was systemd but we support exploring alternatives, not we >support systemd and sysvinit in any case. It wasn’t we desupport sysvinit either. >Systemd is far superior when it comes […] That may very well be, but OUR PRIORITIES ARE OUR USERS AND FREE SOFTWARE (Debian SC), and if the user requires to run sysvinit but wishes to run tomcat as well, it is MASSIVELY outside of the scope of the tomcat main‐ tainers to force people to switch the entire way of how the system is set up, booted and administered! The security implications are documented in the branch. This is enough. We sell rope, after all. (Or perhaps more, ahem, politely: PHP is also still packaged in Debian, despite its security history which is also not a theoretical problem. Sorry for singling you out, PHP, but I needed an example.) bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour”
Bug#972467: aom: Please package new upstream stable release (2.0.0)
Hi all, 在 2021-09-14星期二的 15:24 -0400，Boyuan Yang写道： > 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 FYI: I worked on packaging the embedded library (third_party/libyuv), and it is currently in the NEW queue: https://ftp-master.debian.org/new/libyuv_0.0~git20210909.ed5a9c8-1.html and https://salsa.debian.org/debian/libyuv . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#994843: puppetdb: Frequent command submissions failures with jetty 9.4.16-0+deb10u1
Package: puppetdb
Version: 6.2.0-3
Severity: important
X-Debbugs-Cc: kie...@koumbit.org
Dear Maintainer,
I'm not sure whether this bug applies more to puppetdb or libjetty9-java, but I
will start the report here.
After libjetty9-java upgraded from 9.4.15-1 to 9.4.16-0+deb10u1 frequent puppet
agent run errors started happening, with a vague error:
Error: Could not retrieve catalog from remote server: Error 500 on SERVER:
Server Error: Failed to execute
'/pdb/cmd/v1?checksum=9c18923b33f99552a5e49974ae5ff05be74fb672=9=xxx.example.com=replace_catalog=2021-09-20T20:13:16.121Z'
on at least 1 of the following 'server_urls': https://puppet:8081
The error didn't happen regularly for all nodes, but seemed to affect nodes
with larger catalogs more frequently.
While testing, I enabled to the debug logging in the puppetdb logback.xml.
During the runs that failed, I found a backtrace with the error:
2021-09-20T18:33:07.796-04:00 DEBUG [o.e.j.i.WriteFlusher] ignored:
WriteFlusher@23e9cdf8{IDLE}->null
javax.net.ssl.SSLHandshakeException: Encrypted buffer max length exceeded
A more complete version is towards the end of this report. There is a jetty
release that covered a possibly related issue:
https://github.com/eclipse/jetty.project/issues/6121
Verifying against our monitoring history, which contains information on the
puppet run failures, I noticed that the date corresponded with when the jetty
version changed. By downgrading, I was able to confirm that it fixed the
situation. As I said at the beginning I'm not sure if the fault here is in
puppetdb, or in libjetty9-java.
Please let me know if you need more information.
Debian release: buster
# apt policy
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://deb.debian.org/debian buster/contrib amd64 Packages
release v=10.10,o=Debian,a=oldstable,n=buster,l=Debian,c=contrib,b=amd64
origin deb.debian.org
500 http://deb.debian.org/debian buster/main amd64 Packages
release v=10.10,o=Debian,a=oldstable,n=buster,l=Debian,c=main,b=amd64
origin deb.debian.org
500 http://deb.debian.org/debian buster-updates/main amd64 Packages
release
o=Debian,a=oldstable-updates,n=buster-updates,l=Debian,c=main,b=amd64
origin deb.debian.org
500 http://security.debian.org/debian-security buster/updates/main amd64
Packages
release v=10,o=Debian,a=oldstable,n=buster,l=Debian-Security,c=main,b=amd64
origin security.debian.org
2021-09-20T18:33:07.796-04:00 DEBUG [o.e.j.i.WriteFlusher] ignored:
WriteFlusher@23e9cdf8{IDLE}->null
javax.net.ssl.SSLHandshakeException: Encrypted buffer max length exceeded
at
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:613)
at
org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:340)
at
org.eclipse.jetty.server.HttpConnection.fillAndParseForContent(HttpConnection.java:313)
at
org.eclipse.jetty.server.HttpInputOverHTTP.produceContent(HttpInputOverHTTP.java:33)
at org.eclipse.jetty.server.HttpInput.nextContent(HttpInput.java:369)
at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:301)
at java.base/java.io.InputStream.transferTo(InputStream.java:704)
at java.base/java.nio.file.Files.copy(Files.java:3078)
at puppetlabs.stockpile.queue$write_stream.invokeStatic(queue.clj:102)
at puppetlabs.stockpile.queue$write_stream.invoke(queue.clj:100)
at puppetlabs.stockpile.queue$store$fn__6587.invoke(queue.clj:282)
at puppetlabs.stockpile.queue$store.invokeStatic(queue.clj:281)
at puppetlabs.stockpile.queue$store.invoke(queue.clj:228)
at
puppetlabs.puppetdb.queue$eval21400$store_in_stockpile__21405$fn__21406.invoke(queue.clj:288)
at
puppetlabs.puppetdb.queue$eval21400$store_in_stockpile__21405.invoke(queue.clj:283)
at
puppetlabs.puppetdb.queue$eval21432$store_command__21437$fn__21438.invoke(queue.clj:321)
at
puppetlabs.puppetdb.queue$eval21432$store_command__21437.invoke(queue.clj:317)
at
puppetlabs.puppetdb.command$eval37528$do_enqueue_command__37533$fn__37537$fn__37539.invoke(command.clj:253)
at
puppetlabs.puppetdb.command.proxy$java.lang.Object$Callable$7da976d4.call(Unknown
Source)
at com.codahale.metrics.Timer.time(Timer.java:101)
at
puppetlabs.puppetdb.command$eval37528$do_enqueue_command__37533$fn__37537.invoke(command.clj:252)
at
puppetlabs.puppetdb.command$eval37528$do_enqueue_command__37533.invoke(command.clj:244)
at
puppetlabs.puppetdb.command$reify__37765$service_fnk__23931__auto___positional$reify__37775.enqueue_command(command.clj:728)
at
puppetlabs.puppetdb.command$eval37650$fn__37651$G__37638__37667.invoke(command.clj:420)
at
puppetlabs.puppetdb.command$eval37650$fn__37651$G__37637__37684.invoke(command.clj:420)
at clojure.lang.AFn.applyToHelper(AFn.java:195)
at
Bug#994842: elpa-debian-el: (debian-bug) doesn't work after upgrade to Debain 11
Package: elpa-debian-el Version: 37.10 Severity: serious X-Debbugs-Cc: none, Łukasz Stelmach File: /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-bug.el Dear Maintainer, After upgrading to Debian 11 I tried to file a bug using M-x debian-bug in Emacs. I didn't get properly prefilled report. Quick investitagion reveald that running reportbug in (debian-bug-prefill-report) failed. (call-process) returned 1 and the lisp code didn't handle it properly. Running the command in a shell yeilded the following message --8<---cut here---start->8--- Warning: no reportbug configuration found. Proceeding in novice mode. Detected character set: UTF-8 Please change your locale if this is incorrect. Unable to identify a valid from address, please run 'reportbug --configure' --8<---cut here---end--->8--- Indeed I didn't have ~/.reportbugrc but until upgrade to Debian 11 it didn't matter and (debian-bug) worked just fine. Configuring reportbug by running "reportbug --configure" as advised fixes the problem. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU threads) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-4 ii dh-elpa-helper 2.0.8 ii dpkg1.20.9 ii emacsen-common 3.0.4 ii reportbug 7.10.3 ii xz-utils5.2.5-2 Versions of packages elpa-debian-el recommends: ii emacs-gtk [emacs] 1:27.1+1-3.1 ii wget 1.21-1+b1 elpa-debian-el suggests no packages. -- no debconf information -- Miłego dnia, Łukasz Stelmach signature.asc Description: PGP signature
Bug#901270: trickle FTCBFS: configures for the build architecture
Hi Helmut, Helmut Grohne wrote: > > I see no --host in my build log, but it now (obviously) uses > > dh_auto_configure. > > --host is only passed for cross builds by dh_auto_configure. Ah, thanks for that explanation! > Next time, please do yourself and myself a favour and just close the > bug. I'd have done if that missing --host wouldn't have confused me. > If you did a reasonable stab at fixing the problem (and using > dh_auto_configure is such a thing), please just close ftcbfs bugs (in > general) right away without confirming. Will do. > Packages are automatically retested on uploads. Ah, nice. > And if you want to go the extra mile and check, then go > http://crossqa.debian.net/src/trickle (this is also linked from > tracker.d.o as "cross"). Nice! Didn't notice that so far. Will do next time! > If it hasn't built your version yet (which it > usually does within three days), you may click the "cross build" button > at the bottom and it should do it within an hour. Cool service, thanks! And thanks for making me personally aware of it! :-) > And there you see your build and it does pass --host. It fails on > the AC_TRY_RUN mentioned in my submission. Ah, I understood that as if that was a general issue since the package also had a FTBFS issue also related to autoconf. I also assumed that this would be fixed by my debian/rules rewrite as well. > I still don't have a fix for that. I assume you still consider this bug report as fixed anyway since you closed it. > You'd also save yourself from reading a long reply from me. :) I love long mails. Especially if they're full of helpful information. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#994825: Me Too
I see the same error * (2021-09-21 13:02:46): [sssd] [sbus_server_socket_listen] (0x0020): Unable to start a D-Bus server at unix:path=/var/lib/sss/pipes/private/sbus-monitor [org.freedesktop.DBus.Error.AccessDenied]: Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": Permission denied
Bug#925473: tomcat9: sysvinit script missing
Am Dienstag, dem 21.09.2021 um 16:10 + schrieb Thorsten Glaser: [...] > I have no idea why Emmanuel, the primary maintainer, has been set > so strongly against merging this patch for as long as I promise to > take care of it and deal with any related fallout > (maybe some systemd > fan paid him) ^^^ Such malicious allegations are not helpful. > but this is what is, and that GR outcome is interpreted > as Emmanuel being able to block this indefinitely despite nōn-systemd > continuing to be a supported way of running Debian (albeit not without > UsrMove in bookworm/sid). The GR outcome was systemd but we support exploring alternatives, not we support systemd and sysvinit in any case. Systemd is far superior when it comes to security features like sandboxing and limiting access to the file system. This is not a theoretical problem. Tomcat has been affected by security vulnerabilities like remote code execution and read and write access to arbitrary files in the past. Just focusing on systemd makes it simpler for us to support Tomcat for its whole life cycle which is at least five years. These are the main reasons for not supporting sysvinit. signature.asc Description: This is a digitally signed message part
Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel
On 8/24/2021 7:12 PM, Ben Hutchings wrote: On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote: Ben Hutchings writes: I think a proper fix would be one of: a. If the Xen virtual keyboard driver is advertising capabilities it doesn't have, stop it doing that. b. Change the implementation of modalias attributes to allow longer values. It's not clear to me whether the Xen driver is advertising correctly or not. If it is, then�the solution should be b, but that may be too disruptive a change to the kernel. So a reasonable workaround might be: c. Change the input subsystem to limit the length of the capabilities part of the modalias. The problem with a) is that the Xen keyboard is not a physical keyboard and so it has no way of knowing what keys it actually has. It is a fake input device designed to pass through whatever input the Xen hypervisor sends down. As such, any key could come in. If it doesn't advertise that it has all of these keys, then they would not be accepted by libinput when the hypervisor sends them down. Right, that's what I feared. xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC, KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654 keys and 2362 bytes in the modalias. This seems to be the heart of the problem: libinput was designed assuming that all keyboards can and must report what keys are actually present, and then libinput tries to cram that information into the modalias rather than some other sysfs attribute as it should ( or not at all... I still don't see how this information is actually supposed to be useful to userspace ). I think modaliases aren't intended to be interpreted by user-space, other than processing wildcards when matching to modules. For input devices, the same information is available through other variables in the uevent, in a more compact form. The information *is* useful for user-space; e.g. in initramfs-tools we recognise keyboard devices and add their drivers to the initramfs but ignore other input devices. As for b), the problem isn't with the modalias attribute itself, but when the kernel tries to copy it into the environment block for the udev callout. The environment block is only a single page, and so limited to 4 KB. And that's for everything else that goes into the environment, not just the modalias. Text-based sysfs attributes are limited to a page, but udev receives uevents through netlink, not sysfs. The current limit on the environment of a uevent appears to be 2 KB (UEVENT_BUFFER_SIZE defined in ). That seems like it *might* be easier to change, so long as user-space doesn't have a similar limit. I looked into systemd/udev, and it seems to use an 8 KB buffer for receiving uevents: https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 But as a first step I think increasing the kernel buffer size to 4 KB would be enough. Perhaps someone could test whether this patch to the domU kernel makes udev happier: --- a/include/linux/kobject.h +++ b/include/linux/kobject.h @@ -30,7 +30,7 @@ #define UEVENT_HELPER_PATH_LEN 256 #define UEVENT_NUM_ENVP 64 /* number of env pointers */ -#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */ +#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */ #ifdef CONFIG_UEVENT_HELPER /* path to the userspace helper executed on an event */ --- END --- ? Ben. Even though this patch has been tested to apparently fix this bug and the bug has been elevated to important and tagged patch and upstream, AFAICT there is no action yet upstream or anywhere else after more than three weeks. Is this patch dead as a possible fix for this bug? Best wishes, Chuck
Bug#994741: regression tests: skipped vs failed
On Tue, 21 Sep 2021 12:33:07 +0300
Andrius Merkys wrote:
> if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
> set(RENDERING_TESTS_64bit
> # .otf font with compressed SVG glyphs
> # (test not stable on 32bit Windows)
> text-gzipped-svg-glyph
> )
> endif()
>
> Thus this test is only run on 64bit architectures.
Thanks for pointing that out.
It appears that my assumption that this regression test failure was the
cause of the overall build failure on amd64, was incorrect. According to
the build logs, this test also fails on ppc64 and sparc64, and yet the
builds for those architectures have apparently succeeded.
This appears to be the critical failure on amd64:
cd /<>/obj-x86_64-linux-gnu && /usr/bin/ctest
--force-new-ctest-process
ninja: build stopped: subcommand failed.
dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8
MESON_TESTTHREADS=1 ninja test returned exit code 1
make[1]: *** [debian/rules:21: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
Build finished at 2021-08-21T15:19:37Z
Since the regression test failure is apparently an unrelated problem,
how should that be interpreted?
Bug#980300: libcbor: Please upgrade to new version 0.8.0
Hello, Friendly ping request for this bug. If you need help, I'll be happy to help you with this upgrade. /Nicolas
Bug#994841: sqlparse: CVE-2021-32839
Source: sqlparse Version: 0.4.1-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for sqlparse. CVE-2021-32839[0]: | sqlparse is a non-validating SQL parser module for Python. In sqlparse | versions 0.4.0 and 0.4.1 there is a regular Expression Denial of | Service in sqlparse vulnerability. The regular expression may cause | exponential backtracking on strings containing many repetitions of | '\r\n' in SQL comments. Only the formatting feature that removes | comments from SQL statements is affected by this regular expression. | As a workaround don't use the sqlformat.format function with keyword | strip_comments=True or the --strip-comments command line flag when | using the sqlformat command line tool. The issues has been fixed in | sqlparse 0.4.2. 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-32839 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32839 [1] https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf [2] https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb Regards, Salvatore
Bug#994840: [PATCH] zbarcam-gtk fails on wayland
Package: zbarcam-gtk
Version: 0.23.92-3
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I tried zbarcam-gtk and it did not deliver any output. On the command line it
said:
(zbarcam-gtk:522342): Gdk-WARNING **: 20:58:54.135:
../../../../../gdk/x11/gdkwindow-x11.c:5653 drawable is not a native X11 window
I then tries to run the application using `GDK_BACKEND=x11 zbarcam-gtk` and
it worked. So I applied the attached patch to the source to set the default
backend to 'x11'.
Regards, Daniel
- -- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (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, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages zbarcam-gtk depends on:
ii libc62.32-4
ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii libglib2.0-0 2.70.0-1
ii libgtk-3-0 3.24.30-3
ii libzbar0 0.23.92-3
ii libzbargtk0 0.23.92-3
zbarcam-gtk recommends no packages.
zbarcam-gtk suggests no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmFKK+UACgkQS80FZ8KW
0F3Jhw//Q8wv+CZ7rCaEyqEHQcd9fdijXmA/SwyF8fdpkCYHk/heJDu3Az/D0jnu
H4uRrY+47PEyBaH4aLWIJPzpVeQXboCH4PCsOfBnOZjCqWj+eBmu2J/hLbMCEzaG
CVU88Y+lCz/RWphEQ7cn8lUxN/hwigqqq7LkWF25mCo6Pv/UqRb5DHjW4Z/84s88
le9dkamuo3rzCuwR7njXj8OX/AOC5JfI9+K4iaLazncR4rZn6B5TyYN6Nbi46gdl
olHOorzkIKBJXHT+oNdfuhHAmYOFSzpJMjN6Mo2BoMnWL3b9brpPxtE6wB9iRPSS
LVsR024+qgGYRkCWJK7AZqzVREWbCsNdgu88QHeDhSvlLThaBYqCLIuZXzgd8IMt
qiHjjyVJNpckMXAh/e87dB2VMmyxGgt/qP0rf9Isg0Bn6bu5bOQxTLRw61seFxvV
Q9aVmxmCVN3SFabpgE7+X+KoQVZoS+HHc3b8wTDiMScmUXOsEHhkXTLLU1/YUjOk
sZoMeSa8VDMUh8USu8YDDEEyl95g+JB414YUBSlryPeOKns2FUAZQ27yHS/ETZ28
dyJvsR8i5MD8/8D3YaI58UjPkRmYK1fYd6BUrCtWU1q1ftff9PebL6/CVXdW86MV
5FuGGKk1XVcjw90JVTz8/w6YrCJMKqNrVk1KO/JaSXLUxRws35s=
=+F/Z
-END PGP SIGNATURE-
Author: Daniel Leidert
Subject: Use x11 backend by default
--- a/zbarcam/zbarcam-gtk.c
+++ b/zbarcam/zbarcam-gtk.c
@@ -147,6 +147,7 @@
{
const char *video_arg = NULL;
+gdk_set_allowed_backends ("x11,*");
gtk_init(, );
if(argc > 1)
Bug#994097: osmpbf 1.5.0-1+b1 flagged for acceptance
package release.debian.org tags 994097 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: osmpbf Version: 1.5.0-1+b1 Explanation: binary rebuild
Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40
Hello Jonathan, > Yes please go ahead, you're very welcome, feel free to add yourself as > an uploader too if you'd like. Awesome, I was trying to add the upstream and pristine-tar branches to the repo but it's not looking good so far. Would you be ok with me resetting the git repo with "gbp import-dscs --debsnap gnome-shell-extension-system-monitor" and working on top of that? We would lose the previous commits but I believe it will make contributions easier in the long run. Thank you! -- Samuel Henrique
Bug#896460: Please package ipywidgets 7
Indeed. qa.d.o betrays me. The answer to this was delayed because I considered several times what it should actually be. The _python_ side of ipywidgets has never been a problem, but the JS/browser side has grown in complexity considerably in recent years, and shows little sign of slowing down. The debian javascript situation has improved somewhat - it was possible to significantly simplify the labyrinthine custom build infinity0 did for ipywidgets 6 in 6.0.0-8 to mostly use logic from pkg-js-tools, and having recent versions of eg, webpack helps a lot. I don't think however there is really a useful way of providing "only" the python side of ipywidgets in debian. It's already a concern that needing to unvendor javascript and hack build processes results in a substandard experience in eg, jupyter-notebook, and I don't think it's viable to ship ipywidgets unless we can get something resembling full functionality. The javascript side is blocked on jupyterlab (#934258). I know jpuydt has done some work on it in the past, but I don't know the current state. Some other signficant building blocks like lumino (ex-phosphorjs) are now packaged. It might be possible to vendor only the needed bits of jupyterlab, as was recently necessary in jupyter-notebook (CVE fix requiring multiple new dependencies), but I think that illustrates the issue. While the python side of jupyter proves tractable, the web application side is a large, fast moving target which I have concerns about our ability to really keep up and provide a good user experience. I will certainly _attempt_ to get ipywidgets up to date during this cycle. But given missing dependencies and the time likely to be required, I don't think I can guarantee it. If it cannot be updated in a reasonable period of time, I think the question of whether it is better to drop it might arise. I appreciate there are dependencies, although I think most of them are ultimately optional. Gordon On Sun, Sep 19, 2021 at 10:52:39PM -0400, Sandro Tosi wrote: > Hello Gordon, > you've been active uploading several packages of the ipython stack in > the last few days: can you provide an update regarding ipywidgets too? > thanks > > On Sun, Sep 12, 2021 at 12:01 PM Sandro Tosi wrote: > > > > Hello Gordon, > > > > On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen wrote: > > > Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 > > > doctests to fail. > > > > do you have any plan to update ipywidgets to 7+ anytime soon? the > > upstream version currently in sid is severely outdated, being released > > more than 4 years ago! > > > > Several packages are requiring ipywidgets 7 and the lack of it in > > Debian is hold several maintainers back from updating their packages > > (I have 3 myself alone). > > > > This bug was open more than 3 years ago: please provide an update on a > > timeline for ipywidgets 7 for debian, so that we can plan accordingly. > > > > Thanks, > > Sandro > > > > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi
Bug#994839: ch-upgrading.en.html#sufficient-space: a suggestion.
Package: release-notes Severity: normal Tags: patch At https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#sufficient-space steps 1, 2 and 3 for using a temporary /var/cache/apt/archives work fine for me. At step 4 I do 'mount' and get /dev/sdc1 on /media/usbkeys type ext4 (rw,relatime) /dev/sdc1 on /var/cache/apt/archives type ext4 (rw,relatime) It would seem to me that step 4 should be advising umount /var/cache/apt/archives Cheers, Brian.
Bug#994815: exim4: Helo command rejected: need fully-qualified hostname
Please check whether your system is correctly configured to find the host name. Information can be found on https://wiki.debian.org/PkgExim4UserFAQ#How_does_exim_find_out_its_host_name_to_use_in_HELO.2FEHLO.3F Please report back about your results. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#994798: util-linux FTBFS: configure: error: raw selected, but required raw.h header file not available
Hi Chris, On Tue, Sep 21, 2021 at 02:59:53PM +0200, Chris Hofstaedtler wrote: > Indeed. Linux commit: > https://github.com/torvalds/linux/commit/603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093 > > Thanks for reporting! I will disable the raw(8) tool. Beware that raw is essential. Worse, it is really hard to find in scripts and other things due to its short name. Removing it will be non-trivial. I suggest asking d-devel@l.d.o for confirmation first. debianutils has dropped tempfile and that didn't go too well. Also adding NEWS likely is helpful. As much as I hope that nobody uses raw, I don't believe it. Better communicate this well than receive a tech-ctte bug over it. Helmut
Bug#994837: gyp: Please add doc
Package: gyp Version: 0.1+20200513gitcaa6002-2 Severity: minor Control: block -1 by 992976 Dear Maintainer, Please add the following uscan version=4 opts=\ mode=git,\ pretty=0.1+%cdgit%h,\ dversionmangle=auto \ https://chromium.googlesource.com/external/gyp HEAD group opts=\ mode=git,\ pretty=0.1+%cdgit%h,\ dversionmangle=auto,component=md-pages \ https://chromium.googlesource.com/external/gyp ref/heads/md-pages group
Bug#994833: OpenCL programs abort when intel-opencl-icd is installed
Package: intel-opencl-icd Followup-For: Bug #994833 Downgrading ONLY intel-opencl-icd to version 20.44.18297-1 leads to a different error: Abort was called at 41 line in file: /build/intel-compute-runtime-7vSeZ9/intel-compute-runtime-20.44.18297/shared/source/built_ins/built_ins.cpp Aborted Downgrading ALSO libigc1 and libigdfcl1 to version 1.0.5353.1-2 makes the package usable again. This makes me suspect that the issue is in those libraries instead. Running clinfo with OCL_ICD_VENDORS=/etc/OpenCL/vendors/intel.icd LD_DEBUG=libs gives me the following = 342713: find library=libOpenCL.so.1 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libOpenCL.so.1 342713: 342713: find library=libdl.so.2 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libdl.so.2 342713: 342713: find library=libc.so.6 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libc.so.6 342713: 342713: 342713: calling init: /lib64/ld-linux-x86-64.so.2 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libc.so.6 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libdl.so.2 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 342713: 342713: 342713: initialize program: clinfo 342713: 342713: 342713: transferring control: clinfo 342713: 342713: find library=libpthread.so.0 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libpthread.so.0 342713: 342713: find library=libigdgmm.so.11 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libigdgmm.so.11 342713: 342713: find library=libstdc++.so.6 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 342713: 342713: find library=libm.so.6 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libm.so.6 342713: 342713: find library=libgcc_s.so.1 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/lib/x86_64-linux-gnu/libgcc_s.so.1 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libpthread.so.0 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libgcc_s.so.1 342713: 342713: 342713: calling init: /lib/x86_64-linux-gnu/libm.so.6 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libstdc++.so.6 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libigdgmm.so.11 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/intel-opencl/libigdrcl.so 342713: 342713: find library=libigfxdbgxchg64.so [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libigfxdbgxchg64.so 342713: 342713: find library=libigfxdbginfo.so [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libigfxdbginfo.so 342713: 342713: find library=libelfdwarf.so [0]; searching 342713: search cache=/etc/ld.so.cache 342713: trying file=/usr/lib/x86_64-linux-gnu/libelfdwarf.so 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libelfdwarf.so 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libigfxdbginfo.so 342713: 342713: 342713: calling init: /usr/lib/x86_64-linux-gnu/libigfxdbgxchg64.so 342713: 342713: find library=libigdml.so.1 [0]; searching 342713: search cache=/etc/ld.so.cache 342713: search
Bug#991967: #991967: Simply ACPI powerdown/reset issue?
On 9/21/2021 9:13 AM, Chuck Zmudzinski wrote: On 9/20/2021 10:37 PM, Elliott Mitchell wrote: On Mon, Sep 20, 2021 at 10:23:39PM -0400, Chuck Zmudzinski wrote: On 9/20/21 7:39 PM, Diederik de Haas wrote: On dinsdag 21 september 2021 01:15:15 CEST Elliott Mitchell wrote: Merely having the path is a sufficiently strong indicator for me to simply wave it past. I though would suggest Debian should instead cherry-pick commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8. This is available as a patch at: https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=0f089bbf43ecce6f27576cb548ba4341d0ec46a8 You probably then also want the following commit, which is a fix on that patch: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b Found that via the following url/query: https://xenbits.xen.org/gitweb/?p=xen.git=search=HEAD=commit=x86%2FACPI I don't know whether others should be used from that as well. I tried these two commits (adapted for the xen-4.14 branch) but this approach did not fix the bug - with these patches applied the dom0 did not power down. My advice for the Debian Xen Team is to consult with upstream and get their advice on whether or not it is advisable for Debian to retain the patches from the Xen-4.16 branch that have been added to the Debian 4.14 package in an attempt to support some arm devices that panic during on an unpatched Xen-4.14. If upstream cannot help Debian backport fixes for arm panics from Xen-4.16/unstable to Xen-4.14 stable, I think the Debian Xen team should remove aggressive patches that really have now turned the Debian Xen-4.14 package into a Frankenstein version that is a mixture of Xen-4.14 and Xen-4.16, and decide that support for those arm devices must wait until Debian gets Xen 4.16 up and running on the unstable and hopefully soon, testing distribution. It is still not established you're running into #991967. Unless the one you're pointing towards was backported to the Xen 4.11 packages (which I doubt) it cannot explain #991967, since at the time 4.11 was in use. Could be this is a second bug with symptoms similar to #991967. Now that a fix for the second bug has been identified, you might try a 4.19.181-1 kernel and see whether that fixes things. FWIW, I tried this. Sorry, not only does this not fix things, when I shutdown the dom0 running with the official Debian 4.19.181-1 kernel on the current official Debian Xen-4.14 hypervisor, the dom0 not only did not power off, it did not even reach the systemd poweroff target. Slight correction - after a few minutes, it did finally reach the systemd poweroff target, but the power did not turn off. Yet, it works perfectly on the official Debian Xen-4.11 hypervisor. Again, my tests cannot confirm that there is a bug in src:linux, the only common denominator for this bug in all my testing is src:xen, the and it appears in all the 4.14 Xen versions for bullseye, for every single Linux version tested. Chuck
Bug#991967: #991967: Simply ACPI powerdown/reset issue?
On 9/20/2021 10:37 PM, Elliott Mitchell wrote: On Mon, Sep 20, 2021 at 10:23:39PM -0400, Chuck Zmudzinski wrote: On 9/20/21 7:39 PM, Diederik de Haas wrote: On dinsdag 21 september 2021 01:15:15 CEST Elliott Mitchell wrote: Merely having the path is a sufficiently strong indicator for me to simply wave it past. I though would suggest Debian should instead cherry-pick commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8. This is available as a patch at: https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=0f089bbf43ecce6f27576cb548ba4341d0ec46a8 You probably then also want the following commit, which is a fix on that patch: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b Found that via the following url/query: https://xenbits.xen.org/gitweb/?p=xen.git=search=HEAD=commit=x86%2FACPI I don't know whether others should be used from that as well. I tried these two commits (adapted for the xen-4.14 branch) but this approach did not fix the bug - with these patches applied the dom0 did not power down. My advice for the Debian Xen Team is to consult with upstream and get their advice on whether or not it is advisable for Debian to retain the patches from the Xen-4.16 branch that have been added to the Debian 4.14 package in an attempt to support some arm devices that panic during on an unpatched Xen-4.14. If upstream cannot help Debian backport fixes for arm panics from Xen-4.16/unstable to Xen-4.14 stable, I think the Debian Xen team should remove aggressive patches that really have now turned the Debian Xen-4.14 package into a Frankenstein version that is a mixture of Xen-4.14 and Xen-4.16, and decide that support for those arm devices must wait until Debian gets Xen 4.16 up and running on the unstable and hopefully soon, testing distribution. It is still not established you're running into #991967. Unless the one you're pointing towards was backported to the Xen 4.11 packages (which I doubt) it cannot explain #991967, since at the time 4.11 was in use. Could be this is a second bug with symptoms similar to #991967. Now that a fix for the second bug has been identified, you might try a 4.19.181-1 kernel and see whether that fixes things. FWIW, I tried this. Sorry, not only does this not fix things, when I shutdown the dom0 running with the official Debian 4.19.181-1 kernel on the current official Debian Xen-4.14 hypervisor, the dom0 not only did not power off, it did not even reach the systemd poweroff target. Yet, it works perfectly on the official Debian Xen-4.11 hypervisor. Again, my tests cannot confirm that there is a bug in src:linux, the only common denominator for this bug in all my testing is src:xen, the and it appears in all the 4.14 Xen versions for bullseye, for every single Linux version tested. Chuck
Bug#992149: firmware-sof: Internal microphone (DMIC) not working on Lenovo Thinkpad 13S
❦ 21 September 2021 18:03 +03, Andrei POPESCU: >> The work-around is presented here: >> https://github.com/thesofproject/linux/issues/2460#issuecomment-779212719 >> >> In a nutshell, a binary blob is offered there to replace the file >> sof-hda-generic-2ch.tplg in firmware-sof-signed. >From my understand, this would break all laptops where the mic is on PDM0. It seems the infrastructure to detect PDM0 or PDM1 is not here yet. -- Make sure every module hides something. - The Elements of Programming Style (Kernighan & Plauger)
Bug#994741: regression tests: skipped vs failed
Come on, inkscape 1.0 is not _that_ buggy. It has been around for a whole year (with a few fixing releases in-between), and it's the version present in Debian 11. If it really has grave bugs (I really mean grave), then those should be filed separately, and I should work on getting them fixed as patches on top of 1.0.2. Then, concerning the ftbfs of 1.1. I know of it of course. Just that I've been busy over the past month. I'm as weirded out by that test failure as you, especially since I couldn't reproduce it anywhere else. But no, I'm not going to ignore a test failure just because it's skipped in other architectures for different reasons: I'll need more convincing reasons. If you'd like other bugs in inkscape 1.1: opposed to 1.0.2 it's doing some kind of unaligned memory access somewhere (yet to debug), which makes it crash on armhf when run on arm64 hardware. I was basically forced to ignore that test failure on Ubuntu and that annoyed me enough, I really don't want to ignore tests just because it's convenient for somebody. On Tue, 21 Sep 2021, 6:51 pm , wrote: > On Tue, 21 Sep 2021 18:57:41 +0300 > Andrius Merkys wrote: > > > I cannot reproduce the failure myself on amd64. I tried building on a > > machine without a display, and yet the test succeeds. I will try a > > porterbox next. > > If the test succeeds, is the overall build then successful? Is that the > cause of the amd64 build failure on the autobuild systems? > > If so, then cannot this problem be temporarily fixed by ignoring the > test result on amd64, also? If it's acceptable to not run the test at > all on 32-bit architectures, and to ignore the result on 64-bit BE > architectures, then it cannot really be that important for 64-bit LE > architectures. > > By temporarily ignoring the test result, the immediate problem can be > solved: Inkscape v1.1 is not currently available for amd64 and other > 64-bit LE systems. Having temporarily disabled this test, the actual > cause of the failure can then be investigated at anybody's convenience, > without further delaying the availability of the Inkscape distribution > package. > > Inkscape v1.0.2 is REALLY buggy. This needs to be fixed soon. > >
Bug#994836: exim: dpkg fatal error due to Debian-exim in statoverride
Package: exim Severity: important whilst trying to install build-deps for therion in an unstable chroot i.e apt source therion (6.0.2ds1-3 is downloaded) cd therion-6.0.2ds1 sudo apt --no-install-recommends build-dep . I got (after downloading 887MB of stuff, (304MB, 270 packages)): debconf: delaying package configuration, since apt-utils is not installed dpkg: unrecoverable fatal error, aborting: unknown system group 'Debian-exim' in statoverride file; the system group got removed before the override, which is most probably a packaging bug, to recover you can remove the override manually with dpkg-statoverride E: Sub-process /usr/bin/dpkg returned an error code (2) E: Failed to process build dependencies That's quite bad. Debian-exim is indeed mentionned in the override file. $ cat /var/lib/statoverride: root crontab 2755 /usr/bin/crontab root Debian-exim 640 /etc/exim4/passwd.client root messagebus 4754 /usr/lib/dbus-1.0/dbus-daemon-launch-helper these exim* packages are installed: $ dpkg -l | grep exim ii exim4-base 4.94-9+b1 arm64 support files for all Exim MTA (v4) packages ii exim4-config 4.94-9 all configuration for the Exim MTA (v4) ii exim4-daemon-light 4.94-9+b1 arm64 lightweight Exim MTA (v4) daemon The set of pakcages being changed is: The following packages were automatically installed and are no longer required: libdav1d4 libwavpack1 Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: libavresample4 The following NEW packages will be installed: ca-certificates-java catch2 default-jdk default-jdk-headless default-jre default-jre-headless default-libmysqlclient-dev faketime fonts-urw-base35 gcc-11-base gdal-data gfortran-10 ghostscript ibverbs-providers imagemagick imagemagick-6-common imagemagick-6.q16 java-common libaom-dev libarmadillo-dev libarmadillo10 libarpack2 libarpack2-dev libavcodec-dev libavformat-dev libavutil-dev libblas-dev libboost-dev libboost1.74-dev libbrotli-dev libcfitsio-dev libcfitsio9 libdap-dev libdap27 libdapclient6v5 libdapserver7v5 libdav1d-dev libdav1d5 libde265-0 libde265-dev libdeflate-dev libdeflate0 libegl-dev libeigen3-dev libevdev2 libevent-core-2.1-7 libevent-dev libevent-extra-2.1-7 libevent-openssl-2.1-7 libevent-pthreads-2.1-7 libfabric1 libfaketime libfmt-dev libfmt7 libfontconfig-dev libfontconfig1-dev libfreetype-dev libfreetype6-dev libfreexl-dev libfreexl1 libfyba-dev libfyba0 libgdal-dev libgdal29 libgeos-3.9.1 libgeos-c1v5 libgeos-dev libgeotiff-dev libgeotiff5 libgfortran-10-dev libgif-dev libgif7 libgl-dev libgl1-mesa-dev libgl2ps-dev libgl2ps1.4 libgles-dev libgles1 libgles2 libglew-dev libglew2.1 libglu1-mesa libglu1-mesa-dev libglvnd-core-dev libglvnd-dev libglx-dev libgs9 libgs9-common libgudev-1.0-0 libhdf4-0-alt libhdf4-alt-dev libhdf5-mpi-dev libhdf5-openmpi-103-1 libhdf5-openmpi-cpp-103-1 libhdf5-openmpi-dev libhdf5-openmpi-fortran-102 libhdf5-openmpi-hl-100 libhdf5-openmpi-hl-cpp-100 libhdf5-openmpi-hl-fortran-100 libheif-dev libheif1 libhwloc-dev libhwloc-plugins libhwloc15 libibverbs-dev libibverbs1 libice-dev libidn12 libijs-0.35 libinput-bin libinput10 libjbig2dec0 libjs-jquery libjs-jquery-ui libjson-c-dev libjsoncpp-dev libjsoncpp24 libkml-dev libkmlbase1 libkmlconvenience1 libkmldom1 libkmlengine1 libkmlregionator1 libkmlxsd1 libkpathsea6 liblapack-dev liblqr-1-0 liblz4-dev libmagickcore-6.q16-6 libmagickwand-6.q16-6 libmariadb-dev libmariadb-dev-compat libmd4c0 libminizip-dev libminizip1 libmtdev1 libnetcdf-c++4 libnetcdf-cxx-legacy-dev libnl-3-200 libnl-3-dev libnl-route-3-200 libnl-route-3-dev libnotify4 libnspr4 libnss3 libnuma-dev libodbc1 libogdi-dev libogdi4.1 libogg-dev libopengl-dev libopengl0 libopenjp2-7-dev libopenmpi-dev libopenmpi3 libpaper-utils libpaper1 libpciaccess0 libpcre16-3 libpcre2-16-0 libpcre3-dev libpcre32-3 libpcrecpp0v5 libpcsclite1 libpmix-dev libpmix2 libpoppler-dev libpoppler-private-dev libpoppler102 libpq-dev libpq5 libproj-dev libproj19 libptexenc1 libpthread-stubs0-dev libqhull-dev libqhull-r8.0 libqhull8.0 libqhullcpp8.0 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5widgets5 librdmacm1 librttopo-dev librttopo1 libshp-dev libshp2 libsm-dev libspatialite-dev libspatialite7 libsqlite3-dev libsqlite3-tcl libsrt1.4-gnutls libsuperlu-dev libsuperlu5 libswresample-dev libswscale-dev libsynctex2 libtbb-dev libtbb2 libtcl8.6 libteckit0 libtexlua53 libtheora-dev libtk8.6 libucx0 liburiparser-dev liburiparser1 libutfcpp-dev libvtk9 libvtk9-dev libvtk9-java libvtk9-qt libwacom-common libwacom2 libwebp-dev libwebpdemux2 libwxbase3.0-0v5 libwxbase3.0-dev libwxgtk3.0-gtk3-0v5 libwxgtk3.0-gtk3-dev libx11-dev libx265-dev libxau-dev libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-randr0 libxcb-render-util0
Bug#917103: dh_elpa_test: test bytecompilability
Sean Whitton writes: > Hello, > > On Mon 20 Sep 2021 at 11:24AM -03, David Bremner wrote: > >> By the way, I realized that autopkgtest is already testing byte >> compilation, even for tests disabled via debian/elpa-test. Maybe that's >> enough, what do you think? > > Could you say more? How exactly is it testing it? > As long as Testsuite: autopkgtest-pkg-elpa is present in debian/control, the binary packages are installed and hence byte compiled. Until the upload 20210916git0-2, racket-mode [1] had this configuration with Testsuite defined, but disabled in debian/elpa-test. [1]: https://ci.debian.net/data/autopkgtest/testing/amd64/r/racket-mode/15323474/log.gz
Bug#991967: linux-src 4.19.194-3 breaks Xen Dom0 powerdown and reboot
On 9/21/21 7:22 AM, Fr. Chuck Zmudzinski, C.P.M. wrote: On Sat, 7 Aug 2021 08:40:14 +0200 Salvatore Bonaccorso wrote: > Control: tags -1 + moreinfo > > Hi, > > On Fri, Aug 06, 2021 at 11:50:54AM -0700, Elliott Mitchell wrote: > > Package: src:linux > > Version: 4.19.194-3 > > Control: affects -1 src:xen > > > > SSIA. Previous versions of 4.19 had no issues (4.19.181-1 according to > > notes), but this cropped up with 4.19.194-3 (-1 and -2 weren't tested). > > > > When a Xen domain 0 tries to reboot or powerdown the computer, it hangs > > with the display off, but the power supply is active. > > > > I'm rebuilding from source, so I imagine this also effects > > linux-image-4.19.0-17-amd64. > > Can you please try to bisect which commit introduced the issue? Does > it affect as well current upstream 4.19.201? > > Regards, > Salvatore > > Dear Salvatore, As you have noticed, much more information about this bug has been added to this bug report, but the original reporter is of the opinion that much of that new information concerns a bug related to but distinct from the bug he reported. Both bugs have the same symptom: dom0 does not power down when shutting down the system, and it is clear that both bugs are related to x86 acpi code in either the Linux kernel or in the Xen hypervisor. But I cannot reproduce his original bug which occurred in Linux 4.19.194-3 on Xen-4.11 from buster. I have only seen the bug in Xen-4.14 for bullseye, and I always see it with Xen-4.14 regardless of the Linux kernel version. As far as I can tell, another participant in this bug report has reproduced the behavior I am seeing, but not the behavior the original reporter is seeing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#54 Would you endorse the original reporter's belief that there are two distinct bugs being discussed here? If so, I would be inclined to report the bug I am seeing as a distinct but related bug in the bullseye version of src:xen. Otherwise, I respectfully ask that you reclassify this as a bug in src:xen, since the original reporter has not been able to identify a commit in src:linux that caused the bug and no one has been able to reproduce the bug on Xen-4.11/Linux-4.19.194-3. Regards, Chuck Zmudzinski Allow me to propose the following arguments in favor of changing this to a bug in src:xen: 1) The original report of this bug in src:linux version 4.19.194-3 with Xen 4.11 has not been reproduced by anyone. 2) The same symptom has been reproduced in recent versions of src:xen for bullseye, with Xen version 4.14.x 3) For the future, what is the point of trying to fix a bug in oldstable? Why not concern ourselves with fixing the bug as it now appears in stable? Regards, Chuck Zmudzinski
Bug#925473: tomcat9: sysvinit script missing
Ondrej Zary dixit: >Hello, why tomcat9 still does not have an init script despite it has >been posted here? > >I'm upgrading a Stretch server without systemd to Buster. Tomcat 9 is >installed but cannot be started without an init script. Mostly because Emmanuel insists on using systemd’s abstraction to create the user account, despite a working, tested, alternative I offered to maintain and be responsible for exists. The “sysvinit” branch contains a working version of the package which I update from time to time. I’m also publishing builds of that here: http://www.mirbsd.org/~tg/Debs/dists/bullseye/lts/Pkgs/tomcat9/ This is the “wtf-lts” repo on Wouter’s extrepodata. The package contains the init script, the user management logic that actually works across *all* *supported* Debian configurations instead of just an *arbitrary* subset of those, and some instructions for nōn-systemd users in logging.properties (the default logging is configured for systemd) and README.Debian (specifically noting that some of the applied hardening is systemd-specific, but compared to stretch/sysvinit you’re not worse off, security-wise, so…). I have no idea why Emmanuel, the primary maintainer, has been set so strongly against merging this patch for as long as I promise to take care of it and deal with any related fallout (maybe some systemd fan paid him) but this is what is, and that GR outcome is interpreted as Emmanuel being able to block this indefinitely despite nōn-systemd continuing to be a supported way of running Debian (albeit not without UsrMove in bookworm/sid). bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#994741: regression tests: skipped vs failed
On 2021-09-21 18:03, ian_br...@mail.ru wrote: It appears that my assumption that this regression test failure was the cause of the overall build failure on amd64, was incorrect. According to the build logs, this test also fails on ppc64 and sparc64, and yet the builds for those architectures have apparently succeeded. Actually, build logs show failure of this test case both on amd64 and ppc64, to name a few, but on ppc64 this failure is intentionally ignored [1]: ifeq ($(DEB_HOST_ARCH_ENDIAN),little) dh_auto_test -a --no-parallel else # the testsuite fails on BE. https://gitlab.com/inkscape/inkscape/-/issues/1365 -dh_auto_test -a --no-parallel endif (ppc64 is BE = Big Endian) However, I cannot reproduce the failure myself on amd64. I tried building on a machine without a display, and yet the test succeeds. I will try a porterbox next. [1] https://sources.debian.org/src/inkscape/1.1-1/debian/rules/ Best, Andrius
Bug#994835: vice: Fails to build -- missing JPEG support
Package: vice Version: 3.5.0.dfsg-3 Severity: serious Tags: ftbfs Justification: ftbfs checking for png.h... yes checking for png_sig_cmp in -lpng... yes checking for jpeglib.h... no configure: error: JPEG support is missing make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 1 make[1]: Leaving directory '/build/vice-3.5.0.dfsg' make: *** [debian/rules:60: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 I: copying local configuration Best regards Alastair -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#917103: dh_elpa_test: test bytecompilability
Hello, On Mon 20 Sep 2021 at 11:24AM -03, David Bremner wrote: > By the way, I realized that autopkgtest is already testing byte > compilation, even for tests disabled via debian/elpa-test. Maybe that's > enough, what do you think? Could you say more? How exactly is it testing it? -- Sean Whitton signature.asc Description: PGP signature
Bug#992842: Slow stop due to killproc in /etc/init.d/nagios4
Control: reassign -1 nagios4-common 4.3.4-3 On Ma, 24 aug 21, 09:18:31, Benoit DOLEZ wrote: > Package: nagios4-common Version: 4.3.4-3 Fixing affected package(s) and version due to mangled line breaks. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#992790: Severity: High / Bug on Debian 11 Bullseye - Boot problem - Failed to start Load/Save RF Kill Switch Status
Control: reassign -1 src:linux 5.10.46-4 On Lu, 23 aug 21, 15:38:42, pham...@bluewin.ch wrote: > Package: Kernel > Version: Linux station 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) > x86_64 GNU/Linux > Bug Description: > > After a new install I can't boot normally. > I have to start in recovery mode to be able to get to the login window. > Attachement : > Config : inxi -Fxxxz > - Two print screen of boot > - Boot logs : dmesg, journalctl, journalctl -p err > Best regards. > > Philippe Reassigning to correct package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#992340: network.service error after fresh install
Control: reassign -1 ifupdown On Ma, 17 aug 21, 14:11:51, Alex wrote: > Package: network.service > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > Fresh install of Debian 11 Live ISO with non-free firmware. Error messages > occured aftr fresh install - systemctl status network.service displayed error > message that dhclient had issues during start. > I traced the error back to the unit file of systemd network.service - the > command "ifup -a --read-environment" lead to the error, because the file > /etc/network/interface.d/setup had eth0 as general > network interface. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > I replace eth0 in the file /etc/network/interface.d/setup with the correct > network interface identifier "enp7...". > >* What was the outcome of this action? > This particular error message was gone after the changes that I applied. > > > > -- System Information: > Debian Release: 11.0 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled Reassigning to correct package. Please note you can use 'reportbug /path/to/file' to have reportbug find out the correct package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#994808: upgrade issue
Control: tags -1 + patch Hello, I created Merge Request to fix this issue: https://salsa.debian.org/debian/atftp/-/merge_requests/1 I tested this patch and uploaded it in Kali Linux while waiting for a fix in Debian. I hope it can be merged so we can drop our fork. Thanks Sophie
Bug#992287: progess-linux-desktop: Please remove dependency alternative exfat-fuse and exfat-utils
Control: reassign -1 progress-linux-desktop 20210101-2 On Lu, 16 aug 21, 21:37:39, Sven Hoexter wrote: > Package: progess-linux-desktop > Version: 20210101-2 > Severity: normal > > Hi Daniel, > I would like to drop exfat-fuse and exfat-utils within the next release cycle. > Would be nice if you could drop them completely from this meta package. > I do not consider this one a blocker for myself due to the fact that you > already list exfatprogs as the first choice. > > Cheers, > Sven > > -- System Information: > Debian Release: 11.0 > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled Fixing typo in package name. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#994745: ifupdown: "ifup --read-environment" does not honor $EXCLUDE_INTERFACES
Control: tags -1 + pending El 20/09/21 a las 12:04, Adam Stephens escribió: > Package: ifupdown > Version: 0.8.36+nmu1 > Severity: normal > Tags: patch > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > ifdown does not correctly handle excluded interfaces passed in > $EXCLUDE_INTERFACES: > # EXCLUDE_INTERFACES="lo" /sbin/ifdown lo --read-environment -n > run-parts /etc/network/if-down.d > ip link set dev lo down > run-parts /etc/network/if-post-down.d > > This appears to be caused by an issue copying the value of the > environment variable into excludint … Thanks. Patch applied in the 994745 git branch. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#992305: Only one nic works at a time when installing Debian 11 and Gui (gnome)
Control: reassign -1 installation-reports On Lu, 16 aug 21, 17:56:44, joebeasley...@gmail.com wrote: > Package: > Version: <11> > > Fresh Gui install. Two nics on different networks. If I enable one with > network manager in gnome, it disables the other one. Re-enable the one > it disabled, and it disables the other one?? > Turns out this was a graphical install that created file called > ens3.nmconnection in /etc/NetworkManager/system-connections. I removed > this file and rebooted. Both nics can now be enabled at the same time. > A Text install creates a file called "Wired Connection 1" in the same > folder. Removed it to resolve. > Looks like these files get created if you install a graphical desktop > (gnome) during the install. Three different installs, same results. > I did a text install with no gui, then installed the gnome desktop > after reboot. No issues. > > This is a virtual machine install running on an Ubuntu 18.04.1. Kernel > 5.4.0-77-generic #86~18.04.2-Ubuntu SMP. 64 Gigs Ram. > qemu-kvm version 1:2.11_dfsg-1ubuntu7.37 > > Debian ISO debian-11.0.0-amd64-netinst.iso > size 395.3 MB > md5sum 499953266841cae41612310e65659456 > sha256sum ae6d563d2444665316901fe7091059ac34b8f67ba30f9159f7cef7d2fdc5b > f8a > > > Installs: > Debian Gnu/linux 11 (bullseye) x86_64 > kernel 5.10.0-8-amd64 > shell: bash 5.1.4 Reassigning to correct (pseudo-)package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#992149: firmware-sof: Internal microphone (DMIC) not working on Lenovo Thinkpad 13S
Control: reassign -1 src:firmware-sof 1.7-1 Fixing typo in package name, full quote below for convenience of package Maintainer. Kind regards, Andrei On Vi, 13 aug 21, 12:55:44, Mike Gabriel wrote: > Package: src:firwmare-sof > Severity: important > Version: 1.7-1 > > I just upgraded a notebook to a fresh Debian 11 system (I started the system > with Debian testing +/- a year ago). > > The notebook device is a Lenovo Thinkpad 13S. A year ago, I turned the > dsp_driver on to work-around the firmware-sof package not having been > provided in Debian back then: > > ``` > cat /etc/modprobe.d/no-sof.conf > # play sound without the SOF firmware > options snd_intel_dspcfg dsp_driver=1 > ``` > > One complaint of the customer who owns the notebooks then was, that the > internal microphone was not usable with those machines. > > Today, I looked at switching to using the SOF firmware with the > snd_hda_intel driver and disable the fallback DSP driver again: > > ``` > cat /etc/modprobe.d/with-sof.conf > # play sound without the SOF firmware (this is the kernel's default) > options snd_intel_dspcfg dsp_driver=0 > ``` > > With SOF, I was able to see the onboard DMIC microphone, but the microphone > does not have any input signal. (And yes, I know how to enable/use > microphones on computer, with and without pulseaudio). > > I then found a post on the SOF project's upstream bug tracker, that provided > me with a work-around solution and I wonder if the related fix might be a > bullseye-pu upload candidate: > > The work-around is presented here: > https://github.com/thesofproject/linux/issues/2460#issuecomment-779212719 > > In a nutshell, a binary blob is offered there to replace the file > sof-hda-generic-2ch.tplg in firmware-sof-signed. > > After a reboot, with that firmware file replaced, the onboard DMIC works and > has become usable. > > The related upstream PR is: > https://github.com/thesofproject/sof/pull/3847 > > The PR never got applied, as it got closed when upstream's master branch got > renamed to "main". Noone ever cared for reopening that PR. > > To clarify the situation, I pinged the PR submitter and upstream via: > https://github.com/thesofproject/linux/issues/2460#issuecomment-898423772 > > It would be awesome to get a fixed firmware-sof version (which then also > works for the Lenovo Thinkpad 13S) into Debian 11.1. Let me know if I can > assist with anything around fixing this bug. Thanks. > > Thanks+Greets, > Mike > > > > -- > > DAS-NETZWERKTEAM > c\o Technik- und Ökologiezentrum Eckernförde > Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde > mobile: +49 (1520) 1976 148 > landline: +49 (4351) 850 8940 > > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 > mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de > -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#992131: R8169 CRASH! (rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100))
Control: reassign -1 src:linux 5.10.46+4 On Jo, 12 aug 21, 16:37:47, Vincenzo Gianfelice wrote: > Package: r8169 There is no such package, you probably meant the kernel (guessing the version from your output below). Full quote follows for convenience of kernel maintainers. Kind regards, Andrei > Kernel: 5.10.0-8 (amd64) > > System: Debian 11 (bullseye) > > libc: 2.31 > > Hi. I state that this problem is present from kernel 5.4 and still has > not been fixed ... suddenly, the ethernet stops working and this error > appears (in dmesg): > > > [ 12.063469] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out > [ 12.063509] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:467 > dev_watchdog+0x24d/0x260 > [ 12.063520] Modules linked in: joydev hid_logitech_hidpp uvcvideo > videobuf2_vmalloc hid_gener > ic videobuf2_memops videobuf2_v4l2 videobuf2_common snd_usb_audio > videodev snd_usbmidi_lib snd_r > awmidi usbhid snd_seq_device mc hid intel_rapl_msr intel_rapl_common > rfkill snd_hda_codec_realte > k snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel > snd_intel_dspcfg x86_pkg_ > temp_thermal soundwire_intel intel_powerclamp > soundwire_generic_allocation snd_soc_core coretemp > snd_compress soundwire_cadence kvm_intel snd_hda_codec snd_hda_core > nvidia_drm(POE) mei_hdcp kvm > snd_hwdep soundwire_bus irqbypass drm_kms_helper snd_pcm rapl > intel_cstate snd_timer iTCO_wdt m > ei_me snd intel_pmc_bxt iTCO_vendor_support intel_uncore mei watchdog > soundcore ee1004 sg intel_ > wmi_thunderbolt pcspkr cec nvidia_modeset(POE) evdev acpi_pad > intel_pmc_core nvidia(POE) corefre > qk(OE) parport_pc ppdev drm lp parport fuse configfs ip_tables > x_tables autofs4 ext4 crc16 mbcac > he jbd2 crc32c_generic uas usb_storage sd_mod > [ 12.063805] t10_pi crc_t10dif crct10dif_generic crct10dif_pclmul > crct10dif_common crc32_pclm > ul crc32c_intel ahci libahci ghash_clmulni_intel libata xhci_pci > scsi_mod xhci_hcd aesni_intel i > 2c_i801 i2c_smbus usbcore r8169 libaes crypto_simd realtek mdio_devres > cryptd libphy glue_helper > usb_common wmi fan video button > [ 12.063917] CPU: 3 PID: 0 Comm: swapper/3 Tainted: P OE > 5.10.0-8-amd64 #1 Debia > n 5.10.46-4 > [ 12.063922] Hardware name: Gigabyte Technology Co., Ltd. > H110M-S2H/H110M-S2H-CF, BIOS F24 12/ > 14/2017 > [ 12.063933] RIP: 0010:dev_watchdog+0x24d/0x260 > [ 12.063941] Code: 29 cb fd ff eb a9 4c 89 f7 c6 05 72 b7 10 01 01 > e8 b8 a0 fa ff 44 89 e9 4c > 89 f6 48 c7 c7 40 8d d6 93 48 89 c2 e8 d6 24 14 00 <0f> 0b eb 8a 66 66 > 2e 0f 1f 84 00 00 00 00 0 > 0 0f 1f 40 00 0f 1f 44 > [ 12.063947] RSP: 0018:a1590018ceb8 EFLAGS: 00010286 > [ 12.063957] RAX: RBX: 8eea4c5ba800 RCX: > 083f > [ 12.063963] RDX: RSI: 00f6 RDI: > 083f > [ 12.063972] RBP: 8eea4b5043dc R08: R09: > a1590018ccd8 > [ 12.063978] R10: a1590018ccd0 R11: 942cb3e8 R12: > 8eea4b504480 > [ 12.063983] R13: R14: 8eea4b504000 R15: > 8eea4c5ba880 > [ 12.063990] FS: () GS:8eecaecc() > knlGS: > [ 12.063995] CS: 0010 DS: ES: CR0: 80050033 > [ 12.064001] CR2: 5624fe890068 CR3: 000103f06006 CR4: > 003706e0 > [ 12.064006] DR0: DR1: DR2: > > [ 12.064011] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 12.064016] Call Trace: > [ 12.064024] > [ 12.064038] ? pfifo_fast_enqueue+0x150/0x150 > [ 12.064056] call_timer_fn+0x29/0xf0 > [ 12.064063] __run_timers.part.0+0x1d3/0x240 > [ 12.064071] ? ktime_get+0x38/0xa0 > [ 12.064079] ? lapic_next_deadline+0x28/0x30 > [ 12.064087] ? clockevents_program_event+0x8d/0xf0 > [ 12.064094] run_timer_softirq+0x26/0x50 > [ 12.064103] __do_softirq+0xc5/0x275 > [ 12.064111] asm_call_irq_on_stack+0xf/0x20 > [ 12.064117] > [ 12.064126] do_softirq_own_stack+0x37/0x40 > [ 12.064136] irq_exit_rcu+0x8e/0xc0 > [ 12.064146] sysvec_apic_timer_interrupt+0x36/0x80 > [ 12.064156] asm_sysvec_apic_timer_interrupt+0x12/0x20 > [ 12.064167] RIP: 0010:cpuidle_enter_state+0xc7/0x350 > [ 12.064174] Code: 8b 3d 2d 34 d7 6c e8 a8 2a a2 ff 49 89 c5 0f 1f > 44 00 00 31 ff e8 39 35 a2 > ff 45 84 ff 0f 85 fa 00 00 00 fb 66 0f 1f 44 00 00 <45> 85 f6 0f 88 06 > 01 00 00 49 63 c6 4c 2b 2 > c 24 48 8d 14 40 48 8d > [ 12.064180] RSP: 0018:a159000dfea8 EFLAGS: 0246 > [ 12.064188] RAX: 8eecaecebc00 RBX: 0001 RCX: > 001f > [ 12.064193] RDX: RSI: 1fefa71c RDI: > > [ 12.064198] RBP: 8eecaecf5b00 R08: 0002cf095853 R09: > 0018 > [ 12.064204] R10: 0001fc29 R11: 7786 R12: > 943ae6c0 > [ 12.064208] R13: 0002cf095853 R14: 0001 R15: >
Bug#994834: perl: Memory leak in Perl version 5.32 not fixed in Debian 11.0
Subject: perl: Memory leak in Perl version 5.32 not fixed in Debian 11.0 Package: perl Version: 5.32.1-4+deb11u1 Severity: important Dear Maintainer, The current perl version in Debian 11.0 suffer of memory leak in RegEx The details of the bug and the script to reproduce can be found here. https://github.com/Perl/perl5/issues/18604 This bug is important especially for services written in perl with regex who conduct to memory outage. Could you fix this bug in the current stable Debian 11 distribution. Have a good day. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 perl depends on: ii dpkg 1.20.9 ii libperl5.32 5.32.1-4+deb11u1 ii perl-base 5.32.1-4+deb11u1 ii perl-modules-5.32 5.32.1-4+deb11u1 Versions of packages perl recommends: ii netbase 6.3 Versions of packages perl suggests: pn libtap-harness-archive-perl ii libterm-readline-gnu-perl 1.37-1 ii libterm-readline-perl-perl 1.0303-2.1 ii make 4.3-4.1 ii perl-doc 5.32.1-4+deb11u1 -- no debconf information smime.p7s Description: Signature cryptographique S/MIME
Bug#991818: Package: installation-reports RC3
Control: reassign -1 installation-reports On Lu, 02 aug 21, 07:28:48, Peter Ehlert wrote: > Package: installation-reports RC3 Hello, Reassigning to installation-reports only as there is no "RC3" package ;) Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#991967: #991967: Simply ACPI powerdown/reset issue?
On 9/20/21 10:12 PM, Chuck Zmudzinski wrote: On 9/20/21 6:29 PM, Chuck Zmudzinski wrote: On 9/20/21 1:43 PM, Chuck Zmudzinski wrote: On 9/20/21 12:27 AM, Elliott Mitchell wrote: On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote: I suspect the following patch is the culprit for problems shutting down on the amd64 architecture: 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch This patch does affect amd64 acpi code, and is probably causing the problem on my amd64 system, so my build of the xen-4.14 hypervisor without this patch fixed the problem. Of the ones listed that is the only one which has any overlap with x86 code. The next reproduction step is `apt-get source xen && patch -p1 -R < 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch && dpkg-buildpackage -b`. Then try with this to confirm that patch is what does it. Thing is that delta is rather small. I don't have a simulator, but that is rather small to be the culprit. I just tested the build with patch -p1 -R < 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch applied before building the package and I can confirm that this is the patch causing the trouble for dom0 poweroff on x86/amd64. Reverting this patch fixes it on my amd64 system. But this would probably break the arm build. I think one possible fix would require modifying 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch so it only applies at runtime to the arm architecture. I will try some modifications to the patch instead of removing it, and if I get something that works on amd64 and also might work on arm, I will post it for Elliott to try. I have an encouraging result. I found a very simple patch to xen/arch/x86/acpi/lib.c that fixes the dom0 poweroff bug on my system and it should not affect the arm patches at all: -- This patch partially reverts previous patch 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch This hopefully fixes #911976 --- a/xen/arch/x86/acpi/lib.c 2021-09-20 16:49:08.0 -0400 +++ b/xen/arch/x86/acpi/lib.c 2021-09-20 16:25:05.572038000 -0400 @@ -46,10 +46,6 @@ if ((phys + size) <= (1 * 1024 * 1024)) return __va(phys); - /* No further arch specific implementation after early boot */ - if (system_state >= SYS_STATE_boot) - return NULL; - offset = phys & (PAGE_SIZE - 1); mapped_size = PAGE_SIZE - offset; set_fixmap(FIX_ACPI_END, phys); -- Further testing with this patch revealed a problem. Although this simple patch causes dom0 to poweroff when shutting down, on the next reboot the system dropped to single-user shell because it mixed up my ssd and my hard disk. Normally the system assigns my SSD as /dev/sda and my hard disk as /dev/sdb. But on the first reboot after running the Xen hypervisor, the system reversed them so my SSD was /dev/sdb and my hard disk was /dev/sda. Since the EFI partition, which is a vfat partition, is on the SSD and in /etc/fstab I ask to mount it from the /dev/sda1 partition, it is now at /dev/sdb1, and the first partition is not a vfat partition on the hard disk so the system drops to a root shell for system maintenance. This switching of the devices on the subsequent reboot is another symptom of this bug I have seen in the past, and usually the ordinary behavior is restored on the next reboot or after resetting and powering off or unplugging from power. So this patch does not really fix the bug reliably. To clarify things, I saw this strange behavior of the system switching the disk devices with this patch under the following conditions: 1) Boot using this simple patch - dom0 shuts down properly 2) Boot using Elliott's suggested patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#94 3) It was when booting using Elliott's suggested patch that I saw the drop to single-user root for system maintenance. Moreover, Elliott's suggested patch did not fix the dom0 power off bug. So it might be the case that this simple patch would work for both amd64 and arm devices nicely, but Elliott refuses to test it with his arm devices. Sigh.
Bug#991553: Lagrange: packaging request
Control: reassign -1 wnpp Control: retitle -1 RFP: lagrange -- beautiful GUI Gemini Client On Ma, 27 iul 21, 09:19:16, Daniel wrote: > Package: lagrange > Severity: wishlist > X-Debbugs-Cc: antonucci.d...@gmail.com > > Dear Maintainers, > > I tried to found if this risks to be a duplicated entry, but it looks it is > not. > > I'd like to propose Lagrange, beautiful GUI Gemini Client, as prospect package > for the next Debian release. > > https://github.com/skyjake/lagrange > > From my knowledge Arch Linux and OpenSuse Tumbleweed are already providing > this > Gemini Client. > > Best regards, > > Daniel Reassigning to correct (pseudo-)package. Kind regards, Andrei -- Looking after bugs assigned to unknown or inexistent packages signature.asc Description: PGP signature
Bug#994151: reply from maintainer
Hi, On Tue, Sep 21, 2021 at 02:22:37PM +, okgomdjgbm...@gmail.com wrote: > > some one claims to have received an email back from the maintainer... > https://github.com/ytdl-org/youtube-dl/issues/29965#issuecomment-922377500 > > Sergey M. > 6:22 AM (10 hours ago) > to me > Hello, > Currently I have no free time to spend on > youtube-dl as I'm busy with work, ongoing > renovation and other post-relocation stuff. > Best, > Sergey. > пт, 17 сент. 2021 г. в 03:19, JD Well, given that a single maintainer confirms to have no time on a free software project, isn't it more straightforward to invite others to join that effort instead of creating a fork? Kind regards Andreas. -- http://fam-tille.de
Bug#991967: #991967: Simply ACPI powerdown/reset issue?
On 9/20/21 10:37 PM, Elliott Mitchell wrote: On Mon, Sep 20, 2021 at 10:23:39PM -0400, Chuck Zmudzinski wrote: On 9/20/21 7:39 PM, Diederik de Haas wrote: On dinsdag 21 september 2021 01:15:15 CEST Elliott Mitchell wrote: Merely having the path is a sufficiently strong indicator for me to simply wave it past. I though would suggest Debian should instead cherry-pick commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8. This is available as a patch at: https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=0f089bbf43ecce6f27576cb548ba4341d0ec46a8 You probably then also want the following commit, which is a fix on that patch: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b Found that via the following url/query: https://xenbits.xen.org/gitweb/?p=xen.git=search=HEAD=commit=x86%2FACPI I don't know whether others should be used from that as well. I tried these two commits (adapted for the xen-4.14 branch) but this approach did not fix the bug - with these patches applied the dom0 did not power down. My advice for the Debian Xen Team is to consult with upstream and get their advice on whether or not it is advisable for Debian to retain the patches from the Xen-4.16 branch that have been added to the Debian 4.14 package in an attempt to support some arm devices that panic during on an unpatched Xen-4.14. If upstream cannot help Debian backport fixes for arm panics from Xen-4.16/unstable to Xen-4.14 stable, I think the Debian Xen team should remove aggressive patches that really have now turned the Debian Xen-4.14 package into a Frankenstein version that is a mixture of Xen-4.14 and Xen-4.16, and decide that support for those arm devices must wait until Debian gets Xen 4.16 up and running on the unstable and hopefully soon, testing distribution. It is still not established you're running into #991967. Unless the one you're pointing towards was backported to the Xen 4.11 packages (which I doubt) it cannot explain #991967, since at the time 4.11 was in use. Could be this is a second bug with symptoms similar to #991967. Now that a fix for the second bug has been identified, you might try a 4.19.181-1 kernel and see whether that fixes things. I presume you are suggesting I try booting 4.19.181-1 on the current version of Xen-4.14 for bullseye as a dom0. I am not inclined to try it until an official Debian developer endorses your opinion that the bug I am seeing is distinct from #991967, at which point I will report the bug I am seeing as a new bug. Regards, Chuck Zmudzinski
Bug#994151: reply from maintainer
some one claims to have received an email back from the maintainer... https://github.com/ytdl-org/youtube-dl/issues/29965#issuecomment-922377500 Sergey M. 6:22 AM (10 hours ago) to me Hello, Currently I have no free time to spend on youtube-dl as I'm busy with work, ongoing renovation and other post-relocation stuff. Best, Sergey. пт, 17 сент. 2021 г. в 03:19, JD
Bug#925473: tomcat9: sysvinit script missing
Hi Ondrej, Installing systemd should fix this issue. Emmanuel Bourg Le 2021-09-21 12:23, Ondrej Zary a écrit : Hello, why tomcat9 still does not have an init script despite it has been posted here? I'm upgrading a Stretch server without systemd to Buster. Tomcat 9 is installed but cannot be started without an init script.
Bug#994833: OpenCL programs abort when intel-opencl-icd is installed
Package: intel-opencl-icd
Version: 21.32.20609-1
Severity: critical
Running any OpenCL-enabled program with this ICD installed leads to:
Abort was called at 42 line in file:
./shared/source/built_ins/built_ins.cpp
Aborted
The relevant backtrace is:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x77da1536 in __GI_abort () at abort.c:79
#2 0x76a13c47 in NEO::abortExecution () at
./shared/source/helpers/abort.cpp:14
#3 0x76a2ea50 in NEO::abortUnrecoverable (line=line@entry=42,
file=file@entry=0x76e5f8b8 "./shared/source/built_ins/built_ins.cpp") at
./shared/source/helpers/debug_helpers.cpp:26
#4 0x76d9f2ef in operator() (__closure=0x7fffcb90) at
./shared/source/built_ins/built_ins.cpp:42
#5 std::__invoke_impl&> (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#6 std::__invoke&> (__fn=...) at /usr/include/c++/10/bits/invoke.h:95
#7 operator() (this=) at /usr/include/c++/10/mutex:717
#8 operator() (this=0x0) at /usr/include/c++/10/mutex:722
#9 _FUN () at /usr/include/c++/10/mutex:722
#10 0x77d6aa7f in __pthread_once_slow (once_control=0x556fd9a0,
init_routine=0x77413960 <__once_proxy>) at pthread_once.c:116
#11 0x76d9f612 in __gthread_once (__func=,
__once=0x556fd9a0) at
/usr/include/x86_64-linux-gnu/c++/10/bits/gthr-default.h:700
#12 std::call_once&> (__f=..., __once=...) at
/usr/include/c++/10/mutex:729
#13 NEO::BuiltIns::getSipKernel (this=0x556fd590, type=,
type@entry=NEO::SipKernelType::Csr, device=...) at
./shared/source/built_ins/built_ins.cpp:66
#14 0x76d9fa4b in NEO::SipKernel::initBuiltinsSipKernel
(type=type@entry=NEO::SipKernelType::Csr, device=...) at
./shared/source/built_ins/sip.cpp:50
#15 0x76da0044 in NEO::SipKernel::initSipKernelImpl
(type=NEO::SipKernelType::Csr, device=...) at
./shared/source/built_ins/sip.cpp:134
#16 0x76aa0964 in NEO::Platform::initialize (this=0x556f9a10,
devices=std::vector of length 1, capacity 1 = {...}) at
./opencl/source/platform/platform.cpp:142
#17 0x76a4a94d in clGetPlatformIDs (numEntries=,
platforms=, numPlatforms=) at
./opencl/source/api/api.cpp:101
#18 0x76a4af44 in clIcdGetPlatformIDsKHR (numEntries=0, platforms=0x0,
numPlatforms=0x7fffcf00) at ./opencl/source/api/api.cpp:137
#19 0x77f470bb in khrIcdVendorAdd () from
/opt/intel/oneapi/lib/libOpenCL.so.1
#20 0x77f4bbff in khrIcdOsVendorsEnumerate () from
/opt/intel/oneapi/lib/libOpenCL.so.1
#21 0x77d6aa7f in __pthread_once_slow (once_control=0x77f4e688
, init_routine=0x77f4ba40 ) at
pthread_once.c:116
#22 0x77f47991 in clGetPlatformIDs () from
/opt/intel/oneapi/lib/libOpenCL.so.1
Note that while this is obtained when using libOpenCL.so.1, the same
error is present when using the ocl-icd loader:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x77d9e536 in __GI_abort () at abort.c:79
#2 0x76b37c47 in NEO::abortExecution () at
./shared/source/helpers/abort.cpp:14
#3 0x76b52a50 in NEO::abortUnrecoverable (line=line@entry=42,
file=file@entry=0x76f838b8 "./shared/source/built_ins/built_ins.cpp") at
./shared/source/helpers/debug_helpers.cpp:26
#4 0x76ec32ef in operator() (__closure=0x7fffcba0) at
./shared/source/built_ins/built_ins.cpp:42
#5 std::__invoke_impl&> (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#6 std::__invoke&> (__fn=...) at /usr/include/c++/10/bits/invoke.h:95
#7 operator() (this=) at /usr/include/c++/10/mutex:717
#8 operator() (this=0x0) at /usr/include/c++/10/mutex:722
#9 _FUN () at /usr/include/c++/10/mutex:722
#10 0x77f68a7f in __pthread_once_slow (once_control=0x557f7740,
init_routine=0x77408960 <__once_proxy>) at pthread_once.c:116
#11 0x76ec3612 in __gthread_once (__func=,
__once=0x557f7740) at
/usr/include/x86_64-linux-gnu/c++/10/bits/gthr-default.h:700
#12 std::call_once&> (__f=..., __once=...) at
/usr/include/c++/10/mutex:729
#13 NEO::BuiltIns::getSipKernel (this=0x557f7330, type=,
type@entry=NEO::SipKernelType::Csr, device=...) at
./shared/source/built_ins/built_ins.cpp:66
#14 0x76ec3a4b in NEO::SipKernel::initBuiltinsSipKernel
(type=type@entry=NEO::SipKernelType::Csr, device=...) at
./shared/source/built_ins/sip.cpp:50
#15 0x76ec4044 in NEO::SipKernel::initSipKernelImpl
(type=NEO::SipKernelType::Csr, device=...) at
./shared/source/built_ins/sip.cpp:134
#16 0x76bc4964 in NEO::Platform::initialize (this=0x55747bc0,
devices=std::vector of length 1, capacity 1 = {...}) at
./opencl/source/platform/platform.cpp:142
#17 0x76b6e94d in clGetPlatformIDs (numEntries=,
platforms=, numPlatforms=) at
./opencl/source/api/api.cpp:101
#18 0x76b6ef44 in clIcdGetPlatformIDsKHR (numEntries=0, platforms=0x0,
numPlatforms=0x7fffcf28) at ./opencl/source/api/api.cpp:137
#19 0x77f439f4 in
Bug#994832: numactl: fails to install with manpages-dev 5.10-1
Package: numactl Version: 2.0.12-1+b1 Severity: serious Justification: Policy 7.6.1 Unpacking numactl (2.0.14-1) over (2.0.12-1+b1) ... dpkg: error processing archive /var/cache/apt/archives/numactl_2.0.14-1_amd64.deb (--u npack): trying to overwrite '/usr/share/man/man2/move_pages.2.gz', which is also in package m anpages-dev 5.10-1
Bug#901270: trickle FTCBFS: configures for the build architecture
Hi Helmut, Helmut Grohne wrote: > trickle fails to cross build from source, because it configures for the > build architecture. The easiest way of fixing that is using > dh_auto_configure. After doing so trickle continues to fail due to its > use of AC_TRY_RUN. I have no fix for that to offer. Please consider > fixing the --host part anyway. The attached patch implements that. > Please close this bug when trickle passes --host to ./configure. That > will make the next failure more visible to interested cross builders. I did a QA upload of trickle last night rewriting most of debian/rules to use the dh sequencer and dh compat level 13. (So your patch no more applies.) I see no --host in my build log, but it now (obviously) uses dh_auto_configure. It would be nice if you could check if this cross-build issue still exists with trickle 1.07-11. If that's the case, I'll happily close your bug report and add an according bug report reference retroactively to the changelog entry in git. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#994119: vdirsyncer: Random cannot import name 'metasync' with python3.9
Control: forwarded -1 https://github.com/pimutils/vdirsyncer/issues/862 Upstream considers this issue solve with their release 0.18.0. - 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#994831: ITP: libapp-wdq-perl -- command line access to Wikidata Query Service
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name: libapp-wdq-perl Version : 0.4.4 Upstream Author : Jakob Voß * URL : https://metacpan.org/release/App-wdq * License : GPL-2 Programming Lang: Perl Description : command line access to Wikidata Query Service wdq is a command line utility for Wikidata Query Service. I find this command line utility very convenient for querying the Wikidata. Moreover, as of yet there does not seem to be an alternative for that purpose in Debian. Remark: This package is to be maintained with Debian Perl Group at https://salsa.debian.org/perl-team/modules/packages/libapp-wdq-perl Andrius
Bug#994830: ITP: python-types-dataclasses -- Typing stubs for dataclasses
Package: wnpp Severity: wishlist X-Debbugs-Cc: cru...@debian.org Subject: ITP: python-types-dataclasses -- Typing stubs for dataclasses Package: wnpp Owner: Michael R. Crusoe Severity: wishlist * Package name: python-types-dataclasses Version : 0.1.7 Upstream Author : Gary van der Merwe * URL : https://github.com/python/typeshed * License : Apache-2.0 Programming Lang: Python Description : Typing stubs for dataclasses This is a PEP 561 type stub package for the dataclasses package. It can be used by type-checking tools like mypy, PyCharm, pytype etc. to check code that uses dataclasses. The source for this package can be found at https://github.com/python/typeshed/tree/master/stubs/dataclasses. All fixes for types and metadata should be contributed there. . See https://github.com/python/typeshed/blob/master/README.md for more details. Remark: This package is maintained by Debian Python Team at https://salsa.debian.org/python-team/packages/python-types-dataclasses
Bug#978831: patch gyoto for autoconf 2.70
Thanks for the patch Étienne, very appreciated! OpenPGP_signature Description: OpenPGP digital signature
Bug#994827: ClangConfig.cmake is broken
Also, i think it would be a very good idea to ensure that this also works in -13 packages. It seems to work in -12 packages though. Roman On Tue, Sep 21, 2021 at 3:45 PM Roman Lebedev wrote: > > Package: clang-14 > Version: 1:14~++2021091115+6aacc6933878-1~exp1~20210911091920.4239 > Severity: important > File: /usr/lib/llvm-14/lib/cmake/clang/ClangConfig.cmake > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > CMake Error at /usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake:709 > (message): > The imported target "libclang" references the file > > "/usr/lib/llvm-14/lib/libclang-14.so.14.0.0" > > but this file does not exist. Possible reasons include: > > * The file was deleted, renamed, or moved to another location. > > * An install or uninstall procedure did not complete successfully. > > * The installation package was faulty and contained > > "/usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake" > > but not all the files it references. > > Call Stack (most recent call first): > /usr/lib/llvm-14/lib/cmake/clang/ClangConfig.cmake:20 (include) > dependencies/llvm/CMakeLists.txt:14 (find_package) > > > > - -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, > 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-8-amd64 (SMP w/32 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages clang-14 depends on: > ii binutils 2.37-7 > ii libc6 2.32-4 > ii libc6-dev 2.32-4 > hi libclang-com > 1:14~++2021091115+6aacc6933878-1~exp1~20210911091920.4239 > ii libclang-cpp > 1:14~++2021091115+6aacc6933878-1~exp1~20210911091920.4239 > hi libclang1-14 > 1:14~++2021091115+6aacc6933878-1~exp1~20210911091920.4239 > ii libgcc-10-de 10.3.0-11 > ii libgcc-s1 11.2.0-7 > ii libllvm14 > 1:14~++2021091115+6aacc6933878-1~exp1~20210911091920.4239 > ii libobjc-10-d 10.3.0-11 > ii libstdc++-10 10.3.0-11 > ii libstdc++611.2.0-7 > > Versions of packages clang-14 recommends: > hi libomp-14-de > 1:14~++2021091115+6aacc6933878-1~exp1~20210911091920.4239 > hi llvm-14-dev > 1:14~++2021091115+6aacc6933878-1~exp1~20210911091920.4239 > ii python3 3.9.2-3 > > Versions of packages clang-14 suggests: > pn clang-14-doc > > - -- no debconf information > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAmFJ0z8ACgkQCDw+u0oW > ieB3KBAAig+u6q8jQEz5DxVOoQnITq/MNYfHgCDguf4tfvSTTqJgJ8MSm0dePuO+ > 8gf4CeaixFamCYiCRvxhBopXTOk7VPt6xXSnyEMax/ZJtSCZgvlETY4sRaMZWUfV > DS298kRA+xx8jXqoWtEzAz1+vH0Ik3lVEIU2sEM4sMw7qNxLWBMa7dHNQgq3mBnM > LKhcem6WFEIyVincmJ4Y9C8ptO8lPV+W/v32+eJJt7VnyJqojhxHaxXft37Nn+jh > +b1VcmZJUn7EOyHG3QAnMVs/mbgnjNuEUNuTs1LHwzrCtJ69zNsN7oAIh8QcXNT5 > Ai8w1H0XaVOMCuB4toLJb0WiKb7U6ok9mEjTNjXdJ/uKjiTxVrbfYW8pix7fXKSp > ccFRLxzu08LzX3di4KLsT3XNcPx+Pik29G6D8oqFY7ctftOMzuiczWSsu1qWK7P4 > JOLlhlR+uDcxsUiIr4t6V4jvu8lfGFwYz3/pDiCvXrPjgwDftrVhnzJ7Bb8y/emS > fGcgNobuCWIZmtHoV/JpFDtaXeLeKlac/3B5Z7IoZ0NschUTZPuey7BNBZC1w0J5 > +b4CFRL9pdcsNxHCJxVU3qGGTR2WmwGf9svuGbKgIv7AiVz7HVaXQ3B8KCuIIYYw > sUEbRHpUjYmcxVlsbudA9axr+ZwPewJ+FjaUABMgNSQagoN3vHk= > =JRYs > -END PGP SIGNATURE-
Bug#994798: util-linux FTBFS: configure: error: raw selected, but required raw.h header file not available
Hi Helmut, * Helmut Grohne [210921 06:33]: > util-linux fails to build from source in unstable on amd64. [..] > | checking for linux/raw.h... no > ... > | configure: error: raw selected, but required raw.h header file not available > > I suspect that linux dropped the header and that way makes util-linux > FTBFS. Indeed. Linux commit: https://github.com/torvalds/linux/commit/603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093 Thanks for reporting! I will disable the raw(8) tool. Chris
Bug#994775: flowblade: No module name 'mlt'
Thank you, Gürkan! Your solution provides a local fix for the problem. I think it may work as a fixz when packaging, right? Best, Alexandre On Sep 20 2021, Gürkan Myczko wrote: > solution is here: > > https://github.com/jliljebl/flowblade/issues/1016 > > sorry for the issue will try to fix > > > > On 20 Sep 2021, at 21:03, Alexandre Lymberopoulos wrote: > > > > Package: flowblade > > Version: 2.8.0.3-2 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > > > When I tried to open flowblade from terminal in my XFCE session I get the > > following: > > > > FLOWBLADE MOVIE EDITOR 2.8 > > -- > > Launch script dir: /usr/bin > > Running from installation... > > modules path: /usr/share/flowblade/Flowblade > > MLT not found, exiting... > > ERROR: No module named 'mlt' > > > > But it seems that all the dependencies are installed here. I may provide > > any further information upon request and guidance. > > > > Thanks in advance and best regards, Alexandre > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers testing > > APT policy: (900, 'testing'), (800, 'unstable') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.10.0-8-rt-amd64 (SMP w/4 CPU threads; PREEMPT) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_US:en > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > > > Versions of packages flowblade depends on: > > ii frei0r-plugins1.7.0-1 > > ii gir1.2-gdkpixbuf-2.0 2.42.6+dfsg-2 > > ii gir1.2-glib-2.0 1.68.0-2 > > ii gir1.2-gtk-3.03.24.30-3 > > ii gir1.2-pango-1.0 1.48.9+ds1-2 > > ii gmic 2.9.4-4 > > ii libmlt-data 7.0.1-3 > > ii librsvg2-common 2.50.3+dfsg-1 > > ii python3 3.9.2-3 > > ii python3-cairo 1.16.2-4+b2 > > ii python3-dbus 1.2.18-2 > > ii python3-distutils 3.9.7-1 > > ii python3-gi3.40.1-2 > > ii python3-gi-cairo 3.40.1-2 > > ii python3-mlt 7.0.1-3 > > ii python3-numpy 1:1.19.5-1 > > ii python3-opencv4.5.3+dfsg-1+b1 > > ii python3-pil 8.1.2+dfsg-0.3 > > ii swh-plugins 0.4.17-2 > > > > flowblade recommends no packages. > > > > flowblade suggests no packages. > > > > -- no debconf information > > -- === Alexandre Lymberopoulos - lym...@gmail.com ===
