Bug#840132: xrdp-sesman.service sometimes fails to start on boot
Since so many people are involved in this bug, please can we have an update from any of you. Do you still encounter the reported problem with current versions? Best, Alex
Bug#1068380: autopkgtest: new --lxcpath option doesn't seem to work on ci.d.n workers
reopen -1
reassign -1 debci
On 12-04-2024 7:03 a.m., Paul Gevers wrote:
On Thu, 4 Apr 2024 12:06:16 +0200 Paul Gevers wrote:
I tried to run with the new --lxcpath option but it fails:
"""
admin@ci-worker01:~$ /usr/bin/autopkgtest debputy -- lxc --sudo
autopkgtest-testing-i386 --lxcpath=/tmp -ddd
The order is wrong. --lxcpath is not an lxc-start argument [1] but, an
option for autopkgtest-virt-lxc so it has to go *before* the container
name.
So, bug was (mostly) behind the keyboard.
No, it is in debci, because backends/lxc/test-package has this:
debci-autopkgtest --user debci --apt-upgrade "$@" \
-- lxc --sudo --name "${container_name}"
"autopkgtest-${debci_suite:?}-${debci_arch:?}"
${debci_autopkgtest_args_lxc:-}
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, On 12-04-2024 4:42 a.m., 陈 晟祺 wrote: - If I limit the test file size to 1G, quite many tests would fail even with adequate resources Ack. To be fair, I was more thinking to make current test conditional on the available free disk space. But yeah, that might also lead to issues as the test might be randomly skipped. - If I try to skip large_files as you indicated with 2G memory, Good, so 2GB memory is not enough for zfs-linux (I assume you ran this test with 2 cores like I did) - With my fixes to dependencies, the tests could run to the ending without errors on 2 core + 8 GB. Great. That's progress than. Therefore I think trying to fit zfs-tests into a normal debci VM might be troublesome. I agree we shouldn't spend too much time on squeezing it into the *current* defaults. I'm still somewhat hoping that we could squeeze out a somewhat smaller memory defaults than 8 GB: does 4 GB work (and if so, how long does it take)? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068753: live-build: Should not install raspi-firmware on x86_64
Roland Clobus writes: > Control: severity -1 normal > Control: tags -1 +pending > Control: tags 1065640 +pending > Control: merge -1 1065640 > > Hello Vasudev Kamath, > >> Built the live image for bookworm using live build (on bookworm as well as >> from unstable). > > Note that the version which is on bookworm will not be updated. > Yes that is understood. > > The built >> image incldes raspi-firmware which is not meant for x86_64. I was installing >> some dkms module which >> will regenerate initrd etc and that failed with below error > ... >> The only way to fix this situation was to remove raspi-firmware in the live >> image. For now I'm working >> around the situation using following hook file which I use during live image >> build > ... >> Can we avoid installing it on x86 architecture by default. If some one needs >> it they can pull >> it. > > The issue has already been fixed, it is just not yet released. > You can use the version from the git repository as details here: > https://wiki.debian.org/ReproducibleInstalls/LiveImages > Thanks will consider using repo directly instead of packages when we do our builds. > >> It was claimed to be fixed by 12.2 in this [1] but it probably only fixed >> official live images >> but not the live build? There is also another ticket [2] but does not give >> proper details so created >> a new one > > Instead of creating a new bug, you could have sent a mail to the old one > with your additional information. I've merged both bug reports. > Yes I could have used reportbug to followup but it flashed to me after sending the mail. > > The official Debian live images got fixed for 12.2, because the official > images use the git repository for live-build instead of the .deb-package. > I see. Sorry for confusion as I was not aware how the debian live images are built and also there was no information on it being fixed in git in original report which was filed against debian-live virtual package. > >> Let me know if any other information is needed from my side. > > Please wait a while, a few other changes are pending and then a new > release can be made. Sure no worries. I will start using repo instead of pre-built version in our setup. > > With kind regards, > Roland Clobus Thanks, Vasudev
Bug#1068159: openjfx: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
Tags 1068159 +patch Thanks The build failure is caused by the following in modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h > /* Number of bits in a file offset, on hosts where this is settable. */ > #undef _FILE_OFFSET_BITS Looking at the file, this looks like output from autotools that was copied to become a static configuration file when code was vendored. One option would be to remove this line completely, however to minimise the risk of causing regressions on architectures not involved in the time64 transition I choose instead to place it behind a #ifndef guard. > /* Number of bits in a file offset, on hosts where this is settable. */ > #ifndef _TIME_BITS > # undef _FILE_OFFSET_BITS > #endif With this change, I was able to build the package successfully on armhf. Debdiff attached, if I get no response I will probablly NMU this in a week or so.diff -Nru openjfx-11.0.11+1/debian/changelog openjfx-11.0.11+1/debian/changelog --- openjfx-11.0.11+1/debian/changelog 2023-07-16 03:30:26.0 + +++ openjfx-11.0.11+1/debian/changelog 2024-04-11 15:34:39.0 + @@ -1,3 +1,10 @@ +openjfx (11.0.11+1-3.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Don't undefine _FILE_OFFSET_BITS if _TIME_BITS is set (Closes: #1068159) + + -- root Thu, 11 Apr 2024 15:34:39 + + openjfx (11.0.11+1-3.1) unstable; urgency=medium * Team upload. diff -Nru openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch --- openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch 1970-01-01 00:00:00.0 + +++ openjfx-11.0.11+1/debian/patches/40-dont-unset-file-offset-bits-if-time-bits-set.patch 2024-04-11 15:34:39.0 + @@ -0,0 +1,29 @@ +Description: Don't undefine _FILE_OFFSET_BITS if _TIME_BITS is set. + Having _TIME_BITS set to 64 but _FILE_OFFSET_BITS not set on a 32-bit + architectureis not supported by glibc. As a result of this, unsetting + _FILE_OFFSET_BITS on a 32-bit architecture with 64-bit time causes a build + failure. + + I suspect the unsetting of _FILE_OFFSET_BITS is a leftover from an + autogenerated file that became a static file rather than a deliberate + choice to override system settings. + + I suspect that unsetting _FILE_OFFSET_BITS is unnessacery in general and the + line could be completely removed. However to minimise the risk of regressions + I instead used an ifndef gaurd +Author: Peter Michael Green +Bug-Debian: https://bugs.debian.org/1068159 + +--- openjfx-11.0.11+1.orig/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h openjfx-11.0.11+1/modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h +@@ -544,7 +544,9 @@ + #endif + + /* Number of bits in a file offset, on hosts where this is settable. */ +-#undef _FILE_OFFSET_BITS ++#ifndef _TIME_BITS ++# undef _FILE_OFFSET_BITS ++#endif + + /* Define to 1 to make fseeko visible on some hosts (e.g. glibc 2.2). */ + #undef _LARGEFILE_SOURCE diff -Nru openjfx-11.0.11+1/debian/patches/series openjfx-11.0.11+1/debian/patches/series --- openjfx-11.0.11+1/debian/patches/series 2023-07-16 03:30:26.0 + +++ openjfx-11.0.11+1/debian/patches/series 2024-04-11 15:34:39.0 + @@ -21,3 +21,4 @@ disable-ffmpeg.patch 38-javadoc.patch webkit-217079-only-use-jumpislands-with-JIT.patch +40-dont-unset-file-offset-bits-if-time-bits-set.patch
Bug#1068732: prometheus-ipmi-exporter: debian path patch breaks local collection with sudo
Hi Daniel, On Thu, Apr 11, 2024 at 09:41:44AM +0200, Daniel Swarbrick wrote: > In the upstream bug report, it is suggested that one should "complain to > [Debian] to get this fixed". Yea - upstream's tone was not kind. I hope I didn't come across as complaining, and apologies if I did. > Have you tried overriding the --freeipmi.path flag back to an empty string > (e.g. --freeipmi.path="") so that ipmi_exporter falls back to searching on > the PATH? No, that didn't occur to me. But thanks, that works great! Ross signature.asc Description: PGP signature
Bug#1064235: cloud.debian.org: systemd-resolved et al. status (bookworm)
On Wed, Apr 03, 2024 at 09:39:40PM -0700, Flavio Veloso Soares wrote: > Hi Noah - I guess I'll be doing bullseye->bookworm installs in the meantime, > until 12.6 so I can fill bug reports (if any). It should be plenty to start with the bookworm images and simply remove the libnss-resolve package. It's quite a lot simpler. noah
Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi, > 2024年4月12日 02:39，Paul Gevers 写道： > > Hi > > On 11-04-2024 5:18 p.m., 陈 晟祺 wrote: >> If possible, could you help to build with latest code on salsa then run >> autopkgtest again on a normal debci VM? > > As I'm doing this live on the infrastructure, I don't want to do anything > there except testing what's in the archive, sorry. > Sure, this is reasonable. > My private setup (laptop) is not powerful enough to run this. > > I'm not 100% percent sure how to instruct you to build a ci.d.n like image. I > think it's: > $ autopkgtest-build-qemu debian testing > $ /usr/bin/autopkgtest --no-built-binaries --test-name=zfs-test-suite --user > debci zfs-linux -- qemu > except I don't know where autopkgtest-build-qemu stores the image. > I am indeed using debci images to ensure reproducibility. So the software environment should be the same. Just more observations here: - If I limit the test file size to 1G, quite many tests would fail even with adequate resources. - If I try to skip large_files as you indicated with 2G memory, the tests could proceed for a bit longer, but still got hang on some later tests. Since there are so many tests and I am not familiar with most of them, I have to try it repeatedly to find out which to filter out. Even I could do so, some (other, not seen before) tests would fail unexpectedly. These problems might be hard to workaround. - With my fixes to dependencies, the tests could run to the ending without errors on 2 core + 8 GB. Therefore I think trying to fit zfs-tests into a normal debci VM might be troublesome. -- Thanks, Shengqi Chen
Bug#1066658: sup: FTBFS: scm.c:316:9: error: implicit declaration of function ‘setproctitle’ [-Werror=implicit-function-declaration]
Tags: patch
Hi,
,On Wed, Mar 13, 2024 at 12:57:21PM +0100, Lucas Nussbaum wrote:
scm.c: In function ‘service’:
scm.c:316:9: error: implicit declaration of function ‘setproctitle’
[-Werror=implicit-function-declaration]
316 | setproctitle("Serving %s", remotehost());
| ^~~~
scm.c: In function ‘request’:
scm.c:448:16: warning: ignoring return value of ‘write’ declared with attribute
‘warn_unused_result’ [-Wunused-result]
448 | (void) write(netfile, , sizeof(int));
|^~~
scmio.c: In function ‘readfile’:
I have uploaded it to mentor to wait for sponsoring[0]. But there is one
debdiff if you can review it.
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068814
Thanks.
--
Regards,
--
Bo YU
diff -Nru sup-20100519/debian/changelog sup-20100519/debian/changelog
--- sup-20100519/debian/changelog 2020-08-05 19:53:16.0 +0800
+++ sup-20100519/debian/changelog 2024-04-11 16:41:22.0 +0800
@@ -1,3 +1,12 @@
+sup (20100519-4) unstable; urgency=medium
+
+ * QA upload.
+ * set std-ver to 4.7.0.
+ * Add 07_fix-implicit-function-declaration.patch to fix ftbfs issue.
+(Closes: #1066658)
+
+ -- Bo YU Thu, 11 Apr 2024 16:41:22 +0800
+
sup (20100519-3) unstable; urgency=medium
* QA upload.
diff -Nru sup-20100519/debian/control sup-20100519/debian/control
--- sup-20100519/debian/control 2020-08-05 19:48:03.0 +0800
+++ sup-20100519/debian/control 2024-04-11 16:03:18.0 +0800
@@ -3,7 +3,7 @@
Priority: optional
Build-Depends: debhelper-compat (= 13), libwrap0-dev
Maintainer: Debian QA Group
-Standards-Version: 4.5.0
+Standards-Version: 4.7.0
Package: sup
Architecture: any
diff -Nru
sup-20100519/debian/patches/07_fix-implicit-function-declaration.patch
sup-20100519/debian/patches/07_fix-implicit-function-declaration.patch
--- sup-20100519/debian/patches/07_fix-implicit-function-declaration.patch
1970-01-01 07:30:00.0 +0730
+++ sup-20100519/debian/patches/07_fix-implicit-function-declaration.patch
2024-04-11 15:59:50.0 +0800
@@ -0,0 +1,17 @@
+Description: fix implicit-function-declaration issue
+Author: Bo YU
+Bug: https://bugs.debian.org/1066658
+Last-Update: 2024-04-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/scm.c
b/scm.c
+@@ -195,6 +195,8 @@
+ #define INADDR_LOOPBACK (u_long)0x7f01 /* 127.0.0.1 */
+ #endif
+
++void setproctitle(const char *fmt, ...);
++
+ char scmversion[] = "4.3 BSD";
+ extern int silent;
+
diff -Nru sup-20100519/debian/patches/series sup-20100519/debian/patches/series
--- sup-20100519/debian/patches/series 2020-08-05 19:43:02.0 +0800
+++ sup-20100519/debian/patches/series 2024-04-11 15:01:34.0 +0800
@@ -4,3 +4,4 @@
04_fix_man.patch
05_unconst.patch
06_fix_ftbfs.patch
+07_fix-implicit-function-declaration.patch
signature.asc
Description: PGP signature
Bug#1068847: RFS: circe/2.13-1 [RC] [Team] -- client for IRC in Emacs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "circe": * Package name : circe Version : 2.13-1 Upstream contact : Jorgen Schäfer * URL : https://github.com/jorgenschaefer/circe * License : GPL-2+, BSD-3-clause, GPL-3+ * Vcs : https://salsa.debian.org/cgit/emacsen-team/circe.git Section : net The source builds the following binary packages: elpa-circe - client for IRC in Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/circe/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/circe/circe_2.13-1.dsc Changes since the last upload: circe (2.13-1) unstable; urgency=medium . * Team upload * New upstream release * Refresh patches using quilt-fixup * Backport patch adding lexical-cast to test-tracking.el to fix tests (Closes: #1068754) * Drop Built-Using on arch:all binary package * Modernize d/watch with special strings to be more robust * Use secure copyright file specification URI. * debian/copyright: use spaces rather than tabs to start continuation lines. * Bump debhelper from old 10 to 13. * Set debhelper-compat version in Build-Depends. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse. * Update standards version to 4.7.0, no changes needed. * Add Upstream-Contact in d/copyright * Add "Rules-Requires-Root: no" in d/control Regards, -- Xiyue Deng
Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API
On Tue, Jun 06, 2023 at 11:42:57AM +0200, Alberto Garcia wrote: > The wpewebkit-2.0 packages have already been uploaded to experimental. And now they are in unstable, you can finally upload gstreamer1.0-wpe. Thanks, Berto
Bug#1067884: KiCad no longer seems to recognize any of the built-in libraries
Hai after a regular system update, KiCad no longer seems to recognize any of the built-in libraries or footprints. Same applies to a fresh installation of devuan daedalus best resharks bugreporterm
Bug#1068846: pykwalify aborts on KeyError: 'object'
Package: pykwalify
Version: 1.8.0-2
Severity: important
X-Debbugs-Cc: k...@thevertigo.com
Dear Maintainer,
When attempting to validate the attached YAML minimal with pykwalify(1) against
the OpenAPI schema I noticed the pykwalify(1) binary fails to launch. It raises
a Python exception while trying to find the binary's entry point. This appears
to not be an upstream issue, but probably a problem with the packaging itself.
I am running Ubuntu Mantic, but I tried with the bookwork package pykwalify and
python3-pykwalify and same problem.
Here is how you can reproduce the issue:
$ sudo apt install pykwalify openapi-specification
$ pykwalify --data-file minimal.yaml --schema-file /usr/share/openapi-
specification/schemas/v3.0/schema.yaml
Traceback (most recent call last):
File "/usr/bin/pykwalify", line 33, in
sys.exit(load_entry_point('pykwalify==1.8.0', 'console_scripts',
'pykwalify')())
^^
File "/usr/lib/python3/dist-packages/pykwalify/cli.py", line 98, in
cli_entrypoint
run(parse_cli())
File "/usr/lib/python3/dist-packages/pykwalify/cli.py", line 85, in run
c.validate()
File "/usr/lib/python3/dist-packages/pykwalify/core.py", line 183, in
validate
self._start_validate(self.source)
File "/usr/lib/python3/dist-packages/pykwalify/core.py", line 225, in
_start_validate
root_rule = Rule(schema=self.schema)
File "/usr/lib/python3/dist-packages/pykwalify/rule.py", line 66, in __init__
self.init(schema, "")
File "/usr/lib/python3/dist-packages/pykwalify/rule.py", line 408, in init
self.init_type_value(t, rule, path)
File "/usr/lib/python3/dist-packages/pykwalify/rule.py", line 713, in
init_type_value
self.type_class = type_class(v)
^
File "/usr/lib/python3/dist-packages/pykwalify/types.py", line 49, in
type_class
return _types[type]
~~^^
KeyError: 'object'
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500,
'mantic'), (100, 'mantic-proposed'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-26-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pykwalify depends on:
ii python33.11.4-5
ii python3-pykwalify 1.8.0-2
pykwalify recommends no packages.
pykwalify suggests no packages.
-- no debconf information
openapi: 3.0.0
info:
title: Sample API
description: Optional multiline or single-line description in
[CommonMark](http://commonmark.org/help/) or HTML.
version: 0.1.9
servers:
- url: http://api.example.com/v1
description: Optional server description, e.g. Main (production) server
- url: http://staging-api.example.com
description: Optional server description, e.g. Internal staging server for
testing
paths:
/users:
get:
summary: Returns a list of users.
description: Optional extended description in CommonMark or HTML.
responses:
'200':# status code
description: A JSON array of user names
content:
application/json:
schema:
type: array
items:
type: string
id: https://spec.openapis.org/oas/3.0/schema/2019-04-02
$schema: http://json-schema.org/draft-04/schema#
description: Validation schema for OpenAPI Specification 3.0.X.
type: object
required:
- openapi
- info
- paths
properties:
openapi:
type: string
pattern: ^3\.0\.\d(-.+)?$
info:
$ref: '#/definitions/Info'
externalDocs:
$ref: '#/definitions/ExternalDocumentation'
servers:
type: array
items:
$ref: '#/definitions/Server'
security:
type: array
items:
$ref: '#/definitions/SecurityRequirement'
tags:
type: array
items:
$ref: '#/definitions/Tag'
uniqueItems: true
paths:
$ref: '#/definitions/Paths'
components:
$ref: '#/definitions/Components'
patternProperties:
'^x-': {}
additionalProperties: false
definitions:
Reference:
type: object
required:
- $ref
patternProperties:
'^\$ref$':
type: string
format: uri-reference
Info:
type: object
required:
- title
- version
properties:
title:
type: string
description:
type: string
termsOfService:
type: string
format: uri-reference
contact:
$ref: '#/definitions/Contact'
license:
$ref: '#/definitions/License'
version:
type: string
patternProperties:
Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble
Hello Remus-Gabriel. Okay I've queued up the Romanian translation file to be included with the next upload of Mumble. There are several library transitions going on in Debian, so I'm going to wait a bit for those. I also did an NMU on zeroc-ice which was blocked from transition to Testing due to a FTBFS bug related to the time_t transition because of a newly enabled build flag that caused the build to break with an error. Let me know if you've contacted Mumble upstream about the Romanian translation; if not I'll contact them to see if we can get it included in the source directly. On 4/9/24 18:11, Remus-Gabriel Chelu wrote: Hello Chris, În 08.04.2024 22:22, Chris Knadle a scris: Is it as simple as renaming the mumble_debconf_ro.po file to ro.po and moving it to debian/po/ro.po ? Yes, this is the way to introduce translation within the project, or, even simpler: mv mumble_debconf_ro.po debian/po/ro.po renaming and moving into a single command. Respects, Remus-Gabriel PS: Sorry for the inconvenience caused, I grouped into my machine several translation files (of several programs) in the same folder, for their own convenience; so I had to differentiate them somehow from each other, and I chose to prefix their names with the name of the program for which they are made. The only inconvenience was not knowing how to incorporate the file into the Debian package -- the workflow described above makes sense. As long as I know what to do and can make the time I'm willing to do the work needed to incorporate desired changes. Thanks very much for your work -- Chris Knadle chris.kna...@coredump.us
Bug#1034311: reprotest: make it easier to compare against an existing build (eg from ftp.d.o)
On 2024-03-08, Vagrant Cascadian wrote: > On 2023-04-12, Holger Levsen wrote: >> i guess reprotest maybe should grow an option to do >> --control-build /path/to/packages/ >> --vary=build_path=/use/this/build/path ... >>to make it easier to use reprotest to compare against an existing >> build >>YES >> e.g. there is no way to disable buidl path variations when >> comparing >> against an arbitrary build >>i'm reporting this as a bug to the bts, quoting your words here. >> (ok?) >> reprotest can control it's own builds ... but if i want to use >> reprotest >>against the archive packages or an sbuild >>or pbuilder build package ... it will always have a different >> build path > > Forgot about this bug, but I have since implemented a proof-of-concept > of this: > > > https://salsa.debian.org/reproducible-builds/reprotest/-/commits/wip-specify-build-path?ref_type=heads And merged in 0.7.27 ... which resolves the one specific issue mentioned ... are there any other must-haves we need to consider this bug closed? Better documentation of how to actually do this? :) live well, vagrant signature.asc Description: PGP signature
Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single
I've looked at this again. Sorry it's been so long.
Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying
--quilt=single"):
> I still regret that this change went into bookworm, and would like to
> simplify things again. I still think that this is a case where the cost
> of correctness-in-all-cases is too high.
I hadn't appreciated that, from your (legitimate) point of view, this
was a regression. I'm sorry.
> I think we can revert the behavioural change and come up with an
> appropriate warning in the workflow manpage. It might be relevant to
> recommend users consider using source format 1.0, even.
But, I'm still not sure which behavioural change you're talking about.
Are we talking about this, in 9.0:
* Reject split brain quilt modes with single-debian-patch.
(Previously this would malfunction; now we reject it.)
? That doesn't seem likely since 9.0 was July 2019 and this bug is
February 2023. But maybe that's the one. If so, the commit is
75b7a4c72614 which says "Right now, this malfunctions in dgit: we do
not do the split brain stuff". So although dgit tries to honour d/s/o
single-debian-patch (by invoking dpkg-source) it doesn't manage to do
it in the quilt modes where you evidently want it.
(Looking at the context, I think maybe this was a side effect of other
changes making this complicated to get right.)
#1018984 is scary reading, but doesn't seem to involve anything but
docs changes except
* With dpkg single-debian-patch, pass --include-removal to dpkg-source -b.
but that doesn't seem like it's what is in your way.
Going back to possible options:
Re somehow discovering this information from git tags: since this is
the same branch format, just a different way of generating patches, it
seems like fishing it out of the last git tag would be possible.
My concern in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031793#25
"if the branch format is converted without making a tag"
seems misplaced. But fishing this out of the tag in dgit still feels
very weird to me. It's not a thing dgit ever does the rest of the
time (git-debpush does, but that's different).
You wrote, as an argument in favour of writing single-debian-patch:
> You might want to allow non-dgit users to use 'dpkg-source --commit',
I agree that this is desirable. But the failure modes I previously
described in #1018984 are terrifying. I'm particularly bothered by
"I was able to make a source package [where] as soon as you try to
edit *an unrelated file* dpkg-source craps out terribly".
I don't think we can have both your goal, of letting people
dpkg-source --commit and fold in their changes into an existing patch,
*and* my goal of not ever getting people into the terrifyingly broken
source package situation (or encouraging things that may lead to that).
You also wrote:
> if you think the bugs aren't going to arise for your package
You can know that for the things *you* do to the package. But, you
don't know what changes downstream users are going to try to make. In
my experience, people further from centres of knowledge do
increasingly strange things.
I very much prefer, as an ideological position, to favour the
interests of downstreams, even arguably deragned downstream users,
over upstreams such as ourselves.
So I agree that something should be done. I still think
debian/source/options single-debian-patch is too bad to recommend.
I'm not opposed to trying to honour it, even so. Currently the
rejection is implemented in `build_maybe_quilt_fixup`, near l.6234.
I don't think we can use `quilt_fixup_git_singlepatch` in this case,
because dpkg-source wants to regenerate the patch each time, so we
must produce *our* patch with dpkg-source, or the source package isn't
a fixed point.
So we *have* to generate the patch with
`quilt_fixup_dpkgsource_singlepatch`. AFAICT from the git history and
the source code, that currently just doesn't work in split brain mode
(presumably for reasons to do with playtree juggling etc.
I still think it would be better to invent our own dropping to control
this, and have it modify the default quilt mode. That could cause the
fixup call to be `quilt_fixup_git_singlepatch` and wouldn't need to
interact with dpkg-source's ideas.
We've ruled out our own option in d/s/options, but we could have
debian/source/dgit-options containing `quilt-single-patch` or maybe
even `single-debian-patch` or something.
What a tangled web we weave. I hope this is of some use.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1068845: fwbuilder: fwbuilder crashes when trying to create almost any type of new object
Package: fwbuilder
Version: 5.3.7-5+b2
Severity: normal
Tags: patch
Dear Maintainer,
fwbuilder crashes when trying to create almost any type of new object
To reproduce:
* start fwbuilder without any arguments
* click "New Object"
* click "New Library"
* fwbuilder will crash
The attached debdiff with upstream commit will fix the problem.
--
Regards
Sudip
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fwbuilder depends on:
ii fwbuilder-common5.3.7-5
ii libc6 2.37-15
ii libgcc-s1 14-20240201-3
ii libqt5core5t64 5.15.10+dfsg-7.2+b1
ii libqt5gui5t64 5.15.10+dfsg-7.2+b1
ii libqt5network5t64 5.15.10+dfsg-7.2+b1
ii libqt5printsupport5t64 5.15.10+dfsg-7.2+b1
ii libqt5widgets5t64 5.15.10+dfsg-7.2+b1
ii libsnmp40t645.9.4+dfsg-1.1+b1
ii libstdc++6 14-20240201-3
ii libxml2 2.9.14+dfsg-1.3+b2
ii libxslt1.1 1.1.35-1
ii zlib1g 1:1.3.dfsg-3+b1
Versions of packages fwbuilder recommends:
ii fwbuilder-doc 5.3.7-5
ii rcs5.10.1-1
fwbuilder suggests no packages.
-- no debconf information
diff -Nru fwbuilder-5.3.7/debian/changelog fwbuilder-5.3.7/debian/changelog
--- fwbuilder-5.3.7/debian/changelog2022-01-23 23:01:26.0 +
+++ fwbuilder-5.3.7/debian/changelog2024-04-11 23:04:28.0 +0100
@@ -1,3 +1,10 @@
+fwbuilder (5.3.7-5.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add upstream commit to fix crash creating new object.
+
+ -- Sudip Mukherjee Thu, 11 Apr 2024 23:04:28
+0100
+
fwbuilder (5.3.7-5) unstable; urgency=medium
[ Lukas Mardian ]
diff -Nru
fwbuilder-5.3.7/debian/patches/0001-adding-fix-for-crash-if-you-create-some-new-objects-.patch
fwbuilder-5.3.7/debian/patches/0001-adding-fix-for-crash-if-you-create-some-new-objects-.patch
---
fwbuilder-5.3.7/debian/patches/0001-adding-fix-for-crash-if-you-create-some-new-objects-.patch
1970-01-01 01:00:00.0 +0100
+++
fwbuilder-5.3.7/debian/patches/0001-adding-fix-for-crash-if-you-create-some-new-objects-.patch
2024-04-11 23:04:28.0 +0100
@@ -0,0 +1,38 @@
+From 102d68c3917950c688c1a3ca9bee42c3ff24b57f Mon Sep 17 00:00:00 2001
+From: bluelineXY
+Date: Thu, 22 Feb 2018 21:43:53 +0100
+Subject: [PATCH] adding fix for crash if you create some new objects type out
+ of the menu (e.g. ip addess)
+
+Origin: upstream,
https://github.com/fwbuilder/fwbuilder/commit/102d68c3917950c688c1a3ca9bee42c3ff24b57f
+Last-Update: 2024-04-11
+---
+ src/libgui/ObjectManipulator_tree_ops.cpp | 12
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/src/libgui/ObjectManipulator_tree_ops.cpp
b/src/libgui/ObjectManipulator_tree_ops.cpp
+index ec80537d5..b3327f375 100644
+--- a/src/libgui/ObjectManipulator_tree_ops.cpp
b/src/libgui/ObjectManipulator_tree_ops.cpp
+@@ -774,10 +774,14 @@ void ObjectManipulator::moveItems(ObjectTreeViewItem
*dest,
+ const list )
+ {
+ string folder;
+-if (dest->getUserFolderParent() != 0) {
+-folder = dest->getUserFolderName().toUtf8().constData();
+-} else {
+-folder = dest->getFWObject()->getStr("folder");
++
++if(dest != NULL)
++{
++if (dest->getUserFolderParent() != 0) {
++folder = dest->getUserFolderName().toUtf8().constData();
++} else {
++folder = dest->getFWObject()->getStr("folder");
++}
+ }
+
+ FWCmdMacro *macro = new FWCmdMacro(tr("Move objects"));
+--
+2.39.2
+
diff -Nru fwbuilder-5.3.7/debian/patches/series
fwbuilder-5.3.7/debian/patches/series
--- fwbuilder-5.3.7/debian/patches/series 2022-01-20 13:09:55.0
+
+++ fwbuilder-5.3.7/debian/patches/series 2024-04-11 23:04:10.0
+0100
@@ -6,3 +6,4 @@
pkg-config_libxml2.patch
pkg-config_libxslt.patch
ed4db20ec6cabfaea9c36187b7ce40d9d93c6c79.patch
+0001-adding-fix-for-crash-if-you-create-some-new-objects-.patch
Bug#1068774: (No Subject)
> You found with #956330 already a feature request that asks for that No, that other issue is not about kept-back packages in specific. I don't see how the functionality of that issue would be very useful but for kept-back packages asking the user or by default not marking them as manually installed could be very useful and seems more like what one would expect it to do. > Note that "phases upgrades" have their own listing now Do you mean phased updates? Whether or not you meant that, I don't know what you mean there (what and how it relates to this issue). > it turns out that you 'install' things you care about and don't want removed > as unneeded later on This is about kept-back packages where install is used to make them install.
Bug#1067066: ruby-fusefs: fusefs_fuse.c:31:10: error: implicit declaration of function ‘fuse_chan_fd’ [-Werror=implicit-function-declaration]
Package: ruby-fusefs Followup-For: Bug #1067066 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Control: tags -1 patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * debian/patches/fix-missing-includes.patch: Add missing includes. Closes LP: #2061037. Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-26-generic (SMP w/10 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru ruby-fusefs-0.7.0/debian/patches/fix-missing-includes.patch ruby-fusefs-0.7.0/debian/patches/fix-missing-includes.patch --- ruby-fusefs-0.7.0/debian/patches/fix-missing-includes.patch 1969-12-31 17:00:00.0 -0700 +++ ruby-fusefs-0.7.0/debian/patches/fix-missing-includes.patch 2024-04-11 16:38:56.0 -0600 @@ -0,0 +1,19 @@ +Description: Add missing includes +Author: Zixing Liu +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067066 +Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/ruby-fusefs/+bug/2061037 +Forwarded: no +Last-Update: 2024-04-11 +--- +Index: ruby-fusefs/ext/fusefs_fuse.c +=== +--- ruby-fusefs.orig/ext/fusefs_fuse.c ruby-fusefs/ext/fusefs_fuse.c +@@ -7,6 +7,7 @@ + #define _FILE_OFFSET_BITS 64 + + #include ++#include + #include + #include + #include diff -Nru ruby-fusefs-0.7.0/debian/patches/series ruby-fusefs-0.7.0/debian/patches/series --- ruby-fusefs-0.7.0/debian/patches/series 2022-06-30 17:15:19.0 -0600 +++ ruby-fusefs-0.7.0/debian/patches/series 2024-04-11 16:35:51.0 -0600 @@ -1,2 +1,3 @@ port-to-newer-ruby.patch fix-dynamic-library-load-path.patch +fix-missing-includes.patch
Bug#1066653: prime-phylo: FTBFS: gb.tab.c:1096:16: error: implicit declaration of function ‘yylex’ [-Werror=implicit-function-declaration]
Package: prime-phylo Followup-For: Bug #1066653 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Control: tags -1 patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: * debian/patches/fix-ftbfs-with-gcc13.patch: Fix missing headers and missing prototypes. Closes LP: #2061032. Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-26-generic (SMP w/10 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru prime-phylo-1.0.11/debian/patches/fix-ftbfs-with-gcc13.patch prime-phylo-1.0.11/debian/patches/fix-ftbfs-with-gcc13.patch --- prime-phylo-1.0.11/debian/patches/fix-ftbfs-with-gcc13.patch 1969-12-31 17:00:00.0 -0700 +++ prime-phylo-1.0.11/debian/patches/fix-ftbfs-with-gcc13.patch 2024-04-11 16:13:25.0 -0600 @@ -0,0 +1,54 @@ +Description: Fix missing headers and missing prototypes +Author: Zixing Liu +Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/prime-phylo/+bug/2061032 +Forwarded: no +Last-Update: 2024-04-11 +Index: prime-phylo/src/cxx/libraries/prime/NHXparse.y +=== +--- prime-phylo.orig/src/cxx/libraries/prime/NHXparse.y prime-phylo/src/cxx/libraries/prime/NHXparse.y +@@ -2,6 +2,7 @@ + #include + #include + #include ++#include + #include "NHXnode.h" + #include "NHXtree.h" + #include "NHXannotation.h" +@@ -14,7 +15,9 @@ + /* #define YYERROR_VERBOSE */ + + /* Here comes some C declarations */ +- ++extern int yylex (void); ++extern void read_from_string(char *str); ++extern void close_string_buffer(); + extern FILE *yytree_in; + extern char *yytree_text; + extern unsigned int lineno; /* Current line number in input file */ +Index: prime-phylo/src/cxx/libraries/sfile/gb.y +=== +--- prime-phylo.orig/src/cxx/libraries/sfile/gb.y prime-phylo/src/cxx/libraries/sfile/gb.y +@@ -23,7 +23,8 @@ + #include "entry.h" + #include "sfile.h" + +- ++extern int yylex (void); ++unsigned linenumber(); + static int yyerror(); + + #define YYDEBUG 1 +Index: prime-phylo/src/cxx/libraries/sfile/gbread.c +=== +--- prime-phylo.orig/src/cxx/libraries/sfile/gbread.c prime-phylo/src/cxx/libraries/sfile/gbread.c +@@ -3,6 +3,7 @@ + + extern int yydebug; + ++#include + #include "sfile.h" + #include "gb.tab.h" + diff -Nru prime-phylo-1.0.11/debian/patches/series prime-phylo-1.0.11/debian/patches/series --- prime-phylo-1.0.11/debian/patches/series2021-05-20 05:51:42.0 -0600 +++ prime-phylo-1.0.11/debian/patches/series2024-04-11 16:10:29.0 -0600 @@ -3,3 +3,4 @@ fix-gcc-8.patch 0003-Fix-build-with-Boost-1.67.patch 0004-fix-gcc10-build.patch +fix-ftbfs-with-gcc13.patch
Bug#1068833: discover: A game installed via Discover doesn't start
Control: reassign -1 plasma-discover 5.27.5-2 On Thu, 11 Apr 2024 21:49:48 + Ilkka Kallioniemi wrote: On Thu, 11 Apr 2024 21:45:53 +0200 Pascal Hambourg wrote: > Discover is a hardware identification system. Aren't your confusing with > plasma-discover ? Yes, I am. Sorry for confusing those. How to fix the mixup I caused? This mail should reassign the bug to the right package.
Bug#1068844: nmu: tuxmath_2.0.3-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: tuxm...@packages.debian.org Control: affects -1 + src:tuxmath nmu tuxmath_2.0.3-9 . armel armhf s390x . unstable . -m "Rebuild for time_t" Please rebuild tuxmath on the listed archs now that t4kcommon has built on those archs. Chris
Bug#1068194: pcsx2: diff for NMU version 1.6.0+dfsg-2.1
Control: tags 1068194 + patch Dear maintainer, I've prepared an NMU for pcsx2 (versioned as 1.6.0+dfsg-2.1). The diff is attached to this message. Regards. -- Sebastian Ramacher diff -Nru pcsx2-1.6.0+dfsg/debian/changelog pcsx2-1.6.0+dfsg/debian/changelog --- pcsx2-1.6.0+dfsg/debian/changelog 2022-10-23 17:00:12.0 +0200 +++ pcsx2-1.6.0+dfsg/debian/changelog 2024-04-11 23:36:38.0 +0200 @@ -1,3 +1,13 @@ +pcsx2 (1.6.0+dfsg-2.1) unstable; urgency=medium + + * Non-maintainer upload + + [ Mate Kukri ] + * d/p/cpp_error_ftbfs.patch: fix FTBFS by adding missing include for +std::*_error types. (LP: #2048072) (Closes: #1068194) + + -- Sebastian Ramacher Thu, 11 Apr 2024 23:36:38 +0200 + pcsx2 (1.6.0+dfsg-2) unstable; urgency=medium * Team upload diff -Nru pcsx2-1.6.0+dfsg/debian/patches/cpp_error_ftbfs.patch pcsx2-1.6.0+dfsg/debian/patches/cpp_error_ftbfs.patch --- pcsx2-1.6.0+dfsg/debian/patches/cpp_error_ftbfs.patch 1970-01-01 01:00:00.0 +0100 +++ pcsx2-1.6.0+dfsg/debian/patches/cpp_error_ftbfs.patch 2024-04-11 23:35:30.0 +0200 @@ -0,0 +1,36 @@ +Description: Fix CDVD.cpp FTBFS by adding include +Author: Mate Kukri +Last-Update: 2024-01-04 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/plugins/cdvdGigaherz/src/CDVD.cpp b/plugins/cdvdGigaherz/src/CDVD.cpp +@@ -18,6 +18,8 @@ + #include + #include + #include ++#include ++#include + #include "svnrev.h" + + Settings g_settings; +--- a/plugins/cdvdGigaherz/src/ReadThread.cpp b/plugins/cdvdGigaherz/src/ReadThread.cpp +@@ -19,6 +19,7 @@ + #include + #include + #include ++#include + + const u32 sectors_per_read = 16; + +--- a/plugins/cdvdGigaherz/src/Unix/LinuxIOCtlSrc.cpp b/plugins/cdvdGigaherz/src/Unix/LinuxIOCtlSrc.cpp +@@ -23,6 +23,7 @@ + #include + #include + #include ++#include + + IOCtlSrc::IOCtlSrc(decltype(m_filename) filename) + : m_filename(filename) diff -Nru pcsx2-1.6.0+dfsg/debian/patches/series pcsx2-1.6.0+dfsg/debian/patches/series --- pcsx2-1.6.0+dfsg/debian/patches/series 2022-10-23 13:49:04.0 +0200 +++ pcsx2-1.6.0+dfsg/debian/patches/series 2024-04-11 23:35:30.0 +0200 @@ -1 +1,2 @@ wxwidgets3.2.patch +cpp_error_ftbfs.patch
Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)
Hi Holger, On Sun, 7 Apr 2024 13:00:43 +0200, Holger wrote: > The only thing which is not working currently, is the search functionality, > but since that's not theme-specific I guess (please correct me, if I'm > wrong), I close this bug. The theme looks great, and I agree with closing this bug. However, so that we don't overlook another potential python3-sphinx bug: could you report the problem that you encountered? (I contribute to upstream and may be able to help with investigating that) Thanks, James
Bug#1068833: discover: A game installed via Discover doesn't start
On Thu, 11 Apr 2024 21:45:53 +0200 Pascal Hambourg wrote: > Discover is a hardware identification system. Aren't your confusing with > plasma-discover ? Yes, I am. Sorry for confusing those. How to fix the mixup I caused?
Bug#847805: reprotest: document/support simple reproducibility test with sbuild
On 2016-12-11, Sean Whitton wrote: > On Sun, Dec 11, 2016 at 03:12:57PM -0700, Sean Whitton wrote: >> I have sbuild properly set up on my machine, and I want to use it to >> test package reproducibility. Something like this, where PWD is an >> unpacked source package: >> >> 1) sbuild >> 2) record .deb checksums from .changes file >> 3) sbuild >> 4) compare .deb checksums in new .changes file >> 5) run diffoscope if the checksums differ > > Thanks to #debian-reproducible, this is mostly what I wanted: > > reprotest auto . -- schroot unstable-amd64-sbuild > > This doesn't actually invoke sbuild, but it does perform the builds > inside the schroot I already have set up, and compare the results. > > This is useful, but it would also be good if reprotest could invoke > sbuild(1) itself. That is because sbuild has lots of useful options. > > For example, suppose that foo depends on dh_bar, and I am hacking on > dh_bar in the hope of making foo reproducible. Then I want to build foo > against my local version of dh_bar. With sbuild, I can do this using > --extra-package and --add-depends. reprotest with a pure schroot > backend can't do that kind of thing, so far as I can tell. A while back I did work on a simple wrapper for sbuild that calls reprotest as part of a --finished-build-commands hook: https://salsa.debian.org/reproducible-builds/sbuild-unshare-reprotest It is definitely quite rough around the edges and there are some caveats that limit the functionality, but can do some of what you were looking for. live well, vagrant signature.asc Description: PGP signature
Bug#1068740: qemu-user-static: q-u-s > 8.1.3 fails to run amd64 binaries or docker containers on arm64 host
On Wed, Apr 10, 2024 at 3:09 AM Michael Tokarev wrote: > > 10.04.2024 10:55, Steev Klimaszewski wrote: > > I wanted to try if 8.2.2, or 9.0 has a fix, but due to the time64 change, I > > cannot use > > packages from unstable or experimental at this time as Kali is based on > > Debian > > testing. I did try cloning the repository to build it myself in a kali > > sbuild > > chroot, however I got some unrelated error message about the xz file being > > corrupt. > > You can download qemu-user-static .deb of any version and install it in > your environment - it is a self-contained package (since it is linked > statically) not requiring any time64 changes. > > Speaking of xz file being corrupt - I'd love to know more details about > this one. > > As of the bug itself, - it would be very interesting to see which change > in 8.1.4 caused this problem (hopefully I got it right and it's been > introduced in 8.1.4 - actually, introduced in master and backported to > 8.1.4). > > Please install a build environment (minimal is enough, with libglib-dev, > libz-dev, meson, python3-venv - and maybe a few others which I forgot > about, - you'll know after the first try). Clone the qemu git repository, > build just qemu-x86_64-static binary: > > ../configure --target-list=x86_64-linux-user --enable-static && >make qemu-x86_64 > > and try bisecting between v8.1.3 and v8.1.4 (or maybe try other versions > if it is not in 8.1.4 - eg, check if 8.2.0 works but 8.2.3 doesn't, etc). > You'll have to re-load binfmt registration after updating the binary > in /usr/bin/qemu-x86_64-static - kernel keeps old binary open. Just > use `cat /usr/lib/binfmt.d/qemu-x86_64.conf > > /proc/sys/fs/binfmt_misc/register' > or re-run systemd-binfmt.service. > > It would be difficult for me to try it here since I don't have the hardware. > Maybe you can create a smaller testcase as well. I do not have a good way to reproduce it, aside from starting an amd64 docker container on an arm64 host. >From my testing here, all of 8.1.x are working All of 8.2.x are broken All of 9.0 are working So bisecting between 9.0.0-rc0 and 8.2, it turns out that 4ef1f559f270 fixes the issue Changing to stable-8.2 branch, cherry picking 4ef1f559f270 on top (which does pick cleanly), rebuilding, does indeed allow 8.2 to work I've attempted to throw it in to the qemu package repository, and I get the same xz error: steev@finn:~/kali/work-in-progress/qemu$ gbp buildpackage --git-builder=sbuild --git-export=WC gbp:info: Creating /home/steev/kali/build-area/qemu_8.2.2+ds.orig.tar.xz gbp:error: Error creating qemu_8.2.2+ds.orig.tar.xz: Pristine-tar couldn't checkout "qemu_8.2.2+ds.orig.tar.xz": xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent xdelta3: target window checksum mismatch: XD3_INVALID_INPUT xdelta3: normally this indicates that the source file is incorrect xdelta3: please verify the source file with sha1sum or equivalent pristine-tar: Failed to reproduce original tarball. Please file a bug report. pristine-tar: failed to generate tarball > Thanks, > > /mjt Thank you for the quick response!
Bug#810448: nbc: please switch to libusb 1.0
I do not know how to convert the package to use a newer libusb, but just wanted to mention that a patch to convert t2n to use a newer libusb is available in https://bugs.debian.org/810460 >. -- Happy hacking Petter Reinholdtsen
Bug#1067830: gri: diff for NMU version 2.12.27-1.2
Control: tags 1067830 + patch Dear maintainer, I've prepared an NMU for gri (versioned as 2.12.27-1.2). The diff is attached to this message. Cheers -- Sebastian Ramacher diff -Nru gri-2.12.27/debian/changelog gri-2.12.27/debian/changelog --- gri-2.12.27/debian/changelog 2022-08-25 18:33:47.0 +0200 +++ gri-2.12.27/debian/changelog 2024-04-11 23:23:28.0 +0200 @@ -1,3 +1,11 @@ +gri (2.12.27-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * debian/patches: Apply upstream patch to fix build with 64 bit time_t on +armel and armhf. (Closes: #1067830) + + -- Sebastian Ramacher Thu, 11 Apr 2024 23:23:28 +0200 + gri (2.12.27-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru gri-2.12.27/debian/patches/fix-build-with-t64.patch gri-2.12.27/debian/patches/fix-build-with-t64.patch --- gri-2.12.27/debian/patches/fix-build-with-t64.patch 1970-01-01 01:00:00.0 +0100 +++ gri-2.12.27/debian/patches/fix-build-with-t64.patch 2024-04-11 23:22:33.0 +0200 @@ -0,0 +1,40 @@ +From 4d93a4e76543b914400d9e425e7c2de5c9dbb58d Mon Sep 17 00:00:00 2001 +From: dankelley +Date: Fri, 5 Apr 2024 07:10:17 -0300 +Subject: [PATCH] possibly fix debian error on time_t + +I am a bit concerned that this may break gri on other platforms, but not +really very concerned, since this fiddling with time types is likely +irrelevant to modern machines. And I doubt that anybody is building gri +on some of the platforms for which the code is making special cases. + +Please note that I do not have access to a machine that reproduces the +error message. I am on macos, and don't want to break my toolchain by +over-writing my C++ compilers, etc., to try to reproduce the bug. + +Lacking access to any type of linux machine, I am not able to test +whether my change fixes the problem. But the `git diff` is only one line +long, so hopefully if there is still a problem on debian, someone can +tell me a preprocesser symbol that I can use (and perhaps a header.h +file I can specify) to define the `time_t` type. + +Sorry for the hassles. + +Dan Kelley +--- + src/gr.hh | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/gr.hh b/src/gr.hh +index 6ff2f20..97b1756 100644 +--- a/src/gr.hh b/src/gr.hh +@@ -395,7 +395,7 @@ double lapse_rate(double S, double t, double p); + #if defined(__DECCXX) + #define SECOND_TYPE int + #else +-#define SECOND_TYPE long ++#define SECOND_TYPE time_t + #endif + #endif + diff -Nru gri-2.12.27/debian/patches/series gri-2.12.27/debian/patches/series --- gri-2.12.27/debian/patches/series 2022-08-25 18:33:47.0 +0200 +++ gri-2.12.27/debian/patches/series 2024-04-11 23:22:47.0 +0200 @@ -1 +1,2 @@ imagemagick.patch +fix-build-with-t64.patch
Bug#1068843: nmu: libnbd_1.20.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: lib...@packages.debian.org Control: affects -1 + src:libnbd nmu libnbd_1.20.0-1 . ANY . unstable . -m "Rebuild on buildds" Please rebuild libnbd to replace the profile nocheck builds on armhf, armel. Chris
Bug#755437: leocad suggests ldraw-parts since 0.80.3-1
I believe the requestor never received this email, and as @gmail.com reject emails from me, I doubt he will get my email too. [Nicolas Guilbert 2015-02-12] > the leocad package suggests ldraw-parts since 0.80.3-1 which should fix the > issue about the minimal parts set (apt-get install leocad > --install-suggests). > > Concerning the parts not being visible, I cannot reproduce that error. Is it > still a problem? Without more information, I suspect it is not possible to get further with this issue. Perhaps it can be closed? -- Happy hacking Petter Reinholdtsen
Bug#1067654: tpm2-abrmd: diff for NMU version 3.0.0-1.1
Dear maintainer, I've prepared an NMU for tpm2-abrmd (versioned as 3.0.0-1.1). The diff is attached to this message. Cheers -- Sebastian Ramacher diff -Nru tpm2-abrmd-3.0.0/debian/changelog tpm2-abrmd-3.0.0/debian/changelog --- tpm2-abrmd-3.0.0/debian/changelog 2022-12-12 00:47:34.0 +0100 +++ tpm2-abrmd-3.0.0/debian/changelog 2024-04-11 23:12:31.0 +0200 @@ -1,3 +1,13 @@ +tpm2-abrmd (3.0.0-1.1) unstable; urgency=medium + + * Non-maintainer upload + + [ Michael Hudson-Doyle ] + * Disable testsuite on armhf for now (the mocking the test harness +does fails when _FILE_BITS == 64) (Closes: #1067654). + + -- Sebastian Ramacher Thu, 11 Apr 2024 23:12:31 +0200 + tpm2-abrmd (3.0.0-1) unstable; urgency=low [ Debian Janitor ] diff -Nru tpm2-abrmd-3.0.0/debian/rules tpm2-abrmd-3.0.0/debian/rules --- tpm2-abrmd-3.0.0/debian/rules 2022-12-12 00:42:50.0 +0100 +++ tpm2-abrmd-3.0.0/debian/rules 2024-04-11 23:12:31.0 +0200 @@ -4,9 +4,14 @@ export DEB_CFLAGS_MAINT_APPEND = -Wall # Some variables: +DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) +ifneq (,$(filter armhf armel,$(DEB_HOST_ARCH))) +DEB_BUILD_OPTIONS+=nocheck +endif + %: dh $@ --exclude=.la --with autoreconf
Bug#1066378: pike8.0: FTBFS: zlibmod.c:1235:5: error: implicit declaration of function ‘pop_n_elems’ [-Werror=implicit-function-declaration]
Package: pike8.0
Followup-For: Bug #1066378
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
This is an update to the previous patch that contains further fixes to the
package.
In Ubuntu, the attached patch was applied to achieve the following:
* debian/patches/gz_test_fix.patch: Fix zlib detection logic.
* debian/patches/threads_undefined_var_fix.patch: Fix incorrect
variable referencing in threads.c. Closes LP: #2061023.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-26-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pike8.0-8.0.1738/debian/patches/gz_test_fix.patch
pike8.0-8.0.1738/debian/patches/gz_test_fix.patch
--- pike8.0-8.0.1738/debian/patches/gz_test_fix.patch 1969-12-31
17:00:00.0 -0700
+++ pike8.0-8.0.1738/debian/patches/gz_test_fix.patch 2024-04-11
14:31:45.0 -0600
@@ -0,0 +1,18 @@
+Description: Fix zlib detection logic
+ Fixes the issue where vendored zlib fails to compile on armhf
+Author: Zixing Liu
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066378
+Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/pike8.0/+bug/2061023
+Forwarded: no
+Last-Update: 2024-04-11
+--- pike8.0-8.0.1738.orig/src/modules/Gz/gz_test.c
pike8.0-8.0.1738/src/modules/Gz/gz_test.c
+@@ -320,6 +320,8 @@ void test_sync(compr, comprLen, uncompr,
+ err = inflateSync(_stream); /* but skip the damaged part */
+ CHECK_ERR(err, "inflateSync");
+
++inflateEnd(_stream);
++inflateInit(_stream);
+ err = inflate(_stream, Z_FINISH);
+ if (err != Z_DATA_ERROR) {
+ fprintf(stderr, "inflate should report DATA_ERROR\n");
diff -Nru pike8.0-8.0.1738/debian/patches/series
pike8.0-8.0.1738/debian/patches/series
--- pike8.0-8.0.1738/debian/patches/series 2022-04-18 11:30:23.0
-0600
+++ pike8.0-8.0.1738/debian/patches/series 2024-04-11 14:33:12.0
-0600
@@ -13,3 +13,5 @@
undefined_htons.patch
bad_size_t_redef.patch
dont_disable_debug_symbols.patch
+gz_test_fix.patch
+threads_undefined_var_fix.patch
diff -Nru pike8.0-8.0.1738/debian/patches/threads_undefined_var_fix.patch
pike8.0-8.0.1738/debian/patches/threads_undefined_var_fix.patch
--- pike8.0-8.0.1738/debian/patches/threads_undefined_var_fix.patch
1969-12-31 17:00:00.0 -0700
+++ pike8.0-8.0.1738/debian/patches/threads_undefined_var_fix.patch
2024-04-11 14:33:12.0 -0600
@@ -0,0 +1,16 @@
+Description: Fix incorrect variable referencing in threads.c
+Author: Zixing Liu
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/pike8.0/+bug/2061023
+Forwarded: no
+Last-Update: 2024-04-11
+--- pike8.0-8.0.1738.orig/src/threads.c
pike8.0-8.0.1738/src/threads.c
+@@ -3422,7 +3422,7 @@ static TH_RETURN_TYPE farm(void *_a)
+ int current = prctl(PR_GET_DUMPABLE);
+ #endif
+ #ifdef HAVE_BROKEN_LINUX_THREAD_EUID
+-if( setegid(arg.egid) != 0 || seteuid(arg.euid) != 0 )
++if( setegid(me->egid) != 0 || seteuid(me->euid) != 0 )
+ {
+ fprintf (stderr, "%s:%d: Unexpected error from setegid(2). errno=%d\n",
+ __FILE__, __LINE__, errno);
Bug#1067418: tpm2-tss: diff for NMU version 4.0.1-7.2
Control: tags 1067418 + patch
Dear maintainer,
I've prepared an NMU for tpm2-tss (versioned as 4.0.1-7.2). The diff
is attached to this message.
Cheers
--
Sebastian Ramacher
diff -Nru tpm2-tss-4.0.1/debian/changelog tpm2-tss-4.0.1/debian/changelog
--- tpm2-tss-4.0.1/debian/changelog 2024-02-29 19:28:02.0 +0100
+++ tpm2-tss-4.0.1/debian/changelog 2024-04-11 23:02:54.0 +0200
@@ -1,3 +1,11 @@
+tpm2-tss (4.0.1-7.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches: Apply upstream patch to skip tests which fail on 32-bit
+with _FILE_BITS=64 (Closes: #1067418)
+
+ -- Sebastian Ramacher Thu, 11 Apr 2024 23:02:54 +0200
+
tpm2-tss (4.0.1-7.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru tpm2-tss-4.0.1/debian/patches/series tpm2-tss-4.0.1/debian/patches/series
--- tpm2-tss-4.0.1/debian/patches/series 2024-01-25 14:46:19.0 +0100
+++ tpm2-tss-4.0.1/debian/patches/series 2024-04-11 23:02:01.0 +0200
@@ -4,3 +4,4 @@
0004-tss2-tcti-tcti-libtpms-fix-test-failure-on-big-endia.patch
fix-tcti-spi-helper-big-endian.patch
disable-tests-on-big-endian.patch
+skip-tests-which-fail-on-32-bit.patch
diff -Nru tpm2-tss-4.0.1/debian/patches/skip-tests-which-fail-on-32-bit.patch tpm2-tss-4.0.1/debian/patches/skip-tests-which-fail-on-32-bit.patch
--- tpm2-tss-4.0.1/debian/patches/skip-tests-which-fail-on-32-bit.patch 1970-01-01 01:00:00.0 +0100
+++ tpm2-tss-4.0.1/debian/patches/skip-tests-which-fail-on-32-bit.patch 2024-04-11 23:02:09.0 +0200
@@ -0,0 +1,120 @@
+From 932b1e78047ed0ddc09fcb06bff2e7cf96406976 Mon Sep 17 00:00:00 2001
+From: Juergen Repp
+Date: Sun, 17 Mar 2024 10:43:19 +0100
+Subject: [PATCH] unit tests: skip tests which fail on 32-bit with
+ _FILE_BITS=64
+
+Tests file the unit tests are compiled with _FILE_BITS is set to 64.
+The tests work without problems if _FILE_BITS is not set.
+Addresses: #2786
+
+Signed-off-by: Juergen Repp
+---
+ MAINTAINERS.md | 2 +-
+ test/unit/fapi-io.c | 7 +++
+ test/unit/tcti-device.c | 11 +++
+ test/unit/tcti-libtpms.c | 8
+ test/unit/tcti-pcap.c| 11 +++
+ 5 files changed, 38 insertions(+), 1 deletion(-)
+
+--- a/test/unit/fapi-io.c
b/test/unit/fapi-io.c
+@@ -28,6 +28,7 @@
+ #define LOGMODULE tests
+ #include "util/log.h"
+
++#define EXIT_SKIP 77
+ /*
+ * The unit tests will simulate error codes which can be returned by the
+ * system calls for file system IO.
+@@ -364,6 +365,12 @@
+ int
+ main(int argc, char *argv[])
+ {
++#if _FILE_OFFSET_BITS == 64
++// Would produce cmocka error
++LOG_WARNING("_FILE_OFFSET == 64 would produce cmocka errors.");
++return EXIT_SKIP;
++#endif
++
+ const struct CMUnitTest tests[] = {
+ };
+ return cmocka_run_group_tests(tests, NULL, NULL);
+--- a/test/unit/tcti-device.c
b/test/unit/tcti-device.c
+@@ -25,6 +25,11 @@
+ #include "tss2-tcti/tcti-common.h"
+ #include "tss2-tcti/tcti-device.h"
+
++#define LOGMODULE tests
++#include "util/log.h"
++
++#define EXIT_SKIP 77
++
+ /*
+ * Size of the TPM2 buffer used in these tests. In some cases this will be
+ * the command sent (transmit tests) and in others it's used as the response
+@@ -443,6 +448,12 @@
+ int
+ main(int argc, char* argv[])
+ {
++#if _FILE_OFFSET_BITS == 64
++// Would produce cmocka error
++LOG_WARNING("_FILE_OFFSET == 64 would produce cmocka errors.");
++return EXIT_SKIP;
++#endif
++
+ const struct CMUnitTest tests[] = {
+ cmocka_unit_test (tcti_device_init_all_null_test),
+ cmocka_unit_test(tcti_device_init_size_test),
+--- a/test/unit/tcti-libtpms.c
b/test/unit/tcti-libtpms.c
+@@ -28,6 +28,8 @@
+ #define LOGMODULE test
+ #include "util/log.h"
+
++#define EXIT_SKIP 77
++
+ #define LIBTPMS_DL_HANDLE 0x12345678
+ #define STATEFILE_PATH "statefile.bin"
+ #define STATEFILE_FD 0xAABB
+@@ -1612,6 +1614,12 @@
+ main(int argc,
+ char *argv[])
+ {
++#if _FILE_OFFSET_BITS == 64
++// Would produce cmocka error
++LOG_WARNING("_FILE_OFFSET == 64 would produce cmocka errors.");
++return EXIT_SKIP;
++#endif
++
+ const struct CMUnitTest tests[] = {
+ cmocka_unit_test(tcti_libtpms_init_all_null_test),
+ cmocka_unit_test(tcti_libtpms_init_dlopen_fail_test),
+--- a/test/unit/tcti-pcap.c
b/test/unit/tcti-pcap.c
+@@ -27,6 +27,11 @@
+ #include "tss2-tcti/tcti-common.h"
+ #include "tss2-tcti/tcti-pcap.h"
+
++#define LOGMODULE tests
++#include "util/log.h"
++
++#define EXIT_SKIP 77
++
+ #if (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__)
+ #define _LE32TOH(a,b,c,d) d,c,b,a
+ #define _LE16TOH(a,b) b,a
+@@ -726,6 +731,12 @@
+ main (int argc,
+ char *argv[])
+ {
++#if _FILE_OFFSET_BITS == 64
++// Would produce cmocka error
++LOG_WARNING("_FILE_OFFSET == 64 would produce cmocka errors.");
++return EXIT_SKIP;
++#endif
++
+ const struct CMUnitTest tests[] = {
+ cmocka_unit_test
Bug#1068842: node-undici: Fail upon being required
Package: node-undici Version: 5.28.4+dfsg1+~cs23.12.11-1 Severity: important Hi, Building node-undici in unstable (with nodejs 18.20.1 / openssl 3.2), then requiring it, fails with; Uncaught CompileError: WebAssembly.compile(): expected 48120 bytes, fell off end @+1361 Works fine in same environment with node-undici-5.28.2+dfsg1+_cs23.11.12.3-6. It's not a wasi-glibc regression. No idea what's happening, yet. It would be nice to figure this out, since it's going to block a needed nodejs transition. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1066378: pike8.0: FTBFS: zlibmod.c:1235:5: error: implicit declaration of function ‘pop_n_elems’ [-Werror=implicit-function-declaration]
Package: pike8.0
Followup-For: Bug #1066378
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* debian/patches/gz_test_fix.patch: Fix zlib detection logic. Closes
LP: #2061023.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-26-generic (SMP w/10 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pike8.0-8.0.1738/debian/patches/gz_test_fix.patch
pike8.0-8.0.1738/debian/patches/gz_test_fix.patch
--- pike8.0-8.0.1738/debian/patches/gz_test_fix.patch 1969-12-31
17:00:00.0 -0700
+++ pike8.0-8.0.1738/debian/patches/gz_test_fix.patch 2024-04-11
14:31:45.0 -0600
@@ -0,0 +1,18 @@
+Description: Fix zlib detection logic
+ Fixes the issue where vendored zlib fails to compile on armhf
+Author: Zixing Liu
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066378
+Bug-Ubuntu: https://bugs.launchpad.net/debian/+source/pike8.0/+bug/2061023
+Forwarded: no
+Last-Update: 2024-04-11
+--- pike8.0-8.0.1738.orig/src/modules/Gz/gz_test.c
pike8.0-8.0.1738/src/modules/Gz/gz_test.c
+@@ -320,6 +320,8 @@ void test_sync(compr, comprLen, uncompr,
+ err = inflateSync(_stream); /* but skip the damaged part */
+ CHECK_ERR(err, "inflateSync");
+
++inflateEnd(_stream);
++inflateInit(_stream);
+ err = inflate(_stream, Z_FINISH);
+ if (err != Z_DATA_ERROR) {
+ fprintf(stderr, "inflate should report DATA_ERROR\n");
diff -Nru pike8.0-8.0.1738/debian/patches/series
pike8.0-8.0.1738/debian/patches/series
--- pike8.0-8.0.1738/debian/patches/series 2022-04-18 11:30:23.0
-0600
+++ pike8.0-8.0.1738/debian/patches/series 2024-04-11 14:19:11.0
-0600
@@ -13,3 +13,4 @@
undefined_htons.patch
bad_size_t_redef.patch
dont_disable_debug_symbols.patch
+gz_test_fix.patch
Bug#1066313: fixed upstream
These issues are fixed upstream in main, but there is not a release. The fix is in commit 1171bf2fd4e7a0cab02cf5fca59090b65af9cd29. Clément would you pull that fix into the package to resolve this FTBFS?
Bug#1068825: apt: possible super minor security issue in apt-get source
On Thu, 2024-04-11 at 22:12 +0200, Julian Andres Klode wrote: > > => First, I'm not sure whether this is the right behaviour, as > > the > > "original/modified" file seems to get removed, but it - being > > a > > local file - may actually be something of value to the user. > > So maybe it should just move the file to foo.FAILED and error > > with non-zero exit status? and about that? > I think I'm fine just exiting 1 if the directory already exists, > after doing the download dance. At least I'd suggest to also give a human readable error message or warning. Just a non-zero exit status will be fine for scripts, but will look like an erroneous non-zero for humans. Cheers, Chris.
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
* Holger Levsen [2024-04-11 12:54]: > On Thu, Apr 11, 2024 at 11:28:19AM +0100, Chris Lamb wrote: > [...] > > Applied in Git with attribution taken from your email. > [...] > > Fixed as well. And it adds a nice comment displaying the issue. > > awesome, thank you both! The promised cpython issue: https://github.com/python/cpython/issues/117779 And a small follow-up: https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/140 - Fay
Bug#1068825: apt: possible super minor security issue in apt-get source
On Thu, Apr 11, 2024 at 05:52:47PM +0200, Christoph Anton Mitterer wrote: > Package: apt > Version: 2.7.14 > Severity: normal > Tags: security > > > Hey. > > I noted the following behaviour - which may or may not be regarded as > security relevant. > So this is rather a heads up, and in case you think it's fine as it is, > just close it. > > I always remembered that apt-get source was ought to verify hashes of > the downloaded files (i.e. secure APT as signed by the repo). > > Likewise, I thought to remember that at least at one point in time, > downloads of binary packages (via e.g. apt-get download or aptitude > download) were NOT verified. > Because of that I never trusted these which was quite unhandy. > > So I though I'd simply test that (using a local package repo and simply > changing one byte of the files to download), and turns out that apt-get > download DOES also verify the binary packages and exit with non-zero > status of the don't match. > Nice. > > > So just to be sure I did the same with the source package files. > And here I noted some things: > - It does check freshly downloaded files and exit with non-zero in case > their hashes mismatch. > - But it does so as well, with *already* downloaded files, and if they > don't match it silently downloads (also verified) fresh files. > => First, I'm not sure whether this is the right behaviour, as the > "original/modified" file seems to get removed, but it - being a > local file - may actually be something of value to the user. > So maybe it should just move the file to foo.FAILED and error > with non-zero exit status? > > > Then I made some particular tries: > a) On a previously (valid) downloaded source package I modified a byte >in the local .dsc and modified a byte in the remote .orig.tar.xz. >apt again notcies the valid local .orig.tar.xz and does nothing and >notices the invalid local .dsc and re-downloads it (which succeeds >as I haven't mangled the remote .dsc). > >In principle I'd say this is fine, and there's no direct security >issue ... and probably not even an indirect one. >What does however happen - due to the skipped download of the already >present+valid files - is that the remote corruption of he .orig.tar.xz >isn't notice. > >I'd say, not an issue, but nevertheless wanted to give a heads up. > > > b) What may now be the “super minor security issue” is the following: >apt *does* check already downloaded files for validity and exits >with zero if they match, right? > >So conceptuall one could have gone two ways: >- anything local is already trusted because it was verified before > or the user somehow manually brought it to the system and should > know what he's doing >- `apt-get source` acts also like a checker and if the exit status is > one can assume that the files present are valid > >It seems to be the 2nd, given that it verifies the local files. > >It does however NOT again verify any already unpacked tree. > >So in some super obscure scenarios, a user could come to assume that >exit status zero means that all the stuff is verified, while in fact >only the non unpacked files are. > >Again of course, for an attack, there would need to be some way to >introduce a modified unpacked tree, where one could say that if an >attacker can do that, it's anyway already too late. > >But simply from that conceptual PoV, it seems to me as if that >behaviour is unfortunate. > >I do however have no idea for a better behaviour. >Checking would anyway mean that we need to unpack it - therefore >wasting further resources. >And the tree may differ simply because of user modifications, what >then? Move the dir to xx.NON-PRISTINE? I think I'm fine just exiting 1 if the directory already exists, after doing the download dance. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1068812: [Pkg-electronics-devel] Bug#1068812: pcb-rnd: hardcoded librnd4 dependency
severity 1068812 minor tags 1068812 +pending thanks Gianfranco Costamagna writes: > Hello, I found that librnd4 is correctly evaluated from shlibs:Depends > in the core library and then it can be dropped also on core > reverse-dependencies. Thanks for the bug report. Fixed in packaging for the next upload. Downgrading since this is clearly not actually a release critical bug. Bdale signature.asc Description: PGP signature
Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone
> I'll look at getting the man pages fixed. I've filed https://bugzilla.kernel.org/show_bug.cgi?id=218711 against the strftime man page. For localtime(), it may be sufficient that the man page indicates that localtime() behaves as if tzset() were called, and that the tzset man page indicates that TZ is used. The macOS man page, however, *does* mention TZ, and that may also be true of the ctime man page in other BSDs.
Bug#1068833: discover: A game installed via Discover doesn't start
On 11/04/2024 at 20:22, Ilkka Kallioniemi wrote: Package: discover (...) When installing game MegaGlest using Discover, the installed game is not fully installed. Discover is a hardware identification system. Aren't your confusing with plasma-discover ?
Bug#1068841: RM: esniper -- RoQA; orphaned; doesn't work; dead upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: esni...@packages.debian.org Control: affects -1 + src:esniper User: ftp.debian@packages.debian.org Usertags: remove According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855461 and https://sourceforge.net/p/esniper/bugs/803/ the package doesn't work at all and there is no upstream solution for that either. Orphaned since 2022. $ dak rm -Rn esniper Will remove the following packages from unstable: esniper | 2.35.0+git20190805.7930bb4-1 | source esniper | 2.35.0+git20190805.7930bb4-1+b1 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, s390x esniper | 2.35.0+git20190805.7930bb4-1+b2 | riscv64 Maintainer: Dima Barsky --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#1068840: llvm-toolchain-14: FTBFS on mips64el: /<>/compiler-rt/lib/builtins/clear_cache.c:97:3: error: implicit declaration of function 'syscall' is invalid in C99 [-Werror,-Wimplicit
Source: llvm-toolchain-14 Version: 1:14.0.6-19 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramac...@debian.org https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-14=mips64el=1%3A14.0.6-19=1712480299=0 [122/276] /<>/build-llvm/./bin/clang --target=mips64el-linux-gnuabi64 -DVISIBILITY_HIDDEN -Werror=implicit-function-declaration -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -mips32r2 -mabi=32 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-mipsel.dir/clear_cache.c.o -MF CMakeFiles/clang_rt.builtins-mipsel.dir/clear_cache.c.o.d -o CMakeFiles/clang_rt.builtins-mipsel.dir/clear_cache.c.o -c /<>/compiler-rt/lib/builtins/clear_cache.c FAILED: CMakeFiles/clang_rt.builtins-mipsel.dir/clear_cache.c.o /<>/build-llvm/./bin/clang --target=mips64el-linux-gnuabi64 -DVISIBILITY_HIDDEN -Werror=implicit-function-declaration -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -mips32r2 -mabi=32 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-mipsel.dir/clear_cache.c.o -MF CMakeFiles/clang_rt.builtins-mipsel.dir/clear_cache.c.o.d -o CMakeFiles/clang_rt.builtins-mipsel.dir/clear_cache.c.o -c /<>/compiler-rt/lib/builtins/clear_cache.c /<>/compiler-rt/lib/builtins/clear_cache.c:97:3: error: implicit declaration of function 'syscall' is invalid in C99 [-Werror,-Wimplicit-function-declaration] syscall(__NR_cacheflush, start, (end_int - start_int), BCACHE); ^ 1 error generated. [123/276] /<>/build-llvm/./bin/clang --target=mips64el-linux-gnuabi64 -DVISIBILITY_HIDDEN -Werror=implicit-function-declaration -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -mips32r2 -mabi=32 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-mipsel.dir/gcc_personality_v0.c.o -MF CMakeFiles/clang_rt.builtins-mipsel.dir/gcc_personality_v0.c.o.d -o CMakeFiles/clang_rt.builtins-mipsel.dir/gcc_personality_v0.c.o -c /<>/compiler-rt/lib/builtins/gcc_personality_v0.c [124/276] /<>/build-llvm/./bin/clang --target=mips64el-linux-gnuabi64 -DVISIBILITY_HIDDEN -Werror=implicit-function-declaration -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -mips32r2 -mabi=32 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-mipsel.dir/emutls.c.o -MF CMakeFiles/clang_rt.builtins-mipsel.dir/emutls.c.o.d -o CMakeFiles/clang_rt.builtins-mipsel.dir/emutls.c.o -c /<>/compiler-rt/lib/builtins/emutls.c [125/276] /<>/build-llvm/./bin/clang --target=mips64el-linux-gnuabi64 -DVISIBILITY_HIDDEN -Werror=implicit-function-declaration -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -mips64r2 -mabi=64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-mips64el.dir/comparetf2.c.o -MF CMakeFiles/clang_rt.builtins-mips64el.dir/comparetf2.c.o.d -o CMakeFiles/clang_rt.builtins-mips64el.dir/comparetf2.c.o -c /<>/compiler-rt/lib/builtins/comparetf2.c [126/276] /<>/build-llvm/./bin/clang --target=mips64el-linux-gnuabi64 -DVISIBILITY_HIDDEN -Werror=implicit-function-declaration -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -mips64r2 -mabi=64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-mips64el.dir/addtf3.c.o -MF CMakeFiles/clang_rt.builtins-mips64el.dir/addtf3.c.o.d -o CMakeFiles/clang_rt.builtins-mips64el.dir/addtf3.c.o -c /<>/compiler-rt/lib/builtins/addtf3.c [127/276] /<>/build-llvm/./bin/clang --target=mips64el-linux-gnuabi64 -DVISIBILITY_HIDDEN -Werror=implicit-function-declaration -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-command-line-argument -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -mips64r2 -mabi=64 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-mips64el.dir/divtc3.c.o -MF CMakeFiles/clang_rt.builtins-mips64el.dir/divtc3.c.o.d -o CMakeFiles/clang_rt.builtins-mips64el.dir/divtc3.c.o -c /<>/compiler-rt/lib/builtins/divtc3.c ninja: build stopped: subcommand failed. FAILED:
Bug#1068810: [Pkg-electronics-devel] Bug#1068810: sch-rnd: hardcoded librnd4 dependency
Gianfranco Costamagna writes: > Hello, I found that librnd4 is correctly evaluated from shlibs:Depends > in the core library and then it can be dropped also on core > reverse-dependencies. The point of the dependency is to require version 4.1.0 or later, since that's the librnd version that added support for hierarchical design which is required by this and later releases of sch-rnd. > Please drop it. What actual problem are you trying to solve with this bug report? Bdale signature.asc Description: PGP signature
Bug#1068839: RM: lua5.1-policy -- RoQA; orphaned; FTBFS; unused
Package: ftp.debian.org Severity: normal Tags: ftbfs X-Debbugs-Cc: lua5.1-pol...@packages.debian.org Control: affects -1 + src:lua5.1-policy User: ftp.debian@packages.debian.org Usertags: remove Last maintainer upload in 2011, orphaned since 2021, no longer builds because it uses compat 5, popcon 22. lua5.1-policy-dev has no reverse build-deps and the policy itself is clearly obsolete, talking about liblua-* packages which no longer exist. $ dak rm -Rn lua5.1-policy Will remove the following packages from unstable: lua5.1-policy |33+nmu1 | source, all lua5.1-policy-dev |33+nmu1 | all Maintainer: Enrico Tassi --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#1068838: freecell-solver-bin: gen-multiple-pysol-layouts crashed with ModuleNotFoundError
Package: freecell-solver-bin Version: 5.0.0-2+b1 Severity: normal Dear Maintainer, gen-multiple-pysol-layouts crashed immediately with the error: $ gen-multiple-pysol-layouts Traceback (most recent call last): File "/usr/bin/gen-multiple-pysol-layouts", line 16, in from fc_solve_find_index_s2ints import CardRenderer ModuleNotFoundError: No module named 'fc_solve_find_index_s2ints' -- Regards Sudip -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freecell-solver-bin depends on: ii libc62.37-15 ii libfreecell-solver0 5.0.0-2+b1 ii python3 3.11.6-1 freecell-solver-bin recommends no packages. freecell-solver-bin suggests no packages.
Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1
Hi Sebastian, On Tue, Apr 09, 2024 at 06:18:13PM +0200, Sebastian Andrzej Siewior wrote: > On 2024-04-07 23:46:28 [+0200], To Adam D. Barratt wrote: > > On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote: > > > > > > Sorry for not getting to this sooner. Is this still the case? > > > > So. This happened #1068045 (yapet broke with 1.0 format) due to the > > update. On the bright side it has been broken in unstable but unnoticed. > > Looking into it but also sleeping (but making progress). > > yapet is fixed in unstable. My understanding is that the maintainer will > take care of it. After exposure of the upload in unstable for two days, uploaded now as well to bookworm. Filled #1068836. Regards, Salvatore
Bug#1068837: RM: el-get -- RoQA; orphaned; RC-buggy; very old; low popcon
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: el-...@packages.debian.org Control: affects -1 + src:el-get User: ftp.debian@packages.debian.org Usertags: remove Last maintainer upload in 2011, orphaned since 2019, has an RC bug since 2018 with "we're not doing users of Debian any favours by shipping emacs package metadata that was last updated in 2011". Popcon 20. $ dak rm -Rn el-get Will remove the following packages from unstable: el-get | 3.1-2 | source, all Maintainer: Debian QA Group --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#1068836: bookworm-pu: package yapet/2.6-2~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ya...@packages.debian.org, car...@debian.org
Control: affects -1 + src:yapet
User: release.debian@packages.debian.org
Usertags: pu
Hi,
[ Reason ]
After the update of openssl/3.0.13-1~deb12u1 in bookworm-pu Sean found
that old 1.0 format databases. While most of people should have moved
some time ago to 2.0 format databases, they are still claimed to be
supported. The update of openssl uncovered though a bug in yapet (as
well present in unstable, and fixed as well).
Sebastian explained the situation in https://bugs.debian.org/1068045#94
[ Impact ]
Users using the old 1.0 format could not open anymore their store.
[ Tests ]
Done explicitly with an old 1.0 format database provided by sean,
running the testsuite, and manual checks with 2.0 format databases.
[ Risks ]
Patches provided by the openssl maintainer. While they are not yet
applied upstream, they tackle the bug in yapet as isolated by the
openssl maintainers.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
The two patches drop EVP_CIPHER_CTX_set_key_length() invocation to
keep compatiblity with 1.0 databases and with openssl versions.
Quoting the commit:
|yapet did for blowfish:
|
|| EVP_CipherInit_ex(ctx, cipher, NULL, KEY, iv, mode);
|| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
|| EVP_CipherUpdate(ctx, …);
|
|this worked in earlier OpenSSL versions and stopped working in
|openssl-3.0.13. The problem here is that the
|EVP_CIPHER_CTX_set_key_length() is ignored and the later OpenSSL version
|returns rightfully an error "Provider routines::no key set" here.
|
|Blowfish does support variable key lenghts but the key length has to be
|set first followed by the actual key. Otherwise the blocksize (16) will
|be used.
|The correct way to deal with this would be:
|| EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, mode);
|| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
|| EVP_CipherInit_ex(ctx, NULL, NULL, KEY, IV, mode);
|| EVP_CipherUpdate(ctx, …);
|
|Using now the proper way will break earlier databases because in the
|blowfish case, always the default blocksize / 16 has been used.
|
|In order to keep compatibility with earlier versions of the database and
|openssl remove the EVP_CIPHER_CTX_set_key_length() invocation.
While at it Sebastian fixed as well the invocation present for the
crypt/aes code.
[ Other info ]
None.
Regards,
Salvatore
diff -Nru yapet-2.6/debian/changelog yapet-2.6/debian/changelog
--- yapet-2.6/debian/changelog 2022-03-14 14:19:11.0 +0100
+++ yapet-2.6/debian/changelog 2024-04-11 20:40:18.0 +0200
@@ -1,3 +1,16 @@
+yapet (2.6-2~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm
+
+ -- Salvatore Bonaccorso Thu, 11 Apr 2024 20:40:18 +0200
+
+yapet (2.6-2) unstable; urgency=medium
+
+ * crypt/blowfish: Remove EVP_CIPHER_CTX_set_key_length() (Closes: #1064724)
+ * crypt/aes: Remove EVP_CIPHER_CTX_set_key_length()
+
+ -- Salvatore Bonaccorso Mon, 08 Apr 2024 21:32:50 +0200
+
yapet (2.6-1) unstable; urgency=medium
* New upstream version 2.6
diff -Nru
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
---
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
1970-01-01 01:00:00.0 +0100
+++
yapet-2.6/debian/patches/crypt-aes-Remove-EVP_CIPHER_CTX_set_key_length.patch
2024-04-11 20:40:18.0 +0200
@@ -0,0 +1,41 @@
+From aaa573b14bafcc9a6b46495bd4ffc15b90d35902 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior
+Date: Mon, 8 Apr 2024 18:19:12 +0200
+Subject: [PATCH] crypt/aes: Remove EVP_CIPHER_CTX_set_key_length().
+
+The EVP_CIPHER_CTX_set_key_length() in the AES-256-CBC case is pointless
+because the key here is fixed EVP_CIPHER_CTX_set_key_length() and the
+function does not change the size.
+
+Remove the EVP_CIPHER_CTX_set_key_length() invocation.
+
+Signed-off-by: Sebastian Andrzej Siewior
+---
+ src/libs/crypt/aes256.cc | 11 ---
+ 1 file changed, 11 deletions(-)
+
+diff --git a/src/libs/crypt/aes256.cc b/src/libs/crypt/aes256.cc
+index 1041b9c57347..e105b1a5bedd 100644
+--- a/src/libs/crypt/aes256.cc
b/src/libs/crypt/aes256.cc
+@@ -113,17 +113,6 @@ EVP_CIPHER_CTX* Aes256::initializeOrThrow(const
SecureArray& ivec, MODE mode) {
+ throw CipherError{_("Error initializing cipher")};
+ }
+
+-success = EVP_CIPHER_CTX_set_key_length(context, getKey()->keySize());
+-if (success != SSL_SUCCESS) {
+-LOG_MESSAGE(std::string{__func__} + ": Error setting key length");
+-destroyContext(context);
+-char msg[YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE];
+-std::snprintf(msg,
Bug#1068835: RM: ptex-jtex -- RoQA; orphaned; FTBFS; no upstream; low popcon
Package: ftp.debian.org Severity: normal Tags: ftbfs X-Debbugs-Cc: ptex-j...@packages.debian.org Control: affects -1 + src:ptex-jtex User: ftp.debian@packages.debian.org Usertags: remove Last maintainer upload in 2014, orphaned since 2015, doesn't build because it uses compat 5. No upstream, the upstream code is from 1992. Popcon 10. It's also non-free.
Bug#1068834: RM: sopel -- RoQA; orphaned; NPOASR; very old
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: so...@packages.debian.org Control: affects -1 + src:sopel User: ftp.debian@packages.debian.org Usertags: remove Last maintainer upload in 2019, orphaned since 2019, 6.x is "we don't support anymore" per an upstream 2021 comment in https://github.com/sopel- irc/sopel/issues/2022 >From the Orphaning email: "I also couldn't find a good reason to use this instead of more established codebase like Limnoria, which are seeing way more development and third-party packages. There is also an RC bug https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=943405 which doesn't make much sense to me and seems to be debunked by the upstream in https://github.com/sopel-irc/sopel/issues/2022 but meh. $ dak rm -Rn sopel Will remove the following packages from unstable: sopel | 6.6.9-2.2 | source, all Maintainer: Debian QA Group --- Reason --- -- Checking reverse dependencies... No dependency problem found.
Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi On 11-04-2024 5:18 p.m., 陈 晟祺 wrote: If possible, could you help to build with latest code on salsa then run autopkgtest again on a normal debci VM? As I'm doing this live on the infrastructure, I don't want to do anything there except testing what's in the archive, sorry. My private setup (laptop) is not powerful enough to run this. I'm not 100% percent sure how to instruct you to build a ci.d.n like image. I think it's: $ autopkgtest-build-qemu debian testing $ /usr/bin/autopkgtest --no-built-binaries --test-name=zfs-test-suite --user debci zfs-linux -- qemu except I don't know where autopkgtest-build-qemu stores the image. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068833: discover: A game installed via Discover doesn't start
Package: discover Version: 2.1.2-10 Severity: normal X-Debbugs-Cc: ifonxordgmdwhqy...@cazlg.com Dear Maintainer, When installing game MegaGlest using Discover, the installed game is not fully installed. Menu items appear correctly, but the application is missing an important package. A quick check with aptitude shows that `megaglest-data` gets installed, but the main package `megaglest` is not installed. Installing `megaglest` via terminal fixed the issue and uninstalling MegaGlest using Discover did remove both `megaglest` and `megaglest-data` packages. -- 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-18-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages discover depends on: ii debconf [debconf-2.0] 1.5.82 ii libc6 2.36-9+deb12u4 ii libdiscover2 2.1.2-10 discover recommends no packages. Versions of packages discover suggests: ii sysvinit-utils [lsb-base] 3.06-4 -- debconf information excluded
Bug#1066421: mpb: diff for NMU version 1.11.1-5.1
Control: tags 1066421 + patch Control: tags 1066421 + pending Dear maintainer, I've prepared an NMU for mpb (versioned as 1.11.1-5.1) and uploaded it to unstable. Regards. -- WBR, wRAR diff -Nru mpb-1.11.1/debian/changelog mpb-1.11.1/debian/changelog --- mpb-1.11.1/debian/changelog 2022-12-15 02:17:01.0 +0500 +++ mpb-1.11.1/debian/changelog 2024-04-11 23:13:16.0 +0500 @@ -1,3 +1,10 @@ +mpb (1.11.1-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066421). + + -- Andrey Rakhmatullin Thu, 11 Apr 2024 23:13:16 +0500 + mpb (1.11.1-5) unstable; urgency=medium * debian/control: bump Standards Version to 4.6.1 (no changes) diff -Nru mpb-1.11.1/debian/patches/18-fix-implicit-function-declaration.patch mpb-1.11.1/debian/patches/18-fix-implicit-function-declaration.patch --- mpb-1.11.1/debian/patches/18-fix-implicit-function-declaration.patch 1970-01-01 05:00:00.0 +0500 +++ mpb-1.11.1/debian/patches/18-fix-implicit-function-declaration.patch 2024-04-11 23:11:20.0 +0500 @@ -0,0 +1,53 @@ +Description: Add missing header includes. +Author: Andrey Rakhmatullin +Bug-Debian: https://bugs.debian.org/1066421 +Last-Update: 2024-04-11 + +Index: mpb-1.11.1/mpb/fields.c +=== +--- mpb-1.11.1.orig/mpb/fields.c mpb-1.11.1/mpb/fields.c +@@ -20,6 +20,7 @@ + #include + #include + #include ++#include + + #include "config.h" + #include +Index: mpb-1.11.1/mpb/field-smob.c +=== +--- mpb-1.11.1.orig/mpb/field-smob.c mpb-1.11.1/mpb/field-smob.c +@@ -17,6 +17,7 @@ + + #include + #include ++#include + + #include "config.h" + +Index: mpb-1.11.1/mpb/material_grid.c +=== +--- mpb-1.11.1.orig/mpb/material_grid.c mpb-1.11.1/mpb/material_grid.c +@@ -18,6 +18,7 @@ + #include + #include + #include ++#include + + #include "config.h" + #include +Index: mpb-1.11.1/mpb/material_grid_opt.c +=== +--- mpb-1.11.1.orig/mpb/material_grid_opt.c mpb-1.11.1/mpb/material_grid_opt.c +@@ -20,6 +20,7 @@ + #include + #include + #include ++#include + + #include "config.h" + #include diff -Nru mpb-1.11.1/debian/patches/series mpb-1.11.1/debian/patches/series --- mpb-1.11.1/debian/patches/series 2022-12-15 02:17:01.0 +0500 +++ mpb-1.11.1/debian/patches/series 2024-04-11 23:01:11.0 +0500 @@ -15,5 +15,6 @@ 14-mpb-mpb.1.patch 15-mpb-mpb-split.1.patch 16-utils-mpb-data.1.patch +18-fix-implicit-function-declaration.patch zzz-blas-problem-on-mipsel.patch signature.asc Description: PGP signature
Bug#1068832: Apper does not show the installation history anymore
Package: apper Version: 1.0.0 I think the installation history of the GUI Apper is very useful: it shows a history of package installs and removals with timestamps. I think it should also show other installations made via the command-line (dpkg.log files and .deb file installs). I don't know of any other pre-installed GUI in KDE that also shows an installation log and I proposed that non-default KSystemLog includes it. It doesn't show any entries anymore under History which are still shown on another machine. I recently upgraded from Debian11 to 12. When running apper in the console and opening the History page, it shows: >QObject::connect: No such slot >PackageKit::Transaction::transaction(QDBusObjectPath,QString,bool,uint,uint,QString,uint,QString). Before opening the page there is: >QCommandLineParser: already having an option named "h" >QCommandLineParser: already having an option named "help-all" >QCommandLineParser: already having an option named "v" >QCommandLineParser: option not defined: "install-provide-file" >apper: >apper:
Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone
> Very little, if anything, of strftime() needs to handle TZ, because it's
> handed a const struct tm *, generated either by a call to localtime() or
> gmtime() If generated by a call to localtime(), localtime() has already done
> all the work of converting a time_t to local time, meaning that it's
> localtime(), not strftime(), that uses TZ.
I just checked the tip-of-the-main-branch GNU libc, and, in the time
subdirectory:
strftime_l.c does *not* call getenv(), and thus strftime() does *not*
directly look at TZ;
tzset.c *does* call getenv("TZ") - which it has to do, as it sets the
current time information for the current process based on the setting of TZ.
I'll look at getting the man pages fixed.
Bug#1068831: util-linux: dmesg -H is no more human readable
Package: util-linux Version: 2.40-5 Severity: normal Dear Maintainer, After upgrading to 2.40-5, I have output like this when typing dmesg -H : ESC[32m[ +0,000529] ESC[0mNo NUMA configuration found ESC[32m[ +0,01] ESC[0mFaking a node at [mem 0x-0x000c5f7f] ESC[32m[ +0,08] ESC[0mNODE_DATA(0) allocated [mem 0xc5f7d5000-0xc5f7f] ESC[32m[ +0,000242] ESC[0mZone ranges: ESC[32m[ +0,01] ESC[0m DMA [mem 0x1000-0x00ff] ESC[32m[ +0,02] ESC[0m DMA32[mem 0x0100-0x] ESC[32m[ +0,02] ESC[0m Normal [mem 0x0001-0x000c5f7f] ESC[32m[ +0,02] ESC[0m Device empty ESC[32m[ +0,01] ESC[0mMovable zone start for each node ESC[32m[ +0,02] ESC[0mEarly memory node ranges ESC[32m[ +0,00] ESC[0mESC[33m node 0: ESC[0m[mem 0x1000-0x0009efff] ESC[32m[ +0,02] ESC[0mESC[33m node 0: ESC[0m[mem 0x0010-0x8c36efff] ESC[32m[ +0,01] ESC[0mESC[33m node 0: ESC[0m[mem 0x91fff000-0x91ff] ESC[32m[ +0,01] ESC[0mESC[33m node 0: ESC[0m[mem 0x0001-0x000c5f7f] ESC[32m[ +0,04] ESC[0mInitmem setup node 0 [mem 0x1000-0x000c5f7f] Reverting to 2.39.3-6 solves the issue. Best regards -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 util-linux depends on: ii libblkid1 2.40-5 ii libc6 2.37-17 ii libcap-ng0 0.8.4-2 ii libcrypt1 1:4.4.36-4 ii libmount1 2.40-5 ii libpam0t64 [libpam0g] 1.5.3-4 ii libselinux13.5-2+b2 ii libsmartcols1 2.40-5 ii libsystemd0255.4-1+b1 ii libtinfo6 6.4+20240113-1 ii libudev1 255.4-1+b1 ii libuuid1 2.40-5 Versions of packages util-linux recommends: ii sensible-utils 0.0.22 Versions of packages util-linux suggests: ii dosfstools 4.2-1.1 ii kbd 2.6.4-2 pn util-linux-extra pn util-linux-locales -- no debconf information
Bug#1066340: marked as done (t4kcommon: FTBFS: linebreak.c:163:19: error: implicit declaration of function ‘u8_mbtouc_unsafe’ [-Werror=implicit-function-declaration])
Dear Chris, On Thu, Apr 11, 2024 at 05:51:05PM +, Debian Bug Tracking System wrote: > Date: Thu, 11 Apr 2024 17:50:02 + > From: Debian FTP Masters > To: 1066340-cl...@bugs.debian.org > Subject: Bug#1066340: fixed in t4kcommon 0.1.1-11.2 > Reply-To: Chris Hofstaedtler thanks for that NMU, much appreciated! <3 -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Because things are the way they are, things will not stay the way they are. (Bertolt Brecht) signature.asc Description: PGP signature
Bug#1068830: lcov: changelog says "Depend on python:Depends" but binary package dependency on python was removed
Package: lcov Version: 2.1~beta-1 Severity: minor Dear Maintainer, While checking packages about to be upgraded, I noticed lcov 2.1~beta2-1 does not depend on python anymore (not even python3), but only on: --- gcc --- libcapture-tiny-perl --- libdatetime-perl --- libjson-perl --- libperlio-gzip-perl --- libtimedate-perl --- perl:any But the changelog for 2.1~beta2-1 says: * Depend on python:Depends Thus I'm wondering if the removal of the dependency on python was intended? (If yes, this report can be closed right away) Thanks! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (950, 'unstable'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lcov depends on: ii gcc 4:13.2.0-7 ii libcapture-tiny-perl 0.48-2 ii libdatetime-perl 2:1.65-1+b1 ii libjson-perl 4.1-1 ii libperlio-gzip-perl 0.20-1+b3 ii libtimedate-perl 2.3300-2 ii perl 5.38.2-3.2 ii python3-all 3.11.8-1 Versions of packages lcov recommends: pn libgd-gd2-perl lcov suggests no packages. -- no debconf information -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F |
Bug#1068798: bookworm-pu: package fdroidserver/2.2.1-1
Control: tags -1 + moreinfo On Thu, 2024-04-11 at 11:36 +0200, Jochen Sprickerhof wrote: > [ ] the issue is verified as fixed in unstable > [...] > Upstream is still working on a long term fix that will be uploaded to > unstable later. I agreed with upstream to use use the patch provided > in the mail on oss-security already now. In any case, assuming that the issue affects unstable (which appears to be the case), it should be fixed there first. Regards, Adam
Bug#1068829: Disabling the autostart of KDE Connect and screenreader KAccessible
Package: kde-plasma-desktop Version: 5:142 These aren't needed for most users and are a privacy and security risk. In principle, it makes sense to only autostart things one actually needs to reduce the likelihood of crashes, the number of irrelevant log entries, the hardware resource consumption, and the attack surface (for example due to potential vulnerabilities in any of the software, especially if they constantly listen on some port). Many people are looking for ways to disable these autostarts and don't like that they're just enabled by default, see for example https://unix.stackexchange.com/questions/384306/why-does-kdeconnect-listen-on-port-1716-tcp-all-the-time-how-to-close-the-port and https://discuss.kde.org/t/how-to-disable-kde-connect/7686/3 (there two devs clarified that this is not a KDE issue but "a distribution issue" which is why I'm filing it here). I thought Debian was a distro with great regard for security and stability and that it considers privacy and actual user needs/practices. A major issue with these autostarts is that there is no proper way to disable them. See https://unix.stackexchange.com/questions/774190/how-to-permanently-disable-autostarting-of-applications-on-linux-debian These methods do not only require time and are inconvenient (it's not even clear which one to use), they also get reset when the packages get upgraded such as during a distro upgrade. KDE Connect constantly listens on some ports and according to the second link has been a known vector for a DOS attack. I think "Calendar Reminders", screenreader "Orca", and "geoclue-2.0" also should not autostart but this issue is only about wireless file/device sharing app KDE Connection and KDE Accessible. I don't think these autostarts were enabled to give people a reason to get educated on autostarts and autostart-prevention and to harden these two apps. If that's why they were automatically starting by default so far, then they should still be disabled now. If needed, the user could be asked if they want to have these autostart during initial installation. Rather than bundling security-reducing bloat autostarts, I suggest that if these are installed by default at all, they are not configured to autostart. The user can easily configure them to autostart if they actually want that in the "Autostart" settings.
Bug#952735: gnupg-pkcs11-scd: when used as scdaemon, `gnupg --card-status` reports wrong informations
Control: severity -1 normal Control: forwarded -1 https://github.com/alonbl/gnupg-pkcs11-scd/issues/61 I can reproduce this bug with my card reader and I forwarded the bug upstream -> https://github.com/alonbl/gnupg-pkcs11-scd/issues/61 As this is just a cosmectic bug, I reduce severity again to normal.
Bug#1066860: libprelude ftbfs on time_t64 archs
Control: reopen -1 On Thu, Mar 14, 2024 at 04:14:25PM +0100, Matthias Klose wrote: > libprelude ftbfs on time_t64 archs with symbols file mismatches. This still happens, it wasn't addressed in the upload that closed this: https://buildd.debian.org/status/fetch.php?pkg=libprelude=armel=5.2.0-5.4=1712765101=0 > patch at > http://launchpadlibrarian.net/719321091/libprelude_5.2.0-5.3build2_5.2.0-5.3ubuntu1.diff.gz This seems to be about different symbols though. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1068828: non-portable use of cp -n triggers warning at update-initramfs time
Package: yubikey-luks
Version: 0.5.1+29.g5df2b95-6.2
Severity: minor
Tags: patch
Hi,
the use of "cp -pnL" in /usr/share/initramfs-tools/hooks/yubikey-luks
triggers a warning "cp: warning: behavior of -n is non-portable and may
change in future; use --update=none instead" when the initramfs is
rebuilt.
--- yubikey-luks2024-04-11 18:27:36.614656012 +0200
+++ /usr/share/initramfs-tools/hooks/yubikey-luks 2024-04-11
18:28:05.614804445 +0200
@@ -23,7 +23,7 @@
copy_exec /usr/bin/sha256sum
cp /usr/share/yubikey-luks/ykluks-keyscript "${DESTDIR}/sbin/ykluks-keyscript"
cp /etc/ykluks.cfg "${DESTDIR}/etc/ykluks.cfg"
-cp -pnL /usr/lib/yubikey-luks/initramfs-suspend "${DESTDIR}/suspend"
+cp -pL --update=none /usr/lib/yubikey-luks/initramfs-suspend
"${DESTDIR}/suspend"
chmod 755 "${DESTDIR}/suspend"
exit 0
Makes the warning go away. I am not yet using the functionality so I
don't whether this introduces breakage.
Greetings
Marc
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages yubikey-luks depends on:
ii cryptsetup 2:2.7.2-1
ii initramfs-tools 0.142
ii yubikey-personalization 1.20.0-3+b1
Versions of packages yubikey-luks recommends:
ii cryptsetup-initramfs 2:2.7.2-1
ii expect5.45.4-3
yubikey-luks suggests no packages.
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/share/initramfs-tools/hooks/yubikey-luks (from
yubikey-luks package)
Bug#1068827: Changes from the 0.14.1-5.1 NMU were discarded
Source: falcosecurity-libs Version: 0.15.1-1 Severity: serious 0.15.1-1 doesn't seem to contain changes from 0.14.1-5.1, both the changelog entry and the actual changes. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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
Bug#1068826: vobcopy: homepage seems dead
Source: vobcopy Version: 1.2.1-4 Severity: minor Hey. The site listed in the homepage field: Homepage: http://vobcopy.org seems dead and links eventually to some (I guess) Turikish football website. Should perhaps be removed and replaced with the github repo: https://github.com/barak/vobcopy *if* that is the actual upstream (which I haven't checked). Cheers, Chris.
Bug#1068825: apt: possible super minor security issue in apt-get source
Package: apt Version: 2.7.14 Severity: normal Tags: security Hey. I noted the following behaviour - which may or may not be regarded as security relevant. So this is rather a heads up, and in case you think it's fine as it is, just close it. I always remembered that apt-get source was ought to verify hashes of the downloaded files (i.e. secure APT as signed by the repo). Likewise, I thought to remember that at least at one point in time, downloads of binary packages (via e.g. apt-get download or aptitude download) were NOT verified. Because of that I never trusted these which was quite unhandy. So I though I'd simply test that (using a local package repo and simply changing one byte of the files to download), and turns out that apt-get download DOES also verify the binary packages and exit with non-zero status of the don't match. Nice. So just to be sure I did the same with the source package files. And here I noted some things: - It does check freshly downloaded files and exit with non-zero in case their hashes mismatch. - But it does so as well, with *already* downloaded files, and if they don't match it silently downloads (also verified) fresh files. => First, I'm not sure whether this is the right behaviour, as the "original/modified" file seems to get removed, but it - being a local file - may actually be something of value to the user. So maybe it should just move the file to foo.FAILED and error with non-zero exit status? Then I made some particular tries: a) On a previously (valid) downloaded source package I modified a byte in the local .dsc and modified a byte in the remote .orig.tar.xz. apt again notcies the valid local .orig.tar.xz and does nothing and notices the invalid local .dsc and re-downloads it (which succeeds as I haven't mangled the remote .dsc). In principle I'd say this is fine, and there's no direct security issue ... and probably not even an indirect one. What does however happen - due to the skipped download of the already present+valid files - is that the remote corruption of he .orig.tar.xz isn't notice. I'd say, not an issue, but nevertheless wanted to give a heads up. b) What may now be the “super minor security issue” is the following: apt *does* check already downloaded files for validity and exits with zero if they match, right? So conceptuall one could have gone two ways: - anything local is already trusted because it was verified before or the user somehow manually brought it to the system and should know what he's doing - `apt-get source` acts also like a checker and if the exit status is one can assume that the files present are valid It seems to be the 2nd, given that it verifies the local files. It does however NOT again verify any already unpacked tree. So in some super obscure scenarios, a user could come to assume that exit status zero means that all the stuff is verified, while in fact only the non unpacked files are. Again of course, for an attack, there would need to be some way to introduce a modified unpacked tree, where one could say that if an attacker can do that, it's anyway already too late. But simply from that conceptual PoV, it seems to me as if that behaviour is unfortunate. I do however have no idea for a better behaviour. Checking would anyway mean that we need to unpack it - therefore wasting further resources. And the tree may differ simply because of user modifications, what then? Move the dir to xx.NON-PRISTINE? HTH, Chris.
Bug#1029097: pam: FTBFS on hurd-i386
On Thu, 2024-04-11 at 14:02 -0300, Diego Nieto Cid wrote:
> Hello
>
> > --- /dev/null
> > +++ pam-1.5.3/libpam/include/path_max.h
> > @@ -0,0 +1,7 @@
> > +/*
> > + * Define PATH_MAX if not available
> > + */
> > +
> > +#ifndef PAH_MAX
>
> There's a typo here ^
>
> > +#define PATH_MAX 4096
> > +#endif
>
> Cheers
Thanks,
New patch attached.
Description: define PATH_MAX for compatibility when it's not already set
Some platforms, such as the Hurd, don't set PATH_MAX. Set a reasonable
default value in this case.
Authors: Steve Langasek , Svante Signell
Bug-Debian: http://bugs.debian.org/
Index: pam-1.5.3/libpam/include/path_max.h
===
--- /dev/null
+++ pam-1.5.3/libpam/include/path_max.h
@@ -0,0 +1,7 @@
+/*
+ * Define PATH_MAX if not available
+ */
+
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
Index: pam-1.5.3/tests/tst-dlopen.c
===
--- pam-1.5.3.orig/tests/tst-dlopen.c
+++ pam-1.5.3/tests/tst-dlopen.c
@@ -16,6 +16,9 @@
#include
#include
+/* Hurd compatibility */
+#include "path_max.h"
+
/* Simple program to see if dlopen() would succeed. */
int main(int argc, char **argv)
{
Index: pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
===
--- pam-1.5.3.orig/modules/pam_debug/tst-pam_debug-retval.c
+++ pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_debug"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
===
--- pam-1.5.3.orig/modules/pam_deny/tst-pam_deny-retval.c
+++ pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_deny"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
===
--- pam-1.5.3.orig/modules/pam_echo/tst-pam_echo-retval.c
+++ pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_echo"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
===
--- pam-1.5.3.orig/modules/pam_faildelay/tst-pam_faildelay-retval.c
+++ pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_faildelay"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
===
--- pam-1.5.3.orig/modules/pam_localuser/tst-pam_localuser-retval.c
+++ pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_localuser"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
===
--- pam-1.5.3.orig/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
+++ pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_mkhomedir"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
===
--- pam-1.5.3.orig/modules/pam_nologin/tst-pam_nologin-retval.c
+++ pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_nologin"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_permit/tst-pam_permit-retval.c
===
--- pam-1.5.3.orig/modules/pam_permit/tst-pam_permit-retval.c
+++ pam-1.5.3/modules/pam_permit/tst-pam_permit-retval.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_permit"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_rootok/tst-pam_rootok-retval.c
===
--- pam-1.5.3.orig/modules/pam_rootok/tst-pam_rootok-retval.c
+++ pam-1.5.3/modules/pam_rootok/tst-pam_rootok-retval.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include "path_max.h"
#define MODULE_NAME "pam_rootok"
#define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_warn/tst-pam_warn-retval.c
Bug#1068824: welle.io: Remove myself from uploaders
Package: welle.io Version: 2.4+ds-2 Severity: normal Tags: patch Dear Maintainer, Please remove me from the Uploaders list, either with the attached patch, or by merging the MR at: https://salsa.debian.org/debian-hamradio-team/welle.io/-/merge_requests/5 Patch also available at: https://salsa.debian.org/debian-hamradio-team/welle.io/-/merge_requests/ 5.patch -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 'unstable'), (93, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages welle.io depends on: ii libairspy0 1.0.10-2+b1 ii libasound2 1.2.8-1+b1 ii libc6 2.36-9+deb12u4 ii libfaad2 2.10.1-1 ii libfftw3-single3 3.3.10-1 ii libgcc-s1 12.2.0-14 ii libmp3lame03.100-6 ii libmpg123-01.31.2-1 ii libqt5charts5 5.15.8-2 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus55.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5multimedia5 5.15.8-2 ii libqt5multimedia5-plugins 5.15.8-2 ii libqt5qml5 5.15.8+dfsg-3 ii libqt5quick5 5.15.8+dfsg-3 ii libqt5quickcontrols2-5 5.15.8+dfsg-2 ii libqt5widgets5 5.15.8+dfsg-11 ii librtlsdr0 0.6.0-4 ii libsoapysdr0.8 0.8.1-3 ii libstdc++6 12.2.0-14 ii qml-module-qt-labs-settings5.15.8+dfsg-3 ii qml-module-qtcharts5.15.8-2 ii qml-module-qtgraphicaleffects 5.15.8-2 ii qml-module-qtquick-controls5.15.8-2 ii qml-module-qtquick-controls2 5.15.8+dfsg-2 ii qml-module-qtquick-dialogs 5.15.8-2 ii qml-module-qtquick-layouts 5.15.8+dfsg-3 ii qml-module-qtquick-localstorage5.15.8+dfsg-3 ii qml-module-qtquick-privatewidgets 5.15.8-2 ii qml-module-qtquick-templates2 5.15.8+dfsg-2 ii qml-module-qtquick-window2 5.15.8+dfsg-3 ii qml-module-qtquick25.15.8+dfsg-3 welle.io recommends no packages. welle.io suggests no packages. -- no debconf information From 0a8b301271c09be6c69bf6989b79f542dd19bf74 Mon Sep 17 00:00:00 2001 From: bastif <9907-bas...@users.noreply.salsa.debian.org> Date: Thu, 11 Apr 2024 16:47:12 + Subject: [PATCH] d/control: remove myself from Uploaders. --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 2168e65..e79eaef 100644 --- a/debian/control +++ b/debian/control @@ -2,7 +2,7 @@ Source: welle.io Section: hamradio Priority: optional Maintainer: Debian Hamradio Maintainers -Uploaders: Gürkan Myczko , Fab Stz +Uploaders: Gürkan Myczko Build-Depends: cmake, debhelper-compat (= 13), libairspy-dev, -- GitLab
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
Package: general A distro upgrade of Debian needs a lot of disk space on the root partition. That partition often doesn't have a large size. That could for example be because it's on a mobile device, on a SSD drive, has lots of installed software, or because the user simply followed the advice of guides that usually recommend the root partition to be relatively small. I had this problem when upgrading to Debian12 and also had it during the last distro upgrade. A problem is that the storage requirements displayed when running sudo apt-get upgrade --without-new-pkgs or sudo apt-get full-upgrade are lower than what is actually needed. Obviously, that shouldn't be the case. Solving this problem could be redundant if there was a way to make it upgrade incrementally in several steps. Could you please make stepwise distribution upgrades possible? With the two commands above one can already split it up into two steps but especially the second command still requires a lot of disk space. That it displays less storage requirements than actually needed makes it more difficult to avoid the problem. Avoiding and solving potential issues resulting from the upgrade breaking or from what the user tries to do to free up disk space requires skill and time, and makes the upgrade userunfriendly and far less smooth than it could be. Here's what I do to free up disk space and I had to do some of the things while the upgrade was ongoing as I noticed that it takes up more disk space than I previously freed up: https://unix.stackexchange.com/q/774199/233262 (such as deleting the cached packages after an unrelated fatal error breaking the upgrade so that it downloaded half of them again when I ran the full-upgrade command again after solving that). This could also be an issue for apt but it could probably also be done independently from that package which is why I filed it under general for now. One could also make it so that it dynamically adjusts depending on how much disk space is available throughout the upgrade. It could and probably should still only be one command. For example, I think a good approach to this would be something like this (if the user is low on root partition disk space): 1. asking for *at least* 400MB to be available 2. if a parameter for stepwise is set or it detected low free disk space: 3. downloading the first 300 MB or so of packages 4. installing these 5. deleting the cached packages from /var/cache/apt/archives/ 6. downloading the next batch up to the storage limit set at start 7. and so on (without exiting in-between)
Bug#1062445: yq: Replace with alternative yq app
I second the original request. I installed yq on my Mac using “brew install yq”, wrote a script and then deployed it to a Debian machine on which I’d run “apt install yq". But when I ran the script on the Debian machine I got a syntax error in the “yq” command. It was then that I realised Homebrew had installed the mikefarah version but Debian had installed the kislyuk version. Looking at the GitHub pages for the two projects the mikefarah one has over four times the number of stars of the kislyuk one so is the more popular of the two. It’s also a separate fully-featured program rather than just being a wrapper round jq.
Bug#1066134: ppp: FTBFS due -Werror=implicit-function-declaration
block 1036884 by 1066134 tags 1066134 +patch thanks Hi. The build failure of ppp in unstable is a blocker for the time_t transition, since ppp needs to be rebuilt against the new versions of libpcap and openssl. The version in experimental seems to build fine. Can you fix this, either by adding a backported patch (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066134#12 ), or by uploading the version in experimental to unstable? or would you prefer that someone prepares a NMU?
Bug#1068822: qemu: CVE-2024-3567
Source: qemu X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for qemu. CVE-2024-3567[0]: | A flaw was found in QEMU. An assertion failure was present in the | update_sctp_checksum() function in hw/net/net_tx_pkt.c when trying | to calculate the checksum of a short-sized fragmented packet. This | flaw allows a malicious guest to crash QEMU and cause a denial of | service condition. https://bugzilla.redhat.com/show_bug.cgi?id=2274339 https://gitlab.com/qemu-project/qemu/-/issues/2273 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-3567 https://www.cve.org/CVERecord?id=CVE-2024-3567 Please adjust the affected versions in the BTS as needed.
Bug#1068821: qemu: CVE-2024-3447
Source: qemu X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for qemu. CVE-2024-3447[0]: https://patchew.org/QEMU/20240404085549.16987-1-phi...@linaro.org/ https://patchew.org/QEMU/20240409145524.27913-1-phi...@linaro.org/ https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58813 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-3447 https://www.cve.org/CVERecord?id=CVE-2024-3447 Please adjust the affected versions in the BTS as needed.
Bug#1068820: qemu: CVE-2024-3446
Source: qemu X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for qemu. CVE-2024-3446[0]: | A double free vulnerability was found in QEMU virtio devices | (virtio-gpu, virtio-serial-bus, virtio-crypto), where the | mem_reentrancy_guard flag insufficiently protects against DMA | reentrancy issues. This issue could allow a malicious privileged | guest to crash the QEMU process on the host, resulting in a denial | of service or allow arbitrary code execution within the context of | the QEMU process on the host. https://bugzilla.redhat.com/show_bug.cgi?id=2274211 https://patchew.org/QEMU/20240409105537.18308-1-phi...@linaro.org/ If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-3446 https://www.cve.org/CVERecord?id=CVE-2024-3446 Please adjust the affected versions in the BTS as needed.
Bug#1068819: qemu: CVE-2024-26327 CVE-2024-26328
Source: qemu X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerabilities were published for qemu. CVE-2024-26327[0]: | An issue was discovered in QEMU 7.1.0 through 8.2.1. register_vfs in | hw/pci/pcie_sriov.c mishandles the situation where a guest writes | NumVFs greater than TotalVFs, leading to a buffer overflow in VF | implementations. CVE-2024-26328[1]: | An issue was discovered in QEMU 7.1.0 through 8.2.1. register_vfs in | hw/pci/pcie_sriov.c does not set NumVFs to PCI_SRIOV_TOTAL_VF, and | thus interaction with hw/nvme/ctrl.c is mishandled. https://lore.kernel.org/all/20240213055345-mutt-send-email-mst%40kernel.org Introduced by: https://gitlab.com/qemu-project/qemu/-/commit/7c0fa8dff811b5648964630a1334c3bb97e1e1c6 (v7.0.0-rc0) If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-26327 https://www.cve.org/CVERecord?id=CVE-2024-26327 [1] https://security-tracker.debian.org/tracker/CVE-2024-26328 https://www.cve.org/CVERecord?id=CVE-2024-26328 Please adjust the affected versions in the BTS as needed.
Bug#1068818: sngrep: CVE-2024-3119 CVE-2024-3120
Source: sngrep X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for sngrep. CVE-2024-3119[0]: | A buffer overflow vulnerability exists in all versions of sngrep | since v0.4.2, due to improper handling of 'Call-ID' and 'X-Call-ID' | SIP headers. The functions sip_get_callid and sip_get_xcallid in | sip.c use the strncpy function to copy header contents into fixed- | size buffers without checking the data length. This flaw allows | remote attackers to execute arbitrary code or cause a denial of | service (DoS) through specially crafted SIP messages. https://github.com/irontec/sngrep/commit/dd5fec92730562af6f96891291cd4e102b80bfcc (v1.8.1) CVE-2024-3120[1]: | A stack-buffer overflow vulnerability exists in all versions of | sngrep since v1.4.1. The flaw is due to inadequate bounds checking | when copying 'Content-Length' and 'Warning' headers into fixed-size | buffers in the sip_validate_packet and sip_parse_extra_headers | functions within src/sip.c. This vulnerability allows remote | attackers to execute arbitrary code or cause a denial of service | (DoS) via crafted SIP messages. https://github.com/irontec/sngrep/commit/f3f8ed8ef38748e6d61044b39b0dabd7e37c6809 (v1.8.1) If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-3119 https://www.cve.org/CVERecord?id=CVE-2024-3119 [1] https://security-tracker.debian.org/tracker/CVE-2024-3120 https://www.cve.org/CVERecord?id=CVE-2024-3120 Please adjust the affected versions in the BTS as needed.
Bug#1068817: undertow: CVE-2024-1635
Source: undertow X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for undertow. CVE-2024-1635[0]: | A vulnerability was found in Undertow. This vulnerability impacts a | server that supports the wildfly-http-client protocol. Whenever a | malicious user opens and closes a connection with the HTTP port of | the server and then closes the connection immediately, the server | will end with both memory and open file limits exhausted at some | point, depending on the amount of memory available. At HTTP | upgrade to remoting, the WriteTimeoutStreamSinkConduit leaks | connections if RemotingConnection is closed by Remoting | ServerConnectionOpenListener. Because the remoting connection | originates in Undertow as part of the HTTP upgrade, there is an | external layer to the remoting connection. This connection is | unaware of the outermost layer when closing the connection during | the connection opening procedure. Hence, the Undertow | WriteTimeoutStreamSinkConduit is not notified of the closed | connection in this scenario. Because WriteTimeoutStreamSinkConduit | creates a timeout task, the whole dependency tree leaks via that | task, which is added to XNIO WorkerThread. So, the workerThread | points to the Undertow conduit, which contains the connections and | causes the leak. https://bugzilla.redhat.com/show_bug.cgi?id=2264928 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-1635 https://www.cve.org/CVERecord?id=CVE-2024-1635 Please adjust the affected versions in the BTS as needed.
Bug#1068815: undertow: CVE-2023-1973
Source: undertow X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for undertow. CVE-2023-1973[0]: The only reference is at Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=2185662 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-1973 https://www.cve.org/CVERecord?id=CVE-2023-1973 Please adjust the affected versions in the BTS as needed.
Bug#1068816: undertow: CVE-2024-1459
Source: undertow X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for undertow. CVE-2024-1459[0]: | A path traversal vulnerability was found in Undertow. This issue may | allow a remote attacker to append a specially-crafted sequence to an | HTTP request for an application deployed to JBoss EAP, which may | permit access to privileged or restricted files and directories. The only reference here is at Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=2259475 If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-1459 https://www.cve.org/CVERecord?id=CVE-2024-1459 Please adjust the affected versions in the BTS as needed.
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Am Tue, Apr 09, 2024 at 02:02:13PM +1200 schrieb Vladimir Petko: > Hi, > > I have realized that I have not submitted the bug report for this > issue, so the decision to try vendoring dependencies for JTREG is not > visible anywhere. > > Starting from the April OpenJDK release, JTREG 7.3 will be used for > openjdk-11 and up, which will require having it in Buster and up. > > In Ubuntu, the January OpenJDK update used the vendored version, and > we have not found any test regression issues caused by it. > > I have an MR open[1] that does not update the source tree and a > branch[2] with imported sources. Thanks, using a vendored version seems perfectly fine here and makes our life significantly easier for stable/oldstable updates (and jtreg isn't used outside of OpenJDK anyway) Cheers, Moritz
Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)
Hi Paul, 2024年4月11日 20:59，Paul Gevers 写道： Hi, With the default size of the ramdisk and 2 cpu's the test crashes with: Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/setup (run as root) [00:00] [PASS] Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/large_files_001_pos (run as root) [00:00] [PASS] Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/large_files_002_pos (run as root) [00:00] [PASS] Test: /usr/share/zfs/zfs-tests/tests/functional/large_files/cleanup (run as root) [00:00] [PASS] Killed Killed Killed qemu-system-x86_64: terminating on signal 15 from pid 132251 (/usr/bin/python3) autopkgtest [12:28:46]: ERROR: testbed failure: timed out on command "cat /run/autopkgtest-reboot-mark" (kind: short) root@ci-worker13:~# That at least hints that those tests *might* be generating a bit too large files to be handled in this case. Maybe worth making these tests conditional on free space if they aren't already. Thanks for your detailed diagnosis. I adjusted a test option to limit the maximum file size [1]. Also I fixed numerous test errors caused by missing dependencies [2]. Yet I am concerned that some tests might fail, in turn, due to insufficient disk space. If so I will have to ignore some tests on either side. If possible, could you help to build with latest code on salsa then run autopkgtest again on a normal debci VM? I am also testing that locally. [1]: https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/f6bea9224c4bf734ac381bac36a995dfd33b2078 [2]: https://salsa.debian.org/zfsonlinux-team/zfs/-/commit/177d5b2eab39cf8ca0e7bb66d462b4886f2372e4 Thanks, Shengqi Chen
Bug#1068786: ITS: latencytop
On Thu, 2024-04-11 at 10:31 +0200, Giacomo Catenazzi wrote: > Hello, > > You, or other DD or DM can take maintainership of it. Zero objections. Thank you for the quick reply. I am proceeding with the package upload now. Best, Boyuan > On 2024-04-11 2:41, Boyuan Yang wrote: > > Source: latencytop > > Version: 0.5.0-0.1 > > Severity: important > > X-Debbugs-CC: c...@debian.org > > > > Dear package latencytop maintainer in Debian, > > > > After looking into the package you maintain (latencytop, > > https://tracker.debian.org/pkg/latencytop), I found that this package > > received no maintainer updates in the past 14 years and is not in > > good > > shape. As a result, I am filing an ITS (Intent to Salvage) request > > against your package according to section 5.12 in Debian's > > Developers' > > Reference [1]. > > > > My current plan is to refresh packaging and fix all RC bugs. > > > > Please let me know whether you are still willing to maintain this > > package. According to the criteria listed at [2], I will upload a > > Non- > > maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days > > (May 01, 2024) to continue with the package salvaging. If you find it > > necessary to pause the ITS process, please let me know immediately by > > replying this bug report. > > > > > > [1] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > > [2] https://wiki.debian.org/PackageSalvaging > > signature.asc Description: This is a digitally signed message part
Bug#1068814: RFS: sup/20100519-4 [QA] [RC] -- Software Upgrade Protocol implementation
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "sup": * Package name : sup Version : 20100519-4 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : [fill in] * Vcs : [fill in URL of packaging vcs] Section : devel The source builds the following binary packages: sup - Software Upgrade Protocol implementation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sup/sup_20100519-4.dsc Changes since the last upload: sup (20100519-4) unstable; urgency=medium . * QA upload. * set std-ver to 4.7.0. * Add 07_fix-implicit-function-declaration.patch to fix ftbfs issue. (Closes: #1066658) -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1068813: parallel: no way of silencing Parallel with --halt
Package: parallel Version: 20240222+ds-2 Severity: normal X-Debbugs-Cc: none, Francesco Potortì When using parallel --halt soon,done=43 I get two lines of output for each completed job, like this: parallel: This job finished: get_data_from_csv arg1 arg2 arg3 and I find no way to silence them, as my job does its logging by itself. No problem if --halt is not used. -- Francesco Potortì (ricercatore)Mobile: +39.348.8283.107 ISTI - CNR, Pisa, ItalyWeb:http://fly.isti.cnr.it -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (101, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages parallel depends on: ii perl 5.38.2-3 ii procps 2:4.0.4-4 ii sysstat 12.7.5-2 parallel recommends no packages. Versions of packages parallel suggests: pn csh pn fish ii ksh 20240113 ii ksh93u+m [ksh] 1.0.8-1 ii tcsh6.24.10-4 pn zsh -- no debconf information
Bug#960729: More issues trying to create an Ubuntu focal image
On 2024-04-11 15:25, Paride Legovini wrote: > On 2024-04-11 08:35, Christian Kastner wrote: > Ubuntu did indeed switch to something else: that's netplan.io. > On a Bionic system: > > $ apt show netplan.io > Package: netplan.io > Version: 0.99-0ubuntu3~18.04.5 > Priority: important Oh, that explains ifupdown moving to universe, I guess... > So we have another option: teach setup-testbed how to configure > netplan. > This would be a more realistic setup for a modern Ubuntu system, > and won't need any extra dependency outside of what debootstrap > installs automatically. I think "more realistic" is a strong argument for a test environment. And if the package is already installed, adding the configuring step seems the simplest solution. Best, Christian
Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous
On Thu, Apr 11, 2024 at 03:02:05PM +0200, Christoph Berg wrote: > > additionally you could also only classify d/changelog changing commits > > with "Gbp-Dch: ignore" in them as such, but I'd guess Marc's suggestion > > really is good enough. > I don't understand, if debian/changelog-only commits are already > ignored, what should vcswatch do additionally? nothing. I ment it the other way around: if you were *not* willling to ignore debian/changelog-only commits maybe you'd be willing to ignore debian/changelog-only commits which also have "Gbp-Dch: ignore"/ but it seems you'd be fine to just ignore debian/changelog-only commits, so this is mood. > > Please reconsider, IOW, Myon: my I reassign this back to qa.debian.org > > for vcswatch? > Done. thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If secure encryption is outlawed, only criminals will have it. signature.asc Description: PGP signature
Bug#1063599: More info (Was: mathgl: FTBFS on amd64: tests seg fault)
Hello Sebastian and Andreas, On 2024-02-15 09:14, Sebastian Ramacher wrote: > On 2024-02-15 08:30:37 +0100, Andreas Tille wrote: > > the package builds nicely in my local pbuilder, in Salsa CI as well as > > in the autobuilders. Thus I'm tagging the bug moreinfo and set severity > > to important. > > Could mean that either the tests are flaky or some of the changes in -6 > or -7 fixed the issue. Just wanted to mention that I have tried a couple of rebuilds of mathgl 8.0.1-7.1 in sbuild (including the fix mentioned at https://bugs.debian.org/1067367#12) and it failed with either a segfault or the following error: free(): unaligned chunk detected in tcache 2 Aborted
Bug#1068812: pcb-rnd: hardcoded librnd4 dependency
Package: pcb-rnd
Version: 3.1.4-1
Severity: serious
Tags: patch
Hello, I found that librnd4 is correctly evaluated from shlibs:Depends in the
core library and then it can be dropped also on core reverse-dependencies.
Please drop it.
Thanks for considering the patch.
diff -Nru pcb-rnd-3.1.4/debian/control pcb-rnd-3.1.4/debian/control
--- pcb-rnd-3.1.4/debian/control2024-03-14 00:19:26.0 +0100
+++ pcb-rnd-3.1.4/debian/control2024-04-11 15:53:47.0 +0200
@@ -162,7 +162,7 @@
Package: pcb-rnd-export
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, pcb-rnd-core (=
${binary:Version}), librnd4, librnd4-pixmap
+Depends: ${misc:Depends}, ${shlibs:Depends}, pcb-rnd-core (=
${binary:Version}), librnd4-pixmap
Description: Common export plugins.
Export the board in vector graphics (svg, ps, eps), raster graphics
(png, jpeg, etc.), gerber, 3d model in openscad, xy for pick and
@@ -192,7 +192,6 @@
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends},
pcb-rnd-core (= ${binary:Version}),
- librnd4
Replaces: pcb-rnd (<< 2.2.0-2)
Breaks: pcb-rnd (<< 2.2.0-2)
Description: Netlist/schematics import plugins.
@@ -203,7 +202,6 @@
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends},
pcb-rnd-core (= ${binary:Version}),
- librnd4,
pcb-rnd-lib-io (= ${binary:Version}),
pcb-rnd-io-standard (= ${binary:Version})
Description: Autoroute and autoplace.
@@ -238,7 +236,7 @@
Package: pcb-rnd-core
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, librnd4
+Depends: ${misc:Depends}, ${shlibs:Depends}
Replaces: pcb-rnd (<< 2.2.0-2)
Breaks: pcb-rnd (<< 2.2.0-2)
Description: pcb-rnd executable with the core functionality
@@ -252,8 +250,7 @@
Depends: ${misc:Depends}, ${shlibs:Depends},
pcb-rnd-core (= ${binary:Version}),
pcb-rnd-lib-io (= ${binary:Version}),
- pcb-rnd-extra (= ${binary:Version}),
- librnd4
+ pcb-rnd-extra (= ${binary:Version})
Description: File format compatibility with other PCB layout designers.
Load and/or save boards in file formats supported by other EDA tools,
such as KiCAD, Eagle, protel/autotrax, etc.
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1068810: sch-rnd: hardcoded librnd4 dependency
control: severity -1 serious thanks G. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065457: openzwave: diff for NMU version 1.6.1914+ds-1.2
Control: tags 1065457 + patch Control: tags 1065457 + pending Dear maintainer, I've prepared an NMU for openzwave (versioned as 1.6.1914+ds-1.2) and uploaded it to DELAYED/3. Please feel free to tell me if I should delay it longer. Regards. diff -Nru openzwave-1.6.1914+ds/debian/changelog openzwave-1.6.1914+ds/debian/changelog --- openzwave-1.6.1914+ds/debian/changelog 2024-02-29 19:55:23.0 +0100 +++ openzwave-1.6.1914+ds/debian/changelog 2024-04-11 15:37:03.0 +0200 @@ -1,3 +1,15 @@ +openzwave (1.6.1914+ds-1.2) unstable; urgency=medium + + * Non-maintainer upload. (Closes: #1065457) + * Bump dpkg-dev versioned Build-Depends for t64 transition. + * Patch upstream Makefiles to show compiler invocations. + * Patch additional upstream Makefile to remove -Wno-format. + * Build-Depends: add pkgconf, necessary to place .pc file. + * Reduce CPPFLAGS updating, to avoid unknown ‘-Werror=implicit-function-declaration’ +in cc1plus aborting the build. + + -- Chris Hofstaedtler Thu, 11 Apr 2024 15:37:03 +0200 + openzwave (1.6.1914+ds-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru openzwave-1.6.1914+ds/debian/control openzwave-1.6.1914+ds/debian/control --- openzwave-1.6.1914+ds/debian/control 2024-02-29 19:55:23.0 +0100 +++ openzwave-1.6.1914+ds/debian/control 2024-04-11 15:37:03.0 +0200 @@ -7,7 +7,8 @@ , dh-exec (>=0.2) , libudev-dev , libxml2-utils - , dpkg-dev (>= 1.20) + , dpkg-dev (>= 1.22.6) + , pkgconf Standards-Version: 4.6.0 Homepage: http://www.openzwave.net/ Vcs-Browser: https://salsa.debian.org/debian-iot-team/openzwave diff -Nru openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch --- openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch 1970-01-01 01:00:00.0 +0100 +++ openzwave-1.6.1914+ds/debian/patches/makefile-no-silent.patch 2024-04-11 15:37:03.0 +0200 @@ -0,0 +1,146 @@ +Index: openzwave-1.6.1914+ds/cpp/build/support.mk +=== +--- openzwave-1.6.1914+ds.orig/cpp/build/support.mk openzwave-1.6.1914+ds/cpp/build/support.mk +@@ -184,24 +184,24 @@ endif + + $(OBJDIR)/%.o : %.cpp + @echo "Building $(<:$(top_builddir)/cpp/%=%)" +- @$(CXX) -MM $(CFLAGS) $(CPPFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d ++ $(CXX) -MM $(CFLAGS) $(CPPFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d + @mv -f $(DEPDIR)/$*.d $(DEPDIR)/$*.d.tmp + @$(SED) -e 's|.*:|$(OBJDIR)/$*.o: $(DEPDIR)/$*.d|' < $(DEPDIR)/$*.d.tmp > $(DEPDIR)/$*.d; + @$(SED) -e 's/.*://' -e 's/\\$$//' < $(DEPDIR)/$*.d.tmp | $(FMTCMD) | \ + $(SED) -e 's/^ *//' -e 's/$$/:/' >> $(DEPDIR)/.$*.d; + @rm -f $(DEPDIR)/$*.d.tmp +- @$(CXX) $(CFLAGS) $(CPPFLAGS) $(TARCH) $(INCLUDES) -o $@ $< ++ $(CXX) $(CFLAGS) $(CPPFLAGS) $(TARCH) $(INCLUDES) -o $@ $< + + + $(OBJDIR)/%.o : %.c + @echo "Building $(<:$(top_builddir)/cpp/src/%=%)" +- @$(CC) -MM $(CFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d ++ $(CC) -MM $(CFLAGS) $(INCLUDES) $< > $(DEPDIR)/$*.d + @mv -f $(DEPDIR)/$*.d $(DEPDIR)/$*.d.tmp + @$(SED) -e 's|.*:|$(OBJDIR)/$*.o: $(DEPDIR)/$*.d|' < $(DEPDIR)/$*.d.tmp > $(DEPDIR)/$*.d; + @$(SED) -e 's/.*://' -e 's/\\$$//' < $(DEPDIR)/$*.d.tmp | $(FMTCMD) | \ + $(SED) -e 's/^ *//' -e 's/$$/:/' >> $(DEPDIR)/.$*.d; + @rm -f $(DEPDIR)/$*.d.tmp +- @$(CC) $(CFLAGS) $(TARCH) $(INCLUDES) -o $@ $< ++ $(CC) $(CFLAGS) $(TARCH) $(INCLUDES) -o $@ $< + + + dummy := $(shell test -d $(OBJDIR) || mkdir -p $(OBJDIR)) +Index: openzwave-1.6.1914+ds/cpp/build/Makefile +=== +--- openzwave-1.6.1914+ds.orig/cpp/build/Makefile openzwave-1.6.1914+ds/cpp/build/Makefile +@@ -206,7 +206,7 @@ $(LIBDIR)/$(SHARED_LIB_NAME): $(patsubst + $(patsubst %.cpp,$(OBJDIR)/%.o,$(indep)) \ + $(OBJDIR)/vers.o + @echo "Linking Shared Library" +- @$(LD) $(LDFLAGS) $(TARCH) -o $@ $+ $(LIBS) ++ $(LD) $(LDFLAGS) $(TARCH) -o $@ $+ $(LIBS) + @ln -sf $(SHARED_LIB_NAME) $(LIBDIR)/$(SHARED_LIB_UNVERSIONED) + + $(top_builddir)/libopenzwave.pc: $(top_srcdir)/cpp/build/libopenzwave.pc.in $(PKGCONFIG) +@@ -256,35 +256,35 @@ endif + + install: $(LIBDIR)/$(SHARED_LIB_NAME) doc $(top_builddir)/libopenzwave.pc $(top_builddir)/ozw_config + @echo "Installing Shared Library" +- @install -d $(DESTDIR)/$(instlibdir)/ +- @cp $(LIBDIR)/$(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_NAME) +- @ln -sf $(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_UNVERSIONED) ++ install -d $(DESTDIR)/$(instlibdir)/ ++ cp $(LIBDIR)/$(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_NAME) ++ ln -sf $(SHARED_LIB_NAME) $(DESTDIR)/$(instlibdir)/$(SHARED_LIB_UNVERSIONED) + @echo "Installing Headers" +- @install -d $(DESTDIR)/$(includedir) +- @install -m 0644 $(top_srcdir)/cpp/src/*.h $(DESTDIR)/$(includedir) +- @install -d $(DESTDIR)/$(includedir)/command_classes/ +- @install -m 0644 $(top_srcdir)/cpp/src/command_classes/*.h
Bug#1068811: camv-rnd: hardcoded librnd4 dependency
Package: camv-rnd
Version: 1.1.4-1
Severity: serious
Tags: patch
Hello, I found that librnd4 is correctly evaluated from shlibs:Depends in the
core library and then it can be dropped also on core reverse-dependencies.
Please drop it.
Thanks for considering the patch.
diff -Nru camv-rnd-1.1.4/debian/control camv-rnd-1.1.4/debian/control
--- camv-rnd-1.1.4/debian/control 2023-11-30 16:53:21.0 +0100
+++ camv-rnd-1.1.4/debian/control 2024-04-11 15:44:20.0 +0200
@@ -47,7 +47,7 @@
Architecture: any
Replaces: camv-rnd (<< 1.1.0-1)
Breaks: camv-rnd (<< 1.1.0-1)
-Depends: ${misc:Depends}, ${shlibs:Depends}, librnd4, librnd4-lib-gui
+Depends: ${misc:Depends}, ${shlibs:Depends}, librnd4-lib-gui
Description: camv-rnd executable with the core functionality and boxsym-rnd
Includes the data model, the most common action commands, the native
file format. Can be used in headless mode or batch/scripted mode for
@@ -56,7 +56,7 @@
Package: camv-rnd-export-vector
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, camv-rnd-core (=
${binary:Version}), librnd4
+Depends: ${misc:Depends}, ${shlibs:Depends}, camv-rnd-core (=
${binary:Version})
Description: Export formats: vector graphics
Common vector graphic export formats: ps, eps, svg.
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1068810: sch-rnd: hardcoded librnd4 dependency
Package: sch-rnd
Version: 1.0.5-1
Severity: normal
Tags: patch
Hello, I found that librnd4 is correctly evaluated from shlibs:Depends in the
core library and then it can be dropped also on core reverse-dependencies.
Please drop it.
Thanks for considering the patch.
diff -Nru sch-rnd-1.0.5/debian/control sch-rnd-1.0.5/debian/control
--- sch-rnd-1.0.5/debian/control2024-04-11 06:59:15.0 +0200
+++ sch-rnd-1.0.5/debian/control2024-04-11 15:46:41.0 +0200
@@ -88,7 +88,7 @@
Package: sch-rnd-core
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, librnd4 (>= 4.1.0)
+Depends: ${misc:Depends}, ${shlibs:Depends}
Description: sch-rnd executable with the core functionality and boxsym-rnd
Includes the data model, the most common action commands, the native
file format. Can be used in headless mode or batch/scripted mode for
@@ -97,7 +97,7 @@
Package: sch-rnd-export-vector
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, sch-rnd-core (= ${binary:Version}),
librnd4 (>= 4.1.0)
+Depends: ${misc:Depends}, ${shlibs:Depends}, sch-rnd-core (= ${binary:Version})
Description: Export formats: vector graphics
Common vector graphic export formats: ps, eps, svg.
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1068809: dh-buildinfo: consider deprecating and removing the package
Package: dh-buildinfo Version: 0.11+nmu3 X-Debbugs-Cc: hol...@debian.org Hi, dh-buildinfo much predates the reproducible builds effort and the .buildinfo file and probably laid ground to it. I am now raising the question whether it is time to get rid of dh-buildinfo in Debian. Essentially I am arguing that the use case of dh-buildinfo is now served by dpkg-genbuildinfo and the generated .buildinfo files on every package build. Besides the difference in formatting, the main difference is that dh-buildinfo embeds this information into the binary package rather than next to it (where it can be lost). I argue that all of the uses of dh-buildinfo can now be met with examining .buildinfo files. At the same time, dh-genbuildinfo reduces reproducibility. When cross building a package, we necessarily install different packages from a native build. This difference manifests in the embedded buildinfo files and thus comparing a natively built package with a cross built package needs to ignore the embedded buildinfo file where we would like cross builds to exactly reproduce native builds where possible. As such I am proposing to call dh-buildinfo deprecated, then to actively remove dependencies on it and finally remove it from Debian. If you agree with this vision, please tag this bug confirmed. If you disagree with this vision, please tag it wontfix and explain the added value that I fail to see. Thank you Helmut
Bug#1068808: openmpi-bin has an undeclared file conflict on /usr/bin/pterm
Package: openmpi-bin Version: 5.0.3-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + pterm openmpi-bin has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/bin/pterm is contained in the packages * openmpi-bin/5.0.3-1 as present in experimental * pterm * 0.74-1+deb11u1 as present in bullseye|bullseye-security * 0.78-2+deb12u1 as present in bookworm|bookworm-security * 0.80-1 as present in trixie * 0.80-1+b1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected file. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#960729: More issues trying to create an Ubuntu focal image
On 2024-04-11 08:35, Christian Kastner wrote: > Control: tags -1 - pending > > On 2024-04-08 15:21, Paride Legovini wrote: >> Fixed in master by: >> >> https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/315 > > Sadly, it turns out that this wasn't the fix, at least not in a wider sense. > > Yes, images can be built now, but without ifupdown their network > interface is left unconfigured, and thus autopkgtests can't download > packages. > > With the move of ifupdown to universe, I was assuming that Ubuntu did > things differently. The cloud images *do* things differently, namely > they have systemd-networkd. But autopkgtest allows for alternative init > systems, so we can't rely on that. Ubuntu did indeed switch to something else: that's netplan.io. On a Bionic system: $ apt show netplan.io Package: netplan.io Version: 0.99-0ubuntu3~18.04.5 Priority: important and by running e.g. sudo tools/autopkgtest-build-qemu --mirror=http://archive.ubuntu.com/ubuntu/ jammy jammy-qemu.img I see it being installed, but left unconfigured. Now, when we have ifupdown, what is configuring it? It's setup-testbed: printf 'auto %s\niface %s inet dhcp\n' "$IFACE" "$IFACE" >> "$root/etc/network/interfaces.d/$IFACE" So we have another option: teach setup-testbed how to configure netplan. This basically consists in dropping a yaml under /etc/netplan containing something like: network: version: 2 renderer: networkd ethernets: eth0: dhcp4: yes This would be a more realistic setup for a modern Ubuntu system, and won't need any extra dependency outside of what debootstrap installs automatically. Or we could enable universe during debootstrap, install ifupdown and hope that it will keep playing fine with netplan, as you suggested. Maybe we should just take this simpler route, I am still unsure, input is welcome. Paride
Bug#1068049: Fixed in last week's upload
Control: fixed -1 4.3.0-1 closing as fixed in last upload. OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1067367: mathgl: FTBFS: debian/tests/run-tests: 37: python3.12: not found
Control: tags -1 + patch Hi, On 2024-03-20 09:46, Lucas Nussbaum wrote: > > debian/tests/run-tests: 37: python3.12: not found This is because debian/tests/run-tests iterates over all supported python versions (py3versions -s), but only python3.11 is installed. Please consider build-depending on python3-all (see attached patch) to ensure all supported python runtimes are installed. diff -Nru mathgl-8.0.1/debian/changelog mathgl-8.0.1/debian/changelog --- mathgl-8.0.1/debian/changelog 2024-02-15 07:53:06.0 +0100 +++ mathgl-8.0.1/debian/changelog 2024-04-11 15:00:39.0 +0200 @@ -1,3 +1,10 @@ +mathgl (8.0.1-8) unstable; urgency=medium + + * Build-depend on python3-all to ensure all supported python versions are +installed when running debian/tests/run-tests. (Closes: #1067367) + + -- Emanuele Rocca Thu, 11 Apr 2024 15:00:39 +0200 + mathgl (8.0.1-7) unstable; urgency=medium * Team upload. diff -Nru mathgl-8.0.1/debian/control mathgl-8.0.1/debian/control --- mathgl-8.0.1/debian/control 2024-02-15 07:53:06.0 +0100 +++ mathgl-8.0.1/debian/control 2024-04-11 15:00:13.0 +0200 @@ -38,6 +38,7 @@ mpi-default-dev, python3-dev, python3-numpy, + python3-all , qtwebengine5-dev [amd64 arm64 armhf i386], swig, texinfo,
