Bug#1069679: Debian Bugs information: logs for Bug#1069679
Hi Emilio, Laurent, Hector, et al. On Fr 24 Mai 2024 08:48:04 CEST, Debian Bug Tracking System wrote: Source: ofono X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for ofono. CVE-2023-2794[0]: | A flaw was found in ofono, an Open Source Telephony on Linux. A | stack overflow bug is triggered within the decode_deliver() function | during the SMS decoding. It is assumed that the attack scenario is | accessible from a compromised modem, a malicious base station, or | just SMS. There is a bound check for this memcpy length in | decode_submit(), but it was forgotten in decode_deliver(). https://bugzilla.redhat.com/show_bug.cgi?id=2255387 https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=a90421d8e45d63 b304dc010baba24633e7869682 https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=7f2adfa22fbae8 24f8e2c3ae86a3f51da31ee400 https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=07f48b23e3877e f7d15a7b0b8b79d32ad0a3607e https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=8fa1fdfcb54e1e db588c6a5e260b065a39c9 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-2023-2794 https://www.cve.org/CVERecord?id=CVE-2023-2794 Please adjust the affected versions in the BTS as needed. Is any of you guys planning to fix ofono in Debian unstable anytime soon? Ofono is a direct dependency of the Lomiri Operating Environment and currently two RC bugs in ofono are endangering Lomiri to be removed from testing. If noone plans to fix Ofono in Debian within the next 1-2 weeks, I'd like to do a team upload. In that case, could any of you give me access to https://salsa.debian.org/telepathy-team (or just the ofono repo in there). Thanks+Greets, Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpGA8WD3JJxb.pgp Description: Digitale PGP-Signatur
Bug#1071711: libecal-2.0-2: No -dev package for libecal-2.0-2
On Thu, 23 May 2024 22:43:49 -0500 E Harris wrote: > Package: libecal-2.0-2 > Version: 3.46.4-2 > Severity: normal > > It appears that there is no -dev package for libecal-2.0. > How to build apps that depend on it? https://packages.debian.org/bookworm/libecal2.0-dev Is that what you are looking for? Regards, Patrice
Bug#1071716: RM: python3-dipy-lib [s390x] -- ROM; build-dep not satifiable anymore
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: d...@packages.debian.org, cru...@debian.org Control: affects -1 + src:dipy Dear FTP Team, Please remove the s390x binary package python3-dipy-lib, as the build-dependency "python3-tables-lib" is no longer available for s390x in testing nor unstable. I ran `ssh mirror.ftp-master.debian.org "dak rm --architecture=s390x -Rn python3-dipy-lib"` and got back the following response: > W: -a/--architecture implies -p/--partial. > Nothing to do. Thanks! OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071715: ITP: pytest-httpx -- Intercept and mock HTTPX requests in pytest
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-httpx Version : 0.30.0 Upstream Author : Colin Bounouar * URL : https://github.com/Colin-b/pytest_httpx * License : MIT Programming Lang: Python Description : Intercept and mock HTTPX requests in pytest Provides an `httpx_mock` fixture for the pytest framework. This fixture allows you to intercept and mock HTTP requests made using the HTTPX library. It supports both synchronous and asynchronous HTTPX requests, enabling you to define custom responses, including JSON bodies, headers, status codes, and more. . This library is useful for testing scenarios where making actual network calls is not feasible or desired. You can simulate various HTTP responses and conditions, ensuring your code handles them correctly. Additionally, pytest-httpx supports dynamic responses via callbacks, request verification, and partial mocking, allowing specific requests to go through unmocked. I plan to maintain this package as part of the Python team.
Bug#1071714: python-openstackclient: please (re-)remove extraneous dependency on python3-mock
Source: python-openstackclient Version: 6.6.0-3 Severity: normal Dear Maintainers, This time it looks like it is gone for good. Greetings >python-openstackclient (5.4.0-1) experimental; urgency=medium > > * New upstream release. > * Re-added python3-mock as build-depends. > > -- Thomas Goirand Mon, 05 Oct 2020 10:29:21 +0200 tchet@quieter:/tmp/python-openstackclient$ grep mock -r | grep -e import -e debian | head grep: .git/objects/pack/pack-6354ab6767c7cd8dfe74c9ab3ead6994a26041ca.pack : fichiers binaires correspondent debian/changelog: * Re-added python3-mock as build-depends. debian/control: python3-mock, debian/control: python3-requests-mock, doc/source/contributor/developing.rst:from unittest import mock openstackclient/tests/unit/api/test_object_store_v1.py:from unittest import mock
Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate
Dear Neil,
I've applied your patch, and since then there are no lockups. Before
that my application reported a lockup in a minute or two, now it has
been running for half an hour, and still running.
Thanks,
Richard
2024-05-24 01:31 időpontban NeilBrown ezt írta:
On Fri, 24 May 2024, Richard Kojedzinszky wrote:
Dear devs,
I am attaching a stripped down version of the little program which
triggers the bug very quickly, in a few minutes in my test lab. It
turned out that a single NFS mountpoint is enough. Just start the
program giving it the NFS mount as first argument. It will chdir
there,
and do file operations, which will trigger a lockup in a few minutes.
I couldn't get the go code to run. But then it is a long time since I
played with go and I didn't try very hard.
If you could provide simple instructions and a list of package
dependencies that I need to install (on Debian), I can give it a try.
Or you could try this patch. It might help, but I don't have high
hopes. It adds some memory barriers and fixes a bug which would cause
a
problem if memory allocation failed (but memory allocation never
fails).
NeilBrown
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index ac505671efbd..5bcc0d14d519 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry,
unsigned int flags,
} else {
/* Wait for unlink to complete */
wait_var_event(&dentry->d_fsdata,
- dentry->d_fsdata != NFS_FSDATA_BLOCKED);
+ smp_load_acquire(&dentry->d_fsdata) !=
NFS_FSDATA_BLOCKED);
parent = dget_parent(dentry);
ret = reval(d_inode(parent), dentry, flags);
dput(parent);
@@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry
*dentry)
spin_unlock(&dentry->d_lock);
error = nfs_safe_remove(dentry);
nfs_dentry_remove_handle_error(dir, dentry, error);
- dentry->d_fsdata = NULL;
+ smp_store_release(&dentry->d_fsdata, NULL);
wake_up_var(&dentry->d_fsdata);
out:
trace_nfs_unlink_exit(dir, dentry, error);
@@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct
nfs_renamedata *data)
{
struct dentry *new_dentry = data->new_dentry;
- new_dentry->d_fsdata = NULL;
+ smp_store_release(&new_dentry->d_fsdata, NULL);
wake_up_var(&new_dentry->d_fsdata);
}
@@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct
inode *old_dir,
task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
must_unblock ? nfs_unblock_rename : NULL);
if (IS_ERR(task)) {
+ if (must_unlock) {
+ smp_store_release(&new_dentry->d_fsdata, NULL);
+ wake_up_var(&new_dentry->d_fsdata);
+ }
error = PTR_ERR(task);
goto out;
}
Bug#1071713: python-os-collect-config: please drop extraneous dependency on python3-mock
Source: python-os-collect-config Version: 13.1.0-2 Severity: normal Dear Maintainers, This package has switches to unittest.mock. Greetings tchet@quieter:/tmp/python-os-collect-config$ grep mock -r | grep -e import -e debian debian/control: python3-mock, os_collect_config/tests/test_collect.py:from unittest import mock os_collect_config/tests/test_config_drive.py:from unittest import mock os_collect_config/tests/test_ec2.py:from unittest import mock os_collect_config/tests/test_zaqar.py:from unittest import mock tchet@quieter:/tmp/python-os-collect-config$
Bug#1037133:
Hello, I want to give an update of the situation because I migrated from Debian 11 to 12 (old-stable to stable). Stable now has ownCloud client 2.11.0. The described bug is still in this version. As upstream reported (https://github.com/owncloud/client/issues/10071) it might be fixed in 2.11.1. I am just a user and don't know much about Debian Maintenance. From my perspective it is not "normal" bug. It is a problem that significantly restricts usability and functionality. If it is not possible to fix this in current stable because of policies it would help much if there would be an stable-backports package with 2.11.1 or later. I am aware that this is not an easy thing. I just want to mention. Thanks in advance, Christian Buhtz
Bug#1071712: RM: ros-bond-core/experimental -- ROM; not needed for t64 transition
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ros-bond-c...@packages.debian.org Control: affects -1 + src:ros-bond-core User: ftp.debian@packages.debian.org Usertags: remove
Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate
Dear Neil,
I've stripped the code more, which still triggers the bug for me. On
Bookworm, to get the binary, simply:
$ sudo apt-get install golang
$ go build .
And then give it an nfs mountpoint, e.g.:
$ ./ds /mnt/nfs
Meanwhile, I will try your patch too.
Regards,
Richard
2024-05-24 01:31 időpontban NeilBrown ezt írta:
On Fri, 24 May 2024, Richard Kojedzinszky wrote:
Dear devs,
I am attaching a stripped down version of the little program which
triggers the bug very quickly, in a few minutes in my test lab. It
turned out that a single NFS mountpoint is enough. Just start the
program giving it the NFS mount as first argument. It will chdir
there,
and do file operations, which will trigger a lockup in a few minutes.
I couldn't get the go code to run. But then it is a long time since I
played with go and I didn't try very hard.
If you could provide simple instructions and a list of package
dependencies that I need to install (on Debian), I can give it a try.
Or you could try this patch. It might help, but I don't have high
hopes. It adds some memory barriers and fixes a bug which would cause
a
problem if memory allocation failed (but memory allocation never
fails).
NeilBrown
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index ac505671efbd..5bcc0d14d519 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry,
unsigned int flags,
} else {
/* Wait for unlink to complete */
wait_var_event(&dentry->d_fsdata,
- dentry->d_fsdata != NFS_FSDATA_BLOCKED);
+ smp_load_acquire(&dentry->d_fsdata) !=
NFS_FSDATA_BLOCKED);
parent = dget_parent(dentry);
ret = reval(d_inode(parent), dentry, flags);
dput(parent);
@@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry
*dentry)
spin_unlock(&dentry->d_lock);
error = nfs_safe_remove(dentry);
nfs_dentry_remove_handle_error(dir, dentry, error);
- dentry->d_fsdata = NULL;
+ smp_store_release(&dentry->d_fsdata, NULL);
wake_up_var(&dentry->d_fsdata);
out:
trace_nfs_unlink_exit(dir, dentry, error);
@@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct
nfs_renamedata *data)
{
struct dentry *new_dentry = data->new_dentry;
- new_dentry->d_fsdata = NULL;
+ smp_store_release(&new_dentry->d_fsdata, NULL);
wake_up_var(&new_dentry->d_fsdata);
}
@@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct
inode *old_dir,
task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
must_unblock ? nfs_unblock_rename : NULL);
if (IS_ERR(task)) {
+ if (must_unlock) {
+ smp_store_release(&new_dentry->d_fsdata, NULL);
+ wake_up_var(&new_dentry->d_fsdata);
+ }
error = PTR_ERR(task);
goto out;
}
ds.tar
Description: Unix tar archive
Bug#1049806: mozc: Fails to build binary packages again after successful build
Control: tags -1 unreproducible Hi, > > /usr/lib/x86_64-linux-gnu/libprotobuf.a(arena.o): relocation > > R_X86_64_TPOFF32 against symbol > > `_ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E' can > > not be used when making a shared object; recompile with -fPIC > > /usr/bin/ld: failed to set dynamic section sizes: bad value > > collect2: error: ld returned 1 exit status ninja: build stopped: I've not encounted this issue during try to fix the source after build issue. [1] So, it seems that the situation was changed since then (16 Aug 2023). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045435 Regards,
Bug#1071711: libecal-2.0-2: No -dev package for libecal-2.0-2
Package: libecal-2.0-2 Version: 3.46.4-2 Severity: normal It appears that there is no -dev package for libecal-2.0. How to build apps that depend on it? -- System Information: Debian Release: 12.5 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) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libecal-2.0-2 depends on: ii libc6 2.36-9+deb12u7 ii libcamel-1.2-643.46.4-2 ii libedataserver-1.2-27 3.46.4-2 ii libglib2.0-0 2.74.6-2+deb12u2 ii libical3 3.0.16-1+b1 libecal-2.0-2 recommends no packages. libecal-2.0-2 suggests no packages. -- no debconf information
Bug#1017558: boost1.74: diff for NMU version 1.74.0+ds1-21.1
Hi, no, it is not possible to change the default version in stable release. It is only possible to fix some critical bugs. Best regards Anton
Bug#1071710: objdump.1: some remarks about this man page
Package: binutils-common
Version: 2.42-4
Severity: minor
Dear Maintainer,
here are some notes for the manual.
-.-
The man page is created by Pod::Man (Pod::Simple).
A new version of 'Pod::Man' is needed.
The source file and the processing command may need to be fixed.
-.-
The difference between the formatted outputs can be seen with:
nroff -man >
nroff -man >
diff -u
and for groff, using
"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "
instead of "nroff -man"
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 objdump.1": (possibly shortened list)
mandoc: objdump.1:241:68: STYLE: whitespace at end of input line
mandoc: objdump.1:531:98: STYLE: input text line longer than 80 bytes: will be
overridden i...
mandoc: objdump.1:545:98: STYLE: input text line longer than 80 bytes: will see
\f(CW\*(C`r...
mandoc: objdump.1:618:84: STYLE: input text line longer than 80 bytes: Print
HWR (hardware ...
mandoc: objdump.1:911:65: STYLE: whitespace at end of input line
mandoc: objdump.1:1300:2: WARNING: empty block: RS
-.-.
Remove space characters at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".
241:input file. This option only disassembles those sections which are
911:output from this option can also be restricted by the use of the
-.-.
Change (or include a "FIXME" paragraph about) misused SI (metric)
numeric prefixes (or names) to the binary ones, like Ki (kibi), Mi
(mebi), Gi (gibi), or Ti (tebi), if indicated.
If the metric prefixes are correct, add the definitions or an
explanation to avoid misunderstanding.
801:the \fB=extended\-color\fR argument will add color using 8bit
-.-.
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 reshaped, e.g., after changes.
When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.
This marking is robust, and independent of the position on the line.
It corresponds to "\ " in TeX, and to "@:" in Texinfo.
136:\&\fIobjfile\fR... are the object files to be examined. When you
-.-.
Strings longer than 3/4 of a standard line length (80)
94
\fB\-\-dwarf\fR[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=str\-offsets,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links]]
143
\&\fB\-a,\-d,\-D,\-e,\-f,\-g,\-G,\-h,\-H,\-p,\-P,\-r,\-R,\-s,\-S,\-t,\-T,\-V,\-x\fR
must be given.
814 .IP \fB\-\-disassembler\-color=extened|extended\-color|extened\-colour\fR 4
836 .IP
\fB\-\-dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=str\-offsets,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow\-links]\fR
4
837 .IX Item
"--dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=str-offsets,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow-links]"
1327 .IP \fB\-\-unicode=\fR\fI[default|invalid|locale|escape|hex|highlight]\fR 4
-.-.
Wrong distance between sentences.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
190:mangling styles. The optional demangling style argument can be used to
782:absolute paths. It has no effect without \fB\-\-prefix=\fR\fIprefix\fR.
-.-.
Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.
objdump.1: line 94 length 229
\fB\-\-dwarf\fR[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=str\-offsets,=loc,=Ranges,=pubty
Bug#1071709: cron: Error Since Last Update
Package: cron Version: 3.0pl1-190 Severity: important Dear Maintainer, since the last update I got mails with the following errors: Subject:Cron[ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi /bin/sh: 1: Syntax error: word unexpected Subject:Cron cd / && run-parts --report /etc/cron.hourly Failed to find executable job: No such file or directory Subject:Cron [ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi /bin/sh: 1: Syntax error: word unexpected -- Package-specific info: --- EDITOR: --- /usr/bin/editor: /usr/bin/vim.basic --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 47840 May 23 14:13 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 5 root root 4096 May 21 2022 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 2 root crontab 4096 May 15 2022 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 2 root root 4096 May 23 17:49 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 2 root root 4096 May 23 17:06 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 2 root root 4096 May 23 17:06 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 2 root root 4096 May 23 17:06 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 2 root root 4096 May 23 17:06 /etc/cron.weekly -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 'stable'), (500, 'stable-security'), (500, 'oldstable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 6.8.9-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cron depends on: ii cron-daemon-common 3.0pl1-190 ii init-system-helpers 1.66 ii libc62.39-1 ii libpam-runtime 1.5.3-7 ii libpam0g 1.5.3-7 ii libselinux1 3.5-2+b2 ii sensible-utils 0.0.22 Versions of packages cron recommends: ii postfix [mail-transport-agent] 3.9.0-2 Versions of packages cron suggests: ii anacron2.3-40 pn bat pn checksecurity ii logrotate 3.21.0-2 ii supercat 0.5.7-1 Versions of packages cron is related to: pn libnss-ldap pn libnss-ldapd pn libpam-ldap pn libpam-mount pn nis pn nscd -- no debconf information
Bug#1071007:
Hi! As Sherlock is a private module, I moved it to usr/share according to this policy here: https://www.debian.org/doc/packaging-manuals/python-policy/#programs-shipping-private-modules It is not necessary to __init__py of the package as suggested by Samuel. Thank you everyone for your help! Nilson F. Silva
Bug#1071708: ITP: emacs-dart-mode -- An Emacs major mode for editing Dart files
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-dart-mode Version : 1.0.7+git20240507.ef6cc89 Upstream Author : Google Inc., Brady Trainor * URL or Web page : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ Programming lang: Emacs Lisp Description : An Emacs major mode for editing Dart files This package implements a major-mode for the Dart language, providing basic syntax highlighting and indentation support. I plan to maintain this package within the Debian Emacsen Team .
Bug#1071707: rustc: Add loong64 to the FAILURES_ALLOWED lists in d/rules
Source: rustc Version: 1.71.1+dfsg1-2 Severity: normal Tags: patch User: debian-loonga...@lists.debian.org Usertags: loong64 Dear maintainers, Compiling rustc 1.71 based on llvm-toolchain-16 failed in the Debian loong64 Package Auto-Building environment. The error log is as follows, ``` .. error: could not find native static library `/usr/lib/llvm-16/lib/clang/16/lib/linux/libclang_rt.profile-loongarch64.a`, perhaps an -L flag is missing? Did not run successfully: exit status: 1 .. ``` The full build log can be found at https://buildd.debian.org/status/logs.php?pkg=rustc&ver=1.71.1%2Bdfsg1-2&arch=loong64. Regarding the missing libclang_rt.profile-loongarch64.a file in the libclang-rt-16-dev package, our llvm team will add patches and commit bug for Debian llvm-toolchain-16. Please note that Debian llvm support for loongarch is complete as of llvm-toolchain-17, for example, ``` root@localhost:/home# dpkg -c libclang-rt-16-dev_1%3a16.0.6-27_loong64.deb |grep libclang_rt.profile-loongarch64.a root@localhost:/home# root@localhost:/home# dpkg -c libclang-rt-17-dev_1%3a17.0.6-12_loong64.deb |grep libclang_rt.profile-loongarch64.a -rw-r--r-- root/root 146744 2024-05-04 05:30 ./usr/lib/llvm-17/lib/clang/17/lib/linux/libclang_rt.profile-loongarch64.a root@localhost:/home# dpkg -c libclang-rt-18-dev_1%3a18.1.6-1_loong64.deb |grep libclang_rt.profile-loongarch64.a -rw-r--r-- root/root 150362 2024-05-19 07:27 ./usr/lib/llvm-18/lib/clang/18/lib/linux/libclang_rt.profile-loongarch64.a ``` Compiling rustc 1.71 based on llvm-toolchain-17 failed in our local loong64 ENV. The error message is related to the number of failed test cases, for example, ``` .. Summary: exit code 1, counted 14 tests failed. 10 maximum allowed. Aborting the build. .. ``` We need to add loong64 to the FAILURES_ALLOWED lists in d/rules. Please consider the patch (Signed-off-by: wang...@loongson.cn) I attached. Your opinions are welcome. Thanks, Dandan Zhang diff --git a/rules b/rules index c7b0541..d9a423a 100755 --- a/rules +++ b/rules @@ -335,7 +335,7 @@ endif ifneq (,$(filter $(DEB_BUILD_ARCH), ppc64 s390x)) FAILURES_ALLOWED = 40 endif -ifneq (,$(filter $(DEB_BUILD_ARCH), powerpc powerpcspe riscv64 sparc64 x32)) +ifneq (,$(filter $(DEB_BUILD_ARCH), powerpc powerpcspe riscv64 sparc64 x32 loong64)) FAILURES_ALLOWED = 180 endif FAILED_TESTS = grep "FAILED\|^command did not execute successfully" $(TEST_LOG) | grep -v '^test result: FAILED' | grep -v 'FAILED (allowed)'
Bug#1071521: ukui-screensaver: predictable filenames under /tmp with system()
Hi. This bug is same as1064340. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064340 We will fix it and upload at soon. Thanks. xibowen
Bug#1071699: [debian-mysql] Bug#1071699: mariadb-server: Moved mariadb socket, debian-start reports error connecting to old socket
Thanks for reporting! The lifecycle of /run should always be longer than the process existing. I think /run is cleared only on reboot. Contributions are welcome from you or anybody reading this bug report. If you have a patch (or not ideally Merge Request on Salsa) I am happy to review.
Bug#1071706: networkctl.1: some remarks and editorial changes for this man page
Package: systemd
Version: 255.5-1
Severity: minor
Tags: patch
Dear Maintainer,
here are some notes and editorial fixes for the manual.
The patch is in the attachment.
-.-
The difference between the formatted outputs can be seen with:
nroff -man >
nroff -man >
diff -u
and for groff, using
"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "
instead of "nroff -man"
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 networkctl.1": (possibly shortened list)
mandoc: networkctl.1:2:22: WARNING: missing date, using "": TH
mandoc: networkctl.1:28:2: WARNING: skipping paragraph macro: PP after SH
mandoc: networkctl.1:33:85: STYLE: input text line longer than 80 bytes: for an
introduction ...
mandoc: networkctl.1:35:2: WARNING: skipping paragraph macro: PP after SH
mandoc: networkctl.1:91:138: STYLE: input text line longer than 80 bytes: One
of the bonding o...
mandoc: networkctl.1:98:128: STYLE: input text line longer than 80 bytes: The
link has carrier...
mandoc: networkctl.1:105:185: STYLE: input text line longer than 80 bytes: The
link has carrier...
mandoc: networkctl.1:112:82: STYLE: input text line longer than 80 bytes: The
link has carrier...
mandoc: networkctl.1:119:176: STYLE: input text line longer than 80 bytes: The
link has carrier...
mandoc: networkctl.1:185:149: STYLE: input text line longer than 80 bytes: Show
information abo...
mandoc: networkctl.1:188:86: STYLE: input text line longer than 80 bytes: When
no links are sp...
mandoc: networkctl.1:211:219: STYLE: input text line longer than 80 bytes: In
the overall netwo...
mandoc: networkctl.1:278:105: STYLE: input text line longer than 80 bytes: Show
numerical addre...
mandoc: networkctl.1:332:116: STYLE: input text line longer than 80 bytes:
Renew dynamic config...
mandoc: networkctl.1:339:126: STYLE: input text line longer than 80 bytes: Send
a FORCERENEW me...
mandoc: networkctl.1:346:104: STYLE: input text line longer than 80 bytes:
Reconfigure network ...
mandoc: networkctl.1:350:97: STYLE: input text line longer than 80 bytes:
corresponding to the...
mandoc: networkctl.1:365:88: STYLE: input text line longer than 80 bytes: file
is found, then ...
mandoc: networkctl.1:382:100: STYLE: input text line longer than 80 bytes:
files\&. If no netwo...
mandoc: networkctl.1:384:181: STYLE: input text line longer than 80 bytes: "@",
it will be trea...
mandoc: networkctl.1:391:85: STYLE: input text line longer than 80 bytes: is
specified, edit t...
mandoc: networkctl.1:419:2: WARNING: skipping paragraph macro: PP after SH
mandoc: networkctl.1:479:83: STYLE: input text line longer than 80 bytes: (for
the shortest po...
mandoc: networkctl.1:506:2: WARNING: skipping paragraph macro: PP after SH
mandoc: networkctl.1:509:2: WARNING: skipping paragraph macro: PP after SH
-.-.
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 reshaped, e.g., after changes.
When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.
This marking is robust, and independent of the position on the line.
It corresponds to "\ " in TeX, and to "@:" in Texinfo.
203: Gateway: 10\&.193\&.11\&.1 (CISCO SYSTEMS, INC\&.) on eth0
215:All links have unknown online status (i\&.e\&. there are no required
links)\&.
260:enp0s25 00:e0:4c:00:00:00 GS1900
\&.\&.b\&.\&.\&.\&.\&.\&.\&.\&. 2 Port #2
332:Renew dynamic configurations e\&.g\&. addresses received from DHCP
server\&. Takes interface name or index number\&.
498:Do not print the legend, i\&.e\&. column headers and the footer with
hints\&.
-.-.
Wrong distance between sentences.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
N.B
The number of lines affected is too large to be in the pa
Bug#810018: New Essential package procps-base
On Tue, 14 Nov 2023 10:40:33 + Luca Boccassi wrote: > On Tue, 14 Nov 2023 at 10:13, Helmut Grohne wrote: > > So in essence, you asked for changing the pidof implementation and > > Andreas and me try to turn this into a much bigger quest of making it > > non-essential. While these matters are related, they can be done > > independently in principle and if you do not want to take on the > > non-essential part, I fear I see little alternatives to that procps-base > > proposal. > > Yeah, let's not make this task impossibly huge and lengthy, please. > Using the same implementation as every other distro has immediate > benefits for everybody, packagers and users. Rearranging the packaging > details and priorities and whatnot is pretty much an internal-only > detail - which doesn't mean it's not good or useful or worth doing, > just that I don't think it's worth blocking the first part for it, as > it can happen just as well later. The procps-base proposal looks good > to me. Hello Craig, It's been six months since the last update on this bug - would it be possible to finally take this over the finishing line? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071705: Add UFW profile integration with apache2
Source: apache2
Version: 2.4.52-1ubuntu4
Severity: wishlist
Tags: patch
In 2008 Ubuntu implemented[1] an Uncomplicated Firewall (UFW) profile for
Apache2. To the best I can tell, this has not yet been proposed to
Debian, although Debian does use ufw.
Are ufw profiles of interest to Debian? If so, would Debian's Apache
maintenace team consider adopting this changeset from Ubuntu?
1: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/261198
>From cc0cadcadda2725d7c6a961f221bf643bddf6032 Mon Sep 17 00:00:00 2001
From: Bryce Harrington
Date: Mon, 18 Jul 2022 17:51:08 -0700
Subject: [PATCH] Add Uncomplicated Firewall (UFW) profiles
---
debian/apache2-utils.ufw.profile | 14 ++
debian/apache2.dirs | 1 +
debian/apache2.install | 1 +
debian/control | 3 ++-
4 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 debian/apache2-utils.ufw.profile
diff --git a/debian/apache2-utils.ufw.profile b/debian/apache2-utils.ufw.profile
new file mode 100644
index 0..974a655cd
--- /dev/null
+++ b/debian/apache2-utils.ufw.profile
@@ -0,0 +1,14 @@
+[Apache]
+title=Web Server
+description=Apache v2 is the next generation of the omnipresent Apache web server.
+ports=80/tcp
+
+[Apache Secure]
+title=Web Server (HTTPS)
+description=Apache v2 is the next generation of the omnipresent Apache web server.
+ports=443/tcp
+
+[Apache Full]
+title=Web Server (HTTP,HTTPS)
+description=Apache v2 is the next generation of the omnipresent Apache web server.
+ports=80,443/tcp
diff --git a/debian/apache2.dirs b/debian/apache2.dirs
index 60890130b..1aa6d3c65 100644
--- a/debian/apache2.dirs
+++ b/debian/apache2.dirs
@@ -10,3 +10,4 @@ var/cache/apache2/mod_cache_disk
var/lib/apache2
var/log/apache2
var/www/html
+/etc/ufw/applications.d/apache2
diff --git a/debian/apache2.install b/debian/apache2.install
index b6ad78940..92865fc4e 100644
--- a/debian/apache2.install
+++ b/debian/apache2.install
@@ -8,3 +8,4 @@ debian/config-dir/*.conf /etc/apache2
debian/config-dir/envvars /etc/apache2
debian/config-dir/magic/etc/apache2
debian/debhelper/apache2-maintscript-helper /usr/share/apache2/
+debian/apache2-utils.ufw.profile /etc/ufw/applications.d/
diff --git a/debian/control b/debian/control
index a5d33f22e..87f1833b2 100644
--- a/debian/control
+++ b/debian/control
@@ -43,7 +43,8 @@ Depends: apache2-bin (= ${binary:Version}),
Recommends: ssl-cert
Suggests: apache2-doc,
apache2-suexec-pristine | apache2-suexec-custom,
- www-browser
+ www-browser,
+ ufw
Pre-Depends: ${misc:Pre-Depends}
Provides: httpd,
httpd-cgi
--
2.34.1
Bug#1071702: scoary: tests fail with scipy 1.12
Error is 38s Traceback (most recent call last): 38s File "/usr/lib/python3.11/multiprocessing/pool.py", line 125, in worker 38s result = (True, func(*args, **kwds)) 38s ^^^ 38s File "/usr/lib/python3/dist-packages/scoary/methods.py", line 1267, in PairWiseComparisons 38s resultscontainer[currentgene][Pbest] = ss.binom_test( 38s^ 38s AttributeError: module 'scipy.stats' has no attribute 'binom_test'
Bug#1071704: uc-echo: tests fail with scipy 1.12
Source: uc-echo Version: 1.12-18 Severity: normal uc-echo uses a deprecated scipy API that fails with scipy 1.12 24s autopkgtest [20:33:32]: test runtest: [--- 24s Test for sample data 25s Traceback (most recent call last): 25s File "/usr/lib/uc-echo/ErrorCorrection.py", line 19, in 25s from scipy import floor, ceil 25s ImportError: cannot import name 'floor' from 'scipy' (/usr/lib/python3/dist-packages/scipy/__init__.py) This bug will become serious when scipy 1.12 is uploaded to unstable in the near future.
Bug#1071703: gammapy: test fail with scipy 1.12
Source: gammapy Version: 1.1-4 Severity: normal gammpy appears to be using a deprecated RootResults API that fails with scipy 1.12 92s ERROR collecting test session _ 92s /usr/lib/python3.11/importlib/__init__.py:126: in import_module 92s return _bootstrap._gcd_import(name[level:], package, level) 92s :1204: in _gcd_import 92s ??? 92s :1176: in _find_and_load 92s ??? 92s :1147: in _find_and_load_unlocked 92s ??? 92s :690: in _load_unlocked 92s ??? 92s /usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:178: in exec_module 92s exec(co, module.__dict__) 92s /usr/lib/python3/dist-packages/gammapy/conftest.py:13: in 92s from gammapy.datasets import SpectrumDataset 92s /usr/lib/python3/dist-packages/gammapy/datasets/__init__.py:2: in 92s from .core import Dataset, Datasets 92s /usr/lib/python3/dist-packages/gammapy/datasets/core.py:10: in 92s from gammapy.modeling.models import DatasetModels, Models 92s /usr/lib/python3/dist-packages/gammapy/modeling/__init__.py:4: in 92s from .fit import Fit 92s /usr/lib/python3/dist-packages/gammapy/modeling/fit.py:15: in 92s from .scipy import confidence_scipy, optimize_scipy 92s /usr/lib/python3/dist-packages/gammapy/modeling/scipy.py:5: in 92s from gammapy.utils.roots import find_roots 92s /usr/lib/python3/dist-packages/gammapy/utils/roots.py:9: in 92s BAD_RES = RootResults(root=np.nan, iterations=0, function_calls=0, flag=0) 92s E TypeError: RootResults.__init__() missing 1 required positional argument: 'method' This bug will become serious when scipy 1.12 is uploaded to unstable in the near future.
Bug#1071702: scoary: tests fail with scipy 1.12
Source: scoary Version: 1.6.16-6 Severity: normal scoary uses a deprecated scipy.stats API (binom_test) which causes it to fail tests with scipy 1.12. This bug will become serious when scipy 1.12 is uploaded to unstable in the near future.
Bug#1071701: Please build against lua 5.4 instead of lua 5.3
Source: apache2 Version: 2.4.52-1 Severity: normal X-Debbugs-Cc: Please bump the liblua Build-Dep from liblua5.3-dev to liblua5.4-dev. In Ubuntu we've verified apache2 builds ok with 5.4, and it looks like Debian has lua 5.4 in testing now. (See also Deb #979501 for prior lua bump.) Thank you, Bryce
Bug#1071501: Linux NFS client hangs in nfs4_lookup_revalidate
On Fri, 24 May 2024, Richard Kojedzinszky wrote:
> Dear devs,
>
> I am attaching a stripped down version of the little program which
> triggers the bug very quickly, in a few minutes in my test lab. It
> turned out that a single NFS mountpoint is enough. Just start the
> program giving it the NFS mount as first argument. It will chdir there,
> and do file operations, which will trigger a lockup in a few minutes.
I couldn't get the go code to run. But then it is a long time since I
played with go and I didn't try very hard.
If you could provide simple instructions and a list of package
dependencies that I need to install (on Debian), I can give it a try.
Or you could try this patch. It might help, but I don't have high
hopes. It adds some memory barriers and fixes a bug which would cause a
problem if memory allocation failed (but memory allocation never fails).
NeilBrown
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index ac505671efbd..5bcc0d14d519 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1804,7 +1804,7 @@ __nfs_lookup_revalidate(struct dentry *dentry, unsigned
int flags,
} else {
/* Wait for unlink to complete */
wait_var_event(&dentry->d_fsdata,
- dentry->d_fsdata != NFS_FSDATA_BLOCKED);
+ smp_load_acquire(&dentry->d_fsdata) !=
NFS_FSDATA_BLOCKED);
parent = dget_parent(dentry);
ret = reval(d_inode(parent), dentry, flags);
dput(parent);
@@ -2508,7 +2508,7 @@ int nfs_unlink(struct inode *dir, struct dentry *dentry)
spin_unlock(&dentry->d_lock);
error = nfs_safe_remove(dentry);
nfs_dentry_remove_handle_error(dir, dentry, error);
- dentry->d_fsdata = NULL;
+ smp_store_release(&dentry->d_fsdata, NULL);
wake_up_var(&dentry->d_fsdata);
out:
trace_nfs_unlink_exit(dir, dentry, error);
@@ -2616,7 +2616,7 @@ nfs_unblock_rename(struct rpc_task *task, struct
nfs_renamedata *data)
{
struct dentry *new_dentry = data->new_dentry;
- new_dentry->d_fsdata = NULL;
+ smp_store_release(&new_dentry->d_fsdata, NULL);
wake_up_var(&new_dentry->d_fsdata);
}
@@ -2717,6 +2717,10 @@ int nfs_rename(struct mnt_idmap *idmap, struct inode
*old_dir,
task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry,
must_unblock ? nfs_unblock_rename : NULL);
if (IS_ERR(task)) {
+ if (must_unlock) {
+ smp_store_release(&new_dentry->d_fsdata, NULL);
+ wake_up_var(&new_dentry->d_fsdata);
+ }
error = PTR_ERR(task);
goto out;
}
Bug#1071700: paraview: FTBFS 32-bit arches: xdmf3 invalid conversion ‘long unsigned int*’ to ‘const int*’
Package: paraview Version: 5.12.0+dfsg-4 Severity: important Tags: ftbfs paraview 5.12 has started failing to build on i386. paraview 5.11 previously built on i386. The problem appears to be an implicit conversion from ‘long unsigned int*’ to ‘const int*’ in getArrayType in XdmfArray.cpp paraview was already failing on armel, armhf with other errors, so they are already considered not-supported. Perhaps we might have to drop support on i386 as well. Build logs at https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=i386&ver=5.12.0%2Bdfsg-4&stamp=1716421169&raw=0 https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=armel&ver=5.12.0%2Bdfsg-4&stamp=1716421874&raw=0 https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=armhf&ver=5.12.0%2Bdfsg-4&stamp=1716421071&raw=0 The error message is [ 3%] Linking CXX shared library ../../../../lib/i386-linux-gnu/libvtkprotobuf-pv5.12.so cd /<>/build.python3.12/ThirdParty/protobuf/vtkprotobuf/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/protobuf.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O0 -g -Wl,-lc -Wl,-z,relro -Wl,--as-needed -shared -Wl,-soname,libvtkprotobuf-pv5.12.so.1 -o ../../../../lib/i386-linux-gnu/libvtkprotobuf-pv5.12.so.5.12 CMakeFiles/protobuf.dir/google/protobuf/compiler/importer.cc.o CMakeFiles/protobuf.dir/google/protobuf/compiler/parser.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/coded_stream.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/gzip_stream.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/io_win32.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/printer.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/strtod.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/tokenizer.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/zero_copy_stream.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/zero_copy_stream_impl.cc.o CMakeFiles/protobuf.dir/google/protobuf/io/zero_copy_stream_impl_lite.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/bytestream.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/common.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/int128.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/status.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/statusor.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/stringpiece.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/stringprintf.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/structurally_valid.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/strutil.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/substitute.cc.o CMakeFiles/protobuf.dir/google/protobuf/stubs/time.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/delimited_message_util.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/field_comparator.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/field_mask_util.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/json_util.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/message_differencer.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/time_util.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/type_resolver_util.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/datapiece.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/default_value_objectwriter.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/error_listener.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/field_mask_utility.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/json_escaping.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/json_objectwriter.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/json_stream_parser.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/object_writer.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/proto_writer.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/protostream_objectsource.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/protostream_objectwriter.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/type_info.cc.o CMakeFiles/protobuf.dir/google/protobuf/util/internal/utility.cc.o CMakeFiles/protobuf.dir/google/protobuf/any.cc.o CMakeFiles/protobuf.dir/google/protobuf/any_lite.cc.o CMakeFiles/protobuf.dir/google/protobuf/any.pb.cc.o CMakeFiles/protobuf.dir/google/protobuf/api.pb.cc.o CMakeFiles/protobuf.dir/google/protobuf/arena.cc.o CMakeFiles/protobuf.dir/google/protobuf/descriptor.cc.o CMakeFiles/protobuf.dir/google/protobuf/descriptor.pb.cc.o CMakeFiles/protobuf.dir/google/protobuf/descriptor_database.cc.o CMakeFiles/protobuf.dir/google/protobuf/duration.pb.cc.o CMakeFiles/protobuf.dir/google/protobuf/dynamic_message.cc.o CMakeFiles/protobuf.dir/google/protobuf/empty.pb.cc.o CMakeFiles/protobuf.dir/google/protobuf/extension_set.cc.o CMakeFiles/protobuf.dir/google/protobuf/extension_set_heavy.cc.o CMakeFiles/protobuf.dir/google/protobuf/field
Bug#1071675: duplicity: SSH broken with Paramiko 3.4
tags 1071675 +moreinfo +unreproducible severity 1071675 normal thanks On Thu, 23 May 2024 18:16:58 +0200, Fiona Klute writes: >When trying to do backup to an sftp:// target Duplicity fails since >python3-paramiko was updated to 3.4.0-1, with the following error which >looks like an API change in Paramiko: i cannot reproduce this problem. please provide the output of a duplicity -v9 run and the ssh key types involved on your target machine. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/ Q. What kind of a dog says: "bofh! bofh!?" A. A rootweiler. signature.asc Description: Digital Signature
Bug#1071699: mariadb-server: Moved mariadb socket, debian-start reports error connecting to old socket
Package: mariadb-server Version: 1:10.11.6-0+deb12u1 Severity: normal X-Debbugs-Cc: fuzzye...@gmail.com Dear Maintainer, First, thanks for your hard work maintaining the MariaDB (server) package. You're awesome. After moving /var/lib/mysql/ to /mnt/tera/mariadb/ , modifying /etc/mysql/mariadb.conf.d/50-server.conf from: datadir = /var/lib/mysql to: datadir = /mnt/tera/mariadb , modifying /etc/mariadb.cnf uncomment: port = 3306 from: socket = /run/mysqld/mysqld.sock to:socket = /mnt/tera/mariadb/mysqld.sock , and modifying /etc/mariadb.conf.d/50-client.cnf add to [client] section: port = 3306 socket = /mnt/tera/mariadb/mysqld.conf , starting mariadb (as root) systemctl start mariadb yields a successfully running mariadb tested by: mysqladmin -u root status returns: Uptime: 1644 Threads: 1 Questions: 4 Slow queries: 0 Opens: 17 Open tables: 10 Queries per second avg: 0.002 but debian start returns an error (there may be a smarter way to extract the debian-start messages, but I know this one works) journalctl -b | grep debian-start returns for this start: [...] /etc/mysql/debian-start[141397]: Upgrading MySQL tables if necessary. [...] /etc/mysql/debian-start[141408]: Checking for insecure root accounts. [...] debian-start[141411]: ERROR 2002 (HY000): Can't connect to local server through socket '/run/mysqld/mysqld.sock' (2) Checking /etc/mysql/debian-start and /usr/share/mysql/debian-start.inc.sh, I don't see a hardcoded socket path, so I don't know where this socket path is coming from. I did not expect an error from debian-start. I expect that debian-start indicates if it is attaching to the server via the socket or via localhost/127.0.0.1 (and the port). In fact, if both are configured, I imagine it would check reachability through both mechanisms and report results for both. I also expect it will use the configured mechanisms, not defaults. Correct(?) solution: debian-start uses the configured mechanisms to probe the mariadb server and reports success/fail of each. Errors are only generated if the configured access mechanisms fail. Passable workaround: systemd's maraidb startup script creates a link from /run/mysqld/mysqld.sock to wherever that socket actually is when it starts up. My hack-ish workaround: I have linked the wrong location to the configured location. ln -s /mnt/tera/mariadb/mysqld.sock /run/mysqld/mysqld.sock chown -h mysql:mysql /run/mysqld/mysqld.sock I don't have a clear understanding of the lifetime of the /run/* (sub-)filesystem, so I don't know how long this hack will prevent the error message. Again, thanks for your hard work! -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii galera-4 26.4.13-1 ii gawk 1:5.2.1-2 ii iproute2 6.1.0-3 ii libc6 2.36-9+deb12u7 ii libdbi-perl1.643-4 ii libpam0g 1.5.2-6+deb12u1 ii libssl33.0.11-1~deb12u2 ii libstdc++6 12.2.0-14 ii lsof 4.95.0-1 ii mariadb-client 1:10.11.6-0+deb12u1 ii mariadb-common 1:10.11.6-0+deb12u1 ii mariadb-server-core1:10.11.6-0+deb12u1 ii passwd 1:4.13+dfsg1-1+b1 ii perl 5.36.0-7+deb12u1 ii procps 2:4.0.2-3 ii psmisc 23.6-1 ii rsync 3.2.7-1 ii socat 1.7.4.4-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 ii mariadb-plugin-provider-bzip2 1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-lz4 1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-lzma1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-lzo 1:10.11.6-0+deb12u1 ii mariadb-plugin-provider-snappy 1:10.11.6-0+deb12u1 ii pv 1.6.20-1 Versions of packages mariadb-server suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 pn mariadb-test pn netcat-openbsd -- Configuration Files: /etc/mysql/mariadb.conf.d/50-server.cnf changed: [server] [mysqld] pid-file= /run/mysqld/mysqld.pid basedir = /usr datadir = /mnt/tera/mariadb bind-address= 127.0.0.1 expire_logs_days= 10 character-set-server = utf8mb4 collation-server = utf8mb4_general_ci [embedded] [mariadb] [mariadb-10.11] -- debco
Bug#1071649: mflua.1: some remarks and editorial changes for this man page
1) mflua.1 has never been in TeX Live. I guess someone created it for Debian (or other) without sending it upstream? Anyway, I will copy it into TL. Although mflua.1 doesn't have the usual Debian disclaimers for man pages, I assume that's ok :). 2) It would be welcome, and the fixes seem ok in themselves. But I see: .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.47.16. If that is true, then I don't much want to accept any manual edits, since then we couldn't regenerate it with help2man. Instead, help2man should be fixed to avoid these problems in the first place. bug-help2...@gnu.org I hope you agree? The current version of help2man is 1.49.3. Does it do any better? (It would be a pleasant surprise if the answer was yes.) Thanks for the report, Karl
Bug#1011571: ITA: rinetd -- Internet TCP/UDP redirection server
owner -1 debma...@g-e-u-e-r.de retitle -1 ITA: rinetd -- Internet TCP/UDP redirection server I set up a git repo by 'gbp import-dscs --debsnap ...' under my personal projects [1] and started to work on the package. Cheers, Sven [1] https://salsa.debian.org/sven-geuer/rinetd -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 signature.asc Description: This is a digitally signed message part
Bug#1071647: mendex.1: some remarks and editorial changes for this man page
Control: tags -1 - patch On 23.05.2024 22:18, Bjarni Ingi Gislason wrote: On Thu, May 23, 2024 at 09:32:32AM +0200, Preuße, Hilmar wrote: On 23.05.2024 00:24, Bjarni Ingi Gislason wrote: Hello Bjarni, here are some notes and editorial fixes for the manual. The patch is in the attachment. Unfortunately the patch not match to the manual page from TL204 [1]. Could you adapt to that version? Thanks! The file I get with 'wget2 ...' is a Doc file. No, it is not a doc file, but the HTML file representing the web page: hille@rasppi2:~ $ wget2 https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1 [0] Downloading 'https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1' ... Saving 'mendex.1.1' HTTP response 200 [https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1] hille@rasppi2:~ $ file mendex.1.1 mendex.1.1: HTML document, Unicode text, UTF-8 text, with very long lines (1616) If I copy it from the page with 'firefox' I get the man page when I use the 'raw' choice. When downloading the raw manual page for TL2024 and trying to apply your patch it does not apply. hille@rasppi2:~ $ wget2 "https://raw.githubusercontent.com/debian-tex/texlive-bin/master_tl_2024/texk/mendexk/mendex.1"; [0] Downloading 'https://raw.githubusercontent.com/debian-tex/texlive-bin/master_tl_2024/texk/mendexk/mendex.1' ... Saving 'mendex.1' HTTP response 200 [https://raw.githubusercontent.com/debian-tex/texlive-bin/master_tl_2024/texk/mendexk/mendex.1] hille@rasppi2:~ $ wget2 -O mendex.1.diff "https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1071647;filename=mendex.1.diff;msg=5"; [0] Downloading 'https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1071647;filename=mendex.1.diff;msg=5' ... Saving 'mendex.1.diff' HTTP response 200 [https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1071647;filename=mendex.1.diff;msg=5] hille@rasppi2:~ $ patch < mendex.1.diff (Stripping trailing CRs from patch; use --binary to disable.) patching file mendex.1 Hunk #13 FAILED at 459. Hunk #15 FAILED at 510. Hunk #16 succeeded at 556 with fuzz 2. 2 out of 17 hunks FAILED -- saving rejects to file mendex.1.rej What do you get if you use the option '--dry-run' for 'patch' or the diagnostics from it? See above. Many thanks for your help! I remove the patch tag for now. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1071697: ros-nodelet-core: please remove the old extraneous build dependency on python3-nose
Source: ros-nodelet-core Version: 1.11.0-1 Severity: normal X-Debbugs-Cc: Dmitry Shachnev Hi, I see that this package was not included in the original MBF [0], so I file this one bug. Please remove the old extraneous build-dependency on python3-nose. Greetings [0] https://lists.debian.org/debian-devel/2022/08/msg00184.html > nose has a Python 2 code base and it is difficult to keep it in working state > for new Python versions. It will probably become impossible after Python 3.13, > where lib2to3 will be removed [8].
Bug#1070752: ALT+TAB not working after Glib2.0 update
Hello! The problem has not been resolved. The accents are back, but the *ALT+TAB* keys are not recognized by Debian 12. On Windows and Kali Linux VMs it works normally. I have already reconfigured the keyboard several times and also in the Settings>Keyboard option. What can be done about this bug? - Lenovo Laptop - Legion 5 15IAH7H - Debian GNU/Linux 12 (bookworm) - Gnome 43.9 - Windows Manager: X11 $ apt-cache policy Glib2.0 libglib2.0-dev-bin: Installed: 2.74.6-2+deb12u2 Candidate: 2.74.6-2+deb12u2 Table version: *** 2.74.6-2+deb12u2 500 500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages 100 /var/lib/dpkg/status 2.74.6-2 500 500 http://ftp.us.debian.org/debian bookworm/main amd64 Packages 500 http://deb.debian.org/debian bookworm/main amd64 Packages libglib2.0-bin: Installed: 2.74.6-2+deb12u2 Candidate: 2.74.6-2+deb12u2 Table version: *** 2.74.6-2+deb12u2 500 500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages 100 /var/lib/dpkg/status 2.74.6-2 500 500 http://ftp.us.debian.org/debian bookworm/main amd64 Packages 500 http://deb.debian.org/debian bookworm/main amd64 Packages libglib2.0-dev: Installed: 2.74.6-2+deb12u2 Candidate: 2.74.6-2+deb12u2 Table version: *** 2.74.6-2+deb12u2 500 500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages 100 /var/lib/dpkg/status 2.74.6-2 500 500 http://ftp.us.debian.org/debian bookworm/main amd64 Packages 500 http://deb.debian.org/debian bookworm/main amd64 Packages ibglib2.0-0: Installled: 2.74.6-2+deb12u2 Candidate: 2.74.6-2+deb12u2 Table version: *** 2.74.6-2+deb12u2 500 500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages 100 /var/lib/dpkg/status 2.74.6-2 500 500 http://ftp.us.debian.org/debian bookworm/main amd64 Packages 500 http://deb.debian.org/debian bookworm/main amd64 Packages I created a topic on the Debian forum, but no one responded. https://forums.debian.net/viewtopic.php?t=159209 Please advise how the issue can be resolved. Thanks!
Bug#1071639: /usr/bin/rpmsign: Documentation bug: rpmsign vs rpm
Control: tags -1 upstream wontfix Control: close -1 On Wed, 22 May 2024 14:20:19 -0400 Jon Daley wrote: > Package: rpm > Version: 4.18.0+dfsg-1+deb12u1 > Severity: minor > File: /usr/bin/rpmsign > Tags: upstream > > Upstream documentation bug: > > ~>man rpmsign > rpm --addsign|--resign [rpmsign-options] PACKAGE_FILE ... > rpmsign-options > [--rpmv3] [--fskpath KEY] [--signfiles] > > ~>rpm --addsign --rpmv3 > rpm: --rpmv3: unknown option > ~>rpm --addsign --fskpath asdasd --signfiles asd > rpm: --fskpath: unknown option > ~>rpm --addsign --signfiles asd > rpm: --signfiles: unknown option > > All of these rpmsign-options can only work when running rpmsign as opposed to rpm. > > This bug also applies to Centos 7 and Oracle Linux 9, where I've been doing some testing. It looks like it was introduced between Centos 6 and 7, if that helps anyone. There are no manpage patches downstream, please report this upstream and it will be picked up in the next version, once it is fixed. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1026430: profanity: If an OMEMO msg to 2+ recipients & 1 recipient’s pubkey is bad, the msg is sent anyway (a logistical mess)
It looks like bug 2 is similar to upstream bug 1185: https://github.com/profanity-im/profanity/issues/1185
Bug#1071696: profanity: (security) Untrusted OMEMO keys are being used. Fingerprint trust is inconsistent.
Package: profanity Version: 0.13.1-2 Severity: normal Tags: upstream X-Debbugs-Cc: debbug.profan...@sideload.33mail.com The Profanity user guide¹ states “Before you can start talking with a contact you need to authenticate him by trusting his fingerprint(s).” That seems to be true for some correspondents but not others. I have four people configured as follows: * Alice - trusted fingerprint * Bob - untrusted fingerprint (implicit distrust) * Freddie - untrusted fingerprint (implicit distrust) * Martin - untrusted fingerprint (implicit distrust) My trustmodel is “manual”. All those users are using Snikket on iOS and the server is also Snikket. OMEMO is always enabled for all those users. According to the documentation, only Alice should be able to receive messages from me in this situation. However, Alice, Freddie, and Martin all seem to receive messages from me. Bob is exceptionally plagued with a false error claiming lack of OMEMO support every time I send Bob a msg. Apart from the error message being false, msgs to Bob are rightfully dysfunctional (though I would prefer if he receives no msg at all - what’s the point of sending him a msg he cannot open?). Msgs to Alice are rightfully functional. But what about Freddie & Martin? They generally receive my msgs fine, yet I apparently did not trust their fingerprints. This suggests a noteworthy security vulnerability because an untrusted key should not be used with a trust model of /manual/. Alternative theory 1: I did not keep notes on whose fingerprints I trusted. I am surprised I did not trust Freddie’s key. So I wonder if Profanity might be lying about whether keys are trusted. After entering /msg Freddie to get a dedicated 1:1 window, I entered “/omemo fingerprint” and it showed a fingerprint. It does not say trusted or untrusted. But if I do the same for Alice, “(trusted)” is printed next to the fingerprint. So by the way, the absence of “(trusted)” is an incredibly cryptic way of telling users a key is untrusted. I struggled to trust the software. So I found this file: ~/.local/share/profanity/omemo/$my_acct/trust.txt And indeed the fingerprints for Bob, Freddie, and Martin were not there. So I think we can rule out the alternative narrative that Profanity is lying about which keys are trusted. Alternative theory 2: Perhaps the “OMEMO” tag in the window status bar is a lie, and Profanity is actually sending unencrypted payloads to Freddie & Martin. This also seems unlikely but I will ask them if Snikket shows a padlock or shield on messages they receive from me. If not, I’ll amend this ticket. Otherwise assume they are getting a padlock. ¹ https://profanity-im.github.io/guide/0131/omemo.html -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages profanity depends on: ii libc6 2.36-9+deb12u7 ii libcurl3-gnutls7.88.1-10+deb12u5 ii libgcrypt201.10.1-3 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgpgme11 1.18.0-3+b1 ii libgtk-3-0 3.24.38-2~deb12u1 ii libncursesw6 6.4-4 ii libnotify4 0.8.1-1 ii libotr54.1.1-5 ii libpython3.11 3.11.2-6 ii libreadline8 8.2-1.3 ii libsignal-protocol-c2.3.2 2.3.3-3 ii libsqlite3-0 3.40.1-2 ii libstrophe00.12.2-1 ii libtinfo6 6.4-4 profanity recommends no packages. profanity suggests no packages. -- no debconf information
Bug#1071695: RM: azure-cosmos-table-python -- ROM; deprecated and replaced by python-azure
Package: ftp.debian.org Severity: normal Hi, azure-cosmos-table-python has long been deprecated, as it is replaced by a module from src:python-azure. It is no longer in testing, please now remove it from unstable too. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071694: reportbug: crosshurd does not extract gnumach
Package: crosshurd Version: 1.7.60 Severity: important User: debian-h...@lists.debian.org Usertags: hurd X-Debbugs-Cc: debian-h...@lists.debian.org Dear Maintainer, Due to recent changes in packages aand file names for gnumach, gnumach package is not extracted after being downloaded, so the resulting hurd system is unbootable. Many thanks, João -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 6.1.0-21-686-pae (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages crosshurd depends on: ii dialog1.3-20230209-1 ii dpkg-dev 1.21.22 Versions of packages crosshurd recommends: pn attr pn eatmydata crosshurd suggests no packages. -- no debconf information
Bug#1064938: isospec - maintainer does not access email from ftp-master
Hi Bastian, > It seems to be fixed. My mailbox contains the last bounce on > March, 8th. On Mar 10 I rolled back the changes I did some weeks before to reduce the debichem-devel moderation queue: https://salsa.debian.org/alioth-lists-team/support/-/issues/27 Sorry for not following up on this bug, and thanks for confirming that it's already fixed. Cheers, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer 🍥 log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Bug#1071693: sbsign should check certificate's expiration
Package: sbsigntool
Version: 0.9.4-3.1+b1
Severity: normal
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
it was a bit surprising to learn sbsign will happily sign EFI images
even if the certificate, provided via the --cert parameter, has expired.
While this possibly will not affect functionality, it might still cause
surprising and hard-to-debug issues later.
How to repeat:
Provide an EFI image (e.g. grubx64.efi) as "kernel", and run
-
#!/bin/sh
image='kernel'
if [ ! -f "$image" ]; then
echo "E: Copy some EFI image to '$image' first"
exit 1
fi
# Generate signing key and certificate
# chronic (from moreutils), just to avoid noise
chronic \
faketime "2023/1/2" \
openssl req \
-batch \
-new \
-subj "/CN=Root CA" \
-newkey RSA:4096 \
-nodes \
-keyout root.key \
-x509 \
-days 180 \
-sha256 \
-extensions v3_ca \
-out root.crt.pem
# Show the expiration date
openssl x509 -noout -enddate -in root.crt.pem
sbsign \
--key root.key --cert root.crt.pem --output "$image.signed" "$image"
-
Expected: sbsign should at least warn about an expired certificate, or
even refuse operation.
Observed: sbsign just signs the image.
How to fix (draft):
The patch attached is rather a proof of concept: It checks the
expiration date, warns if it's less than 365 days in the future, and
exits non-zero if it's less than 30 days, or even already expired.
Todo:
* Make the thresholds configurable via command line options.
* Documentation, including "Setting the thresholds to 0 (zero) disables
the check".
* Check the certificate(s) provided via --addcert.
Regards,
Christoph
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.31 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sbsigntool depends on:
ii libc6 2.38-11
ii libssl3t64 3.2.1-3
ii libuuid12.40.1-1
sbsigntool recommends no packages.
sbsigntool suggests no packages.
-- no debconf information
--- a/src/sbsign.c
+++ b/src/sbsign.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
@@ -156,6 +157,8 @@
struct sign_context *ctx;
uint8_t *buf, *tmp;
int rc, c, sigsize;
+ int maxttl_warn = 365, maxttl_crit = 30;
+ time_t now = time(NULL);
EVP_PKEY *pkey;
ctx = talloc_zero(NULL, struct sign_context);
@@ -255,6 +258,29 @@
if (!cert)
return EXIT_FAILURE;
+ ASN1_TIME *notafter = X509_getm_notAfter(cert);
+ int expired = ASN1_TIME_cmp_time_t(notafter, now);
+ if (maxttl_crit > 0) {
+ if (expired == -1) {
+ fprintf(stderr, "critical, certificate %s has expired\n", certfilename);
+ return EXIT_FAILURE;
+ }
+ time_t time_crit = now + 86400*maxttl_crit;
+ if (ASN1_TIME_cmp_time_t(notafter, time_crit) == -1) {
+ fprintf(stderr, "critical, certificate %s will expire in less than %d days\n", certfilename, maxttl_crit);
+ return EXIT_FAILURE;
+ }
+ }
+ if (maxttl_warn > 0) {
+ if (expired == -1) {
+ fprintf(stderr, "warning, certificate %s has expired\n", certfilename);
+ } else {
+ time_t time_warn = now + 86400*maxttl_warn;
+ if (ASN1_TIME_cmp_time_t(notafter, time_warn) == -1)
+fprintf(stderr, "warning, certificate %s will expire in less than %d days\n", certfilename, maxttl_warn);
+ }
+ }
+
const EVP_MD *md = EVP_get_digestbyname("SHA256");
/* set up the PKCS7 object */
signature.asc
Description: PGP signature
Bug#1071647: mendex.1: some remarks and editorial changes for this man page
On Thu, May 23, 2024 at 09:32:32AM +0200, Preuße, Hilmar wrote: > On 23.05.2024 00:24, Bjarni Ingi Gislason wrote: > > Hello, > > > Dear Maintainer, > > > >here are some notes and editorial fixes for the manual. > > > > The patch is in the attachment. > > > > Unfortunately the patch not match to the manual page from TL204 [1]. Could > you adapt to that version? Thanks! > > Hilmar > > [1] > https://github.com/debian-tex/texlive-bin/blob/master_tl_2024/texk/mendexk/mendex.1 > -- > sigfault > The file I get with 'wget2 ...' is a Doc file. If I copy it from the page with 'firefox' I get the man page when I use the 'raw' choice. I do not get any difference between the Debian 'mendex.1' and the downloaded from 'firefox' using the 'raw' choice. What do you get if you use the option '--dry-run' for 'patch' or the diagnostics from it?
Bug#965053: az consumption usage list: TypeError: list() missing 1 required positional argument: 'scope'
Control: close -1 2.61.0-1 On Wed, 15 Jul 2020 09:56:16 +0200 Jakub Wilk wrote: > Package: azure-cli > Version: 2.7.0-1 > > "az consumption usage list" doesn't work at all: > > $ az consumption usage list > Command group 'consumption' is in preview. It may be changed/removed in a future release. > The command failed with an unexpected error. Here is the traceback: > > list() missing 1 required positional argument: 'scope' > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/knack/cli.py", line 215, in invoke > cmd_result = self.invocation.execute(args) > File "/usr/lib/python3/dist- packages/azure/cli/core/commands/__init__.py", line 654, in execute > raise ex > File "/usr/lib/python3/dist- packages/azure/cli/core/commands/__init__.py", line 718, in _run_jobs_serially > results.append(self._run_job(expanded_arg, cmd_copy)) > File "/usr/lib/python3/dist- packages/azure/cli/core/commands/__init__.py", line 709, in _run_job > cmd_copy.exception_handler(ex) > File "/usr/lib/python3/dist- packages/azure/cli/command_modules/consumption/_exception_handler.py", line 16, in consumption_exception_handler > reraise(*sys.exc_info()) > File "/usr/lib/python3/dist-packages/six.py", line 703, in reraise > raise value > File "/usr/lib/python3/dist- packages/azure/cli/core/commands/__init__.py", line 688, in _run_job > result = cmd_copy(params) > File "/usr/lib/python3/dist- packages/azure/cli/core/commands/__init__.py", line 325, in __call__ > return self.handler(*args, **kwargs) > File "/usr/lib/python3/dist- packages/azure/cli/core/__init__.py", line 545, in default_command_handler > return op(**command_args) > File "/usr/lib/python3/dist- packages/azure/cli/command_modules/consumption/custom.py", line 33, in cli_consumption_list_usage > return client.list(expand=expand, filter=filter_expression) > TypeError: list() missing 1 required positional argument: 'scope' Cannot reproduce anymore in 2.61.0-1 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1034797: azure-cli: az keyvault show fails with No module named 'azure.keyvault.v7_0'
Control: close -1 2.61.0-1 On Wed, 12 Jul 2023 14:49:14 +0200 Gregor Riepl wrote: > Package: azure-cli > Version: 2.50.0-2 > Severity: important > Followup-For: Bug #1034797 > X-Debbugs-Cc: onit...@gmail.com > > With azure-cli 2.50.0-2, the keyvault feature is still broken, but it fails > with a different error now: > > $ az keyvault secret show --vault-name myvault --name mykey > No module named 'azure.keyvault.key_vault_id' > > This is similar to https://github.com/Azure/azure-cli/issues/17981 > > Other keyvault commands, such as keyvault list, keyvault secret list, keyvault > show, work fine. Cannot reproduce anymore in 2.61.0-1 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1071292: openssh-server: sshd fails to restart at package upgrade, future logins to server impossible
On Thu, 23 May 2024, Colin Watson wrote: > On Fri, May 17, 2024 at 09:42:05PM +0200, Sven-Haegar Koch wrote: > > I just upgraded openssh as part of my normal "apt dist-upgrade" every > > few days, from 1:9.7p1-4 to 1:9.7p1-5. > > > > The whole apt went through without any errors - but afterwards sshd > > was no longer running / listening on its network ports. > > Hm, I haven't seen this elsewhere either in my own upgrades or from > anyone else, and as you say the ssh.service logs don't give much to go > on. Is there anything informative in /var/log/auth.log, perhaps? Nothing really definitive. For while doing the upgrade (as user aptdater): May 17 20:06:12 vpnhub1 sshd[1102927]: Accepted publickey for aptdater from 193.103.159.64 port 59666 ssh2: RSA SHA256:0FPN 60iZ3XPPFMs5PwTyRxGp8irW/g8w7x/MEveVwtY May 17 20:06:12 vpnhub1 sshd[1102927]: pam_unix(sshd:session): session opened for user aptdater(uid=110) by aptdater(uid=0) May 17 20:06:17 vpnhub1 systemd-logind[332]: New session 28741 of user aptdater. May 17 20:06:20 vpnhub1 (systemd): pam_unix(systemd-user:session): session opened for user aptdater(uid=110) by aptdater(ui d=0) May 17 20:06:24 vpnhub1 sshd[1102927]: pam_env(sshd:session): deprecated reading of user environment enabled May 17 20:06:27 vpnhub1 sudo: aptdater : TTY=pts/0 ; PWD=/var/lib/apt-dater ; USER=root ; COMMAND=/usr/bin/apt update May 17 20:06:27 vpnhub1 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by aptdater(uid=110) May 17 20:06:47 vpnhub1 sudo: pam_unix(sudo:session): session closed for user root May 17 20:06:47 vpnhub1 sudo: aptdater : TTY=pts/0 ; PWD=/var/lib/apt-dater ; USER=root ; COMMAND=/usr/bin/apt dist-upgrade May 17 20:06:47 vpnhub1 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by aptdater(uid=110) May 17 20:09:25 vpnhub1 sshd[382556]: Received signal 15; terminating. May 17 20:11:30 vpnhub1 sudo: pam_unix(sudo:session): session closed for user root May 17 20:11:30 vpnhub1 sudo: aptdater : TTY=pts/0 ; PWD=/var/lib/apt-dater ; USER=root ; COMMAND=/usr/bin/apt-get autoremove May 17 20:11:30 vpnhub1 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by aptdater(uid=110) May 17 20:11:44 vpnhub1 sudo: pam_unix(sudo:session): session closed for user root May 17 20:11:44 vpnhub1 sudo: aptdater : TTY=pts/0 ; PWD=/var/lib/apt-dater ; USER=root ; COMMAND=/usr/bin/apt-get clean May 17 20:11:44 vpnhub1 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by aptdater(uid=110) May 17 20:11:44 vpnhub1 sudo: pam_unix(sudo:session): session closed for user root May 17 20:11:44 vpnhub1 sshd[1102968]: Received disconnect from 193.103.159.64 port 59666:11: disconnected by user May 17 20:11:44 vpnhub1 sshd[1102968]: Disconnected from user aptdater 193.103.159.64 port 59666 May 17 20:11:44 vpnhub1 sshd[1102927]: pam_unix(sshd:session): session closed for user aptdater May 17 20:11:45 vpnhub1 systemd-logind[332]: Session 28741 logged out. Waiting for processes to exit. May 17 20:11:45 vpnhub1 systemd-logind[332]: Removed session 28741. Just a single May 17 20:09:25 vpnhub1 sshd[382556]: Received signal 15; terminating. in the middle, what I assume was when sshd was killed, and supposed to be restarted. The regular sshd[1102452]: Connection closed by 193.103.159.70 port 42808 [preauth] from my monitoring which normally happens every 5 minutes did not occur between 20:05 and 21:50, after I had restarted sshd. When I was logging in after finding it through virt-manager / remote console it shows some errors, but nothing that blocked the console login, where I was able to restart sshd: May 17 21:45:50 vpnhub1 login[2153297]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory May 17 21:45:50 vpnhub1 login[2153297]: PAM adding faulty module: pam_lastlog.so May 17 21:45:52 vpnhub1 login[2153297]: pam_unix(login:session): session opened for user haegar(uid=1000) by haegar(uid=0) May 17 21:45:52 vpnhub1 login[2153297]: pam_systemd(login:session): New sd-bus connection (system-bus-pam-systemd-2153297) opened. May 17 21:45:53 vpnhub1 systemd-logind[332]: New session 28815 of user haegar. May 17 21:45:53 vpnhub1 (systemd): pam_unix(systemd-user:session): session opened for user haegar(uid=1000) by haegar(uid=0) May 17 21:45:53 vpnhub1 (systemd): pam_systemd(systemd-user:session): Failed to create session: Invalid session class manager May 17 21:45:53 vpnhub1 (sd-pam): pam_unix(systemd-user:session): session closed for user haegar May 17 21:46:00 vpnhub1 sudo: haegar : TTY=tty1 ; PWD=/root ; USER=root ; COMMAND=/bin/bash May 17 21:46:00 vpnhub1 sudo: pam_unix(sudo-i:session): session opened for user root(uid=0) by haegar(uid=1000) May 17 21:46:00 vpnhub1 sudo: pam_systemd(sudo-i:session): New sd-bus connection (system-bus-pam-systemd-1129441) opened. May 17 21:46:00 vpnhub1 sudo: pam_systemd(sudo-i:session): Fai
Bug#1071328: lomiri-indicator-network: FTBFS: unit-tests failed
Control: block -1 by 1071690
On Fr 17 Mai 2024 22:39:15 CEST, Santiago Vila wrote:
Package: src:lomiri-indicator-network
Version: 1.0.2-4
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
debian/rules binary
dh binary
dh_update_autotools_config
dh_autoreconf
debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DENABLE_TESTS=ON \
cd obj-x86_64-linux-gnu &&
DEB_PYTHON_INSTALL_LAYOUT=deb cmake -DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
-DFETCHCONTENT_FULLY_DISCONNECTED=ON
-DCMAKE_INSTALL_RUNSTATEDIR=/run
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles"
-DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DENABLE_TESTS=ON ..
-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
[... snipped ...]
1: 1715965979.445 GetAll /org/freedesktop/NetworkManager
org.freedesktop.NetworkManager
1: 1715965979.445 Get
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active.Id
1: 1715965979.445 GetAll
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active
1: 1715965979.445 Get
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active.Type
1: 1715965979.445 GetAll
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active
1: 1715965979.446 Get
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.VPN.Connection.VpnState
1: 1715965979.446 GetAll
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.VPN.Connection
1: 1715965979.446 Get
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active.State
1: 1715965979.446 GetAll
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active
1: 1715965979.446 Get
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active.Connection
1: 1715965979.446 GetAll
/org/freedesktop/NetworkManager/ActiveConnection/0
org.freedesktop.NetworkManager.Connection.Active
1: [ OK ] TestConnectivityApiVpn.UpdatesVpnState (691 ms)
1: [ RUN ] TestConnectivityApiVpn.ReadsOpenvpnProperties
1: Debug: /<>/tests/data/networkmanager.py ((null):0, (null))
1: 1715965979.896 AddModem "ril_0" {"Powered": False}
1: 1715965979.898 GetAll /ril_0 org.ofono.Modem
1: 1715965979.898 emit / org.ofono.Manager.ModemAdded "/ril_0"
{"Online": True, "Powered": True, "Lockdown": False, "Emergency":
False, "Manufacturer": "Fakesys", "Model": "Mock Modem", "Revision":
"0815.42", "Serial": "12345678-1234-1234-1234-", "Type":
"hardware", "Interfaces": ["org.ofono.CallVolume",
"org.ofono.VoiceCallManager", "org.ofono.NetworkRegistration",
"org.ofono.SimManager", "org.ofono.ConnectionManager"], "Features":
["gprs", "net"]}
1: 1715965979.898 SetProperty "Bearer" "none"
1: 1715965979.899 Set /ril_0 org.ofono.ConnectionManager.Bearer "none"
1: 1715965979.899 emit /ril_0
org.freedesktop.DBus.Properties.PropertiesChanged
"org.ofono.ConnectionManager" {"Bearer": "none"} []
1: 1715965979.899 emit /ril_0
org.ofono.ConnectionManager.PropertyChanged "Bearer" "none"
1: 1715965979.899 SetProperty "Powered" False
1: 1715965979.899 Set /ril_0 org.ofono.ConnectionManager.Powered False
1: 1715965979.899 emit /ril_0
org.freedesktop.DBus.Properties.PropertiesChanged
"org.ofono.ConnectionManager" {"Powered": False} []
1: 1715965979.899 emit /ril_0
org.ofono.ConnectionManager.PropertyChanged "Powered" False
1: 1715965979.900 SetProperty "Attached" False
1: 1715965979.900 Set /ril_0 org.ofono.ConnectionManager.Attached False
1: 1715965979.900 emit /ril_0
org.freedesktop.DBus.Properties.PropertiesChanged
"org.ofono.ConnectionManager" {"Attached": False} []
1: 1715965979.900 emit /ril_0
org.ofono.ConnectionManager.PropertyChanged "Attached" False
1: 1715965979.901 AddConnection {"connection": {"id": "apple",
"timestamp": 1441979296, "type": "vpn", "uuid":
"b81a1cf4-37de-4497-925a-9d4e0e22ba76"}, "ipv4": {"addresses": [],
"dns": [], "method": "auto", "never-default": True, "routes": []},
"ipv6": {"addresses": [], "dns": [], "ip6-privacy": 0, "method":
"auto", "never-default": True, "routes": []}, "vpn": {"data": {"ca":
"/my/ca.crt", "cert": "/my/cert.crt",
Bug#1070672: azure-cli: should not request surveys from the user
Control: tags -1 wontfix Control: close -1 On Mon, 6 May 2024 21:59:34 + "brian m. carlson" wrote: > Package: azure-cli > Version: 2.50.0-2 > Severity: normal > > azure-cli prompts the user for surveys in at least some circumstances > when running `az login`. This is done using a bright blue, three- line > banner that is large and distracting, and totally unnecessary. Send a PR upstream to remove it, or just ignore it. Not going to carry patches for cosmetic and harmless things like this. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#761813: grep and locales
On Tue, 14 Mar 2023 10:19:19 -0400 Simon Deziel wrote: > On 2023-03-14 08:49, Richard Lewis wrote: > > On Mon, 13 Mar 2023, 12:36 Simon Deziel, wrote: > > > >> egrep still consumes a lot of memory for me. A workaround I've been > >> using is to add this to /etc/logcheck/logcheck.conf: > >> > >> # XXX: prevent grep from using incredible amounts of RAM (>3G RSS) > >> # this also speeds up grep a lot > >> export LC_ALL=C Returning to this after a while: I think the above -- setting LC_ALL in logcheck.conf is probably the best solution available. So we might even close this bug, as im not sure what else logcheck can do? > > interesting - does using C.UTF-8 have the same effect? > > tl; dr: no :/ Thanks for testing. I suppose the underlying issue is in grep. I hope that later versions of logcheck will allow to swap grep for ag or ripgrep -- but they are faster at the cost of more RAM, at least sometimes
Bug#1070965: xmlrpc
Hi, Per request, the "util" library was split out in it's own package. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071465 It was an act of balancing between the easy & clean solution. Greetings
Bug#630721: logcheck: improve support for non-POSIX charsets in generated report
On Thu, 16 Jun 2011 16:38:49 +0200 Nenad Cimerman wrote: TLDR: some time in the last 15 years, this bug against logcheck has been fixed, as far as i can tell > My system is setup with non-POSIX default locale (see below), using UTF-8 > character encoding. > This leads to many lines inside various log files (e.g. /var/log/syslog) > containing 'german umlaut' characters (äöüÄÖÜß). > Details... > > The script /usr/sbin/logcheck is usually run by the cron deamon, based on > /etc/cron.d/logcheck. This process runs in POSIX locale (LC_ALL=POSIX, > LANG=POSIX), despite /etc/default/locale being possibly set to a different You can set a different LANG in logcheck.conf if you need > Inside /usr/sbin/logcheck, the function sendreport() uses mail(1) or nail(1) logcheck now uses mime-construct(1) instead of either of these > By default, reports are sent 'inline' (not as an attachment) This can also be controlled with the MAILASATTACH option > Unfortunately mail(1) is responsible for the characterset issue, as it does > ignore the locale settings completely. mime-construct allows the charset to be set using the MIMEENCODING option in logcheck.conf So i think we can close this bug.
Bug#1071687: It's the lib
The bug is in python3-tvdb-api, not tvnamer as building a backport of 3.1-4 for bookworm makes tvnamer work again. apt list -a python3-tvdb-api Auflistung… Fertig python3-tvdb-api/now 3.1-4~bpo12+1 all [Installiert,lokal] python3-tvdb-api/stable,stable 3.1-2 all Would you consider uploading a backport of 3.1-4 to bookworm-backports to get tvnamer working again? Best regards, Martin signature.asc Description: PGP signature
Bug#1071594: debhelper: fails to start openssh-server after creating host keys due to systemd 255 change
On Thu, 23 May 2024 at 19:57, Niels Thykier wrote: > > Hi Michael and Luca > > I suspect you are better suited to debug this one. Let me know if I > should change anything in the maintscript generated. We have dependencies between units, we have ExecStartPre= and friends, there's many good ways to handle requirements before a service can be started. Hooking into dpkg reconfigure doesn't seem like a good idea, so I recommend to just fix that.
Bug#1071292: openssh-server: sshd fails to restart at package upgrade, future logins to server impossible
On Fri, May 17, 2024 at 09:42:05PM +0200, Sven-Haegar Koch wrote: > I just upgraded openssh as part of my normal "apt dist-upgrade" every > few days, from 1:9.7p1-4 to 1:9.7p1-5. > > The whole apt went through without any errors - but afterwards sshd > was no longer running / listening on its network ports. Hm, I haven't seen this elsewhere either in my own upgrades or from anyone else, and as you say the ssh.service logs don't give much to go on. Is there anything informative in /var/log/auth.log, perhaps? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071302: cppgir: diff for NMU version 2.0-2.1
Control: tags 1071302 + patch
Control: tags 1071302 + pending
Dear maintainer,
I've prepared an NMU for cppgir (versioned as 2.0-2.1) and
uploaded it to unstable.
Regards.
--
WBR, wRAR
diff -Nru cppgir-2.0/debian/changelog cppgir-2.0/debian/changelog
--- cppgir-2.0/debian/changelog 2024-01-08 13:48:52.0 +0500
+++ cppgir-2.0/debian/changelog 2024-05-23 23:50:03.0 +0500
@@ -1,3 +1,11 @@
+cppgir (2.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix crashing on Gio-2.0 (Closes: #1071302).
+ * Fix several other FTBFS reasons.
+
+ -- Andrey Rakhmatullin Thu, 23 May 2024 23:50:03 +0500
+
cppgir (2.0-2) unstable; urgency=medium
* Add gi-restrict-string-template-conversion-operator.patch from upstream Git.
diff -Nru cppgir-2.0/debian/patches/9a0dcf3ae382f153f20e483bd80f3dea97d98ee1.patch cppgir-2.0/debian/patches/9a0dcf3ae382f153f20e483bd80f3dea97d98ee1.patch
--- cppgir-2.0/debian/patches/9a0dcf3ae382f153f20e483bd80f3dea97d98ee1.patch 1970-01-01 05:00:00.0 +0500
+++ cppgir-2.0/debian/patches/9a0dcf3ae382f153f20e483bd80f3dea97d98ee1.patch 2024-05-23 22:25:45.0 +0500
@@ -0,0 +1,33 @@
+From 9a0dcf3ae382f153f20e483bd80f3dea97d98ee1 Mon Sep 17 00:00:00 2001
+From: Mark Nauwelaerts
+Date: Sat, 20 Jan 2024 14:33:29 +0100
+Subject: [PATCH] tools: avoid null pointer access
+
+Fixes issue #67
+---
+ tools/repository.cpp | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/tools/repository.cpp b/tools/repository.cpp
+index 9d54743..fcffcbe 100644
+--- a/tools/repository.cpp
b/tools/repository.cpp
+@@ -129,10 +129,13 @@ Repository::add(const key_type &girname, const mapped_type::tree_type &n)
+ auto it = self.index.find(qualified);
+ bool registered = false;
+
+- if (it != self.index.end()) {
++ if (girname.empty()) {
++// should not make it here
++assert(false);
++ } else if (it != self.index.end()) {
+ auto &e = it->second;
+ // merge in tree data for predefined
+-if (e.info->flags & TYPE_PREDEFINED) {
++if (e.info && (e.info->flags & TYPE_PREDEFINED)) {
+ e.tree = std::make_unique(n);
+ } else {
+ throw std::runtime_error(
+--
+GitLab
+
diff -Nru cppgir-2.0/debian/patches/a262132e608170142cebd10896d6679b4fe1f3cb.patch cppgir-2.0/debian/patches/a262132e608170142cebd10896d6679b4fe1f3cb.patch
--- cppgir-2.0/debian/patches/a262132e608170142cebd10896d6679b4fe1f3cb.patch 1970-01-01 05:00:00.0 +0500
+++ cppgir-2.0/debian/patches/a262132e608170142cebd10896d6679b4fe1f3cb.patch 2024-05-23 23:13:28.0 +0500
@@ -0,0 +1,33 @@
+From a262132e608170142cebd10896d6679b4fe1f3cb Mon Sep 17 00:00:00 2001
+From: Mark Nauwelaerts
+Date: Sun, 21 Jan 2024 12:58:23 +0100
+Subject: [PATCH] data: ignore some private glib symbols
+
+---
+ data/cppgir.ignore | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/data/cppgir.ignore b/data/cppgir.ignore
+index 17de080..3d7f569 100644
+--- a/data/cppgir.ignore
b/data/cppgir.ignore
+@@ -52,6 +52,16 @@ Gio:function:g_networking_init
+ Gio:method:g_io_module_(load|unload)
+ Gio:function:g_io_module_query
+
++# private parts of the above; these should not make into the GIRs
++# but they might if gobject-introspection was built with embedded glib (meson wrapper)
++GModule:constant:MODULE_IMPL_.*
++GLib:constant:TRACE_.*
++GLib:function:trace_.*
++GLib:function:set_prgname_once
++Gio:function:to_rrtype
++Gio:class:ThreadedResolver
++GObject:bitfield:IOCondition
++
+ # Gst
+ Gst:constant:ERROR_SYSTEM
+ Gst:callback:DebugFuncPtr
+--
+GitLab
+
diff -Nru cppgir-2.0/debian/patches/b4642d32c04c082aa48874320d49a602077f8d84.patch cppgir-2.0/debian/patches/b4642d32c04c082aa48874320d49a602077f8d84.patch
--- cppgir-2.0/debian/patches/b4642d32c04c082aa48874320d49a602077f8d84.patch 1970-01-01 05:00:00.0 +0500
+++ cppgir-2.0/debian/patches/b4642d32c04c082aa48874320d49a602077f8d84.patch 2024-05-23 23:02:56.0 +0500
@@ -0,0 +1,29 @@
+From b4642d32c04c082aa48874320d49a602077f8d84 Mon Sep 17 00:00:00 2001
+From: Mark Nauwelaerts
+Date: Sat, 20 Jan 2024 14:35:14 +0100
+Subject: [PATCH] tools: discard entries without name
+
+... such as glib:boxed entries
+---
+ tools/genns.cpp | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/tools/genns.cpp b/tools/genns.cpp
+index cc5336c..4d0db78 100644
+--- a/tools/genns.cpp
b/tools/genns.cpp
+@@ -1271,7 +1271,10 @@ public:
+ const auto &name = get_name(n.second, std::nothrow);
+ auto &el = n.first;
+ // redirect to oblivion
+- if (ctx.match_ignore.matches(ns, el, {name})) {
++ // empty name might originate from a glib:boxed with glib:name attribute
++ // discard those as well, as that is a glib type without C-type
++ // (which are not really useful in our situation)
++ if (name.empty() || ctx.match_ignore.matches(ns, el, {name})) {
+ logger(Log::INFO, "ignoring {} {}", el, name);
+ } else {
+ ctx.repo.add
Bug#1071691: nim: (build)-depends on obsolete pcre3 library
Source: nim Version: 1.6.10-1 Severity: serious Dear maintainer, Your package still (build-)depends on the old, obsolete PCRE library (i.e. libpcre3). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, the pcre3 library is being removed from Debian. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Maybe think of dropping nimgrep to get rid of the dependency or ask upstream to port to PCRE2. This is an add-on to the mass bug filing that was discussed on debian-devel in https://lists.debian.org/debian-devel/2021/11/msg00176.html
Bug#1071692: autopep8: please drop the now extraneous dependency on python3-lib2to3
Source: autopep8 Version: 2.1.0-1 Severity: important Dear Maintainer, 2to3 is slated for removal; please remove the now extraneous dependency. Greetings https://docs.python.org/3/library/2to3.html > Deprecated since version 3.11, will be removed in version 3.13 tchet@quieter:/tmp/autopep8$ grep 2to3 -r debian/changelog: * Add python3-lib2to3 as a dependency for bin:python3-autopep8. I'm not debian/control: python3-lib2to3 tchet@quieter:/tmp/autopep8$
Bug#1071690: Since 2.80.2: free(): double free detected in tcache 2 (observed in lomiri-indicator-network and lomiri-indicator-telephony-service)
Package: src:glib2.0 Version: 2.80.2-1 Severity: important Hi Simon, hi all, as reported on IRC, we are seeing test failures in lomiri-indicator-network and lomiri-telephony-service since a few weeks ago. The upstream bugs have been filed here showing more details: https://gitlab.com/ubports/development/core/lomiri-indicator-network/-/issues/111 https://gitlab.com/ubports/development/core/lomiri-telephony-service/-/issues/69 Cosima (@OPNA2608) from Ubuntu Touch was able to track it down to a single commit causing the issue + an MR fixing it: Quoting @OPNA2608: Bisected to https://gitlab.gnome.org/GNOME/glib/-/commit/3f30ec86cd11af9cf12f271f118460c9c13978a0, applying https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4073 fixes it on my end. Please provide this patch in glib2.0 in Debian unstable. Thanks! Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpyFoozyBVhP.pgp Description: Digitale PGP-Signatur
Bug#1064938: isospec - maintainer does not access email from ftp-master
Hi On Thu, May 23, 2024 at 08:55:46PM +0300, Adrian Bunk wrote: > Was this any misconfiguration on the debian.org side, > or is/was this any issue at alioth-lists.debian.net, > or what else might have gone wrong here? It seems to be fixed. My mailbox contains the last bounce on March, 8th. Bastian -- Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3
Bug#1033839: Packaging docker 24.0.9
On Fri, 17 May 2024 at 12:05, Tianon Gravi wrote: > (There's a task item on the project's list to document all this publicly > better, but it's definitely challenging, as I'm sure you can > imagine/understand.) Aha, it's public at https://github.com/moby/moby/pull/46772 (a little bit dated now, but describes the gist of the current state and is the best place to contribute on this point). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#1071689: cpl-plugin-visir-calib: visir-kit-4.4.2*.tar.gz is no longer downloadable
Package: cpl-plugin-visir-calib Version: 4.4.2+dfsg-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up cpl-plugin-visir-calib (4.4.2+dfsg-1) ... --2024-05-23 12:16:55-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:55 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:55-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-1.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:56 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:56-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-2.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:56 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:56-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-3.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:57 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:57-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-4.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:57 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:58-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-5.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:58 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:58-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-6.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:58 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:58-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:59 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:59-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-8.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:16:59 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:16:59-- ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-kit-4.4.2-9.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:00 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now dpkg: error processing package cpl-plugin-visir-calib (--configure): installed cpl-plugin-visir-calib package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.38-11) ... Errors were encountered while processing: cpl-plugin-visir-calib cheers, Andreas cpl-plugin-visir-calib_4.4.2+dfsg-1.log.gz Description: application/gzip
Bug#1071688: cpl-plugin-vimos-calib: vimos-kit-4.1.7*.tar.gz is no longer downloadable
Package: cpl-plugin-vimos-calib Version: 4.1.7+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up cpl-plugin-vimos-calib (4.1.7+dfsg-2) ... --2024-05-23 12:21:00-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:01 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:01-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-1.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:02 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:02-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-2.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:02 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:02-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-3.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:03 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:03-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-4.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:03 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:03-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-5.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:04 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:04-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-6.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:04 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:04-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:05 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:05-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-8.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:05 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:21:05-- ftp://ftp.eso.org/pub/dfs/pipelines/vimos/vimos-kit-4.1.7-9.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:21:06 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now dpkg: error processing package cpl-plugin-vimos-calib (--configure): installed cpl-plugin-vimos-calib package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.38-11) ... Errors were encountered while processing: cpl-plugin-vimos-calib cheers, Andreas cpl-plugin-vimos-calib_4.1.7+dfsg-2.log.gz Description: application/gzip
Bug#1071687: tvnamer: Tvnamer throws traceback
Package: tvnamer
Version: 3.0.4-1
Severity: normal
Dear Maintainer,
when trying to use tvnamer it throws a traceback:
```
tvnamer --dry-run --name="The Rookie" --lang="de" Am\ Limit\
\[201027_0220_sendung_roo\].mkv
Loading config: /home/martin/.config/tvnamer/tvnamer.json
# Starting tvnamer
# Found 1 episode
# Processing file: Am Limit [201027_0220_sendung_roo].mkv
# Detected series: The Rookie (season: 2, episode: 20)
Traceback (most recent call last):
File "/usr/bin/tvnamer", line 6, in
tvnamer.main.main()
File "/usr/share/tvnamer/main.py", line 474, in main
tvnamer(paths = sorted(args))
File "/usr/share/tvnamer/main.py", line 370, in tvnamer
processFile(tvdb_instance, episode)
File "/usr/share/tvnamer/main.py", line 175, in processFile
episode.populateFromTvdb(tvdb_instance, force_name=Config['force_name'],
series_id=Config['series_id'])
File "/usr/share/tvnamer/utils.py", line 641, in populateFromTvdb
show = tvdb_instance[force_name or self.seriesname]
~^^^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 1152, in __getitem__
sid = self._nameToSid(key)
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 1136, in _nameToSid
selected_series = self._getSeries(name)
^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 935, in _getSeries
all_series = self.search(series)
^^^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 914, in search
series_resp = self._getetsrc(self.config['url_getSeries'] % (series))
^^^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 874, in _getetsrc
src = self._loadUrl(url, language=language)
^
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 811, in _loadUrl
self.authorize()
File "/usr/lib/python3/dist-packages/tvdb_api.py", line 859, in authorize
r = self.session.post(
^^
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 635, in post
return self.request("POST", url, data=data, json=json, **kwargs)
^
File "/usr/lib/python3/dist-packages/requests_cache/session.py", line 115, in
request
return super().request(method, url, *args, **kwargs)
^
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 587, in
request
resp = self.send(prep, **send_kwargs)
^^
File "/usr/lib/python3/dist-packages/requests_cache/session.py", line 127, in
send
cache_key = self.cache.create_key(request, **kwargs)
TypeError: create_key() got an unexpected keyword argument 'timeout'
```
Best regards,
Martin
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-20-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tvnamer depends on:
ii python33.11.2-1+b1
ii python3-pkg-resources 66.1.1-1
ii python3-tvdb-api 3.1-2
tvnamer recommends no packages.
tvnamer suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#1071686: php-mockery: depends on obsolete pcre3 library
Package: php-mockery Severity: serious Dear maintainer, Your package still depends on the old, obsolete PCRE library (i.e. libpcre3). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, the pcre3 library is being removed from Debian. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ One of the patches already removes the composer dependency, so please also drop it from debian/control. This is an add-on to the mass bug filing that was discussed on debian-devel in https://lists.debian.org/debian-devel/2021/11/msg00176.html
Bug#1071685: cpl-plugin-uves-calib: uves-kit-6.1.8*.tar.gz is no longer downloadable
Package: cpl-plugin-uves-calib Version: 6.1.8+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up cpl-plugin-uves-calib (6.1.8+dfsg-2) ... --2024-05-23 12:18:15-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:16 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:16-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-1.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:17 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:17-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-2.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:17 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:17-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-3.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:18 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:18-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-4.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:18 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:18-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-5.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:19 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:19-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-6.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:19 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:19-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:20 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:20-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-8.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:20 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:18:20-- ftp://ftp.eso.org/pub/dfs/pipelines/uves/uves-kit-6.1.8-9.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:18:21 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now dpkg: error processing package cpl-plugin-uves-calib (--configure): installed cpl-plugin-uves-calib package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.38-11) ... Errors were encountered while processing: cpl-plugin-uves-calib cheers, Andreas cpl-plugin-uves-calib_6.1.8+dfsg-2.log.gz Description: application/gzip
Bug#1070659: transition: re2
Hi Emilio (2024.05.22_07:03:30_+) > Go ahead. Uploaded, built, and installed everywhere. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1071683: confget: autopkgtest regression in testing
Source: confget Version: 5.1.2-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Hi Maintainer Sometime around 2024-02-27, confget's autopkgtest regressed in testing [1]. I've copied what I hope is the relevant part of the log below. Regards Graham [1] https://ci.debian.net/packages/c/confget/testing/amd64/ 95s autopkgtest [19:08:12]: test feature-check: [--- 95s error: unexpected argument '-q' found 95s 95s tip: to pass '-q' as a value, use '-- -q' 95s 95s Usage: feature-check [OPTIONS] [EXPRESSIONS]... 95s autopkgtest [19:08:12]: test feature-check: ---]
Bug#1071684: pkg-php-tools: composer library dependency generation
Package: pkg-php-tools Severity: important The dependency generation in share/php/pkgtools/base/dependency.php for "lib-" prefixed composer dependencies needs fixing. I caught it by it using libpcre3, which should be libpcre2-8-0 now. But some other generated names are also outdated and should be brought in sync with the current php interpreter version.
Bug#1070256: closed by Debian FTP Masters (reply to Alec Leamas ) (Bug#1070256: fixed in libcxx-serial 1.2.1-6)
Control: reopen -1 On Sun, May 12, 2024 at 07:09:07PM +, Debian Bug Tracking System wrote: >... > Changes: > libcxx-serial (1.2.1-6) trixie; urgency=medium > . >* Avoid crash when running with nocheck profile. Closes: #1070256 >... 1.2.1-7 does still FTBFS: https://buildd.debian.org/status/fetch.php?pkg=libcxx-serial&arch=sh4&ver=1.2.1-7&stamp=1715548569&raw=0 ifeq (,$(findstring nocheck,$(DEB_BUILD_PROFILES))) ENABLE_TESTS := ON else ENABLE_TESTS := OFF endif This should be DEB_BUILD_OPTIONS, not DEB_BUILD_PROFILES. cu Adrian
Bug#1071682: cpl-plugin-muse-calib: muse-kit-2.8.7*.tar.gz is no longer downloadable
Package: cpl-plugin-muse-calib Version: 2.8.7+dfsg-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up cpl-plugin-muse-calib (2.8.7+dfsg-3) ... --2024-05-23 12:19:37-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:38 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:38-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-1.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:38 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:38-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-2.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:39 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:39-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-3.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:39 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:39-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-4.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:40 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:40-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-5.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:40 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:40-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-6.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:41 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:41-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:41 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:41-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-8.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:42 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:42-- ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.8.7-9.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:42 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now dpkg: error processing package cpl-plugin-muse-calib (--configure): installed cpl-plugin-muse-calib package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.38-11) ... Errors were encountered while processing: cpl-plugin-muse-calib cheers, Andreas cpl-plugin-muse-calib_2.8.7+dfsg-3.log.gz Description: application/gzip
Bug#1030119: Bug#1018260: openssh-server: fills the log with "deprecated reading of user environment enabled"
Control: tag -1 patch On Mon, May 01, 2023 at 03:57:38PM +0100, Richard Lewis wrote: > Was there an update on this bug against release-notes: the MR against openssh > at > https://salsa.debian.org/ssh-team/openssh/-/merge_requests/21/diffs > doesnt seem to be merged - has this been parked? After some of the more recent discussion, I'm persuaded that I should move up the timeline I proposed, and remove this and document the removal in the release notes of the same Debian release. > Based on the text in that MR , but if I i used this feature i would > want to know: > - can this prevent me logging in? (eg if i am doing the upgrade over ssh) > - will it drop my ssh connection (release-notes does iirc advise > upgrading inside tmux or screen) > - what do i do if i need the settings in pam-envionment - can i add > them to ssh_config? (I assume re-enabling a > deprecated setting is not a good thing to recommend in release-notes) > (and should i do so before or after upgrading?) > > > The release notes could say something like: > > > ssh no longer reads ~/.pam-environment > > The ssh package, which allows > secure login to remote systems, no longer reads the user's > ~/.pam_environment file by default. > See for details. > If you used this feature, you should move variables set in > ~/.pam_environment file to > ~/.ssh/ssh_config before upgrading . > > > > (should there be something about the pam deprecation itself?) Thanks for this. I've adapted these notes into https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/204. (They weren't quite right in some areas: any changes have to be made on the server, not the client, and the only non-root-accessible sshd configuration options that are relevant to this such as ~/.ssh/environment are disabled by default, so I just resorted to suggesting that people move settings to their shell initialization files instead. It isn't perfect, but I think it's OK to assume that people who've gone to the effort of setting this can figure something out given the hint.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064938: isospec - maintainer does not access email from ftp-master
Hi, given neither debian.org nor ftp-master.debian.org have a DMARC policy, it should be a configuration error on alioth-lists.debian.net. (Arguably mailing lists should not impersonate other domains outside their control and set "From:" to an address controlled by the mailing list operator.) Ansgar On Thu, 2024-05-23 at 20:55 +0300, Adrian Bunk wrote: > Hi Bastian, > > The Debichem Group maintains ~ 140 packages with this maintainer > address > at lists.alioth.debian.org. > > Was this any misconfiguration on the debian.org side, > or is/was this any issue at alioth-lists.debian.net, > or what else might have gone wrong here? > > Thanks > Adrian > > > > On Tue, Feb 27, 2024 at 11:23:14PM +0100, Bastian Blank wrote: > > Package: isospec > > Severity: serious > > > > - Forwarded message from > > debichem-devel-ow...@alioth-lists.debian.net - > > > > From: debichem-devel-ow...@alioth-lists.debian.net > > To: ftpmas...@ftp-master.debian.org > > Subject: Processing of isospec_2.2.1-4.1~exp2_source.changes > > > > You are not allowed to post to this mailing list From: a domain > > which > > publishes a DMARC policy of reject or quarantine, and your message > > has > > been automatically rejected. If you think that your messages are > > being rejected in error, contact the mailing list owner at > > debichem-devel-ow...@alioth-lists.debian.net. > > > > > > Date: Sat, 24 Feb 2024 02:03:38 + > > From: Debian FTP Masters > > To: debichem-de...@lists.alioth.debian.org > > Subject: Processing of isospec_2.2.1-4.1~exp2_source.changes > > > > isospec_2.2.1-4.1~exp2_source.changes uploaded successfully to > > localhost > > along with the files: > > isospec_2.2.1-4.1~exp2.dsc > > isospec_2.2.1-4.1~exp2.debian.tar.xz > > isospec_2.2.1-4.1~exp2_source.buildinfo > > > > Greetings, > > > > Your Debian queue daemon (running on host usper.debian.org) > > > > > > > > - End forwarded message - > > > > -- > > Hailing frequencies open, Captain. >
Bug#1071681: php-ml-iri: depends on obsolete pcre3 library
Package: php-ml-iri Severity: serious Dear maintainer, Your package still depends on the old, obsolete PCRE library (i.e. libpcre3). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, the pcre3 library is being removed from Debian. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ The dependency is auto-generated by dh-sequence-phpcomposer. I do not see it actually being used and the php interpreter has long moved to pcre2. This is an add-on to the mass bug filing that was discussed on debian-devel in https://lists.debian.org/debian-devel/2021/11/msg00176.html
Bug#1071680: ocaml-linenoise FTBFS on bytecode architectures
Source: ocaml-linenoise Version: 1.5.1-1 Severity: important Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=ocaml-linenoise&ver=1.5.1-1 ... dh_missing -a -O--buildsystem=ocaml_dune dh_missing: warning: usr/lib/ocaml/linenoise/liblinenoise_stubs.a exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting The following debhelper tools have reported what they installed (with files per package) * dh_install: liblinenoise-ocaml (3), liblinenoise-ocaml-dev (7) * dh_installdocs: liblinenoise-ocaml (0), liblinenoise-ocaml-dev (2) * dh_installexamples: liblinenoise-ocaml (0), liblinenoise-ocaml-dev (2) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.md.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. make: *** [debian/rules:7: binary-arch] Error 255
Bug#1064938: isospec - maintainer does not access email from ftp-master
Hi Bastian, The Debichem Group maintains ~ 140 packages with this maintainer address at lists.alioth.debian.org. Was this any misconfiguration on the debian.org side, or is/was this any issue at alioth-lists.debian.net, or what else might have gone wrong here? Thanks Adrian On Tue, Feb 27, 2024 at 11:23:14PM +0100, Bastian Blank wrote: > Package: isospec > Severity: serious > > - Forwarded message from debichem-devel-ow...@alioth-lists.debian.net > - > > From: debichem-devel-ow...@alioth-lists.debian.net > To: ftpmas...@ftp-master.debian.org > Subject: Processing of isospec_2.2.1-4.1~exp2_source.changes > > You are not allowed to post to this mailing list From: a domain which > publishes a DMARC policy of reject or quarantine, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > debichem-devel-ow...@alioth-lists.debian.net. > > > Date: Sat, 24 Feb 2024 02:03:38 + > From: Debian FTP Masters > To: debichem-de...@lists.alioth.debian.org > Subject: Processing of isospec_2.2.1-4.1~exp2_source.changes > > isospec_2.2.1-4.1~exp2_source.changes uploaded successfully to localhost > along with the files: > isospec_2.2.1-4.1~exp2.dsc > isospec_2.2.1-4.1~exp2.debian.tar.xz > isospec_2.2.1-4.1~exp2_source.buildinfo > > Greetings, > > Your Debian queue daemon (running on host usper.debian.org) > > > > - End forwarded message - > > -- > Hailing frequencies open, Captain.
Bug#1071656: autopkgtest failure on archs other than amd64 and i386
Hi Jeroen, I ran the tests on an arm64 machine, This is the diff of the test that fails: *** Running "Correlate a file with heading with delta crossing 360 degrees CCW" test + valgrind --error-exitcode=126 --tool=memcheck --leak-check=yes --num-callers=30 --log-file=/tmp/gpscorrelate/gpscorrelate/tests/log/test167-valgrind.log /usr/bin/gpscorrelate --heading --max-heading 90 -O -45 -z 0 -g /tmp/gpscorrelate/gpscorrelate/tests/staging/track13.gpx /tmp/gpscorrelate/gpscorrelate/tests/log/test.jpg + exiv2 -pv pr /tmp/gpscorrelate/gpscorrelate/tests/log/test.jpg + EXITCODE=0 + set +x Test test167 FAILED: unexpected output --- /tmp/gpscorrelate/gpscorrelate/tests/data/test167.result2024-05-23 15:44:05.115054075 + +++ /tmp/gpscorrelate/gpscorrelate/tests/log/test167.out2024-05-23 16:49:30.700053733 + @@ -32,6 +32,6 @@ 0x0006 GPSInfo GPSAltitude Rational1 4234/10 0x0007 GPSInfo GPSTimeStampRational3 12/1 34/1 35/1 0x000e GPSInfo GPSTrackRef Ascii 2 T -0x000f GPSInfo GPSTrackRational1 323/1 +0x000f GPSInfo GPSTrackRational1 322/1 0x0012 GPSInfo GPSMapDatum Ascii 7 WGS-84 0x001d GPSInfo GPSDateStampAscii 11 2012:11:22 I am not entirely sure why it outputs 322/1 instead of 323/1 on arm. I will reach out to the upstream maintainer regarding this. On 23/05/24 13:58, Jeroen Ploemen wrote: Package: gpscorrelate Severity: normal Control: found -1 2.1-1 hi Shriram, it seems the recent upload of gpscorrelate has issues preventing migration to testing [1]: the autopkgtest fails for all architectures except amd64 and i386. This could be something really simply causing the output on these platforms to differ in some unimportant way from what the tests expect (like the architecture getting recorded as part of the output with upstream only taking the "standard" archs into account), or something more substantial (actual bugs only triggered on these "other" archs). Some archs have 30 tests failing (s390x), some only one (arm64); and then there's valgrind that is not available on some architectures. I already pushed a fix for the valgrind part to git. Please investigate the failures on the archs where the autopkgtest did run. [1]https://qa.debian.org/excuses.php?package=gpscorrelate Best Regards, -- Shriram Ravindranathan OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059133: dogecoin: FTBFS: error: invalid ‘static_cast’ from type ‘boost::detail::function::function_buffer_members::obj_ptr_t’ {aka ‘void*’} to type ‘void (*)(bool, const CBlockIndex*)’
Control: reassign -1 libboost1.83-dev 1.83.0-2.1 Control: retitle -1 libboost1.83-dev: Please add upstream fix needed for dogecoin Control: affects -1 src:dogecoin Control: tags -1 patch Control: forwarded -1 https://github.com/boostorg/function/pull/47 On Tue, Jan 09, 2024 at 06:37:44PM -0500, Chad Jacob Milios wrote: > Please see https://github.com/boostorg/function/pull/47 and let us know if > that minor modification helps you out. Yes, it does. cu Adrian
Bug#1071663: RFP: minetest-mod-voxelibre -- voxelibre mod for minetest
Matthias Geiger writes: > […] > > Since this is an RFP I suggest you file a different one for Mineclonia. > If someone decides to package either they can draw their own conclusions. Thanks, maybe I will. I am not against packaging VoxeLibre, I just want people to know what they are in for: An upstream that breaks things and is not particularly receptive to approaches that don't break stuff (and arguably that was a big reason for the Mineclonia fork event initially). signature.asc Description: PGP signature
Bug#1071679: eclipse-titan: depends on obsolete pcre3 library
Package: eclipse-titan Severity: serious Dear maintainer, Your package still depends on the old, obsolete PCRE library (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, the pcre3 library is being removed from Debian. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ The dependency seems to be unused, so it should be fine to drop it. This is an add-on to the mass bug filing that was discussed on debian-devel in https://lists.debian.org/debian-devel/2021/11/msg00176.html
Bug#1071677: cpl-plugin-amber-calib: amber-kit-4.4.3*.tar.gz is no longer downloadable
Package: cpl-plugin-amber-calib Version: 4.4.3+dfsg-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up cpl-plugin-amber-calib (4.4.3+dfsg-1) ... --2024-05-23 12:17:50-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:50 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:50-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-1.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:51 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:51-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-2.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:51 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:51-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-3.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:52 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:52-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-4.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:52 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:52-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-5.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:53 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:53-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-6.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:54 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:54-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:54 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:54-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-8.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:55 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:17:55-- ftp://ftp.eso.org/pub/dfs/pipelines/amber/amber-kit-4.4.3-9.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:17:55 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now dpkg: error processing package cpl-plugin-amber-calib (--configure): installed cpl-plugin-amber-calib package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.38-11) ... Errors were encountered while processing: cpl-plugin-amber-calib cheers, Andreas cpl-plugin-amber-calib_4.4.3+dfsg-1.log.gz Description: application/gzip
Bug#1071678: cpl-plugin-fors-calib: fors-kit-5.5.7*.tar.gz is no longer downloadable
Package: cpl-plugin-fors-calib Version: 5.5.7+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up cpl-plugin-fors-calib (5.5.7+dfsg-2) ... --2024-05-23 12:19:11-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:12 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:12-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-1.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:13 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:13-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-2.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:13 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:13-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-3.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:14 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:14-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-4.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:14 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:14-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-5.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:15 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:15-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-6.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:15 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:15-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-7.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:16 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:16-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-8.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:17 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now --2024-05-23 12:19:17-- ftp://ftp.eso.org/pub/dfs/pipelines/fors/fors-kit-5.5.7-9.tar.gz Connecting to 10.99.36.1:3128... connected. Proxy request sent, awaiting response... 404 Not Found 2024-05-23 12:19:17 ERROR 404: Not Found. gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error is not recoverable: exiting now dpkg: error processing package cpl-plugin-fors-calib (--configure): installed cpl-plugin-fors-calib package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.38-11) ... Errors were encountered while processing: cpl-plugin-fors-calib cheers, Andreas cpl-plugin-fors-calib_5.5.7+dfsg-2.log.gz Description: application/gzip
Bug#966570: RFP: libamf -- Advanced Media Framework (AMF) SDK
On 2024-05-23 08:42, Diederik de Haas wrote: On 30 Jul 2020 16:00:44 -0400 Louis-Philippe Véronneau wrote: I'm happy to help or sponsor work for this, but I'm not confident I understand the codebase enough to be packaging this myself. There has been a reply to this, but it didn't directly To/CC you, so I'm replying to make sure you're at least aware of it. Thanks for the ping, I indeed hadn't seen the reply :P Braiam, still up to maintaining this package in Debian? I don't see a link to a git repository in your last message. Happy to try to build it and see if I can upload it if it looks good. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Bug#1071662: chromium: Wrapper script does not correctly pass arguments to Chromium
Thanks for the heads up. While I work on fixing this, a temporary workaround you can use is ' -- ' before --user-agent. Eg, chromium --headless --no-sandbox -- --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" On 5/23/24 07:11, Remco de Man wrote: Package: chromium Version: 125.0.6422.76-1~deb12u1 Severity: normal Dear Maintainer, When running 125.0.6422.76-1~deb12u1, when passing arguments to the chromium wrapper script included in the Debian package, not all arguments are passed correctly to the Chromium binary. This happens especially when the arguments need any type of quoting, like in the case of passing a custom User-Agent with --user-agent. A minimal reproduction sample for me is running the following command: chromium --headless --no-sandbox --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36" It seems that because the user agent contains spaces, this is not correctly passed to the chromium binary. The regression was not present in the previous security release, 125.0.6422.60-1~deb12u1, and seems to be caused by change https://salsa.debian.org/chromium-team/chromium/-/commit/dc792dc4f3bfdd3e00f5fe7b7bf314077ed301bb Because of this, many of our headless usage scenarios do not work correctly anymore, since Chromium exits with the 'Multiple targets are not supported' message, because it parses some of the user agent as seperate arguments to its binary. Seems like the wrapper script should be patched to handle this scenario, or the change should be reverted. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.82 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages chromium depends on: ii chromium-common125.0.6422.76-1~deb12u1 ii libasound2 1.2.8-1+b1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-02.46.0-5 ii libatomic1 12.2.0-14 ii libatspi2.0-0 2.46.0-5 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libcups2 2.4.2-3+deb12u5 ii libdav1d6 1.0.0-2+deb12u1 ii libdbus-1-31.14.10-1~deb12u1 ii libdouble-conversion3 3.2.1-1 ii libdrm22.4.114-1+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-1 ii libflac12 1.4.2+ds-2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgbm122.3.6-1+deb12u1 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libharfbuzz-subset06.0.0+dfsg-3 ii libharfbuzz0b 6.0.0+dfsg-3 ii libjpeg62-turbo1:2.1.5-2 ii libjsoncpp25 1.9.5-4 ii liblcms2-2 2.14-2 ii libminizip11.1-8+deb12u1 ii libnspr4 2:4.35-1 ii libnss32:3.87.1-1 ii libopenh264-7 2.3.1+dfsg-3 ii libopenjp2-7 2.5.0-2 ii libopus0 1.3.1-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-161.6.39-2 ii libpulse0 16.1+dfsg1-2+b1 ii libsnappy1v5 1.1.9-3 ii libstdc++6 12.2.0-14 ii libwoff1 1.0.2-2 ii libx11-6 2:1.8.4-2+deb12u2 ii libxcb11.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage11:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon0 1.5.0-1 ii libxml22.9.14+dfsg-1.3~deb12u1 ii libxnvctrl0525.85.05-3~deb12u1 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 125.0.6422.76-1~deb12u1 Versions of packages chromium suggests: ii chromium-driver 125.0.6422.76-1~deb12u1 pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.36-9+deb12u7 ii libdrm2 2.4.114-1+b1 ii libjsoncpp25 1.9.5-4 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2+deb12u2 ii libxnvctrl0 525.85.05-3~deb12u1 ii x11-utils 7.7+5 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages chromium-common recommends: ii chromium-sandbox 125.0.6422.76-1~deb12u1 pn fonts-liberation ii libgl1-mesa-dri22.3.6-1+deb12u1 pn notification-daemon pn system-config-printer pn udev pn upower Versions of packages chromium-
Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2
Same here, Intel AX201. Bug appears both on 6.1.0-20 and 6.1.0-21 Rémy On Tue, 7 May 2024 01:07:49 +0200 Udo Richter wrote: > Hi, > > Seeing exactly the same bug with an Broadcom Corp. BCM2045B (BDC-2.1) > bluetooth device, so its not just the Intel AX211. > > Jeremy, thanks for tracking this down! > > Udo > >
Bug#1053004: CVE-2019-10784 and CVE-2023-40619
On Wed, May 22, 2024 at 3:00 PM Moritz Muehlenhoff wrote: > > On Wed, May 22, 2024 at 02:42:58PM -0300, Leandro Cunha wrote: > > Hi everyone, > > > > On Wed, May 22, 2024 at 12:39 PM Moritz Mühlenhoff wrote: > > > > > > Am Wed, Mar 06, 2024 at 06:39:01AM -0300 schrieb Leandro Cunha: > > > > Hi Christoph Berg, > > > > > > > > On Wed, Mar 6, 2024 at 5:42 AM Christoph Berg wrote: > > > > > > > > > > Re: Leandro Cunha > > > > > > The > > > > > > next job would be to make it available through backports and I would > > > > > > choose to remove this package from stable. But I would only leave > > > > > > bookworm backports due to other bugs found (this CVEs too) and fixed > > > > > > in 7.14.7. > > > > > > I have to search about the status of backports to oldstable. But I'm > > > > > > also studying the possibility of working with patches for these two > > > > > > versions. > > > > > > > > > > Why would you want to remove it from stable? In closed environments, > > > > > CVEs are often not a problem. > > > > > > > > > > Christoph > > > > > > > > In addition to the CVEs, phppgadmin which is present in stable does > > > > not connect to PostgreSQL 15 and 16 without a patch I inserted in > > > > 7.13.0+dfsg-3, but I can add the same patch by reopening bug #1029516 > > > > or opening another important bug (I am aware that the bug must have a > > > > severity greater than important)[3] for the stable and submission of > > > > new bug to the release team for approval. That way it would be > > > > released in a future release a version with this issue fixed (if > > > > approved). But CVE-2023-40619 is treated with critical severity and > > > > CVE-2019-10784 is also critical according to the NVD[1][2]. The Debian > > > > LTS team handled this with DLA-3644-1 (CVE-2023-40619)[4] in buster > > > > (oldoldstable) and of OpenSUSE team also handled both CVEs in > > > > Leap[5][6]. > > > > Removing this package in stable will not leave users without them and > > > > we can release it in backports. > > > > I can treat this as a job of ensuring the quality of what is > > > > distributed by Debian. > > > > > > Agreed, if the package is actually broken with the version of PostgreSQL > > > in stable and if there's no sensible backport for the open security > > > issues, > > > then let's rather remove it by the next point release. > > > > > > Cheers, > > > Moritz > > > > It's the best thing to do, the package with the necessary corrections > > is already present in bookworm-backports and the user just needs to > > run apt install -t bookworm-backports phppgadmin[1][2][3] with > > sponsorship of Christoph Berg (thank you for that) and thanks also to > > the Debian Security Team. > > Ack, will you do the removal request? You can do that with > "reportbug release.debian.org" and then selecting the > "rm stable/testing removal requests" option. > > Cheers, > Moritz Already in draft. Once it's ready, I'll send it to BTS and using the template of the reportbug. I'll get some DD to review it before sending it too tonight on a video call. https://wiki.debian.org/reportbug -- Cheers, Leandro Cunha
Bug#1071676: Packages-arch-specific: Remove ethtool?
Package: buildd.debian.org Severity: normal Tags: patch ethtool has been declared as "Architecture: linux-any" since 1:5.8-1 (see https://bugs.debian.org/961965), which predates oldstable. It's still a problem in oldoldstable, but I'm not sure Packages-arch-specific systematically cares about that. Can we just remove it? diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..d15ba5f 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -56,6 +56,5 @@ fdflush: alpha amd64 i386 # amd64/i3 # linux specific %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %vmpk: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 # needs RtMidi/real ALSA, see #557899 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071675: duplicity: SSH broken with Paramiko 3.4
Package: duplicity Version: 2.1.4-3+b1 Severity: important When trying to do backup to an sftp:// target Duplicity fails since python3-paramiko was updated to 3.4.0-1, with the following error which looks like an API change in Paramiko: ssh: Unknown exception: public_blob ssh: Traceback (most recent call last): ssh: File "/usr/lib/python3/dist-packages/paramiko/transport.py", line 2220, in run ssh: handler(m) ssh: File "/usr/lib/python3/dist-packages/paramiko/auth_handler.py", line 394, in _parse_service_accept ssh: key_type, bits = self._get_key_type_and_bits(self.private_key) ssh: ^ ssh: File "/usr/lib/python3/dist-packages/paramiko/auth_handler.py", line 218, in _get_key_type_and_bits ssh: if key.public_blob: ssh:^^^ ssh: File "/usr/lib/python3/dist-packages/paramiko/agent.py", line 476, in __getattr__ ssh: raise AttributeError(name) ssh: AttributeError: public_blob ssh: BackendException: ssh connection to ** failed: public_blob Downgrading python3-paramiko to 2.12.0-2 makes Duplicity work again, I assume Duplicity needs to be updated/fixed to work with the new Paramiko API. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages duplicity depends on: ii gnupg 2.2.43-6 ii libc6 2.38-11 ii librsync2t642.3.4-1.1 ii python3 3.11.8-1 ii python3-fasteners 0.18-2 ii python3-setuptools-scm 8.0.4-2 ii python3.11 3.11.9-1 Versions of packages duplicity recommends: ii python3-oauthlib 3.2.2-1 ii python3-paramiko 3.4.0-1 ii python3-pexpect 4.9-2 ii python3-urllib3 1.26.18-2 ii rsync 3.3.0-1 Versions of packages duplicity suggests: pn lftp pn ncftp pn par2 pn python3-boto3 ii python3-pip 24.0+dfsg-2 pn python3-swiftclient pn tahoe-lafs -- no debconf information
Bug#1063161:
On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote: > We are just lacking a configuration symbol. Diederik, starting with > linux 6.8 AMD PMF requires TEE. Do you want me to send a MR? Sure. Bit surprised it wouldn't be automatically selected though. signature.asc Description: This is a digitally signed message part.
Bug#1071674: Packages-arch-specific: Remove linux-wlan-ng
Package: buildd.debian.org Severity: normal Tags: patch linux-wlan-ng hasn't been in any stable release for years, and was removed from unstable in November 2023 (see https://tracker.debian.org/pkg/linux-wlan-ng), so it's no longer in the archive at all. There should be no need to keep it in Packages-arch-specific any more. diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..9112a32 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -22,7 +22,6 @@ fdflush: alpha amd64 i386 # amd64/i386/alpha specific %libgcr410: i386 amd64 # [ANAIS] -%linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS [?] # xorg stuff %xf86-input-multitouch: !s390x Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#961970: vmpk: Please change to Architecture: linux-any
Control: reassign -1 buildd.debian.org Control: retitle -1 Packages-arch-specific: Remove vmpk Control: tag -1 patch On Tue, Apr 05, 2022 at 09:00:20PM +0200, Pedro Lopez-Cabanillas wrote: > > vmpk is linux specific (#557899). > > This was true many years ago, when vmpk was based on RtMidi. It was > replaced by drumstick-rt in vmpk-0.6.0 released in 2014-09-07. > > Since then, vmpk has been successfully ported to FreeBSD. > https://www.freshports.org/audio/vmpk > https://www.freshports.org/audio/drumstick This suggests that we should remove vmpk from Packages-arch-specific. As it happens, kFreeBSD has been removed from debian-ports, and libdrumstick-dev hasn't been built for Hurd (https://buildd.debian.org/status/package.php?p=libdrumstick) - but that just means that vmpk will automatically sit in dep-wait, and there's no need to have a special exception for it. diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..05a7b08 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -58,4 +58,3 @@ fdflush: alpha amd64 i386 # amd64/i3 %bidentd: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %ethtool: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 %linuxtv-dvb-apps: !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 -%vmpk: !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 # needs RtMidi/real ALSA, see #557899 Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1066822: linuxtv-dvb-apps: diff for NMU version 1.1.1+rev1500-1.5
Control: tags 961967 + patch
Control: tags 961967 + pending
Control: tags 1066822 + patch
Control: tags 1066822 + pending
Dear maintainer,
I've prepared an NMU for linuxtv-dvb-apps (versioned as
1.1.1+rev1500-1.5) and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.
I would have sent these as git merge requests of some form, but
Vcs-Git/Vcs-Browser are still set to the obsolete anonscm.debian.org and
I couldn't find any corresponding repositories on salsa, so this was the
best I could do; you should be able to find more detailed history via
"dgit clone linuxtv-dvb-apps" if you need it.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2020-07-26 19:42:38.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2024-05-23 16:49:59.0 +0100
@@ -1,3 +1,11 @@
+linuxtv-dvb-apps (1.1.1+rev1500-1.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around UAPI break in Linux input events (Closes: #1066822).
+ * Set Architecture to linux-any (Closes: #961967).
+
+ -- Colin Watson Thu, 23 May 2024 16:49:59 +0100
+
linuxtv-dvb-apps (1.1.1+rev1500-1.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/control linuxtv-dvb-apps-1.1.1+rev1500/debian/control
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2016-04-07 17:11:50.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2024-05-23 16:49:59.0 +0100
@@ -11,7 +11,7 @@
Homepage: http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
Package: dvb-apps
-Architecture: any
+Architecture: linux-any
Depends:
${shlibs:Depends},
makedev | udev,
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2020-07-26 19:38:59.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2024-05-23 16:49:59.0 +0100
@@ -11,3 +11,4 @@
dst_test-no-set-id.patch
glibc-stime.patch
gcc-10-sid-redefinition.patch
+work-around-uapi-break-in-linux-input-ev.patch
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 1970-01-01 01:00:00.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 2024-05-23 16:49:59.0 +0100
@@ -0,0 +1,25 @@
+From: Colin Watson
+Date: Thu, 23 May 2024 16:38:37 +0100
+X-Dgit-Generated: 1.1.1+rev1500-1.5 5d2fca4cdce8ddcdf7e13a0681da7b381301
+Subject: Work around UAPI break in Linux input events
+
+See
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f.
+
+Closes: #1066822
+
+---
+
+diff --git a/test/evtest.c b/test/evtest.c
+index a61593e..73fb5af 100644
+--- a/test/evtest.c
b/test/evtest.c
+@@ -241,7 +241,7 @@ int main (int argc, char **argv)
+
+ for (i = 0; i < rd / (int) sizeof(struct input_event); i++)
+ printf("Event: time %ld.%06ld, type %d (%s), code %d (%s), value %d\n",
+-ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
++ev[i].input_event_sec, ev[i].input_event_usec, ev[i].type,
+ events[ev[i].type] ? events[ev[i].type] : "?",
+ ev[i].code,
+ names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? names[ev[i].type][ev[i].code] : "?") : "?",
Bug#1068250: Switch to 'ng', but calling it 'dracut', don't add 'ng'?
Fedora, Arch kept calling the package dracut. They did not add the "-ng" appendix. Would it be an option for Debian to keep calling it dracut even though the git upstream repository will be changed to dracut-ng? If permissible, that might be easier. It seems unlikely that the dracut without the "-ng" will come back to live. It just seems like "ng" is the legitimate and unchallenged successor.
Bug#1019063: maxima: no Homepage field
Control: tags -1 + patch Here is a concrete patch to fix this. diff --git a/debian/control b/debian/control index 97b6d17..cb8e8b6 100644 --- a/debian/control +++ b/debian/control @@ -4,6 +4,7 @@ Priority: optional Maintainer: Camm Maguire Build-Depends: gcl ( >= 2.6.14-4 ) , texinfo, automake, debhelper ( >= 13 ), autoconf, gawk | awk, texlive-latex-recommended, sharutils, python3 Standards-Version: 4.6.0.1 +Homepage: https://maxima.sourceforge.io/ Package: maxima Architecture: any -- Happy hacking Petter Reinholdtsen
Bug#1063161:
Hi Nathan, Le 2024-05-23 17:12, Nathan MALO a écrit : > Hello ! > > Thank you very much for enabling those two features in the kernel. > Your work is much appreciated ! > > Maybe I am missing something but I've download the 6.8.9-1 package from > here > http://ftp.us.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.8.9-amd64_6.8.9-1_amd64.deb > and while fiddling with it, I was not able to find the keys CONFIG_AMDTEE > and CONFIG_AMD_PMF in the /boot/config file. > > I was able to see those two keys activated in salsa : > https://salsa.debian.org/kernel-team/linux/-/blob/sid/debian/config/amd64/config?ref_type=heads > > Am I missing something ? > Maybe the package was not rebuilt with this new configuration ? We are just lacking a configuration symbol. Diederik, starting with linux 6.8 AMD PMF requires TEE. Do you want me to send a MR? > Thanks for your help ! Thanks for the report, Vincent signature.asc Description: PGP signature
Bug#961964: bidentd: diff for NMU version 1.1.4-1.3
Control: tags 961964 + patch
Control: tags 961964 + pending
Dear maintainer,
I've prepared an NMU for bidentd (versioned as 1.1.4-1.3) and uploaded
it to DELAYED/5. Please feel free to tell me if I should delay it
longer.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru bidentd-1.1.4/debian/changelog bidentd-1.1.4/debian/changelog
--- bidentd-1.1.4/debian/changelog 2020-03-11 13:12:52.0 +
+++ bidentd-1.1.4/debian/changelog 2024-05-23 16:23:26.0 +0100
@@ -1,3 +1,10 @@
+bidentd (1.1.4-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Set Architecture to linux-any (closes: #961964).
+
+ -- Colin Watson Thu, 23 May 2024 16:23:26 +0100
+
bidentd (1.1.4-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru bidentd-1.1.4/debian/control bidentd-1.1.4/debian/control
--- bidentd-1.1.4/debian/control 2020-03-11 13:12:52.0 +
+++ bidentd-1.1.4/debian/control 2024-05-23 16:23:26.0 +0100
@@ -6,7 +6,7 @@
Standards-Version: 3.8.4
Package: bidentd
-Architecture: any
+Architecture: linux-any
Depends: ${shlibs:Depends}, ${misc:Depends}, netbase, debconf, openbsd-inetd | inet-superserver
Provides: ident-server
Conflicts: ident-server
Bug#933032: Add Salsa-CI integration
Le 16/05/2024 à 04:38, Otto Kekäläinen a écrit : I did confirm by running the CI at https://salsa.debian.org/mariadb-team/mariadb-connector-java/-/pipelines that it works, so there is no technical reason not to have CI enabled in the repository. There is a practical reason, it doesn't solve any problem, and there is an ethical reason, it would consume unnecessary resources.
Bug#1063161:
Hello ! Thank you very much for enabling those two features in the kernel. Your work is much appreciated ! Maybe I am missing something but I've download the 6.8.9-1 package from here http://ftp.us.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.8.9-amd64_6.8.9-1_amd64.deb and while fiddling with it, I was not able to find the keys CONFIG_AMDTEE and CONFIG_AMD_PMF in the /boot/config file. I was able to see those two keys activated in salsa : https://salsa.debian.org/kernel-team/linux/-/blob/sid/debian/config/amd64/config?ref_type=heads Am I missing something ? Maybe the package was not rebuilt with this new configuration ? Thanks for your help !
Bug#1071673: Packages-arch-specific: Remove libgcr410?
Package: buildd.debian.org Severity: normal Tags: patch I was looking at Packages-arch-specific and trying to work out if anything else could be removed from it. I wondered about this line: %libgcr410: i386 amd64# [ANAIS] The architecture is in fact included in the source nowadays - it's just "Architecture: any". I tried building it on armhf and it built fine, albeit with a few warnings, and from a quick grep I don't see anything obviously architecture-specific. Since the CVS history wasn't carried over to git and cvs.debian.org no longer exists, I can't tell exactly when this was added. But at this point it looks like it's an accidental leftover and it would make more sense to just let the package at least try to build elsewhere. diff --git a/Packages-arch-specific b/Packages-arch-specific index aa69ebe..d7a26d9 100644 --- a/Packages-arch-specific +++ b/Packages-arch-specific @@ -21,7 +21,6 @@ # PACKAGE: [SOURCE PACKAGE] [REASON] fdflush: alpha amd64 i386 # amd64/i386/alpha specific -%libgcr410: i386 amd64 # [ANAIS] %linux-wlan-ng: amd64 i386 powerpc armel armhf alpha hppa# ANAIS [?] # xorg stuff Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
