Bug#991566: r-cran-bslib is in NEW now
Hi, just hoping that r-cran-bslib will be accepted soonish to be able to work on this issue. Kind regards Andreas. -- http://fam-tille.de
Bug#1010382: ITP: mkdocstrings-python-legacy -- Legacy Python handler for mkdocstrings
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mkdocstrings-python-legacy Version : 0.2.2 Upstream Author : Timothée Mazzucotelli * URL : https://github.com/mkdocstrings/python-legacy * License : ISC Programming Lang: Python Description : Legacy Python handler for mkdocstrings MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. . This package contains an legacy Python handler used within mkdocstrings. This package is a new dependency for mkdocstrings >= 0.18 which due a split of existing legacy Python functions moved into a own library. It will be maintained within the Debian Python Team.
Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)
Cyril Brulebois (2022-04-29): > > I'll try and pinpoint when it broke using the various intermediary > > versions: > > > > - 5.17~rc3-1~exp1 > > The first attempt was sufficient: it breaks as early as that version. Using the same base image as before, and only updating the kernel: I've tested upstream builds, starting from the .config found in the Debian 5.16.18-1 package, using oldconfig and accepting everything by default: - v5.16 is confirmed a first good; - v5.17-rc1 is confirmed a first bad; - the culprit seems to be 3ceff4ea07410763d5d4cccd60349bf7691e7e61 Here's the git bisect log: git bisect start # good: [df0cc57e057f18e44dac8e6c18aba47ab53202f9] Linux 5.16 git bisect good df0cc57e057f18e44dac8e6c18aba47ab53202f9 # bad: [e783362eb54cd99b2cac8b3a9aeac942e6f6ac07] Linux 5.17-rc1 git bisect bad e783362eb54cd99b2cac8b3a9aeac942e6f6ac07 # good: [fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e] Merge tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator git bisect good fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e # bad: [3ceff4ea07410763d5d4cccd60349bf7691e7e61] Merge tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad 3ceff4ea07410763d5d4cccd60349bf7691e7e61 # good: [57ea81971b7296b42fc77424af44c5915d3d4ae2] Merge tag 'usb-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect good 57ea81971b7296b42fc77424af44c5915d3d4ae2 # good: [feb7a43de5ef625ad74097d8fd3481d5dbc06a59] Merge tag 'irq-msi-2022-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good feb7a43de5ef625ad74097d8fd3481d5dbc06a59 # good: [10674ca9ea02491fd3f8ffe303861b7a6837994b] ASoC/SoundWire: improve suspend flows and use set_stream() instead of set_tdm_slots() for HDAudio git bisect good 10674ca9ea02491fd3f8ffe303861b7a6837994b # good: [c77b1f8a8faeeba43c694d9d09d0b25a4f52cf37] scsi: mpi3mr: Bump driver version to 8.0.0.61.0 git bisect good c77b1f8a8faeeba43c694d9d09d0b25a4f52cf37 # good: [f66229aa355f7e0dc0dc20cbc1f4d45c3176eed2] Merge tag 'asoc-v5.17-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus git bisect good f66229aa355f7e0dc0dc20cbc1f4d45c3176eed2 # good: [59aa7fcfe2e44afbe9736e5cfa941699021d6957] IB/mthca: Use memset_startat() for clearing mpt_entry git bisect good 59aa7fcfe2e44afbe9736e5cfa941699021d6957 # good: [18451db82ef7f943c60a7fce685f16172bda5106] RDMA/core: Calculate UDP source port based on flow label or lqpn/rqpn git bisect good 18451db82ef7f943c60a7fce685f16172bda5106 # good: [1f43e5230aebb17aea35238dc26e297a61095ac0] mailbox: qcom-ipcc: Support more IPCC instance git bisect good 1f43e5230aebb17aea35238dc26e297a61095ac0 # good: [747c19eb7539b5e6bb15ed57a0a14ebf9f3adb8e] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma git bisect good 747c19eb7539b5e6bb15ed57a0a14ebf9f3adb8e # good: [e1a7aa25ff45636a6c1930bf2430c8b802e93d9c] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi git bisect good e1a7aa25ff45636a6c1930bf2430c8b802e93d9c # good: [19980aa10d2d944ed8fe345ce2eb87c2cb4bedf8] ALSA: hda: intel-dsp-config: add JasperLake support git bisect good 19980aa10d2d944ed8fe345ce2eb87c2cb4bedf8 # good: [081c73701ef0c2a4f6a127da824a641ae6505fbe] ALSA: hda: intel-dsp-config: reorder the config table git bisect good 081c73701ef0c2a4f6a127da824a641ae6505fbe # first bad commit: [3ceff4ea07410763d5d4cccd60349bf7691e7e61] Merge tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound I'll try and find out more in a couple of hours, and get in touch with upstream. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#1010368: Maybe marshal nondeterminism?
>From skimming some of cpython's "marshal" code [1] my best guess is that first difference is between it thinking the `_m` string might have another reference to it (and thus adding 0x80, or FLAG_REF to it) or not. This seems driven by whether or not python's object for the string has other references (it calls Py_REFCNT(v) to decide, see line 302). I assume the difference is whether or not python has bothered to collect some other reference to the string or not. Type "Z" is an interned string type, TYPE_SHORT_ASCII_INTERNED, which therefore makes sense that it might be shared with who knows what else. I'm assuming this stops reproducing when you change it to a unique name since no one else will share the reference and you'll just deterministically get no FLAG_REF. Just my best guesses. Keith [1] https://github.com/python/cpython/blob/main/Python/marshal.c
Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"
Source: commons-daemon
Version: 1.0.15-8
Severity: normal
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear Maintainer,
The commons-daemon has a ftbfs issue on riscv64:
```
...
configure:2916: result: none needed
configure:2979: checking for ranlib
configure:2995: found /usr/bin/ranlib
configure:3006: result: ranlib
configure:3071: checking for strip
configure:3087: found /usr/bin/strip
configure:3098: result: strip
configure:3126: checking C flags dependant on host system type
configure:3294: result: failed
configure:3296: error: Unsupported CPU architecture "riscv64"
...
```
The full buildd log is:
https://buildd.debian.org/status/fetch.php?pkg=commons-daemon=riscv64=1.0.15-8=1558276470=0
The attach patch is for supporting build on riscv64. And I have tested it
locally
that is ok. If you need me to do some extra tests please tell me.
BR,
Bo
add support for risv64 arch
Bo YU
--- a/src/native/unix/configure
+++ b/src/native/unix/configure
@@ -2707,6 +2707,11 @@
supported_os="ppc64le"
HOST_CPU=ppc64le
;;
+ riscv64)
+CFLAGS="$CFLAGS -DCPU=\\\"riscv64\\\""
+supported_os="riscv64"
+HOST_CPU=riscv64
+;;
*)
echo "$as_me:$LINENO: result: failed" >&5
echo "${ECHO_T}failed" >&6
--- a/src/native/unix/support/apsupport.m4
+++ b/src/native/unix/support/apsupport.m4
@@ -186,6 +186,11 @@
supported_os="ppc64le"
HOST_CPU=ppc64le
;;
+ riscv64)
+CFLAGS="$CFLAGS -DCPU=\\\"riscv64\\\""
+supported_os="riscv64"
+HOST_CPU=riscv64
+;;
*)
AC_MSG_RESULT([failed])
AC_MSG_ERROR([Unsupported CPU architecture "$host_cpu"]);;
Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available
Hi Etienne, would you have some bandwidth to fix this one? Regards Nilesh On Wed, 27 Apr 2022 18:01:01 +0200 Mattia Rizzolo wrote: > Source: parasail > Version: 2.5+dfsg-3 > Severity: serious > User: reproducible-bui...@lists.alioth.debian.org > Usertags: cpu > > Hi! > > While working on the “reproducible builds” effort [1], we have noticed > that your package "parasail" doesn't build reproducibly. > > In fact, it seems that depending on the type of CPU it builds on, > sometimes there are slightly different files. For example, on an i386 > system: > - usr/lib/i386-linux-gnu/libparasail_novec_table.a > - usr/lib/i386-linux-gnu/libparasail_sse41_rowcol.a > - usr/lib/i386-linux-gnu/libparasail_avx2_table.a > or in an amrhf system: > - usr/lib/arm-linux-gnueabihf/libparasail_novec.a > - usr/lib/arm-linux-gnueabihf/libparasail_novec_rowcol.a > sometimes are there or not. > > I'll have to remember you that building differently depending on the CPU > features of the build host is not allowed by Policy. > > > Furthermore, I notice that amongst the i386 build, there are files such > as > - usr/lib/i386-linux-gnu/libparasail_sse2.a > - usr/lib/i386-linux-gnu/libparasail_sse41.a > that makes me wonder if the program is unconditially using SSE > instructions on i386, that would be a baseline violation; but since I > haven't verified if those features are used unconditially I'm not filing > this report about this, however please do check. > > > [1]: https://wiki.debian.org/ReproducibleBuilds > > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1008569: unar: diff for NMU version 1.10.1-3
Hi all, 在 2022-04-29星期五的 08:20 +0200，Paul Gevers写道： > Dear Boyuan, > > On 25-04-2022 20:44, Sudip Mukherjee wrote: > > > +unar (1.10.1-3) unstable; urgency=medium > > > + > > > + * QA upload. > > > + * Orphan the package (take over package maintenance) via > > > + ITS process. (Closes: #1008569) > > > > I maybe wrong but I was wondering if this is correct. > > > > Section 5.12 in Debian's Developers Reference [1] clearly says: > > Note that the process is only intended for actively taking over > > maintainership. Do not start a package salvaging process when you > > do not intend to maintain the package for a prolonged time. If you > > only want to fix certain things, but not take over the package, you > > must use the NMU process, even if the package would be eligible for > > salvaging. > > > > And, in this case you salavaged the package with the intention to > > orphan it not to maintain it. > > Today I received the 'Work-needing packages report' [1] that notified me > that there are three reverse dependencies of unar. Two are maintained by > me and the a11y team (I didn't realize that when I say the message by > Sudip). The third is maintained by you. It appears to me that you > "salvaged" unar because of that (I could be wrong, please let me know). > I think it would have helped (at least I would have read the message > from Sudip with more sympathy for you) if you would have made that clear > in your original ITS message and/or in a follow-up message to Sudip. > > Do you think it would be a good idea if you co-maintain this package > with the a11y team? That way, you don't need to take the sole ownership > (which you apparently didn't want) but can still easily keep an eye on > it (and continue the work to package 1.10.7). > > Paul > > [1] > https://lists.debian.org/msgid-search/e1nkesg-00066x...@quantz.debian.org Thank you all for the information and offering. Unar is an important package not only because of high popcon and reverse dependencies (including packages in a11y team, KDE's ark, and package bookworm I maintain), it is also the sole sane solution in the Linux world to correctly handle zip files with national encodings AFAIK (especially since unzip-iconv patch never made itself into Debian). That is the basic motivation for me to refresh this package. That being said, having this package team-maintained would be a good idea, better than "maintaining package via QA uploads". I would be happy to co- maintain it under the a11y team, and will reflect team maintenance in the next upload when current icu71 transition is properly dealt. For now my perference is to keep the git packaging repo under salsa.debian.org/debian/ namespace, but please let me know if you have other suggestions. Refreshing this package is expected to be bumpy due to Objective-C source code, non-standard build system, and porting issues ([2][3]). It's likely that I will be seriously using porterbox for the very first time. Any technical suggestions, or even extra hands, would be helpful. Thanks, Boyuan Yang [2] https://ci.debian.net/data/autopkgtest/testing/armhf/u/unar/21226476/log.gz [3] https://bugs.debian.org/746198 signature.asc Description: This is a digitally signed message part
Bug#1008112: fixed in golang-mvdan-sh 3.4.3+ds2-1
Hi Shengjing, >* Team upload >* Merge shfmt package (Closes: #1008112, #1008186, #1008463) Since you added shfmt binary package to golang-mvdan-sh, now both src: golang-mvdan-sh and src:shfmt are proving a shfmt binary, shouldn't src:shfmt be removed then? Also, as you added a new binary package, shouldn't this have made it to new instead? I'm a bit confused admittedly. Let me know Regards, Nilesh
Bug#1009632: The QPA plugin package contains the TLS backends
Hi! On Fri, 15 Apr 2022 at 13:06, Patrick Franz wrote: > > Hi Robert, > > On Wed, 13 Apr 2022 12:02:36 +0200 Robert Griebl > wrote: > > Package: qt6-qpa-plugins > > Version: 6.2.2 > > > > The new Qt6 plugins for the TLS backend (QSslSocket) got packaged with > > the QPA plugins, which is a bit awkward if you have a headless daemon > > that needs to download from https:// URLs, because you are now pulling > > in a lot of X11 and OpenGL dependencies. > > > > I think these should be in their own qt6-tls-plugins package: > > > > /usr/lib/x86_64-linux-gnu/qt6/plugins/tls/libqcertonlybackend.so > > /usr/lib/x86_64-linux-gnu/qt6/plugins/tls/libqopensslbackend.so > > We can do that when we package Qt 6.3, because we'll have new binary > packages anyway then. The only place where these are used are in Qt Network, so the plugins should be shipped there. We can do that in the current packaging with the proper Break+Replaces. > > And while we're at it: the image format plugins also do not really > > belong into the qpa plugin package for the same reasons: you can use > > QtGui and the QImage classes perfectly fine in a headless daemon: > > > > /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqgif.so > > /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqico.so > > /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/libqjpeg.so > > Which package name do you suggest ? We already have " qt6-image-formats- > plugins", but that is from the qtimageformats module. QImage is part of Qt GUI, so they should be there. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#952704: libqt5printsupport5: Printer and queue attributes not available
severity 952704 wishlist tag 952704 wontfix thanks On Sun, 17 Apr 2022 at 11:36, Brian Potkin wrote: > > tags 952704 upstream > found 952704 5.15.2+dfsg-16 > thanks > > > In my opinion, the Qt print dialog should support the CUPS temporary > queue facility correctly. CUPS has APIs to do this. There shoudn't be > any need to set up a permanent manual queue or have cups-browsed add > a permanent queue in order to get remote queue or printer attributes It's a totally valid wishlist bug, but I'm afraid that Qt 5 will not add new features. Your best bet it to check what Qt 6 does and if it still does not supports this then open a bug upstream. Regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#1010369: RediSearch Upstream Needs Swapped out from version 1 to version 2
Hi Kevin, > Currently, this package is obviously packaging the now deprecated > version 1 source at https://github.com/goodform/RediSearch.git > > This should be swapped out for the new version 2 upstream at > https://github.com/RediSearch/RediSearch.git Indeed, and I'd love to be able to do that, but the license of this version is not compatible with the Debian Free Software Guidelines (DFSG). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1010380: buster-pu: flac/1.3.2-3+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
The attached debdiff for flac fixes CVE-2021-0561 in Buster. This CVE
has been marked as no-dsa by the security team.
The same patch has been already uploaded to all other releases.
Thorsten
diff -Nru flac-1.3.2/debian/changelog flac-1.3.2/debian/changelog
--- flac-1.3.2/debian/changelog 2022-01-16 19:54:01.0 +0100
+++ flac-1.3.2/debian/changelog 2022-04-27 22:03:02.0 +0200
@@ -1,3 +1,11 @@
+flac (1.3.2-3+deb10u2) buster; urgency=medium
+
+ * Non-maintainer upload by the LTS Team.
+ * CVE-2021-0561 (Closes: #1006339)
+Add patch to exit at EOS in verify mode.
+
+ -- Thorsten Alteholz Wed, 27 Apr 2022 22:03:02 +0200
+
flac (1.3.2-3+deb10u1) buster; urgency=medium
* Non-maintainer upload.
diff -Nru flac-1.3.2/debian/patches/CVE-2021-0561.patch
flac-1.3.2/debian/patches/CVE-2021-0561.patch
--- flac-1.3.2/debian/patches/CVE-2021-0561.patch 1970-01-01
01:00:00.0 +0100
+++ flac-1.3.2/debian/patches/CVE-2021-0561.patch 2022-04-27
22:03:02.0 +0200
@@ -0,0 +1,30 @@
+From e1575e4a7c5157cbf4e4a16dbd39b74f7174c7be Mon Sep 17 00:00:00 2001
+From: Neelkamal Semwal
+Date: Fri, 18 Dec 2020 22:28:36 +0530
+Subject: [PATCH] libFlac: Exit at EOS in verify mode
+
+When verify mode is enabled, once decoder flags end of stream,
+encode processing is considered complete.
+
+CVE-2021-0561
+
+Signed-off-by: Ralph Giles
+---
+ src/libFLAC/stream_encoder.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+Index: flac-1.3.2/src/libFLAC/stream_encoder.c
+===
+--- flac-1.3.2.orig/src/libFLAC/stream_encoder.c 2022-04-27
23:58:24.569563774 +0200
flac-1.3.2/src/libFLAC/stream_encoder.c2022-04-27 23:58:24.569563774
+0200
+@@ -2578,7 +2578,9 @@
+ encoder->private_->verify.needs_magic_hack = true;
+ }
+ else {
+-
if(!FLAC__stream_decoder_process_single(encoder->private_->verify.decoder)) {
++
if(!FLAC__stream_decoder_process_single(encoder->private_->verify.decoder)
++ || (!is_last_block
++ &&
(FLAC__stream_encoder_get_verify_decoder_state(encoder) ==
FLAC__STREAM_DECODER_END_OF_STREAM))) {
+
FLAC__bitwriter_release_buffer(encoder->private_->frame);
+ FLAC__bitwriter_clear(encoder->private_->frame);
+ if(encoder->protected_->state !=
FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA)
diff -Nru flac-1.3.2/debian/patches/series flac-1.3.2/debian/patches/series
--- flac-1.3.2/debian/patches/series2022-01-16 19:53:49.0 +0100
+++ flac-1.3.2/debian/patches/series2022-04-27 22:03:02.0 +0200
@@ -5,3 +5,5 @@
0051-metaflac-Fix-a-memory-leak.patch
0001-remove-build-path-from-generated-FLAC.tag-file.patch
0001-libFLAC-bitreader.c-Fix-out-of-bounds-read.patch
+
+CVE-2021-0561.patch
Bug#1010379: snacc: reproducible builds: timestamp embedded in header files
Source: snacc Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Various header files embed the timestamp when it was generated in comments: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/snacc.html /usr/include/snacc/c/asn-useful.h ·*This·.h·file·was·generated·by·snacc·on·Fri·May·19·17:42:30·2023 vs. ·*This·.h·file·was·generated·by·snacc·on·Sun·Apr·17·13:25:08·2022 The attached patch fixes this by removing the timestamps from the code that generates the header files. With this patch applied, snacc should become reproducible on tests.reproducible-builds.org! live well, vagrant From d44bf7e4857b23f94319aabf0bd3124a9b11ce58 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Fri, 29 Apr 2022 23:05:46 + Subject: [PATCH] reproducible builds: Remove timestamps from generated comments. https://reproducible-builds.org/docs/timestamps/ --- compiler/back-ends/c++-gen/gen-code.c | 4 ++-- compiler/back-ends/c-gen/gen-code.c | 4 ++-- compiler/back-ends/idl-gen/gen-code.c | 2 +- compiler/core/snacc.c | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/compiler/back-ends/c++-gen/gen-code.c b/compiler/back-ends/c++-gen/gen-code.c index d3632dd..8d15682 100644 --- a/compiler/back-ends/c++-gen/gen-code.c +++ b/compiler/back-ends/c++-gen/gen-code.c @@ -170,7 +170,7 @@ PrintHdrComment PARAMS ((hdr, m), fprintf (hdr, "//\n"); fprintf (hdr, "// %s - class definitions for ASN.1 module %s\n", m->cxxHdrFileName, m->modId->name); fprintf (hdr, "//\n"); -fprintf (hdr, "// This file was generated by snacc on %s", ctime ()); +fprintf (hdr, "// This file was generated by snacc"); fprintf (hdr, "// UBC snacc by Mike Sample\n"); fprintf (hdr, "// A couple of enhancements made by IBM European Networking Center\n"); /* 20.8.93 Thomas Meyer */ fprintf (hdr, "\n"); @@ -188,7 +188,7 @@ PrintSrcComment PARAMS ((src, m), fprintf (src, "//\n"); fprintf (src, "// %s - class member functions for ASN.1 module %s\n", m->cxxSrcFileName, m->modId->name); fprintf (src, "//\n"); -fprintf (src, "// This file was generated by snacc on %s", ctime ()); +fprintf (src, "// This file was generated by snacc"); fprintf (src, "// UBC snacc written by Mike Sample\n"); fprintf (src, "// A couple of enhancements made by IBM European Networking Center\n"); /* 20.8.93 Thomas Meyer */ fprintf (src, "\n"); diff --git a/compiler/back-ends/c-gen/gen-code.c b/compiler/back-ends/c-gen/gen-code.c index e5c94d9..a198676 100644 --- a/compiler/back-ends/c-gen/gen-code.c +++ b/compiler/back-ends/c-gen/gen-code.c @@ -182,7 +182,7 @@ PrintCSrcComment PARAMS ((src, m), fprintf (src, "/*\n"); fprintf (src, " *%s\n *\n", m->cSrcFileName); fprintf (src, " *\"%s\" ASN.1 module encode/decode/print/free C src.\n *\n", m->modId->name); -fprintf (src, " *This file was generated by snacc on %s *\n", ctime ()); +fprintf (src, " *This file was generated by snacc *\n"); fprintf (src, " *UBC snacc written by Mike Sample\n *\n"); fprintf (src, " *NOTE: This is a machine generated file - editing not recommended\n"); fprintf (src, " */\n\n\n"); @@ -231,7 +231,7 @@ PrintCHdrComment PARAMS ((f, m), fprintf (f, "/*\n"); fprintf (f, " *%s\n *\n", m->cHdrFileName); fprintf (f, " *\"%s\" ASN.1 module C type definitions and prototypes\n *\n", m->modId->name); -fprintf (f, " *This .h file was generated by snacc on %s *\n", ctime ()); +fprintf (f, " *This .h file was generated by snacc *\n"); fprintf (f, " *UBC snacc written compiler by Mike Sample\n *\n"); fprintf (f, " *NOTE: This is a machine generated file--editing not recommended\n"); fprintf (f, " */\n\n\n"); diff --git a/compiler/back-ends/idl-gen/gen-code.c b/compiler/back-ends/idl-gen/gen-code.c index 9e4c9c2..978e5a6 100644 --- a/compiler/back-ends/idl-gen/gen-code.c +++ b/compiler/back-ends/idl-gen/gen-code.c @@ -70,7 +70,7 @@ PrintComment PARAMS ((idl, m), fprintf (idl, "//\n"); fprintf (idl, "// %s -- IDL for ASN.1 module %s\n", m->idlFileName, m->modId->name); fprintf (idl, "//\n"); -fprintf (idl, "// This file was generated by snacc on %s", ctime ()); +fprintf (idl, "// This file was generated by snacc"); fprintf (idl, "// UBC snacc written by Mike Sample\n"); fprintf (idl, "// IDL generator written by Robert Joop\n"); fprintf (idl, "\n"); diff --git a/compiler/core/snacc.c b/compiler/core/snacc.c index 96b2683..9b86b9f 100644 --- a/compiler/core/snacc.c +++ b/compiler/core/snacc.c @@ -1125,7 +1125,7 @@ GenCxxCode PARAMS ((allMods, longJmpVal, genTypes, genValues, genEncoders, genDe fprintf (meta.srcfp, "//\n"); fprintf (meta.srcfp, "// modules.C -
Bug#1010340: git: Fails to clone and pull from existign repositories
Hi, Andrea Palazzi wrote: > Package: git > Version: 1:2.36.0-1 > > Dear Maintainer, > > On my test system git is now basically unusable as it fails to clone and to > pull from already cloned repositories with an error "error: git-remote-https > died of signal 4"; e.g.: > > andrea@test:~$ LC_ALL=C git clone --branch=14.0 > https://github.com/OCA/manufacture.git > Cloning into 'manufacture'... > error: git-remote-https died of signal 4 > > I can clone the very same repository from Windows, so the remote is not the > problem. I can't reproduce this on Debian Unstable amd64: /tmp → LC_ALL=C git clone --branch=14.0 https://github.com/OCA/manufacture.git Cloning into 'manufacture'... remote: Enumerating objects: 29001, done. remote: Counting objects: 100% (1661/1661), done. remote: Compressing objects: 100% (831/831), done. remote: Total 29001 (delta 948), reused 1373 (delta 786), pack-reused 27340 Receiving objects: 100% (29001/29001), 8.43 MiB | 2.12 MiB/s, done. Resolving deltas: 100% (19042/19042), done. /tmp → git --version git version 2.36.0 /tmp → lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux bookworm/sid Release:unstable Codename: sid Maybe some hiccup at Github? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1010378: leds-alix: reproducible builds: source tarball embeds timestamps and umask
Source: leds-alix Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps umask X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org leds-alix-source embeds the timestamp and file permissions determined by umask in the leds-alix source tarball: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/leds-alix.html /usr/src/leds-alix.tar.bz2 -rw-r--r--···0·root·(0)·root·(0)·3610·2022-04-15·23:37:31.00·modules/leds-alix/leds-alix.c vs. -rw-rw-r--···0·root·(0)·root·(0)·3610·2023-05-19·06:01:18.00·modules/leds-alix/leds-alix.c The attached patch fixes this by passing arguments to tar in debian/rules to ensure consistent timestamp, file permissions, sort order, user, group, uid and gid in the generated tarball. With this patch applied, leds-alix should become reproducible on tests.reproducible-builds.org! live well, vagrant From 7f79cf28e70fdc2c0832f10517f29f7a9be3b61e Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Fri, 29 Apr 2022 21:35:18 + Subject: [PATCH 1/2] debian/rules: Generate tarball reproducibly. Pass arguments to tar to set sort order, timestamps, owner, group and mode. --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 1068a59..59012aa 100755 --- a/debian/rules +++ b/debian/rules @@ -48,7 +48,7 @@ install: build dh_installdirs -p$(psource) usr/src/modules/$(sname)/debian cp Makefile leds-alix.c $(DESTDIR) cp debian/*modules.in* debian/control debian/rules debian/changelog debian/copyright debian/README.Debian $(DESTDIR)/debian - cd debian/$(psource)/usr/src && tar c modules | bzip2 -9 > $(sname).tar.bz2 && rm -rf modules + cd debian/$(psource)/usr/src && tar --sort=name --mtime="@$(SOURCE_DATE_EPOCH)" --owner=0 --group=0 --numeric-owner --mode=go=rX,u+rw,a-s --create modules | bzip2 -9 > $(sname).tar.bz2 && rm -rf modules dh_install binary-indep: build install -- 2.30.2 signature.asc Description: PGP signature
Bug#1010342: Refuses to create directories for unburdening
Control: tag -1 + moreinfo Hi Didier, Didier 'OdyX' Raboud wrote: > With 0.4.2, after noticing my directories didn't get symlinked, I tried to > run unburden-home-dir by hand and I got the following error(s) (with or > without -F): Thanks for the bug report! > WARNING: Can't handle /home/didier/.cache: /tmp/.unburden-didier/cache not > equal /run/user/1000/.unburden-didier/cache at /usr/bin/unburden-home-dir > line 245, <$list_fh> line 2 This basically means that to wants symlink files elsewhere than before. > I haven't spent much time investigating; as 0.4.1.2 works for me now. > > Anything I could do to help? The output of "env | fgrep XDG_" might be helpful. The weird thing is that there weren't any changes which explains that out of the box: commit 35b8081adf5186e9ea8b366f3da027d6e3eed9f7 Author: Marcel Partap Date: Wed Mar 2 22:59:32 2022 +0100 Only append UID if XDG_RUNTIME_DIR is unset Note: I seem to have forgotten und mention this pull request in the changelog. Fixed in git now. Anyway, this was a bugfix which seemed to rather unbreak things than break things. See https://github.com/xtaran/unburden-home-dir/pull/20 commit cbc8088fe133f4230104d3e7527a0806973d6dca Author: Axel Beckert Date: Mon Feb 14 00:23:01 2022 +0100 Fix wrong file name order in output when creating symlinks Only happened when something actually was replaced by a symlink. Note: This is just a change in the output formatting, not a change in the logic. commit 2f65f99ef8447ef886fa2e9e3b2f007aa5b738c6 Author: Axel Beckert Date: Sun Feb 13 23:03:49 2022 +0100 Fix superfluous whitespace Note: Same as above. commit ced05b7a52e0e9736f9fcd6683898c84ab65c0ee Author: Axel Beckert Date: Sun Feb 13 22:07:54 2022 +0100 Support %i = user id in the FILELAYOUT configuration variable Allows one to use /run/user// as TARGETDIR. Add an example for that as well. Also make documentation of the configuration file easier to grok, by using dotted lists for listing the format strings, etc. Semantic versioning: Bump minor version due to an backwards compatible feature. Note: This just adds a potential format string, but doens't change any logic. That's all since 0.4.1.3. (And the only change in the script itself between 0.4.1.2 and 0.4.1.3 was the version bump.) And under etc/ there weren't any changes since 2017. Then again, I noticed this, too, on one of my hosts. I thought I might have toyed with a non-standard config for testing one of the changes mentioned above and just uncommented this line in /etc/unburden-home-dir to make it work again: #TARGETDIR=/tmp (But before you do the same change, please read until the end of this mail and do "stat" that file.) Actually this looks a bit like a result of this commit from 2015 between 0.3.3 and 0.4: commit 65f632b73c7a78e6f30aae143eebb95e5bb15866 Author: Axel Beckert Date: Sun Jul 5 01:43:27 2015 +0200 Don't set TARGETDIR in config by default but compute a sane default value The default value is determined as follows: - Use $TARGETDIR if set in the configuration file. - Else use $XDG_RUNTIME_DIR/$UID if it exists. - Else use /run/user/$UID if it exists. - Else use $TMPDIR if it exists. - Else use /tmp/. Requires new runtime dependency libfile-slurp-perl. For coverage computation, the test suite is run twice, once with and once without $TMPDIR and $XDG_RUNTIME_DIR being set. Closes: #780387 So I wonder if for some reason the /etc/unburden-home-dir conffile got updated this time while it didn't get update with quite a lot of previous updates. Can you also send me the output of "stat /etc/unburden-home-dir" in case you didn't edit it since the update. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1010377: V2Ray CVE-2021-4070 DoS by Authenticated VMess Server patch not applied
Package: v2ray Version: 4.34.0-1 Control: severity -1 serious This bug is submitted by upstream developers for a serious DoS bug within V2Ray that have been patched in upstream since 05 Dec 2021, and subsequently published but remain unpatched in Debian. The fix for this bug is included in v4.44.0 (https://github.com/v2fly/v2ray-core/releases/tag/v4.44.0). It have been identified as: CVE-2021-4070 (https://nvd.nist.gov/vuln/detail/CVE-2021-4070) This vulnerability allows a VMess Server controlled by an attacker to crash a VMess Client by sending a specially crafted handshake response reply with an (optional) VMess SwitchAccount Command that is one byte shorter than expected. This vulnerability does NOT allow the attacker to retrieve any information from a client other than it used an unpatched version of the software and does NOT allow attacker to control the unpatched software or system. It is strongly recommended for all users to apply this security update at the earliest possible opportunity. We would like to thank geeknik for the responsible disclosure of this vulnerability. Fix: https://github.com/v2fly/v2ray-core/commit/c1af2bfd7aa59a4482aa7f6ec4b9208c1d350b5c
Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Hi I've done more tests (basically recompiled and installed 2 times the same kernel) with linux-5.17.5 but I am still having no luck : I can't figure out why it does not detect the controller ... I've checked the config and the drivers for the controller (ata_piix , ata_generic ) are built but they are not loaded at the initramfs stage. I've tried to put them explicitly in the initramfs via /etc/initramfs-tools/modules but nothing worked. So I decided to give a try to linux 5.18-rc4 : I've reverted the commit d6b88ce2eb9d , recompiled , installed in the target machine , rebooted and BINGO !! The system boots almost with the same config used for compiling linux 5.17.5 :) uname -a Linux 5.18.0-rc4 #1 PREEMPT Fri Apr 29 11:12:55 CEST 2022 i686 GNU/Linux cat /proc/version Linux version 5.18.0-rc4 (@<64bit_hostname>) (gcc (Debian 11.3.0-1) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38) #1 PREEMPT Fri Apr 29 11:12:55 CEST 2022 The deb package I built is basically an optimized kernel for my machine with only the modules for the internal devices and the external components I have , so to be quick at building a new kernel ; it's not suitable for other systems. For who would like to try to build standard deb-flavour kernels in a quicker way in a faster machine, I can say that in the past I managed a 32 bit build host via virtual machine in my 64 bit machine to build deb packages I needed for my 32 bit system (basically, it was a minimal 32 bit debian unstable distribution installed as a virtualbox machine) : it was - and it is still now in my opinion - the easiest way to have a build host for 32 bit packages in a 64 bit environment because I found more complicated setting up a full cross compile environment .
Bug#1010376: RFS: rinetd/0.73-0.1 [NMU] [ITA] -- Internet TCP/UDP redirection server
Package: sponsorship-requests
Severity: normal
Dear mentors,
The current version of rinetd in Debian is 0.62 from year 2003.
I am looking for a sponsor for my package "rinetd":
* Package name: rinetd
Version : 0.73-0.1
Upstream Author : https://github.com/samhocevar/rinetd/issues
* URL : https://github.com/samhocevar/rinetd
* License : GPL-2+
* Vcs : [fill in URL of packaging vcs]
Section : net
The source builds the following binary packages:
rinetd - Internet TCP/UDP redirection server
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/rinetd/
Alternatively, you can download the package with 'dget' using this command:
dget -x
https://mentors.debian.net/debian/pool/main/r/rinetd/rinetd_0.73-0.1.dsc
Changes since the last upload:
rinetd (0.73-0.1) unstable; urgency=medium
.
* Non-maintainer upload.
* New upstream release (from https://github.com/samhocevar/rinetd).
* Added systemd service file debian/rinetd.service.
* Added debian/watch.
* debian/rules: CHANGES renamed to CHANGES.md.
* debian/docs: README renamed to README.md.
* debian/copyright: Update to DEP5 format.
* Removed debian/compat.
* debian/control:
+ Added debhelper-compat to Build-Depends.
+ Added lsb-base to Depends (lintian error).
+ Removed dh-autoreconf from Depends (lintian warning).
+ Added ${misc:Pre-Depends} to Pre-Depends (lintian warning).
+ Added UDP to Description (supported since 0.70).
+ Updated Standards-Version to 4.6.0.1
Regards,
Helmar.
Bug#1010375: smarty4: CVE-2021-21408 CVE-2021-29454
Source: smarty4 Version: 4.1.0-1 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for smarty4. CVE-2021-21408[0]: | Smarty is a template engine for PHP, facilitating the separation of | presentation (HTML/CSS) from application logic. Prior to versions | 3.1.43 and 4.0.3, template authors could run restricted static php | methods. Users should upgrade to version 3.1.43 or 4.0.3 to receive a | patch. CVE-2021-29454[1]: | Smarty is a template engine for PHP, facilitating the separation of | presentation (HTML/CSS) from application logic. Prior to versions | 3.1.42 and 4.0.2, template authors could run arbitrary PHP code by | crafting a malicious math string. If a math string was passed through | as user provided data to the math function, external users could run | arbitrary PHP code by crafting a malicious math string. Users should | upgrade to version 3.1.42 or 4.0.2 to receive a patch. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-21408 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21408 [1] https://security-tracker.debian.org/tracker/CVE-2021-29454 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29454 Regards, Salvatore
Bug#1010357: Extra info
I am using a DELL Latitude D620 laptop with Core Duo inside. It only supports i386. lscpu Architecture: i686 CPU op-mode(s): 32-bit Address sizes: 32 bits physical, 32 bits virtual Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Vendor ID: GenuineIntel BIOS Vendor ID: Intel Model name: Genuine Intel(R) CPU T2400 @ 1.83GHz I am running Debian Testing for a long time without this problem. I have the impression somehow a switch is made to GTK-4.
Bug#1010374: sox: CVE-2021-3643 CVE-2021-23210
Source: sox Version: 14.4.2+git20190427-3 Severity: important Tags: security upstream Forwarded: https://sourceforge.net/p/sox/bugs/351/ X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for sox. CVE-2021-3643[0]: | buffer overflow read vulnerability CVE-2021-23210[1]: | divide by zero in voc.c Note the respective Red Hat Bugzilla entries contain little more information on the connection of the both. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-3643 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3643 https://bugzilla.redhat.com/show_bug.cgi?id=1980626 [1] https://security-tracker.debian.org/tracker/CVE-2021-23210 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23210 https://bugzilla.redhat.com/show_bug.cgi?id=1975670 [2] https://sourceforge.net/p/sox/bugs/351/ Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1010373: mirror submission for fastmirror.pp.ua
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: fastmirror.pp.ua Type: leaf Archive-architecture: amd64 i386 Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Ivan Barabash Country: UA Ukraine Location: Kyiv Trace Url: http://fastmirror.pp.ua/debian/project/trace/ Trace Url: http://fastmirror.pp.ua/debian/project/trace/ftp-master.debian.org Trace Url: http://fastmirror.pp.ua/debian/project/trace/fastmirror.pp.ua
Bug#998627: linux: please enable the new NTFS3 driver in 5.15
Hi, On Sun, Mar 20, 2022 at 10:25:23PM +0100, Ben Hutchings wrote: > On Fri, 2022-03-18 at 20:58 +0100, lenni_na1 wrote: > > Hi, > > > > are there any news on this? > > > > We are now at kernel 5.16 in testing and as far as I can tell the ntfs3 > > driver still hasn't been enabled. > > The recent traffic on the ntfs3 list seems to consist of bug reports > and small fixes, none of them being addressed by the supposed > maintainer of the filesystem (who last posted at the end of November). > > I think that we would be doing our users a disservice by enabling ntfs3 > in this state. In meanwhile the current state of NTFS3 driver has been discussed upstream starting in https://lore.kernel.org/lkml/da20d32b-5185-f40b-48b8-2986922d8...@stargateuniverse.net/ . Regards, Salvatore
Bug#1010372: mysql-8.0: Should mysql-8.0 be removed from unstable?
Source: mysql-8.0 Version: 8.0.23-3 Severity: normal X-Debbugs-Cc: car...@debian.org,t...@security.debian.org,lars.tangv...@oracle.com,vor...@debian.org,p...@debian.org Hi I noticed that mysql-8.0 is still in unstable with a quite ancient version not having updated now for several Oracle CPU rounds. Should mysql-8.0 be dropped completely from the archive or is there still interest in keeping in in unstable? There are in unstable two packages which will have broken Build-Depends, thus CC'ing the interested parties as well. myodbc: libmysqlclient-dev (>= 5.5.17) pytest-services: mysql-testsuite-8.0 If you do agree on the removal, please reassign the bug against ftp.debian.org (and asking as well for removing of the packages with broken build-depends). Regards, Salvatore
Bug#1010128: Patch
There is a patch circulating in the Arch community. https://github.com/archlinux/svntogit-community/blob/master/broadcom-wl-dkms/trunk/012-linux517.patch Regards
Bug#1010371: gav: Source moved to GitHub
Source: gav Version: 0.9.0-3.1 - Forwarded message from Cesare Zavattari - > From: Cesare Zavattari > Subject: Package GAV changed repo > To: ubuntu-m...@lists.ubuntu.com > Date: Tue, 26 Apr 2022 13:00:55 +0200 > > Hi All, > just to inform you that GAV (Gpl Arcade Volleyball) moved from Sourceforge > to Github: > > https://github.com/ctrl-z-bg/gav > > Themes were added to the main repo. > Thanks > Bye > > -- > Cesare - End forwarded message -
Bug#1010112: virtualbox: 6.1.34-dfsg-2 broken, guest VM display window stays black with blinking cursor
You upgraded to 6.1.34-dfsg-2 from what? 6.1.32 or an earlier version? How did you upgrade? dpkg, apt, or Synaptic? On Tue, 26 Apr 2022 03:24:46 +0300 Alexander Kernozhitsky wrote: > Hello, > > I just upgraded to 6.1.34-dfsg-2, and for me everything worked fine, guest > systems start normally. > > Did you try to downgrade the package and ensure that the bug is done after > downgrade? > > -- > Alexander Kernozhitsky > > > >
Bug#1003653: Revision of removal of rename.ul from package util-linux
On 20/04/2022 15:31, Matthew Vernon wrote: I hereby call for a vote on the following ballot. Unless a TC member objects to calling for a vote, voting lasts for a week, or until the result is no longer in doubt. The voting period is over. ===Rationale There are two "rename" programs - the perl rename, and the util-linux rename. Debian and its derivatives have shipped the perl rename as /usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped the util-linux rename thus. The two implementations are incompatible. Users might reasonably desire both implementations to be available on the same system; they are designed to meet different needs. Backwards-compatibility (and the lack of a compelling argument that rename from util-linux should replace perl rename) means that /usr/bin/rename in Debian should remain the perl rename. Prior to bullseye, util-linux's rename was shipped as /usr/bin/rename.ul; Debian's users who wish to use util-linux's rename will expect it to be in this location. ===End Rationale ===Begin Resolution A The Technical Committee overrides the util-linux maintainer, and requires that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary package built from src:util-linux. The package containing rename.ul must not conflict with the rename package nor divert /usr/bin/rename. ===End Resolution A Resolution A wins, with 7 first preference votes (and no other votes). Regards, Matthew
Bug#817943: strip-nondeterminism damages .zip files with bzipped members
reassign 817943 libarchive-zip-perl affects 817943 strip-nondeterminism fixed 817943 1.65-1 thanks Not sure why this wasn't assigned to libarchive-zip-perl long ago. Am doing that now for the sake of BTS archaeologists, and then (hopefully) closing it. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1008500: Should undertaker be removed?
severity 1008500 normal reassign 1008500 ftp.debian.org retitle 1008500 RM: undertaker -- RoQA; Depends on Python 2, unmaintained thanks Reassigning for removal
Bug#1008499: Should neard be removed?
severity 1008499 normal reassign 1008499 ftp.debian.org retitle 1008499 RM: neard -- RoQA; depends on Python 2, unmaintained thanks Reassigning for removal
Bug#1010368: python3.10: python variables called _m lead to unreproducible pyc installations
Hey Johannes, > I'm not familiar with the pyc format so I cannot tell what the bits that > differ mean but maybe somebody who can, can figure this out given the > hexdump difference from above. As I understand it, a .pyc file consists of .pyc-specific header but the bulk of the file is "just" a marshalled PyCode object. The hexdump you referenced has the change within this marshalled part. When I disassemble this part using the dis module, there is no "semantic" difference between two different .pyc files from your loop: 1 0 LOAD_NAME0 (_m) 2 POP_TOP 4 LOAD_CONST 0 (None) 6 RETURN_VALUE This suggests that the difference is some internal implementation detail of the marshalled PyCode object which does not affect its execution semantics. I could imagine that some kind of string internalisation algorithm is resulting in nondeterministic hashmap entry numbers... or something. Still, it might not even be an implementation detail: it could merely be uninitialised memory that is happily skipped over by the parser. As it happens, I don't think you are the first to discover the peculiarity of "_m" — take a look at this enigmatic comment: https://github.com/python/cpython/issues/78903#issuecomment-1093799639 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out
On Fri, 29 Apr 2022, Evren Yurtesen wrote: > > What is the problem with logrotate? It happily rotates files owned > > by anyone in Debian. > > Because in Ubuntu rsyslog drops privileges to `syslog` user. > Therefore, the log files generated by rsyslog are owned by the > `syslog` user. But tomcat9 logrotate configuration forces logrotate to > become `tomcat` user, during rotation. Rsyslog fails to truncate the > catalina.out file which has read/write permissions only for `syslog` > user. The logfiles from tomcat aren’t normally generated by rsyslog though, they’re directly written by Java or via shell redirections. Anyway, this is chiefly a *buntu issue and the proposed fix would worsen the situation in Debian, so please try to get this solved on the *buntu side. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#1007260: performance regression due to linking against libnettle
So.. what should we do? Build it with libssl again because it is not ready to be used when built with nettle, and reopen #828699? Steinar, can you raise this upstream please? It'd be good if whole unbound can be built with nettle instead of openssl, and actually work :) Thanks! /mjt
Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)
Control: found -1 5.17~rc3-1~exp1 Cyril Brulebois (2022-04-29): > The usual start-up rainbow is displayed, the screen turns to black and > nothing happens. My first stop was trying to downgrade the bootloader > (shipped by the raspi-firmware package) to the bullseye's version, but > that didn't help. > > Then I moved to starting from a bullseye image (which boots), upgrading > the raspi-firmware package, that still boots. > > Then I deployed 5.16.18-1 (from snapshot.debian.org), that still boots. > > Then I deployed 5.17.3-1, and it broke booting. > > I'll try and pinpoint when it broke using the various intermediary > versions: > > - 5.17~rc3-1~exp1 The first attempt was sufficient: it breaks as early as that version. > and then try to figure out what broke exactly. Contrary to my earlier > efforts to introduce support for that hardware a few months ago, I > haven't been following upstream changes recently, so I'll need to catch > up. Checking the upstream diff, nothing obvious on the DTB side. Trying to use 5.16.18-1's DTB with 5.17~rc3-1~exp1 kernel didn't help anyway. I've also tried latest mainline: v5.18-rc4-192-g38d741cb70b3 built with: cp ~/config-5.17.0-1-arm64 .config time PATH=/usr/lib/ccache:$PATH make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- oldconfig # accept everything time PATH=/usr/lib/ccache:$PATH make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg -j32 and the symptoms are the same: black screen at start-up. I've also checked the serial console (which is confirmed to work if I boot 5.16.18-1), and I'm not getting anything there either, with either 5.17~rc3-1~exp1 or my local v5.18-rc4-192-g38d741cb70b3 build. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/ signature.asc Description: PGP signature
Bug#914405: appears to not update auto-trust-anchors without requests
Control: tag -1 - moreinfo It looks there's an upstream TODO item about this: o timers rfc 5011 support. (see /usr/share/doc/unbound/TODO.gz) /mjt
Bug#1006586: tpm2-pkcs11: FTBFS with OpenSSL 3.0
On Sun, 27 Feb 2022 23:58:38 +0100 Sebastian Andrzej Siewior wrote: Source: tpm2-pkcs11 Version: 1.7.0-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Your package is failing to build using OpenSSL 3.0 Ubuntu has a patch for this and it should also be resolved with version 1.8.0; changelog: "Add support for OpenSSL 3. Note that calls through engine are no longer supported on OpenSSL3."
Bug#1010369: RediSearch Upstream Needs Swapped out from version 1 to version 2
Package: redis-redisearch Version: 1.2.2-4 Currently, this package is obviously packaging the now deprecated version 1 source at https://github.com/goodform/RediSearch.git This should be swapped out for the new version 2 upstream at https://github.com/RediSearch/RediSearch.git [6c226525-c069-48e9-868b-fcc792609f12]
Bug#1010368: python3.10: python variables called _m lead to unreproducible pyc installations
Source: python3.10
Version: 3.10.4-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
if a package contains python code with a variable named _m, then after
installing that package the pyc file resulting from that code is
unreproducible because of some randomness. Minimal reproducer:
export SOURCE_DATE_EPOCH="$(date +%s)"
for i in `seq 1 10`; do
mmdebstrap --quiet --variant=apt --include=python3.10 \
--customize-hook='echo _m > "$1"/tmp/decoder.py' \
--customize-hook='chroot "$1" python3.10 -m py_compile /tmp/decoder.py' \
--customize-hook='cat "$1"/tmp/__pycache__/decoder.cpython-310.pyc |
md5sum' \
unstable /dev/null 2>&1
done | sort | uniq -c
The above will print something like:
6 4662176a6024d5eec15033097cd7e588 -
4 aeb00bedc784e7cca3eb42cf50e92f8d -
If you run the loop more often, one can see that 2/3 of the times, the
pyc file will have one hash and the other 1/3 of the times the other. So
there are two distinct possible contents that the pyc file generated
from the same python script just containing "_m" can have. Below you can
find a difference between the hexdump these two possible pyc versions.
I have no idea why this happens. But why does it matter? Since #1004558
got fixed, a Priority:standard chroot is now mostly bit-by-bit
identical. Only "mostly" because there is one remaining difference:
/usr/lib/python3.10/json/__pycache__/decoder.cpython-310.pyc
But why does that pyc file differ (randomly) while all the others remain
stable? Even if it sounds ridiculous, I tracked it down to the use of
the variable _m in /usr/lib/python3.10/json/decoder.py.
Also, the problem only shows when compiling all pyc files in a fresh
chroot. Given the same chroot with all pyc files already generated, the
pyc file generated from the minimal test case (just a python script
containing the variable name "_m" as above) will remain stable. So the
following will *not* reproduce the problem:
echo _m > test.py
for i in `seq 1 100`; do
rm -rf __pycache__
python3.10 -m py_compile test.py
md5sum __pycache__/test.cpython-310.pyc
done
It needs to be done in a fresh chroot. Since the pyc contents also rely
on the modification time of the python scripts involved, maybe the
reason for this is behaviour is some unreproducible mtimes after
unpacking the packages? This is why I'm filing it here. This might as
well be some sort of packaging problem.
For the minimal test case (a python script just containing the variable
name "_m"), the pyc file is very tiny and the diffoscope output will
display the whole file via the diff context:
@@ -1,8 +1,8 @@
: 6f0d 0d0a 0300 5371 fe33 17b6 dd59 o...Sq.3...Y
0010: e300
0020: 0001 0040 0073 0800 6500 .@...se.
-0030: 0100 6400 5300 2901 4e29 01da 025f 6da9 ..d.S.).N)..._m.
-0040: 0072 0200 7202 00fa 0f2f 746d .rr../tm
+0030: 0100 6400 5300 2901 4e29 015a 025f 6da9 ..d.S.).N).Z._m.
+0040: 0072 0100 7201 00fa 0f2f 746d .rr../tm
0050: 702f 6465 636f 6465 722e 7079 da08 3c6d p/decoder.py..s.
0070: 00 .
I'm not familiar with the pyc format so I cannot tell what the bits that
differ mean but maybe somebody who can, can figure this out given the
hexdump difference from above.
But it's crazy that a simple choice of variable name triggers randomness
in the pyc files, right? So to further test this theory, I patched the
python3.10 source package like this:
--- a/Lib/json/decoder.py
+++ b/Lib/json/decoder.py
@@ -67,7 +67,7 @@ def _decode_u(s, pos):
raise JSONDecodeError(msg, s, pos)
def py_scanstring(s, end, strict=True,
-_b=BACKSLASH, _m=STRINGCHUNK.match):
+_b=BACKSLASH, m=STRINGCHUNK.match):
"""Scan the string s for a JSON string. End is the index of the
character in s after the quote that started the JSON string.
Unescapes all valid JSON string escape sequences and raises ValueError
@@ -80,7 +80,7 @@ def py_scanstring(s, end, strict=True,
_append = chunks.append
begin = end - 1
while 1:
-chunk = _m(s, end)
+chunk = m(s, end)
if chunk is None:
raise JSONDecodeError("Unterminated string starting at", s, begin)
end = chunk.end()
This solves the problem of random unreproducibility. All pyc files in a
priority:standard chroot are now reproducible even when running the
producer from the top of this mail 100 times. This is why I'm tagging
this bug with "patch". I know this is just a workaround but maybe it can
be applied until the underlying problem is identified?
With above patch, a priority:standard chroot is now finally always
bit-by-bit reproducible. I know that I also claimed that this were the
case for the
Bug#1010366: python3.10: python variables called _m lead to unreproducible pyc installations
Source: python3.10
Version: 3.10.4-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: jo...@debian.org, reproducible-b...@lists.alioth.debian.org
Hi,
if a package contains python code with a variable named _m, then after
installing that package the pyc file resulting from that code is
unreproducible because of some randomness. Minimal reproducer:
export SOURCE_DATE_EPOCH="$(date +%s)"
for i in `seq 1 10`; do
mmdebstrap --quiet --variant=apt --include=python3.10 \
--customize-hook='echo _m > "$1"/tmp/decoder.py' \
--customize-hook='chroot "$1" python3.10 -m py_compile /tmp/decoder.py' \
--customize-hook='cat "$1"/tmp/__pycache__/decoder.cpython-310.pyc |
md5sum' \
unstable /dev/null 2>&1
done | sort | uniq -c
The above will print something like:
6 4662176a6024d5eec15033097cd7e588 -
4 aeb00bedc784e7cca3eb42cf50e92f8d -
If you run the loop more often, one can see that 2/3 of the times, the
pyc file will have one hash and the other 1/3 of the times the other. So
there are two distinct possible contents that the pyc file generated
from the same python script just containing "_m" can have. Below you can
find a difference between the hexdump these two possible pyc versions.
I have no idea why this happens. But why does it matter? Since #1004558
got fixed, a Priority:standard chroot is now mostly bit-by-bit
identical. Only "mostly" because there is one remaining difference:
/usr/lib/python3.10/json/__pycache__/decoder.cpython-310.pyc
But why does that pyc file differ (randomly) while all the others remain
stable? Even if it sounds ridiculous, I tracked it down to the use of
the variable _m in /usr/lib/python3.10/json/decoder.py.
Also, the problem only shows when compiling all pyc files in a fresh
chroot. Given the same chroot with all pyc files already generated, the
pyc file generated from the minimal test case (just a python script
containing the variable name "_m" as above) will remain stable. So the
following will *not* reproduce the problem:
echo _m > test.py
for i in `seq 1 100`; do
rm -rf __pycache__
python3.10 -m py_compile test.py
md5sum __pycache__/test.cpython-310.pyc
done
It needs to be done in a fresh chroot. Since the pyc contents also rely
on the modification time of the python scripts involved, maybe the
reason for this is behaviour is some unreproducible mtimes after
unpacking the packages? This is why I'm filing it here. This might as
well be some sort of packaging problem.
For the minimal test case (a python script just containing the variable
name "_m"), the pyc file is very tiny and the diffoscope output will
display the whole file via the diff context:
@@ -1,8 +1,8 @@
: 6f0d 0d0a 0300 5371 fe33 17b6 dd59 o...Sq.3...Y
0010: e300
0020: 0001 0040 0073 0800 6500 .@...se.
-0030: 0100 6400 5300 2901 4e29 01da 025f 6da9 ..d.S.).N)..._m.
-0040: 0072 0200 7202 00fa 0f2f 746d .rr../tm
+0030: 0100 6400 5300 2901 4e29 015a 025f 6da9 ..d.S.).N).Z._m.
+0040: 0072 0100 7201 00fa 0f2f 746d .rr../tm
0050: 702f 6465 636f 6465 722e 7079 da08 3c6d p/decoder.py..s.
0070: 00 .
I'm not familiar with the pyc format so I cannot tell what the bits that
differ mean but maybe somebody who can, can figure this out given the
hexdump difference from above.
But it's crazy that a simple choice of variable name triggers randomness
in the pyc files, right? So to further test this theory, I patched the
python3.10 source package like this:
--- a/Lib/json/decoder.py
+++ b/Lib/json/decoder.py
@@ -67,7 +67,7 @@ def _decode_u(s, pos):
raise JSONDecodeError(msg, s, pos)
def py_scanstring(s, end, strict=True,
-_b=BACKSLASH, _m=STRINGCHUNK.match):
+_b=BACKSLASH, m=STRINGCHUNK.match):
"""Scan the string s for a JSON string. End is the index of the
character in s after the quote that started the JSON string.
Unescapes all valid JSON string escape sequences and raises ValueError
@@ -80,7 +80,7 @@ def py_scanstring(s, end, strict=True,
_append = chunks.append
begin = end - 1
while 1:
-chunk = _m(s, end)
+chunk = m(s, end)
if chunk is None:
raise JSONDecodeError("Unterminated string starting at", s, begin)
end = chunk.end()
This solves the problem of random unreproducibility. All pyc files in a
priority:standard chroot are now reproducible even when running the
producer from the top of this mail 100 times. This is why I'm tagging
this bug with "patch". I know this is just a workaround but maybe it can
be applied until the underlying problem is identified?
With above patch, a priority:standard chroot is now finally always
bit-by-bit reproducible. I know that I also claimed that this were
Bug#1010367: python3.10: python variables called _m lead to unreproducible pyc installations
Source: python3.10
Version: 3.10.4-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
if a package contains python code with a variable named _m, then after
installing that package the pyc file resulting from that code is
unreproducible because of some randomness. Minimal reproducer:
export SOURCE_DATE_EPOCH="$(date +%s)"
for i in `seq 1 10`; do
mmdebstrap --quiet --variant=apt --include=python3.10 \
--customize-hook='echo _m > "$1"/tmp/decoder.py' \
--customize-hook='chroot "$1" python3.10 -m py_compile /tmp/decoder.py' \
--customize-hook='cat "$1"/tmp/__pycache__/decoder.cpython-310.pyc |
md5sum' \
unstable /dev/null 2>&1
done | sort | uniq -c
The above will print something like:
6 4662176a6024d5eec15033097cd7e588 -
4 aeb00bedc784e7cca3eb42cf50e92f8d -
If you run the loop more often, one can see that 2/3 of the times, the
pyc file will have one hash and the other 1/3 of the times the other. So
there are two distinct possible contents that the pyc file generated
from the same python script just containing "_m" can have. Below you can
find a difference between the hexdump these two possible pyc versions.
I have no idea why this happens. But why does it matter? Since #1004558
got fixed, a Priority:standard chroot is now mostly bit-by-bit
identical. Only "mostly" because there is one remaining difference:
/usr/lib/python3.10/json/__pycache__/decoder.cpython-310.pyc
But why does that pyc file differ (randomly) while all the others remain
stable? Even if it sounds ridiculous, I tracked it down to the use of
the variable _m in /usr/lib/python3.10/json/decoder.py.
Also, the problem only shows when compiling all pyc files in a fresh
chroot. Given the same chroot with all pyc files already generated, the
pyc file generated from the minimal test case (just a python script
containing the variable name "_m" as above) will remain stable. So the
following will *not* reproduce the problem:
echo _m > test.py
for i in `seq 1 100`; do
rm -rf __pycache__
python3.10 -m py_compile test.py
md5sum __pycache__/test.cpython-310.pyc
done
It needs to be done in a fresh chroot. Since the pyc contents also rely
on the modification time of the python scripts involved, maybe the
reason for this is behaviour is some unreproducible mtimes after
unpacking the packages? This is why I'm filing it here. This might as
well be some sort of packaging problem.
For the minimal test case (a python script just containing the variable
name "_m"), the pyc file is very tiny and the diffoscope output will
display the whole file via the diff context:
@@ -1,8 +1,8 @@
: 6f0d 0d0a 0300 5371 fe33 17b6 dd59 o...Sq.3...Y
0010: e300
0020: 0001 0040 0073 0800 6500 .@...se.
-0030: 0100 6400 5300 2901 4e29 01da 025f 6da9 ..d.S.).N)..._m.
-0040: 0072 0200 7202 00fa 0f2f 746d .rr../tm
+0030: 0100 6400 5300 2901 4e29 015a 025f 6da9 ..d.S.).N).Z._m.
+0040: 0072 0100 7201 00fa 0f2f 746d .rr../tm
0050: 702f 6465 636f 6465 722e 7079 da08 3c6d p/decoder.py..s.
0070: 00 .
I'm not familiar with the pyc format so I cannot tell what the bits that
differ mean but maybe somebody who can, can figure this out given the
hexdump difference from above.
But it's crazy that a simple choice of variable name triggers randomness
in the pyc files, right? So to further test this theory, I patched the
python3.10 source package like this:
--- a/Lib/json/decoder.py
+++ b/Lib/json/decoder.py
@@ -67,7 +67,7 @@ def _decode_u(s, pos):
raise JSONDecodeError(msg, s, pos)
def py_scanstring(s, end, strict=True,
-_b=BACKSLASH, _m=STRINGCHUNK.match):
+_b=BACKSLASH, m=STRINGCHUNK.match):
"""Scan the string s for a JSON string. End is the index of the
character in s after the quote that started the JSON string.
Unescapes all valid JSON string escape sequences and raises ValueError
@@ -80,7 +80,7 @@ def py_scanstring(s, end, strict=True,
_append = chunks.append
begin = end - 1
while 1:
-chunk = _m(s, end)
+chunk = m(s, end)
if chunk is None:
raise JSONDecodeError("Unterminated string starting at", s, begin)
end = chunk.end()
This solves the problem of random unreproducibility. All pyc files in a
priority:standard chroot are now reproducible even when running the
producer from the top of this mail 100 times. This is why I'm tagging
this bug with "patch". I know this is just a workaround but maybe it can
be applied until the underlying problem is identified?
With above patch, a priority:standard chroot is now finally always
bit-by-bit reproducible. I know that I also claimed that this were the
case for the
Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)
Source: linux Version: 5.17.3-1 Severity: important X-Debbugs-Cc: raspi-firmw...@packages.debian.org Hi, In the process of testing patches for the Raspberry Pi Compute Modules (CM3 and CM4), for bullseye[1][2] and bookworm[2], I discovered that bookworm images don't boot on the CM4. 1. https://bugs.debian.org/1010317 2. https://bugs.debian.org/996937 The usual start-up rainbow is displayed, the screen turns to black and nothing happens. My first stop was trying to downgrade the bootloader (shipped by the raspi-firmware package) to the bullseye's version, but that didn't help. Then I moved to starting from a bullseye image (which boots), upgrading the raspi-firmware package, that still boots. Then I deployed 5.16.18-1 (from snapshot.debian.org), that still boots. Then I deployed 5.17.3-1, and it broke booting. I'll try and pinpoint when it broke using the various intermediary versions: - 5.17~rc3-1~exp1 - 5.17~rc4-1~exp1 - 5.17~rc5-1~exp1 - 5.17~rc6-1~exp1 - 5.17~rc7-1~exp1 - 5.17~rc8-1~exp1 - 5.17.1-1~exp1 and then try to figure out what broke exactly. Contrary to my earlier efforts to introduce support for that hardware a few months ago, I haven't been following upstream changes recently, so I'll need to catch up. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Bug#998856: libvte-2.91-0: Bug persists in 0.68.0-1+b1
Package: libvte-2.91-0 Version: 0.68.0-1+b1 Followup-For: Bug #998856 X-Debbugs-Cc: jasmin...@noreply.com Dear Maintainer, same bug in 0.68.0-1+b1. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvte-2.91-0 depends on: ii libatk1.0-0 2.38.0-1 ii libc62.33-7 ii libcairo21.16.0-5 ii libfribidi0 1.0.8-2.1 ii libgcc-s112-20220428-1 ii libglib2.0-0 2.72.1-1 ii libgnutls30 3.7.4-2 ii libgtk-3-0 3.24.33-1 ii libicu71 71.1-2 ii libpango-1.0-0 1.50.6+ds-2 ii libpangocairo-1.0-0 1.50.6+ds-2 ii libpcre2-8-0 10.40-1 ii libstdc++6 12-20220428-1 ii libsystemd0 250.4-1 ii libvte-2.91-common 0.68.0-1+b1 ii zlib1g 1:1.2.11.dfsg-4 libvte-2.91-0 recommends no packages. libvte-2.91-0 suggests no packages. -- no debconf information
Bug#1010364: libffi overrides DEB_BUILD_OPTIONS=nocheck
Source: libffi Version: 3.4.2-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Matthias, I see that you made libffi override DEB_BUILD_OPTIONS=nocheck in certain situations. I think your override is too broad as it also covers cross builds. I'm attaching a patch that narrows down your override to native builds only and I think it still covers the intended use (as you explained in the commend). What do you think? Helmut diff --minimal -Nru libffi-3.4.2/debian/changelog libffi-3.4.2/debian/changelog --- libffi-3.4.2/debian/changelog 2022-01-17 11:37:08.0 +0100 +++ libffi-3.4.2/debian/changelog 2022-04-29 17:59:05.0 +0200 @@ -1,3 +1,10 @@ +libffi (3.4.2-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Don't override DEB_BUILD_OPTIONS=nocheck for cross builds. Closes: #-1. + + -- Helmut Grohne Fri, 29 Apr 2022 17:59:05 +0200 + libffi (3.4.2-4) unstable; urgency=medium * Configure --without-gcc-arch. Closes: #995223. diff --minimal -Nru libffi-3.4.2/debian/rules libffi-3.4.2/debian/rules --- libffi-3.4.2/debian/rules 2022-01-17 11:37:06.0 +0100 +++ libffi-3.4.2/debian/rules 2022-04-29 17:59:03.0 +0200 @@ -26,7 +26,7 @@ with_check = yes else # override buildd admins to run the testsuite anyway ... - ifneq (,$(filter $(DEB_HOST_ARCH), m68k powerpcspe sh4)) + ifeq ($(DEB_BUILD_ARCH),$(filter $(DEB_HOST_ARCH), m68k powerpcspe sh4)) with_check = yes endif endif
Bug#1010363: systemd-creds: Support for encrypted credentials not available.
Package: systemd Version: 250.4-1~bpo11+1 Severity: wishlist X-Debbugs-Cc: m...@neils.tech Dear Maintainer, systemd v250 added support for encrypted credentials via the systemd-creds tool. I installed the latest version of systemd from bullseye-backports. When I run 'systemd-creds' I get the following error: "Support for encrypted credentials not available." The cause appears to be that systemd is built without OpenSSL, per this upstream issue: https://github.com/systemd/systemd/issues/22114 In the changelog for the Debian systemd package there is this note: -- Michael Biebl Fri, 24 Dec 2021 13:02:05 +0100 systemd (250~rc3-1) experimental; urgency=medium ... * Explicitly disable OpenSSL support. We don't want to pick up an OpenSSL dependency in a tainted build environment and pull a second crypto stack into systemd's dependencies. ... Is there any possibility that OpenSSL support could be added so we have access to this feature? Thank you, Neils Christoffersen -- Package-specific info: -- 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-10 ii libapparmor1 2.13.6-10 ii libaudit11:3.0-2 ii libblkid12.36.1-8+deb11u1 ii libc62.31-13+deb11u3 ii libcap2 1:2.44-1 ii libcrypt11:4.4.18-4 ii libcryptsetup12 2:2.3.7-1+deb11u1 ii libfdisk12.36.1-8+deb11u1 ii libgcrypt20 1.8.7-6 ii libgnutls30 3.7.1-5 ii libgpg-error01.38-2 ii libip4tc21.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2.1~deb11u1 ii libmount12.36.1-8+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libseccomp2 2.5.1-1+deb11u1 ii libselinux1 3.1-3 ii libsystemd0 250.4-1~bpo11+1 ii libzstd1 1.4.8+dfsg-2.1 ii mount2.36.1-8+deb11u1 ii util-linux 2.36.1-8+deb11u1 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.12.20-2 ii systemd-timesyncd [time-daemon] 250.4-1~bpo11+1 Versions of packages systemd suggests: ii libfido2-11.6.0-2 pn libtss2-esys-3.0.2-0 pn libtss2-mu0 pn libtss2-rc0 pn policykit-1 pn systemd-container Versions of packages systemd is related to: ii dbus-user-session 1.12.20-2 pn dracut ii initramfs-tools0.140 ii libnss-systemd 250.4-1~bpo11+1 ii libpam-systemd 250.4-1~bpo11+1 ii udev 247.3-7 -- Configuration Files: /etc/systemd/logind.conf changed: [Login] HandleLidSwitch=ignore HandleLidSwitchDocked=ignore -- no debconf information
Bug#743228: ifupdown: IPv6 Address doesn't get configured at/after boot
El 28/04/22 a las 18:56, Jan Christoph Uhde escribió: > Hi, > > I have the same problem with vlan interfaces: > > ``` > » cat /etc/network/interfaces > # interfaces(5) file used by ifup(8) and ifdown(8) > > # Please note that this file is written to be used with dhcpcd > # For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf' > > # Include files from /etc/network/interfaces.d: > source-directory /etc/network/interfaces.d > > # loopback > > auto lo > iface lo inet loopback > iface lo inet6 loopback > > # physical adapter > > auto eth0 > iface eth0 inet manual > iface eth0 inet6 manual > > > # internal ethernet (vlan) > # > auto eth0.1 > iface eth0.1 inet static > address 10.xx.xx.xx > netmask 255.255.255.0 > > > #will use the requested prefix > iface eth0.1 inet6 manual > > > # fritx.box ethernet (vlan) > > auto eth0.2 > iface eth0.2 inet static > address 192.xx.xx.xx > netmask 255.255.255.0 > network 192.xx.xx.xx > broadcast 192.xx.xx.255 > gateway 192.xx.xx.xx > iface eth0.2 inet6 auto > request_prefix 1 > mtu 1492 > dhcp 1 > accept_ra 2 > ``` > > Can you give me some what to do to not get the link local addresses only. Could you please give us the output of `ifup eth0.2 -v`? -- S signature.asc Description: PGP signature
Bug#1010362: cruft-ng: Segmentation fault in cruft-ng
Package: cruft-ng
Version: 0.4.52
Severity: normal
X-Debbugs-Cc: richard...@gmail.com
I had created a dpkg local diversion using the command -
dpkg-divert --divert /etc/PackageKit/20packagekit.distrib --rename
/etc/apt/apt.conf.d/20packagekit
The output of the command "dpkg-divert --list" command is now -
diversion of /usr/share/dict/words to
/usr/share/dict/words.pre-dictionaries-common by dictionaries-common
diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz
by dash
local diversion of /etc/apt/apt.conf.d/20packagekit to
/etc/PackageKit/20packagekit.distrib
diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr
diversion of /bin/sh to /bin/sh.distrib by dash
When I run cruft-ng version 0.4.52 on the system it crashes with Segmentation
fault
Below is the relevant part of the output (in gdb, with DEBUG variable set to 1)
Note that the output of "dpkg-divert --list" does not show a package name for
the local diversion. The code parsing the output in dpkg_open() always assumes
that there is one. (If the dpkg local diversion is removed, cruft-ng completes
successfully)
...
READING FILES IN DPKG DATABASE
[Detaching after vfork from child process 104913]
diversion of /usr/share/dict/words to
/usr/share/dict/words.pre-dictionaries-common by dictionaries-common
diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz
by dash
local diversion of /etc/apt/apt.conf.d/20packagekit to
/etc/PackageKit/20packagekit.distrib
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:133
Download failed: Invalid argument. Continuing without source file
./string/../sysdeps/x86_64/multiarch/strlen-vec.S.
133 ../sysdeps/x86_64/multiarch/strlen-vec.S: No such file or directory.
(gdb) bt
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-vec.S:133
#1 0x55568e8c in std::char_traits::length (__s=0x0)
at /usr/include/c++/11/bits/char_traits.h:399
#2 std::__cxx11::basic_string,
std::allocator >::assign (__s=0x0, this=0x7fffcb20)
at /usr/include/c++/11/bits/basic_string.h:1459
#3 std::__cxx11::basic_string,
std::allocator >::operator= (__s=0x0, this=0x7fffcb20)
at /usr/include/c++/11/bits/basic_string.h:690
#4 read_diversions (diversions=std::vector of length 2, capacity 2 = {...})
at ./dpkg_popen.cc:66
#5 0x555696ee in read_dpkg_items (
dpkg=std::vector of length 0, capacity 0) at ./dpkg_popen.cc:83
#6 0x8b5d in main (argc=, argv=)
at ./cruft.cc:258
(gdb)
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cruft-ng depends on:
ii cruft-common 0.9.42
ii libc6 2.33-7
ii libgcc-s1 12-20220319-1
ii libstdc++612-20220319-1
ii plocate 1.1.15-2
cruft-ng recommends no packages.
cruft-ng suggests no packages.
-- no debconf information
Bug#1010265: [pkg-lua-devel] Bug#1010265: CVE-2022-28805
Am Fri, Apr 29, 2022 at 07:49:15AM +0300 schrieb Sergei Golovan: > > This was assigned CVE-2022-28805: > > https://github.com/lua/lua/commit/1f3c6f4534c6411313361697d98d1145a1f030fa > > http://lua-users.org/lists/lua-l/2022-02/msg1.html > > http://lua-users.org/lists/lua-l/2022-02/msg00070.html > > > > Can you please check whether this also affects the older Lua versions > > in the archive? > > This bug is related to the variables which have been introduced in > Lua 5.4, so it doesn't affect the earlier versions. Thanks, I've updated the Debian security tracker. > It does affect Lua 5.4.2 in stable though. > > I'll fix it in unstable shortly. Do I need to prepare a fix for stable? It doesn't need a DSA IMO. Could be fixed via a point release or we fix it along when there's a more severe Lua issue in the future? Cheers, Moritz
Bug#508053: please provide 'host'
Control: tag -1 + wontfix [Replying to a bug report which is more than 10 years old..] On Tue, 21 Jul 2009 19:13:06 +0200 martin f krafft wrote: .. > if the use case is 'lookup a DNS record and print it like > bind9-host does' then bind9-host and unbound-host fit that > description. Right. And it also supports all of the features of host and bind9-host, I think, so once you have unbound-host installed, the others aren't really necessary anymore, are they? 10+ years has passed but unbound-host does not provide the same or even similar functionality as bind9-host. Yes it prints DNS records, but the interface and the defaults are quite a bit different, to a point when you can't substitute one for the other. So marking as wontfix for now. We can probably make it a low-priority alternative for "host" if we had such alternative, - but we don't, iirc. There are other tools of this theme too, eg my dnsget (udns-utils package). /mjt
Bug#1010205: git-buildpackage: gbp import-orig does not store upstream signature in pristine-tar branch
Hi, I put a debug print into pkg/pristinetar.py. It looks like the commit function is not invoked with a signaturefile argument. Regards, Tino
Bug#1010361: netw-ib-ox-ag: FTBFS on riscv64: Could not guess NETWIBDEF_SYSARCH
Source: netw-ib-ox-ag Version: 5.39.0-1.4 Severity: normal Tags: patch, ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear Maintainer, net-ib-ox-ag has ftbfs on riscv64: ``` ... -e 's|NETWIBDEF_INSTPREFIX=.*$|NETWIBDEF_INSTPREFIX=/usr|g' \ src/netwib-src/src/config.dat cd src/netwib-src/src && ./genemake && cd ../../.. Netwib version 5.39.0 (5 39 0) Loading config.dat System name selection NETWIBDEF_SYSNAME=Linux System architecture selection Error: Could not guess NETWIBDEF_SYSARCH. Edit genemake to set NETWIBDEF_SYSARCH, and rerun genemake. Please contact Laurent to permanently solve this problem. make: *** [debian/rules:30: build-stamp] Error 1 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 ... ``` The full buildd log is: https://buildd.debian.org/status/fetch.php?pkg=netw-ib-ox-ag=riscv64=5.39.0-1.4=1651106576=0 The patch that i have build on riscv64 successfully locally. if you need me to do test about it, please tell me. I have riscv64 real hardware by hand. BR, Bo add support for riscv64 arch --- a/src/netwib-src/src/genemake +++ b/src/netwib-src/src/genemake @@ -127,6 +127,9 @@ sh* ) NETWIBDEF_SYSARCH="sh" ;; + "riscv64" ) +NETWIBDEF_SYSARCH="riscv64" +;; * ) echo "Error: Could not guess NETWIBDEF_SYSARCH."; echo "Edit genemake to set NETWIBDEF_SYSARCH, and rerun genemake."; @@ -2090,7 +2093,7 @@ errorcode=\$2 cat <
Bug#1010329: libwebkit2gtk-4.0-37: DSA-5115-1 for i386
On Fri, Apr 29, 2022 at 03:06:49PM +1000, Paul Szabo wrote:
> I have some 32- and 64-bit machines, so with i386 and amd64
> architectures, all at bullseye. I notice that updated webkit2gtk
> packages were released for amd64 with version 2.36.0-3~deb11u1,
> but that i386 is still "stuck" at 2.34.6-1~deb11u1.
> Does this indicate some problem?
Thanks for the report,
there is indeed a problem, a bug in the version of clang available in
bullseye is causing build failures in i386 and mipsel:
int main(int argc, char *argv[])
{
long long result;
return __builtin_smulll_overflow(argc, 5, );
}
This fails to build with:
/usr/bin/ld: /tmp/test-7a89b4.o: in function `main':
test.c:(.text+0x47): undefined reference to `__mulodi4'
It will be worked around in the next upload.
Berto
Bug#641704: unbound-host should be preconfigured with DNS root trust anchor
There is another difference between /var/lib/unbound/root.key and /usr/share/dns/root.key: their respective source of update. The former normally starts its life as a copy of the later but is then managed using RFC 5011 to cope with root KSK rollovers. The later being changed only via package updates. I think Debian needs to settle on a way to deal with the root KSK updates. The current state of having unbound maintain it's own copy feels awkward, IMHO. A possible simplification would be to have all the packages simply consult the read-only copy provided by dns-root-data. This would imply changing `/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf` from unbound's package and turn it into: trust-anchor-file: "/usr/share/dns/root.key" To tell it not to do RFC 5011 maintenance. That way, root KSK refresh would only come from dns-root-data updates. My 2 cents, Simon
Bug#900241: no root.key provided by libunbound2
On 2022-04-28 13:02, Michael Tokarev wrote: Control: tag -1 + moreinfo So, will adding a Recommends: dns-root-data either to libunbound or to various software packages (eg unbound-host) fix this? dns-root-data doesn't put the key where unbound-host expects it though: # unbound-host -D google.com [1651242475] libunbound[100:0] error: error opening file /var/lib/unbound/root.key: No such file or directory [1651242475] libunbound[100:0] error: error reading trust-anchor-file: /var/lib/unbound/root.key [1651242475] libunbound[100:0] error: validator: error in trustanchors config [1651242475] libunbound[100:0] error: validator: could not apply configuration settings. [1651242475] libunbound[100:0] error: module init for module validator failed resolve error: initialization failure Since unbound-host only reads the root.key, maybe it could be told to fallback to reading it from /usr/share/dns/root.key. I'm suggesting to doing it as fallback only because that file isn't subject to RFC 5011 maintenance, only package updates will bring fresh KSK. I suspect that for some environments the distinction could matter. Simon
Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer
El 28/04/22 a las 18:17, Christian Göttsche escribió: > Upstream release a new version 1.17. > Prepared a new upload, with d/watch changes and upstream signature added. > > ncdu (1.17-0.1) unstable; urgency=medium > . >* Non-maintainer upload. >* New upstream version 1.17 (Closes: #996240) >* d/control: > - update build dependencies >+ replace transitional libncurses5-dev and libncursesw5-dev by > libncurses-dev >+ add pkg-config for successful autoreconf >+ drop autotools-dev, default since debhelper compat 10 > - bump to debhelper compat 13 > - bump to std-ver 4.6.0 (no further changes) > - set Rules-Requires-Root no > - use https homepage address >* d/rules: enable hardening and LTO >* d/u/signing-key.asc: add upstream gpg key >* d/watch: > - use https > - bump to format version 4 > - fix to upstream version 1, since version 2 is a reimplementation in >the Zig language > - add pgpsigurlmangle option >* d/u/metadata: add basic metadata > > > > Did not understand > > > >* New upstream version 1.16 > > versus > > > >* d/patches: cherry-pick upstream commits > > These are now included in 1.17 and such dropped from d/patches. > Uploaded to DELAYED/10. Thanks again, -- S signature.asc Description: PGP signature
Bug#641704: unbound-host should be preconfigured with DNS root trust anchor
This is interesting from a few other points of view. unbound-host should probably not use /var/lib/unbound/root.key which is an untrusted-owned file in an untrusted-owned directory. So probably the default value for this root.key file should not point to this location. We probably can change both unbound-host and unbound-anchor to use /usr/share/dns/root.key - the same location as shipped by dns-root-data. And keep unbound-owned file as it is now (which is configured in /etc/unbound/unbound.conf*). On the other hand, if we have a more recent file in the unbound libdir than the one shipped by dns-root-data, or if we do not have dns-root-data installed in the first place, we can use that unbound-owned file too. But see the first point above. I think I'll just move it to /usr/share/dns/root.key, that sounds like the best course of action here. Thanks, /mjt
Bug#1010357: gnome-shell: Gnome settings by gnome-control-center and other apps abort with SIGSEGV
I see you're using i386 instead of amd64. Do you still have this bug with amd64? Thank you, Jeremy Bicha
Bug#1008112: Source is duplicated with golang-mvdan-sh
Hi Christoph, On 29 April 2022 5:47:01 pm IST, Christoph Biedl wrote: >Marcos Talau wrote... > >> I will make the package orphaned. Feel free to manage it. > >... but then nothing happened. Today I found shfmt and consider it a >useful tool, hence I'm interested to see it in Debian, and in good >state - which shfmt is no longer as it dropped out of testing. > >So, are you still interested in having it under the Go packaging team >umbrella? Speaking for myself: with the sort of hostile response I've got from the former maintainer despite being nice to them and the lack of communication at their end, I've no interest in working on this further, and wouldn't reply to any mail on the same. >As a last resort, but no earlier, I might take maintainership >as well. But it will be outside the team then. Sure, please go ahead with the same if you feel like. One request though: please also create a (library)-dev binary package for the same. I'll then ask for a removal for golang-mvdan-sh which would effectively help close this bug which we are talking at. Best, Nilesh
Bug#1010352: wpewebkit: No longer provides libsoup2 version needed by gstreamer
On Fri, Apr 29, 2022 at 06:56:45AM -0400, Jeremy Bicha wrote: > wpewebkit has 2 reverse dependencies in Debian: cog and > gstreamer1.0-wpe. Although cog was switched to use the new libsoup3, > gstreamer1.0-wpe was not. This is already fixed: https://bugs.debian.org/1009721 It was planned with the gst maintainer so it should have been seamless but I guess we failed :-/ > Also, the package names in debian/control do not match the actual > package names built. I believe this is a violation of Debian Policy. > (Also it appears to break Ubuntu's NBS tracker.) It lists both versions but we only build one or the other depending on the target distro. If it causes breakage I guess I'll change it. > I suggest you do like webkit2gtk and offer both libsoup2 and > libsoup3 for now if you want to have the libsoup3 version available. No need to do that since there's only two reverse dependencies. Berto
Bug#1010360: Set-systemwide-default-settings-for-libssl-users.patch is broken (duplicate key for openssl_conf)
Package: openssl Version: 3.0.2-1 The openssl.cnf contains an entry for openssl_conf since #12333 [1]. The attached patch-file should work but I haven't tested it yet. [1] https://github.com/openssl/openssl/pull/12333 From: Sebastian Andrzej Siewior Date: Tue, 20 Mar 2018 22:07:30 +0100 Subject: Set systemwide default settings for libssl users This config change enforeces a TLS1.2 protocol version as minimum. It can be overwritten by the system administrator. It also changes the default security level from 1 to 2, moving from the 80 bit security level to the 112 bit security level. Signed-off-by: Sebastian Andrzej Siewior --- apps/openssl.cnf | 13 + 1 file changed, 13 insertions(+) --- a/apps/openssl.cnf +++ b/apps/openssl.cnf @@ -52,6 +52,7 @@ [openssl_init] providers = provider_sect +ssl_conf = ssl_sect # List of providers to load [provider_sect] @@ -388,3 +389,10 @@ # Certificate revocation cmd = rr oldcert = $insta::certout # insta.cert.pem + +[ssl_sect] +system_default = system_default_sect + +[system_default_sect] +MinProtocol = TLSv1.2 +CipherString = DEFAULT@SECLEVEL=2 smime.p7s Description: S/MIME cryptographic signature
Bug#1008112: Source is duplicated with golang-mvdan-sh
Hi, On Fri, Apr 29, 2022 at 8:25 PM Christoph Biedl wrote: > > Marcos Talau wrote... > > > I will make the package orphaned. Feel free to manage it. > > ... but then nothing happened. Today I found shfmt and consider it a > useful tool, hence I'm interested to see it in Debian, and in good > state - which shfmt is no longer as it dropped out of testing. > > So, are you still interested in having it under the Go packaging team > umbrella? As a last resort, but no earlier, I might take maintainership > as well. But it will be outside the team then. > I planned to merge this when shfmt has a new upstream release. However it seems more urgent now since it was removed from testing the last few days. -- Shengjing Zhu
Bug#1008997: [OpenPrinting/ipp-usb] ipp-usb is not ready for this device (Issue #48)
On Thu 28 Apr 2022 at 10:18:24 +0200, alain wrote: Alain, Take a look at github. The mail below does not appear to have made it through to there. I suggest you put it directly into github. Cheers, Brian. > hello alexander pevzner . > > I will try to answer your 4 questions clearly: > > 1) combinations that work : > - stable kernel with stable ipp-usb > - kernel testing / sid with ipp-usb stable version > > > 2) combinations that definitely don't work: > - kernel testing / sid with ipp-usb (testing / sid version) > > once my printer is plugged , system-config-printer do not recognize it . > > i can not print even a test page . and never see the printer icon . > > > 3) when it works, it works constantly. > system-config-printer is constantly fully functional. > > once i plug in my printer (or power it on) , after a very short delay , > > system-config-printer recognize it and i can print a test page and my > documents . > > i see the printer icon and it is fully functional . > > > 4) when it doesn't work, it's definitive. it doesn't work. > > system-config-printer never recognize it and i can not print even a test > page > > apparmor seems to do nothing with the testing/sid version of ipp-usb . > > > I answered your questions as you wanted? > Did it help you ? > > friendly, > respectfully, > > alain. > > > nb: for instance , i am working with the stable version of ipp-usb and all > is nearly perfect . > > under 5.17 kernel . my system is constantly up-to-date (sid) . > > > in case of , sorry for the flood . > > > Le 28/04/2022 à 09:58, alain a écrit : > > > > re , > > > > up . > > > > > > Le 27/04/2022 à 13:02, alain a écrit : > > > > > > hello alexander pevzner . > > > > > > I will try to answer your 4 questions clearly: > > > > > > 1) combinations that work : > > > - stable core with stable ipp-usb > > > - kernel testing / sid with ipp-usb stable > > > > > > 2) combinations that definitely don't work: > > > - kernel testing / sid with ipp-usb (testing / sid version) > > > > > > 3) when it works, it works constantly. > > > system-config-printer is constantly fully functional. > > > > > > 4) when it doesn't work, it's definitive. it doesn't work. > > > > > > I answered your questions as you wanted? > > > Did it help you ? > > > > > > friendly, > > > respectfully, > > > alain. > > > > > > > > > > > > Translated with www.DeepL.com/Translator (free version) > > > > > > Le 27/04/2022 à 11:45, Alexander Pevzner a écrit : > > > > > > > > 1. Is there any configuration (combination of kernel version and > > > > ipp-usb version), that *definitely works*? > > > > 2. Is there any configuration, that *definitely doesn't work*? > > > > 3. When it works, does it work reliable or time to time? > > > > 4. When it doesn't work, doesn't it work always or time to time? > > > >
Bug#1010359: node-ejs: CVE-2022-29078 server-side template injection
Source: node-ejs Version: 3.1.6-3 Severity: important Tags: security X-Debbugs-Cc: codeh...@debian.org, Debian Security Team Hi, The following vulnerability was published for node-ejs. CVE-2022-29078[0]: | The ejs (aka Embedded JavaScript templates) package 3.1.6 for Node.js | allows server-side template injection in settings[view | options][outputFunctionName]. This is parsed as an internal option, | and overwrites the outputFunctionName option with an arbitrary OS | command (which is executed upon template compilation). 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-29078 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29078 Please adjust the affected versions in the BTS as needed. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#697630: Can't include changes files which contain a duplicate arch all
Hello Bernhard, On Fri, 27 Jan 2017 04:45:06 +0800 Andrew Lee (李健秋) wrote: I am writting to request for a re-review for the latest patch to support auto builder like Open Build Service. As we have been using Open Build Service together with this patched reprepro at a production environment since the patch available. The patch works quite well for us in practice. The Open Build Service package is now available for stretch: https://packages.qa.debian.org/o/open-build-service.html So it would be really really nice to have this patch re-reviewed and included in reprepro package to make Open Build Service more useful in stretch. Could you please have a look at the latest revision of the patch by Simon? As Andrew pointed out, this feature an important use case, and we’ve been using reprepro with this patch for quite a few years with no issues. -- Cheers, Andrej
Bug#1010356: closed by David Kalnischkies (Re: Bug#1010356: apt: PATH messed up by apt eg starting with /usr/local/sbin in PATH)
Hi Many thanks and apologies - several googles didn't find this answer!!! Nick On 29/04/2022 13:39, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the apt package: #1010356: apt: PATH messed up by apt eg starting with /usr/local/sbin in PATH It has been closed by David Kalnischkies . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact David Kalnischkies by replying to this email.
Bug#1010358: ugene: Fix for non-constant SIGSTKSZ
Package: ugene
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Dear Maintainer,
ugene 40.1+dfsg-1 fails to build on Ubuntu.
* Fix for non-constant SIGSTKSZ (LP: #1970417)
* Build on amd64 only.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-27-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ugene-40.1+dfsg/debian/control ugene-40.1+dfsg/debian/control
--- ugene-40.1+dfsg/debian/control 2021-10-19 12:55:46.0 +0200
+++ ugene-40.1+dfsg/debian/control 2022-04-26 14:25:30.0 +0200
@@ -1,9 +1,9 @@
Source: ugene
-Maintainer: Debian Med Packaging Team
+Maintainer: Maintainer: Debian Med Packaging Team
Uploaders: Steffen Moeller ,
Andreas Tille ,
Olivier Sallou
-Section: non-free/science
+Section: multiverse/science
XS-Autobuild: yes
Priority: optional
Build-Depends: qtbase5-dev,
@@ -30,7 +30,7 @@
Rules-Requires-Root: no
Package: ugene
-Architecture: any
+Architecture: amd64
Depends: ${shlibs:Depends},
ugene-data,
${misc:Depends}
diff -Nru ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
--- ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
1970-01-01 01:00:00.0 +0100
+++ ugene-40.1+dfsg/debian/patches/Fix-for-non-constant-SIGSTKSZ.patch
2022-04-26 14:24:36.0 +0200
@@ -0,0 +1,32 @@
+From: David Faure
+Date: Wed, 15 Dec 2021 22:26:40 +0100
+Subject: [PATCH] Fix for non-constant SIGSTKSZ
+
+On glibc > 2.33, `SIGSTKSZ` might not be constant (in which case
+it expands to a call to `sysconf` which returns a `long int`); see
+https://sourceware.org/pipermail/libc-alpha/2020-October/118513.html
+
+Pass unsigned explicitly to std::max, to avoid relying on template
+argument deduction. This works both with the old-style constant
+`SIGSTKSZ` and the new configurable one.
+
+Initially based on https://chromium-review.googlesource.com/c/2776379
+
+Change-Id: I9fc95337f973e871b84735ce822b5e11ba73ea8c
+Reviewed-on:
https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3340721
+Reviewed-by: Mark Mentovai
+---
+ src/client/linux/handler/exception_handler.cc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/libs_3rdparty/breakpad/src/client/linux/handler/exception_handler.cc
b/src/libs_3rdparty/breakpad/src/client/linux/handler/exception_handler.cc
+@@ -141,7 +141,7 @@
+ // SIGSTKSZ may be too small to prevent the signal handlers from overrunning
+ // the alternative stack. Ensure that the size of the alternative stack is
+ // large enough.
+- static const unsigned kSigStackSize = std::max(16384, SIGSTKSZ);
++ const unsigned kSigStackSize = std::max(16384, SIGSTKSZ);
+
+ // Only set an alternative stack if there isn't already one, or if the
current
+ // one is too small.
diff -Nru ugene-40.1+dfsg/debian/patches/series
ugene-40.1+dfsg/debian/patches/series
--- ugene-40.1+dfsg/debian/patches/series 2021-10-19 12:55:46.0
+0200
+++ ugene-40.1+dfsg/debian/patches/series 2022-04-26 14:25:30.0
+0200
@@ -3,3 +3,4 @@
do_not_build_phylip.patch
# only partly addressed by upstream
use_debian_sqlite.patch
+Fix-for-non-constant-SIGSTKSZ.patch
Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows
Hi, I have a very similar bug where kwin-x11 crashes, I get logged out, but have to manually kill kwin. But that bug appeared just recently (I'm using kwin-x11 5.24.4-1 from unstable). Usually after logging in I use a hotkey to go through all windows that want attention (after logging in it is all of them) and around half the time I do this kwin crashes. This maybe happens because I switch too fast through the windows? I haven't found any error yet, but this could be related. Best regards Matthias
Bug#1010357: gnome-shell: Gnome settings by gnome-control-center and other apps abort with SIGSEGV
Package: gnome-shell Version: 42.0-4 Severity: important Dear Maintainer, As can be displayed by Firefox gnome-shell with wayland is using ES 2.0: WebGL 1 Driver Renderer Intel Open Source Technology Center -- Mesa DRI Intel(R) 945GM x86/MMX/SSE2 WebGL 1 Driver Version OpenGL ES 2.0 Mesa 21.3.8 With the current gnome-shell version 42.0-4 many/all graphical gnome apps like gnome-clocks, baobab, gnome-character abort with segmentation failure. Probably this is caused by using GL_HALF_FLOAT, which is not supported by ES 2.0. The coredump shows address data is NULL. A forced abort at _mesa_error shows it is caused by gtk-4. At gsk/gl/gskglcommandqueue.c exist the lines: glVertexAttribPointer (2, 4, GL_HALF_FLOAT, GL_FALSE, and glVertexAttribPointer (3, 4, GL_HALF_FLOAT, GL_FALSE, gert@debian:~$ gnome-control-center Mesa: User error: GL_INVALID_ENUM in glVertexAttribPointer(type = GL_HALF_FLOAT) Segmentation fault (core dumped) Core was generated by `gnome-control-center'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xa623fdf6 in run_vp (ctx=0xa4b6a010, stage=0x1594998) at ../src/mesa/tnl/t_vb_program.c:365 365 COPY_CLEAN_4V(machine->VertAttribs[attr], size, data); [Current thread is 1 (Thread 0xaf0fc3c0 (LWP 4969))] (gdb) bt #0 0xa623fdf6 in run_vp (ctx=0xa4b6a010, stage=0x1594998) at ../src/mesa/tnl/t_vb_program.c:365 #1 0xa6236826 in _tnl_run_pipeline (ctx=0xa4b6a010) at ../src/mesa/tnl/t_pipeline.c:241 #2 0xa617e759 in intelRunPipeline (ctx=0xa4b6a010) at ../src/mesa/drivers/dri/i915/intel_tris.c:1087 #3 0xa6235ad7 in _tnl_draw_prims (ctx=0xa4b6a010, arrays=0x15957c0, prim=0xbf9261dc, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=, max_index=, num_instances=1, base_instance=0) at ../src/mesa/tnl/t_draw.c:528 #4 0xa633d09a in _mesa_draw_gallium_fallback (ctx=0xa4b6a010, info=0xbf926244, drawid_offset=0, draws=0xbf926238, num_draws=1) at ../src/mesa/main/draw.c:1016 #5 0xa633beac in _mesa_draw_arrays (ctx=0xa4b6a010, mode=, start=, count=6, numInstances=1, baseInstance=0) at ../src/mesa/main/draw.c:1319 #6 0xb7575bc2 in () at /lib/i386-linux-gnu/libgtk-4.so.1 #7 0xb758f594 in () at /lib/i386-linux-gnu/libgtk-4.so.1 #8 0xb7570fa1 in () at /lib/i386-linux-gnu/libgtk-4.so.1 #9 0xb755952e in gsk_renderer_render () at /lib/i386-linux-gnu/libgtk-4.so.1 #10 0xb73d82dc in () at /lib/i386-linux-gnu/libgtk-4.so.1 #11 0xb73df3e0 in () at /lib/i386-linux-gnu/libgtk-4.so.1 #12 0xb74dae86 in () at /lib/i386-linux-gnu/libgtk-4.so.1 #13 0xb7ce0056 in () at /lib/i386-linux-gnu/libgobject-2.0.so.0 #14 0xb7cf7c01 in g_signal_emit_valist () at /lib/i386-linux- gnu/libgobject-2.0.so.0 #15 0xb7cf8915 in g_signal_emit () at /lib/i386-linux-gnu/libgobject-2.0.so.0 #16 0xb750827e in () at /lib/i386-linux-gnu/libgtk-4.so.1 #17 0xb7ce0056 in () at /lib/i386-linux-gnu/libgobject-2.0.so.0 #18 0xb7cf87bc in g_signal_emit_valist () at /lib/i386-linux- gnu/libgobject-2.0.so.0 #19 0xb7cf8915 in g_signal_emit () at /lib/i386-linux-gnu/libgobject-2.0.so.0 #20 0xb74f7045 in () at /lib/i386-linux-gnu/libgtk-4.so.1 #21 0xb74f7fb9 in () at /lib/i386-linux-gnu/libgtk-4.so.1 #22 0xb7bcc101 in () at /lib/i386-linux-gnu/libglib-2.0.so.0 #23 0xb7bcb4a9 in g_main_context_dispatch () at /lib/i386-linux- gnu/libglib-2.0.so.0 #24 0xb7bcb879 in () at /lib/i386-linux-gnu/libglib-2.0.so.0 #25 0xb7bcb944 in g_main_context_iteration () at /lib/i386-linux- gnu/libglib-2.0.so.0 #26 0xb7e0f603 in g_application_run () at /lib/i386-linux-gnu/libgio-2.0.so.0 #27 0x00467df9 in main () (gdb) f 0 #0 0xa623fdf6 in run_vp (ctx=0xa4b6a010, stage=0x1594998) at ../src/mesa/tnl/t_vb_program.c:365 365 COPY_CLEAN_4V(machine->VertAttribs[attr], size, data); (gdb) p data $1 = (const GLfloat *) 0x0 Forced abort at _mesa_error: Core was generated by `gnome-control-center'. Program terminated with signal SIGABRT, Aborted. #0 0xb7f34559 in __kernel_vsyscall () [Current thread is 1 (Thread 0xaf0a33c0 (LWP 19873))] (gdb) bt #0 0xb7f34559 in __kernel_vsyscall () #1 0xb5c7e8f6 in __libc_signal_restore_set (set=0xbfc20a8c) at ../sysdeps/unix/sysv/linux/internal-signals.h:105 #2 __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:47 #3 0xb5c6730b in __GI_abort () at abort.c:79 #4 0xa59ed08d in _mesa_error (ctx=, error=, fmtString=) at ../src/mesa/main/errors.c:353 #5 0xa5ae81ca in validate_array_format (ctx=0xa4210010, func=0xa62df2d1 "glVertexAttribPointer", legalTypesMask=, sizeMin=1, sizeMax=4, size=4, type=5131, normalized=false, integer=false, doubles=false, relativeOffset=0, format=6408, attrib=, vao=) at ../src/mesa/main/varray.c:711 #6 0xa5ae86fc in validate_array_and_format (ctx=ctx@entry=0xa4210010, func=func@entry=0xa62df2d1 "glVertexAttribPointer", vao=, obj=, legalTypes=, sizeMin=, sizeMax=out>, size=, type=, stride=, normalized=, integer=, doubles=0 '\000', format=6408, ptr=0x10, attrib=17) at ../src/mesa/main/varray.c:872 #7 0xa5aeb17d in _mesa_VertexAttribPointer (index=2, size=4, type=5131, normalized=0 '\000',
Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input
notfixed 6.0-26 Correction: the issue also affects 6.0-26, but is only reproducible after export LANG=C Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Bug#1008112: Source is duplicated with golang-mvdan-sh
Marcos Talau wrote... > I will make the package orphaned. Feel free to manage it. ... but then nothing happened. Today I found shfmt and consider it a useful tool, hence I'm interested to see it in Debian, and in good state - which shfmt is no longer as it dropped out of testing. So, are you still interested in having it under the Go packaging team umbrella? As a last resort, but no earlier, I might take maintainership as well. But it will be outside the team then. Christoph signature.asc Description: PGP signature
Bug#1010202: libmatio: FTBFS against hdf5 1.12.0 currently in experimental - 3 failed tests
Hi Sébastien, Sébastien Villemot a écrit le 29/04/2022 à 11:45 : Hi Gilles, Le mardi 26 avril 2022 à 10:38 +0200, Gilles Filippini a écrit : Source: libmatio Version: 1.5.23-1 Severity: important Tags: ftbfs While rebuilding libmatio 1.5.23 against hdf5 1.12.0, 3 testcases failed with: […] I had an exchange with upstream, who says that libmatio 1.5.23 should pass all tests against hdf5 1.12.2. Is there any reason why you’re sticking to hdf5 1.12.0 instead of the latest stable release 1.12.2? No, no reason. I wanted to transition 1.12.0 before switching to 1.12.2, but the other way should be fine as well. I'll give it a try. Thanks, _g.
Bug#1010104: cqrlog: missing AppStream metadata
On Tue, 26 Apr 2022 20:44:10 -0700 tony mancill wrote: > On Sun, Apr 24, 2022 at 03:58:48PM +0200, asciiw...@seznam.cz wrote: > > Package: cqrlog > > Version: 2.5.2-1 > > > > The cqrlog package has no AppStream metadata file although this file is > > already present in upstream[1]. Please, consider adding this file. > > > > [1] https://github.com/ok2cqr/cqrlog/blob/master/tools/cqrlog.appdata.xml > > Hi, > > I see the file in the current Debian package: > > $ debc cqrlog_2.5.2-1_amd64.changes | grep appdata.xml > -rw-r--r-- root/root 1266 2022-01-11 08:26 > ./usr/share/metainfo/cqrlog.appdata.xml > > And I also see the metadata registered for bookworm (Debian testing): > > https://appstream.debian.org/bookworm/main/metainfo/cqrlog.html > > Is there some other place where it should be included? > > Cheers, > tony Hi, ah, the AppData file seems to be in the cqrlog-data package (along with desktop icon files), not the main cqrlog one. I am however not sure whether this is supported by GNOME Software / KDE Discover and the Debian/Ubuntu AppStream generator itself[1]. GNOME Software on Ubuntu 22.04 (which uses cqrlog 2.5.2-1 package synced from Debian) does not seem to display valid metadata for the cqrlog package - it uses autogenerated metadata from its desktop file (and no icon) instead. Daniel [1] https://appstream.debian.org/bookworm/main/issues/cqrlog.html
Bug#1010356: apt: PATH messed up by apt eg starting with /usr/local/sbin in PATH
Package: apt
Version: 2.2.4
Severity: normal
Dear Maintainer,
* What led up to the situation?
My postinstall fails to find a called script in /usr/local/sbin
* What exactly did you do (or not do) that was effective (or
ineffective)?
Test using dpkg directly - note PATH shown in DEBUG line:
root@TSB-168:/home/am43# dpkg -i
itrackbox-bluetooth-3.2.1-20220429.112606.7359946.deb
(Reading database ... 32911 files and directories currently installed.)
Preparing to unpack itrackbox-bluetooth-3.2.1-20220429.112606.7359946.deb ...
/var/lib/dpkg/info/itrackbox-bluetooth.prerm DEBUG
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Unpacking itrackbox-bluetooth (3.2.1-20220429.112606.7359946) over
(3.2.1-20220429.112313.7c03e96) ...
Setting up itrackbox-bluetooth (3.2.1-20220429.112606.7359946) ...
/var/lib/dpkg/info/itrackbox-bluetooth.postinst DEBUG
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
and same package via apt:
root@TSB-168:/home/am43# apt install --reinstall
./itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'itrackbox-bluetooth' instead of
'./itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb'
The following packages will be DOWNGRADED:
itrackbox-bluetooth
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 0 B/8308 B of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 /home/am43/itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb
itrackbox-bluetooth armhf 3.2.1-20220429.112313.7c03e96 [8308 B]
dpkg: warning: downgrading itrackbox-bluetooth from
3.2.1-20220429.112606.7359946 to 3.2.1-20220429.112313.7c03e96
(Reading database ... 32911 files and directories currently installed.)
Preparing to unpack .../itrackbox-bluetooth-3.2.1-20220429.112313.7c03e96.deb
...
/var/lib/dpkg/info/itrackbox-bluetooth.prerm DEBUG /usr/sbin:/usr/bin:/sbin:/bin
Unpacking itrackbox-bluetooth (3.2.1-20220429.112313.7c03e96) over
(3.2.1-20220429.112606.7359946) ...
Setting up itrackbox-bluetooth (3.2.1-20220429.112313.7c03e96) ...
/var/lib/dpkg/info/itrackbox-bluetooth.postinst DEBUG
/usr/sbin:/usr/bin:/sbin:/bin
root@TSB-168:/home/am43#
* What was the outcome of this action?
My postinst script fails unless I call scripts using full path
* What outcome did you expect instead?
PATH should not be messed with
-- Package-specific info:
-- (no /etc/apt/preferences present) --
-- (no /etc/apt/preferences.d/* present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- (/etc/apt/sources.list.d/itrack.list present, but not submitted) --
-- System Information:
Debian Release: 11.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 5.4.106-itb3.03 (PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2021.1.1
ii gpgv2.2.27-2+deb11u1
ii libapt-pkg6.0 2.2.4
ii libc6 2.31-13+deb11u3
ii libgcc-s1 10.2.1-6
ii libgnutls30 3.7.1-5
ii libseccomp2 2.5.1-1+deb11u1
ii libstdc++6 10.2.1-6
ii libsystemd0 247.3-7
Versions of packages apt recommends:
ii ca-certificates 20210119
Versions of packages apt suggests:
pn apt-doc
pn aptitude | synaptic | wajig
ii dpkg-dev 1.20.9
ii gnupg2.2.27-2+deb11u1
pn powermgmt-base
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Bug#1010346: linux-image-cloud-amd64: Enable CONFIG_FB_EFI=y in Buster Cloud Kernel
Hi Vasudev On Fri, Apr 29, 2022 at 03:27:26PM +0530, Vasudev Kamath wrote: > Booting a KVM based VM with UEFI enabled using Buster image with cloud kernel > will have > a non working VNC console. Console seems to be frozen on debugging we figured > out that > its because buster cloud kernel does not have CONFIG_FB_EFI enabled. The cloud kernel is marked for specific environments only. All of them use the serial console first. > This issue is not present in Bullseye kernel as it was enabled in following > commit [1]. > Can we also enable same option for Buster cloud kernel?. Else for using VNC > like console > VM image needs to be running regular kernel (linux-image-amd64). Buster is in maintenance mode. So, why? Bastian -- Time is fluid ... like a river with currents, eddies, backwash. -- Spock, "The City on the Edge of Forever", stardate 3134.0
Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input
El 29/4/22 a las 13:27, Enrico Zini escribió: Package: unzip Version: 6.0-21+deb9u2 Severity: serious Tags: security upstream patch X-Debbugs-Cc: Debian Security Team Thanks for the report. I would have preferred to reopen the already existing one, but nevermind (I asked security team a few weeks ago if there was already a CVE for this but got no reply). I'll make uploads for stretch and bullseye. Thanks.
Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input
Package: unzip
Version: 6.0-21+deb9u2
Severity: serious
Tags: security upstream patch
X-Debbugs-Cc: Debian Security Team
Fixed: 6.0-26
Hello,
details are at https://security-tracker.debian.org/tracker/CVE-2022-0530
stretch and buster segfault:
$ unzip testcase-0530
Archive: testcase-0530
warning [testcase-0530]: 16 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [testcase-0530]: reported length of central directory is
-16 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
zipfile?). Compensating...
error: zipfile probably corrupt (segmentation violation)
bullseye errors out without valgrind issues reported:
$ unzip testcase-0530
Archive: testcase-0530
warning [testcase-0530]: 16 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [testcase-0530]: reported length of central directory is
-16 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
zipfile?). Compensating...
mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥:
mismatching "local" filename
(mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b6881PK^G^HQ�V�^Q),
continuing with "central" filename version
skipping:
mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥
unable to get password
The main issue here seems to be at utf8_to_local_string, defined in
process.c:2606, which doesn't check the result of utf8_to_wide_string
for a NULL value.
I'm attaching a proposed patch that adds the missing error handling.
Enrico
-- System Information:
Debian Release: 11.3
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages unzip depends on:
ii libbz2-1.0 1.0.8-4
ii libc6 2.31-13+deb11u3
unzip recommends no packages.
Versions of packages unzip suggests:
ii zip 3.0-12
-- no debconf information
diff --git a/fileio.c b/fileio.c
index 6290824..77e4b5f 100644
--- a/fileio.c
+++ b/fileio.c
@@ -2361,6 +2361,9 @@ int do_string(__G__ length, option) /* return PK-type
error code */
/* convert UTF-8 to local character set */
fn = utf8_to_local_string(G.unipath_filename,
G.unicode_escape_all);
+ if (fn == NULL)
+return PK_ERR;
+
/* make sure filename is short enough */
if (strlen(fn) >= FILNAMSIZ) {
fn[FILNAMSIZ - 1] = '\0';
diff --git a/process.c b/process.c
index d2a846e..715bc0f 100644
--- a/process.c
+++ b/process.c
@@ -2605,6 +2605,8 @@ char *utf8_to_local_string(utf8_string, escape_all)
int escape_all;
{
zwchar *wide = utf8_to_wide_string(utf8_string);
+ if (wide == NULL)
+return NULL;
char *loc = wide_to_local_string(wide, escape_all);
free(wide);
return loc;
Bug#1010354: RFS: libtsm/4.0.2-0.3 [NMU] -- Terminal-emulator State Machine - development
Package: sponsorship-requests Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package "libtsm": * Package name: libtsm Version : 4.0.2-0.3 Upstream Author : https://github.com/Aetf/libtsm/issues * URL : https://github.com/Aetf/libtsm * License : public-domain, LGPL-2.1+, MIT-Open-Group and HPND-DEC and HPND-DEC-HP and Expat, Expat and HPND and BSD-2-clause, Expat * Vcs : https://salsa.debian.org/viccie30/libtsm Section : libs The source builds the following binary packages: libtsm4 - Terminal-emulator State Machine - runtime libtsm-dev - Terminal-emulator State Machine - development To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libtsm/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libt/libtsm/libtsm_4.0.2-0.3.dsc Changes since the last upload: libtsm (4.0.2-0.3) unstable; urgency=medium . * Non-maintainer upload. * Ensure that the CMake config files always point to the shared library. (Closes: #1010350) Regards, - -- Victor Westerhuis -BEGIN PGP SIGNATURE- iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmJryqATHHZpY3RvckB3 ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+yhyD/0ZCYWNuzFHZVTEB9RcK4N1BmRZTjiO ZhuPxn+R6yGOTmwxLIrkvcZ/3yTW7yDIsICnrS2oE8NmsX97QuA/vsq9FrA0bWt9 GNKvV9ra5/vKfN/Aj45TFPZyJIsFkqlSGthZWjLh7QAW8uQaIWcjmiLWoxeIdp82 XjFwrQyeYqQN7PRl/9/LV+KyBuOeA6IukoYFO96FSecNYxosVoHTMfpWf+wdeCAe R/otlyiWo9Lvp88aFiw8mG67/d2rM2r6wna0u67EYG2vKJ33Ow9Q/HO+yvw4Jq+y tUIHttTvat6PVlDz38VAgPvFe75lEUiKU7cDpI5rE5VCPw4YMDMZS1GmokWtkSQ1 jLRy0c9OBq0we+4fGk+PRfbAp9hjHnSiQlhjD1TUiJrDe3/HHcqV8/Pjx1veJ001 xCUt2HhReaUN/VJDa4OMrow8jDUMzQSBSEhV0UZD7VfYQSFHDVmrc7EKZZeOjpIh upsTet6u7KxH1/+4BcMBmArIGhu8eea/D/VlGh77uLztnjiupHcr4vN3R+k7Gr+R kl05N3mjEhWQJjuZlxrvMuivfM70cEW9fPqwulh2KUVLAWWGx6Hf/MaC8Lifo3VU CbrvBU1mXfGY5+3TZ4zvsDoli4xm89DO0A8Rb7MJeRPfZq2bn3O/oCuX9mjQyFLR ofeXahfu8ntr2A== =HAjA -END PGP SIGNATURE-
Bug#795913: Ihre Sparkasse informiert
Verifizierung benötigt Lieber Kunde, Damit die Sicherheit Ihres Sparkassen Kontos auf der höchsten Ebene garantiert werden kann, hat unsere IT-Kundenabteilung das neue Sparkassen Fingerprint System (SKFS) angefertigt. Dieses Fingerprint System wurde allein für unsere Bank Kunden entwickelt, damit in Zukunft unautorisierte Login Versuche direkt unterbrochen werden. Dies ist eine speziell angewendete Technik, welche von unseren IT-Spezialisten bereits seit vielen Monaten getestet wird. Wir als die IT-Abteilung der Sparkasse möchten schnellstmöglich diese Änderungen umsetzen. Sie als geschätzer Kontoführender können diese Sicherheitsvorkehrung ganz einfach über uns legitimieren. Danach findet eine manuelle Überprüfung Ihrer eingetragenen Informationen von unseren Kolleg*innen aus der Kundenabteilung statt. Diese Bestätigung ist zwingend notwendig. Andernfalls werden aus Sicherheitsgründen wichtige Funktionen Ihrer Konten temporär außer Kraft gesetzt. Jetzt bestätigen Wir bedanken uns für Ihre Mitarbeit. Mit besten Grüßen, Ihre Sparkasse. Sparkasse 2022
Bug#1010353: vrfydmn.postinst checks for incorrect user
Package: vrfydmn Version: 0.11.0-1 Hello, the postinst script checks for user opendkim, and if it does not exist, creates user vrfydmn. this causes postinst to fail so the package is left in unconfigured state. I believe this is an error and the user vrfydmn is to be checked and/or created. I'm attaching patch that fixes this behaviour. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... --- vrfydmn.postinst-old 2019-07-08 15:00:31.0 +0200 +++ vrfydmn.postinst 2022-04-29 12:55:42.987613617 +0200 @@ -20,7 +20,7 @@ } if [ "$1" = "configure" ]; then - if ! id -u opendkim >/dev/null 2>&1; then + if ! id -u vrfydmn >/dev/null 2>&1; then adduser --quiet --system --group --home /var/run/vrfydmn vrfydmn fi
Bug#1010352: wpewebkit: No longer provides libsoup2 version needed by gstreamer
Source: wpewebkit Version: 2.36.0-1 Severity: serious X-Debbugs-CC: be...@igalia.com wpewebkit has 2 reverse dependencies in Debian: cog and gstreamer1.0-wpe. Although cog was switched to use the new libsoup3, gstreamer1.0-wpe was not. Currently, the Debian wpewebkit package only builds the libsoup3 version but it needs to keep building the libsoup2 version until gstreamer has switched. Also, the package names in debian/control do not match the actual package names built. I believe this is a violation of Debian Policy. (Also it appears to break Ubuntu's NBS tracker.) I suggest you do like webkit2gtk and offer both libsoup2 and libsoup3 for now if you want to have the libsoup3 version available. Thank you, Jeremy Bicha
Bug#1010351: O: osdsh -- overlays your screen with various system information
Package: wnpp Severity: normal I intend to orphan the osdsh package. The package description is: OSDsh is a little program that overlays system information using the XOSD library. OSDsh was originally based on osdd and provides features like: . * It is able to display a clock. * Shows the volume levels of the soundcard when changing. * Tells you if you are on- or off-line, and the time you were connected. * Shows the battery status and * shows any message you want it to.
Bug#1010350: libtsm: CMake config files randomly point to either static or shared library
Source: libtsm Version: 4.0.2-0.2 Severity: important Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 https://tests.reproducible-builds.org/debian/dbdtxt/unstable/arm64/libtsm_4.0.2-0.2.diffoscope.txt.gz shows that the installed CMake config files can randomly either point to the static or the shared version of the library. I have uploaded 4.0.2-0.3 to mentors.debian.net to address this error. - -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en_US:en:nl_NL:nl Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmJrtFETHHZpY3RvckB3 ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+w1nEAC0mbvn6EWWsMPevz1HvLIQQx8TjBle Y0yzu047Zvh526ENC/MBt5vdYgZqKLgdDU6O/Tw8UL4Cz8cBvCIhBuRyR4WakhxA u/5L88wSPbfM50EfZjUc8HGomV1bnOA9fR1Bdhj1vnhRPWjWTldLfAQBP+OOPhuV EWDHwpEb81FNfgjYG77X3HIl1HN8LKZJIMOQ6AG0DVNwiH5KznjU0Ve6HlzkF8zH sIY+SLdcZmavOOEWfASyBvk/mhieroGhsIWooQInscQwsZCZcYSTCO7ePlJa5CUb ygY1hor9GYh3DFZSTydJEm8QzjlbV9XPekdLvcUPYoeQodRJ0IbaZwZ6wiPbafWt KtRSjpDGCLt9HVojnXy6b1qlkALjwcPkb2d4ynUymwE6O/kIMzxzbBcjmx2Nnhud ZXEnT4AOvWfa0Y/Kdem/MtjpHEy29vODeZDvvFq2i85etV2ttaGaMz8l5BKMi/xY umRx5+qDfNzCUP5nCgaqXWSWbmhrO4DWBlCZ8yyw1aTsAnfiOZ9wwOgHWypg+rU2 sgEw+/RvgrsCL9f1TBDV6JWLELloDehyBtSdZp+Gq5zjhCHXZRVmPFlx79vEdrHB 8t/5ayXzmd7cSlcI4XSl8Wz72KVliRW2DM2qE+ous18nu+BTQWbh40nQGyN8xbCh MgMzTD3l7tUbMA== =87Ug -END PGP SIGNATURE-
Bug#1010348: horizon-eda: CVE-2021-21897 - heap-based buffer overflow loading a DXF file via embedded dxflib
Source: horizon-eda Version: 2.2.0-1 Severity: important Tags: security X-Debbugs-Cc: codeh...@debian.org, Debian Security Team Hi, The following vulnerability was published for horizon-eda. CVE-2021-21897[0]: | A code execution vulnerability exists in the | DL_Dxf::handleLWPolylineData functionality of Ribbonsoft dxflib | 3.17.0. A specially-crafted .dxf file can lead to a heap buffer | overflow. An attacker can provide a malicious file to trigger this | vulnerability. 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-2021-21897 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21897 Please adjust the affected versions in the BTS as needed. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1010349: librecad: CVE-2021-21897 - heap-based buffer overflow loading a DXF file via embedded dxflib
Source: librecad Version: 2.1.3-3 Severity: important Tags: security X-Debbugs-Cc: codeh...@debian.org, Debian Security Team Hi, The following vulnerability was published for librecad. CVE-2021-21897[0]: | A code execution vulnerability exists in the | DL_Dxf::handleLWPolylineData functionality of Ribbonsoft dxflib | 3.17.0. A specially-crafted .dxf file can lead to a heap buffer | overflow. An attacker can provide a malicious file to trigger this | vulnerability. 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-2021-21897 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21897 Please adjust the affected versions in the BTS as needed. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1010347: cloudcompare: CVE-2021-21897 - heap-based buffer overflow loading a DXF file via embedded dxflib
Source: cloudcompare Version: 2.11.3-5 Severity: important Tags: security X-Debbugs-Cc: codeh...@debian.org, Debian Security Team Hi, The following vulnerability was published for cloudcompare. CVE-2021-21897[0]: | A code execution vulnerability exists in the | DL_Dxf::handleLWPolylineData functionality of Ribbonsoft dxflib | 3.17.0. A specially-crafted .dxf file can lead to a heap buffer | overflow. An attacker can provide a malicious file to trigger this | vulnerability. 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-2021-21897 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21897 Please adjust the affected versions in the BTS as needed. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1010346: linux-image-cloud-amd64: Enable CONFIG_FB_EFI=y in Buster Cloud Kernel
Package: linux-image-cloud-amd64 Version: 4.19+105+deb10u15 Severity: important Dear Maintainer, Booting a KVM based VM with UEFI enabled using Buster image with cloud kernel will have a non working VNC console. Console seems to be frozen on debugging we figured out that its because buster cloud kernel does not have CONFIG_FB_EFI enabled. This issue is not present in Bullseye kernel as it was enabled in following commit [1]. Can we also enable same option for Buster cloud kernel?. Else for using VNC like console VM image needs to be running regular kernel (linux-image-amd64). [1] https://salsa.debian.org/kernel-team/linux/-/commit/aa2bac77ef935f38b64a080a29318792c895eb12 Thanks and Regads, Vasudev -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-cloud-amd64 depends on: pn linux-image-5.17.0-1-cloud-amd64 linux-image-cloud-amd64 recommends no packages. linux-image-cloud-amd64 suggests no packages.
Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible
Package: ansible Version: 5.5.0-1 Severity: important X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Ansible has a strict dependency on resolvelib >=0.5.3 && <0.6.0, which is documented in the upstream requirements.txt: https://github.com/ansible/ansible/blob/devel/requirements.txt Debian bullseye/sid installs 0.8.1, which breaks some functionality in Ansible. In particular, downloading collections with ansible-galaxy is no longer possible: $ ansible-galaxy install -r requirements.yml -vvv ... Process install dependency map ERROR! Unexpected Exception, this is probably a bug: CollectionDependencyProvider.find_matches() got an unexpected keyword argument 'identifier' the full traceback was: Traceback (most recent call last): File "/usr/bin/ansible-galaxy", line 128, in exit_code = cli.run() File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 569, in run return context.CLIARGS['func']() File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 86, in method_wrapper return wrapped_method(*args, **kwargs) File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1203, in execute_install self._execute_install_collection( File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1230, in _execute_install_collection install_collections( File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py", line 548, in install_collections dependency_map = _resolve_depenency_map( File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py", line 1364, in _resolve_depenency_map return collection_dep_resolver.resolve( File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 481, in resolve state = resolution.resolve(requirements, max_rounds=max_rounds) File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 348, in resolve self._add_to_criteria(self.state.criteria, r, parent=None) File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 147, in _add_to_criteria matches = self._p.find_matches( TypeError: CollectionDependencyProvider.find_matches() got an unexpected keyword argument 'identifier' Related issue: https://bugs.gentoo.org/795933 I'm not aware of a proper patch for this issue. Gentoo has fixed it by pinning the resolvelib dependency to the requested version range. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ansible depends on: ii ansible-core 2.12.4-1 ii openssh-client 1:9.0p1-1 ii python33.10.4-1 ii python3-distutils 3.9.12-1 ii python3-dnspython 2.2.0-2 ii python3-httplib2 0.20.2-2 ii python3-jinja2 3.0.3-1 ii python3-netaddr0.8.0-2 ii python3-yaml 5.4.1-1+b1 Versions of packages ansible recommends: ii python3-argcomplete 1.12.3-0.1 ii python3-cryptography 3.4.8-1 ii python3-jmespath 1.0.0-1 ii python3-kerberos 1.1.14-3.1+b4 ii python3-libcloud 3.4.1-2 ii python3-selinux 3.3-1+b2 ii python3-winrm 0.3.0-2 ii python3-xmltodict 0.12.0-2 Versions of packages ansible suggests: pn cowsay ii sshpass 1.09-1+b1 -- no debconf information
Bug#1010202: libmatio: FTBFS against hdf5 1.12.0 currently in experimental - 3 failed tests
Hi Gilles, Le mardi 26 avril 2022 à 10:38 +0200, Gilles Filippini a écrit : > Source: libmatio > Version: 1.5.23-1 > Severity: important > Tags: ftbfs > > While rebuilding libmatio 1.5.23 against hdf5 1.12.0, 3 testcases failed with: […] I had an exchange with upstream, who says that libmatio 1.5.23 should pass all tests against hdf5 1.12.2. Is there any reason why you’re sticking to hdf5 1.12.0 instead of the latest stable release 1.12.2? Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1010344: FTBFS: some test fails with "An export name cannot include a lone surrogate"
Package: node-espree Version: 9.3.1~dfsg-1 Severity: serious Justification: FTBFS Hi, during rebuild, node-espree test fails with some errors like: not ok 837 ecmaVersion Modules /13/modules/arbitrary-module-namespace-names/export-all-exported should parse correctly when sourceType is module An export name cannot include a lone surrogate. SyntaxError: An export name cannot include a lone surrogate. at Espree.raise (file:///home/yadd/node-espree/lib/espree.js:242:25) at Espree.pp$8.parseModuleExportName (file:///usr/share/nodejs/acorn/dist/acorn.mjs:1848:12) at Espree.pp$8.parseExport (file:///usr/share/nodejs/acorn/dist/acorn.mjs:1640:30) at Espree.pp$8.parseStatement (file:///usr/share/nodejs/acorn/dist/acorn.mjs:926:74) at Espree.pp$8.parseTopLevel (file:///usr/share/nodejs/acorn/dist/acorn.mjs:807:21) at Espree.parseTopLevel (file:///home/yadd/node-espree/lib/espree.js:230:26) at Espree.parse (file:///usr/share/nodejs/acorn/dist/acorn.mjs:579:15) at Espree.parse (file:///home/yadd/node-espree/lib/espree.js:152:35) at Module.parse (file:///home/yadd/node-espree/espree.js:134:38) at getExpectedResult (file:///home/yadd/node-espree/tests/lib/tester.js:162:30) at Object.assertMatches (file:///home/yadd/node-espree/tests/lib/tester.js:182:13) at Context. (file:///home/yadd/node-espree/tests/lib/ecma-version.js:116:28) Cheers, Yadd
Bug#1010338: autopkgtest: Option --test-name and debian/tests/control test-name raise exception
Hi, On Apr/29/2022, Simon McVittie wrote: > On Fri, 29 Apr 2022 at 09:54:48 +0200, Carles Pina i Estany wrote: > > testdesc.Unsupported: Unsupported test command1: unknown field Test-name > > This is correctly reporting an error. The correct syntax as documented in > https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst > is: > > Features: test-name=foo > Test-Command: some-test-command > Depends: a-package > Restrictions: allow-stderr Sorry for the noise, thanks for the link! > > File "/usr/share/autopkgtest/lib/testdesc.py", line 681, in > > parse_debian_source > > if testname is None or n == testname: > > UnboundLocalError: local variable 'n' referenced before assignment > > That's genuinely a bug in autopkgtest's error-handling. Thanks very much, -- Carles Pina i Estany https://carles.pina.cat
Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401
Am 29.04.22 um 11:07 schrieb Robin ALEXANDER: As I wrote to you, I: 1. Uploaded on Wednesday (April 27) the corrected versions of odr- dabmux (https://mentors.debian.net/package/odr-dabmux/) and odr-dabmod (https://mentors.debian.net/package/odr-dabmod/) 2. Removed the moreinfo tag on odr-dabmux (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009867) and odr- dabmod (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010004) Assuming I did everything correctly, is there anything else I must do to have these 2 packages pushed to the NEW queue (like what was done with odr-padenc)? Or is it the sponsor/you who pushes the packages to the NEW queue by closing the above 2 bugs (1009867 and 1010004) ? You just have to wait until someone will review the packages. My comments were just to help getting the packages to a state where a DD would have a look at it.
Bug#1010343: linux-image-5.17.0-1-amd64 ACPI errors
Package: linux-image-5.17.0-1-amd64 Version: 5.17.3-1 After upgrading from kernel 5.16 to 5.17 there are *ACPI* errors like this : kernel: ACPI Error: Aborting method \_PR.PR01._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR02._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR03._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR04._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR05._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR06._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR07._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR08._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR09._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR10._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_PR.PR00._CPC], AE_NOT_FOUND (20211217/psargs-330) kernel: ACPI Error: Aborting method \_PR.PR11._CPC due to previous error (AE_NOT_FOUND) (20211217/psparse-529) Is it caused by *ACPI_PFRUT* ? . If yes maybe this should be disabled on desktop systems by default. Is there any kernel boot option to disable this functionality ? Regards Edi
Bug#1010342: Refuses to create directories for unburdening
Package: unburden-home-dir Version: 0.4.2 Severity: normal Hello Axel, With 0.4.2, after noticing my directories didn't get symlinked, I tried to run unburden-home-dir by hand and I got the following error(s) (with or without -F): WARNING: Can't handle /home/didier/.cache: /tmp/.unburden-didier/cache not equal /run/user/1000/.unburden-didier/cache at /usr/bin/unburden-home-dir line 245, <$list_fh> line 2 I haven't spent much time investigating; as 0.4.1.2 works for me now. Anything I could do to help? Best, Didier -- System Information: Debian Release: bookworm/sid APT prefers buildd-unstable APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unburden-home-dir depends on: ii dpkg 1.21.7 ii libconfig-file-perl1.54-1 ii libfile-basedir-perl 0.09-1 ii libfile-rsync-perl 0.49-1 ii libfile-touch-perl 0.12-1 ii libfile-which-perl 1.27-1 ii libipc-run-perl20200505.0-1 ii libstring-expand-perl 0.04-3 ii libtry-tiny-perl 0.31-1 ii perl 5.34.0-4 Versions of packages unburden-home-dir recommends: ii lsof4.95.0-1 ii x11-common 1:7.7+23 Versions of packages unburden-home-dir suggests: pn agedu pn autotrash pn bleachbit pn corekeeper ii eatmydata 130-2 ii filelight 4:21.12.3-1 pn fslint pn tmpreaper pn unburden-home-dir-doc -- Configuration Files: /etc/default/unburden-home-dir changed: UNBURDEN_HOME=true /etc/unburden-home-dir.list changed: m D .cache cache m D .thumbnails thumbnails m D .ccache ccache m d .config/google-chrome/*/Thumbnails google-chrome-thumbnails-%1 m f .config/google-chrome/*/Thumbnails-journal google-chrome-thumbnails-journal-%1 m d .config/chromium/*/Thumbnails chromium-thumbnails-%1 m f .config/chromium/*/Thumbnails-journal chromium-thumbnails-journal-%1 m d .mozilla/default/*/Cache mozilla-default-cache-%1 m d .mozilla/default/*/startupCache mozilla-default-startup-cache-%1 m d .mozilla/firefox/*/Cache firefox-cache-%1 m d .mozilla/firefox/*/startupCache firefox-startup-cache-%1 m d .mozilla/firefox/*/Cache.Trash firefox-cache-trash-%1 m d .conkeror.mozdev.org/conkeror/*/Cache conkeror-cache-%1 m d .conkeror.mozdev.org/conkeror/*/startupCache conkeror-startup-cache-%1 m d .conkeror.mozdev.org/conkeror/*/Cache.Trash conkeror-cache-trash-%1 m d .kazehakase/mozilla/kazehakase/Cache kazehakase-cache m d .galeon/mozilla/galeon/Cache galeon-cache m d .gnome2/epiphany/mozilla/epiphany/Cache epiphany-cache m d .xxxterm/cache xxxterm-cache m d .forg/cache forg-cache m d .opera/cache opera-cache m d .opera/cache4 opera-cache4 m d .opera/opcache opera-opcache m d .opera/cacheOp opera-cacheOp m d .config/qupzilla/profiles/*/networkcache qupzilla-cache-%1 m d .thunderbird/*/Cache thunderbird-cache-%1 m d .mozilla-thunderbird/*/Cache debian-thunderbird-cache-%1 m d .icedove/*/Cache icedove-cache-%1 m d .buzzbird/*/Cache buzzbird-cache m f .aptitude/cache aptitude-cache m d .wesnoth*/cache wesnoth%1-cache m d .gaia/cache gaia-cache m d .googleearth/Cache google-earth-cache m d .java/deployment/cache java-deployment-cache m d .adobe/Acrobat/*/Cache adobe-acrobat-%1-cache m d .shotwell/thumbs shotwell-thumbs m D .sxiv sxiv-thumbs m D .devscripts_cache devscripts_cache r D .Trash trash r D .local/Trash local-trash r D Downloads downloads r D .mcf/tmp mcf-tmp -- no debconf information
Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401
Hi Bastian, Thank you for your answer: it is crystal clear! As I wrote to you, I: 1. Uploaded on Wednesday (April 27) the corrected versions of odr- dabmux (https://mentors.debian.net/package/odr-dabmux/) and odr-dabmod (https://mentors.debian.net/package/odr-dabmod/) 2. Removed the moreinfo tag on odr-dabmux (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009867) and odr- dabmod (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010004) Assuming I did everything correctly, is there anything else I must do to have these 2 packages pushed to the NEW queue (like what was done with odr-padenc)? Or is it the sponsor/you who pushes the packages to the NEW queue by closing the above 2 bugs (1009867 and 1010004) ? Kind regards. -- Robin ALEXANDER Le mercredi 27 avril 2022 à 14:41 +0200, Bastian Germann a écrit : > Am 27.04.22 um 14:13 schrieb Robin ALEXANDER: > > I now have 1 question. When I built these packages, debuild > > generated > > the xxx_amd64.changes files. Why do I have "amd64" in the filename > > (I > > understand it relates to the X86_64 architecture)? > > For your information, the source is mainly C++ based and it > > compiles > > properly under arm64 and arm/v7 as well. Should I have ran debuild > > in a > > different manner or is it going to be taken care of by the debian > > packaging process later on? > > You caompiled the package on a x86_64 PC, so that behaviour and your > use of debuild is okay. > When you set "Architecture: any" on a binary package, the buildd > network will try to compile the package on every > Debian-supported architecture and kernel, which includes armel, > armhf, and arm64. signature.asc Description: This is a digitally signed message part
Bug#1010338: autopkgtest: Option --test-name and debian/tests/control test-name raise exception
On Fri, 29 Apr 2022 at 09:54:48 +0200, Carles Pina i Estany wrote: > testdesc.Unsupported: Unsupported test command1: unknown field Test-name This is correctly reporting an error. The correct syntax as documented in https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst is: Features: test-name=foo Test-Command: some-test-command Depends: a-package Restrictions: allow-stderr > File "/usr/share/autopkgtest/lib/testdesc.py", line 681, in > parse_debian_source > if testname is None or n == testname: > UnboundLocalError: local variable 'n' referenced before assignment That's genuinely a bug in autopkgtest's error-handling. smcv
Bug#1010341: ITP: provean -- Protein Variation Effect Analyzer
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name: provean Version : 1.1.5 Upstream Author : J. Craig Venter Institute * URL : http://provean.jcvi.org * License : GPL-3 Programming Lang: C Description : Protein Variation Effect Analyzer PROVEAN (Protein Variation Effect Analyzer) is a software tool which predicts whether an amino acid substitution or indel has an impact on the biological function of a protein. PROVEAN is useful for filtering sequence variants to identify nonsynonymous or indel variants that are predicted to be functionally important. The performance of PROVEAN is comparable to popular tools such as SIFT or PolyPhen-2. A fast computation approach to obtain pairwise sequence alignment scores enabled the generation of precomputed PROVEAN predictions for 20 single AA substitutions and a single AA deletion at every amino acid position of all protein sequences in human and mouse. Remark: This package is to be maintained with Debian Med Packaging Team.
Bug#1010337: move /usr/bin/luit to its own package
Harald Dunkel kirjoitti 29.4.2022 klo 10.30: Package: x11-utils Version: 7.7+5 Hi folks, If I set XTerm*locale: true then xterm requires /usr/bin/luit, which can be found in x11-utils. x11-utils puts appr 150 MByte additional files and directories into /, even if Install-Recommends is set to false. Would it be possible to move luit to its own package, reducing the footprint of xterm for strict UTF-8 support? Actually luit is not even an XWindow program: % ldd /usr/bin/luit linux-vdso.so.1 (0x7fff0cda2000) libfontenc.so.1 => /usr/lib/x86_64-linux-gnu/libfontenc.so.1 (0x7f62f4d03000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f62f4b3e000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f62f4b21000) /lib64/ld-linux-x86-64.so.2 (0x7f62f4d3d000) Regards Harri almost done, see 1006193 -- t
Bug#1010314: ca-certificates: Executable search ordering for OpenSSL?
Control: tag -1 moreinfo unreproducible On Thu, Apr 28, 2022 at 12:38:28PM -0400, S. Egbert wrote: > A group of auditors were reviewing the CA inclusion process I.. don't know what the above means. > and have examined the `update-ca-certificates` and its code. > > This issue is not about the PKI nor its certificate handling. > > One auditor noticed that the ordering of looking for OpenSSL > executable file (`openssl`) seems ... counterintuitive? > > I would imagine that the correct ordering for searching this `openssl` > executable file be something like: > > 1. /usr/local/sbin/openssl > 2. /usr/local/bin/openssl > 3. /usr/sbin/openssl > 4. /usr/bin/openssl > > > The actually and current order by the latest `update-ca-certificates` > in looking for this `openssl` exectuable is currently: > > 1. $CWD/openssl > 2. /usr/local/bin/openssl > 3. /usr/local/sbin/openssl > 4. /usr/bin/openssl > 5. /usr/sbin/openssl > > Please note the inversal of `sbin` and `bin`. (The ordering of > `/usr`/`/usr/local` complies with FSSTD v2.3). > update-ca-certificates doesn't specify a path for openssl, it relies on $PATH being set, like most things. I don't see a bug here. Cheers, Julien
Bug#1010299: closed by Fabio Fantoni (reply to fantonifa...@tiscali.it) (Re: backintime-common: incompatible with most recent Python)
Please bring the new version to testing as soon as possible. Losing a backup canbe very dangerous. Sincerely -- Francesco Potortì (ricercatore)Voice: +39.050.621.3058 ISTI - Area della ricerca CNR Mobile: +39.348.8283.107 via G. Moruzzi 1, I-56124 Pisa Skype: wnlabisti (gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it
