Bug#1010549: itksnap: FTBFS because b-d on libvtk6-dev
Source: itksnap Version: 3.6.0-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: jo...@debian.org Hi, currently itksnap FTBFS because it B-D on libvtk6-dev which depends on libjsoncpp24: https://qa.debian.org/dose/debcheck/src_unstable_main/latest/packages/itksnap.html Thanks! cheers, josch
Bug#980406: Improving node-node-pty towards node-xterm version 4
Hi, I wanted to push node-xterm towards version 4, but I saw bug report #980406 about needing node-node-pty, so I tried my hand on the salsa repository for this would-be package. I managed to fix a few things, but I'm stuck on the last hurdle and upstream is proving pretty uncooperative: https://github.com/microsoft/node-pty/issues/539 Question: isn't src/windowsPtyAgent.ts just for the windows port of the lib, in which case it can somehow be dropped? If anybody has any answer or hint, don't hesitate... J.Puydt
Bug#996961: bpfcc-tools: biosnoop fails to print the SIZE field correctly on bullseye
Control: fixed -1 0.24.0+ds-1 Hi Rich, Sorry for the delayed response. This is no longer an issue in latest version of bpfcc-tools. Hence closing the bug. Thanks and Regards, Vasudev
Bug#987295: profile-bpf: 3 warnings generated
Control: fixed -1 0.24.0+ds-1 Hi Jacobo, Sorry for delayed response. I checked with latest version of bpfcc-tools and this is no longer an issue. So closing this bug. Thanks and Regards, Vasudev
Bug#986590: Patch #76, still fails
Unfortunately the patch in #76 still fails. Needs some more investigation: == FAIL: test-libdbustest-mock-test ** (gtester:7666): WARNING **: 21:18:27.890: Deprecated: Since GLib 2.62, gtester and gtester-report are deprecated. Port to TAP. TEST: ./test-libdbustest-mock... (pid=7667) /libdbustest/mock/basic: (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7667): libdbustest-WARNING **: 21:18:27.910: Unable to start watchdog DBus daemon: unix:abstract=/tmp/dbus-QtSQwrxNGw,guid=5439845aad7f1bb8e63d4297626c5623 DBusMock: Started with PID: 7687 DBusMock: Shutting down DBus daemon: Shutdown ** ERROR:test-libdbustest-mock.c:45:wait_for_connection_close: assertion failed: (wait_count != SESSION_MAX_WAIT) FAIL GTester: last random seed: R02S0c733c834df4b87e3a0bb6bff1c44e77 (pid=7728) /libdbustest/mock/properties: (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-CRITICAL **: 21:21:48.365: dbus_test_dbus_mock_object_add_property: assertion 'g_variant_is_of_type(value, type)' failed (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-WARNING **: 21:21:48.367: Unable to start watchdog DBus daemon: unix:abstract=/tmp/dbus-FB8W7MsRSE,guid=4425b2c97b1ed05ae561ebd2626c56ec DBusMock: Started with PID: 7747 (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-CRITICAL **: 21:21:48.462: Property 'prop1' is not of same value in dbus_test_dbus_mock_object_update_property() DBusMock: Shutting down DBus daemon: Shutdown OK /libdbustest/mock/methods: (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-WARNING **: 21:21:48.472: Unable to start watchdog DBus daemon: unix:abstract=/tmp/dbus-7xF4SrW7pk,guid=9514c44ce88f66e83ee408cc626c56ec DBusMock-1: Started with PID: 7755 DBusMock-1: Shutting down DBus daemon: Shutdown OK /libdbustest/mock/signals: (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-WARNING **: 21:21:48.771: Unable to start watchdog DBus daemon: unix:abstract=/tmp/dbus-4AGx7A42El,guid=46c8120e5b0e1fa2f9082734626c56ec DBusMock-2: Started with PID: 7763 DBusMock-2: 1651267308.866 emit /test foo.test.interface.testsig DBusMock-2: 1651267308.968 emit /test foo.test.interface.testsig_abc "a" "b" "c" DBusMock-2: Shutting down DBus daemon: Shutdown OK /libdbustest/mock/running: (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-WARNING **: 21:21:49.076: Unable to start watchdog DBus daemon: unix:abstract=/tmp/dbus-MJiLNJREgr,guid=71b2068fe312fd7ba7dd5e06626c56ed DBusMock-3: Started with PID: 7771 DBusMock-3: Shutting down DBus daemon: Shutdown OK /libdbustest/mock/running-system: (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-WARNING **: 21:21:49.371: Unable to start watchdog DBus daemon: unix:abstract=/tmp/dbus-KMNGhYfACr,guid=a04514c03ab8369dfed6f3f9626c56ed DBusMock-4: Started with PID: 7779 DBusMock-4: Shutting down DBus daemon: Shutdown OK /libdbustest/mock/interfaces: (/builds/debian/dbus-test-runner/debian/output/source_dir/tests/.libs/test-libdbustest-mock:7728): libdbustest-WARNING **: 21:21:49.668: Unable to start watchdog DBus daemon: unix:abstract=/tmp/dbus-yeC3JJFI37,guid=e1b247ec47e3e0d499b9f17c626c56ed DBusMock-5: Started with PID: 7787 DBusMock-5: Shutting down DBus daemon: Shutdown OK FAIL: ./test-libdbustest-mock FAIL test-libdbustest-mock-test (exit status: 1) == Anton
Bug#1010475: wiki.debian.org: wrong link to libreoffice-kf5
On Wed, 2022-05-04 at 03:05 +, Felipe Maia wrote: > If I had included the Severity header with a level different than > what was established before, would it have been changed by the > Control? In other words, can I change Severity and Close the bug all > at once, with only one email? Not sure, but I think yes, but only with the Control header: To: 1010475-d...@bugs.debian.org Control: severity -1 minor AFAIK, the Severity header is only used when filing new bugs. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1010475: wiki.debian.org: wrong link to libreoffice-kf5
On Wed, 2022-05-04 at 02:26 +, Felipe Maia wrote: > Do you mind writing the entire pseudo-header? I think it would be > better to understand exactly what you're recommending. I'll then > compare to the pseudo-header I wrote. Package: wiki.debian.org Version: https://wiki.debian.org/Wayland?action=diff=44=43 A summary of the changes from your version: The Severity header isn't needed, since it doesn't change the severity and you already changed it via a Control header. The Comment header isn't needed, for the reason I mentioned earlier. The Version header I changed to just the diff link. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1010148: openmsx: FTBFS on riscv64
On 4 May 2022, at 00:51, olivier-gondo...@laposte.net wrote:
>
>
> Hi,
>
> Sorry if I don't answer the good way, I'm new in patch contribution of Debian.
>
> Here is a patch for OpenMSX 17.0 on RISCV64, not specific to Debian. in the
> hope it can help you.
>
> Regards.
>
> commit 3846683656aef48a4faa26e8213163fb21cecd34
> Author: Olivier Gondouin
> Date: Tue May 3 23:36:47 2022 +
>
> patch riscv64
>
> diff --git a/build/detectsys.py b/build/detectsys.py
> index 060e4a8..27ee135 100644
> --- a/build/detectsys.py
> +++ b/build/detectsys.py
> @@ -35,6 +35,8 @@ def detectCPU():
> return 'aarch64'
> elif cpu == 'aarch64_be':
> return 'aarch64_be'
> + elif cpu == 'riscv64':
> + return 'riscv64'
> elif cpu.startswith('mips') or cpu == 'sgi':
> return 'mipsel' if cpu.endswith('el') else 'mips'
> elif cpu == 'm68k':
> diff --git a/build/flavour-riscv64.mk b/build/flavour-riscv64.mk
> new file mode 100644
> index 000..ec4c293
> --- /dev/null
> +++ b/build/flavour-riscv64.mk
> @@ -0,0 +1,7 @@
> +# Configuration for "riscv64" flavour:
> +
> +# Start with generic optimisation flags.
> +include build/flavour-opt.mk
> +
> +# Add riscv64 specific flags.
> +CXXFLAGS+=-march=rv64g
The Debian baseline is rv64gc and is the default, so I don’t understand
why this is here?
Jess
> diff --git a/build/main.mk b/build/main.mk
> index 2e93733..48cdfb7 100644
> --- a/build/main.mk
> +++ b/build/main.mk
> @@ -159,10 +159,14 @@ else
> ifeq ($(OPENMSX_TARGET_CPU),m68k)
> OPENMSX_FLAVOUR?=m68k
> else
> +ifeq ($(OPENMSX_TARGET_CPU),riscv64)
> +OPENMSX_FLAVOUR?=riscv64
> +else
> OPENMSX_FLAVOUR?=opt
> endif
> endif
> endif
> +endif
>
> # Load OS specific settings.
> $(call DEFCHECK,OPENMSX_TARGET_OS)
Bug#1010548: lists.debian.org: Some web archive links broken?
Package: lists.debian.org Severity: important X-Debbugs-CC: listmas...@lists.debian.org Dear Debian Listmasters, I am not sure why, but some mailing list web page archive looks heavily broken. Steps to reproduce: 1. Visit https://lists.debian.org/package-sponsorship-requests/ . 2. Click May 2022 archive page. 3. Click "Previous Month" button. 4. The server returns 404. Please look into this issue. Thanks! Best Regards, Boyuan signature.asc Description: This is a digitally signed message part
Bug#965799: rasqal: diff for NMU version 0.9.33-0.3
Control: tags 965799 + patch
Control: tags 965799 + pending
Dear maintainer,
I've prepared an NMU for rasqal (versioned as 0.9.33-0.3) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru rasqal-0.9.33/debian/changelog rasqal-0.9.33/debian/changelog
--- rasqal-0.9.33/debian/changelog 2021-09-18 13:40:08.0 -0400
+++ rasqal-0.9.33/debian/changelog 2022-05-03 21:34:08.0 -0400
@@ -1,7 +1,27 @@
+rasqal (0.9.33-0.3) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * debian/: Bump debhelper compat to v13. (Closes: #965799)
+ * debian/control:
++ Bump Standards-Version to 4.6.0.
++ Add Vcs-* fields.
++ Migrate from manual -dbg package to automatic -dbgsym package.
+ * debian/changelog: Drop trailing spaces.
+ * debian/control: Drop trailing spaces.
+ * debian/rules:
++ Convert to dh sequencer.
++ Build documentation from source code instead of using pre-built
+ doc/html.
++ Enable full hardening.
+ * debian/copyright: Use secure URI.
+ * debian/watch: Update to v4 format.
+
+ -- Boyuan Yang Tue, 03 May 2022 21:34:08 -0400
+
rasqal (0.9.33-0.2) unstable; urgency=high
* Non-maintainer upload.
- * Add missing build-dependency gtk-doc-tools. (Closes: #978895)
+ * Add missing build-dependency gtk-doc-tools. (Closes: #978895)
-- Boyuan Yang Sat, 18 Sep 2021 13:40:08 -0400
diff -Nru rasqal-0.9.33/debian/compat rasqal-0.9.33/debian/compat
--- rasqal-0.9.33/debian/compat 2021-09-18 13:38:35.0 -0400
+++ rasqal-0.9.33/debian/compat 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-5
diff -Nru rasqal-0.9.33/debian/control rasqal-0.9.33/debian/control
--- rasqal-0.9.33/debian/control2021-09-18 13:40:05.0 -0400
+++ rasqal-0.9.33/debian/control2022-05-03 21:34:08.0 -0400
@@ -2,9 +2,11 @@
Section: devel
Priority: optional
Maintainer: Dave Beckett
-Build-Depends: debhelper (>> 8.1.3), cdbs (>= 0.4.93~), dh-autoreconf, pkg-
config, libraptor2-dev (>=2.0.12-2), libgmp-dev, libmhash-dev, libpcre3-dev,
uuid-dev, gtk-doc-tools
-Standards-Version: 3.9.5
+Build-Depends: debhelper-compat (= 13), pkg-config, libraptor2-dev (>=2.0.12-
2), libgmp-dev, libmhash-dev, libpcre3-dev, uuid-dev, gtk-doc-tools
+Standards-Version: 4.6.0
Homepage: http://librdf.org/rasqal/
+Vcs-Git: https://salsa.debian.org/debian/rasqal.git
+Vcs-Browser: https://salsa.debian.org/debian/rasqal
Package: librasqal3-dev
Provides: librasqal-dev
@@ -30,7 +32,7 @@
Rasqal is a C library providing support for querying the
Resource Description Framework (RDF) including
parsing query syntaxes, constructing the queries, executing them,
- returning result bindings and formatting results. It supports the
+ returning result bindings and formatting results. It supports the
SPARQL RDF Query Language, RDF Data Query Language (RDQL) and LAQRS
experimental query language extending SPARQL.
.
@@ -43,19 +45,10 @@
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: raptor2-utils, redland-utils
Description: Rasqal RDF Query utilities
- This package provides the roqet tool for querying RDF content
+ This package provides the roqet tool for querying RDF content
with SPARQL and RDQL RDF query languages using the Rasqal RDF
query library.
-Package: librasqal3-dbg
-Priority: extra
-Section: debug
-Architecture: any
-Depends: ${misc:Depends}, librasqal3 (= ${binary:Version})
-Description: Rasqal RDF Query Library - debugging symbols
- This package contains the debugging symbols for debugging
- applications which use librasqal3.
-
Package: librasqal3-doc
Section: doc
Architecture: all
@@ -64,7 +57,7 @@
Rasqal is a C library providing support for querying the
Resource Description Framework (RDF) including
parsing query syntaxes, constructing the queries, executing them,
- returning result bindings and formatting results. It supports the
+ returning result bindings and formatting results. It supports the
SPARQL RDF Query Language, RDF Data Query Language (RDQL) and LAQRS
experimental query language extending SPARQL.
.
diff -Nru rasqal-0.9.33/debian/copyright rasqal-0.9.33/debian/copyright
--- rasqal-0.9.33/debian/copyright 2021-09-18 13:38:35.0 -0400
+++ rasqal-0.9.33/debian/copyright 2022-05-03 21:33:08.0 -0400
@@ -1,7 +1,7 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Rasqal RDF Query Library
Upstream-Contact: Dave Beckett
-Source: http://download.librdf.org/source/
+Source: https://download.librdf.org/source/
Files: *
Copyright: 2000-2014 David Beckett
diff -Nru rasqal-0.9.33/debian/librasqal3-dev.docs rasqal-
0.9.33/debian/librasqal3-dev.docs
--- rasqal-0.9.33/debian/librasqal3-dev.docs1969-12-31 19:00:00.0
-0500
+++ rasqal-0.9.33/debian/librasqal3-dev.docs2022-05-03 21:20:25.0
-0400
Bug#1002079: yubiserver: update ftbfs issue on yubiserver
Source: yubiserver
Version: 0.6-3.1
Tags: ftbfs patch
Followup-For: Bug #1002079
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Control: tags -1 ftbfs patch
Dear Maintainer,
I noticed Ileana who has submited the patch for the issue.
And I will attach the patch to fix the issue also, or:
Updtae the config scripts:
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
Add support riscv arch
--- a/build-aux/config.guess
+++ b/build-aux/config.guess
@@ -1001,6 +1001,9 @@
ppcle:Linux:*:*)
echo powerpcle-unknown-linux-${LIBC}
exit ;;
+riscv32:Linux:*:* | riscv32be:Linux:*:* | riscv64:Linux:*:* |
riscv64be:Linux:*:*)
+echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
+exit ;;
s390:Linux:*:* | s390x:Linux:*:*)
echo ${UNAME_MACHINE}-ibm-linux-${LIBC}
exit ;;
Bug#907178: gimp-plugin-registry: resynthesizer not appearing in menu Filters/Enhance
Hello, I confirm that the resynthesizer plugin is currently broken. It is not available once installed. I'm currently on Debian Testing : gimp-plugin-registry 9.20200927+b1 gimp 2.10.30-1+b1 gimp-python is no longer available. Is there a workaround?
Bug#740893: libjs-jquery-hotkeys: Incompatible ABI changes in library
Control: affects -1 - python-coverage On 25-May-2017, Ben Finney wrote: > Until the ‘libjs-jquery-hotkeys’ package resolves bug#740893, the > ‘python-coverage’ packages should not use that library. > > I will patch the ‘python-coverage’ source so it omits any use of > that library. This was done in Debian release “4.3.4+dfsg.1-1” of ‘python-coverage’. As of version 6.2, the Coverage.py code makes no use of that library. Debian includes this change as of release “6.2+dfsg1-1”. Now that every version of ‘python-coverage’ in Debian since “buster” has removed this library as a dependency, I am altering this bug report to record that it no longer affects ‘python-coverage’. -- \ “Faith, n. Belief without evidence in what is told by one who | `\ speaks without knowledge, of things without parallel.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney signature.asc Description: PGP signature
Bug#740893: libjs-jquery-hotkeys: Incompatible ABI changes in library
Control: retitle -1 libjs-jquery-hotkeys: Incompatible ABI changes in library Control: tags -1 + upstream Control: summary -1 0 Some users of this library expect the ABI from ‘jeresig’ source, while the currently packaged library is from the ‘tzuryby’ source with an incompatible ABI. On 09-Apr-2017, Ben Finney wrote: > On 06-Apr-2017, Philipp Hahn wrote: > > > So "coverage_html.js" uses the 'jeresig' API to pass the hotkey > > via "data", while the 'tzuryby' API "jquery.hotkeys.js" expects is > > via 'namespace'. > > That's good investigation, thank you for that. > > > So all of them use the "jeresig" API, but 'libjs-jquery-hotkeys' > > packages the "tzuryby" API. > > We get differing results, so I'd like to better understand before > choosing how to resolve this. I am altering this bug report to describe the root problem to be addressed. -- \ “I used to think that the brain was the most wonderful organ in | `\ my body. Then I realized who was telling me this.” —Emo Philips | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
Hello, On Tue 03 May 2022 at 12:13PM -04, Joey Hess wrote: > Fixed with attached patch. Cool, thanks. Seems like there might be a release soon so I'll hold off patching Debian's version? -- Sean Whitton signature.asc Description: PGP signature
Bug#1010475: wiki.debian.org: wrong link to libreoffice-kf5
On Tue, 2022-05-03 at 22:19 +, Felipe Maia wrote: > Time to close the bug. Please verify if the following pseudo-header > is correct: ... > > Comment: Fixes "Bug#1010475: wiki.debian.org: wrong link to > > libreoffice-kf5". Typo "libreoiffice-kf5" corrected to > > "libreoffice-kf5". Yes, except you don't need to include the edit Comment really, since the edit itself preserves the comment and the Version refers to the edit via the number and link. > I'm not sure if the information I included as "Version" should have > been included as "Comment" instead. I think that the Version you used is fine, although I would have just used the link for the Version myself. > Just realized the mistake I made changing the category of the Wiki > page. Paul reverted the change. Thanks Paul! I thought the category > was related to the editing I did, not to the page itself. Yeah, categories are for the page itself, not the edit. I'm not sure if our guide for editors covers that, but you might like to read it and expand it with this tip if it doesn't. https://wiki.debian.org/DebianWiki/EditorGuide -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
Hi Jan and Tobias, @Jan good to hear from you. @Tobias, thanks for useful suggestions, see my reactions below. On Tue, May 03 2022, Jan Dittberner wrote: > As you might have guessed I'm busier than I would like and do usually need a > bit of time to respond. > > It would have been a good idea to contact me directly or via a wishlist bug > requesting a package update. I would have answered a wishlist bug > requesting an usbrelay upstream version update. The RFS came a bit > surprisingly. A short mail before starting the work would have been nice. I > had contact with Darryl Bond in the past and responded to his > requests. I apologize for not contacting you. I'm also in contact with Darryl Bond and I understood that he tried to contact you recently, but without success. It might have been my misunderstanding. > I would be happy to have a co-maintainer for usbrelay. @Michal you may add > yourself to Uploaders if you are interested in taking care of the package in > the future. Yes, I'll add myself. I'm using this software quite extensively and will be happy to help with packaging. @Jan How shall I proceed now? I've implemented the changes suggested by Tobias, but I need to test the result again with the hardware, for which I'll need a day or two. What then? Shall I upload a new version to mentors.d.o or send salsa merge request or both? > Please run lintian with the flags -i -v -E --pedantic to get the maximum > output. I recommend using pbuilder or sbuild to build in a clean > environment. I usually use sbuild in combination with git-buildpackage to do > my package builds. Both sbuild and pbuilder can lintian automatically after > a finished package build. Thanks. On Tue, May 03 2022, Tobias Frost wrote: > Ok, let me check the package: (I'm using the mentors version for the review) > - As said earlier, depending if you want a Team upload or follow the ITS, this > needs some entry in d/changelog, depending how you want to proceed... > - debian/io.github.darrylb123.usbrelay.metainfo.xml should possible brought > upstream, > shouldn't it (no need to change for the upload, but I guess this is > not debian specific) I'll send that (as well as other parts) upstream. I first wanted to know what changes are required for Debian and then send the final version upstream. > - d/rules >- (bikeshed -- no need to change) I'd prefer to use d/clean instead of > overriding the clean target; overrides are harder to maintain :) I didn't notice this possibility - it's definitely nicer! > - the man page is still in the debian directory -- it can be deleted as > it is now part of upstream. Upstream has usbrelay.1, I've added usbrelayd.8. As mentioned above, I'll send it upstream later. > - same for the udev rules. Upstream rules are slightly different - looser permissions, different group. > - d/usbrelay.install has a hard-coded architecture-dependent path. That will > break build on > archs != amd64. Good catch. > - d/postinst (and postrm): > The username is not correct. According to Debian Policy, 4.9.1, it must > start with an "_" > I guess also that you don't want/need a homedirectory for that uses, so its > $HOME > should be /nonexistent in this case. (Policy 9.2.3) > HOWEVER, let me suggest something else: > Use the DynamicUser feature from systemd: > > DynamicUser=yes > SupplementaryGroups=plugdev > > in the service file should make postint/postrm no longer be needed. That's definitely a good thing. > - Lintian has a few remarks: (my related remarks in brackets) > W: usbrelay source: no-nmu-in-changelog > W: usbrelay source: source-nmu-has-incorrect-version-number 1.0-1 > (will be gone once the changelog mentions the team upload or after the > salvage procedure is done) > I: usbrelay source: debian-rules-parses-dpkg-parsechangelog (line 20) > (see abovr) > I: usbrelay source: older-debian-watch-file-standard 3 > (could be updated to version 4, just s/3/4/ in the header) done > I: usbrelayd: package-supports-alternative-init-but-no-init.d-script > lib/systemd/system/usbrelayd.service > (can be ignored) > I: usbrelay source: patch-not-forwarded-upstream > debian/patches/0002-Mention-README-in-the-man-page.patch > I: usbrelay source: patch-not-forwarded-upstream debian/patches/gcc9.patch > (see below) > I: usbrelayd: systemd-service-file-missing-documentation-key > [lib/systemd/system/usbrelayd.service] > (possibly ask upstream to ammend the service file accordingly) Added, will send upstream later. > X: usbrelay source: debian-watch-does-not-check-gpg-signature [debian/watch] > (it would be nice if upstream could pgp-sign their tarballs, so noone can > tamper with them. > They sign their commits already, so a key would be available. Not > required for this upload.) I think that tarballs are created automatically by GitHub upon tagging the release. I guess that for that, we would need to generate tarballs locally, sign them and upload
Bug#999850: ITP: maturin -- Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages.
Hi Agathe, On Tue, May 03, 2022 at 09:25:30AM +0200, Agathe Porte wrote: > Were you able to progress on this package? If so, could you share your work > on Salsa or elsewere? I depend on this package for another ITP of mine that > I would like to complete before the freeze. The current packaging can be found at https://salsa.debian.org/jelmer/maturin I'm currently waiting for some of the rust dependencies and their dependencies to make it into the archive: * pyo3 (waiting for pyo3-ffi) * pyo3-ffi (in NEW) * fat-macho (needs updating of goblin) * llvm-bitcode (waiting for num-enum) * num-enum (in NEW) * num-enum-derive (in NEW) Cheers, Jelmer
Bug#1010547: libgtk-4-1: Applications hang with "gtk_widget_measure: assertion 'for_size >= -1' failed"
Package: libgtk-4-1 Version: 4.6.2-2ak Severity: normal Tags: patch Dear Maintainer, A patch for: https://gitlab.gnome.org/GNOME/gtk/-/issues/4517 was recently merged to the upstream Gtk 4.6 branch: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4670/ Among potentially numerous other applications, this affected xdg-desktop-portal-gnome for me, because the window chooser dialog for screen sharing incurred a hang with the message in the subject line repeated ad infinitum. By building my own gtk package (see the "2ak" versions below), I was able to confirm that the patch in the MR addresses the issue. I think it would be useful to release a patched version of Gtk4. Thanks for your service maintaining Gtk4 for Debian! Andreas -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgtk-4-1 depends on: ii adwaita-icon-theme42.0-2 ii hicolor-icon-theme0.17-2 ii libc6 2.33-7 ii libcairo-gobject2 1.16.0-5 ii libcairo-script-interpreter2 1.16.0-5 ii libcairo2 1.16.0-5 ii libcloudproviders00.3.1-2 ii libcolord21.4.6-1 ii libcups2 2.4.1op1-2 ii libepoxy0 1.5.10-1 ii libfontconfig12.13.1-4.4 ii libfribidi0 1.0.8-2.1 ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 ii libglib2.0-0 2.72.1-1 ii libgraphene-1.0-0 1.10.8-1 hi libgtk-4-common 4.6.2-2ak ii libharfbuzz0b 2.7.4-1+b1 ii libjpeg62-turbo 1:2.1.2-1 ii libpango-1.0-01.50.6+ds-2 ii libpangocairo-1.0-0 1.50.6+ds-2 ii libpangoft2-1.0-0 1.50.6+ds-2 ii libpng16-16 1.6.37-5 ii libtiff5 4.3.0-7 ii libwayland-client01.20.0-1 ii libwayland-egl1 1.20.0-1 ii libx11-6 2:1.7.5-1 ii libxcursor1 1:1.2.1-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.4-1 ii libxfixes31:6.0.0-1 ii libxi62:1.8-1 ii libxinerama1 2:1.1.4-3 ii libxkbcommon0 1.4.0-1 ii libxrandr22:1.5.2-2+b1 ii shared-mime-info 2.1-2 Versions of packages libgtk-4-1 recommends: ii iso-codes4.9.0-1 hi libgtk-4-bin 4.6.2-2ak ii librsvg2-common 2.52.5+dfsg-3+b1 Versions of packages libgtk-4-1 suggests: ii gvfs 1.50.0-1 hi libgtk-4-media-gstreamer 4.6.2-2ak -- no debconf information
Bug#1010546: tldr-py: tdlr update fails ("master" should be "main")
Package: tldr-py
Version: 0.7.0-4
Severity: important
Dear Maintainer,
Running "tldr update" fails with the following:
$ tldr update
Check for updates...
fatal: ambiguous argument 'master': unknown revision or path not in the working
tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
Traceback (most recent call last):
File "/usr/bin/tldr", line 33, in
sys.exit(load_entry_point('tldr.py==0.7.0', 'console_scripts', 'tldr')())
File "/usr/lib/python3/dist-packages/click/core.py", line 1128, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 1053, in main
rv = self.invoke(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1659, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3/dist-packages/click/core.py", line 1395, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3/dist-packages/click/core.py", line 754, in invoke
return __callback(*args, **kwargs)
File "/usr/lib/python3/dist-packages/tldr/cli.py", line 114, in update
local = subprocess.check_output('git rev-parse master'.split()).strip()
File "/usr/lib/python3.10/subprocess.py", line 420, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.10/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['git', 'rev-parse', 'master']'
returned non-zero exit status 128.
I guess a branch was renamed from "master" to "main".
This may be related: https://github.com/lord63/tldr.py/issues/49
Best,
--
Antoine Amarilli
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tldr-py depends on:
ii python33.10.4-1+b1
ii python3-click 8.0.3-1
ii python3-pkg-resources 59.6.0-1.2
ii python3-yaml 5.4.1-1+b1
Versions of packages tldr-py recommends:
ii git 1:2.35.1-1
tldr-py suggests no packages.
-- debconf-show failed
Bug#1010402: debmake-doc: Quilt configuration leads to shell error
Hi, > -Original Message- > From: Philippe SWARTVAGHER > Reply-To: Philippe SWARTVAGHER , 1010...@bugs.debian.org > > The problem appears here: > https://www.debian.org/doc/manuals/debmake-doc/ch03.en.html#quilt-setup > (debmake-doc, not maint-guide ;) ) and the patch I provided applies to > I got it. This was bug introduced while creating debmake-doc. (debmake being python code, I got carried out.) I have kept my system using long line version. Since keeping script within reasonable length is good for readability, let me fix it by using proper shell string concatenation. Thanks Osamu
Bug#1010545: biosig: FTBFS with dcmtk >= 3.6.7
Source: biosig Version: 2.3.3-1 Severity: serious Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: jo...@debian.org Hi, biosig FTBFS with dcmtk 3.6.7 from unstable: cc -c -D=__4HAERTEL__ -D=WITH_FAMOS -D=WITH_FIFF -D=WITHOUT_NETWORK -D=WITH_SCP3 -D=WITH_FEF -D=WITH_INTAN -D=WITH_ATF - D=MAKE_EDFLIB -D=WITH_DCMTK -D=WITH_LIBTINYXML -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>= . -fstack-protector-strong -Wformat -Werror=format-security -pipe -fPIC -fno-builtin-memcmp -O2 -Wno-unused-result -Wno-d eprecated -fvisibility=hidden -I/usr/include -o "sopen_heka_read.o" "./t210/sopen_heka_read.c" In file included from ./t210/sopen_dcmtk_read.cpp:51: /usr/include/dcmtk/ofstd/ofstdinc.h:113:2: error: #error "Macro INCLUDE_CSTDIO not supported anymore. Include directly." 113 | #error "Macro INCLUDE_CSTDIO not supported anymore. Include directly." | ^ /usr/include/dcmtk/ofstd/ofstdinc.h:117:2: error: #error "Macro INCLUDE_CSTDLIB not supported anymore. Include directly." 117 | #error "Macro INCLUDE_CSTDLIB not supported anymore. Include directly." | ^ /usr/include/dcmtk/ofstd/ofstdinc.h:121:2: error: #error "Macro INCLUDE_CSTRING not supported anymore. Include directly." 121 | #error "Macro INCLUDE_CSTRING not supported anymore. Include directly." | ^ I attached a debdiff that adds a patch fixing this problem. Thanks! cheers, josch diff -Nru biosig-2.3.3/debian/changelog biosig-2.3.3/debian/changelog --- biosig-2.3.3/debian/changelog 2021-10-02 15:32:14.0 +0200 +++ biosig-2.3.3/debian/changelog 2022-05-03 23:06:01.0 +0200 @@ -1,3 +1,10 @@ +biosig (2.3.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * add patch to build with dcmtk >= 3.6.7 (closes: #XXX) + + -- Johannes Schauer Marin Rodrigues Tue, 03 May 2022 23:06:01 +0200 + biosig (2.3.3-1) unstable; urgency=medium [ Alois Schlögl ] diff -Nru biosig-2.3.3/debian/patches/dcmtk-3.6.7 biosig-2.3.3/debian/patches/dcmtk-3.6.7 --- biosig-2.3.3/debian/patches/dcmtk-3.6.7 1970-01-01 01:00:00.0 +0100 +++ biosig-2.3.3/debian/patches/dcmtk-3.6.7 2022-05-03 23:06:01.0 +0200 @@ -0,0 +1,15 @@ +--- a/biosig4c++/t210/sopen_dcmtk_read.cpp b/biosig4c++/t210/sopen_dcmtk_read.cpp +@@ -44,9 +44,9 @@ + #include "dcmtk/dcmdata/dctk.h" + #include "dcmtk/dcmdata/dcistrmf.h" + +-#define INCLUDE_CSTRING +-#define INCLUDE_CSTDLIB +-#define INCLUDE_CSTDIO ++ #include ++ #include ++ #include + + #include "dcmtk/ofstd/ofstdinc.h" + diff -Nru biosig-2.3.3/debian/patches/series biosig-2.3.3/debian/patches/series --- biosig-2.3.3/debian/patches/series 2021-10-02 15:32:14.0 +0200 +++ biosig-2.3.3/debian/patches/series 2022-05-03 23:04:36.0 +0200 @@ -1 +1,2 @@ fix-make-clean-when-mathematica-is-not-available.patch +dcmtk-3.6.7
Bug#1010544: victoriametrics: FTBFS on armel
Source: victoriametrics Version: 1.75.0+ds1-1 Severity: serious Tags: ftbfs sid bookworm 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=victoriametrics=armel=1.75.0%2Bds1-1=1651441792=0 === RUN TestAddMulti --- PASS: TestAddMulti (0.47s) PASS ok github.com/VictoriaMetrics/VictoriaMetrics/lib/uint64set25.179s ? github.com/VictoriaMetrics/VictoriaMetrics/lib/workingsetcache [no test files] ? github.com/VictoriaMetrics/VictoriaMetrics/lib/writeconcurrencylimiter [no test files] FAIL dh_auto_test: error: cd _build && go test -vet=off -v -p 4 github.com/VictoriaMetrics/VictoriaMetrics/app/victoria-metrics github.com/VictoriaMetrics/VictoriaMetrics/app/victoria-metrics/test github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/common github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/csvimport github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/datadog github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/graphite github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/influx github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/native github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/opentsdb github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/opentsdbhttp github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/prometheusimport github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/promremotewrite github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/remotewrite github.com/VictoriaMetrics/VictoriaMetrics/app/vmagent/vmimport github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert/config github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert/datasource github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert/notifier github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert/remoteread github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert/remotewrite github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert/tpl github.com/VictoriaMetrics/VictoriaMetrics/app/vmalert/utils github.com/VictoriaMetrics/VictoriaMetrics/app/vmauth github.com/VictoriaMetrics/VictoriaMetrics/app/vmbackup github.com/VictoriaMetrics/VictoriaMetrics/app/vmbackup/snapshot github.com/VictoriaMetrics/VictoriaMetrics/app/vmctl github.com/VictoriaMetrics/VictoriaMetrics/app/vmctl/influx github.com/VictoriaMetrics/VictoriaMetrics/app/vmctl/limiter github.com/VictoriaMetrics/VictoriaMetrics/app/vmctl/opentsdb github.com/VictoriaMetrics/VictoriaMetrics/app/vmctl/prometheus github.com/VictoriaMetrics/VictoriaMetrics/app/vmctl/vm github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/common github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/csvimport github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/datadog github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/graphite github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/influx github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/native github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/opentsdb github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/opentsdbhttp github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/prometheusimport github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/prompush github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/promremotewrite github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/relabel github.com/VictoriaMetrics/VictoriaMetrics/app/vminsert/vmimport github.com/VictoriaMetrics/VictoriaMetrics/app/vmrestore github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/bufferedwriter github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/graphite github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/graphiteql github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/netstorage github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/prometheus github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/promql github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/querystats github.com/VictoriaMetrics/VictoriaMetrics/app/vmselect/searchutils github.com/VictoriaMetrics/VictoriaMetrics/app/vmstorage github.com/VictoriaMetrics/VictoriaMetrics/lib/auth github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/actions github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/common github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/fscommon github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/fslocal github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/fsnil github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/fsremote github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/gcsremote github.com/VictoriaMetrics/VictoriaMetrics/lib/backup/s3remote github.com/VictoriaMetrics/VictoriaMetrics/lib/blockcache
Bug#1010543: mtail: FTBFS on ppc64el
Source: mtail Version: 3.0.0~rc48-4 Severity: serious Tags: ftbfs sid bookworm 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=mtail=ppc64el=3.0.0%7Erc48-4%2Bb1=1651446567=0 === RUN TestTestWakerWakes --- PASS: TestTestWakerWakes (0.00s) === RUN TestTestWakerTwoWakees --- PASS: TestTestWakerTwoWakees (0.00s) === RUN TestTestWakerTwoWakeups --- PASS: TestTestWakerTwoWakeups (0.00s) === RUN TestTimedWakerWakes --- PASS: TestTimedWakerWakes (0.02s) PASS ok github.com/google/mtail/internal/waker 0.027s FAIL dh_auto_test: error: cd build && go test -vet=off -v -p 4 -timeout 100s github.com/google/mtail/cmd/mfmt github.com/google/mtail/cmd/mtail github.com/google/mtail/internal/exporter github.com/google/mtail/internal/logline github.com/google/mtail/internal/metrics github.com/google/mtail/internal/metrics/datum github.com/google/mtail/internal/mtail github.com/google/mtail/internal/mtail/golden github.com/google/mtail/internal/runtime github.com/google/mtail/internal/runtime/code github.com/google/mtail/internal/runtime/compiler github.com/google/mtail/internal/runtime/compiler/ast github.com/google/mtail/internal/runtime/compiler/checker github.com/google/mtail/internal/runtime/compiler/codegen github.com/google/mtail/internal/runtime/compiler/errors github.com/google/mtail/internal/runtime/compiler/opt github.com/google/mtail/internal/runtime/compiler/parser github.com/google/mtail/internal/runtime/compiler/position github.com/google/mtail/internal/runtime/compiler/symbol github.com/google/mtail/internal/runtime/compiler/types github.com/google/mtail/internal/runtime/vm github.com/google/mtail/internal/tailer github.com/google/mtail/internal/tailer/logstream github.com/google/mtail/internal/testutil github.com/google/mtail/internal/waker returned exit code 1 make[1]: *** [debian/rules:34: override_dh_auto_test] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:25: binary-arch] Error 2 Cheers -- Sebastian Ramacher
Bug#1010542: lizardfs: FTBFS everywhere
Source: lizardfs Version: 3.12.0+dfsg-4 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=lizardfs=amd64=3.12.0%2Bdfsg-4%2Bb3=1651440278=0 ../src/common/libmfscommon.a(slogger.cc.o): in function `spdlog::spdlog_ex::spdlog_ex(std::__cxx11::basic_string, std::allocator > const&, int)': /usr/include/spdlog/common-inl.h:59: undefined reference to `fmt::v8::format_system_error(fmt::v8::detail::buffer&, int, char const*)' /usr/bin/ld: ../src/common/libmfscommon.a(slogger.cc.o): in function `std::__cxx11::basic_string, std::allocator > fmt::v8::format, std::allocator >&, unsigned long&, std::__cxx11::basic_string, std::allocator >&>(fmt::v8::basic_format_string, std::allocator >&>::type, fmt::v8::type_identity::type, fmt::v8::type_identity, std::allocator >&>::type>, std::__cxx11::basic_string, std::allocator >&, unsigned long&, std::__cxx11::basic_string, std::allocator >&)': /usr/include/fmt/core.h:3119: undefined reference to `fmt::v8::vformat[abi:cxx11](fmt::v8::basic_string_view, fmt::v8::basic_format_args >)' collect2: error: ld returned 1 exit status make[3]: *** [utils/CMakeFiles/mfsping.dir/build.make:105: utils/mfsping] Error 1 make[3]: Leaving directory '/<>/build' make[2]: *** [CMakeFiles/Makefile2:1671: utils/CMakeFiles/mfsping.dir/all] Error 2 Cheers -- Sebastian Ramacher
Bug#1010541: git-sizer: FTBFS on ppc64el
Source: git-sizer Version: 1.5.0-1 Severity: serious Tags: ftbfs sid bookworm 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=git-sizer=ppc64el=1.5.0-1%2Bb1=1651440393=0 --- PASS: TestNontrivialPipeline (0.05s) === CONT TestBigEPIPE pipeline_test.go:327: Error Trace:pipeline_test.go:327 Error: An error is expected but got nil. Test: TestBigEPIPE --- FAIL: TestBigEPIPE (0.05s) --- PASS: TestPipelineWithFunction (0.05s) --- PASS: TestPipelineReadFromSlowly (0.30s) --- PASS: TestPipelineReadFromSlowly2 (0.63s) --- PASS: TestLittleEPIPE (1.01s) FAIL FAILgithub.com/github/git-sizer/internal/pipe 1.016s ? github.com/github/git-sizer/internal/refopts[no test files] ? github.com/github/git-sizer/internal/testutils [no test files] ? github.com/github/git-sizer/isatty [no test files] ? github.com/github/git-sizer/meter [no test files] ? github.com/github/git-sizer/sizes [no test files] FAIL dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/github/git-sizer github.com/github/git-sizer/counts github.com/github/git-sizer/git github.com/github/git-sizer/internal/pipe github.com/github/git-sizer/internal/refopts github.com/github/git-sizer/internal/testutils github.com/github/git-sizer/isatty github.com/github/git-sizer/meter github.com/github/git-sizer/sizes returned exit code 1 make[1]: *** [debian/rules:12: override_dh_auto_test] Error 25 make[1]: Leaving directory '/<>' Cheers -- Sebastian Ramacher
Bug#1010540: RFS: opencpn/5.6.2+dfsg-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo10+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds the following two packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo10+1.dsc Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo10+1) buster-backports-sloppy; urgency=medium . * Initial buster backport of 5.6.2+dfsg2. * Rebase and renumber patches. * Add 1.2M patch restoring bundled wxsvg library since system libwxsvg is not available on buster (handled by repacking in 5.6.0). Regards, -- Alec Leamas
Bug#1010539: ghdl: FTBFS on armhf
Source: ghdl Version: 1.0.0+dfsg-8 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=ghdl=armhf=1.0.0%2Bdfsg-8=1644890335=0 /<>/testrundir/llvm/usr/bin/ghdl --disp-standard --std=87 > /<>/testrundir/llvm/usr/lib/ghdl/llvm/vhdl/src/std/v87/standard.vhdl /bin/sh: 1: /<>/testrundir/llvm/usr/bin/ghdl: not found make[2]: *** [Makefile:133: install] Error 127 make[2]: Leaving directory '/<>/builddir/llvm' > tests: sanity gna vests vpi > args: [33mGHDL is: /<>/testrundir/llvm/usr/bin/ghdl-llvm[0m GHDL 1.0.0 (Debian 1.0.0+dfsg-8) [Dunoon edition] Compiled with GNAT Version: 10.3.0 llvm code generator Written by Tristan Gingold. Copyright (C) 2003 - 2021 Tristan Gingold. GHDL is free software, covered by the GNU General Public License. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. REF: unknown HASH: unknown [33mGHDL help[0m usage: /<>/testrundir/llvm/usr/bin/ghdl-llvm COMMAND [OPTIONS] ... COMMAND is one of: analyze [OPTS] FILEs Analyze one or multiple VHDL files aliases: -a, analyse elaborate [OPTS] UNIT [ARCH] Elaborate design UNIT alias: -e run UNIT [ARCH] [RUNOPTS] Run design UNIT alias: -r elab-run [OPTS] UNIT [ARCH] [RUNOPTS] Elaborate and run design UNIT alias: --elab-run bind [OPTS] UNIT [ARCH] Bind design UNIT alias: --bind link [OPTS] UNIT [ARCH] Link design UNIT alias: --link list-link [OPTS] UNIT [ARCH] List objects file to link UNIT alias: --list-link compile [OPTS] FILEs -e UNIT [ARCH] Generate whole sequence to elaborate design UNIT from FILEs alias: -c make [OPTS] UNIT [ARCH] Make design UNIT alias: -m gen-makefile [OPTS] UNIT [ARCH] Generate a Makefile for design UNIT alias: --gen-makefile gen-depends [OPTS] UNIT [ARCH] Generate dependencies of design UNIT alias: --gen-depends disp-config Display tools path aliases: --disp-config, dispconfig, --dispconfig bootstrap-std (internal) Compile std.standard alias: --bootstrap-standard synth [FILES... -e] UNIT [ARCH] Synthesis from UNIT alias: --synth --libghdl-name Display libghdl name --libghdl-library-path Display libghdl library path --libghdl-include-dir Display libghdl include directory import [OPTS] FILEs Import units of FILEs alias: -i syntax [OPTS] FILEs Check syntax of FILEs alias: -s dir [LIBs] Display contents of the libraries alias: --dir files FILEs Display units in FILES alias: -f clean Remove generated files alias: --clean remove Remove generated files and library file alias: --remove copy Copy work library to current directory alias: --copy disp-standard Disp std.standard in pseudo-vhdl alias: --disp-standard elab-order [OPTS] UNIT [ARCH] Display ordered source files alias: --elab-order find-top Display possible top entity in work library alias: --find-top chop [OPTS] FILEs Chop FILEs alias: --chop lines FILEs Precede line with its number alias: --lines reprint [OPTS] FILEs Redisplay FILEs alias: --reprint fmt [OPTS] FILEs Format FILEs alias: --format compare-tokens [OPTS] REF FILEs Compare FILEs with REF alias: --compare-tokens pp-html FILEs Pretty-print FILEs in HTML alias: --pp-html xref-html FILEs Display FILEs in HTML with xrefs alias: --xref-html xref FILEs Generate xrefs alias: --xref --vpi-compile CMD ARGS Compile with VPI include path --vpi-link CMD ARGS Link with VPI library --vpi-cflags Display VPI compile flags --vpi-ldflags Display VPI link flags --vpi-include-dir Display VPI include directory --vpi-library-dir Display VPI library directory --vpi-library-dir-unix Display VPI library directory (unix form) file-to-xml FILEs Dump AST in XML alias: --file-to-xml help [CMD] Display this help or [help on CMD] aliases: -h, --help version Display ghdl version aliases: -v, --version opts-help Display help for analyzer options alias: --options-help To display the options of a GHDL program, run your program with the 'help' option. Also see 'opts-help' for analyzer options. Please, refer to the GHDL manual for more information. Report issues on https://github.com/ghdl/ghdl [33m[GHDL - test] sanity[0m sanity 001hello87: [32mok[0m sanity 002hello2008: [32mok[0m sanity 004all08: [32mok[0m sanity tests are successful [33m[GHDL - test] gna[0m gna bug01: [32mok[0m gna bug010: [32mok[0m gna bug0100: [32mok[0m gna bug0101: [32mok[0m gna bug0103: [32mok[0m gna bug0104: [32mok[0m gna bug0105: [32mok[0m gna bug0106: [32mok[0m gna bug0108: [32mok[0m gna bug0109: [32mok[0m gna bug011: [32mok[0m gna bug0110: [32mok[0m gna bug0111: [32mok[0m gna bug0112: [32mok[0m gna bug0114: [32mok[0m gna bug0115: [32mok[0m gna bug0117: [32mok[0m gna bug0118: [32mok[0m gna bug012: [32mok[0m gna bug0120: [32mok[0m gna bug014: [32mok[0m gna bug015: [32mok[0m
Bug#1010538: gdu: FTBFS on ppc64el
Source: gdu Version: 5.13.2-1 Severity: serious Tags: ftbfs sid bookworm 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=gdu=ppc64el=5.13.2-1%2Bb1=1651439537=0 === RUN TestMin --- PASS: TestMin (0.00s) PASS ok github.com/dundee/gdu/v5/tui0.229s FAIL dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/dundee/gdu/v5/build github.com/dundee/gdu/v5/cmd/gdu github.com/dundee/gdu/v5/cmd/gdu/app github.com/dundee/gdu/v5/internal/common github.com/dundee/gdu/v5/internal/testanalyze github.com/dundee/gdu/v5/internal/testapp github.com/dundee/gdu/v5/internal/testdev github.com/dundee/gdu/v5/internal/testdir github.com/dundee/gdu/v5/pkg/analyze github.com/dundee/gdu/v5/pkg/device github.com/dundee/gdu/v5/pkg/fs github.com/dundee/gdu/v5/report github.com/dundee/gdu/v5/stdout github.com/dundee/gdu/v5/tui returned exit code 1 make: *** [debian/rules:14: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 Cheers -- Sebastian Ramacher
Bug#1010278: xterm_set_titles is broken
I have the same problem, which causes a broken display when eg, deleting messages. I can confirm that setting TERM=xterm-p370 avoids the problem. -- see shy jo signature.asc Description: PGP signature
Bug#1010177: (no subject)
same error for me, no problem for linux 5.16. thanks for fixing.
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Source: dcmtk Version: 3.6.6-5 Severity: grave Justification: renders package unusable X-Debbugs-Cc: ti...@debian.org Hi Andreas, thanks for your upload of the new upstream version of dcmtk. Unfortunately, I think this is missing a proper transition because the ABI and thus the SONAME changed. This can also be seen in the autopkgtests of biosig, odil and odin which all fail with a similar error right now: biosig & odil: ImportError: libdcmdata.so.16: cannot open shared object file: No such file or directory odin: gencoil: error while loading shared libraries: libdcmimgle.so.16: cannot open shared object file: No such file or directory This is because the new upstream version bumped the SONAME from 16 to 17. This means, that the binary package name should also change from libdcmtk16 to libdcmtk17. This probably would've been caught by lintian if package-name-doesnt-match-sonames wasn't overridden in debian/libdcmtk16.lintian-overrides... :/ The package should've probably first been uploaded to experimental, would go through binary-NEW and create a auto-dcmtk transition. I'm unsure how to clean this up now that the package has already been uploaded to unstable. I'm going to rebuild all reverse dependencies and see if anything breaks and report back to you in case I find any FTBFS caused by the new dcmtk version. Thanks! cheers, josch
Bug#1010402: debmake-doc: Quilt configuration leads to shell error
Hello, Le 03/05/2022 à 01:00, Osamu Aoki a écrit : 1.17-4 is in testing and used for Debian web site web page generation now. There is no "+" in https://www.debian.org/doc/manuals/maint-guide/modify.fr.html#quiltrc as I see. The problem appears here: https://www.debian.org/doc/manuals/debmake-doc/ch03.en.html#quilt-setup (debmake-doc, not maint-guide ;) ) and the patch I provided applies to this source: https://salsa.debian.org/debian/debmake-doc/-/blob/master/asciidoc/12-setups.txt#L91 Philippe.
Bug#1010395: ITP: neom -- desktop IM client for the Matrix protocol
0.0~git20220427 draft 1, needs embedding 235 crates (148 missing, 5 broken, 2 incomplete, 62 outdated, 18 ahead); builds in ~25 minutes; successfully connects to a matrix instance. My plan now is to keep up with upstream code development, package dependencies, and encourage the Rust team to update/upgrade existing but unaligned crate packages. You can help by testing this draft package (either build it yourself or tell if you want me to provide you a binary package) and provide feedback on how well it works in your environment. You can also help by joining the Rust team in Debian and help unbreak and upgrade packaged crates, and add more: https://salsa.debian.org/matrix-team/neom/-/blob/debian/latest/debian/TODO - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#945788: lightdm: Language support is broken
I confirm that this bug still exists as described on Bullseye. The weird behavior of not using the selected language until the second login is an upstream issue present (for years and years) in all distros I've tried. But the /etc/pam.d/lightdm quirk is unique to Debian. Could at least that last sub-issue be fixed? Thanks a lot.
Bug#1010535: cyrus-imapd: FTBFS against openssl 3
Package: cyrus-imapd
Version: 3.6.0~beta2-2
Severity: normal
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic
Dear Maintainer,
When building against openssl 3 from experimental, cyrus-imapd will fail in
unit test at build time. This appears to be related to related to the warning
listed at
https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_base_id.html
which suggests using
https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_is_a.html
instead.
In these failing cases, EVP_PKEY_base_id is returning 0, which fails to match
the nid that is being compared against.
I have a patch which converts usage of EVP_PKEY_base_id to EVP_PKEY_is_a, which
allows builds against OpenSSL 3 to pass for both Ubuntu Kinetic and Debian Sid.
Please see attached. I also updated another usage of EVP_PKEY_base_id which I
believe will be incorrect under OpenSSL 3 but that doesn't seem to be caught by
current tests.
Ordinarly at this point I would forward to upstream, but I prefer to do so
first by reproducing the failures with raw upstream source which is is having
unrelated build problems for me. So I'm starting this way.
(also filed at https://launchpad.net/bugs/1971469)
-Dan
Description: OpenSSL 3 compatibility fix for EVP_PKEY_base_id usage
The WARNING section of the EVP_PKEY_base_id manpage in OpenSSL 3 says that
EVP_PKEY_base_id is "only reliable with EVP_PKEYs that have been assigned an
internal key with EVP_PKEY_assign_*", and the usage here of base_id seems to
be without a EVP_PKEY_assign usage.
This same warning points to EVP_PKEY_is_a, which seems fine for this purpose
but is part of OpenSSL 3.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/cyrus-imapd/+bug/1971469
Last-Update: 2022-05-03
--- a/imap/http_jwt.c
+++ b/imap/http_jwt.c
@@ -120,10 +120,15 @@
EVP_PKEY *pkey = PEM_read_bio_PUBKEY(bp, NULL, NULL, NULL);
if (pkey) {
+#if OPENSSL_VERSION_NUMBER >= 0x3000L
+if (!EVP_PKEY_is_a(pkey, "RSA")) {
+xsyslog(LOG_ERR, "Unsupported public key", NULL);
+#else
int nid = EVP_PKEY_base_id(pkey);
if (nid != EVP_PKEY_RSA) {
xsyslog(LOG_ERR, "Unsupported public key",
"type=<%s>", OBJ_nid2ln(nid));
+#endif
EVP_PKEY_free(pkey);
pkey = NULL;
}
@@ -318,6 +323,25 @@
return 1;
}
+static int validate_pkey_type(struct jwt *jwt, EVP_PKEY *pkey)
+{
+if (!jwt->nid)
+return 0;
+
+if (jwt->nid == EVP_PKEY_base_id(pkey))
+return 1;
+
+#if OPENSSL_VERSION_NUMBER >= 0x3000L
+if (jwt->nid == EVP_PKEY_HMAC && EVP_PKEY_is_a(pkey, "HMAC"))
+return 1;
+
+if (jwt->nid == EVP_PKEY_RSA && EVP_PKEY_is_a(pkey, "RSA"))
+return 1;
+#endif
+
+return 0;
+}
+
static int validate_signature(struct jwt *jwt)
{
buf_reset(>buf);
@@ -339,7 +363,7 @@
EVP_PKEY *pkey = ptrarray_nth(, i);
EVP_MD_CTX_reset(ctx);
-if (jwt->nid != EVP_PKEY_base_id(pkey))
+if (!validate_pkey_type(jwt, pkey))
continue;
if (jwt->nid == EVP_PKEY_HMAC) {
Bug#1001068: samba: Missing upstream commit 0a546be0 on bullseye, bookworm and sid (part of CVE-2020-25717)
Hi Paul, On Tue, May 03, 2022 at 09:05:34PM +0200, Paul Gevers wrote: > Dear all, > > On Fri, 03 Dec 2021 15:44:02 +0100 =?utf-8?q?J=C3=B6rg_Behrmann?= > wrote: > > The upstream samba commit 0a546be0 is included in the buster security > > release > > 2:4.9.5+dfsg-5+deb10u2 via the patch file bug-14901-v4-9.patch, but is > > missing > > in the bullseye security release 2:4.13.13+dfsg-1~deb11u2. > > This bug shows up in the list of RC bugs for bookworm, because according to > the fixed versions, it still applies to unstable and testing. I *assume* > this has been fixed in the mean time in unstable. It would be great if > somebody could confirm that, ideally with the appropriate "Control: -1 fixed > ." line at the start of the mail. Right, the upstream commit in question is included in 4.16.0 upstream, so added an additional fixed version to the bug. Regards, Salvatore
Bug#1010534: src:libperl-critic-freenode-perl: fails to migrate to testing for too long: dependent upon package conflicts
Source: libperl-critic-freenode-perl Version: 0.033-1 Severity: serious Control: close -1 0.033-2 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:libperl-critic-freenode-perl has been trying to migrate for 61 days [2]. Hence, I am filing this bug. It seems [3] that libperl-critic-community-perl has a conflicts with this version of libperl-critic-freenode-perl. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=libperl-critic-freenode-perl [3] https://qa.debian.org/dose/debcheck/unstable_main/1651554002/packages/libperl-critic-freenode-perl.html OpenPGP_signature Description: OpenPGP digital signature
Bug#1008481: marked as pending in im-config
Hi On Wed, May 4, 2022 at 2:30 AM Gunnar Hjalmarsson wrote: > > Control: tag -1 pending > > Hello, > > Bug #1008481 in im-config reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/input-method-team/im-config/-/commit/74f8b98e1b4bf7f699059840bc2857b9a9140e3d > > > Add SDL_IM_MODULE to fcitx4 and fcitx5 > > Closes: #1008481 Thanks for moving forward. I've been busy with life recently due to the lockdown in Shanghai. -- Shengjing Zhu
Bug#1001068: samba: Missing upstream commit 0a546be0 on bullseye, bookworm and sid (part of CVE-2020-25717)
Dear all, On Fri, 03 Dec 2021 15:44:02 +0100 =?utf-8?q?J=C3=B6rg_Behrmann?= wrote: The upstream samba commit 0a546be0 is included in the buster security release 2:4.9.5+dfsg-5+deb10u2 via the patch file bug-14901-v4-9.patch, but is missing in the bullseye security release 2:4.13.13+dfsg-1~deb11u2. This bug shows up in the list of RC bugs for bookworm, because according to the fixed versions, it still applies to unstable and testing. I *assume* this has been fixed in the mean time in unstable. It would be great if somebody could confirm that, ideally with the appropriate "Control: -1 fixed ." line at the start of the mail. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1010485: plocate PRUNE_BIND_MOUNTS incompatible with btrfs subvolumes
On Tue, May 03, 2022 at 07:59:48PM +0200, Julian Andres Klode wrote: > I fail to see how naming it @root instead of @, or @screwedup for that > matter makes a difference. Try it. :-) > This is a significant regression for users coming from mlocate. They had > working locate No, did they not. The mlocate updatedb code had broken bind mount detection after the switch from /etc/mtab to /proc/mountinfo, which specifically broke btrfs subvolumes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746943 > If you prefer to keep plocate broken with btrfs in Debian, Please stop misrepresenting the issue. plocate isn't broken with btrfs, but you can configure btrfs subvolumes in a way such that plocate (and basically any other tool that tries to skip bind mounts) will not work in the default configuration. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#1010533: mark python3-setuptools-git Multi-Arch: foreign
Package: python3-setuptools-git
Version: 1.2-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:dbus-deviation src:freedombox src:pyxrd
The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on python3-setuptools-git is not
satisfiable. In general, Architecture: all packages can never satisfy
cross Build-Depends unless marked Multi-Arch: foreign or annotated
:native. In this case, I think the foreign marking is reasonable. All of
its dependencies are already marked Multi-Arch: foreign or annotated
:any. It contains a pure python module and even though byte compiled
Python files are created, the module can be used without. As such, I
think the marking is reasonable. Please consider applying the attached
patch.
Helmut
diff --minimal -Nru python-setuptools-git-1.2/debian/changelog
python-setuptools-git-1.2/debian/changelog
--- python-setuptools-git-1.2/debian/changelog 2019-10-13 09:01:44.0
+0200
+++ python-setuptools-git-1.2/debian/changelog 2022-05-03 20:28:52.0
+0200
@@ -1,3 +1,10 @@
+python-setuptools-git (1.2-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark python3-setuptools-git Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Tue, 03 May 2022 20:28:52 +0200
+
python-setuptools-git (1.2-3) unstable; urgency=medium
* Update homepage location.
diff --minimal -Nru python-setuptools-git-1.2/debian/control
python-setuptools-git-1.2/debian/control
--- python-setuptools-git-1.2/debian/control2019-10-13 09:01:44.0
+0200
+++ python-setuptools-git-1.2/debian/control2022-05-03 20:28:51.0
+0200
@@ -8,6 +8,7 @@
Package: python3-setuptools-git
Architecture: all
+Multi-Arch: foreign
Depends: ${python3:Depends}, ${misc:Depends}, python3-setuptools, git
Description: plugin for setuptools that enables git integration
This is a plugin for setup tools that enables Git integration. Once
Bug#1010372: [debian-mysql] Bug#1010372: mysql-8.0: Should mysql-8.0 be removed from unstable?
Control: forcemerge 1004180 1010372 Hi Robie, On Tue, May 03, 2022 at 04:51:54PM +0100, Robie Basak wrote: > Hi Salvatore, > > On Fri, Apr 29, 2022 at 09:52:04PM +0200, Salvatore Bonaccorso wrote: > > Should mysql-8.0 be dropped completely from the archive or is there > > still interest in keeping in in unstable? > > I think this is a dupe of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004180? Was asking > again intentional? Ah, no sort of combination of a) human error, b) triggering the question given there was no movement since some Oracle CPUs on the version. Let's merge the both. > My answer is the same - we'd like to keep mysql-8.0 in unstable and are > working on updating unstable and getting Ubuntu back into sync against > Debian. > > At Canonical, I am onboarding a colleague who will be working on this. > Prompted again by you, we just set ourselves a goal of having this done > by the end of the month, if that's OK with you? Okay. but then I hope this can happen soon. As said above I did forgot I already asked, and did overlook we had already #1004180, but my worry is still the same. Even if it's only in unstable, the current list from https://security-tracker.debian.org/tracker/source-package/mysql-8.0 is getting huge. Thanks in any case if you pick it up and keep then unstable and get back on track for the version. Regards, Salvatore
Bug#1010532: dcm2niix FTCBFS: python3-sphinx dependency not satisfiable
Source: dcm2niix Version: 1.0.20211006-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability dcm2niix cannot satisfy its cross Build-Depends, because its dependency on python3-sphinx is not satisfiable. In general, Architecture: all packages can never satisfy cross Build-Depends unless marked Multi-Arch: foreign or annotated :native. In this case, we considered marking python3-sphinx, but it can be used in an architecture-dependent way, so it must not be thus marked. dcm2niix happens to use python3-sphinx in an architecture-independent way. We can express that by annotating the relevant dependency with :native. Doing so makes dcm2niix cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru dcm2niix-1.0.20211006/debian/changelog dcm2niix-1.0.20211006/debian/changelog --- dcm2niix-1.0.20211006/debian/changelog 2021-10-10 21:33:59.0 +0200 +++ dcm2niix-1.0.20211006/debian/changelog 2022-05-03 20:36:38.0 +0200 @@ -1,3 +1,11 @@ +dcm2niix (1.0.20211006-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Annotate python3-sphinx build dependency with :native. +(Closes: #-1) + + -- Helmut Grohne Tue, 03 May 2022 20:36:38 +0200 + dcm2niix (1.0.20211006-1) unstable; urgency=medium * Team upload diff --minimal -Nru dcm2niix-1.0.20211006/debian/control dcm2niix-1.0.20211006/debian/control --- dcm2niix-1.0.20211006/debian/control2021-10-10 21:33:59.0 +0200 +++ dcm2niix-1.0.20211006/debian/control2022-05-03 20:36:37.0 +0200 @@ -9,7 +9,7 @@ libturbojpeg0-dev, libyaml-cpp-dev, pkg-config, - python3-sphinx, + python3-sphinx:native, zlib1g-dev Standards-Version: 4.6.0 Vcs-Browser: https://salsa.debian.org/med-team/dcm2niix
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
Hi Julian, On Tue, May 03, 2022 at 06:22:37PM +0200, Julian Andres Klode wrote: > On Tue, May 03, 2022 at 08:47:56AM -0700, Clayton Craft wrote: > > Hi folks, > > > > > what is the story there? I don't believe any of those MS reports > > > are actually (important) security issues, > > > > The issue is basically that microsoft and/or their customers are allowing > > arbitrary code execution under a system user account (the same one that > > normally > > runs systemd-networkd). I can't speak for Debian, but other distros I've > > seen > > restrict who can "own" the systemd-networkd service name on the system dbus > > session to that user, so obviously if you allow that user to run arbitrary > > code > > then you're going to allow anything to bypass those restrictions. > > That's my understanding and hence why I asked them to publish a > correction within 4 business days that this is caused by local > misconfiguration and not a result of undisclosed security > vulnerabilities. > > > > > That's important in this context because networkd-dispatcher derives paths > > to > > scripts it runs based on the messages it receives on dbus for the > > systemd-networkd service. So if something else can "own" that name on the > > bus > > then it can (before the sanitation patch in the latest version) get > > networkd-dispatcher to run things located elsewhere. > > > > I should have been sanitizing input from dbus, which networkd-dispatcher > > does > > now. But again, in every other configuration I've seen, the user who is > > sending > > messages under that service is a dedicated system user who is only running > > systemd-networkd. > > > > > also why was this being disclosed publicly rather than responsibly? > > > > It was disclosed responsibly, as far as I understand the "responsible > > disclosure" process to be. They contacted me privately about a month ago > > about > > it, giving me enough time to come up with something to address it (I'm not > > paid > > to work on this :D) They also gave me a script to reproduce it shortly after > > contacting me, which (after a lot of effort) I was able to trigger it a > > couple > > of times in a VM running Arch Linux, but only after doing things that I > > shouldn't have been doing in the "real world" > > (e.g. sudo -u systemd-network ./foo) > > So the way this usually goes is that distros also get notified, and > fixes are held back until a date (well hour really) coordinated by the > distros so everyone can release fixes at the same time, by way of > contacting the distros mailing list > (https://oss-security.openwall.org/wiki/mailing-lists/distros) or > individual email. > > Given that you are just working on this in your spare time and had not > had to deal with a CVE, I think MS should have at least helped ensure that > this is being communicated properly. So if I followed your both argumentation, then we can treat this within Debian as negligible issue, not impacting us. Julian, correct? If so we can simply close the bug with the version including those upstream comimits related and there is no necessity for a security update (and neither possibly a point release update, or maybe as hardening in the point release). I notice Ubuntu appears to have released a USN for this: https://ubuntu.com/security/notices/USN-5395-1 Regards, Salvatore
Bug#999887: dcmtk FTCBFS: uses TRY_RUN check for signedness of char
Control: tags -1 fixed-upstream https://github.com/DCMTK/dcmtk/commit/bd4e58ea577012b5aaa43b9caaa56c9e3805da33
Bug#1008481: Add SDL_IM_MODULE to fcitx4 and fcitx5
On 2022-04-06 11:13, wangtianzhu wrote: INPUT_METHOD have also been added in the patch. INPUT_METHOD can be used to distinguish fcitx4 and fcitx5. Please submit a separate bug about that. If you do, I think you need to elaborate on the justification. -- Rgds, Gunnar Hjalmarsson
Bug#1010531: Acknowledgement (bullseye-pu: package ldap-account-manager/7.4-1)
Hi team,
here is the debdiff for the changes.
Best regards
Roland
diff -Nru ldap-account-manager-7.4/debian/changelog ldap-account-manager-7.4/debian/changelog
--- ldap-account-manager-7.4/debian/changelog 2020-12-06 09:05:33.0 +0100
+++ ldap-account-manager-7.4/debian/changelog 2022-04-15 19:33:40.0 +0200
@@ -1,3 +1,9 @@
+ldap-account-manager (7.4-1+deb11u1) stable-security; urgency=medium
+
+ * fixes CVE-2022-24851
+
+ -- Roland Gruber Fri, 15 Apr 2022 19:33:40 +0200
+
ldap-account-manager (7.4-1) unstable; urgency=medium
* new upstream release
diff -Nru ldap-account-manager-7.4/debian/patches/01_CVE-2022-24851.patch ldap-account-manager-7.4/debian/patches/01_CVE-2022-24851.patch
--- ldap-account-manager-7.4/debian/patches/01_CVE-2022-24851.patch 1970-01-01 01:00:00.0 +0100
+++ ldap-account-manager-7.4/debian/patches/01_CVE-2022-24851.patch 2022-04-15 19:29:02.0 +0200
@@ -0,0 +1,87 @@
+Description: CVE-2022-24851
+ Security fix for stored XSS and reading of arbitary images.
+Author: Roland Gruber
+Origin: upstream
+Bug: https://github.com/LDAPAccountManager/lam/issues/170
+Applied-Upstream: 7.9.1
+Reviewed-by: Roland Gruber
+Last-Update: 2022-04-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: ldap-account-manager-7.4/lib/html.inc
+===
+--- ldap-account-manager-7.4.orig/lib/html.inc
ldap-account-manager-7.4/lib/html.inc
+@@ -525,10 +525,10 @@ class htmlInputField extends htmlElement
+ }
+ if (isset($values[$this->fieldName])) {
+ if (isObfuscatedText($values[$this->fieldName][0])) {
+-$this->fieldValue = deobfuscateText($values[$this->fieldName][0]);
++$this->fieldValue = htmlspecialchars(deobfuscateText($values[$this->fieldName][0]));
+ }
+ else {
+-$this->fieldValue = $values[$this->fieldName][0];
++$this->fieldValue = htmlspecialchars($values[$this->fieldName][0]);
+ }
+ }
+ $validators = array();
+@@ -2588,7 +2588,7 @@ class htmlInputTextarea extends htmlElem
+ function generateHTML($module, $input, $values, $restricted, &$tabindex, $scope) {
+ $this->cssClasses[] = 'ui-corner-all';
+ if (isset($values[$this->name])) {
+- $this->value = implode("\r\n", $values[$this->name]);
++ $this->value = htmlspecialchars(implode("\r\n", $values[$this->name]));
+ }
+ $colCount = ($this->colCount != null) ? ' cols="' . $this->colCount . '"' : '';
+ $rowCount = ($this->rowCount != null) ? ' rows="' . $this->rowCount . '"' : '';
+Index: ldap-account-manager-7.4/templates/pdfedit/pdfpage.php
+===
+--- ldap-account-manager-7.4.orig/templates/pdfedit/pdfpage.php
ldap-account-manager-7.4/templates/pdfedit/pdfpage.php
+@@ -121,8 +121,9 @@ if(!isset($_SESSION['currentPDFStructure
+ }
+ }
+
++$logoFiles = \LAM\PDF\getAvailableLogos($_SESSION['config']->getName());
+ if (!empty($_POST['form_submit'])) {
+- updateBasicSettings($_SESSION['currentPDFStructure']);
++ updateBasicSettings($_SESSION['currentPDFStructure'], $logoFiles);
+ updateSectionTitles($_SESSION['currentPDFStructure']);
+ addSection($_SESSION['currentPDFStructure']);
+ addSectionEntry($_SESSION['currentPDFStructure']);
+@@ -218,7 +219,6 @@ else if (isset($_POST['pdfname'])) {
+ // headline
+ $headline = $_SESSION['currentPDFStructure']->getTitle();
+ // logo
+-$logoFiles = \LAM\PDF\getAvailableLogos($_SESSION['config']->getName());
+ $logos = array(_('No logo') => 'none');
+ foreach($logoFiles as $logoFile) {
+ $logos[$logoFile['filename'] . ' (' . $logoFile['infos'][0] . ' x ' . $logoFile['infos'][1] . ")"] = $logoFile['filename'];
+@@ -509,14 +509,25 @@ function translateFieldIDToName($id, $sc
+ *
+ * @param PDFStructure $structure
+ */
+-function updateBasicSettings(PDFStructure &$structure) {
++function updateBasicSettings(PDFStructure &$structure, $logoFiles) {
+ // set headline
+ if (isset($_POST['headline'])) {
+ $structure->setTitle(str_replace('<', '', str_replace('>', '', $_POST['headline'])));
+ }
+ // set logo
+ if (isset($_POST['logoFile'])) {
+- $structure->setLogo($_POST['logoFile']);
++$fileName = $_POST['logoFile'];
++ $found = false;
++ foreach ($logoFiles as $logoFile) {
++ if ($logoFile['filename'] === $fileName) {
++ $found = true;
++}
++}
++ if (!$found) {
++ logNewMessage(LOG_ERR, 'Invalid PDF logo file: ' . $fileName);
++ return;
++}
++ $structure->setLogo($fileName);
+ }
+ // set folding marks
+ if (isset($_POST['foldingmarks'])) {
diff -Nru ldap-account-manager-7.4/debian/patches/series ldap-account-manager-7.4/debian/patches/series
--- ldap-account-manager-7.4/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ ldap-account-manager-7.4/debian/patches/series 2022-04-15 19:14:10.0 +0200
@@ -0,0 +1 @@
+01_CVE-2022-24851.patch
Bug#1010531: bullseye-pu: package ldap-account-manager/7.4-1
Package: release.debian.org Severity: important Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: p...@rolandgruber.de [ Reason ] Stored XSS and arbitrary image read vulnerability. See https://github.com/LDAPAccountManager/lam/security/advisories/GHSA-f2fr-cccr-583v [ Impact ] Security issue [ Tests ] Manual tests were done [ Risks ] Minimal risk, backport of latest release 7.9.1-1 [ 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 ] Backport of upstream fixes of 7.9.1 version. See https://github.com/LDAPAccountManager/lam/commit/39c48502cfa61c682cfd5f0cac3e3a8a2c3c9dcf [ Other info ] Security team asked to add this to next point release. It would not justify a DSA.
Bug#1010485: plocate PRUNE_BIND_MOUNTS incompatible with btrfs subvolumes
On Mon, May 02, 2022 at 07:02:14PM +0200, Steinar H. Gunderson wrote: > On Mon, May 02, 2022 at 06:47:46PM +0200, Julian Andres Klode wrote: > > It says to make / as subvolume as well, which seems incomplete, as > > mounted at / is the subvolume @ (that's the standard Ubuntu layout); > > That would be to make it at @root or similar. I fail to see how naming it @root instead of @, or @screwedup for that matter makes a difference. > > > updatedb needs to parse /proc/mounts, look for subvol= flag, and > > for each subvol= traverse the shortest path (or first path it sees). > > There's no way you can meaningfully say that /a is shorter than /b. There's a word for confusing the issue with corner cases that I don't remember that perfectly describes what's happening here. > And the order Linux gives you a directory entry back is pretty much random, > so “first it sees“ would be a nightmare for incremental updatedb. It's not a problem to parse /proc/mounts, sort it and consider the shortest/first path the canonical location of a "bind mount". Then all the normal cases of having a btrfs fs mounted at like /, /.snapshots or whatever, /var/log will just work as you expect them to, and if you mount the same subvolume in multiple places, the behavior is still odd, it would index /a and not /b, but those are niche cases in comparison, and the behavior is still better than not indexing at all. > > If you don't want bind mounts pruned (and that includes btrfs subvolumes > on the inside of each other), you'll need to turn off the bind mount pruning > option. Or you'd have to fix btrfs so that it doesn't implement subvolumes > as bind mounts :-) There are no btrfs subvolumes inside of each other here. At least not in the sense that the subvolume is inside the subvolume, all subvolumes are at the / level of the file system (which is outside the filesystem hierarchy mounted at /, but might be mounted temporarily for snapshotting purposes). They are inside each other in the sense that we mount those top-level subvolumes below the /@ subvolumes. This is a significant regression for users coming from mlocate. They had working locate, and after they migrate to plocate, their databases are empty and they spent hours trying to figure out why. That's the reason I (work me) reported it in Ubuntu and put it on the team backlog to work on. If you prefer to keep plocate broken with btrfs in Debian, that's your choice. It's not a choice I agree with; and I'm happy carrying a delta for in Ubuntu to make things work for our users. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1010530: /etc/trafshow: /etc/trafshow: line 50: Unknown port `timed'
Package: netdiag Version: 1.2-1.1 Severity: normal File: /etc/trafshow X-Debbugs-Cc: miroslaw.kwasn...@pwr.edu.pl Dear Maintainer, trafshow doesn't start whithout commenting this line. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages netdiag depends on: ii debconf [debconf-2.0] 1.5.77 ii libc6 2.31-13+deb11u3 ii libncurses66.2+20201114-2 ii libpcap0.8 1.10.0-2 ii libtinfo6 6.2+20201114-2 ii netbase6.3 netdiag recommends no packages. netdiag suggests no packages. -- debconf information: netdiag/run_statnetd: false
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
Am Tue, May 03, 2022 at 04:35:46PM +0200 schrieb Tobias Frost: > Hi Michael, > > (@Jan: would be nice if you could chimein in regards to this RFS) Hi Tobias, Hi Michal, As you might have guessed I'm busier than I would like and do usually need a bit of time to respond. > On Tue, May 03, 2022 at 12:28:39PM +0200, Michal Sojka wrote: > > > the package triggers several lintian warnings. I guess most of them were > > > already present in old version. But at least the > > > package-contains-no-arch-dependent-files warning for the new usbrelayd > > > package can be trivially fixed by setting its arch to "all" instead of > > > "any". > > I've removed the package-contains-no-arch-dependent-files warning and > > reuploaded (https://mentors.debian.net/package/usbrelay/). I'm a bit > > confused that when I run lintian locally, I get less warnings that what > > is shown in mentors.debian.net. Are there some switches that I need to > > run lintian with to see all relevant warnings? > > > > I'm also not sure about NMU warnings. Shall I mention NMU in the > > changelog or it will be done by the one who will really upload the > > package? > > no, the sponsor usually does not modfify the package. > Regarding the NMU, see below, as our mails crossed... > On Mon, May 02, 2022 at 09:44:59PM +0200, Michal Sojka wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for package "usbrelay": > > > > * Package name: usbrelay > >Version : 1.0-1 > >Upstream Author : Darryl Bond > > * URL : https://github.com/darrylb123/usbrelay > > * License : GPL-2+, CC-BY-SA-4.0 > > * Vcs : https://salsa.debian.org/wentasah/usbrelay > >Section : electronics > > The package is officially maintained by DD Jan Dittberner, but he seems > > to be no longer active, at least with this package. I contribute to the > > development of the upstream package and from time to time, users report > > problems that are caused by too old version of the package in the Debian > > archive. Having more recent version in Debian would be beneficial. It would have been a good idea to contact me directly or via a wishlist bug requesting a package update. I would have answered a wishlist bug requesting an usbrelay upstream version update. The RFS came a bit surprisingly. A short mail before starting the work would have been nice. I had contact with Darryl Bond in the past and responded to his requests. I would be happy to have a co-maintainer for usbrelay. @Michal you may add yourself to Uploaders if you are interested in taking care of the package in the future. Please run lintian with the flags -i -v -E --pedantic to get the maximum output. I recommend using pbuilder or sbuild to build in a clean environment. I usually use sbuild in combination with git-buildpackage to do my package builds. Both sbuild and pbuilder can lintian automatically after a finished package build. > unfortunatly those bugs were not reported in the Debian bug tracker... > > Some thoughts about procedures: > Jan is generally active (uploaded a package last month), but is in the > LowNMU list [1] and the package is in the salsa Debian group [2]. > Using the "LowNMU" procedure means that your package needs to be a NMU [3], > but an NMU requires that the upload fixes bugs reported in the Debian BTS and > a > NMU limits the changes you are allowed to do in a package. You can of course > file the bugs you fix in your changes in the Debian BTS (including a "please > package the new upstream version where you can list all the problems with the > old version.), but some changes will still be out of scope for an NMU. > > The salsa Debian group is technically a Team upload [4] and team-uploads do > not > have restrictions on what to upload, so I guess this is an viable approach. > > The third option is to adopt the package -- either by an explicit OK to do > from Jan > or via the ITS procedure [5]. With that, you will become (co-)maintainer of > the package, but that implies some kind of promise to also look after the > package in > the future. This is of course the best outcome for Debian and your project, > but > also means a commitment in maintaing the package. > > [1] https://wiki.debian.org/LowThresholdNmu > > [2] > https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#collaborative-maint␆bib > [3] https://wiki.debian.org/NonMaintainerUpload > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus > [4] https://wiki.debian.org/TeamUpload > [5] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > https://wiki.debian.org/PackageSalvaging > (The "conservative" criterias are imho fulfilled: > -::q open bugs, missing upstream releases, sourceful
Bug#1010529: Problems with theme HighContrast in Debian 11.2 и 11.3 64-bits Xfce 4.16 DoubleCmd 1.0.5
Package: libgtk-3-0
Version: 3.24.5-1
Severity: normal
X-Debbugs-Cc: serfyo...@yandex.ru
Dear Maintainer,
In Debian 11.2 and 11.3 64-bits Xfce 4.16, under the login of a "regular user"
, I encountered a strange thing: in DoubleCommander 1.0.5 or v.10177, with
xfce4-settings selected ("Applications→Settings→Appearance") linux-theme
"HighContrast (hicolor)" in black letters on a black background (i.e. nothing
is visible), the "Disk button panel" areas are displayed (only disk labels,
icons are normal, the hint field is normal), the "Disk List" area (only
disk labels, icons are normal, the hint field is normal), the "Status bar"
at the bottom of the left or right frame, "Directory path of the active panel"
to the left of the command line, the bottom line is the "Function Key bar"
and in some windows (not all). I haven't noticed anything in other applications
yet.
Under login "root" everything is displayed normally.
Under the login of the "ordinary user" I chose the theme "Adwaita" and
everything began to be displayed in DC normally, only in the upper and lower
panels the background became dark in Desktop Xfce.
Installed Debian 10.12.0. Installed DoubleCommander. Launched it. Everything
is displayed normally.
libgtk-3-0 version: 3.24.33
In Debian 11.2 and 11.3, Double Commander already has a problem with
the HighContrast theme.
Debian 11.3 has libgtk-3-0 version installed: 3.24.5-1.
For Debian 11.3 from "https://www.xfce-look.org; downloaded the light gray theme
"Redstar-greybird+gtk32" (https://www.xfce-look.org/p/1208044 )
("jayu-mon"), which is similar to "HighContrast", but unlike it is normally
displayed in DC.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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
Versions of packages libgtk-3-0 depends on:
ii adwaita-icon-theme 42.0-2
ii hicolor-icon-theme 0.17-2
ii libatk-bridge2.0-0 2.38.0-4
ii libatk1.0-0 2.38.0-1
ii libc62.33-7
ii libcairo-gobject21.16.0-5
ii libcairo21.16.0-5
ii libcolord2 1.4.6-1
ii libcups2 2.4.1op1-2
ii libepoxy01.5.10-1
ii libfontconfig1 2.13.1-4.4
ii libfribidi0 1.0.8-2.1
ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1
ii libglib2.0-0 2.72.1-1
ii libgtk-3-common 3.24.33-1
ii libharfbuzz0b2.7.4-1+b1
ii libpango-1.0-0 1.50.6+ds-2
ii libpangocairo-1.0-0 1.50.6+ds-2
ii libpangoft2-1.0-01.50.6+ds-2
ii libwayland-client0 1.20.0-1
ii libwayland-cursor0 1.20.0-1
ii libwayland-egl1 1.20.0-1
ii libx11-6 2:1.7.5-1
ii libxcomposite1 1:0.4.5-1
ii libxcursor1 1:1.2.1-1
ii libxdamage1 1:1.1.5-2
ii libxext6 2:1.3.4-1
ii libxfixes3 1:6.0.0-1
ii libxi6 2:1.8-1
ii libxinerama1 2:1.1.4-3
ii libxkbcommon01.4.0-1
ii libxrandr2 2:1.5.2-2+b1
ii shared-mime-info 2.2-1
Versions of packages libgtk-3-0 recommends:
ii libgtk-3-bin 3.24.33-1
ii librsvg2-common 2.52.5+dfsg-3+b1
Versions of packages libgtk-3-0 suggests:
ii gvfs 1.50.0-1
Versions of packages libgtk-3-0 is related to:
pn appmenu-gtk3-module
pn fcitx-frontend-gtk3
pn gcin-gtk3-immodule
pn gtk-vector-screenshot
pn gtk3-engines-xfce
pn gtk3-im-libthai
pn hime-gtk3-immodule
pn ibus-gtk3
pn imhangul-gtk3
ii libcanberra-gtk3-module 0.30-10
pn libcaribou-gtk3-module
pn libgtk3-nocsd0
pn maliit-inputcontext-gtk3
pn packagekit-gtk3-module
pn scim-gtk-immodule
pn topmenu-gtk3
pn uim-gtk3
pn uim-gtk3-immodule
-- no debconf information
Bug#1010528: exiv2 rm file.tiff does not remove XMP data
Package: exiv2 Version: 0.27.3-3+deb11u1 Severity: normal Dear Maintainer, On Debian Stretch and Buster I'm able to run 'exiv2 rm file.tiff' to remove all metadata from a TIFF file. However, on Debian Bullseye this only removes some metadata, notably the XMP data (the whole '...' XML stuff) remains in the resulting file. I also tried version 0.27.5-3 from unstable with the same result. If desired I can provide a test file, but it's quite trivial to build one with GIMP and its metadata editor. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages exiv2 depends on: ii libc62.31-13+deb11u3 ii libexiv2-27 0.27.3-3+deb11u1 ii libgcc-s110.2.1-6 ii libstdc++6 10.2.1-6 exiv2 recommends no packages. exiv2 suggests no packages. -- no debconf information
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
On Tue, 03 May 2022 18:22:37 +0200 Julian Andres Klode wrote: > So the way this usually goes is that distros also get notified, and > fixes are held back until a date (well hour really) coordinated by the > distros so everyone can release fixes at the same time, by way of > contacting the distros mailing list > (https://oss-security.openwall.org/wiki/mailing-lists/distros) or > individual email. I see, thank you for explaining. This is my first CVE rodeo. > Given that you are just working on this in your spare time and had not > had to deal with a CVE, I think MS should have at least helped ensure that > this is being communicated properly. That makes sense. Let me know if there's anything I can do to help. -Clayton signature.asc Description: PGP signature
Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail
On Tue, May 03, 2022 at 12:00:44PM -0400, ant wrote: i don't explicitly set that variable anywhere in any of my mutt profiles that i know of. unsetting that does allow mutt to send mail again using the 2.2.3-2 version so that did take care of the problem. thank you! :) I'm glad that fixed the problem. But I think it would be worth investigating a bit more where the assignment came from. From my most recent email (which I think arrived after you sent this one), it looks like the assignment, wherever it is, is using non-ascii quote-marks. Mutt is actually *including* the unicode curly-quotes as part of the method value. I think cyrus sasl must have been lax, but the gnu sasl code is picky about the value being legal. So it can't actually find a method '”cram-md5”' in the list 'PLAIN LOGIN CRAM-MD5' provided by the server. I think this bug can be closed, but I'd still like to hear if you found where it was coming from. :-) Thank you, -Kevin signature.asc Description: PGP signature
Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment
Hi Julian, Sorry for the silence, you're doing great work. On 03-05-2022 18:19, Julian Gilbey wrote: I've now done more searching, and the conclusion I've come to is that this is that this is the same issue discussed in https://wiki.debian.org/LXC/CGroupV2#LXC_containers_started_by_root (and in various other bug reports); by adding the two lines I wonder if you refer to https://bugs.debian.org/902394 https://bugs.debian.org/904732 Our infrastructure (where we don't experiences issues and are using the autopkgtest/debci/autodep8 packages from unstable on an otherwise stable system) runs lxc version 1:4.0.6-2. So that maybe limiting the changes further. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail
On Mon, 2 May 2022 20:35:13 -0700 "Kevin J. McCarthy" wrote: > On Mon, 02 May 2022 19:20:29 -0400 ant wrote: > > Package: mutt > > Version: 2.2.3-1 > > Just checking this is for 2.2.3-2. yes, because of the error i could not e-mail so i downgraded to 2.2.3-1 so i could get back to working mail. sorry for the confusion. > That update switched to the gsasl > library, which unfortunately needs some bugs worked out with its mutt > implementation. :-( > > From the debug log, it looks like you have $smtp_authenticators set. > What happens if you unset that variable, does authentication work in > that case? i don't explicitly set that variable anywhere in any of my mutt profiles that i know of. unsetting that does allow mutt to send mail again using the 2.2.3-2 version so that did take care of the problem. thank you! :) i just did a quick glance at the perl script muttprofile that i use and i see no reference to that variable being set either so i'm not sure where that set is coming from. > What if you explicitly set $smtp_authenticators to "login" > or "plain"? > > I'll try to see if I can duplicate the problem, but I don't have access > to a smtp server supporting cram-md5. Is the server you are using > accessible for me to try (and of course fail) authenticating with? > > -Kevin i can send that info via private e-mail if you'd still find that useful? but i think we've got the issue figured out... :) ant
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
On Tue, May 03, 2022 at 08:47:56AM -0700, Clayton Craft wrote: > Hi folks, > > > what is the story there? I don't believe any of those MS reports > > are actually (important) security issues, > > The issue is basically that microsoft and/or their customers are allowing > arbitrary code execution under a system user account (the same one that > normally > runs systemd-networkd). I can't speak for Debian, but other distros I've seen > restrict who can "own" the systemd-networkd service name on the system dbus > session to that user, so obviously if you allow that user to run arbitrary > code > then you're going to allow anything to bypass those restrictions. That's my understanding and hence why I asked them to publish a correction within 4 business days that this is caused by local misconfiguration and not a result of undisclosed security vulnerabilities. > > That's important in this context because networkd-dispatcher derives paths to > scripts it runs based on the messages it receives on dbus for the > systemd-networkd service. So if something else can "own" that name on the bus > then it can (before the sanitation patch in the latest version) get > networkd-dispatcher to run things located elsewhere. > > I should have been sanitizing input from dbus, which networkd-dispatcher does > now. But again, in every other configuration I've seen, the user who is > sending > messages under that service is a dedicated system user who is only running > systemd-networkd. > > > also why was this being disclosed publicly rather than responsibly? > > It was disclosed responsibly, as far as I understand the "responsible > disclosure" process to be. They contacted me privately about a month ago about > it, giving me enough time to come up with something to address it (I'm not > paid > to work on this :D) They also gave me a script to reproduce it shortly after > contacting me, which (after a lot of effort) I was able to trigger it a couple > of times in a VM running Arch Linux, but only after doing things that I > shouldn't have been doing in the "real world" > (e.g. sudo -u systemd-network ./foo) So the way this usually goes is that distros also get notified, and fixes are held back until a date (well hour really) coordinated by the distros so everyone can release fixes at the same time, by way of contacting the distros mailing list (https://oss-security.openwall.org/wiki/mailing-lists/distros) or individual email. Given that you are just working on this in your spare time and had not had to deal with a CVE, I think MS should have at least helped ensure that this is being communicated properly. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment
An update... On Mon, May 02, 2022 at 08:21:13AM +0100, Julian Gilbey wrote: > [...] > > Since autopkgtest-build-lxc doesn't allow a --logfile option, I > > attempted to start the container manually, using the command > > lxc-start -n autopkgtest-sid --logfile /tmp/lxc.log --logpriority INFO > > and got the following warnings and errors in the log file (I've > > excluded the INFO entries): > > > > > > [...] > > lxc-start autopkgtest-sid 20220501145802.681 ERRORcgfsng - > > cgroups/cgfsng.c:cg_legacy_set_data:2675 - No such file or directory - > > Failed to setup limits for the "devices" controller. The controller seems > > to be unused by "cgfsng" cgroup driver or not enabled on the cgroup > > hierarchy > > lxc-start autopkgtest-sid 20220501145802.681 ERRORcgfsng - > > cgroups/cgfsng.c:cgfsng_setup_limits_legacy:2742 - No such file or > > directory - Failed to set "devices.deny" to "a" > [...] I've now done more searching, and the conclusion I've come to is that this is that this is the same issue discussed in https://wiki.debian.org/LXC/CGroupV2#LXC_containers_started_by_root (and in various other bug reports); by adding the two lines lxc.cgroup.devices.allow = lxc.cgroup.devices.deny = to the file /var/lib/lxc/autopkgtest-unstable/config, I was able to start the container. But I'm running lxc version 1:4.0.11-1 and that wiki page says this change is unnecessary from version 4.0.2-1~1 onwards, which does not seem to be the case. lxc: I don't know whether the wiki is wrong or some change made in 4.0.2-1 has been reverted more recently. Either way, it would be great to resolve this discrepancy. autopkgtest-build-lxc: perhaps it would be good to add these lines at the end of the config file when the container is built, especially if the lxc folks can't fix this. Best wishes, Julian
Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail
On Mon, 2 May 2022 20:35:13 -0700 "Kevin J. McCarthy" wrote: I'll try to see if I can duplicate the problem, but I don't have access to a smtp server supporting cram-md5. Is the server you are using accessible for me to try (and of course fail) authenticating with? I've just noticed one funny thing in your debug log: [2022-05-02 19:11:00] smtp_authenticate: Trying method ”cram-md5” The method name should not include any kind of quoting, and those seem to be non-ascii quote marks. I wonder if you've accidentally copy/pasted non-ascii quotes in your muttrc 'set smtp_authenticators' line. Try deleting the quote marks and manually re-type ascii double-quote (or single-quotes) around the value: set smtp_authenticators="cram-md5" -Kevin signature.asc Description: PGP signature
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
Fixed with attached patch.
--
see shy jo
From 43701759a32e38613c61de6dc923c24069f435d6 Mon Sep 17 00:00:00 2001
From: Joey Hess
Date: Tue, 3 May 2022 12:12:25 -0400
Subject: [PATCH] disable shellescape for rsync 3.2.4
rsync 3.2.4 broke backwards-compatability by preventing exposing filenames
to the shell. Made the rsync and gcrypt special remotes detect this and
disable shellescape.
An alternative fix would have been to always set RSYNC_OLD_ARGS=1.
Which would avoid the overhead of probing rsync --help for each affected
remote. But that is really very fast to run, and it seemed better to switch
to the modern code path rather than keeping on using the bad old code path.
Sponsored-by: Tobias Ammann on Patreon
---
CHANGELOG | 3 +++
Remote/GCrypt.hs | 3 ++-
Remote/Rsync.hs| 27 ++-
doc/special_remotes/rsync.mdwn | 15 ---
4 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/CHANGELOG b/CHANGELOG
index 263da8e6e..6f53e3e1a 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -11,6 +11,9 @@ git-annex (10.20220323) UNRELEASED; urgency=medium
* Fix test failure on NFS when cleaning up gpg temp directory.
* Fix a build failure with ghc 9.2.2.
Thanks, gnezdo for the patch.
+ * rsync 3.2.4 broke backwards-compatability by preventing exposing
+filenames to the shell. Made the rsync and gcrypt special remotes
+detect this and disable shellescape. Closes: #1010397
-- Joey Hess Mon, 28 Mar 2022 14:46:10 -0400
diff --git a/Remote/GCrypt.hs b/Remote/GCrypt.hs
index 9662e75d4..0b120806a 100644
--- a/Remote/GCrypt.hs
+++ b/Remote/GCrypt.hs
@@ -130,7 +130,8 @@ gen' r u c gc rs = do
cst <- remoteCost gc $
if repoCheap r then nearlyCheapRemoteCost else expensiveRemoteCost
let (rsynctransport, rsyncurl, accessmethod) = rsyncTransportToObjects r gc
- let rsyncopts = Remote.Rsync.genRsyncOpts c gc rsynctransport rsyncurl
+ protectsargs <- liftIO Remote.Rsync.probeRsyncProtectsArgs
+ let rsyncopts = Remote.Rsync.genRsyncOpts protectsargs c gc rsynctransport rsyncurl
let this = Remote
{ uuid = u
, cost = cst
diff --git a/Remote/Rsync.hs b/Remote/Rsync.hs
index 81d60311e..e7e9ff740 100644
--- a/Remote/Rsync.hs
+++ b/Remote/Rsync.hs
@@ -16,7 +16,8 @@ module Remote.Rsync (
withRsyncScratchDir,
rsyncRemoteConfigs,
genRsyncOpts,
- RsyncOpts
+ RsyncOpts,
+ probeRsyncProtectsArgs,
) where
import Annex.Common
@@ -36,6 +37,7 @@ import Remote.Rsync.RsyncUrl
import Crypto
import Utility.Rsync
import Utility.CopyFile
+import Utility.Process.Transcript
import Messages.Progress
import Utility.Metered
import Types.Transfer
@@ -74,7 +76,8 @@ gen r u rc gc rs = do
cst <- remoteCost gc expensiveRemoteCost
(transport, url) <- rsyncTransport gc $
fromMaybe (giveup "missing rsyncurl") $ remoteAnnexRsyncUrl gc
- let o = genRsyncOpts c gc transport url
+ protectsargs <- liftIO probeRsyncProtectsArgs
+ let o = genRsyncOpts protectsargs c gc transport url
let islocal = rsyncUrlIsPath $ rsyncUrl o
return $ Just $ specialRemote c
(fileStorer $ store o)
@@ -124,6 +127,18 @@ gen r u rc gc rs = do
, remoteStateHandle = rs
}
+-- | Since 3.2.4, rsync protects filenames from being exposed to the shell.
+newtype RsyncProtectsArgs = RsyncProtectsArgs Bool
+
+probeRsyncProtectsArgs :: IO RsyncProtectsArgs
+probeRsyncProtectsArgs = do
+ (helpoutput, _) <- processTranscript "rsync" ["--help"] Nothing
+ -- The --old-args option was added to disable the new arg
+ -- protection, so use it to detect when that feature is supported
+ -- by rsync, rather than parsing versions.
+ return (RsyncProtectsArgs $ "--old-args" `isInfixOf` helpoutput)
+
+
-- Things used by genRsyncOpts
rsyncRemoteConfigs :: [RemoteConfigFieldParser]
rsyncRemoteConfigs =
@@ -131,15 +146,17 @@ rsyncRemoteConfigs =
(FieldDesc "set to no to avoid usual shell escaping (not recommended)")
]
-genRsyncOpts :: ParsedRemoteConfig -> RemoteGitConfig -> Annex [CommandParam] -> RsyncUrl -> RsyncOpts
-genRsyncOpts c gc transport url = RsyncOpts
+genRsyncOpts :: RsyncProtectsArgs -> ParsedRemoteConfig -> RemoteGitConfig -> Annex [CommandParam] -> RsyncUrl -> RsyncOpts
+genRsyncOpts (RsyncProtectsArgs protectsargs) c gc transport url = RsyncOpts
{ rsyncUrl = url
, rsyncOptions = appendtransport $ opts []
, rsyncUploadOptions = appendtransport $
opts (remoteAnnexRsyncUploadOptions gc)
, rsyncDownloadOptions = appendtransport $
opts (remoteAnnexRsyncDownloadOptions gc)
- , rsyncShellEscape = fromMaybe True (getRemoteConfigValue shellEscapeField c)
+ , rsyncShellEscape = if protectsargs
+ then False
+ else fromMaybe True (getRemoteConfigValue shellEscapeField c)
}
where
appendtransport l = (++ l) <$> transport
diff --git a/doc/special_remotes/rsync.mdwn b/doc/special_remotes/rsync.mdwn
index 96e452b10..e9f54dc68 100644
--- a/doc/special_remotes/rsync.mdwn
+++ b/doc/special_remotes/rsync.mdwn
@@ -26,13
Bug#1010372: [debian-mysql] Bug#1010372: mysql-8.0: Should mysql-8.0 be removed from unstable?
Hi Salvatore, On Fri, Apr 29, 2022 at 09:52:04PM +0200, Salvatore Bonaccorso wrote: > Should mysql-8.0 be dropped completely from the archive or is there > still interest in keeping in in unstable? I think this is a dupe of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004180? Was asking again intentional? My answer is the same - we'd like to keep mysql-8.0 in unstable and are working on updating unstable and getting Ubuntu back into sync against Debian. At Canonical, I am onboarding a colleague who will be working on this. Prompted again by you, we just set ourselves a goal of having this done by the end of the month, if that's OK with you? Thanks, Robie signature.asc Description: PGP signature
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
Hi folks, > what is the story there? I don't believe any of those MS reports > are actually (important) security issues, The issue is basically that microsoft and/or their customers are allowing arbitrary code execution under a system user account (the same one that normally runs systemd-networkd). I can't speak for Debian, but other distros I've seen restrict who can "own" the systemd-networkd service name on the system dbus session to that user, so obviously if you allow that user to run arbitrary code then you're going to allow anything to bypass those restrictions. That's important in this context because networkd-dispatcher derives paths to scripts it runs based on the messages it receives on dbus for the systemd-networkd service. So if something else can "own" that name on the bus then it can (before the sanitation patch in the latest version) get networkd-dispatcher to run things located elsewhere. I should have been sanitizing input from dbus, which networkd-dispatcher does now. But again, in every other configuration I've seen, the user who is sending messages under that service is a dedicated system user who is only running systemd-networkd. > also why was this being disclosed publicly rather than responsibly? It was disclosed responsibly, as far as I understand the "responsible disclosure" process to be. They contacted me privately about a month ago about it, giving me enough time to come up with something to address it (I'm not paid to work on this :D) They also gave me a script to reproduce it shortly after contacting me, which (after a lot of effort) I was able to trigger it a couple of times in a VM running Arch Linux, but only after doing things that I shouldn't have been doing in the "real world" (e.g. sudo -u systemd-network ./foo) > The fixes for the alleged permission issue also only handles one > parent directory and classic permissions, but not any other > (grand)parents or ACLs. Ya, I'll admit that I'm not entirely sure if that particular change is all that useful... and I believe that it's up to distros to configure ACLs on the system. I would welcome any improvements to attempt to verify ACLs. So to recap: 1) if you don't re-use the systemd-network user (or whatever user your distro restricts the networkd dbus service name to) for running other things besides systemd-networkd, then this shouldn't be a problem. 2) If you do use the systemd-network user to run whatever, then networkd-dispatcher will now sanitize messages from dbus from the networkd dbus "service" (regardless of who/what has managed to own the name on the bus), so that it won't run things. This was shown by Microsoft to completely mitigate the issue. 3) system admins can still create symlinks to scripts outside of the config directories (which should be owned by root) the app searches, so it's still possible for system admins to footgun themselves, but networkd-dispatcher will at least *try* a little bit better now to prevent running things that are writeable by non-root users. -Clayton On Tue, 03 May 2022 14:12:14 +0200 Julian Andres Klode wrote: > Hi Clayton (CC), > > what is the story there? I don't believe any of those MS reports > are actually (important) security issues, also why was this being > disclosed publicly rather than responsibly? > > The fixes for the alleged permission issue also only handles one > parent directory and classic permissions, but not any other > (grand)parents or ACLs. > > On Tue, May 03, 2022 at 01:21:12PM +0200, Julian Andres Klode wrote: > > On Thu, Apr 28, 2022 at 01:53:58PM +0200, Salvatore Bonaccorso wrote: > > > Source: networkd-dispatcher > > > Version: 2.1-2 > > > Severity: grave > > > Tags: security upstream > > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > > > > > > > Hi, > > > > > > The following vulnerabilities were published for networkd-dispatcher. > > > > > > CVE-2022-29799[0] and CVE-2022-29800[1]. > > > > > > If you fix the vulnerabilities please also make sure to include the > > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > > > I do not believe these are vulnerabilities. Microsoft claims a > > vulnerability exists if there is vulnerable code running under > > the systemd-network user, and claims that apt and epmd run under > > such user, but neither has communicated how those processes are > > vulnerable, nor why they would run under that user. > > > > It's likely that their tool is a confused deputy, running on a > > system with broken containers where container _apt and epmd > > users are mapped to the same UID as the host systemd-network > > (which still would not give them access to the bus), or it's > > a FUD smear campaign. > > > > Microsoft also claims that a vulnerability exists if scripts > > are writable by the user, however the directory is owned by > > root, so any scripts in there had to be written there by > > root. As such, that is a local admin choice to allow that > > user to
Bug#1009245: ruby-autoprefixer-rails: broken build (TypeError: Cannot read property 'env' of undefined)
On 03/05/2022 15:46, Pirate Praveen wrote:
On Tue, 12 Apr 2022 23:59:16 +0530 Akshay S Dinesh
wrote:
> There is a possibility that this is related to the execjs version.
>
>
https://github.com/ai/autoprefixer-rails/issues/203#issuecomment-838512342
>
>
> On the other hand, the autoprefixer.js from the gem (about 1 MB) and the
> autoprefixer.js that's generated through build from the upstream repo
> (about 8 MB) seems to be different. This is unexplained by the dev.
>
>
I think one of the build dependency with major version difference is
causing the broken build.
"@rollup/plugin-commonjs": "^17.0.0", vs 21.0.1+repack-1
"@rollup/plugin-node-resolve": "^11.0.1", vs 13.2.1+ds-1
"@rollup/plugin-replace": "^2.3.3", vs 3.0.0+ds+~2.2.0-1
We should try the upstream build with these newer versions and see if
the error can be reproduced.
I enabled test (uvu), passed. So JS part seems not broken.
The error "Cannot read property 'env' of undefined" seems related to
this line (generated vendor/autoprefixer.js):
> if (process.env.NODE_DEBUG) {
So I don't understand what is wrong here
It seems to have no test for ruby part:
> Run tests for ruby3.0: no test suite!
Maybe we can do something here ? "spec" directory seems related to ruby test
Bug#1010527: RFS: c-evo-nh/1.3.0.420+dfsg-1 -- Empire Building Game, C-evo: New Horizons
Package: sponsorship-requests Severity: wishlist Dear Mentors, I am looking for a sponsor for my package "c-evo-nh": * Package name : c-evo-nh Version : 1.3.0.420+dfsg-1 Upstream Author : Chronos * URL : https://app.zdechov.net/c-evo * License : GPL-2+, CC-BY-3.0, CC0-1.0, CC-BY-SA-3.0-US Section : games The source builds the following binary packages: c-evo-nh - Empire Building Game, C-evo: New Horizons c-evo-gtk2 - Empire Building Game (GTK2), C-evo: New Horizons c-evo-qt5 - Empire Building Game (Qt5), C-evo: New Horizons c-evo-stdai - Empire Building Game (AI module), C-evo: New Horizons c-evo-data - Empire Building Game (data files), C-evo: New Horizons c-evo-qt5-graphics-patch - Empire Building Game (qt5 graphics patch), C-evo: New Horizons To access further information about this package, please visit the following URL: https://mentors.debian.net/package/c-evo-nh/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/c-evo-nh/c-evo-nh_1.3.0.420+dfsg-1.dsc Changes for the initial release: c-evo-nh (1.3.0.420+dfsg-1) unstable; urgency=medium . * Initial release for Debian. Closes: #968495 C-evo is a Civilization style game, inspired by Civ II. Originally written in Delphi for Windows, it has been ported to FPC/Lazarus for Linux. It will appeal to players of FreeCiv who fancy a new challenge. There are several patches to the upstream version. These focus on policy for debian packaging, bug fixes, and also larger buttons, support for larger maps and work on the QT5 version which is ongoing. Built binaries available here https://build.opensuse.org/package/show/home:PeterBBB/c-evo The 420 in upstream version is the SVN revision number I used. https://app.zdechov.net/c-evo/browser/trunk Regards, -- Peter Blackman
Bug#1010397: Fwd: Bug#1010397: git-annex sync fails in rsync remotes with rsync 3.2.4-1
> > git-annex enableremote foo shellescape=no I've confirmed that this workaround works. Also, the client's version of rsync is what matters. 3.2.3 client and 3.2.4 server does not have the problem. -- see shy jo signature.asc Description: PGP signature
Bug#740893: ‘libjs-jquery-hotkeys’ 0.2.0 works with ‘python-coverage’
Control: severity -1 important Hi, On Sat, 16 Mar 2019 21:57:46 +0100 Paul Gevers wrote: If I understand this bug properly, I think Debian could/should have two versions of libjs-jquery-hotkeys, one for each upstream. This issue is now 7 years old, is part of all currently supported suites and I don't think it's smart to revert the libjs-jquery-hotkeys package back to the other upstream, as we'll have similar issues the other way around. Hence, I am lowering the severity as I believe the solution forward lies in a new source package that provides the other fork of this code. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1010526: libxml2: CVE-2022-29824: integer overflows in xmlBuf and xmlBuffer
Source: libxml2 Version: 2.9.13+dfsg-1 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for libxml2. CVE-2022-29824[0]: | In libxml2 before 2.9.14, several buffer handling functions in buf.c | (xmlBuf*) and tree.c (xmlBuffer*) don't check for integer overflows. | This can result in out-of-bounds memory writes. Exploitation requires | a victim to open a crafted, multi-gigabyte XML file. Other software | using libxml2's buffer functions, for example libxslt through 1.1.35, | is affected as well. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-29824 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29824 [1] https://gitlab.gnome.org/GNOME/libxml2/-/commit/2554a2408e09f13652049e5ffb0d26196b02ebab Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1010521: RFS: anacron/2.3-32 [O] -- cron-like program that doesn't go by time
Hi Lance, On Tue, May 03, 2022 at 01:57:46PM +, Lance Lin wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I realize that the upstream for anacron has not been updated in a very long > time, but I am on the Debian Med team and one of our packages depends on it. > There are also several open bugs I hope to work on. The changes in this RFS are quite minimial, it would be cool if you could some bug triaging and include some fixed of the open bus in the BTS, just to fill this RFS with a bit of content ;-) Also, please change the orphaning bug to an Intend-To-Adopt one to announce your intentions properly. (unrelated to this RFS: Did you see #998557?) -- tobi V > I am looking for a sponsor for my package "anacron": > > * Package name: anacron >Version : 2.3-32 >Upstream Author : Itai Tzur > * URL : http://sourceforge.net/projects/anacron/ > * License : GNU > * Vcs : https://salsa.debian.org/debian/anacron >Section : admin > > The source builds the following binary packages: > > anacron - cron-like program that doesn't go by time > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/anacron/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/a/anacron/anacron_2.3-32.dsc > > Changes since the last upload: > > anacron (2.3-32) unstable; urgency=medium > . >[ Debian Janitor ] >* Remove constraints unnecessary since buster: > + anacron: Drop versioned constraint on lsb-base in Depends. > + Remove 2 maintscript entries from 1 files. >* Bump debhelper from old 12 to 13. > + debian/rules: Drop --fail-missing argument to dh_missing, which is now > the >default. >* Set upstream metadata fields: Name, Repository. >* Avoid explicitly specifying -Wl,--as-needed linker flag. > . >[ Lance Lin ] >* d/control: Removed debutils dep, added new maintainer (Closes: #897138) > > Regards, > -- > > Lin Qigang > > GPG Fingerprint: 8CAD 1250 8EE0 3A41 7223 03EC 7096 F91E D75D 028F
Bug#982766: [Pkg-javascript-devel] Bug#982766: Bug#982766: node-webpack: remove dependency on node-uglifyjs-webpack-plugin
Control: block 977311 by -1 On Sun, 14 Mar 2021 11:44:31 +0530 Pirate Praveen wrote: 2. Yadd already discussed about node-uglifyjs-webpack-plugin with release team. I don't recall that discussion now, can somebody please add a pointer to this bug report such that we can judge what to do with this RC bug for bookworm? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#951161: O: distorm3 -- powerful disassembler library for x86/AMD64 binary streams
Hi Lance, I was wondering if you still intend to adopt this package, as it seems no activity since a while? -- tobi
Bug#1002381: ipyparallel: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar'
Control: reassign -1 src:nbconvert 6.1.0-1 Control: fixed -1 6.3.0-1 Control: affects -1 src:ipyparallel On Mon, 11 Apr 2022 11:48:56 +0200 "Michael R. Crusoe" wrote: Package: nbconvert Version: 6.3.0-1 Real problem was in nbconvert, which has been fixed since nbconvert 6.3.0-1 So, to avoid confusing our tooling, let's reassign to the right package then. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1010524: RFP: hut -- A CLI tool for sr.ht
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: hut Version : 0.1.0 Upstream Author : Simon Ser * URL : https://sr.ht/~emersion/hut/ * License : AGPLv3 only Programming Lang: Go Description : A CLI tool for sr.ht A command line interface to sr.ht services. SourceHut is a fully FLOSS development platform and this tool allows you to interact with the various SourceHut services directly from the command line, like builds, git, hg, lists, meta, pages, paste and todo. For questions/patches/etc: https://lists.sr.ht/~emersion/hut-dev Bug reports: https://todo.sr.ht/~emersion/hut It may be a good idea if this were to be maintained in some kind of sourcehut team as there are several other RFP bug for sr.ht services. #920873 RFP: python3-srht -- core sr.ht shared code #921407 RFP: python-srht-scm -- Shared support code for sr.ht source control services #921485 RFP: python-srht-git -- sr.ht git services #921604 RFP: python-srht-meta -- sr.ht core account services This tool is NOT dependent on any of those being packaged though. -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYnFGWwAKCRDXblvOeH7b binRAQCL6mQcIwQ46ORQJEJzLm6ArCCBRBEVSIcMcYERlVFwHwD/WxExdL8bvI9a DDVWQb1zc5YVd8FbcQn93+pq6cHa+Qs= =Qum9 -END PGP SIGNATURE-
Bug#1010494: Re: Bug#1010494: RFS: usbrelay/1.0-1 -- USB HID relay driver
Control: tags -1 moreinfo Control: owner -1 ! Hi Michael, (@Jan: would be nice if you could chimein in regards to this RFS) On Tue, May 03, 2022 at 12:28:39PM +0200, Michal Sojka wrote: > Hi Tino, > > thanks for the feedback. > > > the package triggers several lintian warnings. I guess most of them were > > already present in old version. But at least the > > package-contains-no-arch-dependent-files warning for the new usbrelayd > > package can be trivially fixed by setting its arch to "all" instead of > > "any". > > I've removed the package-contains-no-arch-dependent-files warning and > reuploaded (https://mentors.debian.net/package/usbrelay/). I'm a bit > confused that when I run lintian locally, I get less warnings that what > is shown in mentors.debian.net. Are there some switches that I need to > run lintian with to see all relevant warnings? > > I'm also not sure about NMU warnings. Shall I mention NMU in the > changelog or it will be done by the one who will really upload the > package? no, the sponsor usually does not modfify the package. Regarding the NMU, see below, as our mails crossed... > Best regards, > -Michal Hi Michael, On Mon, May 02, 2022 at 09:44:59PM +0200, Michal Sojka wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for package "usbrelay": > > * Package name: usbrelay >Version : 1.0-1 >Upstream Author : Darryl Bond > * URL : https://github.com/darrylb123/usbrelay > * License : GPL-2+, CC-BY-SA-4.0 > * Vcs : https://salsa.debian.org/wentasah/usbrelay >Section : electronics > > > The package is officially maintained by DD Jan Dittberner, but he seems > to be no longer active, at least with this package. I contribute to the > development of the upstream package and from time to time, users report > problems that are caused by too old version of the package in the Debian > archive. Having more recent version in Debian would be beneficial. unfortunatly those bugs were not reported in the Debian bug tracker... Some thoughts about procedures: Jan is generally active (uploaded a package last month), but is in the LowNMU list [1] and the package is in the salsa Debian group [2]. Using the "LowNMU" procedure means that your package needs to be a NMU [3], but an NMU requires that the upload fixes bugs reported in the Debian BTS and a NMU limits the changes you are allowed to do in a package. You can of course file the bugs you fix in your changes in the Debian BTS (including a "please package the new upstream version where you can list all the problems with the old version.), but some changes will still be out of scope for an NMU. The salsa Debian group is technically a Team upload [4] and team-uploads do not have restrictions on what to upload, so I guess this is an viable approach. The third option is to adopt the package -- either by an explicit OK to do from Jan or via the ITS procedure [5]. With that, you will become (co-)maintainer of the package, but that implies some kind of promise to also look after the package in the future. This is of course the best outcome for Debian and your project, but also means a commitment in maintaing the package. [1] https://wiki.debian.org/LowThresholdNmu [2] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#collaborative-maint␆bib [3] https://wiki.debian.org/NonMaintainerUpload https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus [4] https://wiki.debian.org/TeamUpload [5] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging https://wiki.debian.org/PackageSalvaging (The "conservative" criterias are imho fulfilled: -::q open bugs, missing upstream releases, sourceful upload required, no visible activity on the package >6months) > The updated package is based on the version already in Debian and > introduces two additional binary packages to cover new functionality > provided by upstream. I tried to prepare the updated package as well as > I can, but this is my first attempt to prepare official Debian packaging > so I'm open to suggestions for improvement. The packaging is inspired by > official documentation as well as by Fedora packaging, which was created > recently by other contributors. > > The source builds the following binary packages: > > usbrelay - USB HID relay driver > python3-usbrelay - Python bindings for USB HID relay driver > usbrelayd - MQTT client for USB HID relay driver > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/usbrelay/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x >
Bug#826608: hfsprogs: Please switch to use libmd instead of OpenSSL's libcrypto
Hi Guillem! While I think this change is a sensible idea, I'm a bit hesitant to apply it as it changes quite a large number of source files. Are there any compelling reasons for not using OpenSSL? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#987972:
fixed 987972 3.6.7-1
Bug#1010453: closed by Debian FTP Masters (reply to Doug Torrance ) (Bug#1010453: fixed in macaulay2 1.19.1+ds-9)
On Mon 02 May 2022 12:11:48 AM EDT, Paul Gevers wrote: Hi, On 02-05-2022 02:39, Debian Bug Tracking System wrote: macaulay2 (1.19.1+ds-9) unstable; urgency=medium . * debian/tests/control - Mark package-tests as flaky since it regularly times out on armhf (Closes: #1010453). Hmmm. May I recommend something else? Marking autopkgtests that regularly time out is a solution that has a relative high price on the infrastructure. These tests are still run (until they time out), while they don't influencing migration of any package if the package contain more than one autopkgtest. Marking tests flaky is nearly only useful if a human is regularly going to look at the results and does something with it. To be honest, I'm not expecting that here (but let me know if I'm making a wrong assumption here). Instead, I recommend to not run the test at all on armhf if we're going to ignore the result there (successful runs also take long), but use it normally on all other architectures. There's the "Architecture" field available in debian/tests/control that can be used to achieve that in a correct way. It understands the regular syntax so "!armhf" should suffice. That seems like a good solution -- thanks for the suggestion! I'll switch to this on the next upload (likely after Macaulay2 1.20 is released in a few weeks). Doug signature.asc Description: PGP signature
Bug#1009245: ruby-autoprefixer-rails: broken build (TypeError: Cannot read property 'env' of undefined)
On the other hand, the autoprefixer.js from the gem (about 1 MB) and the autoprefixer.js that's generated through build from the upstream repo (about 8 MB) seems to be different. This is unexplained by the dev. I was comparing an older version of the gem actually. Please ignore this comment. On the other hand, I have found that the node-resolve is somehow resolving util.js from the system (/usr/share/nodejs) instead of node_modules (possibly related to the patch we're applying) and that causes process.env to be read directly (without handling it as if it is inside browser)
Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [ITP] -- Open the system file manager and optionally select files in it
On 2022-05-03 10:09:12, Antoine Beaupré wrote: > On 2022-05-02 21:53:03, Tino Mettler wrote: >> Hi, >> >> I uploaded a new package to my mentors account. >> >> dget -x >> https://mentors.debian.net/debian/pool/main/s/show-in-file-manager/show-in-file-manager_1.1.4-1.dsc >> >> The only change to the last version is a >> debian/tests/autopkgtest-pkg-python.conf >> file. Now the autopkgtest-pkg-python test passes. > > I don't see that change in the above source package, somehow. > > but i'll test the git repo instead. Nevermind that, I was in the wrong directory, sorry for the noise. Everything looks good, i'll upload shortly. -- The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.- Friedrich Nietzsche
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
On 2022-05-03 10:20, Michael Tokarev wrote: 03.05.2022 17:08, Simon Deziel wrote: On 2022-05-03 07:44, Michael Tokarev wrote: Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied I'm assuming the way to reproduce this is with `chroot: "/etc/unbound"`. Having a daemon write to /etc/ feels wrong, IMHO. The profile was designed with the following in mind IIRC: Oh. Yes, you're right, I haven't noticed the difference here between unbound message and kernel message. This explains why I can't fix it by adding stuff for /var/lib/unbound to aparmor.d/. Yes, I chroot it to /etc/unbound, with /var/lib/unbound bind-mounted to /etc/unbound/var/... - the way it was supposed to work by upstream, apparently. The problem with chrooting it to /var/lib/unbound is the copy of all the configuration which must not be done by root into nonroot-owned untrusted directory, and because you lose unbound-control reload. Could a bind mount of the control socket make it work? Similar to systemd's notify socket. Copying configs is bad, I think. Well, the way unbound chroots feels awkward to me. I don't understand why stuff needs to be present in the chroot. I maybe naively think that unbound-control could have supplied fresh configs to the running chroot'ed daemon without having to move files/sockets/pid/etc around. # cat /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "/var/lib/unbound" I just tested the above and it seems to work. Yes, this one works (with the above comment/restriction). And yes, adding /etc/unbound/var/lib/unbound/* stuff to apparmor profile seems to be working as well, - something which I missed initially, - that's why I filed this bugreport instead of fixing it right away, - b/c I weren't able to figure out why it doesn't work after my attempts to fix the profile. If you'd like to have your bind-mount setup to work, I'm happy to add the missing apparmor bits to https://salsa.debian.org/dns-team/unbound/-/merge_requests/19 Thanks, Simon
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
03.05.2022 17:08, Simon Deziel wrote: On 2022-05-03 07:44, Michael Tokarev wrote: Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied I'm assuming the way to reproduce this is with `chroot: "/etc/unbound"`. Having a daemon write to /etc/ feels wrong, IMHO. The profile was designed with the following in mind IIRC: Oh. Yes, you're right, I haven't noticed the difference here between unbound message and kernel message. This explains why I can't fix it by adding stuff for /var/lib/unbound to aparmor.d/. Yes, I chroot it to /etc/unbound, with /var/lib/unbound bind-mounted to /etc/unbound/var/... - the way it was supposed to work by upstream, apparently. The problem with chrooting it to /var/lib/unbound is the copy of all the configuration which must not be done by root into nonroot-owned untrusted directory, and because you lose unbound-control reload. Copying configs is bad, I think. # cat /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "/var/lib/unbound" I just tested the above and it seems to work. Yes, this one works (with the above comment/restriction). And yes, adding /etc/unbound/var/lib/unbound/* stuff to apparmor profile seems to be working as well, - something which I missed initially, - that's why I filed this bugreport instead of fixing it right away, - b/c I weren't able to figure out why it doesn't work after my attempts to fix the profile. HTH, Definitely, thank you Simon! /mjt
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
On 2022-05-03 07:44, Michael Tokarev wrote: Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied I'm assuming the way to reproduce this is with `chroot: "/etc/unbound"`. Having a daemon write to /etc/ feels wrong, IMHO. The profile was designed with the following in mind IIRC: # cat /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "/var/lib/unbound" I just tested the above and it seems to work. HTH, Simon
Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [ITP] -- Open the system file manager and optionally select files in it
On 2022-05-02 21:53:03, Tino Mettler wrote: > Hi, > > I uploaded a new package to my mentors account. > > dget -x > https://mentors.debian.net/debian/pool/main/s/show-in-file-manager/show-in-file-manager_1.1.4-1.dsc > > The only change to the last version is a > debian/tests/autopkgtest-pkg-python.conf > file. Now the autopkgtest-pkg-python test passes. I don't see that change in the above source package, somehow. but i'll test the git repo instead. -- La destruction de la société totalitaire marchande n'est pas une affaire d'opinion. Elle est une nécessité absolue dans un monde que l'on sait condamné. Puisque le pouvoir est partout, c'est partout et tout le temps qu'il faut le combattre. - Jean-François Brient, de la servitude moderne
Bug#1010422: transition: r-api-bioc-3.15
On Tue, May 03, 2022 at 04:04:22PM +0200, Graham Inggs wrote: > Control: tags -1 + moreinfo > > I am now trying to get ggplot2 and friends in testing. Please give > > it time until this weekend to migrate after which I will remove > > my hacks and re-upload. > > Please also look at rmatrix, it is a build-dependency of several > r-bioc-* packages. That'd get in once ggplot2 and friends transition. Should be soonish. > > Let's start bioc transition after this is done. > > Please remove the moreinfo tag once you are ready. Sure, thanks Graham! -- Best, Nilesh signature.asc Description: PGP signature
Bug#1010422: transition: r-api-bioc-3.15
Control: tags -1 + moreinfo Hi Nilesh On Tue, 3 May 2022 at 15:51, Nilesh Patra wrote: > > Andreas Tille wrote: > >> >I guess your recent upload of 0.1.2.1-3 is supposed to fix this and > >> >is intended to enable the migration, right? > >> > > >> > >> Yes, let's wait until r-base migrates, I guess it'd take a day or two > >> maybe. > >> Anyway we need to wait for bioc transition until we get a thumbs up from > >> release team. > > > > Sure. I guess it is sensible to not fiddle around with R package > > updates for the moment. > > I am now trying to get ggplot2 and friends in testing. Please give > it time until this weekend to migrate after which I will remove > my hacks and re-upload. Please also look at rmatrix, it is a build-dependency of several r-bioc-* packages. > Let's start bioc transition after this is done. Please remove the moreinfo tag once you are ready. Regards Graham
Bug#1010522: new upstream release (0.4.0)
Package: trocla Severity: wishlist There's a new upstream release available (0.4.0) that we need to package, but it needs a new Moneta upload (#1010286) otherwise tests fail. -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 trocla depends on: ii ruby 1:2.7+2 ii ruby-bcrypt3.1.16-1 ii ruby-highline 2.0.3-2 ii ruby-moneta1.0.0-9 trocla recommends no packages. Versions of packages trocla suggests: ii puppet 5.5.22-2
Bug#976118: Bug Status?
On 11 Feb 2022 10:32:06 +0100 Matthias Urlichs wrote: > Upstream appears to have merged the fix. Do you have a link to that fix? > Please consider upgrading this package. The latest upstream tag is v1.6.2 which is available in Testing/Unstable. Is the issue still present or is it fixed with that version? signature.asc Description: This is a digitally signed message part.
Bug#1009905: Problem persists with 18.0.1+10-1
Setting up ca-certificates-java (20190909) ... head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or directory /var/lib/dpkg/info/ca-certificates-java.postinst: line 101: java: command not found dpkg: error processing package ca-certificates-java (--configure): installed ca-certificates-java package post-installation script subprocess returned error exit status 127 dpkg: dependency problems prevent configuration of openjdk-18-jre-headless:amd64: openjdk-18-jre-headless:amd64 depends on ca-certificates-java (>= 20190405~); however: Package ca-certificates-java is not configured yet. dpkg: error processing package openjdk-18-jre-headless:amd64 (--configure): dependency problems - leaving unconfigured Processing triggers for libc-bin (2.33-7) ... Processing triggers for ca-certificates (20211016) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... /etc/ca-certificates/update.d/jks-keystore: 82: java: not found E: /etc/ca-certificates/update.d/jks-keystore exited with code 1. done. Processing triggers for sgml-base (1.30) ... Setting up libfontconfig1:amd64 (2.13.1-4.4) ... Processing triggers for libc-bin (2.33-7) ... Errors were encountered while processing: ca-certificates-java openjdk-18-jre-headless:amd64
Bug#998041: RFS: makedeb/11.0.1-1 [ITP] -- The modern packaging tool for Debian archives
Package: sponsorship-requests Followup-For: Bug #998041 Control: tags -1 moreinfo Lintian's still unhappy: (Please integrate lintian in your workflow, as those lintian remarks had been found in previous reviews already.) I've added some remarks. E: makedeb: extended-description-is-empty W: makedeb: description-synopsis-starts-with-article W: makedeb source: no-debian-changes W: makedeb: no-manual-page usr/bin/makedeb-makepkg W: makedeb: no-manual-page usr/bin/makepkg-template W: makedeb: script-not-executable [etc/makepkg.conf] -- Remark: possibly this file should not be a script! X: makedeb source: debian-watch-does-not-check-gpg-signature [debian/watch] P: makedeb source: package-uses-old-debhelper-compat-version 12 P: makedeb source: silent-on-rules-requiring-root [debian/control] P: makedeb source: trailing-whitespace debian/rules (line 4) P: makedeb source: trailing-whitespace debian/rules (line 5) P: makedeb source: trailing-whitespace debian/rules (line 6) P: makedeb source: update-debian-copyright 2021 vs 2022 [debian/copyright:11] X: makedeb source: upstream-metadata-file-is-missing Beside: - /etc/makepkg.conf: -you are packaging arch:all but have hard-coded arch-dependent settings for amd64. Is this intentional? -I don't think that should be a script needing a shebang, should it? - d/makedeb-docs.docs d/README d/README.source should not be needed (and they do not contain useful information) - Somewhere in the documentation it still says "the modern packaging tool for Debian archives", which needs still to be changed, accordingly to your message in #998039#32. Disclaimer: I'm not going to sponsor this package. I believe that makedeb creates packages in a way that might cause problems for our users. (e.g as laid out in 998039#22; it makes dependency handling a user-problem, which is a core task of a packaging management system. So I thinkg it needs still some development before it should be uploaded. I was playing with makedeb, but unfortunatly with very mixed result: For example, I test-built "moonlight-qt" (selected because it was on the frontpage of the homepage [¹] and not arch-all generates this Depends: line for the generated binary package: > Depends: libegl1-mesa-dev, libgl1-mesa-dev, libopus-dev, libqt5svg5-dev, > libsdl2-dev, libsdl2-ttf-dev, libssl-dev, libavcodec-dev, libva-dev, > libvdpau-dev, libxkbcommon-dev, qt5-qmake, qtbase5-dev, qtdeclarative5-dev, > qtquickcontrols2-5-dev, wayland-protocols, qml-module-qtquick-controls2, > qml-module-qtquick-layouts, qml-module-qtquick-window2, qml-module-qtquick2, > ffmpeg (note that it would also depend on qt5-default, but I had to edit it because this package is gone in sid, and I used a sid container for my tests.) Another package, zotero, claims "zotero is not available for the 'x86_64' architecture.**", and I found many others with the exact same problem... As those working using "x86_64" in the PKGBUILD and those which don't "amd64", makes me wonder if the PKGBUILD used or how it is parsed by makedeb is stable. Also, my i386 (on amd64 hardware -- Multiarch) chroot claims to be 64 bit... I guess there are bugs here... Also (IIRC gh (some github tool)) created an arch:all package which having arch-dependent binaries. (Frankly, I ran accross so many broken PKGBUILD recipes, all sorts of errors... Is there (automated) QA?) -- tobi [¹] https://mpr.makedeb.org/
Bug#1010520: debian-security-support: check-support-status uses desired state instead of current state
Package: debian-security-support
Version: 2020.06.21~deb10u1
Severity: normal
Dear Maintainer,
Used check-support-status to identify problematic packages. Tried to purge
them, but
could not due to dependencies. Went to confirm that problematic packages
were still listed, but they were not.
Modified source of check-support-status to use current state instead of
desired state
awk '($1=="install"){print}' |
becomes
awk '($3=="installed"){print}' |
This fixes problem as expected
jrd
-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename: buster
Architecture: armv7l
Kernel: Linux 5.10.103-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages debian-security-support depends on:
ii adduser3.118
ii debconf [debconf-2.0] 1.5.71+deb10u1
ii gettext-base 0.19.8.1-9
debian-security-support recommends no packages.
debian-security-support suggests no packages.
-- debconf information:
debian-security-support/earlyend:
debian-security-support/ended:
* debian-security-support/limited:
Bug#1010441: torbrowser-launcher fails to download browser bundle when launched for the first time
Package: torbrowser-launcher Version: 0.3.5-2 Followup-For: Bug #1010441 Dear Maintainer, I confirm the workaround suggested by Paul works. Not sure it is the best solution tough. Best, Alexandre -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-security') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages torbrowser-launcher depends on: ii ca-certificates20211016 ii gnupg 2.2.35-2 ii libdbus-glib-1-2 0.112-2 ii python33.10.4-1+b1 ii python3-gpg1.16.0-1.2 ii python3-packaging 21.3-1 ii python3-pyqt5 5.15.6+dfsg-1+b2 ii python3-requests 2.27.1+dfsg-1 ii python3-socks 1.7.1+dfsg-1 Versions of packages torbrowser-launcher recommends: pn tor Versions of packages torbrowser-launcher suggests: pn apparmor -- no debconf information
Bug#1010519: g++-12: compilation fails on riscv64 because of always_inline when using fmtlib
Package: g++-12
Version: 12-20220428-1
Severity: important
Dear Maintainer,
I have uploaded my package opm-common to experimental. Buildd shows that
compilation fails on riscv64 with the message:
In file included from /usr/include/fmt/format.h:48,
from
/<>/src/opm/input/eclipse/Deck/UDAValue.cpp:19:
/usr/include/fmt/core.h: In member function ‘void
Opm::UDAValue::assert_numeric() const’:
/usr/include/fmt/core.h:3117:31: error: inlining failed in call to
‘always_inline’ ‘std::string fmt::v8::format(format_string, T&& ...)
[with T = {const std::__cxx11::basic_string,
std::allocator >&}]’: target specific option mismatch
3117 | FMT_NODISCARD FMT_INLINE auto format(format_string fmt, T&&...
args)
| ^~
/<>/src/opm/input/eclipse/Deck/UDAValue.cpp:77:169: note: called
from here
77 | std::string msg = fmt::format("Internal error: The support for
use of UDQ/UDA is not complete in opm/flow. The string: '{}' must be numeric",
this->string_value);
|
^
/usr/include/fmt/core.h:3057:28: error: inlining failed in call to
‘always_inline’ ‘fmt::v8::basic_format_string::basic_format_string(const S&) [with S = char [109]; typename
std::enable_if
>::value, int>::type = 0; Char = char; Args = {const
std::__cxx11::basic_string, std::allocator
>&}]’: target specific option mismatch
3057 | FMT_CONSTEVAL FMT_INLINE basic_format_string(const S& s) : str_(s) {
|^~~
/<>/src/opm/input/eclipse/Deck/UDAValue.cpp:77:169: note: called
from here
77 | std::string msg = fmt::format("Internal error: The support for
use of UDQ/UDA is not complete in opm/flow. The string: '{}' must be numeric",
this->string_value);
|
^
make[3]: *** [CMakeFiles/genkw.dir/build.make:107:
CMakeFiles/genkw.dir/src/opm/input/eclipse/Deck/UDAValue.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
[ 8%] Generating tests/TEST_WLIST.DATA
See [1] for the full log.
It seems like this problem might be solved upstream already, see [2]. Maybe we
shold backport this?
[1] https://buildd.debian.org/status/fetch.php?pkg=opm-
common=riscv64=2022.04%7Erc1-2=1651224804=0
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234#c14
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-13-amd64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C),
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages g++-12 depends on:
ii gcc-1212-20220428-1
ii gcc-12-base 12-20220428-1
ii libc6 2.33-7
ii libgmp10 2:6.2.1+dfsg-3
ii libisl23 0.24-2
ii libmpc3 1.2.1-2
ii libmpfr6 4.1.0-3
ii libstdc++-12-dev 12-20220428-1
ii libzstd1 1.5.2+dfsg-1
ii zlib1g1:1.2.11.dfsg-4
g++-12 recommends no packages.
Versions of packages g++-12 suggests:
pn g++-12-multilib
pn gcc-12-doc
Bug#913079: ITP: strawberry -- an audio player and music collection organizer fully based on Qt5
Hi, I'd like to see Strawberry make it into Debian for Bookworm, but there has been no visible progress for over a year. Assuming this ITP has been abandoned, I'll like to take it over, and will need a sponsor. @Tony, Louis Hoping you are still interested in Strawberry, I have packaged the latest version 1.0.4 and uploaded to Mentors. https://mentors.debian.net/package/strawberry/ Cheers, Peter https://qa.debian.org/developer.php?login=pe...@pblackman.plus.com
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
Hi Clayton (CC), what is the story there? I don't believe any of those MS reports are actually (important) security issues, also why was this being disclosed publicly rather than responsibly? The fixes for the alleged permission issue also only handles one parent directory and classic permissions, but not any other (grand)parents or ACLs. On Tue, May 03, 2022 at 01:21:12PM +0200, Julian Andres Klode wrote: > On Thu, Apr 28, 2022 at 01:53:58PM +0200, Salvatore Bonaccorso wrote: > > Source: networkd-dispatcher > > Version: 2.1-2 > > Severity: grave > > Tags: security upstream > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > > > > Hi, > > > > The following vulnerabilities were published for networkd-dispatcher. > > > > CVE-2022-29799[0] and CVE-2022-29800[1]. > > > > If you fix the vulnerabilities please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > I do not believe these are vulnerabilities. Microsoft claims a > vulnerability exists if there is vulnerable code running under > the systemd-network user, and claims that apt and epmd run under > such user, but neither has communicated how those processes are > vulnerable, nor why they would run under that user. > > It's likely that their tool is a confused deputy, running on a > system with broken containers where container _apt and epmd > users are mapped to the same UID as the host systemd-network > (which still would not give them access to the bus), or it's > a FUD smear campaign. > > Microsoft also claims that a vulnerability exists if scripts > are writable by the user, however the directory is owned by > root, so any scripts in there had to be written there by > root. As such, that is a local admin choice to allow that > user to run code as root. > > By the same argument, the code would have to check that any > parent directory of the scripts is not writable by non-root > users. > > The proposed fix also would not address this problem in the > context of ACLs, as it only checks owner user and group, > and mode, but not whether any ACLs are granted. Hence if that > were really a bug, it's still not fixed. > > I can prepare a security update for this if people want it, > but I do not believe in the existence of these bugs or that > the fixes address them in a meaningful way. > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1010518: gnome-terminal: Tab auto-complete broken
Package: gnome-terminal Version: 3.44.0-1 Severity: important X-Debbugs-Cc: powe...@gmail.com For example, when I have: dude@pc:~$ sudo nvme --list and I press tab, I get: dude@pc:~$ sudo nvme --listdude@pc:~$ -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.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 gnome-terminal depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.0-1 ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gnome-terminal-data 3.44.0-1 ii gsettings-desktop-schemas 42.0-1 ii libatk1.0-0 2.38.0-1 ii libc6 2.33-7 ii libdconf1 0.40.0-3 ii libgcc-s1 12-20220428-1 ii libglib2.0-0 2.72.1-1 ii libgtk-3-03.24.33-1 ii libpango-1.0-01.50.6+ds-2 ii libstdc++612-20220428-1 ii libuuid1 2.38-4 ii libvte-2.91-0 0.68.0-1+b1 ii libx11-6 2:1.7.5-1 Versions of packages gnome-terminal recommends: ii gvfs 1.50.0-1 ii nautilus-extension-gnome-terminal 3.44.0-1 ii yelp 42.1-1 gnome-terminal suggests no packages. -- no debconf information
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied There are 2 issues there: the wrong apparmor profile and the behavour of unbound which makes this error to be fatal. /mjt
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
On Thu, Apr 28, 2022 at 01:53:58PM +0200, Salvatore Bonaccorso wrote: > Source: networkd-dispatcher > Version: 2.1-2 > Severity: grave > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerabilities were published for networkd-dispatcher. > > CVE-2022-29799[0] and CVE-2022-29800[1]. > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. I do not believe these are vulnerabilities. Microsoft claims a vulnerability exists if there is vulnerable code running under the systemd-network user, and claims that apt and epmd run under such user, but neither has communicated how those processes are vulnerable, nor why they would run under that user. It's likely that their tool is a confused deputy, running on a system with broken containers where container _apt and epmd users are mapped to the same UID as the host systemd-network (which still would not give them access to the bus), or it's a FUD smear campaign. Microsoft also claims that a vulnerability exists if scripts are writable by the user, however the directory is owned by root, so any scripts in there had to be written there by root. As such, that is a local admin choice to allow that user to run code as root. By the same argument, the code would have to check that any parent directory of the scripts is not writable by non-root users. The proposed fix also would not address this problem in the context of ACLs, as it only checks owner user and group, and mode, but not whether any ACLs are granted. Hence if that were really a bug, it's still not fixed. I can prepare a security update for this if people want it, but I do not believe in the existence of these bugs or that the fixes address them in a meaningful way. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1010516: sqlite3: consider linking dynamically
Package: sqlite3 Version: 3.38.3-1 Severity: wishlist Tags: patch Hi, I was investigating why sqlite3 was so "big" and noticed that it links libsqlite3 statically. The most common reason for doing so is usage of unexported symbols. Evidently that's not the case here. So why would it not link dynamically? I looked into whether doing it was possible. The attached patch makes sqlite3 link libsqlite3 dynamically. Easy enough. Possibly, we'd have to guard it by some configure option to make it upstreamable. How do package sizes change? libsqlite3-0 has an Installed-Size of 1664 and is obviously unaffected by the change. Prior to the change, sqlite3 weighs in at Installed-Size 1878. After the change, its size is reduced to 519, but we must now account for libsqlite3-0, so we effectively get 2183, i.e. a growth of 305. The bulk of that is the (duplicated) contents of of /usr/share/doc. Given that libsqlite3-0 is pulled by very many packages, and that /usr/share/doc can be removed in size-constrained settings, the reduction achieved by dynamic linking seems reasonable to me. Do you agree? Helmut --- sqlite3-3.38.3.orig/Makefile.in +++ sqlite3-3.38.3/Makefile.in @@ -657,9 +657,9 @@ -avoid-version sed -i "/dependency_libs/s/'.*'/''/" $@ -sqlite3$(TEXE): shell.c sqlite3.c +sqlite3$(TEXE): shell.c libsqlite3.la $(LTLINK) $(READLINE_FLAGS) $(SHELL_OPT) -o $@ \ - shell.c sqlite3.c \ + shell.c libsqlite3.la \ $(LIBREADLINE) $(TLIBS) -rpath "$(libdir)" sqldiff$(TEXE): $(TOP)/tool/sqldiff.c sqlite3.lo sqlite3.h
Bug#998039: ITP: makedeb -- The modern packaging tool for Debian archives.
Control: retitle -1 ITP: makedeb -- A simplicity-focused packaging tool for Debian archives On Fri, 17 Dec 2021 14:49:54 -0800 LEO PUVILLAND wrote: > > Hey Guillem! > We have reworked the description and title, it's now "A simplicity-focused packaging tool for Debian archives". Retitling bug accordingly.
