Bug#1016509: libgetfem-dev,libgetfem5,libgmm-dev: missing Breaks+Replaces on their getfem++ counterparts
Followup-For: Bug #1016509 Do not forget python3-getfem: Unpacking python3-getfem (5.4.1+dfsg1-1) ... dpkg: error processing archive /var/cache/apt/archives/python3-getfem_5.4.1+dfsg1-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/getfem/__init__.py', which is also in package python3-getfem++ 5.3+dfsg1-4.2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libgetfem5_5.4.1+dfsg1-1_amd64.deb /var/cache/apt/archives/python3-getfem_5.4.1+dfsg1-1_amd64.deb Andreas
Bug#1016511: python3-pydevd: missing Breaks+Replaces: python3-omegaconf (<< ???)
Package: python3-pydevd Version: 2.8.0+git20220714.32dee0b+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: block -1 with 1016510 Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Selecting previously unselected package python3-pydevd. Preparing to unpack .../python3-pydevd_2.8.0+git20220714.32dee0b+dfsg-2_amd64.deb ... Unpacking python3-pydevd (2.8.0+git20220714.32dee0b+dfsg-2) ... dpkg: error processing archive /var/cache/apt/archives/python3-pydevd_2.8.0+git20220714.32dee0b+dfsg-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/pydevd_plugins/__init__.py', which is also in package python3-omegaconf 2.1.0~rc1-3 Errors were encountered while processing: /var/cache/apt/archives/python3-pydevd_2.8.0+git20220714.32dee0b+dfsg-2_amd64.deb python3-omegaconf still needs to drop the conflicting files (#1016510), so my guess would be that you need to add Breaks+Replaces: python3-omegaconf (<< 2.1.0~rc1-4~) cheers, Andreas python3-omegaconf=2.1.0~rc1-3_python3-pydevd=2.8.0+git20220714.32dee0b+dfsg-2.log.gz Description: application/gzip
Bug#1016510: python3-omegaconf: ships /usr/lib/python3/dist-packages/pydevd_plugins/__init__.py, now in python3-pydevd, too
Package: python3-omegaconf Version: 2.1.0~rc1-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Selecting previously unselected package python3-pydevd. Preparing to unpack .../python3-pydevd_2.8.0+git20220714.32dee0b+dfsg-2_amd64.deb ... Unpacking python3-pydevd (2.8.0+git20220714.32dee0b+dfsg-2) ... dpkg: error processing archive /var/cache/apt/archives/python3-pydevd_2.8.0+git20220714.32dee0b+dfsg-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/pydevd_plugins/__init__.py', which is also in package python3-omegaconf 2.1.0~rc1-3 Errors were encountered while processing: /var/cache/apt/archives/python3-pydevd_2.8.0+git20220714.32dee0b+dfsg-2_amd64.deb python3-pydevd was recently introduced into the archive, please stop shipping the conflicting files: usr/lib/python3/dist-packages/pydevd_plugins/__init__.py usr/lib/python3/dist-packages/pydevd_plugins/extensions/__init__.py cheers, Andreas python3-omegaconf=2.1.0~rc1-3_python3-pydevd=2.8.0+git20220714.32dee0b+dfsg-2.log.gz Description: application/gzip
Bug#1016509: libgetfem-dev,libgetfem5,libgmm-dev: missing Breaks+Replaces on their getfem++ counterparts
Package: libgetfem-dev,libgetfem5,libgmm-dev Version: 5.4.1+dfsg1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../libgetfem5_5.4.1+dfsg1-1_amd64.deb ... Unpacking libgetfem5:amd64 (5.4.1+dfsg1-1) ... dpkg: error processing archive /var/cache/apt/archives/libgetfem5_5.4.1+dfsg1-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libgetfem.so.5', which is also in package libgetfem5++:amd64 5.3+dfsg1-4.2 Preparing to unpack .../libgmm-dev_5.4.1+dfsg1-1_amd64.deb ... Unpacking libgmm-dev (5.4.1+dfsg1-1) ... dpkg: error processing archive /var/cache/apt/archives/libgmm-dev_5.4.1+dfsg1-1_amd64.deb (--unpack): trying to overwrite '/usr/include/gmm/getfem_arch_config.h', which is also in package libgmm++-dev 5.3+dfsg1-4.2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Preparing to unpack .../libgetfem-dev_5.4.1+dfsg1-1_amd64.deb ... Unpacking libgetfem-dev (5.4.1+dfsg1-1) ... dpkg: error processing archive /var/cache/apt/archives/libgetfem-dev_5.4.1+dfsg1-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/getfem-config', which is also in package libgetfem++-dev 5.3+dfsg1-4.2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libgetfem5_5.4.1+dfsg1-1_amd64.deb /var/cache/apt/archives/libgmm-dev_5.4.1+dfsg1-1_amd64.deb /var/cache/apt/archives/libgetfem-dev_5.4.1+dfsg1-1_amd64.deb cheers, Andreas libgetfem++-dev=5.3+dfsg1-4.2_libgetfem-dev=5.4.1+dfsg1-1.log.gz Description: application/gzip
Bug#1016508: rapiddisk,rapiddisk-dkms: both ship /usr/src/rapiddisk-8.2.0-2/*
Package: rapiddisk,rapiddisk-dkms Version: 8.2.0-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Selecting previously unselected package rapiddisk-dkms. Preparing to unpack .../rapiddisk-dkms_8.2.0-2_all.deb ... Unpacking rapiddisk-dkms (8.2.0-2) ... dpkg: error processing archive /var/cache/apt/archives/rapiddisk-dkms_8.2.0-2_all.deb (--unpack): trying to overwrite '/usr/src/rapiddisk-8.2.0-2/Makefile', which is also in package rapiddisk 8.2.0-2 Errors were encountered while processing: /var/cache/apt/archives/rapiddisk-dkms_8.2.0-2_all.deb BTW, you should only use the upstream version without Debian revision for the path in /usr/src, i.e. /usr/src/rapiddisk-8.2.0/ cheers, Andreas rapiddisk=8.2.0-2_rapiddisk-dkms=8.2.0-2.log.gz Description: application/gzip
Bug#1016507: ITP: python-intervals -- tools for handling intervals (ranges of comparable objects) in python
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, j...@nahmias.net, kon...@fastmonkeys.com * Package name: python-intervals Version : 0.9.2 Upstream Author : Konsta Vesterinen * URL : https://github.com/kvesteri/intervals * License : BSD Programming Lang: Python Description : tools for handling intervals (ranges of comparable objects) in python This package provides objects, methods, constructors and functions for representing and manipulating mathematical intervals. Included are factory methods for creating intervals objects, comparison operators, set operators, and arithmetic functions.
Bug#1016506: libghc-shake-{doc,dev,data}: all ship /usr/lib/haskell-packages/extra-packages/shake-0.19.6
Package: libghc-shake-doc,libghc-shake-dev,libghc-shake-data Version: 0.19.6-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): ... Selecting previously unselected package libghc-shake-data. Preparing to unpack .../12-libghc-shake-data_0.19.6-1_all.deb ... Unpacking libghc-shake-data (0.19.6-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-2iAjjB/12-libghc-shake-data_0.19.6-1_all.deb (--unpack): trying to overwrite '/usr/lib/haskell-packages/extra-packages/shake-0.19.6', which is also in package libghc-shake-doc 0.19.6-1 Selecting previously unselected package libghc-unordered-containers-dev. Preparing to unpack .../13-libghc-unordered-containers-dev_0.2.17.0-2+b1_amd64.deb ... Unpacking libghc-unordered-containers-dev (0.2.17.0-2+b1) ... Selecting previously unselected package libghc-utf8-string-dev. Preparing to unpack .../14-libghc-utf8-string-dev_1.0.2-1+b1_amd64.deb ... Unpacking libghc-utf8-string-dev (1.0.2-1+b1) ... Selecting previously unselected package libghc-shake-dev. Preparing to unpack .../15-libghc-shake-dev_0.19.6-1_amd64.deb ... Unpacking libghc-shake-dev (0.19.6-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-2iAjjB/15-libghc-shake-dev_0.19.6-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/haskell-packages/extra-packages/shake-0.19.6', which is also in package libghc-shake-doc 0.19.6-1 Errors were encountered while processing: /tmp/apt-dpkg-install-2iAjjB/12-libghc-shake-data_0.19.6-1_all.deb /tmp/apt-dpkg-install-2iAjjB/15-libghc-shake-dev_0.19.6-1_amd64.deb ... cheers, Andreas libghc-shake-doc=0.19.6-1_libghc-shake-dev=0.19.6-1.log.gz Description: application/gzip
Bug#1016505: patch: Fix `Incorrect netdev->dev_addr` errors in linux-5.17+ patch
Source: broadcom-sta Version: 6.30.223.271-20 Severity: important Tags: patch X-Debbugs-Cc: die...@gnome.org Dear Maintainer, The patch for linux-5.17 deprecations incorrectly inverted the src/dest of the copying of MAC addresses. I have pushed a branch with the gbp-processed patch: https://salsa.debian.org/diegoe/broadcom-sta/-/tree/debian-diegoe-202208 I _think_ this potentially fixes two recent bugs that have the trace/bug in the logs, but my card is a different PHY so I can't confirm that. Here's the commit log for further explanation: ``` d/patches: Fix the linux-5.17 deprecations patch The patch was enough to get things to build, but it accidentally inverted the direction of the copy of a few addresses. This was causing traces when the device address was set in the driver: ``` wl :03:00.0 wlp3s0: Current addr: NN NN NN NN NN NN 00 00 00 00 00 00 00 00 00 wl :03:00.0 wlp3s0: Expected addr: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ cut here ] netdevice: wlp3s0: Incorrect netdev->dev_addr WARNING: CPU: 3 PID: 1178 at net/core/dev_addr_lists.c:517 dev_addr_check.cold+0x43/0x7d (...) ``` (where NN is the device MAC) Apparently this might be enough in some cards to make it impossible to connect to a network. See bugs below. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011529 See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016426 ``` -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1016504: ITP: wtforms-components -- various additional fields, validators and widgets for WTForms
Package: wnpp Severity: wishlist Owner: Joseph Nahmias X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, j...@nahmias.net, kon...@fastmonkeys.com * Package name: wtforms-components Version : 0.10.5 Upstream Author : Konsta Vesterinen * URL : https://github.com/kvesteri/wtforms-components * License : BSD Programming Lang: Python Description : various additional fields, validators and widgets for WTForms WTForms-Components provides enhanced versions of some WTForms HTML5 fields and some additional new fields and validatiors. These enhancements include: . * DateTimeField * IntegerField * SelectField * SelectMultipleField * ColorField * NumberRangeField * PassiveHiddenField * Read-only fields * DateRange validator * Email validator * If validator * Unique Validator
Bug#1016482: jamulus: please add support for riscv64
Hi, On Mon, Aug 01, 2022 at 03:31:36PM +, Thorsten Glaser wrote: It can also be built successfully on big-endian platforms, but that doesn’t mean it works correctly. Upstream’s custom build for opus custom modes precludes adding more architectures, but as #686777 seems to have been fixed I was intending on permitting all architectures in an upload that can use this (I’ll have to figure out how to use it first). But as-is, this patch isn’t suitable. Ok, thanks for let me know that. This is also what I worry about. Maybe some packages can be built on riscv64 arch, but they may not work as our imagination. -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows
Hello! I've moved over the repository into Salsa, updated it for the latest release `3.1.2`. I've built it on my Sid desktop with sbuild, lintian reports no errors, and it the software is working as expected. Let me know if you see anything you would change. Thanks, Blake On Mon, Jul 25, 2022, at 12:32 PM, Blake Lee wrote: > Okay sounds good, I'll get it moved over when I get some time. > > I've been personally using and maintaining it for about 5 months now with no > issues. It's the best solution I've found for a good tiling experience in > KDE, previously I was using i3-gaps and picom, but there are a lot of minor > inconveniences with this route. > > Additionally my packaging was officially included in Ubuntu 22.04, with some > changes to the debian files that I backported. I know there are at least some > users of it as it's posted on bismuth's official GitHub. I've only ever > received requests to update the package to a new upstream version. > > On Mon, Jul 25, 2022, at 11:46 AM, Didier Raboud wrote: >> Le lundi, 25 juillet 2022, 17.35:43 h CEST Blake Lee a écrit : >> > As for the repo should I just mirror my current work from GitLab over to >> > Salsa? >> >> If that's working well for you, I'd say yes; having team-maintained packages >> in a common location makes most things easier; including common CI test >> scripts, team-at-large changes, etc. >> >> *Attachments:* >> * signature.asc >
Bug#1016502: Acknowledgement (libsecret: FTBFS on hppa - test-session timeout is too small)
Patch. -- John David Anglin dave.ang...@bell.net Index: libsecret-0.20.5/libsecret/test-session.c === --- libsecret-0.20.5.orig/libsecret/test-session.c +++ libsecret-0.20.5/libsecret/test-session.c @@ -164,7 +164,7 @@ test_ensure_async_aes (Test *test, gboolean ret; secret_service_ensure_session (test->service, NULL, on_complete_get_result, ); - egg_test_wait_until (500); + egg_test_wait_until (5000); g_assert_true (G_IS_ASYNC_RESULT (result)); ret = secret_service_ensure_session_finish (test->service, result, );
Bug#1016502: libsecret: FTBFS on hppa - test-session timeout is too small
Source: libsecret Version: 0.20.5-2 Severity: normal Tags: patch Dear Maintainer, The program test-session fails on hppa: 6/21 libsecret:libsecret / test-session FAIL 4.52s killed by signal 6 SIGABRT See log: https://buildd.debian.org/status/fetch.php?pkg=libsecret=hppa=0.20.5-2=1659391609=0 This can be fixed by increasing the timeout in test_ensure_async_aes: https://buildd.debian.org/status/fetch.php?pkg=libsecret=hppa=0.20.5-2=1659395930=0 Regards, Dave Anglin -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 5.18.15+ (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#1016055: fmtutil failed. Output has been stored in
Am 01.08.2022 um 09:22 teilte Klaus Ethgen mit: Am So den 31. Jul 2022 um 22:02 schrieb Hilmar Preuße: Hi Klaus, This sounds like a full file system during installation, which can lead to various issues like this. I suggest to close the issue as "caused by full file system". Could be but I suspect apt/dpkg to take care of that and fail graceful. The install script of a package fails, hence apt declares the whole package installation to be not successful. apt can't do much in this situation except trying the script of the later version in the hope a script bug was fixed in the new version. This was not the case, the script failed (probably) due to a full file system. This is not uncommon when doing TL upgrades. So, what do you expect? Should apt delete some random files and start over? apt could try to do some random system checks like "df -h", show users the results, so they get an idea why the installation failed. However this is an wishlist bug for apt, not a serious bug for "tex-common". Can we close the issue here? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#990047: timeshift: Not possible to browse content of snapshot via the gui
Steeve, Good question. And, you're right, thanks ! I thought it was some kind of "internal browser" provided with timeshift. But after looking more closely, it was actually trying to start VSCode ! :s And it's the one that do not like to be run as root. Not sure why or how it decided to use it instead of the Gnome file browser. But apt remove of it "fixed" the issue. I don't see any settings for that in the timeshift GUI. I'm not sure how I can force it to use the default gnome file browser :( Thanks -- Ludovic Poujol
Bug#1014633: linux-headers-5.19.0-rc4-common: file check-local-export does not exist
On Sun, 2022-07-31 at 23:02 +0200, Andreas Beckmann wrote: > Followup-For: Bug #1014633 > > What about adding a superficial autopkgtest that tries to compile a > dummy third-party kernel module using kbuild? That should help noticing > such breakage earlier. This is such an obviously good idea that I already did it in version 5.18.14-1. :-) Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Bug#1016486: wayfire: please make the build reproducible
Control: forwarded -1 https://github.com/WayfireWM/wayfire/issues/1534 Bug forwarded upstream to have WF_SRC_DIR macro removed. Thanks, Boyuan Yang 在 2022-08-01星期一的 09:39 -0700，Chris Lamb写道： > Source: wayfire > Version: 0.7.4-1 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: buildpath > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Hi, > > Whilst working on the Reproducible Builds effort [0] we noticed that > wayfire could not be built reproducibly. > > This is because it embedded an absolute build path into a config.h > file. A patch is attached that fixes this value to a known/fixed > value — the absolute build path won't exist at runtime anyway, so > this is at least "no worse". > > [0] https://reproducible-builds.org/ signature.asc Description: This is a digitally signed message part
Bug#1016500: README.Debian documents KillUserProcesses but not Linger
Package: systemd
Version: 251.3-1
Severity: normal
File: /usr/share/doc/systemd/README.Debian.gz
The README.Debian file duefully documents the surprising[1] effects that
happen when using tmux or similar under in a logind session. However, it
only covers the KillUserProcesses part of things (a mechanism that
Debian thankfully disables by default), and not the linger part, which
has a similar (if not the same) effect and is set to kill by default.
Suggested new text, based on the current one:
> KillUserProcesses and linger behavior in Debian
> ===
>
> If KillUserProcesses=yes is configured in logind.conf(5), the session scope
> will be terminated when the user logs out of that session.
>
> Likewise, processes launched by users configured as Linger=no (see
> loginctl(1)) are terminated.
>
> See logind.conf(5):
>
> | Note that setting KillUserProcesses=yes will break tools like screen(1) and
> | tmux(1), unless they are moved out of the session scope.
>
> The default for KillUserProcesses in /etc/systemd/logind.conf is set
> to "yes" in upstream systemd, though Debian defaults to "no" (see #825394).
>
> The default Linger value for users is set to "no", and may need to be
> altered with `loginctl enable-linger ${USER}` to keep screen and tmux
> useful.
[1]: https://bugs.debian.org/1016475
-- Package-specific info:
-- 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.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages systemd depends on:
ii adduser3.123
ii libacl12.3.1-1
ii libaudit1 1:3.0.7-1+b1
ii libblkid1 2.38-6
ii libc6 2.33-8
ii libcap21:2.44-1
ii libcryptsetup122:2.5.0-1
ii libfdisk1 2.38-6
ii libgcrypt201.10.1-2
ii libkmod2 30+20220630-3
ii liblz4-1 1.9.3-2
ii liblzma5 5.2.5-2.1
ii libmount1 2.38-6
ii libseccomp22.5.4-1+b1
ii libselinux13.4-1+b1
ii libssl33.0.5-1
ii libsystemd-shared 251.3-1
ii libsystemd0251.3-1
ii libzstd1 1.5.2+dfsg-1
ii mount 2.38-6
Versions of packages systemd recommends:
ii dbus [default-dbus-system-bus] 1.14.0-2
ii ntpsec [time-daemon]1.2.1+dfsg1-7+b1
Versions of packages systemd suggests:
ii libfido2-11.11.0-1+b1
ii libtss2-esys-3.0.2-0 3.2.0-1+b1
ii libtss2-mu0 3.2.0-1+b1
ii libtss2-rc0 3.2.0-1+b1
ii policykit-1 0.105-33
pn systemd-boot
ii systemd-container 251.3-1
pn systemd-homed
pn systemd-userdbd
Versions of packages systemd is related to:
ii dbus-user-session 1.14.0-2
pn dracut
ii initramfs-tools0.142
pn libnss-systemd
ii libpam-systemd 251.3-1
ii udev 251.3-1
-- no debconf information
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: PGP signature
Bug#1016474: [pkg-cryptsetup-devel] Bug#1016474: cryptsetup: The system installed on encrypted LVM (both root and swap partitions) freezes during massive writes
On Mon, 2022-08-01 at 23:00 +0200, Wojciech Zabołotny wrote: > BTW, that problem gives even more "interesting" results when one > copies > a lot of data from or to the USB disc. The freeze of the system may > break the USB communication (unmounting the filesystem or remounting > it > read-only due to errors) which may result in partially copied data. I don't think I've ever observed that (though I simply might not have copied data to USB, when I put heavy IO load on my dm-crypt). Maybe a better place for this would be the cryptsetup mailing list (though cryptsetup itself, is likely not the problem but rather dm- crypt)... but there one may simply meet quite a number of experienced people. Cheers, Chris.
Bug#1016499: cctbx: autopkgtest failure: Please run this program in an empty directory.
Source: cctbx Version: 2021.12+ds1-7 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package cctbx, great. However, it fails. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=cctbx https://ci.debian.net/data/autopkgtest/testing/amd64/c/cctbx/23732580/log.gz Testing with python3.10: Sorry: Please run this program in an empty directory. autopkgtest [21:14:13]: test command1 OpenPGP_signature Description: OpenPGP digital signature
Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment
Julian Gilbey wrote on 08/06/2022 at 10:50:18+0200: > notfixed 1010469 1:4.0.11-1 > thanks > >> I decided to reinstall my system from scratch, and now this bug has >> gone away. So as no-one else could reproduce it and I have no idea >> what has changed on my system as a result of reinstalling, I'm closing >> it with an "unreproducible" tag. > > Oh dear, oh dear, oh dear. It's just happened again. > > I am so completely stumped by this one. What apparmor profile are you trying to run your container with? -- PEB signature.asc Description: PGP signature
Bug#1016496: nmu: abinit_9.6.2-1
On 8/1/22 22:34, Paul Gevers wrote: On 01-08-2022 22:18, Bas Couwenberg wrote: nmu abinit_9.6.2-1 . ANY . unstable . -m "Rebuild with libnetcdff7 (>= 4.6.0+ds-1)" To resolve the autopkgtest failure reported in #1016414, the package needs to be rebuilt. That normally means it's papering over the real issue. Are you sure libnetcdff shouldn't have bumped it's SONAME? Based on the symbols changes I'd say no, only a few new symbols were introduced. But it's fortran of which I know little to nothing, so... I don't want to diverge from upstream nor go through NEW for an issue I don't understand, so feel free to close this issue and we'll wait for autoremoval or a new upload. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1016498: rope: autopkgtest regression: No module named 'pkg_resources'
Source: rope Version: 1.2.0-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of rope the autopkgtest of rope fails in testing when that autopkgtest is run with the binary packages of rope from unstable. It passes when run with only packages from testing. In tabular form: passfail rope from testing1.2.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. It seems to me you're just missing a new (test) dependency. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=rope https://ci.debian.net/data/autopkgtest/testing/amd64/r/rope/24208691/log.gz Testing with python3.10: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/rope/__init__.py", line 3, in from pkg_resources import get_distribution ModuleNotFoundError: No module named 'pkg_resources' autopkgtest [16:13:00]: test command1 OpenPGP_signature Description: OpenPGP digital signature
Bug#1016496: nmu: abinit_9.6.2-1
Hi Bas, On 01-08-2022 22:18, Bas Couwenberg wrote: nmu abinit_9.6.2-1 . ANY . unstable . -m "Rebuild with libnetcdff7 (>= 4.6.0+ds-1)" To resolve the autopkgtest failure reported in #1016414, the package needs to be rebuilt. That normally means it's papering over the real issue. Are you sure libnetcdff shouldn't have bumped it's SONAME? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1016497: node-fetch: CVE-2022-2596
Source: node-fetch Version: 3.2.9+~cs18.4.14-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for node-fetch. CVE-2022-2596[0]: | Denial of Service in GitHub repository node-fetch/node-fetch prior to | 3.2.10. TTBOMK it has introduced in v3.1.0 only so affects only the version in experimental, but please double-check again. 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-2022-2596 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2596 Regards, Salvatore
Bug#937234: trying to remove python2.7 from bookworm
Hi all, This is a heads up that we are trying to remove python2.7 from bookworm. Please either fix pam-python to use python3 or drop the dependency from debian-edu-config. Paul [Release Team member hat on] OpenPGP_signature Description: OpenPGP digital signature
Bug#1016495: mediathekview: fills up /var/log/syslog, /var/log/messages and /var/log/user.log with debug info
Package: mediathekview Version: 13.2.1-4 Severity: important X-Debbugs-Cc: be...@judiz.de Dear Maintainer, I have tried to use MediathekView again, after some time. First it would not start, showing the logo with a progress bar at maybe 30% for maybe 10 minutes on several attempts. Then I moved my old .mediathek3 config directory away. Now MediathekView started as expected. I chose the detailed setup process, and before it had even downloaded all TV programs I got a message that my log partition was full. It looks like MediathekView is writing detailed java debug info to all available log files. I have not touched any debug logging options. IMHO flooding the log files is a security risk. MediathekView should not write to system log files by default, and especially not debug info to /var/log/syslog. Thanks for your work! Michael -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN 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 mediathekview depends on: ii default-jre [java9-runtime] 2:1.11-72 ii java-wrappers 0.3 ii libcommons-compress-java1.21-1 ii libcommons-configuration2-java 2.8.0-1 ii libcommons-dbcp2-java 2.9.0-1 ii libcommons-lang3-java 3.12.0-2 ii libcommons-pool2-java 2.11.1-1 ii libcontrolsfx-java 11.0.0-1 ii libguava-java 29.0-6 ii libh2-java 2.1.212-1 ii libjackson2-core-java 2.13.0-2 ii libjchart2d-java3.2.2+dfsg2-3 ii libjiconfont-font-awesome-java 4.7.0.0-2 ii libjiconfont-java 1.0.0-2 ii libjiconfont-swing-java 1.0.1-2 ii libjide-oss-java3.7.6+dfsg-2 ii liblog4j2-java 2.17.2-1 ii libmbassador-java 1.3.1-2 ii libmiglayout-java 5.1-3 ii libokhttp-java 3.13.1-3 ii libopenjfx-java 11.0.11+0-1 ii libswingx-java 1:1.6.2-4 ii libxz-java 1.9-1 ii openjdk-11-jre [java9-runtime] 11.0.16+8-1 ii openjdk-18-jre [java9-runtime] 18.0.2+9-2 Versions of packages mediathekview recommends: ii flvstreamer 2.1c1-1+b2 ii mplayer 2:1.4+ds1-3+b1 ii mpv 0.34.1-1+b4 ii vlc 3.0.17.4-4+b1 Versions of packages mediathekview suggests: ii ffmpeg 7:5.0.1-3+b1 -- no debconf information
Bug#1016414: abinit: autopkgtest failure
Installing the dbgsym packages makes the backtrace a little more informative: Backtrace for this error: #0 0x7f889dd4b93f in ??? at ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 #1 0x7f889e3c5518 in __netcdf_nc_interfaces_MOD_addcnullchar at ./fortran/module_netcdf_nc_interfaces.F90:2587 #2 0x7f889e3b33b0 in nf_def_var_ at ./fortran/nf_genvar.F90:63 #3 0x7f889e427b8e in __netcdf_MOD_nf90_def_var_onedim at ./fortran/netcdf4_variables.F90:61 #4 0x559ee1f317bf in __m_nctk_MOD_write_var_netcdf at ./shared/common/src/27_toolbox_oop/m_nctk.F90:2941 #5 0x559ee1c23cd0 in __m_parser_MOD_prttagm at ./src/42_parser/m_parser.F90:3538 #6 0x559ee1c2588f in __m_parser_MOD_prttagm_images at ./src/42_parser/m_parser.F90:3668 #7 0x559ee18ae96f in __m_outvar_a_h_MOD_outvar_a_h at ./src/57_iovars/m_outvar_a_h.F90:191 #8 0x559ee18ad8fa in __m_outvars_MOD_outvars at ./src/57_iovars/m_outvars.F90:371 #9 0x559ee0bbfffd in abinit at ./src/98_main/abinit.F90:323 #10 0x559ee0bbd88e in main at ./src/98_main/abinit.F90:88 Rebuilding with netcdf-fortan (4.6.0+ds-1) resolves the issue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1016496: nmu: abinit_9.6.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu abinit_9.6.2-1 . ANY . unstable . -m "Rebuild with libnetcdff7 (>= 4.6.0+ds-1)" To resolve the autopkgtest failure reported in #1016414, the package needs to be rebuilt. Kind Regards, Bas
Bug#1015897: gobby: Gobby is crashing right after calling it
Hi Philipp,
Am Sun, Jul 31, 2022 at 06:12:55PM +0200 schrieb Philipp Kern:
> > It existed - but if I remove it no such dir is create newly.
>
> And how about ~/.infinote-records and your homedir?
That dir existed in my homedir from former DebConfs when gobby worked.
If I rename it now and try gobby again it grashes as well. When trying
under strace I get:
...
openat(AT_FDCWD, "/home/tillea/.infinote/", O_RDONLY|O_NOFOLLOW) = -1 ENOENT
(No such file or directory)
openat(AT_FDCWD, "/home/tillea/.infinote/", O_RDONLY|O_NOFOLLOW) = -1 ENOENT
(No such file or directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffc14a99fe8} ---
+++ killed by SIGSEGV +++
I think I understand that issue now. I have copied the configuration of
my current box from a former laptop where I used a symlink
ln -s /home/andreas /home/tillea
since ages ago I was using user tillea. Currently I am
$ whoami
andreas
$ echo $HOME
/home/andreas
Since /home/tillea does not exist gobby can't create that dir.
OK, I think we found the reason - but IMHO gobby is buggy in two ways:
1. It should simply use $HOME to create the dirs it needs (and not some
"random" config which I would like to know to fix / remove it)
and more importantly
2. it should not crash SIGSEGV but rather print "can't create dir XY"
> FWIW, it does not crash for me on a new installation on bookworm.
I believe this now since I think I understood that issue (which I could
probably fix by the said symlink but I guess its better to find a real
solution.
Kind regards
Andreas.
--
http://fam-tille.de
Bug#1016184: additional information
I rebooted the system after getting the information requested and there was messages when rebooting (while shutting down) about dpkg-exe and percent completed. That process had to finish before it would finish the reboot. -- Tim McConnell
Bug#1016494: python2-pip: don't ship python2.7 with bookworm
Source: python2-pip Version: 20.3.4+dfsg-4 Severity: serious Dear maintainers, I'm surprised to see there's no RC bug against python2-pip yet, but we're trying to not ship python2.7 with bookworm, which means this package has to go too, right? Paul
Bug#1016474: [pkg-cryptsetup-devel] Bug#1016474: cryptsetup: The system installed on encrypted LVM (both root and swap partitions) freezes during massive writes
On Mon, 2022-08-01 at 15:42 +0200, Guilhem Moulin wrote: > Pretty sure most systems don't freeze under heavy > write anyway :-) I have that too... on basically every system with dm-crypt and high memory. I just thought it was a known issue of dm-crypt and never really digged any deeper into it ^^ Also I don't use LVM anymore. Whenever I write a lot of data it first goes fast (as if some buffer would first be filled up) and then easily freezes the whole system (until all data has been encrypted and written). Sometimes it even freezes stuff which one would assume shouldn't need any IO (clock applet in the desktop environment or even the mouse cursor). Cheers, Chris.
Bug#1015873: libtirpc: diff for NMU version 1.3.2-2.1
Control: tags 1015873 + patch
Control: tags 1015873 + pending
Dear maintainer,
I've prepared an NMU for libtirpc (versioned as 1.3.2-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
The corresponding merge request is at
https://salsa.debian.org/debian/libtirpc/-/merge_requests/1 .
Regards,
Salvatore
diff -Nru libtirpc-1.3.2/debian/changelog libtirpc-1.3.2/debian/changelog
--- libtirpc-1.3.2/debian/changelog 2021-08-17 17:16:38.0 +0200
+++ libtirpc-1.3.2/debian/changelog 2022-08-01 16:26:18.0 +0200
@@ -1,3 +1,10 @@
+libtirpc (1.3.2-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix DoS vulnerability in libtirpc (CVE-2021-46828) (Closes: #1015873)
+
+ -- Salvatore Bonaccorso Mon, 01 Aug 2022 16:26:18 +0200
+
libtirpc (1.3.2-2) unstable; urgency=medium
* Upload to unstable
diff -Nru libtirpc-1.3.2/debian/patches/Fix-DoS-vulnerability-in-libtirpc.patch libtirpc-1.3.2/debian/patches/Fix-DoS-vulnerability-in-libtirpc.patch
--- libtirpc-1.3.2/debian/patches/Fix-DoS-vulnerability-in-libtirpc.patch 1970-01-01 01:00:00.0 +0100
+++ libtirpc-1.3.2/debian/patches/Fix-DoS-vulnerability-in-libtirpc.patch 2022-08-01 16:26:18.0 +0200
@@ -0,0 +1,180 @@
+From: Dai Ngo
+Date: Sat, 21 Aug 2021 13:16:23 -0400
+Subject: Fix DoS vulnerability in libtirpc
+Origin: http://git.linux-nfs.org/?p=steved/libtirpc.git;a=commit;h=86529758570cef4c73fb9b9c4104fdc510f701ed
+Bug-Debian: https://bugs.debian.org/1015873
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-46828
+
+Currently svc_run does not handle poll timeout and rendezvous_request
+does not handle EMFILE error returned from accept(2 as it used to.
+These two missing functionality were removed by commit b2c9430f46c4.
+
+The effect of not handling poll timeout allows idle TCP conections
+to remain ESTABLISHED indefinitely. When the number of connections
+reaches the limit of the open file descriptors (ulimit -n) then
+accept(2) fails with EMFILE. Since there is no handling of EMFILE
+error this causes svc_run() to get in a tight loop calling accept(2).
+This resulting in the RPC service of svc_run is being down, it's
+no longer able to service any requests.
+
+RPC service rpcbind, statd and mountd are effected by this
+problem.
+
+Fix by enhancing rendezvous_request to keep the number of
+SVCXPRT conections to 4/5 of the size of the file descriptor
+table. When this thresold is reached, it destroys the idle
+TCP connections or destroys the least active connection if
+no idle connnction was found.
+
+Fixes: 44bf15b8 rpcbind: don't use obsolete svc_fdset interface of libtirpc
+Signed-off-by: dai@oracle.com
+Signed-off-by: Steve Dickson
+---
+ INSTALL | 371 +--
+ src/svc.c| 17 ++-
+ src/svc_vc.c | 62 -
+ 3 files changed, 78 insertions(+), 372 deletions(-)
+ mode change 100644 => 12 INSTALL
+
+diff --git a/src/svc.c b/src/svc.c
+index 6db164bbd76b..3a8709fe375c 100644
+--- a/src/svc.c
b/src/svc.c
+@@ -57,7 +57,7 @@
+
+ #define max(a, b) (a > b ? a : b)
+
+-static SVCXPRT **__svc_xports;
++SVCXPRT **__svc_xports;
+ int __svc_maxrec;
+
+ /*
+@@ -194,6 +194,21 @@ __xprt_do_unregister (xprt, dolock)
+ rwlock_unlock (_fd_lock);
+ }
+
++int
++svc_open_fds()
++{
++ int ix;
++ int nfds = 0;
++
++ rwlock_rdlock (_fd_lock);
++ for (ix = 0; ix < svc_max_pollfd; ++ix) {
++ if (svc_pollfd[ix].fd != -1)
++ nfds++;
++ }
++ rwlock_unlock (_fd_lock);
++ return (nfds);
++}
++
+ /*
+ * Add a service program to the callout list.
+ * The dispatch routine will be called when a rpc request for this
+diff --git a/src/svc_vc.c b/src/svc_vc.c
+index f1d9f001fcdc..3dc8a75787e1 100644
+--- a/src/svc_vc.c
b/src/svc_vc.c
+@@ -64,6 +64,8 @@
+
+
+ extern rwlock_t svc_fd_lock;
++extern SVCXPRT **__svc_xports;
++extern int svc_open_fds();
+
+ static SVCXPRT *makefd_xprt(int, u_int, u_int);
+ static bool_t rendezvous_request(SVCXPRT *, struct rpc_msg *);
+@@ -82,6 +84,7 @@ static void svc_vc_ops(SVCXPRT *);
+ static bool_t svc_vc_control(SVCXPRT *xprt, const u_int rq, void *in);
+ static bool_t svc_vc_rendezvous_control (SVCXPRT *xprt, const u_int rq,
+ void *in);
++static int __svc_destroy_idle(int timeout);
+
+ struct cf_rendezvous { /* kept in xprt->xp_p1 for rendezvouser */
+ u_int sendsize;
+@@ -313,13 +316,14 @@ done:
+ return (xprt);
+ }
+
++
+ /*ARGSUSED*/
+ static bool_t
+ rendezvous_request(xprt, msg)
+ SVCXPRT *xprt;
+ struct rpc_msg *msg;
+ {
+- int sock, flags;
++ int sock, flags, nfds, cnt;
+ struct cf_rendezvous *r;
+ struct cf_conn *cd;
+ struct sockaddr_storage addr;
+@@ -379,6 +383,16 @@ again:
+
+ gettimeofday(>last_recv_time, NULL);
+
++ nfds = svc_open_fds();
++ if (nfds >= (_rpc_dtablesize() / 5) * 4) {
++ /* destroy idle connections */
++ cnt = __svc_destroy_idle(15);
++ if (cnt == 0) {
++ /* destroy least active */
++
Bug#1015742: libspdlog1: ABI breakage without SONAME bump
Hi, Am Tue, Aug 02, 2022 at 01:38:58AM +0800 schrieb Shengjing Zhu: > To fix the ABI breakage in spdlog/1.10, I request the fmt/9 transition > afterwards. > Since with fmt/9 translation, spdlog ABI will bump to > libspdlog1-fmt9(from libspdlog1-fmt8) anyway. A, OK, I missed that point. Feel free to revert my change. > See my comments on #1016418. > I'm not sure if the release team will be happy with that. I see the situation is more complex than I've thought. Thanks a lot for caring for it Andreas. -- http://fam-tille.de
Bug#994704: timeshift: Unable to init server: connection refused. possible pkexec misconfiguration for timeshift-laucher command
Bruno, I've not been able to reproduce this problem. Does it still happen for you? Thanks -Steve
Bug#1016493: unbound: CVE-2022-30698 CVE-2022-30699
Source: unbound Version: 1.16.0-2 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for unbound. CVE-2022-30698[0]: | NLnet Labs Unbound, up to and including version 1.16.1 is vulnerable | to a novel type of the "ghost domain names" attack. The vulnerability | works by targeting an Unbound instance. Unbound is queried for a | subdomain of a rogue domain name. The rogue nameserver returns | delegation information for the subdomain that updates Unbound's | delegation cache. This action can be repeated before expiry of the | delegation information by querying Unbound for a second level | subdomain which the rogue nameserver provides new delegation | information. Since Unbound is a child-centric resolver, the ever- | updating child delegation information can keep a rogue domain name | resolvable long after revocation. From version 1.16.2 on, Unbound | checks the validity of parent delegation records before using cached | delegation information. CVE-2022-30699[1]: | NLnet Labs Unbound, up to and including version 1.16.1, is vulnerable | to a novel type of the "ghost domain names" attack. The vulnerability | works by targeting an Unbound instance. Unbound is queried for a rogue | domain name when the cached delegation information is about to expire. | The rogue nameserver delays the response so that the cached delegation | information is expired. Upon receiving the delayed answer containing | the delegation information, Unbound overwrites the now expired | entries. This action can be repeated when the delegation information | is about to expire making the rogue delegation information ever- | updating. From version 1.16.2 on, Unbound stores the start time for a | query and uses that to decide if the cached delegation information can | be overwritten. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-30698 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30698 [1] https://security-tracker.debian.org/tracker/CVE-2022-30699 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30699 [2] https://www.nlnetlabs.nl/downloads/unbound/CVE-2022-30698_CVE-2022-30699.txt [3] https://github.com/NLnetLabs/unbound/commit/f6753a0f1018133df552347a199e0362fc1dac68 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1016090: python-django breaks lots of autopkgtests
Hi Chris, On 01-08-2022 21:24, Chris Lamb wrote: b) Wait for the 4.x stream to become designated LTS. I believe this should happen with version 4.2, due for release in about 6 or 7 months: https://www.djangoproject.com/download/ That seems to happen after the Debian freeze starts. So please don't do that. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001776: yt-dlp: error message
Howdy, On Mon, 1 Aug 2022, michel wrote: Package: yt-dlp Version: 2022.07.18-1~bpo11+1 Followup-For: Bug #1001776 X-Debbugs-Cc: okgomdjgbm...@gmail.com Dear Maintainer, I don't know if you care about this, but an error message asks to do a "yt-dlp -U" please report this issue on https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using yt-dlp -U I wouldn't say that I wouldn't care, but yes my goal is to greatly limit patches added to yt-dlp. That being said, I don't think it's even needed here at all. When you run `yt-dlp -U` it checks online if you're running the current version and will print out the latest version online and your local version. If you install via pip/package manager, it detects this and tells you to upgrade using those methods: Latest version: 2022.07.18, Current version: 2022.07.17 ERROR: It looks like you installed yt-dlp with a package manager, pip or setup.py; Use that to update As such, the initial error message basically just tells you to check your local version and that it matches the current release, which seems ideal to me. ~Unit 193 Unit193 @ Libera Unit193 @ OFTC
Bug#990047: timeshift: Not possible to browse content of snapshot via the gui
Ludovic, This sounds to me like an issue with not being allowed to run your file browser with root permissions. If this is still a problem for you, which file browser are you using? Thanks -Steve
Bug#937085: [Pkg-mozext-maintainers] Bug#937085: mozilla-devscripts: Python2 removal in sid/bullseye
Hi Håvard, all, On Wed, 27 Jul 2022 10:37:25 +0200 =?UTF-8?Q?H=c3=a5vard_F=2e_Aasen?= wrote: I have continued working on the redland-bindings package, cleaned it up a bit, and enabled the Python 3 testsuite. I created an MR [1]. I believe redland-bindings is ready to be uploaded to NEW/unstable. I just uploaded it to NEW/experimental. Which means that once accepted we can iron out mozilla-devscripts there too. > To test that the Python 3 migration did not break anything, I would > take a bunch of webext package (that build depend on mozilla- > devscripts) and rebuild them (once with the current package and once > with the Python 3 port). Then use diffoscope to compare the content of > the two builds to be identical (same generated dependencies, same > paths, etc). That should give us confidence to not break anything. Did I look in the wrong place? when doing: $ apt-cache rdepends mozilla-devscripts Reverse Depends: devscripts Which is only in the suggests section. You need the reverse *build* depends. paul@mulciber ~ $ reverse-depends -b mozilla-devscripts Reverse-Testsuite-Triggers * devscripts Reverse-Build-Depends * autofill-forms * devscripts * dispmua * mozilla-noscript * tinyjsd * tree-style-tab * umatrix Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1016090: python-django breaks lots of autopkgtests
Raphael Hertzog wrote: > I'm surprised that we uploaded an non-LTS release to unstable. > > Chris, why did you do that? Hmpf, this is deeply unfortunate. I was working under the incorrect belief that the 4.0.x series was now the LTS branch. A number of things encouraged this interpretation, including that the 4.0.x and 4.1.x were the release streams that were receiving security and targeted bugfix releases, and this was happening as a relatively consistent pair. (As in, not the 3.x stream.) Regardless of that though, I think we have two options: a) Revert back to the 3.2.14 LTS version in Debian unstable. b) Wait for the 4.x stream to become designated LTS. I believe this should happen with version 4.2, due for release in about 6 or 7 months: https://www.djangoproject.com/download/ Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1016491: freerdp2: Please package 2.8.0
Source: freerdp2 Version: 2.7.0+dfsg1-1 Severity: wishlist Please package freerdp2 2.8.0. It's required by gnome-remote-desktop 43 for a new audio feature. Thank you, Jeremy Bicha
Bug#1016490: gnome-core: Switch default terminal app to gnome-console
Package: gnome-core Version: 1:42+4 X-Debbugs-CC: debian-gtk-gn...@lists.debian.org GNOME switched its default terminal app from gnome-terminal to gnome-console in GNOME 42. We briefly discussed doing this in for instance https://bugs.debian.org/1008805 Now that we are nearly at the end of the GNOME 43 development cycle, we can continue the discussion. The good news is that the blockers for basic Debian integration (x-terminal-emulator and new tabs opening in current working directory) are either fixed in 43 or there is a working merge proposal available. However, the upstream Console developers (and designers) were busy with other things this cycle and there still isn't a preferences dialog nor have there really been additions to the gsettings options either. Therefore, I believe Fedora 37 will continue to use GNOME Terminal by default. I also think our users will be happier with GNOME Terminal for Debian 12 too. Ubuntu 22.10 may switch to Console by default, but Ubuntu is at the start of their LTS development cycle while Debian is at the end. Thank you, Jeremy Bicha
Bug#1010421: gir-to-d: FTBFS with ldc 1.29
severity 1010421 important thankyou Hi! I'm reducing the severity since an easy-ish workaround is available and keeping this at a blocking severity prevents the workaround-included gir-to-d version to migrate. This is still an important issue though which should be fixed for the release, as it might be triggered by pretty much any D code at compile-time.
Bug#1016475: tmux sessions do not persist through logout
Hi, There’s nothing tmux can do right now about systemd killing user sessions without lingering enabled; just run `sudo loginctl enable-linger $USER`. Thanks.
Bug#1016003: yt-dlp: little script
Package: yt-dlp Version: 2022.07.18-1~bpo11+1 Followup-For: Bug #1016003 X-Debbugs-Cc: okgomdjgbm...@gmail.com Dear Maintainer, I fleshed out the proposal a bit more. The simplest possibillity is to make symlinks, of both the executable and module, to pretend they are youtube-dl and the module youyube_dl. This way, also python programs that load the module could work. A little bit better is this little wraper. you link the exec and module to it. -- #!/usr/bin/python3 import sys from yt_dlp import * if __name__ == "__main__": args=sys.argv.copy() args.pop(0) args=['--compat-options','youtube-dl']+args main(args) The compat options should improve the compatibility. Also, by using the cli options, it would risk less of breaking over time and keeping a fix stupid proof. Maybe a final improvement, would be to initialise the appropriate variable for the compatibility options, so that they are active in the module also. This would have a higher risk of breaking. I tested this with pafy(has an unrelated bug) and mpv on stable. This should stay relevent, for a whille.
Bug#1004628: qtav: FTBFS with ffmpeg 5.0
Heads up for those following this bug: qtav appears to be unmaintained upstream. My only interest in the package was to enable video playback in digikam. Digikam upstream has taken most of the qtav code, incorporated into digikam source tree and fixed it up. The next release of digikam will not need qtav and therefore I will no longer be maintaining qtav. The only other usage in Debian I can find is "matrix-mirage" (which is itself orphaned). My suggestion is to simply remove qtav from Debian. If you do need qtav for some other purpose, please respond here and consider yourself the new maintainer. Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#1015742: libspdlog1: ABI breakage without SONAME bump
FTR, To fix the ABI breakage in spdlog/1.10, I request the fmt/9 transition afterwards. Since with fmt/9 translation, spdlog ABI will bump to libspdlog1-fmt9(from libspdlog1-fmt8) anyway. See my comments on #1016418. I'm not sure if the release team will be happy with that. -- Shengjing Zhu
Bug#1016489: opendht: Prepare for new upstream version 2.4.9
Source: opendht
Version: 2.3.1-1
Severity: important
Tags: patch
Hello,
Please find attached the patch for preparing for new upstream version
2.4.9. Please pull in the latest release after merging this.
>From 19922ba06d462b6af7873f8889ec39a41d99b857 Mon Sep 17 00:00:00 2001
From: Amin Bandali
Date: Mon, 1 Aug 2022 12:29:29 -0400
Subject: [PATCH] Prepare for new upstream version 2.4.9
* d/watch: Tweak opts to use newly-suggested format in the current
uscan(1) manual for GitHub repositories, helping correctly detect
the new 2.4.9 release.
* d/patches: Refresh pkgconfig-static.patch for latest upstream
release.
---
debian/changelog | 14 ++
debian/patches/pkgconfig-static.patch | 2 +-
debian/watch | 4 ++--
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index e8d06fe..46925d8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+opendht (2.4.9-1) UNRELEASED; urgency=medium
+
+ [ Amin Bandali ]
+ * d/watch: Tweak opts to use newly-suggested format in the current
+uscan(1) manual for GitHub repositories, helping correctly detect
+the new 2.4.9 release.
+ * d/patches: Refresh pkgconfig-static.patch for latest upstream
+release.
+
+ [ Alexandre Viau ]
+ * New upstream version.
+
+ -- Alexandre Viau Mon, 01 Aug 2022 12:12:12 -0500
+
opendht (2.3.1-1) unstable; urgency=medium
[ Amin Bandali ]
diff --git a/debian/patches/pkgconfig-static.patch b/debian/patches/pkgconfig-static.patch
index 9955b84..ff82a1b 100644
--- a/debian/patches/pkgconfig-static.patch
+++ b/debian/patches/pkgconfig-static.patch
@@ -8,7 +8,7 @@ Author: Alexandre Viau
+++ b/opendht.pc.in
@@ -5,7 +5,7 @@
Name: OpenDHT
- Description: C++14 Distributed Hash Table library
+ Description: C++17 Distributed Hash Table library
Version: @VERSION@
-Libs: -L${libdir} -lopendht
+Libs: -L${libdir} -lopendht -lnettle -lgnutls -largon2 -lhttp_parser
diff --git a/debian/watch b/debian/watch
index b42aa67..31ca925 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
version=4
-opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*@ARCHIVE_EXT@)%@PACKAGE@-$1%" \
https://github.com/savoirfairelinux/opendht/tags \
- (?:.*?/)?@ANY_VERSION@@ARCHIVE_EXT@
+ (?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@
--
2.36.1
Bug#982459: mdadm examine corrupts host ext4
On Sun, 31 Jul 2022, Chris Hofstaedtler wrote: I can't see a difference that should matter from userspace. I have stared a bit at the kernel code... there have been quite some changes and fixes in this area. Which kernel version were you running when testing this? Could you retry on something >= 5.9? I.e. some version with patch 08fc1ab6d748ab1a690fd483f41e2938984ce353. Dear Chris, I believe that I was running 5.10 (bullseye). It looks like 5.18 (from backports) does not show the issue! (i.e. works) Some more details: I have now tried again: host: linux-image-5.10.0-16-amd64 5.10.127-2 mdadm 4.2-1~bpo11+1 chroot: mdadm 4.1-11 Some more details: This time I did get some dmesg BUG output as well (attached). It does not seem to be the same backtrace on two occurances. I also noticed that the BUG: report in dmesg does not happen directly when doing 'mdadm --examine --scan --config=partitions'. It rather occurs when some activity happens on the host filesystem, e.g. a 'touch /root/a' command. host: linux-image-5.18.0-0.bpo.1-amd64 5.18.2-1~bpo11+1 (did not re-install anything else, except upgraded zfs, also from backports (since pure bullseye would not compile with 5.18)) Does not exhibit the problem. I have tried with both kernels several times, and it was repeatable that 5.10 got stuck while 5.18 does not show issues. Reminder: to get the issue, /dev/ should not be mounted in the chroot. With /dev/ mounted, 5.10 also works. Best regards, Håkan[mÃ¥n aug 1 15:53:08 2022] BUG: kernel NULL pointer dereference, address: 0010 [mÃ¥n aug 1 15:53:08 2022] #PF: supervisor read access in kernel mode [mÃ¥n aug 1 15:53:08 2022] #PF: error_code(0x) - not-present page [mÃ¥n aug 1 15:53:08 2022] PGD 0 P4D 0 [mÃ¥n aug 1 15:53:08 2022] Oops: [#1] SMP PTI [mÃ¥n aug 1 15:53:08 2022] CPU: 2 PID: 284256 Comm: cron Tainted: P OE 5.10.0-16-amd64 #1 Debian 5.10.127-2 [mÃ¥n aug 1 15:53:08 2022] Hardware name: Dell Computer Corporation PowerEdge 2850/0T7971, BIOS A04 09/22/2005 [mÃ¥n aug 1 15:53:08 2022] RIP: 0010:__ext4_journal_get_write_access+0x29/0x120 [ext4] [mÃ¥n aug 1 15:53:08 2022] Code: 00 0f 1f 44 00 00 41 57 41 56 41 89 f6 41 55 41 54 49 89 d4 55 48 89 cd 53 48 83 ec 10 48 89 3c 24 e8 ab d7 bb e1 48 8b 45 30 <4c> 8b 78 10 4d 85 ff 74 2f 49 8b 87 e0 00 00 00 49 8b 9f 88 03 00 [mÃ¥n aug 1 15:53:08 2022] RSP: 0018:ae27c059fd60 EFLAGS: 00010246 [mÃ¥n aug 1 15:53:08 2022] RAX: RBX: 9d1b94505480 RCX: 9d1bc52e5e38 [mÃ¥n aug 1 15:53:08 2022] RDX: 9d1bc13782d8 RSI: 0c14 RDI: c096feb0 [mÃ¥n aug 1 15:53:08 2022] RBP: 9d1bc52e5e38 R08: 9d1be04d5230 R09: 0001 [mÃ¥n aug 1 15:53:08 2022] R10: 9d1bc985f000 R11: 001d R12: 9d1bc13782d8 [mÃ¥n aug 1 15:53:08 2022] R13: 9d1be04d5000 R14: 0c14 R15: 9d1bc13782d8 [mÃ¥n aug 1 15:53:08 2022] FS: 7fed5ecb1840() GS:9d1cd7c8() knlGS: [mÃ¥n aug 1 15:53:08 2022] CS: 0010 DS: ES: CR0: 80050033 [mÃ¥n aug 1 15:53:08 2022] CR2: 0010 CR3: 0001a46d8000 CR4: 06e0 [mÃ¥n aug 1 15:53:08 2022] Call Trace: [mÃ¥n aug 1 15:53:08 2022] ext4_orphan_del+0x23f/0x290 [ext4] [mÃ¥n aug 1 15:53:08 2022] ext4_evict_inode+0x31f/0x630 [ext4] [mÃ¥n aug 1 15:53:08 2022] evict+0xd1/0x1a0 [mÃ¥n aug 1 15:53:08 2022] __dentry_kill+0xe4/0x180 [mÃ¥n aug 1 15:53:08 2022] dput+0x149/0x2f0 [mÃ¥n aug 1 15:53:08 2022] __fput+0xe4/0x240 [mÃ¥n aug 1 15:53:08 2022] task_work_run+0x65/0xa0 [mÃ¥n aug 1 15:53:08 2022] exit_to_user_mode_prepare+0x111/0x120 [mÃ¥n aug 1 15:53:08 2022] syscall_exit_to_user_mode+0x28/0x140 [mÃ¥n aug 1 15:53:08 2022] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [mÃ¥n aug 1 15:53:08 2022] RIP: 0033:0x7fed5eea2d77 [mÃ¥n aug 1 15:53:08 2022] Code: 44 00 00 48 8b 15 19 a1 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 e9 a0 0c 00 f7 d8 64 89 02 b8 [mÃ¥n aug 1 15:53:08 2022] RSP: 002b:7ffd50452818 EFLAGS: 0202 ORIG_RAX: 0003 [mÃ¥n aug 1 15:53:08 2022] RAX: RBX: 55dab4578910 RCX: 7fed5eea2d77 [mÃ¥n aug 1 15:53:08 2022] RDX: 7fed5ef6e8a0 RSI: RDI: 0006 [mÃ¥n aug 1 15:53:08 2022] RBP: R08: R09: 7fed5ef6dbe0 [mÃ¥n aug 1 15:53:08 2022] R10: 006f R11: 0202 R12: 7fed5ef6f4a0 [mÃ¥n aug 1 15:53:08 2022] R13: R14: R15: 0001 [mÃ¥n aug 1 15:53:08 2022] Modules linked in: msr autofs4 nfsd auth_rpcgss nfsv3 nfs_acl nfs lockd grace sunrpc nfs_ssc fscache xt_mac xt_length xt_recent xt_multiport xt_tcpudp xt_state xt_conntrack
Bug#1016394: column_family.cc:1494: rocksdb::ColumnFamilySet::~ColumnFamilySet(): Assertion `last_ref' failed.
Control: tags -1 +moreinfo Hi, On Sun, Jul 31, 2022 at 4:09 AM Linas Vepstas wrote: > Software that I maintain is generating the error message > ``` > ./db/column_family.cc:1494: rocksdb::ColumnFamilySet::~ColumnFamilySet(): > Assertion `last_ref' failed. > ``` [...] > I think the bug is benign, in that it only happens when shutting down, > and I assume there is no data corruption as the result of it, but ... > I dunno. Version 7.3.1 of RocksDB will migrate to testing this week. Please test your software with this version and report back. But honestly, I don't know what to do with this. I'm not a developer of RocksDB itself. Don't know what caused this message you reported. Regards, Laszlo/GCS
Bug#1016184: unattended-upgrades: Unattended-upgrades has file lock after completion
Hi Michael, Ask and ye shall receive: apt-get dist-upgrade -y -m E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 629520 (unattended-upgr) N: Be aware that removing the lock file is not a solution and may break your system. E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock- frontend), is another process using it? ps afx | grep /proc/629520/ 1263559 pts/0S+ 0:00 | | \_ grep /proc/629520/ lsof -p 629520 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME unattende 629520 root cwd DIR8,5 4096 2359297 /var/backups unattende 629520 root rtd DIR8,4 4096 2 / unattende 629520 root txt REG8,4 5900104 3154250 /usr/bin/python3.10 unattende 629520 root DEL REG8,5 7082389 /var/cache/apt/pkgcache.bin unattende 629520 root DEL REG8,5 7077991 /var/cache/apt/pkgcache.bin unattende 629520 root mem REG8,4 4713720 3152806 /usr/lib/x86_64-linux-gnu/libcrypto.so.3 unattende 629520 root mem REG8,4 700448 3152807 /usr/lib/x86_64-linux-gnu/libssl.so.3 unattende 629520 root mem REG8,463568 3673413 /usr/lib/python3.10/lib-dynload/_hashlib.cpython-310-x86_64- linux-gnu.so unattende 629520 root mem REG8,4 212304 3673415 /usr/lib/python3.10/lib-dynload/_ssl.cpython-310-x86_64-linux- gnu.so unattende 629520 root mem REG8,4 161864 3146718 /usr/lib/x86_64-linux-gnu/libgpg-error.so.0.33.0 unattende 629520 root mem REG8,438864 3146762 /usr/lib/x86_64-linux-gnu/libcap.so.2.44 unattende 629520 root mem REG8,4 1332480 3146730 /usr/lib/x86_64-linux-gnu/libgcrypt.so.20.4.1 unattende 629520 root DEL REG8,4 3156120 /usr/lib/x86_64-linux-gnu/libsystemd.so.0.34.0 unattende 629520 root DEL REG8,4 3149630 /usr/lib/x86_64-linux-gnu/libudev.so.1.7.4 unattende 629520 root mem REG8,4 751840 3145954 /usr/lib/x86_64-linux-gnu/libzstd.so.1.5.2 unattende 629520 root mem REG8,4 137568 3146757 /usr/lib/x86_64-linux-gnu/liblz4.so.1.9.3 unattende 629520 root mem REG8,4 2190408 3151362 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30 unattende 629520 root mem REG8,4 158400 3146118 /usr/lib/x86_64-linux-gnu/liblzma.so.5.2.5 unattende 629520 root mem REG8,4 125320 3149167 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 unattende 629520 root mem REG8,4 2055472 3149284 /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0.0 unattende 629520 root mem REG8,422728 3152663 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 unattende 629520 root mem REG8,435888 3172444 /usr/lib/x86_64-linux-gnu/librt-2.33.so unattende 629520 root mem REG8,4 351024 3674340 /usr/lib/python3/dist-packages/apt_pkg.cpython-310-x86_64- linux-gnu.so unattende 629520 root mem REG8,4 206984 3157107 /usr/lib/x86_64-linux-gnu/girepository-1.0/GLib-2.0.typelib unattende 629520 root mem REG8,4 362276 3157110 /usr/lib/x86_64-linux-gnu/girepository-1.0/Gio-2.0.typelib unattende 629520 root mem REG8,4 215704 3675617 /usr/lib/python3/dist-packages/cairo/_cairo.cpython-310-x86_64- linux-gnu.so unattende 629520 root mem REG8,447312 3169945 /usr/lib/x86_64-linux-gnu/libmd.so.0.0.5 unattende 629520 root mem REG8,484840 3150673 /usr/lib/x86_64-linux-gnu/libbsd.so.0.11.6 unattende 629520 root mem REG8,4 137376 3167131 /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1.0.9 unattende 629520 root mem REG8,414496 3152661 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 unattende 629520 root mem REG8,451360 3167133 /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1.0.9 unattende 629520 root mem REG8,430776 3149260 /usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0 unattende 629520 root mem REG8,481568 3152672 /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 unattende 629520 root mem REG8,4 1322504 3152669 /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0 unattende 629520 root mem REG8,447608 3167671 /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 unattende 629520 root mem REG8,4 170936 3152665
Bug#1015742: Reverted droping symbols
Hi Andreas, On Sun, Jul 31, 2022 at 02:48:20PM +0200, Andreas Tille wrote: > Hi Boyuan Yang, > > I admit symbols files are a maintenance burden for C++ libraries. > However, it helps to spot ABI changes for new upstream versions. To > reduce the maintenance burden while keeping that ABI change detection > functionality I frequently maintain amd64 symbols only. Motivated by > this bug report I have re-added the symbols you droped in your last > upload. Please also see my last attemp to drop the symbol. https://salsa.debian.org/med-team/spdlog/-/commit/2eb3ef1436723302070f753bbed3c0bea745a9d1 symbol file for spdlog doesn't work. spdlog abi is tracked manually in d/rules, https://salsa.debian.org/med-team/spdlog/-/blob/master/debian/rules#L12
Bug#1016385: asn1c-doc: trying to overwrite '/usr/share/doc/asn1c/BUGS', which is also in package asn1c 0.9.28+dfsg-3
Followup-For: Bug #1016385 The existing Breaks+Replaces must be bumped to (<< 0.9.28+dfsg-4) since more files were moved into the -doc package. Andreas
Bug#1016488: openvpn: OpenVPN client prevents shutdown process.
Package: openvpn Version: 2.6.0~git20220518+dco-3 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? When openVPN client is connecter and tyring to shutdown the computer using init 0 command. * What exactly did you do (or not do) that was effective (or ineffective)? Waiting 90s gets the client killed. However, client should not be hanging. Issue is that network is down and client can't reconnect (expected) * What was the outcome of this action? * What outcome did you expect instead? Client should exit quickly instead of waiting for timeout and get killed. Here is an extract of the journalctl: sep 07 04:39:11 t460s NetworkManager[9152]: [1631003951.8511] device (wlp4s0): no secrets: No ag> sep 07 04:39:11 t460s NetworkManager[9152]: [1631003951.8522] device (wlp4s0): Activation: faile> sep 07 04:39:15 t460s ovpn-client[8902]: write UDP: Network is unreachable (code=101) sep 07 04:39:15 t460s ovpn-client[8902]: Network unreachable, restarting sep 07 04:39:15 t460s ovpn-client[8902]: SIGUSR1[soft,network-unreachable] received, process restarting sep 07 04:39:15 t460s ovpn-client[8902]: Restart pause, 300 second(s) sep 07 04:40:38 t460s systemd[1]: session-2.scope: Stopping timed out. Killing. -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (100, 'bullseye- fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openvpn depends on: ii debconf [debconf-2.0] 1.5.77 ii libc6 2.31-13+deb11u3 ii liblz4-1 1.9.3-2 ii liblzo2-2 2.10-2 ii libnl-3-2003.4.0-1+b1 ii libnl-genl-3-200 3.4.0-1+b1 ii libpam0g 1.4.0-9+deb11u1 ii libpkcs11-helper1 1.27-1 pn libssl3 ii libsystemd0247.3-7 ii lsb-base 11.1.0 ii systemd247.3-7 Versions of packages openvpn recommends: ii easy-rsa 3.0.8-1 Versions of packages openvpn suggests: ii openssl 1.1.1n-0+deb11u3 pn openvpn-dco-dkms pn openvpn-systemd-resolved ii resolvconf1.87 -- debconf information:
Bug#1016487: rust-rustls: please make the build reproducible
Source: rust-rustls Version: 0.20.6-6 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that rust-rustls could not be built reproducibly. This is because, whilst the package does attempt to clean up the offending sslkeylogfile.txt file, this file is actually generated under the rustls/ directory. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2022-08-01 09:43:13.283451411 -0700 --- b/debian/rules 2022-08-01 09:46:54.628158679 -0700 @@ -10,7 +10,7 @@ # cleanup after test execute_after_dh_auto_test: - rm -rf sslkeylogfile.txt + rm -rf rustls/sslkeylogfile.txt # mangle system-shared code to use system-shared test-ca and fuzz data execute_after_dh_auto_install:
Bug#1001776: yt-dlp: error message
Package: yt-dlp Version: 2022.07.18-1~bpo11+1 Followup-For: Bug #1001776 X-Debbugs-Cc: okgomdjgbm...@gmail.com Dear Maintainer, I don't know if you care about this, but an error message asks to do a "yt-dlp -U" please report this issue on https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using yt-dlp -U
Bug#1016486: wayfire: please make the build reproducible
Source: wayfire Version: 0.7.4-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0] we noticed that wayfire could not be built reproducibly. This is because it embedded an absolute build path into a config.h file. A patch is attached that fixes this value to a known/fixed value — the absolute build path won't exist at runtime anyway, so this is at least "no worse". [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1969-12-31 16:00:00.0 -0800 --- b/debian/patches/reproducible-build.patch 2022-08-01 09:32:24.630250887 -0700 @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2022-08-01 + +--- wayfire-0.7.4.orig/config.h.in wayfire-0.7.4/config.h.in +@@ -3,7 +3,7 @@ + + #define INSTALL_PREFIX "@INSTALL_PREFIX@" + #define PLUGIN_PATH "@PLUGIN_PATH@" +-#define WF_SRC_DIR "@WF_SRC_DIR@" ++#define WF_SRC_DIR "/nonexistent" + #define PLUGIN_XML_DIR "@PLUGIN_XML_DIR@" + #define SYSCONFDIR "@SYSCONFDIR@" + #define WF_DEFAULT_CONFIG_BACKEND "@DEFAULT_CONFIG_BACKEND@" --- a/debian/patches/series 1969-12-31 16:00:00.0 -0800 --- b/debian/patches/series 2022-08-01 09:32:23.738249510 -0700 @@ -0,0 +1 @@ +reproducible-build.patch
Bug#1014391: scilab: CVE-2022-30045 incorrect memory handling in ezml support leading to a heap out-of-bounds read
Hello, Le 05/07/2022 à 11:19, Neil Williams a écrit : Source: scilab Version: 6.1.1+dfsg2-3 Severity: important Tags: security X-Debbugs-Cc: codeh...@debian.org, Debian Security Team Hi, The following vulnerability was published for scilab. CVE-2022-30045[0]: | An issue was discovered in libezxml.a in ezXML 0.8.6. The function | ezxml_decode() performs incorrect memory handling while parsing | crafted XML files, leading to a heap out-of-bounds read. 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-2022-30045 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30045 Please adjust the affected versions in the BTS as needed. While Scilab indeed ships ezxml.c, I am not sure how this can be exploited. The code is probably only used to load scicos/xcos schema. https://github.com/scilab/scilab/blob/b0937f19e4b8ddf416ca9a9a433bcbbd3f4ef2c0/scilab/modules/scicos/src/c/ezxml.c Cheers Sylvestre
Bug#1016357: Fails tests with insufficient network connectivity
On Mon, Aug 1, 2022 at 11:50 PM Nilesh Patra wrote: > > On 8/1/22 8:38 PM, Shengjing Zhu wrote: > > On Mon, Aug 1, 2022 at 11:05 PM Nilesh Patra wrote: > >> > >> On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote: > > The package fails tests (see log of failing test below) when run on a > > machine with limited network (in this case: Can only reach the > > relevant APT repository server). This is a policy violation, which > > says that package tests must only access local resources services that > > were also spun up by the test. This tests tries to reach > > stun1.l.google.com though. And fails with a nil pointer dereference... > > I am not aware of any such policy -- can you please point me to it? > >>> > >>> Debian policy 4.9: > >>> > >>> For packages in the main archive, required targets must not attempt > >>> network access, except, via the loopback interface, to services on the > >>> build host that have been started by the build. > >> > >> Thanks for the link. I was under the impression that network access is > >> already > >> forbidden in the buildd environment, and package would not build if it > >> tries > >> to do so -- not sure when that changed? > > > > Because schroot doesn't implement network isolation. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802849 > > I am aware that this does not work locally because of the bug. > But one quick question - I was talking about the buildd (buildd.debian.org) > machines > here. In the wiki, it says there is 'no network' in the machines[1]. However > when I see the > setup using schroot[2]. Is it the same bug affecting it or do I miss > something (since the > package was building fine earlier anyway) > > [1]: https://wiki.debian.org/buildd#buildd_Differences > [2]: https://wiki.debian.org/BuilddSetup Wiki is not always up to date. If you want the details, you'd better ask buildd admins, and I'm not. -- Shengjing Zhu
Bug#1016357: Fails tests with insufficient network connectivity
On 8/1/22 8:38 PM, Shengjing Zhu wrote: On Mon, Aug 1, 2022 at 11:05 PM Nilesh Patra wrote: On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote: The package fails tests (see log of failing test below) when run on a machine with limited network (in this case: Can only reach the relevant APT repository server). This is a policy violation, which says that package tests must only access local resources services that were also spun up by the test. This tests tries to reach stun1.l.google.com though. And fails with a nil pointer dereference... I am not aware of any such policy -- can you please point me to it? Debian policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. Thanks for the link. I was under the impression that network access is already forbidden in the buildd environment, and package would not build if it tries to do so -- not sure when that changed? Because schroot doesn't implement network isolation. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802849 I am aware that this does not work locally because of the bug. But one quick question - I was talking about the buildd (buildd.debian.org) machines here. In the wiki, it says there is 'no network' in the machines[1]. However when I see the setup using schroot[2]. Is it the same bug affecting it or do I miss something (since the package was building fine earlier anyway) [1]: https://wiki.debian.org/buildd#buildd_Differences [2]: https://wiki.debian.org/BuilddSetup -- Best, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Bug#1016485: libnl3: please upgrade to release 3.7.0
Source: libnl3 Version: 3.5.0-0.1 Severity: wishlist Tags: upstream Dear Maintainer, Upstream has released two new versions this year: 3.6.0 and 3.7.0. Is it possible to upgrade to the latest one to get the new features and bug fixes please? Kind regards, Matt
Bug#1016482: jamulus: please add support for riscv64
# bts-close because of the reason below close 1016482 thanks Bo YU dixit: >The jamulus can be built on real riscv64 hardware successfully with the >change attached, so could you please add riscv64 as a build target in >new upload? thanks It can also be built successfully on big-endian platforms, but that doesn’t mean it works correctly. Upstream’s custom build for opus custom modes precludes adding more architectures, but as #686777 seems to have been fixed I was intending on permitting all architectures in an upload that can use this (I’ll have to figure out how to use it first). But as-is, this patch isn’t suitable. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1010777: Packaging qflipper - comaintainers wanted
I just pushed some initial packaging work to salsa[1]. This is still unclean and not exactly tested. Two main points need to be taken care of before uploading: - Proper d/copyright. Any help here is highly appreciated - Disable the builtin autoupdater Comaintenance or a team umbrella to put this under would also be very welcome. Cheers, sur5r [1] https://salsa.debian.org/debian/qflipper -- ceterum censeo microsoftem esse delendam. pgpSTv7urvt80.pgp Description: OpenPGP digital signature
Bug#1016484: Frequent kernel panics following update 5.10.120-1 -> 5.10.127-1
Package: LINUX-IMAGE-5.10.0-16-AMD64 Version: 5.10.127-1 Debian Bullseye, fully up to date. After an unattended upgrade on 10 July 2022, the system started locking up multiple times per day. This machine is a small office server, including mail, web, database, etc. services and serving files from a zfs pool over NTFSv4 to 5-10 clients on premise. Some of the kernel panic lines seem to be related to openzfs, others to kvm, which is why I file the bug to this package. Below a list of the kernel panic information extracted from the journals. Since I have downgraded the kernel to 5.10.0.13, the machine is running reliably again. First kernel panic: jul 11 16:58:17 luke kernel: VERIFY3(hdr->b_type == type) failed (1426261535 == 2) jul 11 16:58:17 luke kernel: PANIC at arc.c:1571:arc_buf_type() jul 11 16:58:17 luke kernel: Showing stack for process 599 jul 11 16:58:17 luke kernel: CPU: 13 PID: 599 Comm: dbuf_evict Tainted: P IOE 5.10.0-16-amd64 #1 Debian 5.10.127-1 jul 11 16:58:17 luke kernel: Hardware name: HPE ProLiant DL160 Gen10/ProLiant DL160 Gen10, BIOS U31 11/13/2019 jul 11 16:58:17 luke kernel: Call Trace: jul 11 16:58:17 luke kernel: dump_stack+0x6b/0x83 jul 11 16:58:17 luke kernel: spl_panic+0xd4/0xfc [spl] jul 11 16:58:17 luke kernel: ? __slab_free+0x3b0/0x430 jul 11 16:58:17 luke kernel: ? __vunmap+0x228/0x290 jul 11 16:58:17 luke kernel: ? spl_kmem_cache_free+0x13d/0x1b0 [spl] jul 11 16:58:17 luke kernel: ? spl_kmem_cache_free+0x13d/0x1b0 [spl] jul 11 16:58:17 luke kernel: remove_reference.constprop.0+0x9b/0xa0 [zfs] jul 11 16:58:17 luke kernel: arc_buf_destroy+0x7e/0x100 [zfs] jul 11 16:58:17 luke kernel: dbuf_destroy+0x2e/0x430 [zfs] jul 11 16:58:17 luke kernel: dbuf_evict_one+0xfb/0x120 [zfs] jul 11 16:58:17 luke kernel: dbuf_evict_thread+0x128/0x1d0 [zfs] jul 11 16:58:17 luke kernel: ? dbuf_evict_one+0x120/0x120 [zfs] jul 11 16:58:17 luke kernel: thread_generic_wrapper+0x6f/0x80 [spl] jul 11 16:58:17 luke kernel: ? __thread_exit+0x20/0x20 [spl] jul 11 16:58:17 luke kernel: kthread+0x11b/0x140 jul 11 16:58:17 luke kernel: ? __kthread_bind_mask+0x60/0x60 jul 11 16:58:17 luke kernel: ret_from_fork+0x1f/0x30 [...] jul 11 17:00:00 luke kernel: list_add corruption. prev->next should be next (96737bbd12f0), but was 2d766e206e676953. (prev=966e06c0ec88). jul 11 17:00:00 luke kernel: [ cut here ] jul 11 17:00:00 luke kernel: kernel BUG at lib/list_debug.c:26! jul 11 17:00:00 luke kernel: invalid opcode: [#1] SMP NOPTI jul 11 17:00:00 luke kernel: CPU: 0 PID: 596 Comm: arc_evict Tainted: P IOE 5.10.0-16-amd64 #1 Debian 5.10.127-1 jul 11 17:00:00 luke kernel: Hardware name: HPE ProLiant DL160 Gen10/ProLiant DL160 Gen10, BIOS U31 11/13/2019 jul 11 17:00:00 luke kernel: RIP: 0010:__list_add_valid.cold+0x3d/0x3f jul 11 17:00:00 luke kernel: Code: f2 4c 89 c1 48 89 fe 48 c7 c7 10 1f b2 a7 e8 31 14 ff ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 b8 1e b2 a7 e8 1a 14 ff ff <0f> 0b 48 89 fe 48 c7 c7 48 1> jul 11 17:00:00 luke kernel: RSP: 0018:b3048096bd60 EFLAGS: 00010246 jul 11 17:00:00 luke kernel: RAX: 0075 RBX: 96737bbd12f0 RCX: jul 11 17:00:00 luke kernel: RDX: RSI: 96749fc1ca00 RDI: 96749fc1ca00 jul 11 17:00:00 luke kernel: RBP: 9673ce89b438 R08: R09: b3048096bb88 jul 11 17:00:00 luke kernel: R10: b3048096bb80 R11: a80cb448 R12: 966e06c0ec88 jul 11 17:00:00 luke kernel: R13: 9673ce89b438 R14: 966da1539680 R15: c1cf8a10 jul 11 17:00:00 luke kernel: FS: () GS:96749fc0() knlGS: jul 11 17:00:00 luke kernel: CS: 0010 DS: ES: CR0: 80050033 jul 11 17:00:00 luke kernel: CR2: 0296a8dbd000 CR3: 00060700a002 CR4: 007726f0 jul 11 17:00:00 luke kernel: DR0: DR1: DR2: jul 11 17:00:00 luke kernel: DR3: DR6: fffe0ff0 DR7: 0400 jul 11 17:00:00 luke kernel: PKRU: 5554 jul 11 17:00:00 luke kernel: Call Trace: jul 11 17:00:01 luke kernel: multilist_sublist_move_forward+0x7c/0xa0 [zfs] jul 11 17:00:01 luke kernel: arc_evict_state+0x1e3/0x900 [zfs] jul 11 17:00:01 luke kernel: arc_evict_cb+0x754/0x7d0 [zfs] jul 11 17:00:01 luke kernel: zthr_procedure+0x139/0x150 [zfs] jul 11 17:00:01 luke kernel: ? zrl_is_locked+0x20/0x20 [zfs] jul 11 17:00:01 luke kernel: thread_generic_wrapper+0x6f/0x80 [spl] jul 11 17:00:01 luke kernel: ? __thread_exit+0x20/0x20 [spl] jul 11 17:00:01 luke kernel: kthread+0x11b/0x140 jul 11 17:00:01 luke kernel: ? __kthread_bind_mask+0x60/0x60 jul 11 17:00:01 luke kernel: ret_from_fork+0x1f/0x30 jul 11 17:00:01 luke kernel: Modules linked in: cbc cts rpcsec_gss_krb5 xt_conntrack nf_conntrack_netlink xt_multiport xt_nat xt_tcpudp xt_addrtype xt_mark nft_chain_nat xt_MASQUERADE nf_nat >
Bug#1016357: Fails tests with insufficient network connectivity
On Mon, Aug 1, 2022 at 11:05 PM Nilesh Patra wrote: > > On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote: > > > > The package fails tests (see log of failing test below) when run on a > > > > machine with limited network (in this case: Can only reach the > > > > relevant APT repository server). This is a policy violation, which > > > > says that package tests must only access local resources services that > > > > were also spun up by the test. This tests tries to reach > > > > stun1.l.google.com though. And fails with a nil pointer dereference... > > > > > > I am not aware of any such policy -- can you please point me to it? > > > > Debian policy 4.9: > > > > For packages in the main archive, required targets must not attempt > > network access, except, via the loopback interface, to services on the > > build host that have been started by the build. > > Thanks for the link. I was under the impression that network access is already > forbidden in the buildd environment, and package would not build if it tries > to do so -- not sure when that changed? Because schroot doesn't implement network isolation. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802849 > > Also I presume that this policy is only for build, and not autopkgtests? Yes. -- Shengjing Zhu
Bug#1016357: Fails tests with insufficient network connectivity
On Mon, Aug 01, 2022 at 10:54:20PM +0800, Shengjing Zhu wrote: > > > The package fails tests (see log of failing test below) when run on a > > > machine with limited network (in this case: Can only reach the > > > relevant APT repository server). This is a policy violation, which > > > says that package tests must only access local resources services that > > > were also spun up by the test. This tests tries to reach > > > stun1.l.google.com though. And fails with a nil pointer dereference... > > > > I am not aware of any such policy -- can you please point me to it? > > Debian policy 4.9: > > For packages in the main archive, required targets must not attempt > network access, except, via the loopback interface, to services on the > build host that have been started by the build. Thanks for the link. I was under the impression that network access is already forbidden in the buildd environment, and package would not build if it tries to do so -- not sure when that changed? Also I presume that this policy is only for build, and not autopkgtests? > > I've seen several packages in debian that access external URLs, and have > > never seen them as any sort of policy violation, no such bugs either. > > > > Please open bugs when you see that. There are a couple of python packages that I can think of doing so. Will open. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1016483: pkg-js-tools: pkgjs-depends eats all memory and dies (probably by linux OOM Killer)
Package: pkg-js-tools Version: 0.14.31 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I tries run the following command in a pristine Sid environment: pkgjs-depends @solid/community-server After hanging at 4% for 5-6 minutes, the process ate all available memory (16+ GB!) and then died (probably killed by the linux OOM Killer). - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLn6OoACgkQLHwxRsGg ASGaPQ/+MfyPlcyU7sudQWEbeaW/wG/dFBbENcXSNsGeLu8JMFA3AzNZ+Ge0m/rx ezT2z2tF8O9gG2+80buD5clRRiHL0RYQbZkql7drY5YSSgvVXm9wZNgVevznZ9wh 0+OKjEMSakNmC6LSJ/ezaxehFFNwGZduJdlhKp67+cYlA2hiTuErPJKdO7H9nlf/ IimnjId5hml5YBrsjrtOQ00vHyXGw5i622BKAmjMDmQ4gkjtOn26r6wI6Xc32eGW lj65pqZUMpteD1KyV9n8TxSP30bpxTu9hAf3bKVNIDYv2mahJaWtQ3DowLxeJfuu TLgH8vlvR0R1kYvlvZZzISslH8huUw99GPu4sXsD700JiTEmZlYiyfnXtcYZlSaV hUwlMKpSFmNvmcSaS6cPxmoKzhBY+0rMGdi+dZE3utgBBoP08f73DYXdLy28bcyX zP89iDTMgnM7Fbo14/3tCW0szTF7k2c0OMhcpzDhDpvf2cEA6p/mCF/m9PF+h4Wv 8WfUKvCsiIgLnaHVfJ0ewCu44HlKtMWoI/OtzjEpBuawQ8udWp7WwSR+YhoLDOnM K+XVNVTJ4dfWGUnva/u4cM3ySAWdjj9gaDXhS+mQankznWr6GowdMrmoylX4pee7 AdM1xW1iVr9ZGvks5NrTbHEfm19WgwmbcC5TXhgLM5YgP6KgjNU= =3hin -END PGP SIGNATURE-
Bug#1016357: Fails tests with insufficient network connectivity
On Mon, Aug 1, 2022 at 9:12 PM Nilesh Patra wrote: > > Control: severity -1 normal > > On Fri, 29 Jul 2022 15:11:10 -0700 Sven Mueller > wrote: > > Package: golang-github-pion-turn.v2 > > Version: 2.0.8-2 > > Severity: Serious > > > > The package fails tests (see log of failing test below) when run on a > > machine with limited network (in this case: Can only reach the > > relevant APT repository server). This is a policy violation, which > > says that package tests must only access local resources services that > > were also spun up by the test. This tests tries to reach > > stun1.l.google.com though. And fails with a nil pointer dereference... > > I am not aware of any such policy -- can you please point me to it? Debian policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. > I've seen several packages in debian that access external URLs, and have > never seen them as any sort of policy violation, no such bugs either. > Please open bugs when you see that. -- Shengjing Zhu
Bug#1016482: jamulus: please add support for riscv64
Source: jamulus
Version: 3.8.2+dfsg-1
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear jamulus Maintainer,
The jamulus can be built on real riscv64 hardware successfully with the
change attached, so could you please add riscv64 as a build target in
new upload? thanks
--
Regards,
--
Bo YU
diff -Nru jamulus-3.8.2+dfsg/debian/control jamulus-3.8.2+dfsg/debian/control
--- jamulus-3.8.2+dfsg/debian/control 2022-02-25 18:24:21.0 +
+++ jamulus-3.8.2+dfsg/debian/control 2022-02-25 18:52:53.0 +
@@ -16,7 +16,7 @@
Package: jamulus
# will be "any" once #686777 is fixed
# armel might work but better safe than crash
-Architecture: amd64 arm64 armhf i386
+Architecture: amd64 arm64 armhf i386 riscv64
Multi-Arch: foreign
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
signature.asc
Description: PGP signature
Bug#1001214: Getting EFI Boot Guard into Debian
Control: retitle -1 ITP: efibootguard -- UEFI-based bootloader Control: owner -1 Quirin Gylstorff After an internal discuss I would step up as the Maintainer for efibootguard. Thanks, Quirin
Bug#1016474: cryptsetup: The system installed on encrypted LVM (both root and swap partitions) freezes during massive writes
On Mon, 01 Aug 2022 at 15:32:19 +0200, Wojciech Zabołotny wrote: > BTW. I'm really amused that no one else complained about that issue. > The problem exists for at least a few years. Not claiming that no one would benefit from --perf-*, but as the link from the cloudflare blog suggests it appears most users don't suffer from the overhead. Pretty sure most systems don't freeze under heavy write anyway :-) -- Guilhem. signature.asc Description: PGP signature
Bug#922545: [pkg-lxc-devel] Bug#922545: Bug#922545: lxc: FTBFS on hppa -
Bonjour, > > The same error occurs on alpha, m68k, sh4 and sparc64. > > > > libseccomp-dev is available on hppa but not on the other arches. lxc build > > successfully on hppa if I include the libseccomp-dev > > dependency. Wasn't able to fix symbol issue. > > I am not sure about how I can make the symbols file vary for > architectures. I'll ask to other developers. > > If you have recommendations I'm eager to take them! :) Architecture-specific symbols files can be supplied by naming them liblxc1.symbols., for example liblxc1.symbols.sparc64. The attached liblxc1.symbols.sparc64 was created by copying liblxc1.symbols and then applying the attached symbols.diff. I think the same file could be used for liblxc1.symbols.alpha, liblxc1.symbols.m68k, liblxc1.symbols.sh4 and liblxc1.symbols.sparc64. I have verified that building lxc 4.0.11-1 against sid on sparc64 succeeds when the attached liblxc1.symbols.sparc64 is included in the debian directory. Another approach could be to lower DPKG_GENSYMBOLS_CHECK_LEVEL to 0 on architectures where libseccomp-dev is not available. This will still log the symbol differences but without failing the build. This can be achieved by applying the attached rules.diff against debian/rules. This approach avoids having to maintain architecture-specific symbols files. I have verified that building lxc 4.0.11-1 against sid on sparc64 succeeds with the attached rules.diff applied. Both approaches are documented at [1]. Could you please consider adopting either one of these approaches? Thanks! For hppa, as described by Dave Anglin above, libseccomp-dev is actually available and changing the dependency from libseccomp-dev [!alpha !hppa !m68k !sh4 !sparc64] to libseccomp-dev [!alpha !m68k !sh4 !sparc64] should allow the build to succeed there. Merci! Tom [1]: https://manpages.debian.org/unstable/dpkg-dev/dpkg-gensymbols.1.en.html rules.diff Description: Binary data symbols.diff Description: Binary data liblxc1.symbols.sparc64 Description: Binary data
Bug#1016357: Fails tests with insufficient network connectivity
Control: severity -1 normal On Fri, 29 Jul 2022 15:11:10 -0700 Sven Mueller wrote: > Package: golang-github-pion-turn.v2 > Version: 2.0.8-2 > Severity: Serious > > The package fails tests (see log of failing test below) when run on a > machine with limited network (in this case: Can only reach the > relevant APT repository server). This is a policy violation, which > says that package tests must only access local resources services that > were also spun up by the test. This tests tries to reach > stun1.l.google.com though. And fails with a nil pointer dereference... I am not aware of any such policy -- can you please point me to it? I've seen several packages in debian that access external URLs, and have never seen them as any sort of policy violation, no such bugs either. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1016453: python-tornado breaks python-bonsai autopkgtest: 'TornadoLDAPConnectionTest' object has no attribute 'should_close_asyncio_loop'
Hi Paul, I have checked in bonsai code base, and there is no reference to should_close_asyncio_loop. It looks like a tornado thing. However, looking at the full error trace, I can see that: > ldapwhoami: unrecognized option -� > Issue LDAP Who am I? operation to request user's authzid > > usage: ldapwhoami [options] > Common options: > -d level set LDAP debugging level to `level' > -D binddn bind DN > [...] Which may cause the tests to be aborted early and cause should_close_asyncio_loop to be accessed[1] before it is defined[2] in tornado. [1]: https://salsa.debian.org/python-team/packages/python-tornado/-/blob/master/tornado/testing.py#L282 [2]: https://salsa.debian.org/python-team/packages/python-tornado/-/blob/master/tornado/testing.py#L204-230 There were a few unreleased patches from bonsai[3], I'll make a new release. [3]: https://salsa.debian.org/python-team/packages/python-bonsai/-/commit/22d2533ab8094a299d1816a46917070e2b251265 In the meantime, I think that the should_close_asyncio_loop attribute should be defined in tornado.testing.AsyncTestCase.__init__() instead of in tornado.testing.AsyncTestCase.setUp().
Bug#1016363: libx11-6 1.8.1 also breaks glxinfo
With libx11-6 1.8.1 I get: |glxinfo name of display: :0 glxinfo: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed. Abgebrochen| rebuilding libx11 with the --disable-thread-safety-constructor flag solved the issue. |System: Host: box Kernel: 5.18.0-rt11 arch: x86_64 bits: 64 compiler: gcc v: 12.1.0 Desktop: Cinnamon v: 5.2.7 Distro: siduction 18.3.0 Patience - cinnamon - (201805132102) base: Debian GNU/Linux bookworm/sid Machine: Type: Desktop System: Dell product: Inspiron 3668 v: N/A serial: Mobo: Dell model: 07KY25 v: A00 serial: UEFI: Dell v: 1.4.0 date: 07/19/2017 CPU: Info: quad core model: Intel Core i5-7400 bits: 64 type: MCP arch: Kaby Lake rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB Speed (MHz): avg: 3300 min/max: 800/3001 boost: enabled cores: 1: 3300 2: 3300 3: 3300 4: 3300 bogomips: 24000 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx Graphics: Device-1: Intel HD Graphics 630 vendor: Dell driver: i915 v: kernel arch: Gen-9.5 bus-ID: 00:02.0 Device-2: NVIDIA GP108 [GeForce GT 1030] vendor: Dell driver: nvidia v: 470.129.06 arch: Pascal bus-ID: 01:00.0 Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.3 driver: X: loaded: modesetting,nvidia unloaded: fbdev,nouveau,vesa gpu: i915,nvidia resolution: 1920x1080~60Hz|
Bug#1016474: cryptsetup: The system installed on encrypted LVM (both root and swap partitions) freezes during massive writes
On Mon, 01 Aug 2022 at 14:10:26 +0200, Wojciech Zabołotny wrote: > Modifying the mapping parameters with: > # cryptsetup --perf-no_write_workqueue refresh name_of_the_mapping > > indeed eliminates the problem. > Isn't it then the problem with default mapping parameters used in > cryptsetup? IMHO not: if setting up these flags were desirable in all cases then the better place to change the defaults would be the dm-crypt subsystem (ie the kernel). Note that if the --perf-* flag(s) improve performance on your system you can set them in /etc/crypttab too, so the wrappers pass them along when mapping the volume (like for discard). -- Guilhem. signature.asc Description: PGP signature
Bug#1016090: python-django breaks lots of autopkgtests
On Tue, 26 Jul 2022, Paul Gevers wrote: > Source: python-django > Control: found -1 python-django/2:4.0.6-1 I'm surprised that we uploaded an non-LTS release to unstable. Chris, why did you do that? > I note that the changelog has this: > "This security release mitigates the issue, but we have identified > improvements to the Database API methods related to date extract and > truncate that would be beneficial to add to Django 4.1 before it's final > release. This will impact 3rd party database backends using Django 4.1 > release candidate 1 or newer, until they are able to update to the API > changes. We apologize for the inconvenience." > > I guess that means that these breakages might be intentional, but even if > all this is to be expected, it would be good to add a *versioned* Breaks to > python-django3 for all the packages that it really breaks (not just the > autopkgtest). I don't think that the above changelog entry is relevant. The issue is broader, it's more likely that we moved from 3.2 to 4.0 and that many packages have not been prepared for that switch. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.
On 2022-07-31 10:39, Osamu Aoki wrote: im-config has gone through several changes last several years to accommodate non-ibus for GNOME on wayland. We may have introduced some regression for X based system. It's possible, of course. OTOH I just installed an XFCE system (Xubuntu 22.04), installed ibus-anthy, and things just work. Even if my keyboard does not include any special Japanese keys... `ctrl+j` key-binding sounds like something ibus-anthy preference menu sets if you ever set it so or it is the default. (I may have changed it on my system so I can't check for you ...) It is the default. That's after having working ibus-anthy and using anthy as input method. It only changs operational mode of anthy. You set it through anthy's preference menu. Switching between "日本語 - anthy" and "日本語 - japanese" sounds like switching between different ibus engines. That's usually SUPER-SPACE and its binding is set by ibus- setup for pure classic X system. That distinction is important. Ctrl+J for toggling between Hiragana and latin typing, while the active input method is Anthy, vs. Super+Space for switching to some other input source. -- Gunnar
Bug#1016395: linux-image-5.18.0-2-amd64: kernel 5.18: rtw_8821ce wireless fails to suspend/wake from suspend
On maandag 1 augustus 2022 02:07:02 CEST Linas Vepstas wrote: > I just attempted a hand-build of kernel 5.18.15 and it exhibits exactly the > same failure, the same stack traces. It's probably best to bring this to the attention of the upstream developers at linux-wirel...@vger.kernel.org When you do, please reference that thread in this bug report. signature.asc Description: This is a digitally signed message part.
Bug#1016480: ubuntu-dev-tools: can't run anymore ubuntu-build --batch --retry from cmdline due to wrong login() call in Python
Source: ubuntu-dev-tools Version: 0.190 tags: patch severity: important As said on irc: some changes you did on ubuntu-dev-tools broke launchpad login http://launchpadlibrarian.net/520965621/ubuntu-dev-tools_0.178_0.178ubuntu1.diff.gz in specific, reverting this change in jammy -self.login() +self.login_anonymously() works as expected and my ubuntu-build is back otherwise... ubuntu-build --batch --retry openimageio Traceback (most recent call last): File "/usr/bin/ubuntu-build", line 282, in main() File "/usr/bin/ubuntu-build", line 260, in main can_retry = options.retry and me.canUploadPackage(ubuntu_archive, AttributeError: 'NoneType' object has no attribute 'canUploadPackage' can you please have a look? I fixed by changing that line login_anonymously into login /usr/lib/python3/dist-packages/ubuntutools/lp/lpapicache.py line 108 G.
Bug#1016479: python3-pafy: [minor] refresh package information
Package: python3-pafy Version: 0.5.2-2.1 Severity: minor X-Debbugs-Cc: okgomdjgbm...@gmail.com Dear Maintainer, Some information of the package are outdated. The curent home page is "https://github.com/mps-youtube/pafy; youtube-dl should be a recomended dependency. updated feature list from the home page • Retreive metadata such as viewcount, duration, rating, author, thumbnail, keywords • Download video or audio at requested resolution / bitrate / format / filesize • Command line tool (ytdl) for downloading directly from the command line • Retrieve the URL to stream the video in a player such as vlc or mplayer • Works with age-restricted videos and non-embeddable videos • Small, standalone, single importable module file (pafy.py) • Select highest quality stream for download or streaming • Download video only (no audio) in m4v or webm format • Download audio only (no video) in ogg or m4a format • Retreive playlists and playlist metadata • Works with Python 2.6+ and 3.3+ • Optionally depends on youtube-dl (recommended; more stable)
Bug#1016478: gnome-passwordsafe: Sometimes freezing after entering data in field and directly pressing ctrl + s
Package: gnome-passwordsafe Version: 5.1-3 Severity: normal Random freezes after pressing ctrl + s having entered some info into a textfield. How to reproduce: (1) Enter anything into a login data field (2) Press ctrl + s (3) Go to (1) if it does not freeze (yet) Sometimes multiple fields have to be edited first I haven't found any relevant bug in Gnome's GitLab. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-3-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-passwordsafe depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gir1.2-handy-1 1.6.3-1 ii python3 3.10.5-3 ii python3-construct2.10.68+dfsg1-1 ii python3-dateutil 2.8.1-6 ii python3-gi 3.42.2-1 ii python3-pwquality1.4.4-1+b1 ii python3-pycryptodome 3.11.0+dfsg1-3 ii python3-pykeepass4.0.1-1 gnome-passwordsafe recommends no packages. gnome-passwordsafe suggests no packages. -- no debconf information
Bug#1016477: seafile-gui: Can't perform SSO Login: ERR_CERT_AUTHORITY_INVALID
Package: seafile-gui Version: 8.0.7+ds1-1 Severity: important Trying to use the Login with SSO function just leads to: This site can’t be reached The webpage at https://seafile.rlp.net/shib- login?shib_client_version=8.0.7_platform=linux_device_name=blurb_platform_version=_device_id=blurb might be temporarily down or it may have moved permanently to a new web address. ERR_CERT_AUTHORITY_INVALID ... -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages seafile-gui depends on: ii libc62.33-8 ii libgcc-s112.1.0-7 ii libglib2.0-0 2.72.3-1 ii libjansson4 2.14-2 ii libqt5core5a 5.15.4+dfsg-4 ii libqt5dbus5 5.15.4+dfsg-4 ii libqt5gui5 5.15.4+dfsg-4 ii libqt5network5 5.15.4+dfsg-4 ii libqt5webenginewidgets5 5.15.10+dfsg-4 ii libqt5widgets5 5.15.4+dfsg-4 ii libquazip5-1 0.9.1-2 ii libseafile0 8.0.7-1 ii libsearpc1 3.2.0-8+really3.2+git20220425.54145b0-1 ii libsqlite3-0 3.39.2-1 ii libstdc++6 12.1.0-7 ii seafile-daemon 8.0.7-1 seafile-gui recommends no packages. Versions of packages seafile-gui suggests: ii seafile-cli 8.0.7-1 -- no debconf information
Bug#1011284: popularity-contest: d/postinst: remove bash dependency, fix shellcheck
Hi!
Sorry, I had a brain-fart last time. Instead of trying to do something
weird, we can just use The Program That Generates Random Numbers:
shuf appeared in coreutils 6.1 (2006-08-19) and is available under busybox.
Attached is a much simpler patchset that does the same thing but just
uses shuf -n1 -r0-$top_of_mod_range.
Best,
наб
From d46fe12c6161f3329c933514b1ac89c3c5e783da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?=
Date: Thu, 19 May 2022 16:52:23 +0200
Subject: [PATCH v3 1/2] Use shuf instead of bash to generate random numbers in
d/postinst
X-Mutt-PGP: OS
---
debian/changelog | 6 ++
debian/postinst | 10 +++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 063d6a9..200cfb8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+popularity-contest (1.75) UNRELEASED; urgency=medium
+
+ * Use shuf instead of bash to generate random numbers in d/postinst
+
+ -- наб Thu, 19 May 2022 16:52:49 +0200
+
popularity-contest (1.74) unstable; urgency=medium
* debian/rules: add missing targets. Closes: #999319 Thanks Lucas Nussbaum
diff --git a/debian/postinst b/debian/postinst
index 1501d5c..6737fd9 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -36,14 +36,18 @@ generate_id() {
fi;
}
+random_number() {
+ shuf -i 0-"$(( $1 - 1 ))" -n1
+}
+
# Select a random day to submit on, to spread the load over time, unless it is already set.
select_random_day() {
-DAY=`bash -c 'echo $(($RANDOM % 7))'`
+ DAY=$(random_number 7)
}
generate_crond() {
- MIN=`bash -c 'echo $(($RANDOM % 60))'`
- HOUR=`bash -c 'echo $(($RANDOM % 24))'`
+ MIN=$(random_number 60)
+ HOUR=$(random_number 24)
FILE=/etc/cron.daily/popularity-contest
cat > /etc/cron.d/popularity-contest /dev/null 2>&1; then
-MY_HOSTID=`uuidgen -r | tr -d -`
+MY_HOSTID=$(uuidgen -r | tr -d -)
elif test -r /proc/sys/kernel/random/uuid; then
-MY_HOSTID=`tr -d - < /proc/sys/kernel/random/uuid`
+MY_HOSTID=$(tr -d - < /proc/sys/kernel/random/uuid)
else
-MY_HOSTID=`od -x -An -N16 /dev/urandom | tr -d ' '`
+MY_HOSTID=$(od -x -An -N16 /dev/urandom | tr -d ' ')
fi;
}
@@ -102,7 +102,7 @@ case "$1" in
# Workaround for bug #237874 triggered on hurd. The
# problem was fixed in version 1.15, 2004-03-20.
- $EMPTYID) generate_id;;
+ "$EMPTYID") generate_id;;
# Workaround for bug #240603 triggered by md5sums change
# of behaviour with stdin. version 1.17, 2004-04-12.
*-) MY_HOSTID="${MY_HOSTID% -}";;
--
2.30.2
signature.asc
Description: PGP signature
Bug#1016476: mod-wsgi: CVE-2022-2255: Trusted Proxy Headers Removing Bypass
Source: mod-wsgi Version: 4.9.0-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for mod-wsgi. CVE-2022-2255[0]: | Trusted Proxy Headers Removing Bypass 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-2022-2255 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2255 [1] https://github.com/GrahamDumpleton/mod_wsgi/commit/af3c0c2736bc0b0b01fa0f0aad3c904b7fa9c751 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1016475: tmux sessions do not persist through logout
Package: tmux Version: 3.3a-1 Severity: normal Under some starting conditions (eg. "starting from an xterm in Gnome"), the tmux server gets killed when the user logs off (or, more practically, gets logged off by the X server crashing). This damages one of tmux's strong points: keeping whatever is launched in it running no matter how unstable the terminal connection is. Steps to reproduce: * In a fresh sid installation, start Gnome under X11 (Wayland not tested). * Alt+F2, xterm * tmux * Ensure you recognize the screen again later on * Log out * Log in back again, open xterm again * tmux attach: "no sessions" -- the session was killed Note that this is sentitive to the precise way tmux is being launched; for example, if gnome-terminal were used, things would behave as normal. That indicates that there is something processes can do to protect themselves from getting killed (possibly with cgroups involved). I've originally reported this against systemd as https://bugs.debian.org/946645 assuming it's an error in `KillUserProcesses=no` (whose default has caused similar grief), but maintainers there insist it's not about that. The issue and discussion around it may have valuable material, also w/rt other things I've tested. Please enable tmux to persist in the rough desktop environment. If you think that it's not tmux's fault but tmux sessions should still persist, please reassign to where you think this should be fixed. Thanks chrysn PS. The issue appears to also exist in 3.4, which I've tested for unrelated reasons. -- 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.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tmux depends on: ii libc62.33-8 ii libevent-core-2.1-7 2.1.12-stable-5+b1 ii libtinfo66.3+20220423-2 ii libutempter0 1.2.1-2 tmux recommends no packages. tmux suggests no packages. -- no debconf information -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature
Bug#1016474: cryptsetup: The system installed on encrypted LVM (both root and swap partitions) freezes during massive writes
Control: tag -1 + moreinfo Hi, On Mon, 01 Aug 2022 at 12:27:39 +0200, Wojciech Zabołotny wrote: > That configuration generally works, but if a massive write operations > are performed, the syste, practically freezes. What makes you think that is a src:cryptsetup issue? Nothing in this package is involved once the device has been mapped. -- Guilhem. signature.asc Description: PGP signature
Bug#1005309: (no subject)
Dear mentors, A new version of the package is uploaded at mentors with the following changes compared with the previous version uploaded: * maintscript are simplified by using the cpsv tool from runit package * README (explain how to use the package) is updated * git VCS moved under my salsa namespace * git history of the old package is preserved I am looking for a sponsor for my package "runit-services": * Package name: runit-services Version : 0.5.0 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : CC0-1.0, BSD-3-Clause * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.0.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next Changes since the last upload: runit-services (0.5.0) experimental; urgency=medium . * Reintroduce the package (closes: #986656) * new maintainer * Overall package update: - 3.0 native format, use dh sequencer - build with dh-runit >= 2.14.0 - dep5 copyright - bump S-V to 4.6.1 - set Rules-requires-root to no - update package description * Enable the standard Salsa CI * Update/rewrite old services: - add apache2, remove apache; - update cron, chrony, postfix, xdm, dhclient; - rename dhcp to isc-dhcpd-server * Add new services: acpi-fakekey, anacron, atd, cups, dbus, elogind, gdomap (gnustep), haveged, lightdm, lircd, mariadb, mdadm, openntpd, preload, proftpd, rsyslog, sddm, slim, wicd * Remove obsolete services: - ssh (already included in openssh-server package); - portmap (no longer in Debian) - nfs-kernel-server, rpc.statd, squid, exim, gdm (further work is needed) * Update copyright for new runscripts * Sync runscript at postinstall, by using 'cpsv --sync' * Add triggers to watch systemd and sysv services so that installed runit services are kept in sync with systemd/sysv services * Stop running services on package removal * postrm: disable services when the package is removed; remove service and log dirs when purge is requested * Update README * Add lintian override for empty log directories Regards, -- Lorenzo Puliti
Bug#1001084: ITP: meli -- terminal mail client
0.7.2 draft 1 needs embedding 66 crates (25 missing, 39 ahead); builds in ~35 minutes; runs and seems to work from a brief test use. Main tasks now are to keep package up-to-date with upstream releases, and to package more of the crates currently embedded. Here's how you can help: As user running Debian, you can test this draft package: Either build it yourself from source or tell (by posting to this bugreport) if you prefer testing the binary packages I built - then I will share those. As developer (but no need to be official member of Debian!), you can join the Debian Rust team and help package these missing crates: https://salsa.debian.org/debian/meli/-/blob/debian/latest/debian/TODO - 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#910111: ITP: node-solid-server - Solid server on top of the file-system
Control: retitle -1 ITP: node-solid-server - Solid server on top of the file-system Control: owner -1 ! Solid is a concept and a collection of data specifications. Implementation of Solid are what should be packaged. I have for some time now made slow progress towards packaging the Expat-licensed Node.js implementation "solid-server": https://github.com/nodeSolidServer/node-solid-server Breakdown of dependencies are tracked here: https://wiki.debian.org/Javascript/Nodejs/Tasks/solid-server -- * 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#1016466: ImportError: /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.3: undefined symbol
Control: reassign -1 libspdlog1 Control: affects -1 gnuradio * Jan - PE0SAT : > ImportError: /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.3: > undefined symbol: > _ZN6spdlog5sinks15basic_file_sinkINS_7details10null_mutexEEC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb libspdlog1 has changed its ABI without bumping the SONAME. Probably related/same as #1015742.
Bug#910111: ITP: node-solid-community-server - open and modular implementation of Solid specs
Control: clone -1 -2 Control: retitle -2 ITP: node-solid-community-server - open and modular implementation of Solid specs Control: owner -2 ! Solid is a concept and a collection of data specifications. Implementation of Solid are what should be packaged. I have for some time now made slow progress towards packaging the Expat-licensed Node.js implementation "@solid/community-server": https://github.com/CommunitySolidServer/CommunitySolidServer/ Breakdown of dependencies are tracked here: https://wiki.debian.org/Javascript/Nodejs/Tasks/solid-community-server - 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#983146: 983146 RFS: bung/3.2.5-2 [ITP] -- backup next generation
Dear Bastian Thank you for your help The mentors upload has been fixed. I had accidentally uploaded to ftp.upload.debian.org instead of mentors.debian.net https://mentors.debian.net/package/bung/ QA information shows 'The uploader is not in the package's "Maintainer" or "Uploaders" fields'. I will fix that on the next upload The QA information shows lintian messages in the package and the source I will fix * The uploader is not in the package's "Maintainer" or "Uploaders" fields * The W messages * I extra-license-file * I typo-in-manual-page * I out-of-date-standards-version * P silent-on-rules-requiring-root * P uses-debhelper-compat-file * X debian-watch-does-not-check-gpg-signature * X upstream-metadata-file-is-missing I will consider fixing * X prefer-uscan-symlink I cannot fix * E source-is-missing Backup scripts next generation 3.2.x User Guide.htm is created by saving the .odt file in HTML format Best Charles
Bug#1016467: python3-configobj: places "private" files in top level of /usr/lib/python3/dist-packages
Control: forwarded -1 https://github.com/DiffSK/configobj/issues/32 Control: tag -1 + upstream Hi Julian (2022.08.01_06:26:09_+) > A package should not be placing "_version.py" or "validate.py" in the > top directory of this hierarchy. Instead, the layout should be > something like: Yeah, this has always been a bit annoying for validate.py. And yes, unacceptable for _version.py The good news is that upstream fixed it *years* ago. https://github.com/DiffSK/configobj/issues/32 https://github.com/DiffSK/configobj/issues/72 There is a separate package for validate now: https://pypi.org/project/validate/ And the new configobj release (when it comes) will have a shim to push users to it. The bad news is that they haven't cut a release in many years: https://github.com/DiffSK/configobj/issues/105 https://github.com/DiffSK/configobj/issues/160 https://github.com/DiffSK/configobj/issues/197 https://github.com/DiffSK/configobj/issues/204 https://github.com/DiffSK/configobj/issues/213 I'm a little hesitant to apply a package layout change without upstream cutting a release for PyPI etc. However, I see arch linux has done this. https://bugs.archlinux.org/task/68893 It did cause some breakage for other modules, until they added a compatibility shim: https://bugs.archlinux.org/task/69057 So, we could do the same thing. But it'll need some testing with reverse-deps. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1016251: python-lark: FTBFS: Handler for event 'source-read' threw an exception (exception: TableProcessor.__init__() missing 1 required positional argu
Control: reassign -1 src:sphinx-markdown-tables Control: found -1 0.0.15-3 Control: tags -1 + fixed-upstream Control: affects -1 src:python-lark thanks Dear Lucas, thanks for reporting this problem. It seems that the root cause of this FTBFS issue is a breaking change in python-markdown 3.4 which in turn requires changes in sphinx-markdown-tables which in turn is a build dependency of python-lark. More information on this issue can be found in the following sphinx-markdown-tables issue: https://github.com/ryanfox/sphinx-markdown-tables/issues/36 Best regards, Peter
Bug#1016470: RFP: muon-meson -- an implementation of the meson build system
Package: wnpp Severity: wishlist X-Debbugs-Cc: stephanlach...@debian.org * Package name: muon-meson Version : any Upstream Author : https://git.sr.ht/~lattis/ * URL : https://muon.build/ * License : GPL v3 Programming Lang: C99 Description : an implementation of the meson build system muon is an implementation of the meson build system in c99 with minimal dependencies. It is interesting because it has some features that meson does not: - muon analyze - a static analyzer for meson.build files. Capable of doing type inference, checking unused variables, undeclared variables, etc. - muon fmt_unstable - a meson.build code formatter - An interactive stepping debugger with the dbg() function. muon is close to feature-complete with the core of meson for C and C++ (but still in early development IMHO). I think it should be fairly easy to package due to using meson and the minimal dependencies, but I won't put the time into packaging it (yet).
Bug#1016469: qemu-web-desktop: please add support for riscv64
Source: qemu-web-desktop
Version: 22.04.22-1+ds1-1
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear qemu-web-desktop Maintainer,
The package has built on my real riscv64 hardware successfully with
change attached, so could you please add support for riscv64 arch as
a build target in next upload? thanks.
--
Regards,
--
Bo YU
diff -Nru qemu-web-desktop-22.04.22-1+ds1/debian/control qemu-web-desktop-22.04.22-1+ds1/debian/control
--- qemu-web-desktop-22.04.22-1+ds1/debian/control 2022-05-02 22:53:54.0 +0800
+++ qemu-web-desktop-22.04.22-1+ds1/debian/control 2022-05-02 22:55:59.0 +0800
@@ -10,7 +10,7 @@
Homepage: https://gitlab.com/soleil-data-treatment/soleil-software-projects/remote-desktop
Package: qemu-web-desktop
-Architecture: amd64 ppc64el arm64
+Architecture: amd64 ppc64el arm64 riscv64
Depends: ${shlibs:Depends}, ${misc:Depends},
apache2,
libapache2-mod-perl2,
signature.asc
Description: PGP signature
Bug#1016468: android-platform-tools: do not override dwz
Source: android-platform-tools Version: 29.0.6-20 tags: patch Hello, I added a better patch instead of ignoring dwz call. Its about exporting gdwarf-4, until new dwz starts understanding dwarf-5 format (so we should in the future re-evaluate this cflag and remove it). Also, it would be nice to disable lto, I don't think it makes any sense in android toolchain. trivial patch is: diff -Nru android-platform-tools-29.0.6/debian/rules android-platform-tools-29.0.6/debian/rules --- android-platform-tools-29.0.6/debian/rules 2022-07-28 16:01:55.0 + +++ android-platform-tools-29.0.6/debian/rules 2022-08-01 07:31:57.0 + @@ -4,10 +4,10 @@ include /usr/share/dpkg/pkg-info.mk ## Security Hardening -export DEB_BUILD_MAINT_OPTIONS = hardening=+all +export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto # https://android.googlesource.com/platform/build/soong/+/refs/tags/platform-tools-29.0.6/cc/config/global.go#121 -export DEB_CFLAGS_MAINT_APPEND = -fPIC -export DEB_CXXFLAGS_MAINT_APPEND = -fPIC +export DEB_CFLAGS_MAINT_APPEND = -fPIC -gdwarf-4 +export DEB_CXXFLAGS_MAINT_APPEND = -fPIC -gdwarf-4 export DEB_LDFLAGS_MAINT_APPEND = -fPIC export DEB_CPPFLAGS_MAINT_APPEND = -DNDEBUG -UDEBUG \ -fmessage-length=0 \ @@ -205,6 +205,3 @@ dh_gencontrol -pandroid-sdk-libsparse-utils -- -v1:$(DEB_VERSION) dh_gencontrol -pfastboot -- -v1:$(DEB_VERSION) dh_gencontrol -pmkbootimg -- -v1:$(DEB_VERSION) - -override_dh_dwz: - dh_dwz || true G.
