Bug#1073042: RFP: gtkman -- A simple GTK+3 manual page viewer
Package: gtkman Severity: wishlist A simple GTK+3 manual page viewer This seems like a very nifty and simple GUI for manpages to port from Salix (where it originates from). Installing from source was not a problem on Debian 12. Please consider adding this to unstable. Thank you. Upstream: https://github.com/gapan/gtkman
Bug#1073041: [Pkg-nagios-devel] Bug#1073041: icinga2: Ignore 1 test failure on loong64
Control: tags -1 pending This is fixed in git. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1073041: icinga2: Ignore 1 test failure on loong64
Source: icinga2 Version: 2.14.2-1 Severity: normal Tags: ftbfs patch User: debian-loonga...@lists.debian.org Usertags: loong64 Dear maintainers, Compiling the icinga2 failed for loong64 in the Debian Package Auto-Building environment. The error log is as follows, ``` 99% tests passed, 1 tests failed out of 164 Total Test time (real) = 11.12 sec The following tests FAILED: 152 - base-methods_pluginnotificationtask/truncate_long_output (Failed) Errors while running CTest make[2]: *** [Makefile:94: test] Error 8 .. ``` The Full log can be found at https://buildd.debian.org/status/logs.php?pkg=icinga2=2.14.2-1=loong64. Refer for other architectures, please ignore 1 test failure on loong64. Please consider the patch I attached. Your opinions are welcome. Thanks, Dandan Zhang diff --git a/debian/rules b/debian/rules index a52a8e4..84a5798 100755 --- a/debian/rules +++ b/debian/rules @@ -39,7 +39,7 @@ override_dh_auto_configure: -DUSE_SYSTEMD=ON override_dh_auto_test: -ifneq (,$(filter $(DEB_BUILD_ARCH),i386 mips64el ppc64el powerpc)) +ifneq (,$(filter $(DEB_BUILD_ARCH),i386 mips64el ppc64el powerpc loong64)) dh_auto_test || echo "Ignoring test failures" else dh_auto_test
Bug#1072857: dput: Fails when processing ssh_config_options value: AttributeError: 'list' object has no attribute 'split'
Control: clone -1 -2
Control: retitle -2 dput: Fails when processing ssh_config_options value:
AttributeError: 'list' object has no attribute 'split'
Control: tags -2 + confirmed
Control: severity -2 severe
On 11-Jun-2024, Christoph Berg wrote:
> Uploading to ssh-upload [DELAYED/0-day] (via scp to ssh.upload.debian.org):
> Traceback (most recent call last):
> File "/usr/bin/dput", line 33, in
> sys.exit(load_entry_point('dput==1.2', 'console_scripts',
> 'execute-dput')())
>
> ^^
> File "/usr/share/dput/dput/dput.py", line 1548, in main
> upload_files(
> File "/usr/share/dput/dput/dput.py", line 1267, in upload_files
> upload_func(
> File "/usr/share/dput/dput/dput.py", line 1152, in
> upload_files_via_method_scp
> line.strip() for line in ssh_config_options.split("\n"))
>
> AttributeError: 'list' object has no attribute 'split'
This is a bug in recently refactored code, thank you for finding it. I will
correct that and get you to confirm the fix.
--
\ “All progress has resulted from people who took unpopular |
`\ positions.” —Adlai Stevenson |
_o__) |
Ben Finney
signature.asc
Description: PGP signature
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti: > > Source: dhcpcd > Version: 1:10.0.8-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of your package because it > was tested for glibc. I noticed that it regularly fails. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. This is a non-bug. This package has only one test and it requires an isolation machine. amd64 is the only architecture that provides it. Other architectures will always be marked flakey. Additionally, looking at the tracker for this package, amd64 always passes. Martin-Éric
Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language
Hi Submitter and all, It has been almost a year since the last activity on this Request For Sponsorship (RFS). Is there still interest in the packaging of zig by the submitter or others, or can this RFS be closed and the Intent To Package (ITP) be returned (retitled) to Request For Package (RFP) status? Regards Phil -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1073039: transition: libqalculate
Package: release.debian.org Severity: normal X-Debbugs-Cc: libqalcul...@packages.debian.org, j...@debian.org Control: affects -1 + src:libqalculate User: release.debian@packages.debian.org Usertags: transition Hello release team, I'm requesting a slot for the libqalculate 5.x transition. This upstream major release bumps the SONAME from 22 to 23. I've rebuilt all reverse dependencies in a chroot locally. These all work fine: - cantor 4:22.12.3-1.1 - plasma-workspace 4:5.27.11.1-1 - step 4:22.12.3-1 qalculate-gtk (from the same upstream) needs to be updated to the latest v5.1.0 to build correctly. I can upload this to experimental as well if it's helpful, or upload the new libqalculate + qalculate-gtk to unstable together - let me know what you prefer. Ben file: title = "libqalculate"; is_affected = .depends ~ "libqalculate22t64" | .depends ~ "libqalculate23"; is_good = .depends ~ "libqalculate23"; is_bad = .depends ~ "libqalculate22t64"; (This is my first library transition, please let me know if I've missed anything!) Best, James
Bug#1073038: po4a: Fails due to undefined subroutine Locale::Po4a::Pod::dgettext
Package: po4a Version: 0.70 Severity: serious Hi! When building dpkg, it now fails with something like this: ,--- Making check in man make[1]: Entering directory '/dpkg/man' /usr/bin/po4a --previous --srcdir . --destdir . --no-backups --porefs file --msgmerge-opt=--add-location=file --package-name dpkg-man --package-version 1.22.6-80-gec07 --copyright-holder "Dpkg Developers" --msgid-bugs-address debian-d...@lists.debian.org ./po/po4a.cfg Undefined subroutine ::Po4a::Pod::dgettext called at /usr/share/perl5/Locale/Po4a/Pod.pm line 94, <$fh> line 21. make[1]: *** [Makefile:902: man.stamp] Error 255 make[1]: Leaving directory '/dpkg/man' `--- It seems the module is missing some import. Thanks, Guillem
Bug#1067431: brutespray: Update the package to version > 2
Hi (cc pkg-security-tools), a new release of brutespray just went live, 2.2.3. Version 2 is a rewrite in Go so we have to manage go dependencies. I made a list of dependencies needed to be packaged so brutespray v2 can be uploaded - see below. This is kinda of call for help for those interested in brutespray :-) In Debian! -- github.com/emersion/go-imap v1.2.1 `--> golang-github-emersion-go-imap-dev 1.2.1-1 github.com/hirochachacha/go-smb2 v1.1.0 `--> golang-github-hirochachacha-go-smb2-dev 1.1.0-2 github.com/jlaffaye/ftp v0.2.0 `--> golang-github-jlaffaye-ftp-dev 0.2.0-1 github.com/lib/pq v1.10.9 `--> golang-github-lib-pq-dev 1.10.9-2 github.com/mitchellh/go-vnc v0.0.0-20150629162542-723ed9867aed `--> golang-github-mitchellh-go-vnc-dev 0.0~git20150629.723ed98-2 Might require newer version --- github.com/go-sql-driver/mysql v1.8.1 `--> golang-github-go-sql-driver-mysql-dev 1.7.1-2 github.com/gosnmp/gosnmp v1.37.0 `--> golang-github-soniah-gosnmp-dev 1.35.0-1 go.mongodb.org/mongo-driver v1.15.0 `--> golang-mongodb-mongo-driver-dev 1.12.1+ds1-2 golang.org/x/crypto v0.24.0 `--> golang-golang-x-crypto-dev 1:0.23.0-1 New packages github.com/knadh/go-pop3 v1.0.0 github.com/multiplay/go-ts3 v1.2.0 github.com/pterm/pterm v0.12.79 github.com/sijms/go-ora/v2 v2.8.19 github.com/tomatome/grdp v0.1.0 github.com/wenerme/astgo v0.0.0-20230926205800-1b5bc38663fa gosrc.io/xmpp v0.5.1 Cheers, Charles signature.asc Description: PGP signature
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Xiyue Deng writes: > I made another change to dh-elpa enabling better back trace for > buttercup tests, so here is the refreshed patchset. TIA! Friendly ping for comments from David :) -- Xiyue Deng signature.asc Description: PGP signature
Bug#1073037: [RFP]: deltachat-desktop -- A chat client, uses any email server as a backend
Package: deltachat-desktop Severity: RFP X-Debbugs-CC: debian-on-mob...@lists.debian.org Upstream Author : Deltachat contributors (>10 people) URL : https://delta.chat/ License : GPLv3 Programming Lang: C++ Description : chat messaging over email (IMAP), E2EE *backend: any standard-compliant mail server *frontend: dedicated Deltachat clients (packaging requested) or standard IMAP email clients (inferior). Deltachat clients have normal chat interfaces (including group chat). There are GUI clients for all common platforms: desktop OSs (Linux, macOS, and Windows), and mobile OSs (Mobian/mobile Linux, Android, and iOS). The clients are all GPLv3, and all depend on a common client core, deltachat-core-rust (Mozilla Public License v2), which has a command-line interface. (https://github.com/deltachat) The deltachat-desktop client would probably fit best in Debian, and its packaging is requested. The mobile client made for UBports is called Deltatouch. It is third-party, GPLv3. It would make a good addition to Mobian, if anyone is willing to package it (https://open-store.io/app/deltatouch.lotharketterer). A web client is planned. Autocrypt and SecureJoin are used for end-to-end encryption (https://delta.chat/en/2024-03-25-crypto-analysis-securejoin). The server(s) see(s) only the addresses of sender and recipient, and message timings and sizes; other metadata is encrypted. If a recipient does not have a Deltachat client, they can use a regular email client or webmail client to reply, though they will have inferior formatting (and usually transport-only encryption; the client UI warns when encryption is unavailable). It is possible to use multiple pseudoanonymous profiles in one client, and the same profile in multiple clients on multiple devices. Database encryption is in beta on mobile, and does not yet exist on desktop. Perfect Forward Secrecy is not (yet) implemented. Messages may contain an autodeletion-time request. Clients can be backed up to and restored from a backup file (including keys and contacts), though there's no built-in way to deniably encrypt the backup file (hiding it locally or on a server). (source: https://delta.chat/en/help) As a backend, any email server works, as long as it uses IMAP. Email servers that require a server-specific protocol to talk to the server, like Tutanota and Protonmail, therefore do not work. See also https://www.ubuntubuzz.com/2021/09/delta-chat-overview-and-installation.html and https://pocketnow.com/10-ways-delta-chat-is-better-than-whatsapp-signal-and-telegram/ Upstream says getting stable clients packaged natively in Linux repositories is their current goal, and they have Deltachat running on Debian (search "repositories" in https://delta.chat/en/help). They probably need help or advice on packaging dependencies. The list of dependencies is here: https://aur.archlinux.org/packages/deltachat-desktop Deltachat seems pretty stable; it's been around since 2017. Contributors include a roughly 12-person team at Merlinux (Freiburg, Germany), with assorted public funding, private donations, and third-party developers. (https://www.vodafone.de/featured/apps/delta-chat-app-funktionen-e-mail-test/) I, the RFP submitter, am not in any way affiliated with the project. I've tried to be accurate, but I'm working from public info only, and the devs would know better than I do about everything.
Bug#1068724: RFS: gensync/2.0.5-1 [ITP] -- a library for efficient synchronization of data over a network.
Hi, Thank you for your interest in Debian. Before I commit further time to this Request For Sponsorship (RFS) submission. Could you elaborate on where version 2.0.5 comes from? The linked git repository[1] 'README.md' states version '2.0.4'. If you do some digging into the git repository tags[2], the latest version is '1.0.4'. If you look into the branch 'colosseum', which looks like it has the/a codebase in it, there is no version in 'README.md' or elsewhere. [1] https://github.com/nislab/gensync [2] https://github.com/nislab/gensync/tags Regards Phil -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
Control: tags -1 + patch On 09-Jun-2024, Martin-Éric Racine wrote: > Incorrect delayed argument: ValueError: delayed days value must be a decimal > integer: At https://salsa.debian.org/debian/dput/-/merge_requests/14> is a merge request proposing to fix this bug. Can you try the resulting Dput package, and confirm whether it corrects the behaviour in your case? -- \ “An idea isn't responsible for the people who believe in it.” | `\ —Donald Robert Perry Marquis | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1072774: Upstream bug files
Upstream bug filed here - https://github.com/openzfs/zfs/issues/16261 John
Bug#1072993: please add OnlyShowIn=GNOME;Unity; in com.mattjakeman.ExtensionManager.desktop
Control: forwarded -1 https://github.com/mjakeman/extension-manager/issues/668 Hi Jeremy, I had reported it to upstream and also create PR: https://github.com/mjakeman/extension-manager/pull/669 在 2024/6/11 23:55, Jeremy Bícha 写道: On Tue, Jun 11, 2024 at 8:54 AM xiao sheng wen wrote: The gnome-shell-extension-manager is only use in GNOME, so add field: OnlyShowIn=GNOME;Unity; While this could be done as a Debian specific patch, this could be useful to people using other distros too. Could you report this request to the upstream project at https://github.com/mjakeman/extension-manager/issues ? Also, you could try to submit your own git merge request there for this if you want. Note that Unity does not use GNOME Shell at all so you don't want Unity in the OnlyShowIn field. Yes, Unity is not need here. Thank you, Jeremy Bícha Thank you, -- 肖盛文 xiao sheng wen https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com Debian salsa: https://salsa.debian.org/atzlinux-guest GnuPG Public Key: 0x00186602339240CB OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072774: Also fails on upstream
I rebuilt the Debian package using the latest upstream (https://github.com/openzfs/zfs), and saw the same error. Log is (hopefully attached). Will raise the issue there as well. Thanks, John typescript Description: Binary data
Bug#1073036: rsyslog.conf.5: some remarks and editorial changes for this man page
Package: rsyslog Version: 8.2404.0-2 Severity: minor Tags: patch Dear Maintainer, * What led up to the situation? Checking for defects with [test-]groff -mandoc -t -K utf8 -ww -b -z < "man page" [test-groff is a script in the repository for "groff"] * What was the outcome of this action? an.tmac::93: warning: cannot nest .TP or .TQ inside .TP; supply a tag * What outcome did you expect instead? No output (warnings). -.- Remarks and a patch are in the attachments. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages rsyslog depends on: ii libc6 2.38-12 ii libestr0 0.1.11-1+b1 ii libfastjson4 1.2304.0-1+b1 ii liblognorm5 2.0.6-4+b1 ii libsystemd0 256~rc4-1 ii libuuid1 2.40.1-8 ii libzstd1 1.5.5+dfsg2-2 ii zlib1g1:1.3.dfsg+really1.3.1-1 Versions of packages rsyslog recommends: ii logrotate 3.21.0-2 Versions of packages rsyslog suggests: ii rsyslog-doc 8.2404.0+dfsg-1 pn rsyslog-gssapi pn rsyslog-mongodb pn rsyslog-mysql | rsyslog-pgsql pn rsyslog-openssl | rsyslog-gnutls pn rsyslog-relp -- no debconf information Any program (person), that produces man pages, should check its content for defects by using groff -mandoc -t -ww -b -z [ -K utf8 | k ] The same goes for man pages that are used as an input. For a style guide use mandoc -T lint -.- So any generator should check its products with the above mentioned 'groff' and additionally with 'nroff ...'. This is just a simple quality control measure. The generator may have to be corrected to get a better man page, the source file may, and any additional file may. -.- The difference between the formatted outputs can be seen with: nroff -mandoc > nroff -mandoc > diff -u and for groff, using "printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - " instead of "nroff -mandoc" Add the option "-t", if the file contains a table. Read the output of "diff -u" with "less -R" or similar. -.-. If "man" (man-db) is used to check the manual for warnings, the following must be set: The option "-warnings=w" The environmental variable: export MAN_KEEP_STDERR=yes (or any non-empty value) or (produce only warnings): export MANROFFOPT="-ww -z" export MAN_KEEP_STDERR=yes (or any non-empty value) -.-. Output from "mandoc -T lint rsyslog.conf.5": (possibly shortened list) mandoc: rsyslog.conf.5:31:96: STYLE: input text line longer than 80 bytes: manpage. Rsyslog.con... mandoc: rsyslog.conf.5:92:2: WARNING: line scope broken: TP breaks TP mandoc: rsyslog.conf.5:134:85: STYLE: input text line longer than 80 bytes: Rsyslog.conf should ... mandoc: rsyslog.conf.5:138:94: STYLE: input text line longer than 80 bytes: Global directives se... mandoc: rsyslog.conf.5:139:85: STYLE: input text line longer than 80 bytes: message queue ($Main... mandoc: rsyslog.conf.5:140:85: STYLE: input text line longer than 80 bytes: All global directive... mandoc: rsyslog.conf.5:141:95: STYLE: input text line longer than 80 bytes: a dollar-sign. The c... mandoc: rsyslog.conf.5:146:91: STYLE: input text line longer than 80 bytes: Templates allow you ... mandoc: rsyslog.conf.5:147:90: STYLE: input text line longer than 80 bytes: file name generation... mandoc: rsyslog.conf.5:152:84: STYLE: input text line longer than 80 bytes: Output channels prov... mandoc: rsyslog.conf.5:153:90: STYLE: input text line longer than 80 bytes: They have to be defi... mandoc: rsyslog.conf.5:158:83: STYLE: input text line longer than 80 bytes: Every rule line cons... mandoc: rsyslog.conf.5:159:84: STYLE: input text line longer than 80 bytes: two fields are separ... mandoc: rsyslog.conf.5:181:81: STYLE: input text line longer than 80 bytes: and should not be us... mandoc: rsyslog.conf.5:234:93: STYLE: input text line longer than 80 bytes: The action field of ... mandoc: rsyslog.conf.5:235:90: STYLE: input text line longer than 80 bytes: is written to a kind... mandoc: rsyslog.conf.5:239:93: STYLE: input text line longer than 80 bytes: Typically messages a... mandoc: rsyslog.conf.5:244:113: STYLE: input text line longer than 80 bytes: *.* /var/log/tra... mandoc: rsyslog.conf.5:265:92: STYLE: input text line longer than 80 bytes: This version of rsys... mandoc: rsyslog.conf.5:266:90: STYLE: input text line longer than 80 bytes: named pipe can be us... mandoc: rsyslog.conf.5:267:93: STYLE: input text line longer than 80 bytes: to the name of the f... mandoc: rsyslog.conf.5:271:89: STYLE: input text line longer than 80 bytes: If the file you
Bug#1073035: alsamixer.1: some remarks and editorial changes for this man page
Package: alsa-utils Version: 1.2.11-1 Severity: minor Tags: patch Dear Maintainer, * What led up to the situation? Checking for defects with [test-]groff -mandoc -t -K utf8 -ww -b -z < "man page" [test-groff is a script in the repository for "groff"] * What was the outcome of this action? troff: backtrace: file '':79 troff::79: warning: trailing space in the line troff: backtrace: file '':86 troff::86: warning: trailing space in the line troff: backtrace: file '':142 troff::142: warning: trailing space in the line troff: backtrace: file '':296 troff::296: warning: trailing space in the line troff: backtrace: file '':392 troff::392: warning: trailing space in the line * What outcome did you expect instead? No output (warnings). -.- Remarks and a patch are in the attachments. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages alsa-utils depends on: ii kmod 32+20240327-1 ii libasound2t64 1.2.11-1+b1 ii libatopology2t64 1.2.11-1+b1 ii libc6 2.38-12 ii libfftw3-single3 3.3.10-1+b2 ii libncursesw6 6.5-2 ii libsamplerate00.2.2-4+b1 ii libtinfo6 6.5-2 alsa-utils recommends no packages. Versions of packages alsa-utils suggests: pn dialog -- no debconf information Any program (person), that produces man pages, should check its content for defects by using groff -mandoc -t -ww -b -z [ -K utf8 | k ] The same goes for man pages that are used as an input. For a style guide use mandoc -T lint -.- So any generator should check its products with the above mentioned 'groff' and additionally with 'nroff ...'. This is just a simple quality control measure. The generator may have to be corrected to get a better man page, the source file may, and any additional file may. Common errors: Not removing trailing spaces (in in- and output). The reason for these trailing spaces should be found and eliminated. Not beginning each input sentence (that is not confined to a markup) in the first column. Line length should thus be reduced. -.- The difference between the formatted outputs can be seen with: nroff -mandoc > nroff -mandoc > diff -u and for groff, using "printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - " instead of "nroff -mandoc" Add the option "-t", if the file contains a table. Read the output of "diff -u" with "less -R" or similar. -.-. If "man" (man-db) is used to check the manual for warnings, the following must be set: The option "-warnings=w" The environmental variable: export MAN_KEEP_STDERR=yes (or any non-empty value) or (produce only warnings): export MANROFFOPT="-ww -z" export MAN_KEEP_STDERR=yes (or any non-empty value) -.-. Output from "mandoc -T lint alsamixer.1": (possibly shortened list) mandoc: alsamixer.1:29:81: STYLE: input text line longer than 80 bytes: Select the starting ... mandoc: alsamixer.1:79:67: STYLE: whitespace at end of input line mandoc: alsamixer.1:86:85: STYLE: whitespace at end of input line mandoc: alsamixer.1:142:70: STYLE: whitespace at end of input line mandoc: alsamixer.1:192:130: STYLE: input text line longer than 80 bytes: Valid values for \fI... mandoc: alsamixer.1:194:91: STYLE: input text line longer than 80 bytes: Valid values for \fI... mandoc: alsamixer.1:207:104: STYLE: input text line longer than 80 bytes: If enabled (\fI1\fP)... mandoc: alsamixer.1:296:57: STYLE: whitespace at end of input line -.-. Remove space characters at the end of lines. Use "git apply ... --whitespace=fix" to fix extra space issues, or use global configuration "core.whitespace". 79:The default view mode is the playback view. You can change it via 86:\fBalsamixer\fP recognizes the following keyboard commands to control the soundcard. 142:[\fIZ\fP | \fIX\fP | \fIC\fP ] -- turn DOWN [ left | both | right ] 296:Increase volume of current control by \fI\fP percent. -.-. Change two HYPHEN-MINUSES (code 0x2D) to an em-dash (\(em), if one is intended. An en-dash is usually surrounded by a space, while an em-dash is used without spaces. "man" (1 byte characters in input) transforms an en-dash (\(en) to one HYPHEN-MINUS, and an em-dash to two HYPHEN-MINUSES without considering the space around it. If "--" are two single "-" (end of options) then use "\-\-". alsamixer.1:140:[\fIQ\fP | \fIW\fP | \fIE\fP ] -- turn UP [ left | both | right ] alsamixer.1:142:[\fIZ\fP | \fIX\fP | \fIC\fP ] -- turn DOWN [ left | both | right ] -.-. Mark a full stop (.) and the exclamation mark (!) with "\&", if it does not mean an end of a sentence. This is a preventive action, the paragraph could be
Bug#1073034: Some hyperlinks are including trailing comma and result in 404 if followed.
Package: lintian Version: 2.117.0 Severity: normal Dear Maintainer, N: N: The listed file or maintainer script appears to reference the build path N: used to build the package as specified in the Build-Path field of the N: .buildinfo file. N: N: This is likely to cause the package to be unreproducible, but it may also N: indicate that the package will not work correctly outside of the N: maintainer's own system. N: N: Please note that this tag will not appear unless the .buildinfo file N: contains a Build-Path field. That field is optional. You may have to set N: DEB_BUILD_OPTIONS=buildinfo=+path or use N: --buildinfo-option=--always-include-path with dpkg-buildpackage when N: building. N: N: Please refer to https://reproducible-builds.org/, N: https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles, and the N: dpkg-genbuildinfo(1) manual page for details. N: N: Visibility: info N: Show-Always: no N: Check: files/contents N: N: Issue: In 'tilix', links here are including the trailing ',' and result in 404 if you right click on one of the links and then click on 'Open Link'. Regards Phil -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1073033: neomutt removes gpg.rc and smime.rc breaking cryptographic functions for users relying on them
Package: neomutt
Version: 20231103+dfsg1-1+b2
Severity: normal
X-Debbugs-Cc: charlesmel...@riseup.net
Dear Maintainer,
This is a bug to prevent 20240425+dfsg-1 migrating to testing.
20240425+dfsg-2 was uploaded today containing d/NEWS and d/README.Debian
explaining the situation to neomutt users.
-- Package-specific info:
NeoMutt 20231103
Copyright (C) 1996-2022 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 6.7.12-amd64 (x86_64)
ncurses: ncurses 6.5.20240427 (compiled with 6.4.20240113)
libidn2: 2.3.7 (compiled with 2.3.7)
GPGME: 1.18.0
GnuTLS: 3.8.3
libnotmuch: 5.6.0
PCRE2: 10.42 2022-12-11
storage: tokyocabinet, lmdb
compression: lz4, zlib, zstd
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
{--libdir=${prefix}/lib/x86_64-linux-gnu} --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --mandir=/usr/share/man
--libexecdir=/usr/libexec --with-mailpath=/var/mail --autocrypt --full-doc
--gnutls --gpgme --gsasl --gss --lmdb --lua --lz4 --notmuch --mixmaster --pcre2
--sqlite --tokyocabinet --zlib --zstd
Compilation CFLAGS: -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/build/reproducible-path/neomutt-20231103+dfsg1=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -fno-delete-null-pointer-checks
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED
-I/usr/include/lua5.4 -I/usr/include -I/usr/include -I/usr/include
-DNCURSES_WIDECHAR -I/usr/include -I/usr/include/p11-kit-1 -I/usr/include
-isystem /usr/include/mit-krb5 -O2
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+autocrypt +fcntl -flock -fmemopen +futimens +getaddrinfo +gnutls +gpgme
+gsasl +gss +hcache -homespool +idn +inotify -locales_hack +lua +mixmaster
+nls +notmuch -openssl +pcre2 +pgp -sasl +smime +sqlite +sun_attachment
+truecolor
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages neomutt depends on:
ii libc62.38-12
ii libgnutls30t64 3.8.5-4
ii libgpgme11t641.18.0-4.1+b1
ii libgsasl18 2.2.1-1+b1
ii libgssapi-krb5-2 1.20.1-6+b1
ii libidn2-02.3.7-2
ii liblmdb0 0.9.31-1+b1
ii liblua5.4-0 5.4.6-3+b1
ii liblz4-1 1.9.4-2
ii libncursesw6 6.5-2
ii libnotmuch5t64 0.38.3-1+b1
ii libpcre2-8-0 10.42-4+b1
ii libsqlite3-0 3.46.0-1
ii libtinfo66.5-2
ii libtokyocabinet9t64 1.4.48-15.1
ii libzstd1 1.5.5+dfsg2-2
ii sensible-utils 0.0.22
ii zlib1g 1:1.3.dfsg+really1.3.1-1
Versions of packages neomutt recommends:
ii locales 2.38-12
ii mailcap 3.72
Versions of packages neomutt suggests:
ii aspell0.60.8.1-1+b1
ii ca-certificates 20240203
ii gnupg 2.2.43-7
ii ispell3.4.06-1
ii msmtp-mta [mail-transport-agent] 1.8.24-1+b2
ii openssl 3.2.1-3
pn urlview
Versions of packages neomutt is related to:
ii neomutt 20231103+dfsg1-1+b2
-- no debconf information
Bug#1064876: RFS: openjph/0.10.3-1 [Team] -- HTJ2K image compression/decompression library (documentation files)
Hi, Thank you for giving your time and updating this package for Debian. A quick review of the package indicates the below that may require work. * Spelling error at line 802 of file: 'src/core/codestream/ojph_codestream_local.cpp'. 'indivdual' should be 'individual'. Can be simply patched locally and reported upstream if necessary. * .devcontainer/devcontainer.json is 'MIT' license not 'BSD-2'. * In 'debian/copyright'. License is 'BSD-2-clause' not 'BSD-2'. - See: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Regards Phil -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit : > On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote: > > During a rebuild of all packages in unstable, your package failed to build: > … > > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed: > > 0) > > Non-zero exit status: 255 > > Parse errors: No plan found in TAP output > > On the face of it this looks to be a result of po4a changes. I'm not > sure if the root cause is the same as #1072643 yet; further > investigation is required. These two bugs are unrelated. The failure on goobox (#1072643) is linked to the fact that po4a is now much less forgiving about charsets. It now supposes UTF encoding unless specified otherwise. Before, it was relying on the default Perl behavior, which tries to do "the right thing" even if the user does something wrong. This is why previously, the ISO-8859-15 files were accepted without additional configuration while now po4a reports that it's not UTF. Fixing this simply requires to specify the encoding using the -M flag. The question may be about why we changed this. The answer is that the default Perl behavior was not always right leading to messy failures (in particular with gettext which makes things even more complex when msgids contain non-ascii chars), while the new behavior gives us more control. I'll try to improve the error messages to make things more explicit. On its side, the failure on ikiwiki (#1072760) is related to the fact that ikiwiki is using a function that I consider as a private API in po4a and recently changed. The fix is simply to update the the calls of that API in ikiwiki's code, and the update is trivial (simply give the filename twice to use it as refname). Sorry about the inconvenience, but please people, do not CC both bugs as they are unrelated. Sorry again about the inconvenience, Mt signature.asc Description: This is a digitally signed message part
Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output
Le lundi 10 juin 2024 à 10:21 +0100, Jonathan Dowland a écrit :
> On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> …
> > t/po.t (Wstat: 65280 (exited 255) Tests: 38 Failed:
> > 0)
> > Non-zero exit status: 255
> > Parse errors: No plan found in TAP output
>
> On the face of it this looks to be a result of po4a changes. I'm not
> sure if the root cause is the same as #1072643 yet; further
> investigation is required.
>
I think that the relevant part of the logs is here:
---
Cannot write to a file without refname at
/usr/share/perl5/Locale/Po4a/TransTractor.pm line 444.
Locale::Po4a::TransTractor::read(Locale::Po4a::Text=HASH(0x559ec7d9f248),
"/tmp/ikiwiki-test-po.nKtVlhHS3_/src/index.mdwn") called at /build/ikiwiki-
3.20200202.4/blib/lib/IkiWiki/Plu
gin/po.pm line 907
IkiWiki::Plugin::po::refreshpot("/tmp/ikiwiki-test-
po.nKtVlhHS3_/src/index.mdwn") called at t/po.t line 225
main::refresh_n_scan("index.mdwn", "translatable.mdwn",
"nontranslatable.mdwn") called at t/po.t line 233
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 38.
t/po.t .
-
That's really astonishing for me. I could not imagine that this function is
called by someone else than po4a itself...
This bug is related to https://github.com/mquinson/po4a/issues/504 which
requires a documentation improvement in po4a, but the bug to fix is in ikiwiki.
You should update your calls to this function to follow the prototype
modification. I'm sorry about that, but I fail to see another option.
Sorry for the inconvenience,
Mt
signature.asc
Description: This is a digitally signed message part
Bug#1073032: RM: libinnodb -- RoQA; unmaintained upstream and in Debian; rc-buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: b...@debian.org, libinn...@packages.debian.org Control: affects -1 src:libinnodb libinnodb's only two uploads were in 2010. It is rc-buggy since at least 2020 and thus missed oldstable and stable. Upstream has vanished too. Please remove libinnodb from unstable. Chris
Bug#981767:
hi,
https://wiki.debian.org/DpkgConffileHandling suggests that that should be doable
using dpkg conffile checksums, e.g.
% dpkg-query -W -f='${Conffiles}' apt-cacher-ng
/etc/apt-cacher-ng/acng.conf 87897bc5b2bbb83614d1ef5e57b57abc
/etc/apt-cacher-ng/security.conf e6cc84b92032492d92d2f723a6a0a63d
/etc/avahi/services/apt-cacher-ng.service f9a20231fdcd52a6fbf8ffbf3656aa78
signature.asc
Description: PGP signature
Bug#1073031: kexec-tools: diff for NMU version 1:2.0.27-1.2
Control: tags 1073031 + pending Dear maintainer, I've prepared an NMU for kexec-tools (versioned as 1:2.0.27-1.2) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards. diff -Nru kexec-tools-2.0.27/debian/changelog kexec-tools-2.0.27/debian/changelog --- kexec-tools-2.0.27/debian/changelog 2024-04-27 14:49:56.0 +0200 +++ kexec-tools-2.0.27/debian/changelog 2024-06-12 00:36:59.0 +0200 @@ -1,3 +1,11 @@ +kexec-tools (1:2.0.27-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Install programs into canonical locations in /usr. (DEP17 M2) +(Closes: #1073031) + + -- Chris Hofstaedtler Wed, 12 Jun 2024 00:36:59 +0200 + kexec-tools (1:2.0.27-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru kexec-tools-2.0.27/debian/kexec-tools.dirs kexec-tools-2.0.27/debian/kexec-tools.dirs --- kexec-tools-2.0.27/debian/kexec-tools.dirs 2023-08-22 18:53:02.0 +0200 +++ kexec-tools-2.0.27/debian/kexec-tools.dirs 2024-06-12 00:32:43.0 +0200 @@ -1,2 +1,2 @@ -sbin +usr/sbin etc/default/kexec.d diff -Nru kexec-tools-2.0.27/debian/rules kexec-tools-2.0.27/debian/rules --- kexec-tools-2.0.27/debian/rules 2023-10-04 19:59:38.0 +0200 +++ kexec-tools-2.0.27/debian/rules 2024-06-12 00:32:36.0 +0200 @@ -27,7 +27,7 @@ dh_testdir dh_update_autotools_config dh_autoreconf - CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/sbin --mandir=/usr/share/man --datadir=/usr/share + CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" dh_auto_configure -- --prefix=/usr --exec-prefix=/usr --sbindir=/usr/sbin --mandir=/usr/share/man --datadir=/usr/share touch configure-stamp build: build-arch build-indep @@ -63,7 +63,7 @@ [ ! -f $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static ] || strip $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static endif - install -D -m 0755 debian/kexec-tools/sbin/kexec debian/kexec-tools-udeb/sbin/kexec + install -D -m 0755 debian/kexec-tools/usr/sbin/kexec debian/kexec-tools-udeb/usr/sbin/kexec binary-indep: build install
Bug#1072977: apt-listbugs 0.1.42 is broken
Control: tags -1 + unreproducible moreinfo On Tue, 11 Jun 2024 10:27:33 +0200 Karine Crèvecœur wrote: > Package: apt-listbugs > Version: 0.1.42 > Severity: grave > > > Hi, Hello Karine, thanks for caring about apt-listbugs! > > Since the upgrade to version 0.1.42, apt-listbugs doesn't work anymore. That's unfortunate. However, I have tested apt-listbugs/0.1.42 for months, without ever experiencing any issue like this. And I am currently unable to reproduce the issue. > > As examplen the command > apt-listbugs list apt-lisbugs > gave the error: > > Retrieving bug reports... 0% Fail > Error retrieving bug reports from the server with the following error message: > E: SSL_connect returned=1 errno=0 > peeraddr=[2605:bc80:3010:b00:0:deb:166:212]:443 state=error: certificate > verify failed (unable to get local issuer certificate) > It could be because your network is down, or because of broken proxy servers, > or the BTS server itself is down. Check network configuration and try again This command works on my boxes: $ apt-listbugs -v 0.1.42 $ apt-listbugs list apt-listbugs Retrieving bug reports... Done Parsing Found/Fixed information... Done grave bugs of apt-listbugs (→ ) b1 - #1072977 - apt-listbugs 0.1.42 is broken Summary: apt-listbugs(1 bug) > > > I downgrade apt-listbugs to the version 0.1.41-nmu1, it works just fine. [...] > I don't figure out why this issue occurs. It seems that your system is unable to verify the TLS certificate of https://bugs.debian.org apt-listbugs/0.1.42 switched to https by default, that's why it now needs to connect to the SOAP server via https. Can you think of a reason why your system fails to verify the TLS certificate of https://bugs.debian.org ? You should have package 'ca-certificates' installed: $ apt policy ca-certificates ca-certificates: Installed: 20240203 Candidate: 20240203 Version table: *** 20240203 800 800 http://deb.debian.org/debian testing/main amd64 Packages 500 http://deb.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status I say that you should, since there's the following dependency chain: apt-listbugs → ruby → ruby3.1 → rubygems-integration → ca-certificates Are you able to verify other TLS certificates, when accessing other sites via https? For instance, if you have a web browser installed on the same system, can you visit https://www.debian.org/ with your browser, without TLS certificate issues? Please let me know, so that we can try to debug the issue. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpNULiGv60DM.pgp Description: PGP signature
Bug#1021460: ITA: elpa-rust-mode -- Major Emacs mode for editing Rust source code
Control: reopen -1 Control: tags -1 pending Reopen and pending closing with latest prepared package. -- Xiyue Deng
Bug#1039898: The package is only unusable in stable (bookworm)
tags 1039898 - sid trixie thanks Hi, The package is only unusable in stable (bookworm). But, you can use bookworm-backports [0] to install the same testing/unstable version. It was fixed in testing/unstable by #172 [1]. So, I'm removing sid and trixie tags from this bug report. Cheers, [0] https://tracker.debian.org/news/1530133/accepted-libapache2-mod-qos-1174-1bpo121-source-amd64-into-stable-backports/ [1] https://bugs.debian.org/172 -- Marcelo Jorge Vieira xmpp:me...@jabber-br.org https://metaldot.alucinados.com signature.asc Description: This is a digitally signed message part
Bug#1073031: kexec-tools: move files into /usr (DEP17 M2)
Package: kexec-tools Version: 1:2.0.27-1.1 Severity: normal Tags: patch Your package installs files into aliased locations. They need to move into canonical paths in /usr instead. Because your source package also builds an udeb, automatic analysis failed. Instead, find a patch attached. Additional info can be found at https://wiki.debian.org/UsrMerge Chris diff -Nru kexec-tools-2.0.27/debian/changelog kexec-tools-2.0.27/debian/changelog --- kexec-tools-2.0.27/debian/changelog 2024-04-27 14:49:56.0 +0200 +++ kexec-tools-2.0.27/debian/changelog 2024-06-12 00:32:48.0 +0200 @@ -1,3 +1,10 @@ +kexec-tools (1:2.0.27-1.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Install programs into canonical locations in /usr. (DEP17 M2) + + -- Chris Hofstaedtler Wed, 12 Jun 2024 00:32:48 +0200 + kexec-tools (1:2.0.27-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru kexec-tools-2.0.27/debian/kexec-tools.dirs kexec-tools-2.0.27/debian/kexec-tools.dirs --- kexec-tools-2.0.27/debian/kexec-tools.dirs 2023-08-22 18:53:02.0 +0200 +++ kexec-tools-2.0.27/debian/kexec-tools.dirs 2024-06-12 00:32:43.0 +0200 @@ -1,2 +1,2 @@ -sbin +usr/sbin etc/default/kexec.d diff -Nru kexec-tools-2.0.27/debian/rules kexec-tools-2.0.27/debian/rules --- kexec-tools-2.0.27/debian/rules 2023-10-04 19:59:38.0 +0200 +++ kexec-tools-2.0.27/debian/rules 2024-06-12 00:32:36.0 +0200 @@ -27,7 +27,7 @@ dh_testdir dh_update_autotools_config dh_autoreconf - CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" dh_auto_configure -- --prefix=/usr --exec-prefix=/ --sbindir=/sbin --mandir=/usr/share/man --datadir=/usr/share + CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)" CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)" dh_auto_configure -- --prefix=/usr --exec-prefix=/usr --sbindir=/usr/sbin --mandir=/usr/share/man --datadir=/usr/share touch configure-stamp build: build-arch build-indep @@ -63,7 +63,7 @@ [ ! -f $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static ] || strip $(CURDIR)/debian/kexec-tools/usr/lib/kexec-tools-testing/kexec_test.static endif - install -D -m 0755 debian/kexec-tools/sbin/kexec debian/kexec-tools-udeb/sbin/kexec + install -D -m 0755 debian/kexec-tools/usr/sbin/kexec debian/kexec-tools-udeb/usr/sbin/kexec binary-indep: build install
Bug#731346: issue goes away with usrmerge
tags 731346 + wontfix thanks this concern becomes a non-issue with wiki.debian.org/UsrMerge signature.asc Description: PGP signature
Bug#1071144: systemd-sysuser has problems too
On Wed, May 29, 2024 at 04:37:30PM +0200, Lorenzo wrote: > just to make sure that the info is complete: Both of your points are FUD. > the patch adds a dependency in the form > > systemd | systemd-standalone-sysusers | systemd-sysusers > > with the above by default, on an alternative init system, apt > wants to remove your init system and intall systemd. A quick check on a current Debian unstable with runit-init, and with or without elogind, shows that there is no problem. stunnel4 is a package using the dependency as you show: | # dpkg -l runit-init | egrep '^ii' | ii runit-init 2.1.2-54 arm64system-wide service supervision (as init system) | # apt install stunnel4 | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | The following additional packages will be installed: | systemd-standalone-sysusers | Suggested packages: | logcheck-database | The following NEW packages will be installed: | stunnel4 systemd-standalone-sysusers | 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. > Another issue is that it contributes to make it impossible to switch > a system from systemd to another init system; I recently tried in > virtualbox and could not do it even using dpkg --force-depends, thanks > to elogind plus other important packages like udev and > cron-dameon-common that are using this kind of dependency. See above. It just works. There is no need for --force-depends or any trickery, except what you documented yourself: init has to be removed to install runit-init. Chris
Bug#1072952: krb5: FTBFS: ../../src/tests/t_iprop.py - E: Build killed with signal TERM after 60 minutes of inactivity
control: tags -1 -help +confirmed I reproduced the problem with a podman container with no network. Apparently t_iprop.py hangs if the only network interface is loopback. I'm fairly sure it would work fine only talking to itself if there was a non-127.0.0.1 address for it to use. If I can fix this easily, I'll do so. Otherwise I'll engage with the sbuild maintainers. It's always been the case that builds have had a network interface, even if it has been illegal to reach off the local machine. Kerberos has always treated lo different than other local interfaces; the rationale for this goes back to the Kerberos standard (RFC 4120). --Sam
Bug#1072765: python-skbio: FTBFS: dh_sphinxdoc: error: debian/python-skbio-doc/usr/share/doc/python-skbio-doc/html/_static/js/jquery-fix.js is missing
Control: reassign -1 sphinx-bootstrap-theme/0.8.1-4 On Friday, June 07 2024, Santiago Vila wrote: > Dear maintainer: > > During a rebuild of all packages in unstable, your package failed to build: > [...] > dh_sphinxdoc --package=python-skbio-doc > dh_sphinxdoc: error: > debian/python-skbio-doc/usr/share/doc/python-skbio-doc/html/_static/js/jquery-fix.js > is missing This problem was introduced by: https://salsa.debian.org/python-team/packages/sphinx-bootstrap-theme/-/commit/974f47fade1fa7de53c9dd1ec152536d7119942c It's clearly wrong to stop installing the js/font files here; they are exactly what makes the theme work. Arguably the package should be using js/font files from existing Debian packages, but that's another issue and there's a bug for it. Reassigning. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#1073030: kglobalacceld has an undeclared file conflict on /usr/lib/systemd/user/plasma-kglobalaccel.service
Package: kglobalacceld Version: 6.0.90-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libkf5globalaccel-bin kglobalacceld has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/systemd/user/plasma-kglobalaccel.service is contained in the packages * kglobalacceld/6.0.90-1 as present in experimental * libkf5globalaccel-bin * 5.103.0-1 as present in bookworm * 5.115.0-2 as present in trixie|unstable * 5.78.0-3 as present in bullseye These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1070726: nvidia-kernel-dkms wont build with latest bullseye kernel 5.10.0-29-amd64
On Wed, 8 May 2024 06:43:26 +0200 Andreas Beckmann mailto:a...@debian.org>> wrote: > On 08/05/2024 02.20, Braiden Kindt wrote: > > Package: nvidia-kernel-dkms > > Version: 470.223.02-1 > > There is already a newer driver version in oldstable-proposed-updates. Hi Andreas, How long might the new driver version stay in oldstable-proposed-updates until it moves to oldstable-updates? I just ran into this issue when upgrading to kernel 5.10.0-30-amd64 on a test machine and am looking for a solution before attempting to roll the updates out to our lab machines. Cheers, Merlin.
Bug#1063473: tgt DEP8 fix proposal
Control: tags -1 patch The DEP8 tests currently fail with: 48s The following packages have unmet dependencies: 48s satisfy:command-line : Depends: tgt-rbd but it is not going to be installed 48s Depends: tgt-glusterfs but it is not installable 48s E: Unable to correct problems, you have held broken packages. 48s storage FAIL badpkg 48s blame: tgt 48s badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. The following salsa MR fixes the issue by skipping the unsupported tests for the failing architectures https://salsa.debian.org/debian/tgt/-/merge_requests/4 This is needed because the issue lies in package dependencies no longer supporting 32-bit architectures. -- Athos Ribeiro
Bug#1069575: FTBFS in experimental
On Mon, 10 Jun 2024 11:02:23 +0200 Jonas Smedegaard wrote: > > > > I will look into updating concurrent-queue to 2.5.0 then. > > Any news on updating concurrent-queue to 2.5.0? > > - Jonas Just uploaded to exp along with async-io 2.3.3. best, werdahias
Bug#1073027: RFS: parlatype/4.2-1 -- Minimal audio player for manual speech transcription
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "parlatype": * Package name : parlatype Version : 4.2-1 Upstream contact : that's actually me * URL : www.parlatype.xyz * License : GPL-3+ * Vcs : https://salsa.debian.org/gkarsay/parlatype Section : sound The source builds the following binary packages: parlatype - Minimal audio player for manual speech transcription parlatype-common - Minimal audio player for manual speech transcription (arch-independent files) libparlatype7 - Library for Parlatype - runtime version libparlatype-dev - Library for Parlatype - development version libparlatype-doc - Documentation files for the Parlatype library gir1.2-parlatype-5.0 - Library for Parlatype - gir bindings To access further information about this package, please visit the following URL: https://mentors.debian.net/package/parlatype/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/parlatype/parlatype_4.2-1.dsc Changes since the last upload: parlatype (4.2-1) unstable; urgency=medium . * New upstream version 4.2 * Update watch file * Refresh patch #02 * Add patch for autopkgtest * Remove glade option and copyright of its assets * Update copyright for added/removed files * Update homepage to www.parlatype.xyz * Change app ID to xyz.parlatype.Parlatype (install) * Raise GTK dependency from 3 to 4 * Update gir package to 5.0 * Update lib package to libparlatype7 * Move arch-independent files into package parlatype-common * Enable cross-compiling GObject introspection data * Bump Standards-Version to 4.7.0 (no changes needed) * Lintian override for gir (false positive) Other info: * Although I intended to fix cross compiling, the Salsa CI cross compile test didn't succeed. * According to mentors' QA information there's an unused override. I had that lintian warning locally and as described in the override I think it's a false positive. Regards, Gabor Karsay
Bug#1073029: libx11: please consider upgrading to 3.0 source format
Source: libx11 Version: 2:1.8.7-1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073028: libsm: please consider upgrading to 3.0 source format
Source: libsm Version: 2:1.2.3-1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073026: libpciaccess: please consider upgrading to 3.0 source format
Source: libpciaccess Version: 0.14-1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073025: libice: please consider upgrading to 3.0 source format
Source: libice Version: 2:1.0.9-2 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073024: please consider upgrading to 3.0 source format
Source: glw Version: 8.0.0-1.1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073023: ocaml-luv: autopkgtest regression: Version 3.15 of the dune language is not supported
Source: ocaml-luv Version: 0.5.12-2 Severity: serious Tags: sid trixie User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Your package has an autopkgtest, great. However, it started to fail in testing. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. The release team has announced [1] that failing autopkgtest on amd64 and arm64 are considered RC in testing. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073022: please consider upgrading to 3.0 source format
Source: cl-xptest Version: 1.2.4-3.1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073021: please consider upgrading to 3.0 source format
Source: cl-xlunit Version: 0.6.3-2.2 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073020: please consider upgrading to 3.0 source format
Source: cl-pubmed Version: 2.1.3-5.2 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073019: please consider upgrading to 3.0 source format
Source: cl-pipes Version: 1.2.1-5.2 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073018: please consider upgrading to 3.0 source format
Source: cl-photo Version: 0.14-4.2 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073017: please consider upgrading to 3.0 source format
Source: cl-modlisp Version: 0.6-7.1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073015: please consider upgrading to 3.0 source format
Source: cl-lml Version: 2.5.7-4.1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073016: please consider upgrading to 3.0 source format
Source: cl-lml2 Version: 1.6.6-4.1 Severity: wishlist This package is among the few that still use source format 1.0. Please upgrade it to source format 3.0, as (1) this format has many advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to standardization of packaging practices.
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Source: dhcpcd Version: 1:10.0.8-1 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package because it was tested for glibc. I noticed that it regularly fails. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul https://ci.debian.net/packages/d/dhcpcd/testing/amd64/47186590/ [--- 86s Preparing virtual interfaces... 86s Actual changes: 86s tx-checksum-ip-generic: off 86s tx-tcp-segmentation: off [not requested] 86s tx-tcp-ecn-segmentation: off [not requested] 86s tx-tcp-mangleid-segmentation: off [not requested] 86s tx-tcp6-segmentation: off [not requested] 86s tx-checksum-sctp: off 86s Preparing dnsmasq configuration... 91s Obtaining network configuration for veth1 via dhcp... 122s timed out 122s autopkgtest [05:47:12]: test timesyncd-ntp-servers-from-dhcp: ---] OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073013: [Pkg-javascript-devel] Bug#1073013: nodejs: Testsuite fails with OpenSSL 3.2.2
Le mar. 11 juin 2024 à 22:00, Sebastian Andrzej Siewior < sebast...@breakpoint.cc> a écrit : > Package: nodejs > Version: 20.14.0+dfsg-1 > Severity: serious > Tags: patch > > OpenSSL 3.2.2 introduced an error code a behaviour Node was testing and > now "test/parallel/test-http2-https-fallback.js" is unhappy. The OpenSSL > change is was introduced in https://github.com/openssl/openssl/pull/24338. > > I don't know if node relies on that error outside of the testsuite. The > patch attached swaps the error code and the test passes. OpenSSL 3.2.2 > is currently in unstable. Thank you. There is an upstream fix for this (and some other tests).
Bug#1072874: pscan: Convert cdbs patches to 3.0 (quilt) patches
Control: tags -1 patch Please find a patch attached.diff -Nru pscan-1.2/debian/changelog pscan-1.2/debian/changelog --- pscan-1.2/debian/changelog 2024-06-09 13:39:31.0 + +++ pscan-1.2/debian/changelog 2024-06-11 20:00:15.0 + @@ -1,3 +1,10 @@ +pscan (1.2-9.3) unstable; urgency=medium + + * Non-maintainer upload. + * Convert cdbs patches to 3.0 (quilt) patches. (Closes: #1072874) + + -- Bastian Germann Tue, 11 Jun 2024 20:00:15 + + pscan (1.2-9.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru pscan-1.2/debian/patches/40_max_stack.patch pscan-1.2/debian/patches/40_max_stack.patch --- pscan-1.2/debian/patches/40_max_stack.patch 2024-06-09 13:38:23.0 + +++ pscan-1.2/debian/patches/40_max_stack.patch 2024-06-11 19:59:42.0 + @@ -1,5 +1,5 @@ pscan.c.orig 2008-07-26 00:59:02.0 +0200 -+++ pscan.c2008-07-26 00:59:20.0 +0200 +--- pscan-1.2.orig/pscan.c 2008-07-26 00:59:02.0 +0200 pscan-1.2/pscan.c 2008-07-26 00:59:20.0 +0200 @@ -46,7 +46,7 @@ static int warnings = FALSE; static char *filename; diff -Nru pscan-1.2/debian/patches/series pscan-1.2/debian/patches/series --- pscan-1.2/debian/patches/series 1970-01-01 00:00:00.0 + +++ pscan-1.2/debian/patches/series 2024-06-11 19:58:03.0 + @@ -0,0 +1,3 @@ +20_pscan.patch +30_scanner.patch +40_max_stack.patch diff -Nru pscan-1.2/debian/rules pscan-1.2/debian/rules --- pscan-1.2/debian/rules 2024-06-09 13:38:23.0 + +++ pscan-1.2/debian/rules 2024-06-11 19:58:18.0 + @@ -9,5 +9,4 @@ include /usr/share/cdbs/1/class/makefile.mk include /usr/share/cdbs/1/rules/debhelper.mk -include /usr/share/cdbs/1/rules/simple-patchsys.mk
Bug#1073013: nodejs: Testsuite fails with OpenSSL 3.2.2
Package: nodejs
Version: 20.14.0+dfsg-1
Severity: serious
Tags: patch
OpenSSL 3.2.2 introduced an error code a behaviour Node was testing and
now "test/parallel/test-http2-https-fallback.js" is unhappy. The OpenSSL
change is was introduced in https://github.com/openssl/openssl/pull/24338.
I don't know if node relies on that error outside of the testsuite. The
patch attached swaps the error code and the test passes. OpenSSL 3.2.2
is currently in unstable.
Sebastian
From: Sebastian Andrzej Siewior
Date: Tue, 11 Jun 2024 19:30:13 +
Subject: [PATCH] tests: Check for real error code
OpenSSL since 3.2.2 got an actual error code for the behaviour node was
testing. It was introduced by https://github.com/nodejs/node/pull/53384.
Signed-off-by: Sebastian Andrzej Siewior
---
test/parallel/test-http2-https-fallback.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/parallel/test-http2-https-fallback.js b/test/parallel/test-http2-https-fallback.js
index 8e0612375f48..d44e49ab021c 100644
--- a/test/parallel/test-http2-https-fallback.js
+++ b/test/parallel/test-http2-https-fallback.js
@@ -151,7 +151,7 @@ function onSession(session, next) {
// Incompatible ALPN TLS client
tls(Object.assign({ port, ALPNProtocols: ['fake'] }, clientOptions))
.on('error', common.mustCall((err) => {
- strictEqual(err.code, 'ECONNRESET');
+ strictEqual(err.code, 'ERR_SSL_TLSV1_ALERT_NO_APPLICATION_PROTOCOL');
cleanup();
testNoALPN();
}));
Bug#1072877: cycfx2prog: Convert cdbs patches to 3.0 (quilt) patches
Control: tags -1 patch Please find a patch attached.diff -Nru cycfx2prog-0.47/debian/changelog cycfx2prog-0.47/debian/changelog --- cycfx2prog-0.47/debian/changelog2024-03-24 19:53:34.0 + +++ cycfx2prog-0.47/debian/changelog2024-06-11 19:51:49.0 + @@ -1,3 +1,10 @@ +cycfx2prog (0.47-1.3) unstable; urgency=medium + + * Non-maintainer upload. + * Apply patches via quilt instead of cdbs. (Closes: #1072877) + + -- Bastian Germann Tue, 11 Jun 2024 19:51:49 + + cycfx2prog (0.47-1.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru cycfx2prog-0.47/debian/patches/series cycfx2prog-0.47/debian/patches/series --- cycfx2prog-0.47/debian/patches/series 1970-01-01 00:00:00.0 + +++ cycfx2prog-0.47/debian/patches/series 2024-06-11 19:49:25.0 + @@ -0,0 +1 @@ +fix-ftbfs-with-ls-as-needed.patch diff -Nru cycfx2prog-0.47/debian/rules cycfx2prog-0.47/debian/rules --- cycfx2prog-0.47/debian/rules2024-03-24 19:53:13.0 + +++ cycfx2prog-0.47/debian/rules2024-06-11 19:49:35.0 + @@ -7,7 +7,6 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/makefile.mk -include /usr/share/cdbs/1/rules/simple-patchsys.mk binary-install/cycfx2prog:: install cycfx2prog debian/cycfx2prog/usr/bin
Bug#1060528: libu2f-host: Please switch Build-Depends to systemd-dev
On Thu, Jan 11, 2024 at 11:36:52PM +0100, bi...@debian.org wrote: > your package libu2f-host declares a Build-Depends on systemd and/or > udev. > > In most cases, this build dependency is added to get the paths that > are defined in udev.pc or systemd.pc (via pkgconfig). It turns out the package did not need udev, so I uploaded an NMU to DELAYED/0-day removing it. nmudiff attached. Kind regards Philipp Kern diff -Nru libu2f-host-1.1.10/debian/changelog libu2f-host-1.1.10/debian/changelog --- libu2f-host-1.1.10/debian/changelog 2021-01-14 18:43:26.0 +0100 +++ libu2f-host-1.1.10/debian/changelog 2024-06-11 21:19:54.0 +0200 @@ -1,3 +1,11 @@ +libu2f-host (1.1.10-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Drop the udev build dependency. (Closes: #1060528) + * Build-depend on pkgconf instead of pkg-config. + + -- Philipp Kern Tue, 11 Jun 2024 21:19:54 +0200 + libu2f-host (1.1.10-3) unstable; urgency=medium * debian/copyright: Fix syntax error with Upstream-Contact diff -Nru libu2f-host-1.1.10/debian/control libu2f-host-1.1.10/debian/control --- libu2f-host-1.1.10/debian/control 2021-01-14 18:43:26.0 +0100 +++ libu2f-host-1.1.10/debian/control 2024-06-11 21:19:54.0 +0200 @@ -14,9 +14,8 @@ libglib2.0-dev, libhidapi-dev, libjson-c-dev, - pkg-config, - python3, - udev [linux-any] + pkgconf, + python3 Standards-Version: 4.5.1 Rules-Requires-Root: no Homepage: https://developers.yubico.com/libu2f-host/
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
On Tue, Jun 11, 2024 at 8:24 PM Otto Kekäläinen wrote: > I will post my suggestion that involves having a config similar to > https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/gbp.conf but > upstream as 'main' and some other tweaks for easier long-term > maintainability, along with explanation why my suggestion is what it is. Would 'git config --global init.defaultBranch main' and reimport of package versions do it? Maybe change it now? I think this might to it: git branch -m master main git push -u origin main > Are you ok hosting the package in salsa.debian.org/debian namespace? > Or at least mirror it there? As noted, GitHub is only for the easier review for you instead of downloading the whole repository on a slow internet connection. Laszlo/GCS
Bug#1029140: cron-apt refuses to run when RUNSLEEP is set
On Tue, Jun 11, 2024 at 08:12:27PM +0200, Ola Lundqvist wrote: > Certainly. If you know those I'm happy to fix them. > > I thought I had fixed them all already. The one that jumped to my mind is $RANDOM which doesnt work in dash. I would recommend just using /bin/bash in the shebang line. At least that's what I do since I'd rather not delve into those shell details too deeply. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#738178: O: libinnodb -- Embedded InnoDB Library
Control: retitle -1 O: libinnodb -- Embedded InnoDB Library Control: reassign -1 wnpp X-Debbugs-Cc: stew...@flamingspork.com Steward has never uploaded the package, so it is fair to say that it is orphaned after 14 years of packager inactivity which led to it neither being available in bullseye nor bookworm.
Bug#1073012: Automatically rewrite incoming entries from some CNAs as NFUs
Package: security-tracker Severity: wishlist These days the scopes of CNAs are usually narrow and scoped to a specific vendor. We should leverage this for pre-processing incoming data and to reduce toil. We can do this by extending the "automatic update" job to automatically annotate CVEs assigned by a given CNA as NFU entries. As an example all CVEs coming from the "Wordfence" CNA should be automatically added as "NOT-FOR-US: WordPress plugin". This avoids cumbersome manual triage (and review would still happen on the commited entries). Same for many commercial software vendors, e.g. a company like SAP which has no ties to FLOSS everything coming from their CNA should automatically be added as "NOT-FOR-US: SAP" without human interaction. We should only extend this on a case-by-case basis. E.g. Oracle has a lot of propietary software, but they also maintain mysql, Java and virtualbox, so they need manual review still. Cheers, Moritz
Bug#1073011: nmu: cgal_5.6.1-1
Package: release.debian.org Severity: normal X-Debbugs-Cc: c...@packages.debian.org, Joachim Reichel Control: affects -1 + src:cgal User: release.debian@packages.debian.org Usertags: binnmu New version of Ipe has been uploaded, which cgal uses. nmu cgal_5.6.1-1 . ANY . unstable . -m "Rebuild against libipe 7.2.30" signature.asc Description: This is a digitally signed message part.
Bug#1073010: Crash on every beamer pdf re-compilation
Package: evince Version: 46.3-1 Severity: important Since a few days I noticed (but the problem could be weeks old before I noticed), evince crashes when it displays a pdf that is being re- compiled from latex. It is a beamer in presentation view, in case it matters - but obviously reproducing the issue would be more efficient. Setting severity to important because a crash does impact the usefulness of the software, even though it doesn't make it completely useless. Cheers, J.Puydt PS: I ran evince in gdb and tried to reproduce the crash ; here is what the end of the log looks like: [New Thread 0x7f1b492006c0 (LWP 830981)] (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: instance of invalid non-instantiatable type 'GEnum' (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: instance of invalid non-instantiatable type '(null)' (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: instance of invalid non-instantiatable type '' (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (evince:830951): GLib-GObject-CRITICAL **: 20:55:33.417: g_object_unref: assertion 'G_IS_OBJECT (object)' failed [Thread 0x7f1b420006c0 (LWP 830967) exited] [Thread 0x7f1b492006c0 (LWP 830981) exited] [New Thread 0x7f1b492006c0 (LWP 830988)] [New Thread 0x7f1b420006c0 (LWP 830989)] Thread 1 "evince" received signal SIGSEGV, Segmentation fault. 0x7f1b581d2205 in g_type_check_instance () from /lib/x86_64-linux- gnu/libgobject-2.0.so.0 (gdb) bt #0 0x7f1b581d2205 in g_type_check_instance () at /lib/x86_64- linux-gnu/libgobject-2.0.so.0 #1 0x7f1b581c7788 in g_signal_handlers_disconnect_matched () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #2 0x7f1b5829e0f5 in () at /lib/x86_64-linux-gnu/libevview3.so.3 #3 0x7f1b5829e200 in () at /lib/x86_64-linux-gnu/libevview3.so.3 #4 0x7f1b581b204b in g_object_unref () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #5 0x55cee218ba7f in () #6 0x7f1b581ac730 in g_closure_invoke () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #7 0x7f1b581c087c in () at /lib/x86_64-linux-gnu/libgobject- 2.0.so.0 #8 0x7f1b581c2281 in () at /lib/x86_64-linux-gnu/libgobject- 2.0.so.0 #9 0x7f1b581c7f06 in g_signal_emit_valist () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #10 0x7f1b581c7fc3 in g_signal_emit () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #11 0x7f1b581b0924 in () at /lib/x86_64-linux-gnu/libgobject- 2.0.so.0 #12 0x7f1b581b43b9 in g_object_notify () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #13 0x55cee2184231 in () #14 0x7f1b581ac730 in g_closure_invoke () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #15 0x7f1b581c087c in () at /lib/x86_64-linux-gnu/libgobject- 2.0.so.0 #16 0x7f1b581c2281 in () at /lib/x86_64-linux-gnu/libgobject- 2.0.so.0 #17 0x7f1b581c7f06 in g_signal_emit_valist () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #18 0x7f1b581c7fc3 in g_signal_emit () at /lib/x86_64-linux- gnu/libgobject-2.0.so.0 #19 0x7f1b582772db in () at /lib/x86_64-linux-gnu/libevview3.so.3 #20 0x7f1b580a3dff in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #21 0x7f1b580a5e87 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #22 0x7f1b580a64a0 in g_main_context_iteration () at /lib/x86_64- linux-gnu/libglib-2.0.so.0 #23 0x7f1b5741a43d in g_application_run () at /lib/x86_64-linux- gnu/libgio-2.0.so.0 #24 0x55cee2173063 in main ()
Bug#1073009: doesn't work with SQLAlchemy 2.X
Source: openstack-trove Version: 1:21.0.1-2 Severity: serious Tags: ftbfs Hi, I uploaded SQLAlchemy 2.X to unstable and openstack-trove currently FTBFS due to failing tests (tries to import sqlalchemy.databases which is no longer available) so the code is definitely not ready for SA 2.X. I gues you're well aware of this, reporting to keep track of what needs to be done.
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
Good, looks like you got the hang of it. I will post my suggestion that involves having a config similar to https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/gbp.conf but upstream as 'main' and some other tweaks for easier long-term maintainability, along with explanation why my suggestion is what it is. Are you ok hosting the package in salsa.debian.org/debian namespace? Or at least mirror it there?
Bug#1029140: cron-apt refuses to run when RUNSLEEP is set
Hi Marc Certainly. If you know those I'm happy to fix them. I thought I had fixed them all already. Cheers // Ola On Tue, 11 Jun 2024 at 15:52, Marc Haber wrote: > > On Mon, Jun 10, 2024 at 11:02:30PM +0200, Ola Lundqvist wrote: > > Sorry, I meant to run with dash -x. Or do dash not have that option? > > It has this option. > > But I see a problem in cron-apt using bashisms while using the /bin/sh > shebang line. I don't know whether this have to do with this, bug, but > it should be fixed anyway. > > Greetings > Marc > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 > Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Bug#1058130: closed by Debian FTP Masters (reply to Ulises Vitulli ) (Bug#1058130: fixed in python-nmea2 1.19.0-1)
Control: tags -1 + patch
On Tuesday, May 14 2024, Adrian Bunk wrote:
> Control: reopen -1
>
> On Mon, Feb 12, 2024 at 10:57:03PM +, Debian Bug Tracking System wrote:
>>...
>> python-nmea2 (1.19.0-1) unstable; urgency=medium
>> .
>>* New upstream release (Closes: #1058130).
>>...
>> Relevant part (hopefully):
>> > fakeroot debian/rules clean
>> > dh clean --with python3 --buildsystem=pybuild
>> >dh_auto_clean -O--buildsystem=pybuild
>> > I: pybuild base:310: python3.12 setup.py clean
>> > Traceback (most recent call last):
>> > File "/<>/setup.py", line 3, in
>> > import imp
>> > ModuleNotFoundError: No module named 'imp'
>> > E: pybuild pybuild:395: clean: plugin distutils failed with: exit code=1:
>> > python3.12 setup.py clean
>> > dh_auto_clean: error: pybuild --clean -i python{version} -p "3.12 3.11"
>> > returned exit code 13
>> > make: *** [debian/rules:7: clean] Error 25
>>...
>
> The fix is not included in 1.19.0-2:
> https://buildd.debian.org/status/fetch.php?pkg=python-nmea2=all=1.19.0-2=1715629490=0
Upstream has not made a proper release yet; the following debdiff fixes
the issue meanwhile.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
diff -Nru
python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch
python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch
--- python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch
1969-12-31 19:00:00.0 -0500
+++ python-nmea2-1.19.0/debian/patches/0001-Python-3.12-compatibility-164.patch
2024-06-11 13:55:12.0 -0400
@@ -0,0 +1,72 @@
+From: Simon H
+Date: Sun, 11 Feb 2024 17:59:59 +
+Subject: Python 3.12 compatibility (#164)
+
+* Removed depreciated `imp` and replaced with `importlib`
+
+* Updated meta classifiers to include newer Python versions
+
+* Added Python3.12 into github workflow action
+
+* Updated workflow to test all versions we say we do
+
+* Tidied mixed markup styles
+
+* Assed Windows and MacOS to tests
+
+* Updated depreciated setup-python action to v5
+
+* Adding Python3.12 to Action
+
+* Removed my test branch from Actions
+
+Origin: backport,
https://github.com/Knio/pynmea2/commit/802bfb627eb05a1ee655854dd261800061322b9a
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058130
+
+This patch has been adjusted to contain only the necessary bits from
+setup.py. All the other changes were dropped.
+---
+ setup.py | 24 ++--
+ 1 file changed, 22 insertions(+), 2 deletions(-)
+
+diff --git a/setup.py b/setup.py
+index facd391..d9d3eb8 100644
+--- a/setup.py
b/setup.py
+@@ -1,7 +1,24 @@
++import importlib.machinery
++import importlib.util
++
+ from setuptools import setup
+
+-import imp
+-_version = imp.load_source("pynmea2._version", "pynmea2/_version.py")
++
++def load_source(modname, filename):
++"""Load a source file and return its module object.
++
++From: https://docs.python.org/3.12/whatsnew/3.12.html#imp
++"""
++loader = importlib.machinery.SourceFileLoader(modname, filename)
++spec = importlib.util.spec_from_file_location(modname, filename,
loader=loader)
++module = importlib.util.module_from_spec(spec)
++# The module is always executed and not cached in sys.modules.
++# Uncomment the following line to cache the module.
++# sys.modules[module.__name__] = module
++loader.exec_module(module)
++return module
++
++_version = load_source("pynmea2._version", "pynmea2/_version.py")
+
+ setup(
+ name='pynmea2',
+@@ -29,6 +46,9 @@ setup(
+ 'Programming Language :: Python :: 3.7',
+ 'Programming Language :: Python :: 3.8',
+ 'Programming Language :: Python :: 3.9',
++'Programming Language :: Python :: 3.10',
++'Programming Language :: Python :: 3.11',
++'Programming Language :: Python :: 3.12',
+ 'Programming Language :: Python :: Implementation :: PyPy',
+ 'Topic :: Scientific/Engineering :: GIS',
+ 'Topic :: Software Development :: Libraries :: Python Modules',
diff -Nru python-nmea2-1.19.0/debian/patches/series
python-nmea2-1.19.0/debian/patches/series
--- python-nmea2-1.19.0/debian/patches/series 1969-12-31 19:00:00.0
-0500
+++ python-nmea2-1.19.0/debian/patches/series 2024-06-11 13:55:12.0
-0400
@@ -0,0 +1 @@
+0001-Python-3.12-compatibility-164.patch
signature.asc
Description: PGP signature
Bug#1073007: rust-object: please upgrade to v0.35
Source: rust-object Version: 0.32.2-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please upgrade to, or separately provide, branch v0.35. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZokBwACgkQLHwxRsGg ASEEzA//TFdb6wgvGKU5+NPvgttVSP6T2xEpU0/YKXgR93ibeKW+wmPCWbqNj+ul V1Hji+5NwwMYmUxZgAQnH4BobxlYAlCKdEyaCgc4lbfuRjZ3bXSJjyKwMqvo5ocj 8Fv2zKcsTmUOUc0xqjYdspQgFR32foy3+DNTtLxIQQHQi9ZHo5ws6XWx2xAtu2Fv ZaautU2Ya38+pfhSRMHpsLi9OYmE2Gpaooh7DUNXCAmeU9jPsmgylZOkeLABSVD9 GWeEo7JOIUXX6FgZaqwsHgE5ochV1eDDqvwesmZd91z/nhX9pwipDR6dcP/5h5AN a+ulH/4ZfPDBUGMunj8CNs6FUmmIcZQcBPNdUYYbLJZLXF3atI49kHj+npLfPbWu PW7vc27X+wb1NisWhFx7Eci5flCc6HzqGaEeJ1CLG5Za3cPpDVMoMxp+Mppoe4Ut r/nlAmJbiljDfT2imk/6Iq24aZI3jkK36t7JA0zDnCouaT5hdxVJTk6jr7wOOtHI Crc/L8GYqtybvNnbxsM5UB717tL+r2/jzcnO6hVORrneLVLsDRi4RLf+P3XCRpe3 0GVRfswWF6PmTWz7atVqWR27JwKqiZidGftpvqcFkj68i0+uVh0euJ1/lv5LW4je rzGt/c68/rIklnJrErw9Wlp6+eacCBx8W0KRdjE0CnQYy4nwOw0= =1y8t -END PGP SIGNATURE-
Bug#1073006: rust-gimli: please upgrade to v0.29
Source: rust-gimli Version: 0.28.1-2 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please upgrade to, or separately provide, v0.29. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZojh4ACgkQLHwxRsGg ASFd6w/8CQvrJw8+BMlxRPF5Fs21xnsfXuDeA+m5HnQDHCII2KTziMVZHNniduxB wMfVLOpxicNkFkgGa5oDl9jZmJPIutshmcaa/JpmkSBqA9hMTLJ5ld3C9Y07b362 4E3Gb714PT47odD6mo7qJyrkwlckncukVRUJXB/Gq9xIRi8fzYBVe1XBoa/1i/ge AWYPmELImO+ce2CPkOPRmKkYzMW5PPWTFIGOIXMO4hC8y7WTImf4JuyiPJZTOc0J 1++c6umQyfyfCvwb9KBkFKYm67fpN6bK5a+hbkyobFG03w4mM8YrtJHmbBTGB4QZ qN8YhWdJ+epKkrdFLAYIXE9HkRtu0AT7YtjGprBr3JZimj2sRz9HOEkW5oe53dUR +UIrYGBwa8bX/g2AYFznwC6+ern4KFDtKY8WjgmubsgL6yFv2U7YyrV0RYWxp4JT AbOG1jtP2tgZVpJiwVbOc/frCFz/zgyo+Oo7nXkv7D+yRCSPf2lpbCSMa/qKZJ54 p3YbR3RPOoGqZFz+JdIC0E+9pMS1n+jBDjso8OSRnDkCMzs8hrwG0nuAF5x8OMDg klac/i+jhKdStGgVTV4VM1cfDY754r5QaBG3jUlUlKHuprVfV0Yy9RzhLtZNcE2L nj221Kv2Lf5Ld+Ri9yQ2CCxhXgNWD6gvN4wOnZ1Rw6D2i0YfAiY= =OYsQ -END PGP SIGNATURE-
Bug#1073005: transmission: consider switching back to vendored libb64
Source: transmission Version: 4.0.6+dfsg-1 transmission-gtk is included in Ubuntu Desktop's default install (specifically the expanded install option). This means that transmission-gtk is in Ubuntu main and all its dependencies must be in Ubuntu main instead of in Ubuntu universe. libb64 is in Ubuntu universe. After an initial review, I determined that libb64 does not seem like a good candidate for Ubuntu's Main Inclusion process [1]. Therefore, I will need to re-vendor libb64 inside the transmission package. If Debian does the same, then it would be possible for Debian and Ubuntu to share the same packaging, allowing package improvements to more quickly reach Ubuntu during the part of Ubuntu's development cycle when automatic sync is enabled. Specifically: - libb64 has been unmaintained since 2013 https://sourceforge.net/p/libb64/git/commit_browser - libb64 has several open bugs, some of which have security implications https://sourceforge.net/p/libb64/bugs/ - libb64 is missing a pkgconfig file which is a relatively simple standard way for other software to use libb64 https://launchpad.net/bugs/1534293 - The Debian packaging is not using simple dh rules. The packaging seems to otherwise be fairly modern but it's more complicated than typical Debian packages. https://salsa.debian.org/alteholz/libb64/-/blob/master/debian/rules Reference -- [1] https://github.com/canonical/ubuntu-mir Thank you, Jeremy Bícha
Bug#1066608: dvbstreamer: diff for NMU version 2.1.0-5.7
Control: tags 1066608 + patch
Control: tags 1066608 + pending
Dear maintainer,
I've prepared an NMU for dvbstreamer (versioned as 2.1.0-5.7) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer or cancel the NMU.
Regards.
diff -Nru dvbstreamer-2.1.0/debian/changelog dvbstreamer-2.1.0/debian/changelog
--- dvbstreamer-2.1.0/debian/changelog 2022-08-08 18:22:11.0 +
+++ dvbstreamer-2.1.0/debian/changelog 2024-06-11 16:44:11.0 +
@@ -1,3 +1,12 @@
+dvbstreamer (2.1.0-5.7) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add debian/patches/no-implicit-declarations.patch,
+fix missing declaration of UTF8_nextchar() and typo.
+Thanks to Steve Langasek . (Closes: #1066608)
+
+ -- Francisco Vilmar Cardoso Ruviaro Tue, 11 Jun 2024
16:44:11 +
+
dvbstreamer (2.1.0-5.6) unstable; urgency=medium
* fix lintian no-versioned-debhelper-prerequisite 10
diff -Nru dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
--- dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
1970-01-01 00:00:00.0 +
+++ dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
2024-06-11 16:43:40.0 +
@@ -0,0 +1,38 @@
+Description: fix missing declaration of UTF8_nextchar() and typo
+Author: Steve Langasek
+Bug-Debian: https://bugs.debian.org/1066608
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+===
+--- dvbstreamer-2.1.0.orig/src/standard/dvb/sdtprocessor.c
dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+@@ -46,6 +46,7 @@
+ #include "sdtprocessor.h"
+ #include "dvbtext.h"
+ #include "standard/dvb.h"
++#include "utf8.h"
+
+
/***
+ * Defines
*
+Index: dvbstreamer-2.1.0/src/plugins/cam.c
+===
+--- dvbstreamer-2.1.0.orig/src/plugins/cam.c
dvbstreamer-2.1.0/src/plugins/cam.c
+@@ -97,7 +97,7 @@
+
+ if (pmt->i_program_number == service->id)
+ {
+-needs_decrypting = PMTDoesNeedDecypting(pmt);
++needs_decrypting = PMTDoesNeedDecrypting(pmt);
+
+ if (currentPMT)
+ {
+@@ -197,4 +197,4 @@
+ }
+
+ return false;
+-}
+\ No newline at end of file
++}
diff -Nru dvbstreamer-2.1.0/debian/patches/series
dvbstreamer-2.1.0/debian/patches/series
--- dvbstreamer-2.1.0/debian/patches/series 2021-10-16 08:37:38.0
+
+++ dvbstreamer-2.1.0/debian/patches/series 2024-06-11 16:43:48.0
+
@@ -16,3 +16,4 @@
## does not apply, needs some care
#svn_819.diff
+no-implicit-declarations.patch
--
Francisco Vilmar Cardoso Ruviaro
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00diff -Nru dvbstreamer-2.1.0/debian/changelog dvbstreamer-2.1.0/debian/changelog
--- dvbstreamer-2.1.0/debian/changelog 2022-08-08 18:22:11.0 +
+++ dvbstreamer-2.1.0/debian/changelog 2024-06-11 16:44:11.0 +
@@ -1,3 +1,12 @@
+dvbstreamer (2.1.0-5.7) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add debian/patches/no-implicit-declarations.patch,
+fix missing declaration of UTF8_nextchar() and typo.
+Thanks to Steve Langasek . (Closes: #1066608)
+
+ -- Francisco Vilmar Cardoso Ruviaro Tue, 11 Jun 2024 16:44:11 +
+
dvbstreamer (2.1.0-5.6) unstable; urgency=medium
* fix lintian no-versioned-debhelper-prerequisite 10
diff -Nru dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch
--- dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 1970-01-01 00:00:00.0 +
+++ dvbstreamer-2.1.0/debian/patches/no-implicit-declarations.patch 2024-06-11 16:43:40.0 +
@@ -0,0 +1,38 @@
+Description: fix missing declaration of UTF8_nextchar() and typo
+Author: Steve Langasek
+Bug-Debian: https://bugs.debian.org/1066608
+Last-Update: 2024-04-09
+Forwarded: no
+
+Index: dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+===
+--- dvbstreamer-2.1.0.orig/src/standard/dvb/sdtprocessor.c
dvbstreamer-2.1.0/src/standard/dvb/sdtprocessor.c
+@@ -46,6 +46,7 @@
+ #include "sdtprocessor.h"
+ #include "dvbtext.h"
+ #include "standard/dvb.h"
++#include "utf8.h"
+
+ /***
+ * Defines *
+Index: dvbstreamer-2.1.0/src/plugins/cam.c
+===
+--- dvbstreamer-2.1.0.orig/src/plugins/cam.c
dvbstreamer-2.1.0/src/plugins/cam.c
+@@ -97,7 +97,7 @@
+
+ if
Bug#1073004: transmission-qt: Switch to qt6
Package: transmission-qt Version: 4.0.6+dfsg-1 Please consider switching transmission-qt to build with Qt6 instead of Qt5. I think the Debian Qt/KDE team is going to try to switch to KDE 6 in time for the next major release of Debian (Debian 13 "Trixie"). Therefore, as long as the transmission qt6 build works reasonably well, I think it would be a better fit than the qt5 build. Thank you, Jeremy Bícha
Bug#1064536: scribus: Please package 1.6.1
Hi, what's the status of getting 1.6 uploaded? Do you need any help? Regards, Daniel
Bug#1073003: ITP: python-django-structlog -- Structured Logging for Django
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-structlog Version : 8.1.0 Upstream Contact: Michael Fladischer * URL : https://github.com/jrobichaud/django-structlog * License : Expat Programming Lang: Python Description : Structured Logging for Django django-structlog is a structured logging integration for Django project using structlog. Logging will then produce additional cohesive metadata on each logs that makes it easier to track events or incidents. I intend to maintain this as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmZogXwbHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqXPoIAJC4pQVllONVB1tF0xZI 0bJ0HGSW9UHtAC3HlkirN5RNS2Ax8VCUGRQjBlXtfDh38CdHuMH6KodCRi0t0mqR 7lnUu7cvK/I//3FGutqKonRAO9RQGA5d+dqLGauATQ0CrRFSU05BMspRAdWWjWHA 4/iaVbl2crB2obgQnCxHFf3Wg/HowdchY2yyMQlgeQgt1SdIzu0ttt+LZKqUaYs/ zM+DHBVL0hRF92JcROvTD/iH5X3DCsCp7upkkvYZ45NyVMBza68lKwGUkIwQh9LJ nrs5oibLlkupbhXPyGMJvcLPf1irbVae2Aw/icWAKAlelHorMqw1cwuBm6EhQbx8 Hvo= =XYb0 -END PGP SIGNATURE-
Bug#1073002: cups: CVE-2024-35235
Source: cups Version: 2.4.7-1.2 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for cups. CVE-2024-35235[0]: | OpenPrinting CUPS is an open source printing system for Linux and | other Unix-like operating systems. In versions 2.4.8 and earlier, | when starting the cupsd server with a Listen configuration item | pointing to a symbolic link, the cupsd process can be caused to | perform an arbitrary chmod of the provided argument, providing | world-writable access to the target. Given that cupsd is often | running as root, this can result in the change of permission of any | user or system files to be world writable. Given the aforementioned | Ubuntu AppArmor context, on such systems this vulnerability is | limited to those files modifiable by the cupsd process. In that | specific case it was found to be possible to turn the configuration | of the Listen argument into full control over the cupsd.conf and | cups-files.conf configuration files. By later setting the User and | Group arguments in cups-files.conf, and printing with a printer | configured by PPD with a `FoomaticRIPCommandLine` argument, | arbitrary user and group (not root) command execution could be | achieved, which can further be used on Ubuntu systems to achieve | full root command execution. Commit | ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the | issue. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-35235 https://www.cve.org/CVERecord?id=CVE-2024-35235 [1] https://www.openwall.com/lists/oss-security/2024/06/11/1 [2] https://github.com/OpenPrinting/cups/commit/a436956f374b0fd7f5da9df482e4f5840fa1c0d2 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1072687: Re: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian
Hello, Thank you, I will return the result to you as soon as the problem occurs again. While I'm at it, do you know if there is a command that can be run to re-execute the automatic discovery of network hardware and devices connected to it, just like it happens at the beginning of the Debian installation process ? By analogy, tasksel allows this regarding the desktop configuration. Best regards. Philippe Message d'origine De : m...@dorfdsl.de Date : 11/06/2024 - 09:49 (E) À : pham...@bluewin.ch, 1072...@bugs.debian.org Objet : Re: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian Am 11.06.2024 um 09:21:55 Uhr schrieb pham...@bluewin.ch: > Tell me exactly which log you need to solve this problem ? Please enable trace logging in NetworkManager. The dmesg doesn't show anything unusual at the first view. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/introduction-to-networkmanager-debugging_configuring-and-managing-networking#temporarily-setting-log-levels-at-run-time-using-nmcli_introduction-to-networkmanager-debugging nmcli general logging level TRACE domains ALL Then use journalctl -u NetworkManager -b -- Gruß Marco Send unsolicited bulk mail to 1718090515mu...@cartoonies.org
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
On Tue, 11 Jun 2024 at 18:05:21 +0200, Helmut Grohne wrote: > I looked for other cases where there would be a versioned dependency on > usr-is-merged and to my surprise dbus was literally the only one. I suspect many of the other packages that migrated from shipping systemd units in /lib/systemd to shipping them in /usr/lib/systemd had less dramatically bad failure modes if the system is still in the unmerged-/usr state - often the single service shipped in that package would not start, but the system as a whole would still boot, leading to a lower expectation that the maintainer must prioritize a response. smcv
Bug#1052714: firmware-amd-graphics: Missing firmware for AMD Radeon RX 7000 series cards
I'd like to ping this issue. Just installed a RX 7700 XT and needed to manually download a bunch of firmware files from the upstream repo to get it to work. I am on unstable, Is there anything a user (me) can do to help here? What is needed to get this package up to date? I saw a little update in the git repo, but it does not look like an update to a newer linux-firmware version? Regards Andre
Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]
Yes, I am transferring a very large number of files. The curiosity is, that it works until debian 12.4 or even with the last update of rsync without these errors. I can split the transfer into smaller parts. I will try and come back with the results. Thanks, Norbert On Tue 11 Jun 2024, Norbert Schulz wrote: If I run rsync without 'z' option the error is: [receiver] exceeded --max-alloc=1073741824 setting (file=fileio.c, line=260) rsync error: error allocating core memory buffers (code 22) at util2.c(80) [receiver=3.2.7] rsync: [generator] write error: Broken pipe (32) rsync: connection unexpectedly closed (18054825 bytes received so far) [generator] Hmm, you could be running into a memory constraint, are you transferring a very large number of files? If so, is it possible to split the transfer up into smaller parts? Thanks, Paul
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
On Tue, Jun 11, 2024 at 03:31:04PM +0100, Simon McVittie wrote: > I don't think that is true. The (single!) change in usrmerge v38 was that > it no longer implements the undocumented opt-out mechanism involving > /etc/unsupported-skip-usrmerge-conversion, therefore any system with > usrmerge (>= 38~) or usr-is-merged (>= 38~) is always going to be > /usr-merged. How could I have missed this! Sorry. > Would the suggested versioned dependency on base-files offer the same? Yes. base-files (>= 13.3~) will directly ship the aliasing links in its data.tar and its preinst will fail if any of these links actually is a real directory (rather than being a symlink or absent both of which mean that after unpack there'll be a symlink). I looked for other cases where there would be a versioned dependency on usr-is-merged and to my surprise dbus was literally the only one. So given that we do not want to duplicate the conflicts into base-files and that dbus actually is the only package wanting to express this, I am now convinced that the originally proposed solution of adding the base-files alternative actually is a good solution for the problem at hand. Helmut
Bug#1073001: buildbot FTBFS: python3-sqlalchemy (<< 1.5) no longer satisfiable
Source: buildbot Version: 3.10.1-2 Severity: serious Tags: ftbfs trixie sid buildbot can no longer be built in unstable as the python3-sqlalchemy package is too new to satisfy buildbot's build dependencies. It likely needs an upload that establishes compatibility with newer sqlalchemy. Helmut
Bug#1072993: please add OnlyShowIn=GNOME;Unity; in com.mattjakeman.ExtensionManager.desktop
On Tue, Jun 11, 2024 at 8:54 AM xiao sheng wen wrote: > The gnome-shell-extension-manager is only use in GNOME, so add field: > > OnlyShowIn=GNOME;Unity; While this could be done as a Debian specific patch, this could be useful to people using other distros too. Could you report this request to the upstream project at https://github.com/mjakeman/extension-manager/issues ? Also, you could try to submit your own git merge request there for this if you want. Note that Unity does not use GNOME Shell at all so you don't want Unity in the OnlyShowIn field. Thank you, Jeremy Bícha
Bug#1070099: RocksDB: Please consider using VCS and host on Salsa for easier collaboration
On Tue, Jun 11, 2024 at 1:39 PM Otto Kekäläinen wrote: > I am travelling and on slow internet. I will review and hopefully help > you with feedback this weekend. To make the browsing easier for you, I've imported the v9.2.1 changes and pushed the repository to GitHub located at: https://github.com/gcsideal/rocksdb Hope this helps, Laszlo/GCS
Bug#1073000: ssh-askpass-gnome: No longer visually prompted to touch security key after upgrading to Bookworm
Package: ssh-askpass-gnome Version: 1:9.2p1-2+deb12u2 Severity: normal X-Debbugs-Cc: e.batek+deb...@itkaufmann.at Dear Maintainer, After upgrading my system from Bullseye to Bookworm, I’m no longer visually prompted to touch an attached security key (e.g. YubiKey) to confirm SSH logins etc. Instead the app just waits with no visual indicator that it expects user interaction. Luckily my YubiKey has an LED that blinks in this state, but apart from that there’s nothing that distinguishes the situation from a hanging program. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ssh-askpass-gnome depends on: ii libc6 2.36-9+deb12u7 ii libglib2.0-02.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii openssh-client 1:9.2p1-2+deb12u2 ssh-askpass-gnome recommends no packages. ssh-askpass-gnome suggests no packages. -- no debconf information
Bug#1054367: cjs: Move to mozjs115
Am 11.06.24 um 17:33 schrieb Fabio Fantoni: About autoconf2.13 I don't see it in cjs build-deps, I suppose you got confused with mozjs, or am I wrong? You are right, I got confused.
Bug#1072689: can be closed
ne'er mind, turns out the mouse was FUBAR. never knew that could happen, but there ya go.
Bug#1054367: cjs: Move to mozjs115
Il 11/06/2024 17:01, Bastian Germann ha scritto: Control: tags -1 fixed-upstream Please import the latest release 6.2.0, which has this integrated. Don't forget to remove autoconf2.13 from the Build-Depends. Hi, when I'll have time I'll start to upload it to experimental, I don't have time to test it recently but if someone want start to test it will be available in experimental. I also not had time to check all cinnamon development recently (but only something), I don't know if it require also change in cinnamon (so will need also new cinnamon now in development, and probably will enter in beta shortly, or backports of some commits), is probable, like previous rebase that even if not big as previous required some changes in cinnamon. For now I did only a very fast look to cinnamon git history I didn't found commits that seems related to cjs. About autoconf2.13 I don't see it in cjs build-deps, I suppose you got confused with mozjs, or am I wrong? OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072999: RM: gcc-3.3 -- RoQA; orphaned; leaf pkg; build-depends on autoconf2.13
Package: ftp.debian.org User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 + src:gcc-3.3 gcc-3.3 is an orphaned leaf package. It was kept around for old (non-free) binaries that depend on libstdc++5. There is now a compelling reason to remove it, i.e., not to block autoconf2.13 removal. All other autoconf2.13 reverse build deps have at least one release with newer autoconf now and are going to move eventually.
Bug#1072998: Black screen on host during vbox manager startup
Package: virtualbox Version: 7.0.18-dfsg-1+b1 Launching virtualbox manager causes host screen to blink black (like disabling monitor for a sec.). This behavior was observed under wayland/xwayland with kernel 6.7.12 with UHD Graphics 630 - i915 module.
Bug#1070815: libdrm-intel1 should be compiled for arm64
Control: reopen -1 Control: severity -1 serious Control: tags -1 +ftbfs -patch After this change, libdrm is failing to build on arm64. Build log excerpt dh_install: warning: Cannot find (any matches for) "usr/lib/*/libdrm_intel.so.1*" (tried in ., debian/tmp) dh_install: warning: libdrm-intel1 missing files: usr/lib/*/libdrm_intel.so.1* Full build log - Click Build-Attempted at https://buildd.debian.org/status/package.php?p=libdrm Thank you, Jeremy Bícha
Bug#1033839: Packaging docker 24.0.9, update gotest.tools to 3.5.1-1
Hello Arnauld, I created the changes for updating gotest.tools to 3.5.1. I created a fork and pushed to badrikesh/gotest-3.5.1 branch. Please review the above link: https://salsa.debian.org/badrikesh/gotest.tools/-/tree/badrikesh/gotest-3.5.1?ref_type=heads After the update I ran the ratt test as suggested, Here's the result: ``` trixie@debian:~/update-gotest-tools$ ~/go/bin/ratt gotest.tools_3.5.1-1_amd64.changes 13:49:59 [47/47] 2024/06/11 12:45:02 Loading changes file "gotest.tools_3.5.1-1_amd64.changes" 2024/06/11 12:45:02 - 1 binary packages: golang-github-gotestyourself-gotest.tools-dev 2024/06/11 12:45:02 Corresponding .debs (will be injected when building): 2024/06/11 12:45:02 golang-github-gotestyourself-gotest.tools-dev_3.5.1-1_all.deb 2024/06/11 12:45:02 Setting -dist=sid (from .changes file) 2024/06/11 12:45:02 Figuring out reverse build dependencies using dose-ceve(1). This might take a while 2024/06/11 12:45:24 Found 40 reverse build dependencies 2024/06/11 12:45:24 Setting -sbuild_dist=unstable (from .changes file) 2024/06/11 12:45:24 Building package 1 of 40: go-containerregistry 2024/06/11 12:46:25 Building package 2 of 40: crowdsec 2024/06/11 12:49:01 Building package 3 of 40: distrobuilder 2024/06/11 12:50:17 Building package 4 of 40: golang-github-containers-storage 2024/06/11 12:52:46 Building package 5 of 40: golang-github-openshift-imagebuilder 2024/06/11 12:53:45 Building package 6 of 40: golang-github-containerd-stargz-snapshotter 2024/06/11 12:55:55 Building package 7 of 40: oci-seccomp-bpf-hook 2024/06/11 12:57:08 Building package 8 of 40: golang-github-mudler-docker-companion 2024/06/11 12:57:56 Building package 9 of 40: golang-github-crowdsecurity-go-cs-bouncer 2024/06/11 12:58:54 Building package 10 of 40: golang-github-containers-psgo 2024/06/11 12:59:38 Building package 11 of 40: golang-oras-oras-go 2024/06/11 13:00:32 Building package 12 of 40: libpod 2024/06/11 13:04:12 Building package 13 of 40: golang-github-moby-term 2024/06/11 13:04:38 Building package 14 of 40: golang-github-checkpoint-restore-checkpointctl 2024/06/11 13:05:29 Building package 15 of 40: gotestsum 2024/06/11 13:06:06 Building package 16 of 40: prometheus 2024/06/11 13:12:51 Building package 17 of 40: golang-github-optiopay-kafka 2024/06/11 13:13:44 Building package 18 of 40: singularity-container 2024/06/11 13:17:38 Building package 19 of 40: golang-github-sigstore-sigstore 2024/06/11 13:18:52 Building package 20 of 40: prometheus-postfix-exporter 2024/06/11 13:19:49 Building package 21 of 40: skopeo 2024/06/11 13:21:18 Building package 22 of 40: gitlab-ci-multi-runner 2024/06/11 13:22:18 building gitlab-ci-multi-runner failed: exit status 2 2024/06/11 13:22:18 Building package 23 of 40: rootlesskit 2024/06/11 13:23:05 Building package 24 of 40: containerd 2024/06/11 13:25:34 Building package 25 of 40: docker.io 2024/06/11 13:31:38 Building package 26 of 40: golang-github-containers-image 2024/06/11 13:33:13 Building package 27 of 40: crowdsec-firewall-bouncer 2024/06/11 13:34:17 Building package 28 of 40: golang-github-containers-buildah 2024/06/11 13:37:06 Building package 29 of 40: golang-github-samalba-dockerclient 2024/06/11 13:37:59 Building package 30 of 40: golang-k8s-sigs-release-utils 2024/06/11 13:38:47 Building package 31 of 40: crowdsec-custom-bouncer 2024/06/11 13:39:50 Building package 32 of 40: golang-github-crc-org-crc 2024/06/11 13:41:02 Building package 33 of 40: skeema 2024/06/11 13:41:55 Building package 34 of 40: golang-github-fsouza-go-dockerclient 2024/06/11 13:42:47 Building package 35 of 40: open-vm-tools 2024/06/11 13:45:55 Building package 36 of 40: golang-github-sylabs-sif 2024/06/11 13:46:57 Building package 37 of 40: golang-github-crewjam-saml 2024/06/11 13:47:35 Building package 38 of 40: golang-github-containers-common 2024/06/11 13:49:16 Building package 39 of 40: golang-github-tonistiigi-fsutil 2024/06/11 13:50:03 Building package 40 of 40: tty-share 2024/06/11 13:50:43 1 packages failed the first pass; you can rerun ratt only for them passing the option -include '^(gitlab-ci-multi-runner)$' 2024/06/11 13:50:43 Build results: 2024/06/11 13:50:43 PASSED: golang-github-containers-psgo 2024/06/11 13:50:43 PASSED: containerd 2024/06/11 13:50:43 PASSED: golang-github-crewjam-saml 2024/06/11 13:50:43 PASSED: golang-github-crc-org-crc 2024/06/11 13:50:43 PASSED: golang-github-containers-common 2024/06/11 13:50:43 PASSED: distrobuilder 2024/06/11 13:50:43 PASSED: golang-oras-oras-go 2024/06/11 13:50:43 PASSED: libpod 2024/06/11 13:50:43 PASSED: golang-github-containers-image 2024/06/11 13:50:43 PASSED: crowdsec-firewall-bouncer 2024/06/11 13:50:43 PASSED: tty-share 2024/06/11 13:50:43 PASSED: golang-github-containerd-stargz-snapshotter 2024/06/11 13:50:43 PASSED: oci-seccomp-bpf-hook 2024/06/11 13:50:43 PASSED: golang-github-optiopay-kafka 2024/06/11 13:50:43 PASSED: golang-github-sigstore-sigstore 2024/06/11 13:50:43 PASSED: rootlesskit 2024/06/11
Bug#1054367: cjs: Move to mozjs115
Control: tags -1 fixed-upstream Please import the latest release 6.2.0, which has this integrated. Don't forget to remove autoconf2.13 from the Build-Depends.
Bug#1072183: fenics-dolfinx: FTBFS with nanobind 2.0
Hi, * Francesco Ballarin [2024-06-11 09:53]: Hopefully there won't be future ABI breaks that aren't aligned with a fenics-basix/fenics-dolfinx release, but if there will be we will look forward to any suggestion from you on how to come up with a more elegant solution. I gave it a bit of thought and tightened the dependency from python3-nanobind on nanobind-dev, so both packages will be installed with the same version. I also added a pydist override so that python3-nanobind will automatically emit a versioned dependency (>= 2, << 3), so you do not have to do that downstream any more. I'm not 100% certain that it is enough, but it should definitely help. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯
Bug#1030668: dinstall could run more often (every hour?)
Hi, On Mon, 6 Feb 2023 12:45:17 +0100 Bastian Blank wrote: > > The bigger picture is: packages are not part of the Debian build > > infrastructure (buildd, piuparts, etc) for hours and this blocks many > > development activities. > > They are. The buildd use incoming.d.o with accepted packages as > additional source. maybe let me use this topic to ask a maybe a little bit tangential question. For a few days I have been involved in fixing the autopkgtest of my package mmdebstrap to make it work with Helmut's recent merged-/usr uploads of bash, dash, util-linux and glibc. My workflow is: fix a thing, upload, see if ci.d.n is happy, fix bug, repeat. This takes multiple dinstalls and thus multiple days of work for me. This is not a nice experience for me as a contributor because instead of being able to sit down and fix the thing, I have to spread my work across multiple days. I'm aware that there are multiple possible fixes to this: 1. add support for using incoming as a apt source to ci.d.n 2. set up my own copy of ci.d.n (difficult as i'm on a slow arm cortex a53 system with 3.7 GB ram) 3. ask far a shell on ci.d.n from elbrus 4. add support for apt pinning to autopkgtest on salsaci I must admit I'm not that frustrated by the six hour dinstall time as while it is not optimal, it is something I find myself having accepted as the way that Debian just works. So whatever. But here comes my tangential question: I have my package (mmdebstrap) which seems to require overall 29 seconds to build on the builds. The buildd queues are empty. I upload an hour before the next dinstall. Then it takes 20 minutes for the ACCEPTED mail to arrive after my dput (why this long?) and then it takes another half an hour before the buildds even register that there is a new binary package to be built (why this long?), then it builds in 29 seconds, 10 minutes before the next dinstall it's finished. It still misses it. So my question: for a package that takes 29 seconds to build and empty buildd queues. How long before the official dinstall times do I have to upload so that my package makes it? It is very frustrating to upload an hour in advance, plan my time for the day accordingly, only to then see it fail. This waiting time and unpredictability is what makes Debian development extremely frustrating for me. I do not understand why processing such a tiny package is taking a full hour. Maybe things would be a bit better if I would at least be able to predict what is going on at a given time. I literally told my family: hey can I have some free time later to work on Debian and now it's not going to happen. This is not a problem of only 4 dinstalls per day but it's a problem of not knowing what is going on and why. Maybe this can be improved? Thanks! cheers, josch signature.asc Description: signature
Bug#1072756: dbus: should depend on recent base-files, and only versioned on usr-is-merged as fallback
On Tue, 11 Jun 2024 at 13:16:21 +0200, Helmut Grohne wrote:
> the only important features
> (from a client package pov) that usr-is-merged gained with higher
> versions are those Conflicts.
I don't think that is true. The (single!) change in usrmerge v38 was that
it no longer implements the undocumented opt-out mechanism involving
/etc/unsupported-skip-usrmerge-conversion, therefore any system with
usrmerge (>= 38~) or usr-is-merged (>= 38~) is always going to be
/usr-merged.
This means that any package with a dependency on usr-is-merged (>= 38~)
can safely assume that it will never be installable on systems where
/etc/unsupported-skip-usrmerge-conversion has been used to delay the
conversion to merged-/usr, even during a partial upgrade, and therefore
it does not need to be defensively programmed so that it will either
work as intended or fail cleanly with an obvious error message on
unmerged-/usr.
Specifically, either the system is already /usr-merged, or
usr-is-merged.preinst will have already failed (somewhat cleanly) and
the dependency will not be met. Either way, the new dbus will not get
configured and therefore any failure is somewhat clearly not a dbus bug.
Would the suggested versioned dependency on base-files offer the same?
I could have implemented this without an external dependency by
open-coding a check for merged /usr and graceful failure into dbus.preinst
or dbus.postinst, similar to the one in usr-is-merged.preinst; but this
didn't really seem like it should be my job, and I try to minimize the
amount of load-bearing shell script that I'm responsible for.
> For dbus, it was added via #1054650, but the bug log does not express
> why the version restriction was needed.
I had hoped that the extensive changelog entry justifying this change
would be sufficiently clear, but in case it wasn't:
The reporter of #1054650 was running in the unsupported configuration
of a post-bookworm system with unmerged /usr, presumably having used
/etc/unsupported-skip-usrmerge-conversion to suppress conversion from
unmerged to merged /usr.
Before dbus 1.14.10-2, even though this scenario was explicitly
unsupported, in practice it worked anyway. After dbus 1.14.10-2,
the unsupported scenario caused boot to fail, which was reported as
a Severity: critical bug in dbus ("breaks the entire system").
I considered #1054650 to be a non-bug, because it is an unsupported
scenario, and creating that scenario must have required acknowledging
this by creating a file with "unsupported" in its name; but I was not
willing to make myself responsible for closing a series of duplicate
high-severity bug reports, with an increased likelihood of being
flamed by angry unmerged-/usr users with each duplicate, and that's
what I expected would happen if I didn't add some sort of mitigation
promptly (especially if 1.14.10-2 had reached testing).
As a result of our dependency system being as elaborate as it is,
there tends to be a perception that if it has been possible to install
a package successfully, then any failure to work as intended after that
is automatically a high-severity bug that demands a priority response
from the maintainer, even if it involves scenarios that have been widely
publicized as unsupported. The addition of
Depends: usr-is-merged (>= 38~) in dbus was intended to ensure that the
unsupported scenario could not happen, instead of creating the perception
that dbus was irretrievably broken and it was my fault.
Being told that I am personally responsible for critically harming Debian
is not an aspect of the maintainer role that I enjoy, even if it isn't
actually true, and I try to minimize it if I can. I'm sorry if my attempts
to protect myself have caused additional work for others.
> it feels right to me that dbus pulls the physical
> usr-is-merged package whose purpose at this time is forcing other
> packages off the system
>From my point of view, forcing other packages broken by merged-/usr off
the system is only a side-effect, and the purpose of this dependency
was to redirect the blame for "package does not work on an unsupported
non-/usr-merged system" to whoever set up the unsupported situation and
is now continuing to rely on it.
smcv
Bug#1072142:
Same issue here, fixed by installing libnvidia-egl-wayland1 and rebooting, should some part of the driver depend on this package?
Bug#1072997: rust-csv: please update to v1.3
Source: rust-csv Version: 1.2.2-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to at least v1.3.0. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmZoV20ACgkQLHwxRsGg ASEFCw//Vl76LTw0qYfs0mfzrzGIWU7YsiEKbEiAq5hEo5hyn+ANV2MKxrRKOVef i9mp1iDOLhmDxo6IJOrzTJ1QsIcNMJtcTZWMFApqDbAJZoaEh/QRK7cp6CmTUcFK tzjuEQehhy6xm4psGc3/CMSdl9vDd0b1ufGJJxalzEk920I8jtEyGzMHuWO2Fge4 HhH4lf/ETMdxpDAglNOe+TZJ3PYlgLBcGrOe7JCr/mdiXABVWWNiDub4ibC8Fuyy NTqpGtINrX29DrsJ/P5prmOieonZm4B8at6ajN4A1LLnW51aAD3monlw5M6L2wzd vvTBSx2wjuiuhPUV1Qrfla2zo4lKhmOVr9smgm74axl5UmVgwLSN5vt9wju+VSNp 8wTtB3s0DfZUmB+b7/ZYmc1O5Jy3vVOe35UEwZmCkAFmhi6byiJ+6e83dB7NYpEe t817PpdE36sqVgQQj4wV8W3XUqNnDdzGXBRhkSK9FNYvXydWJzgsLZy67pItgPe/ o87ruOtriD0RME7Wbi4v2hw6BVH3HXah0jacOHBhiO97Pj3MNdxpm20QZL/88C+i YPeW4QWOqJi5IWJj6FzdVkDuCd1XhBDwxBJchv/ClPhktW+dPDnoH5fJ02V+gTgp exG+I9UIOMesVsIMy6tgxKNocloaZUHLGBnokVa41iut/VDAqUc= =6uCz -END PGP SIGNATURE-
Bug#1029140: cron-apt refuses to run when RUNSLEEP is set
On Mon, Jun 10, 2024 at 11:02:30PM +0200, Ola Lundqvist wrote: > Sorry, I meant to run with dash -x. Or do dash not have that option? It has this option. But I see a problem in cron-apt using bashisms while using the /bin/sh shebang line. I don't know whether this have to do with this, bug, but it should be fixed anyway. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
