Bug#964077: one more patch on top for container execution
Testing across more test environments showed that the link tests will fail in containers. To not throw away the other tests in those environments via e.g. a restriction to only run in VMs I decided to just skip the link tests in this case. Here is the patch that would go on top of the others I already reported. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd From a7166325c8c34a8ae45480e93513a900f0c474ee Mon Sep 17 00:00:00 2001 From: Christian Ehrhardt Date: Tue, 14 Jul 2020 07:52:10 +0200 Subject: [PATCH] d/t/test-build: link tests fail in containers Signed-off-by: Christian Ehrhardt --- debian/tests/test-build | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/debian/tests/test-build b/debian/tests/test-build index 20b4115..0360b5f 100644 --- a/debian/tests/test-build +++ b/debian/tests/test-build @@ -44,10 +44,14 @@ cmpio_uring-cpio_uring-cp.copy ./io_uring-cp-static io_uring-cp-static io_uring-cp-static.copy cmpio_uring-cp-static io_uring-cp-static.copy -./link-cp link-cplink-cp.link -cmplink-cplink-cp.link -./link-cp-static link-cp-static link-cp-static.link -cmplink-cp-static link-cp-static.link +# known to fail in containers +if ! systemd-detect-virt --container -q; then +./link-cp link-cplink-cp.link +cmplink-cplink-cp.link + +./link-cp-static link-cp-static link-cp-static.link +cmplink-cp-static link-cp-static.link +fi ./ucontext-cp ucontext-cpucontext-cp.copy cmpucontext-cpucontext-cp.copy -- 2.27.0
Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist
On Mon, Jul 13, 2020 at 04:55:36PM -0700, Sean Whitton wrote: > control: tag -1 + moreinfo > > Hello Nicholas, [...] > Is there any reason to think the software no longer works? > > Otherwise, perhaps it would be better if you were simply to orphan it. Hi Sean, It does still work (modulo #936008, which requires rewriting one script -- though the package is basically just two scripts). However, there's nothing it does that other packages don't do equally well or better; it could be orphaned and remain for another release or two, but I'm not convinced it's helping anyone trying to decide between all the results of "apt-cache search galler(y|ies)". Nicholas
Bug#964997: simgear FTCBFS: does not pass cross flags for cmake
Source: simgear Version: 1:2020.1.3+dfsg-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs simgear fails to cross build from source, because it does not pass cross flags to cmake. The easiest way of doing so - using dh_auto_configure - makes simgear cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru simgear-2020.1.3+dfsg/debian/changelog simgear-2020.1.3+dfsg/debian/changelog --- simgear-2020.1.3+dfsg/debian/changelog 2020-07-12 16:44:06.0 +0200 +++ simgear-2020.1.3+dfsg/debian/changelog 2020-07-13 17:57:08.0 +0200 @@ -1,3 +1,10 @@ +simgear (1:2020.1.3+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1) + + -- Helmut Grohne Mon, 13 Jul 2020 17:57:08 +0200 + simgear (1:2020.1.3+dfsg-1) unstable; urgency=medium * New upstream version 2020.1.3+dfsg diff --minimal -Nru simgear-2020.1.3+dfsg/debian/rules simgear-2020.1.3+dfsg/debian/rules --- simgear-2020.1.3+dfsg/debian/rules 2020-07-12 16:41:48.0 +0200 +++ simgear-2020.1.3+dfsg/debian/rules 2020-07-13 17:57:08.0 +0200 @@ -32,7 +32,6 @@ -DCMAKE_CXX_FLAGS="$(CXXFLAGS)" \ -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-g -DNDEBUG" \ -DCMAKE_SHARED_LINKER_FLAGS="$(LDFLAGS)" \ - -DCMAKE_VERBOSE_MAKEFILE=ON \ -DCMAKE_INSTALL_PREFIX:PATH=/usr \ -DSIMGEAR_SHARED=OFF \ -DSYSTEM_EXPAT=ON \ @@ -43,8 +42,7 @@ dh $@ --buildsystem=cmake --builddirectory=build override_dh_auto_configure: - mkdir build - cd build && cmake .. $(CMAKE_FLAGS) + dh_auto_configure -- $(CMAKE_FLAGS) override_dh_clean: dh_clean
Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does
On Wed, May 20, 2020 at 12:48:18PM -0700, Ross Vandegrift wrote: > On Thu, May 07, 2020 at 07:52:31PM +0200, Julien Cristau wrote: > > On Thu, May 07, 2020 at 09:48:34PM +1000, Dmitry Smirnov wrote: > > > On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote: > > > > This use of Provides is not acceptable. The systemctl package does not > > > > in any way provide the same functionality / interfaces as the systemd > > > > package, and as such it does not get to pretend that it does and cause > > > > problems to other packages. > > > > > > I have to challenge that. "systemctl" provides enough functionality to > > > replace "systemd" inside application containers. Therefore there are > > > situations where "Provides: systemd" is justified. > > > > > That's not what "Provides" means though. What you're saying is > > "systemctl provides a subset of the systemd package's functionality". > > That's not good enough. Provides is much stronger than "there are cases > > where this might be enough", and there's more to systemd than systemctl. > > Indeed- packages that Build-Depend on systemd need a way to express that > fact. experimental builds use apt-cudf, which now sees systemctl as a > more attractive solution: > https://buildd.debian.org/status/package.php?p=e17=experimental Hi Dmitry - systemctl is still breaking builds in experimental, any updates? Ross
Bug#964927: ibus-avro: Remove deps on ibus IM module packages
On 2020-07-14 04:17, Changwoo Ryu wrote: That is not set as default. Add the "tagpending' webhook URL below in the project settings. https://salsa.debian.org/salsa/salsa-webhook Ah, thanks! (Would have been a sensible default IMO.) -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj
Bug#964996: ibus-unikey: Remove deps on ibus IM module packages
Package: ibus-unikey Version: 0.7.0~beta1-0.1 Severity: normal Currently ibus-unikey depends on ibus-gtk and ibus-gtk3. These IM module package are for supporting UIs and they should not be in Depends of ibus language engine packages.
Bug#964995: RFS: kcollectd/0.11.99.0-1 -- simple collectd graphing front-end for KDE
Package: sponsorship-requests Severity: normal X-Debbugs-CC: pkg-kde-t...@alioth-lists.debian.net Dear mentors, I am looking for a sponsor for my package "kcollectd": * Package name: kcollectd Version : 0.11.99.0-1 Upstream Author : Antonio Russo (myself) * URL : www.antonioerusso.com/projects/kcollectd * License : GPLv3 * Vcs : https://salsa.debian.org/qt-kde-team/extras/kcollectd.git Section : utils It builds these binary packages: kcollectd To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kcollectd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.11.99.0-1.dsc Changes since the last upload: * New upstream release 0.11.99.0. - Includes --basedir CLI option to select directory containing RRDs. * Do not depend on collectd at build or runtime. * Bump debhelper-compat to 13 (no changes). Most critically of the above is that it avoids a build dependency on collectd, which is currently due to be autoremoved in 4 days. Though this program may be most useful on a machine that has collectd installed, it is still useful for viewing RRD files that are remote (via, say, sshfs). This is actually a recent, specific feature request [1]. Best, Antonio Russo [1] https://gitlab.com/aerusso/kcollectd/-/issues/4
Bug#964994: RFS: pybj/0.2.5-1 [ITP] -- Binary JData (BJData) encoder/decoder for Python 2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "pybj" * Package name : pybj Version : 0.2.5-1 Upstream Author : [fill in name and email of upstream] * URL : https://github.com/fangq/pybj * License : Apache-2.0 * Vcs : https://salsa.debian.org/science-team/pybj Section : python It builds those binary packages: python-bjdata - Binary JData (BJData) encoder/decoder for Python 2 python3-bjdata - Binary JData (BJData) encoder/decoder for Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pybj Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pybj/pybj_0.2.5-1.dsc Changes since the last upload: * Initial release. (Closes: #964984) Regards,
Bug#964986: buster-pu: package ksh/93u+20120801-3.4
Hi Anuradha, [disclaimer: not a member of the release team, so not an authoritative reply] On Mon, Jul 13, 2020 at 06:56:27PM -0400, Anuradha Weeraman wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: anura...@debian.org, car...@debian.org > > [ Reason ] > Summary of the issue: In ksh version 20120801, a flaw was found in the > way it evaluates certain environment variables. An attacker could use > this flaw to override or bypass environment restrictions to execute > shell commands. > > [ Impact ] > Services and applications that allow remote unauthenticated > attackers to provide one of those environment variables could allow them > to exploit this issue remotely, although the risk is deemed low. > > [ Tests ] > There is a test included in the diff that was used to validate the > fix. Also, the regression test suite was run to make sure there were > no regressions. > > [ Risks ] > The regression test suite has been run before and after the patch to > confirm no new regressions. Also, the fix is applied in unstable with no > new issues reported. > > [ Checklist ] > [X] *all* changes are documented in the d/changelog > [X] I reviewed all changes and I approve them > [X] attach debdiff against the package in (old)stable > [X] the issue is verified as fixed in unstable > > [ Changes ] > * Patch to arith.c that fixes the CVE > * Test case for the fix > > [ Other info ] > This was brought up to the security team first, and it was deemed that a > DSA is not required by Salvatore Bonaccorso. Small change is needed in the debdiff: > diff -Nru ksh-93u+20120801/debian/changelog ksh-93u+20120801/debian/changelog > --- ksh-93u+20120801/debian/changelog 2018-12-14 02:26:58.0 -0500 > +++ ksh-93u+20120801/debian/changelog 2020-07-12 11:26:07.0 -0400 > @@ -1,3 +1,15 @@ > +ksh (93u+20120801-4+deb10u1) buster-security; urgency=high The target distribution would need to be 'buster' in this case of the upload for the point release. Thanks for your work on this update, Regards, Salvatore
Bug#964993: RFS: pyjdata/0.3.5-1 [ITP] -- JData format encoder/decoder for Python 2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "pyjdata" * Package name : pyjdata Version : 0.3.5-1 Upstream Author : [fill in name and email of upstream] * URL : https://github.com/fangq/pyjdata * License : Apache-2.0 * Vcs : https://salsa.debian.org/science-team/pyjdata Section : python It builds those binary packages: python-jdata - JData encoder/decoder for Python 2 python3-jdata - JData encoder/decoder for Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pyjdata Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pyjdata/pyjdata_0.3.5-1.dsc Changes since the last upload: * Initial release. (Closes: #964984) Regards,
Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base
On Tue, Apr 07, 2020 at 09:40:52AM +0200, masar wrote: > > Hi, > > the bug is still present in > >openjdk-11-jdk 11.0.7+9-1 Hi Maurizio, In your initial bug report you said that you have a reproducible test case with docker. Would you mind sharing that with me? FWIW, I happened to notice a similar bug reported against AdoptOpenJDK builds (https://github.com/AdoptOpenJDK/openjdk-build/issues/1214) that makes we wonder if there a common root cause, perhaps in the toolchains used by both projects to build OpenJDK. Thank you, tony signature.asc Description: PGP signature
Bug#870641: light-locker: screen stays black after closing and opening laptop lid
On Mon, Jul 13, 2020 at 08:26:14PM +0200, Yves-Alexis Perez wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Mon, 2020-07-13 at 10:33 +0800, Aaron Lu wrote: > > On Tue, May 12, 2020 at 11:13:52AM +0200, Yves-Alexis Perez wrote: > > > I've also re-pinged upstream Linux and the patch should be included in the > > > next Linux point release (hopefully 4.19.123), and which will then be > > > included > > > in Debian buster for the next Debian point release (hopefully 10.5). It's > > > not > > > tomorrow but still it should help at one point. > > > > Just want to report that I have installed 5.6.0-0.bpo.2-amd64 from > > buster-backport and now the display can be powered back on when I > > pressed my keyboard or moved my mouse. > > Could you try linux-image-4.19.0-10-amd64 from testing-proposed-updates and > report back? It should include the fix. It doesn't seem easy to install packages from testing-proposed-updates. https://wiki.debian.org/TestingProposedUpdates doesn't tell me how to do that and after adding: deb http://some_debian_mirror/debian/ testing-proposed-updates main 'apt-cache search linux-image' doesn't show me linux-image-4.19.0-10-amd64.. Anyway, I downloaded this package directly from the mirror's pool: linux-image-4.19.0-10-amd64-unsigned_4.19.131-2_amd64.deb Is the above package correct? And the good news is, this kernel also works fine :-) > > I do not see any other problems right now, everything seems to work > > fine, except one error message in dmesg everytime the display goes the > > off-on cycle: > > broken atomic modeset userspace detected, disabling atomic > > But I guess it's a different problem and it doesn't seem to cause any > > problem. > > Actually the problem lies in the way Xorg uses atomic, and that's why the fix > is to disable them. So if you see the message that means the fix is correctly > applied. I see, thanks for the explanation.
Bug#964992: ITP: pyjdata -- JData format encoder/decoder for Python
Package: wnpp Severity: wishlist Name: pybjdata Version: 0.3.5 Summary: JData format encoder/decoder for Python License: Apache 2.0 URL: https://github.com/fangq/pybjdata Description: The JData Specification (https://github.com/fangq/jdata/) defines a lightweight language-independent data annotation interface targeted at storing and sharing complex data structures across different programming languages such as MATLAB, JavaScript, Python etc. Using JData formats, a complex Python data structure can be encoded as a `dict` object that is easily serialized as a JSON/binary JSON file and share such data between programs of different languages. Comment: I am the upstream author and maintainer of this python module.
Bug#964927: ibus-avro: Remove deps on ibus IM module packages
2020년 7월 14일 (화) 오전 12:39, Gunnar Hjalmarsson 님이 작성: > > Control: tags -1 + pending > > Fix pushed to repo: > https://salsa.debian.org/input-method-team/ibus-avro/-/commit/06990e57 > > (Don't know why salsa didn't do this automatically.) That is not set as default. Add the "tagpending' webhook URL below in the project settings. https://salsa.debian.org/salsa/salsa-webhook
Bug#963750: RM: chef -- ROM; trademark issues
On Mon, 13 Jul 2020 16:49:25 -0700 Sean Whitton wrote: > DFSG#4 probably covers this case. ...if it were moved into non-free, since "Chef" currently fails DFSG #1, but even that's not an option if Debian can't distribute "Chef" in the first place, lest the project run afoul of the trademark policy. Adopting Cinc as a rebranded version of Chef would sidestep the entire matter: https://cinc.sh/ pgpYPkPdWTnJb.pgp Description: OpenPGP digital signature
Bug#821341: debian-installer: unbootable, no gpt partition for uefi install
What is the status of this bug? Also can somebody delete one spam message above. We should support 0xEF MBR. Also look at the note here about "UEFI to the MBR handle". What the hell is that? https://books.google.ru/books?id=ePNODQAAQBAJ=PT524=PT524=mbr+0xef+UEFI=bl=QAyIhjP_gS=ACfU3U2dHce5h6O7So55jIuS7pLBi4EP6w=ru=X=2ahUKEwjDrpyGtsvqAhV1w8QBHc0qBoEQ6AEwBHoECAMQAQ#v=onepage=mbr%200xef%20UEFI=false
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
Bdale Garbee writes:
> So... while I'm sure gEDA could be "saved" in Debian with enough effort,
> I just don't see the point, and won't put any time or attention on it
> myself.
I'd suggest we should do something "soonish". This is the last package
holding guile-2.0 in testing, and I'd *really* like to be able to finish
the guile-2.0 removal.
For what it's worth, I thought I'd see how hard it might be to update to
guile-3.0, and the attached (very primitive/incomplete) diff does get
the current package to build and pass all but one of the tests here
(assuming that wasn't a short-circuit and there are more tests after
that).
However, unless someone's interested in maintaining the package,
pursuing guile-3.0 support, upgrading to 1.10, etc. Perhaps it's best
to file for removal now. We can always reintroduce it later, if the
situation improves.
diff --git a/configure.ac b/configure.ac
index 30328f5..2b42fd6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -70,7 +70,9 @@ AX_DESKTOP_I18N
PKG_PROG_PKG_CONFIG
-AX_CHECK_GUILE([1.8.0])
+GUILE_PKG([3.0])
+GUILE_PROGS
+GUILE_FLAGS
PKG_CHECK_MODULES(GLIB, [glib-2.0 >= 2.20.0], ,
AC_MSG_ERROR([GLib 2.20.0 or later is required.]))
diff --git a/debian/control b/debian/control
index fc66e52..a7a8e0a 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
Maintainer: Debian Electronics Team
Uploaders: Peter Clifton , أحمد المحمودي (Ahmed El-Mahmoudy) , Bdale Garbee
Standards-Version: 4.2.0
-Build-Depends: debhelper (>= 11), libgtk2.0-dev (>= 2.16.0), guile-2.0-dev, libgd-dev, libxml-parser-perl, ghostscript, transfig, libstroke0-dev, groff, libglib2.0-dev, flex, intltool, texinfo
+Build-Depends: debhelper (>= 11), libgtk2.0-dev (>= 2.16.0), guile-3.0-dev, libgd-dev, libxml-parser-perl, ghostscript, transfig, libstroke0-dev, groff, libglib2.0-dev, flex, intltool, texinfo
Homepage: http://www.geda-project.org/
Vcs-Git: https://salsa.debian.org/electronics-team/geda-gaf.git
Vcs-Browser: https://salsa.debian.org/electronics-team/geda-gaf
@@ -48,7 +48,7 @@ Description: GPL EDA -- Electronics design software (library files)
Package: libgeda-dev
Architecture: any
Section: libdevel
-Depends: ${misc:Depends}, ${shlibs:Depends}, libgeda42 (= ${binary:Version}), libgtk2.0-dev, guile-2.0-dev [!ia64], guile-1.8-dev [ia64], libgd-dev
+Depends: ${misc:Depends}, ${shlibs:Depends}, libgeda42 (= ${binary:Version}), libgtk2.0-dev, guile-3.0-dev, libgd-dev
Pre-Depends: ${misc:Pre-Depends}
Description: GPL EDA -- Electronics design software (development files)
The gEDA project has produced and continues working on a full GPL'd suite and
diff --git a/gnetlist/src/parsecmd.c b/gnetlist/src/parsecmd.c
index aa31e86..9f15f6d 100644
--- a/gnetlist/src/parsecmd.c
+++ b/gnetlist/src/parsecmd.c
@@ -206,13 +206,13 @@ parse_commandline (int argc, char *argv[])
backend_params = g_slist_append(backend_params, optarg);
break;
-case 'c':
- scm_internal_stack_catch (SCM_BOOL_T,
-(scm_t_catch_body) scm_c_eval_string,
-(void *) optarg,
-(scm_t_catch_handler) catch_handler,
-(void *) optarg);
- break;
+/* case 'c': */
+/* scm_internal_stack_catch (SCM_BOOL_T, */
+/* (scm_t_catch_body) scm_c_eval_string, */
+/* (void *) optarg, */
+/* (scm_t_catch_handler) catch_handler, */
+/* (void *) optarg); */
+/* break; */
case 'h':
usage(argv[0]);
diff --git a/gschem/src/Makefile.am b/gschem/src/Makefile.am
index 12d22d6..b4cfd24 100644
--- a/gschem/src/Makefile.am
+++ b/gschem/src/Makefile.am
@@ -98,7 +98,7 @@ SUFFIXES = .x
snarf_cpp_opts = $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(gschem_CPPFLAGS) $(AM_CFLAGS) $(gschem_CFLAGS)
.c.x:
- CPP="$(CPP)" $(GUILE_SNARF) -o $@ $< $(snarf_cpp_opts)
+ CPP="$(CPP)" guile-snarf-$(GUILE_EFFECTIVE_VERSION) -o $@ $< $(snarf_cpp_opts)
localedir = @datadir@/locale
DEFS = -DLOCALEDIR=\"$(localedir)\" @DEFS@
diff --git a/libgeda/shell/Makefile.am b/libgeda/shell/Makefile.am
index d339bb5..87c0645 100644
--- a/libgeda/shell/Makefile.am
+++ b/libgeda/shell/Makefile.am
@@ -23,6 +23,6 @@ SUFFIXES = .x
snarf_cpp_opts = $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(geda_shell_CPPFLAGS) $(AM_CFLAGS) $(geda_shell_CFLAGS)
.c.x:
- CPP="$(CPP)" $(GUILE_SNARF) -o $@ $< $(snarf_cpp_opts)
+ CPP="$(CPP)" guile-snarf-$(GUILE_EFFECTIVE_VERSION) -o $@ $< $(snarf_cpp_opts)
CLEANFILES = $(BUILT_SOURCES)
diff --git a/libgeda/src/Makefile.am b/libgeda/src/Makefile.am
index c65c979..a866a37 100644
--- a/libgeda/src/Makefile.am
+++ b/libgeda/src/Makefile.am
@@ -98,7 +98,7 @@ SUFFIXES = .x
snarf_cpp_opts = $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(libgeda_la_CPPFLAGS)
Bug#959845: librsvg: FTBFS on mips*el: transform::tests::parses_transform_list, transform::tests::parses_valid_transform: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))
YunQiang Su 于2020年7月14日周二 上午7:24写道： > > Yunqiang Su 于2020年7月10日周五 上午8:14写道： > > > > On Mon, 11 May 2020 13:15:23 +0100 Simon McVittie wrote: > > > Control: retitle -1 librsvg: FTBFS on Loongson-3A: assertion failed: > > > t1.y0.approx_eq(t2.y0, (epsilon, 1)) > > > Control: severity -1 wishlist > > > Control: tags -1 + confirmed wontfix > > > Control: notforwarded -1 > > > > > > On Mon, 11 May 2020 at 11:50:43 +0200, Aurelien Jarno wrote: > > > > On 2020-05-06 11:19, Simon McVittie wrote: > > > > > There seems to be a strong correlation where this test passes on a > > > > > Rhino > > > > > Labs UTM8 but fails on a Loongson 3A. Are there known issues with > > > > > Loongson 3A hardware, or is there different FPU behaviour, or > > > > > something? > > > > > > > > Thanks for the analysis. Yep the Loongson 3A is known for having an FPU > > > > bug that could explain that behaviour. Basically it treats the madd, > > > > msub, nmadd and nmsub instructions as fused while they should not. > > > > > > It seems strange to me that a release architecture is using > > > known-to-be-faulty hardware for buildds. Is there any possibility of > > > replacing those machines, or taking them out of the buildd rotation > > > entirely? > > > > > > In particular, we treated this as a RC bug, and prioritized reporting > > > it upstream; but we should not be wasting upstreams' time with issues > > > that are a result of faulty hardware. I don't think we can expect every > > > package maintainer, or every upstream maintainer, to know that Debian's > > > mips*el buildds have this bug and that failing build-time tests that > > > touch floating-point are likely to be not a real bug in the software. > > > > > > At the same time, I don't want to disable build-time tests or ignore > > > their results, because for most architectures they are the only evidence > > > we have that a package works at all. > > > > > > > I am going to blacklist librsvg from the Loongson 3A based buildds so > > > > that it doesn't happen again. > > Your code about block Loongson has some problem, > The cpuinfo of my Loongson 3A 2000 machine is like: > cpu model : ICT Loongson-3 V0.8 FPU V0.1 > > 3B1500, it is > cpu model: ICT Loongson-3 V0.7 FPU V0.1 > > feel free about it. I have figure out a patch to disable madd.fmt insns. > Wish it can just fix this problem. > > > > > > > Thanks. I'll add a check to d/rules to make the build fail sooner if a > > > Loongson-3A CPU is detected (when not building with nocheck), to make > > > sure this blacklisting mechanism doesn't regress. > > > > For gcc, we patched it to not use madd.fmt. We should so the same thing to > > llvm. > > Let’s do it. > > > > > > > > smcv > > > > > > > > > > -- > YunQiang Su With this patch to llvm-toolchain-9, this problem has been gone. we don't need to rebuild rust for this librsvg. -- YunQiang Su mips-force-nomadd4.diff Description: Binary data
Bug#964937: RM: dictdlib dict-bouvier dict-moby-thesaurus -- RoQA; dead upstrea (10+ years); python2-only; no extrenal deps outside of this set; extremely low popcon
Hello Sandro, I'm sorry for the inconvenience but we need three separate bugs for our scripts to generate the appropriate dak commands. -- Sean Whitton signature.asc Description: PGP signature
Bug#964921: RM: golang-x-text -- RoQA; Source package was renamed to golang-golang-x-text
control: tag -1 + moreinfo Hello, On Sun 12 Jul 2020 at 07:31PM +08, Shengjing Zhu wrote: > I will amend this RM bug, after cleaning up the above packages. > But I'm not sure if the dependency problem is blocker for RM. It is. Please remove tag when fixed. -- Sean Whitton signature.asc Description: PGP signature
Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist
control: tag -1 + moreinfo Hello Nicholas, On Sat 11 Jul 2020 at 05:26PM -07, Nicholas Breen wrote: > Package: ftp.debian.org > Severity: normal > > Please remove jigl from the archive. It has not had any upstream > activity since 2006, and has the lowest popcon count of all remaining > similar tools: > > https://qa.debian.org/popcon-graph.php?packages=jigl%2C+llgal%2C+fgallery%2C+lazygal%2C+igal2%2C+imageindex_installed=on_legend=on_date=2010-01-01_date=_date=_fmt=%25Y=1 Is there any reason to think the software no longer works? Otherwise, perhaps it would be better if you were simply to orphan it. -- Sean Whitton signature.asc Description: PGP signature
Bug#963750: RM: chef -- ROM; trademark issues
Hello Jason, On Sat 11 Jul 2020 at 09:29PM -07, Jason Self wrote: > Sean Whitton asked: >> On the other hand you say you think that we should remove the Chef >> package because there are not going to be future upstream releases >> which are free software. Could you provide me a reference, please? > > The problematic pieces appear to be contained within [0]. These two > points appear to eliminate freedom #2 [1] by making exact copies > impossible. DFSG#4 probably covers this case. -- Sean Whitton signature.asc Description: PGP signature
Bug#964983: New Upstream Version
Hello, On Mon 13 Jul 2020 at 10:58PM +01, Barak A. Pearlmutter wrote: > Sometimes I wonder if Debian needs some serious process analysis and > restructuring. Should a new library version that happens to cross a major > version boundary really good though the same extra vetting queue that a new > browser goes through? I think in this case Clint meant that haskell-binary-instances would need to go through NEW, not the new github library. -- Sean Whitton signature.asc Description: PGP signature
Bug#964980: RFS: ncdu/1.15.1-0.1 [NMU] -- ncurses disk usage viewer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ncdu" * Package name: ncdu Version : 1.15.1-0.1 Upstream Author : Yoran Heling * URL : https://dev.yorhel.nl/ncdu/ * License : expat * Vcs : None Section : admin It builds those binary packages: ncdu - ncurses disk usage viewer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ncdu Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/ncdu/ncdu_1.15.1-0.1.dsc Changes since the last upload: * Non-maintainer upload. * New upstream version 1.15.1 (Closes: #953731, #957580, #961876) * d/control: - bump to debhelper compat level 13 and standard version 4.5.0 - use https homepage - add pkg-config to build-dependencies - set Rules-Requires-Root: no * d/rules: enable hardening options * d/patches: drop upstream applied patch * d/upstream: add signing-key.asc * d/watch: use https and check pgp signature Regards, -- Christian Göttsche
Bug#959845: librsvg: FTBFS on mips*el: transform::tests::parses_transform_list, transform::tests::parses_valid_transform: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))
Yunqiang Su 于2020年7月10日周五 上午8:14写道： > > On Mon, 11 May 2020 13:15:23 +0100 Simon McVittie wrote: > > Control: retitle -1 librsvg: FTBFS on Loongson-3A: assertion failed: > > t1.y0.approx_eq(t2.y0, (epsilon, 1)) > > Control: severity -1 wishlist > > Control: tags -1 + confirmed wontfix > > Control: notforwarded -1 > > > > On Mon, 11 May 2020 at 11:50:43 +0200, Aurelien Jarno wrote: > > > On 2020-05-06 11:19, Simon McVittie wrote: > > > > There seems to be a strong correlation where this test passes on a Rhino > > > > Labs UTM8 but fails on a Loongson 3A. Are there known issues with > > > > Loongson 3A hardware, or is there different FPU behaviour, or something? > > > > > > Thanks for the analysis. Yep the Loongson 3A is known for having an FPU > > > bug that could explain that behaviour. Basically it treats the madd, > > > msub, nmadd and nmsub instructions as fused while they should not. > > > > It seems strange to me that a release architecture is using > > known-to-be-faulty hardware for buildds. Is there any possibility of > > replacing those machines, or taking them out of the buildd rotation > > entirely? > > > > In particular, we treated this as a RC bug, and prioritized reporting > > it upstream; but we should not be wasting upstreams' time with issues > > that are a result of faulty hardware. I don't think we can expect every > > package maintainer, or every upstream maintainer, to know that Debian's > > mips*el buildds have this bug and that failing build-time tests that > > touch floating-point are likely to be not a real bug in the software. > > > > At the same time, I don't want to disable build-time tests or ignore > > their results, because for most architectures they are the only evidence > > we have that a package works at all. > > > > > I am going to blacklist librsvg from the Loongson 3A based buildds so > > > that it doesn't happen again. Your code about block Loongson has some problem, The cpuinfo of my Loongson 3A 2000 machine is like: cpu model : ICT Loongson-3 V0.8 FPU V0.1 3B1500, it is cpu model: ICT Loongson-3 V0.7 FPU V0.1 feel free about it. I have figure out a patch to disable madd.fmt insns. Wish it can just fix this problem. > > > > Thanks. I'll add a check to d/rules to make the build fail sooner if a > > Loongson-3A CPU is detected (when not building with nocheck), to make > > sure this blacklisting mechanism doesn't regress. > > For gcc, we patched it to not use madd.fmt. We should so the same thing to > llvm. > Let’s do it. > > > > > smcv > > > > -- YunQiang Su
Bug#964987: reportbug: Error when filing a report with release.debian.org for buster-pu
Package: reportbug
Version: 7.7.0
Severity: normal
Tags: patch
X-Debbugs-Cc: anura...@debian.org
I was attempting to file a report with release.debian.org for a
buster-pu and got an error, transcript below:
Choose the request type: 3
Please enter the name of the package: ksh
Checking status database...
Latest version seems to be 93u+20120801-3.4, is this the proper one ?
[Y|n|?]? y
Traceback (most recent call last):
File "/usr/bin/reportbug", line 2302, in
main()
File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
File "/usr/bin/reportbug", line 1709, in user_interface
res = special_prompts(package, bts, ui, fromaddr,
File "/usr/bin/reportbug", line 531, in special_prompts
return pkgprompts(package, bts, ui, fromaddr, timeout, online, http_proxy)
File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 613, in
handle_debian_release
body = textwrap.dedent("""\
TypeError: not all arguments converted during string formatting
I've attached a patch to /usr/lib/python3/dist-packages/reportbug/debbugs.py
that I used to work around.
-- Package-specific info:
** Environment settings:
EDITOR="vi"
PAGER="less"
VISUAL="vi"
DEBEMAIL="anura...@debian.org"
DEBFULLNAME="Anuradha Weeraman"
INTERFACE="text"
** /home/anuradha/.reportbugrc:
reportbug_version "7.7.0"
mode advanced
ui text
no-cc
list-cc-me
smtphost reportbug.debian.org
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.8 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages reportbug depends on:
ii apt2.1.7
ii python33.8.2-3
ii python3-reportbug 7.7.0
ii sensible-utils 0.0.12+nmu1
reportbug recommends no packages.
Versions of packages reportbug suggests:
pn claws-mail
pn debconf-utils
ii debsums 3.0.0
pn default-mta | postfix | exim4 | mail-transport-agent
pn dlocate
pn emacs-bin-common
ii file 1:5.38-5
ii gnupg 2.2.20-1
ii python3-urwid 2.1.0-4
pn reportbug-gtk
ii xdg-utils 1.1.3-2
Versions of packages python3-reportbug depends on:
ii apt2.1.7
ii file 1:5.38-5
ii python33.8.2-3
ii python3-apt2.1.3
ii python3-debian 0.1.37
ii python3-debianbts 3.0.2
ii python3-requests 2.23.0+dfsg-2
ii sensible-utils 0.0.12+nmu1
python3-reportbug suggests no packages.
-- no debconf information
--- debbugs.py.old 2020-07-13 18:59:58.431958248 -0400
+++ debbugs.py.new 2020-07-13 19:00:12.999697479 -0400
@@ -641,7 +641,7 @@
[ Other info ]
(Anything else the release team should know.)
-""" % (package, package, version))
+""")
elif tag == 'rm':
subject = 'RM: %s/%s' % (package, version)
body = '(explain the reason for the removal here)\n'
Bug#890475: Status for Vulkan development tools?
On Mon, 13 Jul 2020 16:53:42 -0600 John Zupin wrote: > The current status for the shaderc package is that it has been out for Sorry I meant to say the lunarg-vktrace package
Bug#964986: buster-pu: package ksh/93u+20120801-3.4
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: anura...@debian.org, car...@debian.org
[ Reason ]
Summary of the issue: In ksh version 20120801, a flaw was found in the
way it evaluates certain environment variables. An attacker could use
this flaw to override or bypass environment restrictions to execute
shell commands.
[ Impact ]
Services and applications that allow remote unauthenticated
attackers to provide one of those environment variables could allow them
to exploit this issue remotely, although the risk is deemed low.
[ Tests ]
There is a test included in the diff that was used to validate the
fix. Also, the regression test suite was run to make sure there were
no regressions.
[ Risks ]
The regression test suite has been run before and after the patch to
confirm no new regressions. Also, the fix is applied in unstable with no
new issues reported.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
* Patch to arith.c that fixes the CVE
* Test case for the fix
[ Other info ]
This was brought up to the security team first, and it was deemed that a
DSA is not required by Salvatore Bonaccorso.
Anuradha
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
diff -Nru ksh-93u+20120801/debian/changelog ksh-93u+20120801/debian/changelog
--- ksh-93u+20120801/debian/changelog 2018-12-14 02:26:58.0 -0500
+++ ksh-93u+20120801/debian/changelog 2020-07-12 11:26:07.0 -0400
@@ -1,3 +1,15 @@
+ksh (93u+20120801-4+deb10u1) buster-security; urgency=high
+
+ * Fix for CVE-2019-14868: in ksh version 20120801, a flaw was found
+in the way it evaluates certain environment variables. An attacker
+could use this flaw to override or bypass environment restrictions
+to execute shell commands. Services and applications that allow
+remote unauthenticated attackers to provide one of those
+environment variables could allow them to exploit this issue
+remotely. (Closes: #948989)
+
+ -- Anuradha Weeraman Sun, 12 Jul 2020 11:26:07 -0400
+
ksh (93u+20120801-3.4) unstable; urgency=medium
[ Boyuan Yang ]
diff -Nru ksh-93u+20120801/debian/patches/cve-2019-14868.patch
ksh-93u+20120801/debian/patches/cve-2019-14868.patch
--- ksh-93u+20120801/debian/patches/cve-2019-14868.patch1969-12-31
19:00:00.0 -0500
+++ ksh-93u+20120801/debian/patches/cve-2019-14868.patch2020-07-12
11:26:07.0 -0400
@@ -0,0 +1,97 @@
+Description: CVE-2019-14868
+ Certain environment variables were interpreted as arithmetic
+ expressions on startup, leading to code injection.
+Bug-Debian: https://bugs.debian.org/948989
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1757324
+Author: Kurtis Rader
+Origin:
https://github.com/ksh93/ksh/commit/593a5a8b7f272c2488c8a800820ae990942946e7
+Date: 2020-05-21
+
+diff --git a/src/cmd/ksh93/sh/arith.c b/src/cmd/ksh93/sh/arith.c
+index b1059421..6361431b 100644
+--- a/src/cmd/ksh93/sh/arith.c
b/src/cmd/ksh93/sh/arith.c
+@@ -513,21 +513,36 @@ Sfdouble_t sh_strnum(register const char *str, char**
ptr, int mode)
+ char base=(shp->inarith?0:10), *last;
+ if(*str==0)
+ {
+- if(ptr)
+- *ptr = (char*)str;
+- return(0);
+- }
+- errno = 0;
+- d = strtonll(str,,,-1);
+- if(*last || errno)
+- {
+- if(!last || *last!='.' || last[1]!='.')
+- d = strval(shp,str,,arith,mode);
+- if(!ptr && *last && mode>0)
+- errormsg(SH_DICT,ERROR_exit(1),e_lexbadchar,*last,str);
++ d = 0.0;
++ last = (char*)str;
++ } else {
++ errno = 0;
++ d = strtonll(str,,,-1);
++ if (*last && !shp->inarith && sh_isstate(SH_INIT)) {
++ /* This call is to handle "base#value" literals if
we're importing untrusted env vars. */
++ errno = 0;
++ d = strtonll(str, , NULL, -1);
++ }
++
++ if(*last || errno)
++ {
++ if (sh_isstate(SH_INIT)) {
++ /*
++ * Initializing means importing untrusted env
vars. The string does not appear to be
++ * a recognized numeric literal, so give up. We
can't safely call strval(), because
++ * that allows arbitrary expressions, causing
security vulnerability CVE-2019-14868.
++ */
++ d = 0.0;
++ } else {
++ if(!last || *last!='.' || last[1]!='.')
Bug#890474: Status for Vulkan development tools?
Hello, Brett is no longer with LunarG and I'll be making updates to his ITP bug submissions about the status of these packages. The current status for the lunarg-vulkan-layers package is that it has been out for 1+ years now and is hosted by LunarG. I am LunarG's curator for these packages, please check https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for more information about our repository.
Bug#890475: Status for Vulkan development tools?
Hello, Brett is no longer with LunarG and I'll be making updates to his ITP bug submissions about the status of these packages. The current status for the shaderc package is that it has been out for 1+ years now and is hosted by LunarG. I am LunarG's curator for these packages, please check https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for more information about our repository.
Bug#890476: Status for Vulkan development tools?
Hello, Brett is no longer with LunarG and I'll be making updates to his ITP bug submissions about the status of these packages. The current status for the lunarg-via package is that it has been out for 1+ years now and is hosted by LunarG. I am LunarG's curator for these packages, please check https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for more information about our repository.
Bug#961497: #961497 Please install registries.conf from samples directory
There is no "ideological fight". This is just unnecessary if you build your own containers, like I do. Yes, with "bud" and Dockerfiles but without external Docker registry. Since all Buildah functionality is available anyways, availability of Docker images in external registry warrants to "Suggests" or "Recommends" severity equivalent at best. Admin control over which Docker image libraries are allowed by default is more important. And since users have full control anyway through their personal configs (for rootless mode), the system-wide config allowing everything is completely unnecessary. -- Cheers, Dmitry Smirnov. --- If the truth offends, it's our job to offend. -- Satoshi Kanazawa --- Ignoring the Covid evidence: Far from following the science, the government turned its back on all available data. -- Alistair Haimes https://thecritic.co.uk/issues/july-august-2020/ignoring-the-covid-evidence/ signature.asc Description: This is a digitally signed message part.
Bug#890471: Status for Vulkan development tools?
Hello, Brett is no longer with LunarG and I'll be making updates to his ITP bug submissions about the status of these packages. The current status for the spirv-cross package is that it has been out for 1+ years now and is hosted by LunarG. I am LunarG's curator for these packages, please check https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for more information about our repository.
Bug#964977: ITS: check -- unit test framework for C
Source: check Severity: important X-Debbugs-CC: Robert Lemmen , Paul Gevers Hi, I intend to salvage the check source package. src:check was last uploaded by its maintainer in 2013 and the last two uploads are NMUs. Due to #918572 check was several months not available in testing, fixed by Paul last month. My interest in Check is based on it being a build dependency of vnstat and selint[1]. The package lacks latest upstream releases (0.12.0 vs 0.15.0). I created a NMU upload[2] but due to some changes were out of scope for an NMU, salvaging was suggested. Best regards, Christian Göttsche [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963085 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956731
Bug#964793: odd qemu/xen crashes + toolchain rings a bell
However, On 7/13/20 4:19 PM, Hans van Kranenburg wrote: > (Adding more To:; Note that mailing the bug number does not make it end > up at the submitter automatically, only the package maintainer). > > Hi Christian, > > thanks for the hints! > > On Mon, 13 Jul 2020 09:01:18 +0200 Christian Ehrhardt > wrote: >> Hi, >> I was seeing the bug updates flying by and just wanted to mention that we >> have seen something similar in Ubuntu - but back then things weren't >> replicable on Debian so we couldn't contribute things back. >> It seemed to be due to the newer and different-defaults toolchain that we >> had in Ubuntu at the time. >> >> But here qemu/xen crashes + new toolchain come together again which >> reminded me. >> >> So without any promises that it really is related I wanted to FYI you to >> these two fixes we needed for Xen: >> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1001-strip-note-gnu-property.patch?h=ubuntu/groovy-devel > > I guess this first one would be one needed? "Force fcf-protection off > when using -mindirect-branch". > > In that case want this one, it's not backported to 4.11-stable: > > "x86/build: Unilaterally disable -fcf-protection" > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a218961b16f1f4feb1147f56338faf1ac8f5703 However, this is a workaround for a gcc bug that is fixed in: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a03efb266f This fix is included in gcc-9 in Debian since 9.3.0-12: https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-9-debian/debian/changelog#L55 (it's the PR target/93654 (x86)) Reporter says the 4.11.4-1 package is used, which is built using gcc 9.3.0-13: https://buildd.debian.org/status/fetch.php?pkg=xen=all=4.11.4-1=1590602099=0 >> https://git.launchpad.net/ubuntu/+source/xen/tree/debian/patches/1000-flags-fcs-protect-none.patch?h=ubuntu/groovy-devel > > This one is about the build failing. > >> This would seem more applicable if the new toolchain would have recently >> rebuilt xen and not qemu as in this case. But as an FYI it is still worth a >> ping. > > 小太, can you do... > > xl create -vvv > > ...which should show how qemu is invoked. Can you show that command? > > I can provide you with some test packages with the mentioned upstream > patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if > your domU starts with them. > > If so, we can request the backport upstream and/or maybe pick it for > Debian 4.11 into the patch queue, whatever happens earlier. So, the above info tells us that this probably is not the issue that we're looking at. (I'm fine with still making some test packages for reporter to test with to 100% check this.) Then, let's see what shows up in the xl -vvv output and if there's anything that can be debugged when starting the qemu process with those args? > Thanks, > Hans (Debian Xen Team) >
Bug#734353: libexo-1-0: does not handle email body for mutt
On Mon, 6 Jan 2014 "Alexandra N. Kossovsky" wrote:
>
> I use mutt as e-mail client. mutt itself perfectly handles mailto:
> URLs, including the mail body. When using it via xfce, the mail body is gone.
Please find below a patch that fixes this.
It also moves the "-s subject" option to the front. As documented in the
man page, the "-a attachments" must be the last option, and it can take
multiple arguments. The '--' delimiter is used to mark the end of the
options; the remaining arguments are the recipients. Passing the message
body is possible by adding a mailto uri there, too.
--- exo-compose-mail-1.orig 2020-07-12 10:46:48.390415327 +0200
+++ exo-compose-mail-1 2020-07-13 23:56:48.089760063 +0200
@@ -221,16 +221,20 @@
}
elsif ($style eq 'mutt') {
# generate the parameters for mutt
+ $subject and push (@argv, '-s', $subject);
for my $cc (@cc) {
push (@argv, '-c', $cc);
}
for my $bcc (@bcc) {
push (@argv, '-b', $bcc);
}
- for my $uri (@attachments) {
- push (@argv, '-a', $uri->path ());
+ if (@attachments > 0) {
+ push (@argv, '-a');
+ for my $uri (@attachments) {
+ push (@argv, $uri->path ());
+ }
}
- $subject and push (@argv, '-s', $subject);
+ push (@argv, '--');
for my $to (@to) {
push (@argv, $to);
}
@@ -239,6 +243,8 @@
# any, just append an empty string and mutt
# will prompt for the To: address
(not @to) and push (@argv, '');
+
+ $body and push(@argv, 'mailto:?body=' . uri_escape($body));
}
else {
print STDERR "$0: Unsupported style '$style'.\n";
Bug#964983: New Upstream Version
Sometimes I wonder if Debian needs some serious process analysis and restructuring. Should a new library version that happens to cross a major version boundary really good though the same extra vetting queue that a new browser goes through? tldr: What have we wrought???
Bug#964223: linuxtv-dvb-apps: FTBFS with glibc 2.31 (uses removed stime function)
control: severity -1 serious
On 2020-07-03 22:27, Aurelien Jarno wrote:
> Source: linuxtv-dvb-apps
> Version: 1.1.1+rev1500-1.2
> Severity: important
> Tags: patch upstream
>
> linuxtv-dvb-apps fails to build from source with glibc 2.31:
>
> | CC dvbdate
> | dvbdate.c: In function ‘set_time’:
> | dvbdate.c:312:6: warning: implicit declaration of function ‘stime’; did you
> mean ‘ctime’? [-Wimplicit-function-declaration]
> | 312 | if (stime(new_time)) {
> | | ^
> | | ctime
> | /usr/bin/ld: /tmp/cchQDddv.o: in function `set_time':
> | ./util/dvbdate/dvbdate.c:312: undefined reference to `stime'
> | /usr/bin/ld: ./util/dvbdate/dvbdate.c:312: undefined reference to `stime'
> | collect2: error: ld returned 1 exit status
> | make[3]: *** [../../Make.rules:82: dvbdate] Error 1
> | make[3]: Leaving directory '/<>/util/dvbdate'
> | make[2]: *** [Makefile:10: all] Error 2
> | make[2]: Leaving directory '/<>/util'
> | make[1]: *** [Makefile:14: all] Error 2
> | make[1]: Leaving directory '/<>'
> | dh_auto_build: error: make -j1 returned exit code 2
> | make: *** [debian/rules:4: build] Error 25
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
>
> The full build log is available there:
> http://qa-logs.debian.net/2020/06/24/linuxtv-dvb-apps_1.1.1+rev1500-1.2_unstable_glibc-exp.log
>
> The stime function has been marked as obsolete for some time, and since
> glibc 2.31 it is no longer available to newly linked binaries. The
> clock_settime function should be used instead.
>
> You will find attached a patch fixing that. It would be nice if it can
> be fixed relatively soon so that we can start the transition.
>
Note that glibc 2.31 is now in unstable. I am therefore increasing the
severity to serious.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#964220: vdr: FTBFS with glibc 2.31 (uses removed stime function)
control: severity -1 serious On 2020-07-03 22:12, Aurelien Jarno wrote: > Source: vdr > Version: 2.4.1-4 > Severity: important > Tags: patch upstream > > Dear maintainer, > > vdr fail to build from source with glibc 2.31: > > | g++ -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DSDNOTIFY > -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/var/lib/video\" > -DCONFDIR=\"/var/lib/vdr\" -DARGSDIR=\"/etc/vdr/conf.d\" > -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/share/vdr\" > -DPLUGINDIR=\"/usr/lib/vdr/plugins\" -DLOCDIR=\"/usr/share/locale\" > -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -o > eitscan.o eitscan.c > | eit.c: In constructor ‘cTDT::cTDT(const u_char*)’: > | eit.c:394:13: error: ‘stime’ was not declared in this scope; did you mean > ‘ctime’? > | 394 | if (stime() == 0) > | | ^ > | | ctime > | make[2]: *** [Makefile:135: eit.o] Error 1 > | make[2]: *** Waiting for unfinished jobs > | make[2]: Leaving directory '/<>' > | dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" > PREFIX=/usr VIDEODIR=/var/lib/video LIBDIR=/usr/lib/vdr/plugins SDNOTIFY=1 > VERBOSE=1 returned exit code 2 > | make[1]: *** [debian/rules:17: override_dh_auto_build] Error 25 > | make[1]: Leaving directory '/<>' > | make: *** [debian/rules:14: build] Error 2 > | dpkg-buildpackage: error: debian/rules build subprocess returned exit > status 2 > > The full build log is available there: > http://qa-logs.debian.net/2020/06/24/vdr_2.4.1-4_unstable_glibc-exp.log > > The stime function has been marked as obsolete for some time, and since > glibc 2.31 it is no longer available to newly linked binaries. The > clock_settime function should be used instead. > > You will find attached a patch fixing that. It would be nice if it can > be fixed relatively soon so that we can start the transition. Note that glibc 2.31 is now in unstable. I am therefore increasing the severity to serious. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#964231: faketime: FTBFS with glibc 2.31 due to ftime deprecation
control: severity -1 serious On 2020-07-03 23:47, Aurelien Jarno wrote: > Package: faketime > Version: 0.9.7-3 > Severity: important > Tags: patch upstream > > faketime fails to build from source with glibc 2.31: > > | gcc -c -std=gnu99 -Wall -DFAKE_STAT -Werror -Wextra timetest.c > | ./testframe.sh functests > | # Begin Test Suites in functests > | > | # Begin functests/test_exclude_mono.sh > | # PLATFORM=linuxlike > | timetest.c: In function ‘main’: > | timetest.c:143:5: error: ‘ftime’ is deprecated > [-Werror=deprecated-declarations] > | 143 | ftime(); > | | ^ > | In file included from timetest.c:25: > | /usr/include/x86_64-linux-gnu/sys/timeb.h:39:12: note: declared here > |39 | extern int ftime (struct timeb *__timebuf) > | |^ > | cc1: all warnings being treated as errors > | make[2]: *** [Makefile:12: timetest.o] Error 1 > | make[2]: *** Waiting for unfinished jobs > > > The full build log is available there: > http://qa-logs.debian.net/2020/06/24/faketime_0.9.7-3_unstable_glibc-exp.log > > In glibc 2.31, the ftime function has been marked as deprecated, though > it's still usable. however the tests are run with -Wall -Wextra -Werror, > turning causing this deprecation into an error. > > Upstream already has a fix for this issue, although the issue is wrongly > attributed to gcc 9 instead of glibc 2.31: > > https://github.com/wolfcw/libfaketime/commit/f19d68ea3231f1af7a6e3913dc6d3c46f73947b2 > > This patch applies cleanly to the version in debian and correctly fixes > the issue. It would be nice if you can apply it relatively soon so that > we can start the transition. Note that glibc 2.31 is now in unstable. I am therefore increasing the severity to serious. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#964983: New Upstream Version
On Mon, Jul 13, 2020 at 09:05:28PM +0100, Barak A. Pearlmutter wrote: > There's a new upstream version available, and I cannot update the > github-backup package until libghc-github-dev (>= 0.23) is available. > So I hope to see the new version packaged. Someone would need to package binary-instances first, and then wait however many months until it gets through NEW.
Bug#964227: datefudge: FTBFS with glibc 2.31 (conflicting gettimeofday prototype)
control: severity -1 serious
On 2020-07-03 23:01, Aurelien Jarno wrote:
> Package: datefudge
> Version: 1.23
> Severity: important
> Tags: patch upstream
>
> datefudge fails to build from source with glibc 2.31
>
> | gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wall -Wextra -D_REENTRANT -fpic -c -o datefudge.o
> datefudge.c
> | sed -e 's,@VERSION@,1.23,g; s,@MULTIARCH_PATTERN@,/*-*,g;
> s,@LIBDIR@,/usr/lib,g;' \
> | < datefudge.man > datefudge.1
> | datefudge.c:81:5: error: conflicting types for ‘gettimeofday’
> |81 | int gettimeofday(struct timeval *x, struct timezone *y) {
> | | ^~~~
> | In file included from datefudge.c:21:
> | /usr/include/x86_64-linux-gnu/sys/time.h:66:12: note: previous declaration
> of ‘gettimeofday’ was here
> |66 | extern int gettimeofday (struct timeval *__restrict __tv,
> | |^~~~
> | make[1]: *** [Makefile:40: datefudge.o] Error 1
> | make[1]: Leaving directory '/<>'
> | dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true"
> returned exit code 2
> | make: *** [debian/rules:16: binary] Error 25
> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> status 2
>
> The full build log is available there:
> http://qa-logs.debian.net/2020/06/24/datefudge_1.23_unstable_glibc-exp.log
>
> The support for timezones in gettimeofday has been removed in glibc
> 2.31. As a result the second argument of the gettimeofday prototype has
> been changed from struct timezone * to void *. The same change needs to
> be done in datefudge.
>
> You will find attached a patch fixing that. It would be nice if it can
> be fixed relatively soon so that we can start the transition.
Note that glibc 2.31 is now in unstable. I am therefore increasing the
severity to serious.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Bug#964438: apt-listbugs: dns error when running from cron job
On Tue, 7 Jul 2020 23:08:03 +0200 Oswald Buddenhagen wrote: > On Tue, Jul 07, 2020 at 10:53:59PM +0200, Francesco Poli wrote: > >On Tue, 7 Jul 2020 20:17:15 +0200 Oswald Buddenhagen wrote: > >> there is a report every hour despite it claiming to be a daily job. > >> that's weird at least. > > > >It works this way by design. [...] > >The rationale is: the job must be attempted at various times, since the > >network could be down sometimes. > > > i see. you actually want anacron-like functionality with network > awareness. i guess systemd should be doing something like that ... I researched this a lot, studying the systemd documentation, but I haven't found a satisfying strategy to get what I wanted. Hence, I implemented it by myself. > > >Was your system offline 5 min after waking up from sleep? > > > no, my point was that this is happening *right* after waking up. there > is no delay. Mmmh, I am not sure what happens with systemd timers, if the machine is put to sleep. Could it be that the timer was just about to be triggered, when the machine woke up? > > >Please reply to the other questions in my previous message. > > > the only one which seems relevant would be the one about recent changes, > to which i can speculate that this possibly started with the recent-ish > systemd v245.6 upgrade. Well, I am using systemd/245.6-2 right now, and I do not experience your DNS issues. So I cannot reproduce the bug. I would love to help you, but, please help me to help you! :-) If you do not reply to my questions, I will not be able to investigate and I will have no other choice than closing this bug report as unreproducible... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpi4qpBmJKjE.pgp Description: PGP signature
Bug#964200: apt-listbugs: transient frozen string error
Control: tags -1 + unreproducible Apparently "Control" commands are ignored when sent to bug_n-close addresses... Resending to the bug address. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPy8gM1L10a.pgp Description: PGP signature
Bug#964985: libpcap0.8: build with rpcap support (--enable-remote)
Package: libpcap0.8 Version: 1.9.1-4 Severity: wishlist Dear Maintainer, since libpcap 1.9, rpcap (remote-pcap) is supported [1] and can be enabled at build by specifying --enable-remote or in cmake -DENABLE_REMOTE=YES [2]. Please consider enabling this for libpcap 1.9. [1] https://github.com/the-tcpdump-group/libpcap/issues/266#issuecomment-617655700 [2] https://github.com/the-tcpdump-group/libpcap/issues/795#issuecomment-455824284 -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpcap0.8 depends on: ii libc62.28-10 ii libdbus-1-3 1.12.16-1 libpcap0.8 recommends no packages. libpcap0.8 suggests no packages. -- no debconf information
Bug#963121: Additional analysis and suggested bugfix
Am 13.07.20 um 21:27 schrieb Gert van de Kraats: > Problem also occurs at systemd version 245.6-2 . > Indeed I am using GNOME where the login session is managed > by systemd --user. > The problem is not concerning an ordinary user service, which is killed > by SIGKILL after 90 seconds. There is no SIGKILL-message!! > As described at the initial bug-text a restart of the user dbus may > cause a hang at state > AUTHENTICATING during shutdown. At the log you can see > AUTHENTICATING starts at 18:10:02 and ends at 18:11:32, 90 seconds > later. State RUNNING is never reached. > > Jun 15 18:10:02 debian systemd[1360]: Bus bus-api-user: changing state > OPENING → AUTHENTICATING > Jun 15 18:11:32 debian systemd[1360]: Bus bus-api-user: changing state > AUTHENTICATING → CLOSED > > In that hanging situation, as soon as the user systemd gets a SIGTERM > from pid 1 (systemd) it will > call sd_bus_flush at libsystemd/sd-bus/sd-bus.c. > This will call bus_ensure_running, that repeats calling sd_bus_process, > that finally repeatingly calls bus_socket_process_authenticating. > This routine will cause a timeout after 90 seconds, the timeout-value is > hard coded by DEFAULT_TIMEOUT_USEC at basic/def.h . > > A simple and tested patch at sd_bus_flush at libsystemd/sd-bus/sd-bus.c is > next code just before the call to bus_ensure_running: > > if ((bus->state == BUS_AUTHENTICATING) && (bus->is_user)) > return -ETIMEDOUT; > > It assumes state BUS_AUTHENTICATING is not normal for an user dbus at a > call to sd_flush. > > I think this is an upstream bug! In that case, please raise this upstream at https://github.com/systemd/systemd/issues signature.asc Description: OpenPGP digital signature
Bug#964973: mesa-opencl-icd: Applications using OpenCL crash with ": CommandLine Error: Option 'polly' registered more than once!".
Package: mesa-opencl-icd Version: 20.1.2-1 Severity: important Dear Maintainer, After upgrading from version 19.1.6, applications using OpenCL are crashing with error message: ": CommandLine Error: Option 'polly' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options". For example: # clinfo : CommandLine Error: Option 'polly' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options -- Package-specific info: glxinfo: DISPLAY is not set. /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev c1) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 (2020-06-24) Xorg X server log files on system: -- -rw-r--r--. 1 root root 51966 Mar 27 2019 /var/log/Xorg.0.log -rw-r--r--. 1 roman roman 23062 Apr 29 2019 /home/roman/.local/share/xorg/Xorg.2.log -rw-r--r--. 1 root root 22875 Apr 29 2019 /var/log/Xorg.3.log -rw-r--r--. 1 roman roman 41083 Jul 13 17:46 /home/roman/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/roman/.local/share/xorg/Xorg.0.log): -- [ 105.769] (--) Log file renamed from "/home/roman/.local/share/xorg/Xorg.pid-2221.log" to "/home/roman/.local/share/xorg/Xorg.0.log" [ 105.770] X.Org X Server 1.20.8 X Protocol Version 11, Revision 0 [ 105.770] Build Operating System: Linux 4.19.0-8-amd64 x86_64 Debian [ 105.770] Current Operating System: Linux Lenovo-B51-80 5.7.0-1-amd64 #1 SMP Debian 5.7.6-1 (2020-06-24) x86_64 [ 105.770] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.7.0-1-amd64 root=UUID=a5e403c0-734b-406d-b2a7-3a9d5aff0c7e ro security=selinux quiet apparmor=0 [ 105.771] Build Date: 31 March 2020 10:14:40AM [ 105.771] xorg-server 2:1.20.8-2 (https://www.debian.org/support) [ 105.771] Current version of pixman: 0.36.0 [ 105.771]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 105.771] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 105.771] (==) Log file: "/home/roman/.local/share/xorg/Xorg.0.log", Time: Mon Jul 13 17:11:29 2020 [ 105.772] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 105.773] (==) No Layout section. Using the first Screen section. [ 105.773] (==) No screen section available. Using defaults. [ 105.773] (**) |-->Screen "Default Screen Section" (0) [ 105.773] (**) | |-->Monitor "" [ 105.773] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 105.773] (==) Automatically adding devices [ 105.773] (==) Automatically enabling devices [ 105.773] (==) Automatically adding GPU devices [ 105.773] (==) Max clients allowed: 256, resource mask: 0x1f [ 105.774] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 105.774]Entry deleted from font path. [ 105.774] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 105.774] (==) ModulePath set to "/usr/lib/xorg/modules" [ 105.774] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 105.774] (II) Loader magic: 0x564cb3e45e20 [ 105.774] (II) Module ABI versions: [ 105.774]X.Org ANSI C Emulation: 0.4 [ 105.774]X.Org Video Driver: 24.1 [ 105.774]X.Org XInput driver : 24.1 [ 105.774]X.Org Server Extension : 10.0 [ 105.776] (++) using VT number 2 [ 105.780] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_35 [ 105.781] (II) xfree86: Adding drm device (/dev/dri/card0) [ 105.782] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0 [ 105.784] (--) PCI:*(5@0:0:0) 1002:15d8:17aa:5124 rev 193, Mem @ 0xc000/268435456, 0xd000/2097152, 0xd060/524288, I/O @ 0x1000/256 [ 105.784] (II) LoadModule: "glx" [ 105.786] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 105.789] (II)
Bug#964334:
After running "sudo apt update && sudo apt upgrade && sudo apt dist-upgrade" There was an update to chromium and the issue seems to be resolved.
Bug#962384: Support for systemd-sysusers
Hi, On Sun, Jul 05, 2020 at 02:52:17PM +0200, Niels Thykier wrote: > Just to confirm, what debhelper should do with this is: > > On postinst configure: > > systemd-sysusers .conf Yes, that's all. > And that is it? I.e. there is no action to be done for any of the other > maintscripts? There might be cornercases where the system user needs to be created in the preinst. There's 668 binary packages with a Depends on adduser in sid and per "apt-cache rdepends --no-depends --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances adduser" 34 with a Pre-Depends. I checked a few of those and found some cases where a Pre-Depends in declared, but adduser only used in postinst (miredo, transmission) and a few where adduser is called in preinst (quagga, wims), but it's not really clear whether that's actually strictly needed. I'm inclined to suggest to only use it in postinst. In corner cases where it's needed in preinst it can still be added manually. Or we make it selectable via an option, not sure. post* scripts should not be needed due to lack of system user removals mentioned earlier. Cheers, Moritz
Bug#964984: ITP: pybj -- A Python encoder/decoder for Binary JData (BJData) format
Package: wnpp Severity: wishlist Name: pybj Version: 0.2.5 Summary: A Python encoder/decoder for Binary JData (BJData) format License: GPLv3+ URL: https://github.com/fangq/pybj Description: The Binary JData (BJData) Specification defines an efficient serialization protocol for unambiguously storing complex and strongly-typed binary data found in numerous application domains. The BJData specification is the binary counterpart to the JSON format, derived and extended from the Universal Binary JSON (UBJSON, http://ubjson.org) specification. This python module implements BJData Spec V1 Draft 1. Comment: I am the upstream maintainer of this python module. The code was derived from the py-ubjson project, which is currently packaged in Debian: https://packages.debian.org/sid/python-ubjson My packaging files were adapted from the python-ubjson files.
Bug#928692: #928692 - lxde: Wicd no longer maintained upstream - should not be default any longer
I struggled with the same problem and tried all the various options for Debian 11 Bullseye lxde-core. I now use package cmst and connman with lxde-core on Debian 11 Bullseye and it has been working great, even more stable with certain wifi chipsets than using wicd on Debian 10 Buster. The following brings everything required for Debian 11 Bullseye lxde-core: apt install cmst -y
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Hi, Daniel Shahaf wrote: > After extending the key I re-pushed it to keyservers, but did not > regenerate the d/u/signing-key.asc export. (I'd like to automate > that regeneration, since my key appears in multiple packages' > signing-key.asc files, but that's a question for another thread.) That might be something for lintian-brush once a lintian check is there. Cc'ing Jelmer, the author of lintian-brush. 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#963808: ruby-sanitize: CVE-2020-4054: HTML sanitization bypass in Sanitize
Hi Antonio, On Mon, Jul 13, 2020 at 11:19:38AM -0300, terce...@debian.org wrote: > On Sun, Jul 12, 2020 at 03:11:30PM +0200, Salvatore Bonaccorso wrote: > > On Sat, Jun 27, 2020 at 09:10:01PM +0200, Salvatore Bonaccorso wrote: > > > Source: ruby-sanitize > > > Version: 4.6.6-2 > > > Severity: grave > > > Tags: security upstream > > > Justification: user security hole > > > > > > Hi, > > > > > > The following vulnerability was published for ruby-sanitize. > > > > > > CVE-2020-4054[0]: > > > | In Sanitize (RubyGem sanitize) greater than or equal to 3.0.0 and less > > > | than 5.2.1, there is a cross-site scripting vulnerability. When HTML > > > | is sanitized using Sanitize's "relaxed" config, or a custom config > > > | that allows certain elements, some content in a math or svg element > > > | may not be sanitized correctly even if math and svg are not in the > > > | allowlist. You are likely to be vulnerable to this issue if you use > > > | Sanitize's relaxed config or a custom config that allows one or more > > > | of the following HTML elements: iframe, math, noembed, noframes, > > > | noscript, plaintext, script, style, svg, xmp. Using carefully crafted > > > | input, an attacker may be able to sneak arbitrary HTML through > > > | Sanitize, potentially resulting in XSS (cross-site scripting) or other > > > | undesired behavior when that HTML is rendered in a browser. This has > > > | been fixed in 5.2.1.o > > > > Attached ist a preliminary debdiff with the fix, but two prerequisites > > before "fix: Don't treat :remove_contents as `true` when it's an > > Array" and "feat: Remove useless filtered element content by default". > > > > Antonio, would it be possible to let it go trough your second pair of > > eyes, with the pre-knolege that I'm not familiar with the package but > > trying to address the CVE-2020-4054. > > > > If those look correct, the plan would be to do 4.6.6-2.1~deb10u1 based > > on that for buster-security. > > Yes, those patches look OK. > > Thanks for your work. Thanks for your review! So propsing to upload the NMU first, and then later handle the DSA for it based on that version if no negative reports come in. Regards, Salvatore
Bug#964983: New Upstream Version
Package: libghc-github-dev Version: 0.20-2 Severity: wishlist There's a new upstream version available, and I cannot update the github-backup package until libghc-github-dev (>= 0.23) is available. So I hope to see the new version packaged. Cheers, --Barak.
Bug#963808: ruby-sanitize: diff for NMU version 4.6.6-2.1
Control: tags 963808 + patch
Control: tags 963808 + pending
Dear maintainer,
I've prepared an NMU for ruby-sanitize (versioned as 4.6.6-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards,
Salvatore
diff -Nru ruby-sanitize-4.6.6/debian/changelog ruby-sanitize-4.6.6/debian/changelog
--- ruby-sanitize-4.6.6/debian/changelog 2019-02-07 21:15:34.0 +0100
+++ ruby-sanitize-4.6.6/debian/changelog 2020-07-12 15:02:54.0 +0200
@@ -1,3 +1,13 @@
+ruby-sanitize (4.6.6-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * fix: Don't treat :remove_contents as `true` when it's an Array
+ * feat: Remove useless filtered element content by default
+ * Fix sanitization bypass in HTML foreign content (CVE-2020-4054)
+(Closes: #963808)
+
+ -- Salvatore Bonaccorso Sun, 12 Jul 2020 15:02:54 +0200
+
ruby-sanitize (4.6.6-2) unstable; urgency=medium
* Team upload.
diff -Nru ruby-sanitize-4.6.6/debian/patches/Fix-sanitization-bypass-in-HTML-foreign-content.patch ruby-sanitize-4.6.6/debian/patches/Fix-sanitization-bypass-in-HTML-foreign-content.patch
--- ruby-sanitize-4.6.6/debian/patches/Fix-sanitization-bypass-in-HTML-foreign-content.patch 1970-01-01 01:00:00.0 +0100
+++ ruby-sanitize-4.6.6/debian/patches/Fix-sanitization-bypass-in-HTML-foreign-content.patch 2020-07-12 15:02:31.0 +0200
@@ -0,0 +1,134 @@
+From: Ryan Grove
+Date: Mon, 15 Jun 2020 14:27:07 -0700
+Subject: Fix sanitization bypass in HTML foreign content
+Origin: https://github.com/rgrove/sanitize/commit/a11498de9e283cd457b35ee252983662f7452aa9
+Bug: https://github.com/rgrove/sanitize/security/advisories/GHSA-p4x4-rw2p-8j8m
+Bug-Debian: https://bugs.debian.org/963808
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-4054
+
+https://github.com/rgrove/sanitize/security/advisories/GHSA-p4x4-rw2p-8j8m
+
+[Salvatore Bonaccorso: Backport to 4.6.6 for context changes]
+---
+ README.md | 11 +++
+ lib/sanitize/config/default.rb | 2 +-
+ test/test_clean_element.rb | 30 --
+ test/test_malicious_html.rb| 13 +
+ 4 files changed, 45 insertions(+), 11 deletions(-)
+
+--- a/README.md
b/README.md
+@@ -73,6 +73,11 @@ Sanitize can sanitize the following type
+ * Standalone CSS stylesheets
+ * Standalone CSS properties
+
++However, please note that Sanitize _cannot_ fully sanitize the contents of
++`` or `` elements, since these elements don't follow the same parsing
++rules as the rest of HTML. If this is something you need, you may want to look
++for another solution.
++
+ ### HTML Fragments
+
+ A fragment is a snippet of HTML that doesn't contain a root-level ``
+@@ -417,6 +422,12 @@ elements not in this array will be remov
+ ]
+ ```
+
++**Warning:** Sanitize cannot fully sanitize the contents of `` or ``
++elements, since these elements don't follow the same parsing rules as the rest
++of HTML. If you add `math` or `svg` to the allowlist, you must assume that any
++content inside them will be allowed, even if that content would otherwise be
++removed by Sanitize.
++
+ :protocols (Hash)
+
+ URL protocols to allow in specific attributes. If an attribute is listed here
+--- a/lib/sanitize/config/default.rb
b/lib/sanitize/config/default.rb
+@@ -70,7 +70,7 @@ class Sanitize
+ # the specified elements (when filtered) will be removed, and the contents
+ # of all other filtered elements will be left behind.
+ :remove_contents => %w[
+-iframe noembed noframes noscript script style
++iframe math noembed noframes noscript plaintext script style svg xmp
+ ],
+
+ # Transformers allow you to filter or alter nodes using custom logic. See
+--- a/test/test_clean_element.rb
b/test/test_clean_element.rb
+@@ -192,21 +192,16 @@ describe 'Sanitize::Transformers::CleanE
+ .must_equal ''
+ end
+
+-it 'should escape the content of removed `plaintext` elements' do
+- Sanitize.fragment('hello! alert(0)')
+-.must_equal 'hello! scriptalert(0)/script'
+-end
+-
+-it 'should escape the content of removed `xmp` elements' do
+- Sanitize.fragment('hello! alert(0)')
+-.must_equal 'hello! scriptalert(0)/script'
+-end
+-
+ it 'should not preserve the content of removed `iframe` elements' do
+ Sanitize.fragment('hello! alert(0)')
+ .must_equal ''
+ end
+
++it 'should not preserve the content of removed `math` elements' do
++ Sanitize.fragment('hello! alert(0)')
++.must_equal ''
++end
++
+ it 'should not preserve the content of removed `noembed` elements' do
+ Sanitize.fragment('hello! alert(0)')
+ .must_equal ''
+@@ -222,6 +217,11 @@ describe 'Sanitize::Transformers::CleanE
+ .must_equal ''
+ end
+
++it 'should not preserve the content of removed `plaintext` elements' do
++ Sanitize.fragment('hello!
Bug#964821: New Upstream Version
There's a new upstream version available, and I cannot update the github-backup package until libghc-github-dev (>= 0.23) is available. So I hope to see the new version packaged. Cheers, --Barak.
Bug#777403: leave: please make the build reproducible
On Sat, Jul 11, 2020 at 07:32:22AM -0400, Boyuan Yang wrote: > It has been another 3 years since last reply; is there any possibility > to push this forward? Oh, sure, I just forgot about it. -- Josip Rodin
Bug#963121: Additional analysis and suggested bugfix
Problem also occurs at systemd version 245.6-2 . Indeed I am using GNOME where the login session is managed by systemd --user. The problem is not concerning an ordinary user service, which is killed by SIGKILL after 90 seconds. There is no SIGKILL-message!! As described at the initial bug-text a restart of the user dbus may cause a hang at state AUTHENTICATING during shutdown. At the log you can see AUTHENTICATING starts at 18:10:02 and ends at 18:11:32, 90 seconds later. State RUNNING is never reached. Jun 15 18:10:02 debian systemd[1360]: Bus bus-api-user: changing state OPENING → AUTHENTICATING Jun 15 18:11:32 debian systemd[1360]: Bus bus-api-user: changing state AUTHENTICATING → CLOSED In that hanging situation, as soon as the user systemd gets a SIGTERM from pid 1 (systemd) it will call sd_bus_flush at libsystemd/sd-bus/sd-bus.c. This will call bus_ensure_running, that repeats calling sd_bus_process, that finally repeatingly calls bus_socket_process_authenticating. This routine will cause a timeout after 90 seconds, the timeout-value is hard coded by DEFAULT_TIMEOUT_USEC at basic/def.h . A simple and tested patch at sd_bus_flush at libsystemd/sd-bus/sd-bus.c is next code just before the call to bus_ensure_running: if ((bus->state == BUS_AUTHENTICATING) && (bus->is_user)) return -ETIMEDOUT; It assumes state BUS_AUTHENTICATING is not normal for an user dbus at a call to sd_flush. I think this is an upstream bug!
Bug#961195: transition: glibc
On 2020-07-13 20:43, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > Hi Aurelien, > > On 13/07/2020 19:54, Aurelien Jarno wrote: > > On 2020-07-11 18:09, Emilio Pozuelo Monfort wrote: > >> block 961195 with 955368 964223 964225 964226 964220 964227 964229 964231 > >> thanks > > > > Does it mean that we need to have those bugs fixed before starting the > > transition? > > No, I just wanted to get them in the BTS, as that would tell me at any given > time how many are still open. Ok, thanks for the explanation. I'll upload fixes to the delayed queue to fix them. > > Or can we start the transition and fix them at the same > > time? > > Yeah, let's go ahead and do that. Ok, thanks. I have just uploaded the package to unstable. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#964982: src:biojava4-live: fails to migrate to testing for too long: maintainer built arch:all binary
Source: biojava4-live Version: 4.2.12+dfsg-2 Severity: serious Control: close -1 4.2.12+dfsg-3 Tags: sid bullseye pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:biojava4-live in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=biojava4-live signature.asc Description: OpenPGP digital signature
Bug#964979: src:neutron-vpnaas: fails to migrate to testing for too long: piuparts regression
Source: neutron-vpnaas Version: 2:15.0.0-2 Severity: serious Control: close -1 2:16.0.0-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:neutron-vpnaas in its current version in unstable has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=neutron-vpnaas signature.asc Description: OpenPGP digital signature
Bug#964981: src:neutron-dynamic-routing: fails to migrate to testing for too long: piuparts regression
Source: neutron-dynamic-routing Version: 2:15.0.0-3 Severity: serious Control: close -1 2:16.0.0-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:neutron-dynamic-routing in its current version in unstable has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=neutron-dynamic-routing signature.asc Description: OpenPGP digital signature
Bug#964978: src:ruby-pgplot: fails to migrate to testing for too long: B-D on non-free package
Source: ruby-pgplot Version: 0.1.9-3 Severity: serious Control: close -1 0.2.0-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:ruby-pgplot in its current version in unstable has been trying to migrate for 62 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=ruby-pgplot signature.asc Description: OpenPGP digital signature
Bug#964044: mrpt: FTBFS: test failure
On 2020-06-30 22:37:57 +0200, Sebastian Ramacher wrote: > Source: mrpt > Version: 1:2.0.4-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > binNMUs of mrpt failed to build: > | [--] 1 test from RawlogGrabberApp > | [ RUN ] RawlogGrabberApp.CGenericCamera_AVI > | [CCameraSensor::initialize] Opening camera... > | [CCameraSensor::initialize] FFmpeg stream: > /<>/share/mrpt/datasets/dummy_video.avi... > | [CCameraSensor::initialize] Done! > | Rawlog grabbed objects: 1 > | /<>/libs/apps/src/RawlogGrabberApp_unittest.cpp:94: Failure > | Expected: (app.rawlog_saved_objects) >= (REQUIRED_GRAB_OBS), actual: 1 vs 3 > | [ FAILED ] RawlogGrabberApp.CGenericCamera_AVI (1511 ms) > | [--] 1 test from RawlogGrabberApp (1511 ms total) > > See > https://buildd.debian.org/status/fetch.php?pkg=mrpt=amd64=1%3A2.0.4-1%2Bb1=1593549279=0 > for example This issue has been fixed upstream: https://github.com/MRPT/mrpt/commit/15234dc335c2413e3fd41021f7511f1d36fe915b. Could you please apply the fix to the Debian package so that ros-geometry2 transition can be completed? Thanks Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#964955: [Tts-project] Bug#964955: Please move the executables to /usr/libexec/
Hi Laurent, On 13-07-2020 13:00, Laurent Bigonville wrote: > Debian now officially support the FHS 3.0 which allows executables to be > installed in (a subfolder of) /usr/libexec Apart from being allowed, can you elaborate why that would be desirable? (I honestly don't know). Paul signature.asc Description: OpenPGP digital signature
Bug#923860: rsync crashes sporadically when remote host closes connection
Hello, This is not addressing the issue directly, but I think it's worth pointing out, > That is definitely weird. rsync is one of the few Debian packages without > debug symbols of any type available, so it had to be rebuilt, but it was > rebuilt from the same source archive (apt-get source rsync) and version as > the original crashing binary. The line numbers /should/ match up. Starting with 3.1.3-7, rsync has now dbgsym packages, unfortunately stable has 3.1.3-6 and we can't perform a stable update for this change. We recently uploaded rsync to buster-backports, this means that rsync on backports does ship dbgsym. And starting with the next stable release (Debian 11/bullseye), rsync will provide dbgsym packages. Regards, -- Samuel Henrique
Bug#961195: transition: glibc
Control: tags -1 confirmed Hi Aurelien, On 13/07/2020 19:54, Aurelien Jarno wrote: > On 2020-07-11 18:09, Emilio Pozuelo Monfort wrote: >> block 961195 with 955368 964223 964225 964226 964220 964227 964229 964231 >> thanks > > Does it mean that we need to have those bugs fixed before starting the > transition? No, I just wanted to get them in the BTS, as that would tell me at any given time how many are still open. > Or can we start the transition and fix them at the same > time? Yeah, let's go ahead and do that. Cheers, Emilio
Bug#870641: light-locker: screen stays black after closing and opening laptop lid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2020-07-13 at 10:33 +0800, Aaron Lu wrote: > On Tue, May 12, 2020 at 11:13:52AM +0200, Yves-Alexis Perez wrote: > > I've also re-pinged upstream Linux and the patch should be included in the > > next Linux point release (hopefully 4.19.123), and which will then be > > included > > in Debian buster for the next Debian point release (hopefully 10.5). It's > > not > > tomorrow but still it should help at one point. > > Just want to report that I have installed 5.6.0-0.bpo.2-amd64 from > buster-backport and now the display can be powered back on when I > pressed my keyboard or moved my mouse. Could you try linux-image-4.19.0-10-amd64 from testing-proposed-updates and report back? It should include the fix. > I do not see any other problems right now, everything seems to work > fine, except one error message in dmesg everytime the display goes the > off-on cycle: > broken atomic modeset userspace detected, disabling atomic > But I guess it's a different problem and it doesn't seem to cause any > problem. Actually the problem lies in the way Xorg uses atomic, and that's why the fix is to disable them. So if you see the message that means the fix is correctly applied. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl8Mp0YACgkQ3rYcyPpX RFs+kQgA6vO+abjPhh198KJPDVy/970Y7sEW1qgx7pHsrWy2/McdNWfWydSlld0x 29BKlYY/ZlwHP9AX5yLjR6gnuxHum4AncJu982w/+zlG3cB/VisSjBsCxOeM8nMW 8CsCidxq56YUiOIjA5GaKwroK6jb84SfmMva3BkURYB/teSs7URJ9nnunyWtITDv HJYKrYND99/vc1KaSOTBE6T6FK5jPaH8HPOARMSMXOinVkba/QGLdYl6YC/mtMif WD6QC6DkcLqK7z95Q33hOHIMyL418tqfoUIz+twv3FGel067EnSj6jbU4zGgXrz3 LyPx2UMh8pqBEtrvvFXWUge1I9JY2w== =j2FJ -END PGP SIGNATURE-
Bug#964102: gle-graphics should build depend on libqt5opengl5-desktop-dev instead of libqt5opengl5-dev
Adrian, On Wed, Jul 01, 2020 at 10:26:33PM +0300, Adrian Bunk wrote: > Source: gle-graphics > Version: 4.2.5-8 > Severity: important > Tags: ftbfs > > gle-graphics FTBFS on armel and armhf: > > https://buildd.debian.org/status/package.php?p=gle-graphics=sid > > ... > 3dviewer.cpp: In destructor ‘virtual QGLE3DWidget::~QGLE3DWidget()’: > 3dviewer.cpp:56:6: error: ‘glDeleteLists’ was not declared in this scope >56 | glDeleteLists(object, 1); > | ^ > ... > > The root cause is that on armel/armhf > Qt5 is compiled with OpenGL ES instead of OpenGL. > > Ideally it should be fixed to build and work with OpenGL ES, > changing the build dependency from libqt5opengl5-dev to > libqt5opengl5-desktop-dev would at least stop trying to > build on armel/armhf. Thanks for the hint! I am not sure if I am in the position to fix the OpenGL issues, but maybe somebody from the glx list is. However, I will make use of your workaround until this can be sorted out. thanks, Christian
Bug#964441: geeqie: No image is rendered, only white rectangle visible
On Wed, 08 Jul 2020 09:22:47 +0800 Paul Wise wrote: > Control: forwarded -1 > https://github.com/BestImageViewer/geeqie/issues/539 Control: retitle > -1 geeqie: No image is rendered, only white rectangle visible under > GNOME Wayland Control: tags -1 + patch Control: usertags -1 + wayland > > On Tue, 07 Jul 2020 12:19:13 +0200 Florian wrote: > > > No image is shown, instead only a white rectangle is visible. > > I'm getting this too. > > > I am on gnome/wayland. > > I've tested GNOME Xorg and it does not have this issue, retitling. > > > Might be this one: > https://github.com/BestImageViewer/geeqie/issues/539 > > Marking as forwarded. > > It seems there is a patch that makes it work for GPU acceleration mode > but unfortunately not for software rendering mode. > Thanks guys - have I understood correctly that upstream current Git fixes it properly? I have tested some with latest upstream git, and to me it seems it does, but I would like confirmation that it fixes it for you too - I am a bit hesitant in packaging a Git snapshot, but if that is what it takes to fix the bug, then so be it. Upstream unfortunately makes new releases very rarely. /Andreas Rönnquist gus...@debian.org
Bug#955368: busybox FTBFS with glibc 2.31 (references to obsolete 'stime')
Hi, On 2020-03-30 09:17, Steve Langasek wrote: > Package: busybox > Version: 1:1.30.1-4 > Severity: important > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu focal ubuntu-patch > > Dear maintainers, > > In Ubuntu, the busybox package has begun to FTBFS because Ubuntu has moved > to glibc 2.31, which has obsoleted the stime() function and busybox still > calls this function. > > The attached patch has been uploaded to Ubuntu, replacing the calls to > stime() with clock_settime(), per the glibc upstream documentation. > > This is not a serious bug today in Debian because glibc 2.31 is only in > experimental, but at some point it will become a serious FTBFS. It would be nice if this bug could be fixed as it is currently blocking the glibc 2.31 transition. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#959363: jenkins.debian.org: broken links in index_suite_${ARCH}_stats.html
Hi Patrice, fixed now. & thanks for your bug report and patience in the first place! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C There are no jobs on a dead planet. signature.asc Description: PGP signature
Bug#961195: transition: glibc
On 2020-07-11 18:09, Emilio Pozuelo Monfort wrote: > block 961195 with 955368 964223 964225 964226 964220 964227 964229 964231 > thanks Does it mean that we need to have those bugs fixed before starting the transition? Or can we start the transition and fix them at the same time? Beside busybox, they are all leaf packages or almost. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#964729: vim-gitgutter doesn't respect the Debian vim policy
On 2020-07-11 09 h 37, James McCoy wrote: > On Thu, Jul 09, 2020 at 01:00:24PM -0400, Louis-Philippe Véronneau wrote: >> On 2020-07-09 12 h 37, Raphael Medaer wrote: >>> Dear Louis-Philippe, >>> >>> The first packaging I did (not published) was using `vim-addon-manager`. >>> Although I switch to dh-vim_addon (and friends) which is not using >>> `vim-addon-manager` anymore. >>> This move has been recommended by James McCoy (who >>> sponsored the package). >>> >>> I guess you spotted a lack of documentation/policy for this new helper: >>> `dh-vim_addon`. >>> I add James in CC. Maybe should we discuss/write a new Policy and/or some >>> guidelines. >>> >>> I already started a TODO list of checks for new/next vim addon packages. I >>> would appreciate some feedback on it, but first let me a few days to make >>> it clean. >>> >>> Here are some additional notes about your comments: >>> >>> > It appears this package doesn't follow the Debian vim policy [1]. It's >>> > clearly not easy to find (I had to search quite a bit to find it), but I >>> > think it's important vim packages try to respect it :) >>> >>> Is this policy still relevant ? Already mentionned above. >> >> No idea, I'm only a vim user and I haven't done any vim work in Debian :) > > The policy basically codifies the behavior that we implemented in vam. > That's problematic in its own right, but also an issue because vam is > very flawed (see #438482). > > >>> > * the addon is enabled after the installation; it shouldn't >>> >>> If I well understood James' advices: with `dh-vim_addon` help, vim addon >>> packages should always be enabled if you can disable them through your >>> vimrc with `let g:loaded_gitgutter = 1`. >> This is quite a big change and I guess it breaks my current setup :s > > I'm curious about how this breaks your setup. Could you explain this > more? Nothing important really. I use configuration management on hosts I use (servers and clients) to get a consistent vim profile, and I used vam to enable or disable addons. Addons being enabled by default will simply mean everything will be done via vimrc files. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#964976: ITP: tao-config -- C++ header-only library that reads config files and produces a JSON value
Package: wnpp Severity: wishlist Subject: ITP: tao-config -- C++ header-only library that reads config files and produces a JSON value Package: wnpp Owner: Shayan Doust Severity: wishlist * Package name: tao-config Version : 0.0+git20200604.84a7383 Upstream Author : Dr. Colin Hirsch * URL : https://github.com/taocpp/config * License : Expat Programming Lang: C Description : C++ header-only library that reads config files and produces a JSON value C++ header-only library that reads config files based on JSON and JAXN formats and in turn, produces a single JSON valur as a result. . Its features are as follows: 1. JAXN syntax with extensions (backwards compatible with JSON). 2. JAXN data model (JSON extended with binary data and non-finites). 3. Meta data, all sub-values are annotated with filename and position. 4. Copy, reference, replace and delete anything in the JSON structure. 5. Multiple ways to read and parse other config and data files. 6. Uses environmental variables and the output of arbitrary shell commands. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/tao-config
Bug#949394: libsmbclient rename failure: related samba bugs
These samba bugs are probably related: https://bugzilla.samba.org/show_bug.cgi?id=13599 https://bugzilla.samba.org/show_bug.cgi?id=14169
Bug#819460: lintian: duplicate-updaterc.d-calls-in-postinst false positive
Hi Richard, > FYI, I also had to silence a duplicate-updaterc.d-calls-in-postinst > false positive in ddclient. The two calls to update-rc.d are in the two > branches of an 'if' statement, so it is not actually called twice. > > See lines 139 and 149 of: > https://salsa.debian.org/debian/ddclient/-/blob/debian/3.9.1-2/debian/postinst#L139 > > Commit that disabled the lintian check: > https://salsa.debian.org/debian/ddclient/-/commit/b65a60e072334f0cee52b41ed4b254bce0d02bad Glancing at this quickly, we now have: update-rc.d ddclient defaults >/dev/null invoke-rc.d ddclient start || exit 1 … yet we should be skipping the first due to: next unless /^(?:.+;|^\s*system[\s\(\']+)?\s*update-rc\.d\s+ So maybe we can fix this one. Can't immediately see why this is not working. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#964975: ugrep: Wrong synopsis line
Package: ugrep Version: 2.1.1+dfsg-1 Severity: normal X-Debbugs-Cc: eribe...@debian.org Dear Maintainer, The synopsis in your package is not compliant with Debian Policy §3.4.1. Using 'apt search ugrep' I can see: ugrep/unstable 2.1.1+dfsg-1 amd64 Universal grep: ultra fast searcher of file systems, text and Please, use an informative line to describe your package. Regards, Eriberto -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64)
Bug#964141: libc6: "cannot allocate memory in static TLS block" with some library combinations on arm64
Control: tags -1 + fixed-upstream On Fri, Jul 03, 2020 at 03:57:36PM +0200, Gianfranco Costamagna wrote: > control: tags -1 patch > > Hello, the patch (v5) applied on top of 2.31 (build-tested in Ubuntu) > seems to solve the issue Thanks for testing it! Dear glibc maintainers: the patchset was updated to v6 and then committed upstream a few days ago: Cover mail: https://sourceware.org/pipermail/libc-alpha/2020-July/115968.html PATCH 1/3: https://sourceware.org/git/?p=glibc.git;a=commit;h=0c7b002fac12dcb2 PATCH 2/3: https://sourceware.org/git/?p=glibc.git;a=commit;h=17796419b5fd6943 PATCH 3/3: https://sourceware.org/git/?p=glibc.git;a=commit;h=ffb17e7ba3a5ba96 Fix for this bug is in the third patch, but I guess it needs the first two as well if you will be backporting it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#960073: Package:python-pyqt5 Run the example code with Trace and crash (SIGABRT)
Hi, sorry for the late reply too. On Mon, Jul 06, 2020 at 02:56:04PM +0800, pengzon...@uniontech.com wrote: > Hi! > > Sorry for my late reply. I preload libGLX_mesa.so.0 , and then run the code > on the arm machine is ok. > I tried to debug it, and then I found something different. The parameter of > __glXLookupVendorByName is NVIDIA instead of mesa, it will dlopen > libGLX_nvidia.so.0, but my Graphics Card is AMD, only IibGLX_mesa.so.0 can > be found locally, so __glXLookupVendorByName failed. It looks like for some reason your X server returns "nvidia" in response to glXQueryServerString request. I would suggest you to try writing a minimal test case that would call glXQueryServerString (e.g. via libxcb and xcb_glx_query_server_string), and check what happens. If the value is wrong then maybe open a bug against the X server. Exporting __GLX_VENDOR_LIBRARY_NAME=mesa (or whatever) env variable should override it. P.S. The glibc patch was accepted upstream, so it will land in Debian packages sooner or later. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#964974: berusky-data: Please add Multi-Arch: foreign
Package: berusky-data Version: 1.7-2 Severity: wishlist User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi, It looks like berusky-data offers an architecture independent (data level) interface to its users. Would you mind setting it to Multi-Arch: foreign? It's usually a matter of adding one line to debian/control. This would hopefully improve install options for different architectures. Like running the x32 variant on an amd64 system. Note: Architecture=all packages are not Multi-Arch=foreign automatically for various reasons, so they need to be set manually. Cheers Elrond
Bug#964967: systemd: ExecStartPost executed even if ExecStart fails immediately
Am 13.07.20 um 17:49 schrieb Michael Biebl: > Am 13.07.20 um 17:04 schrieb Drexl Johannes: >> Package: systemd >> Version: 241-7~deb10u4 >> Severity: normal >> >> Dear Maintainer, >> >> tests on systemd environment variables under certain conditions got me >> puzzled, >> and I guess this would be considered a bug. >> >> A systemd service will execute all ExecStartPost statements, even if the >> corresponding service configured with ExecStart has bailed out with error >> code. >> One can test it with a [Service] section like that: >> >> Type=exec > > If you want this behaviour, use Type=oneshot, not Type=exec I.e. with Type=exec, systemd will not wait until the program specified in ExecStart= has terminated (and evaluates its exit code) before it proceeds executing the next command. signature.asc Description: OpenPGP digital signature
Bug#964972: xfsm-shutdown: general protection fault for xfsm-shutdown-h
Package: xfce4-session Version: 4.12.1-6 Severity: normal File: xfsm-shutdown-helper Dear Maintainer, While I required the hibernate state, this command does not work and logs are : traps: xfsm-shutdown-h[8091] general protection fault ip:7fd18613e9bd sp:7ffe359f9370 error:0 in libc-2.28.so[7fd1860dc000+148000] Note that the swap memory was deactivated some seconds or minutes before by me. It was perhaps the cause but it should not get a general protection fault. -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-session depends on: ii libatk1.0-02.36.0-2~bpo10+1 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libdbus-1-31.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk2.0-02.24.32-3 ii libice62:1.0.9-2 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-01.42.4-8~deb10u1 ii libpangoft2-1.0-0 1.42.4-8~deb10u1 ii libpolkit-gobject-1-0 0.105-25 ii libsm6 2:1.2.3-1 ii libwnck22 2.30.7-6 ii libx11-6 2:1.6.7-1 ii libxfce4ui-1-0 4.12.1-3 ii libxfce4util7 4.12.1-3 ii libxfconf-0-2 4.12.1-1 ii xfce4-settings 4.12.4-1 ii xfconf 4.12.1-1 Versions of packages xfce4-session recommends: ii dbus-x11 1.12.16-1 ii libpam-systemd 245.6-1~bpo10+1 ii light-locker 1.8.0-3 ii systemd-sysv 245.6-1~bpo10+1 ii upower 0.99.10-1 ii x11-xserver-utils 7.7+8 ii xfdesktop4 4.12.4-2 ii xfwm4 4.12.5-1 Versions of packages xfce4-session suggests: pn fortunes-mod ii sudo 1.8.27-1+deb10u2 -- no debconf information
Bug#890472: Status for Vulkan development tools?
Hello, Brett is no longer with LunarG and I'll be making updates to his ITP bug submissions about the status of these packages. The current status for the shaderc package is that it has been out for 1+ years now and is hosted by LunarG. I am LunarG's curator for these packages, please check https://vulkan.lunarg.com/sdk/home under the "ubuntu packages" tab for more information about our repository.
Bug#964967: systemd: ExecStartPost executed even if ExecStart fails immediately
Am 13.07.20 um 17:04 schrieb Drexl Johannes: > Package: systemd > Version: 241-7~deb10u4 > Severity: normal > > Dear Maintainer, > > tests on systemd environment variables under certain conditions got me > puzzled, > and I guess this would be considered a bug. > > A systemd service will execute all ExecStartPost statements, even if the > corresponding service configured with ExecStart has bailed out with error > code. > One can test it with a [Service] section like that: > > Type=exec If you want this behaviour, use Type=oneshot, not Type=exec See man systemd.service >• The exec type is similar to simple, but the service manager > will consider the unit started immediately after the main service binary has > been executed. The service manager will delay starting of follow-up units > until that point. (Or in other >words: simple proceeds with further jobs right after fork() > returns, while exec will not proceed before both fork() and execve() in the > service process succeeded.) Note that this means systemctl start command > lines for exec services will report >failure when the service's binary cannot be invoked > successfully (for example because the selected User= doesn't exist, or the > service binary is missing). Afaics, everything is working as documented signature.asc Description: OpenPGP digital signature
Bug#964959: mpack: Non-standard headers risk mail being marked as spam
Package: mpack Version: 1.6-15 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, When sending a file which does not require splitting across emails, mpack creates the header "Mime-Version" rather than "MIME-Version" as used in RFC 2045. Although the RFC does not specify case-sensitivity, this behaviour does cause spam scoring for some recipients (e.g., those using rspamd) so the behaviour should be amended. This will also make behaviour consistent within the package, as when splitting files across emails the header "MIME-Version" is already used. The necessary change is at encode.c.124 -- apologies but I am not sure on what the most helpful patch format to supply here would be. Sam - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mpack depends on: ii libc6 2.30-8 mpack recommends no packages. Versions of packages mpack suggests: pn inews ii postfix [mail-transport-agent] 3.5.4-1 - -- no debconf information -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEEpNktSs6Yz6ACYTv0nBYn1jXHAa4FAl8MR/0UHGRlYmlhbkBz ZGtlbXAuY28udWsACgkQnBYn1jXHAa4leAf/aNZbG8McFuNLlnLh3MiTvCzSpBpA osLDTx/DyfLFyQqNuWx8EQZqAfF4tR9oyOHcXV1OCxM7ZofsizalOrgd5ZVNUK1L OO1Jd4oDeJp7BjjxwEtELFkAdC10elyojRMl91LurnkWE31+zkOpdF3yJyesgrWq X6damLp4n+N661+kpJvgkLTwSrpMCMMxQ6hfHNyWzmXOjGPHEb5bCWvF7Wvyn5yX TY9OxKekqjLTOBE/+AHBntaQohbp7tVQag1IWaRANqsiiKsSu148E4g3kHl5sUlM cLwCCSxilGwUQkrJDVCQB6qEcrNWq1MugAM9x4Q9rKU+ZPEx5HEQF1NjsA== =5BTS -END PGP SIGNATURE-
Bug#964318: gosa login broken with PHP 7.4
Control: forwarded -1 https://github.com/gosa-project/gosa-core/pull/33 Hi, On Do 09 Jul 2020 21:54:34 CEST, Wolfgang Schweer wrote: On Mon, Jul 06, 2020 at 12:05:44PM +0200, Wolfgang Schweer wrote: In both encrypt and decrypt cases, the chosen cipher method seems to return 0. This is the case because the chosen method (aes-256-ecb) doesn't use an initialization vector ($iv) at all, causing its length ($ivlen) to be 0, see e.g. https://usr.ed48.com/php/ssl/?xf=7 So the encrypt/decrypt implementation seems to have been sort of wrong before (and only now with PHP 7.4 an error is thrown). Please check and test the attached changes to /usr/share/gosa/include/functions.inc and /usr/sbin/gosa-encrypt-passwords; works for me, but then my skills are low level and this is a quite sensitive issue. Wolfgang patch submitted upstream. https://github.com/gosa-project/gosa-core/pull/33 Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpO_IaXRLe8T.pgp Description: Digitale PGP-Signatur
Bug#962239: RFP: jc -- converts command output to JSON
Control: tags -1 pending This has now been uploaded and will appear in the NEW queue at https://ftp-master.debian.org/new.html. ftp-masters will review it next. I will add the man page on the next upload (if ftp-masters accepts this from NEW). -- Regards Sudip
Bug#964927: ibus-avro: Remove deps on ibus IM module packages
Control: tags -1 + pending Fix pushed to repo: https://salsa.debian.org/input-method-team/ibus-avro/-/commit/06990e57 (Don't know why salsa didn't do this automatically.) -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj
Bug#963706: kdenlive with ffmpeg version 7:4.3-2 can't Render Project to MP4
Ah, thanks for the clarification. I misread your earlier message. There do not appear to be any bugs currently filed against libmlt6, so I assume the correct next step would be to file one there? On Sat, 11 Jul 2020 05:25:16 +0100 Rik Mills wrote: > On 11/07/2020 04:14, Stephen Hwang wrote: > > I encountered bug #963706 last week, and was happy to see that it had been addressed > > in version 20.04.3-1 uploaded today, July 10. Unfortunately, the new version does > > not appear to fix the bug for me. > > As previously mentioned, the issue is with MLT, and it is that which > requires a rebuild against the new ffmpeg. That is why this bug was not > fixed via the new kdenlive upload. > > >
Bug#964971: lintian: please consider new check: expired keys in debian/upstream/signing-key.asc
Package: lintian Version: 2.83.0 Severity: wishlist Tags: upstream Dear Maintainer, I noticed yesterday that the current source package of zsh-syntax-highlighting contains a debian/upstream/signing-key.asc file which contains an expired snapshot of upstream's signing key: the snapshot gives the key's expiration date as 2018-06-28.¹ I then generated and built that package on a then-current sid chroot and observed that no lintian warnings were logged about the expired key. I invoked lintian as «lintian --display-info --display-experimental --pedantic --color=always --no-tag-display-limit /build/*.changes /build/*.dsc /build/*.deb». I was wondering whether it would be a good idea for Lintian to add a check for expired keys in debian/upstream/signing-key.asc. Despite the name being in singular, signing-key.asc may contain multiple keys, just like upstream tar.gz.asc files may contain multiple people's signatures. I am not sure what the semantics of the check should be when that file contains multiple keys, only some of which are expired. When upstream's release manager (RM)'s identity changes, it can be useful to keep carrying the outgoing RM's public key, in order to make it easier to verify past and potential future upstream releases signed with that key. However, someone who had stepped down from being RM might let their key expire and not renew it until and unless they resume being the RM. An alternative point of view is that signing-key.asc should contain only keys that are currently in use, and older keys should be removed (they'll still be available in archived sourced packages). Under this point of view, there might be room for an additional check that the keys in signing-key.asc are indeed those keys used to sign the upstream tarball. Cheers, Daniel ¹ In this particular case, upstream's key is my key, and that key has been regularly extended (to 2020-07-01 and to 2021-12-31). After extending the key I re-pushed it to keyservers, but did not regenerate the d/u/signing-key.asc export. (I'd like to automate that regeneration, since my key appears in multiple packages' signing-key.asc files, but that's a question for another thread.)
Bug#964970: RFP: dotpagemod -- Firefox add-on to load local CSS and JavaScript from your dotfiles into websites
Package: wnpp Severity: wishlist * Package name: dotpagemod Version : 0.4.1 Upstream Author : David Kalnischkies * URL : https://github.com/DonKult/dotPageMod * License : Expat Programming Lang: JavaScript -- Jakub Wilk
Bug#964969: RFP: open-in-browser -- Firefox add-on to open files directly in the browser
Package: wnpp Severity: wishlist * Package name: open-in-browser Version : 2.11 Upstream Author : Rob Wu * URL : https://github.com/Rob--W/open-in-browser * License : MPL-2.0 Programming Lang: JavaScript Firefox extension that offers the ability to open files directly in the browser instead of downloading them. You can also change the MIME-type if you wish, and choose to remember the preferred action per file-type. -- Jakub Wilk
Bug#964968: RFP: webext-urls-list -- Firefox add-on to list URLs
Package: wnpp Severity: wishlist * Package name: webext-urls-list Version : 0.5.0 Upstream Author : Moritz H * URL : https://github.com/moritz-h/urls-list * License : Expat Programming Lang: JavaScript Firefox extension to list the URLs of all tabs from the current window as copyable plain text. This extension can also load a plain text list of URLs to individual tabs. -- Jakub Wilk
Bug#964967: systemd: ExecStartPost executed even if ExecStart fails immediately
Package: systemd Version: 241-7~deb10u4 Severity: normal Dear Maintainer, tests on systemd environment variables under certain conditions got me puzzled, and I guess this would be considered a bug. A systemd service will execute all ExecStartPost statements, even if the corresponding service configured with ExecStart has bailed out with error code. One can test it with a [Service] section like that: Type=exec User=debian Group=debian # Test ExecStartPre=/bin/true ExecStart=/bin/false ExecStartPost=/bin/echo "StartPost Beginn" ExecStartPost=/bin/sleep 5 ExecStartPost=/bin/printenv ExecStartPost=/bin/true ExecStop=/bin/echo "Stop Beginn" ExecStop=/bin/printenv ExecStop=/bin/true ExecStopPost=/bin/echo "StopPost Beginn" ExecStopPost=/bin/printenv This will result in a situation captured in journal: Jul 13 16:57:29 primus systemd[1]: test.service: Main process exited, code=exite -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- An ExecStart= process belonging to unit test.service has exited. -- -- The process' exit code is 'exited' and its exit status is 1. Jul 13 16:57:29 primus echo[24742]: StartPost Beginn Jul 13 16:57:34 primus printenv[24744]: LANG=en_US.UTF-8 Jul 13 16:57:34 primus printenv[24744]: PATH=/usr/local/sbin:/usr/local/bin:/usr Jul 13 16:57:34 primus printenv[24744]: HOME=/home/debian Jul 13 16:57:34 primus printenv[24744]: LOGNAME=debian Jul 13 16:57:34 primus printenv[24744]: USER=debian Jul 13 16:57:34 primus printenv[24744]: SHELL=/bin/bash Jul 13 16:57:34 primus printenv[24744]: INVOCATION_ID=e9c25c8c677743b19cf95abe7c Jul 13 16:57:34 primus printenv[24744]: JOURNAL_STREAM=9:2458318 Jul 13 16:57:34 primus echo[24746]: StopPost Beginn As is clearly visible, Systemd knows the main process bailed out prior to Systemd beginning to execute even the first ExecStartPost statement. Although I might miss out some really important thoughts on why it was decided as such, I find it a little confusing, because all ExecStop statements are skipped as can be read in the documentation. -- Package-specific info: -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /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-4 ii libapparmor1 2.13.2-10 ii libaudit11:2.8.4-3 ii libblkid12.33.1-0.1 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcryptsetup12 2:2.1.0-5+deb10u2 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.6.7-4+deb10u4 ii libgpg-error01.35-1 ii libidn11 1.33-2.2 ii libip4tc01.8.2-4 ii libkmod2 26-1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.33.1-0.1 ii libpam0g 1.3.1-5 ii libseccomp2 2.3.3-4 ii libselinux1 2.8-1+b1 ii libsystemd0 241-7~deb10u4 ii mount2.33.1-0.1 ii util-linux 2.33.1-0.1 Versions of packages systemd recommends: ii dbus1.12.16-1 ii libpam-systemd 241-7~deb10u4 Versions of packages systemd suggests: ii policykit-10.105-25 pn systemd-container Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.133+deb10u1 ii udev 241-7~deb10u4 -- Configuration Files: /etc/systemd/timesyncd.conf changed [not included] -- no debconf information
Bug#964950: nginx: CVE-2020-11724
In case this helps, here's some documentation to test the issue with the
new upstream test cases:
https://wiki.debian.org/LTS/TestSuites/nginx
and my planned stretch package:
https://www.beuc.net/tmp/debian-lts/nginx/
Cheers!
Sylvain Beucler
Debian LTS Team
diff -Nru nginx-1.10.3/debian/changelog nginx-1.10.3/debian/changelog
--- nginx-1.10.3/debian/changelog 2020-01-11 08:28:05.0 +0100
+++ nginx-1.10.3/debian/changelog 2020-07-13 11:40:49.0 +0200
@@ -1,3 +1,11 @@
+nginx (1.10.3-1+deb9u5) stretch-security; urgency=high
+
+ * Non-maintainer upload by the LTS Security Team.
+ * CVE-2020-11724: ngx_http_lua_subrequest.c allows HTTP request
+smuggling, as demonstrated by the ngx.location.capture API.
+
+ -- Sylvain Beucler Mon, 13 Jul 2020 11:40:49 +0200
+
nginx (1.10.3-1+deb9u4) stretch; urgency=medium
* Handle CVE-2019-20372, error page request smuggling
diff -Nru nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
--- nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
1970-01-01 01:00:00.0 +0100
+++ nginx-1.10.3/debian/modules/patches/nginx-lua/CVE-2020-11724.patch
2020-07-13 11:40:49.0 +0200
@@ -0,0 +1,863 @@
+Origin:
https://github.com/openresty/openresty/commit/4e8b4c395f842a078e429c80dd063b232357
+Origin:
https://github.com/openresty/lua-nginx-module/commit/9ab38e8ee35fc08a57636b1b6190dca70b0076fa
+Last-Update: 2020-07-13
+Reviewed-by: Sylvain Beucler
+
+commit 96c330c3cb2a5abc95d293854801c7ba2896d1da
+Author: Thibault Charbonnier
+Date: Mon Mar 23 19:40:47 2020 -0700
+
+bugfix: prevented request smuggling in the ngx.location.capture API.
+
+From 9ab38e8ee35fc08a57636b1b6190dca70b0076fa Mon Sep 17 00:00:00 2001
+From: Thibault Charbonnier
+Date: Mon, 23 Mar 2020 19:40:47 -0700
+Subject: [PATCH] bugfix: prevented request smuggling in the
+ ngx.location.capture API.
+
+Signed-off-by: Yichun Zhang (agentzh)
+(tests)
+
+Index: nginx-lua/src/ngx_http_lua_subrequest.c
+===
+--- nginx-lua.orig/src/ngx_http_lua_subrequest.c
nginx-lua/src/ngx_http_lua_subrequest.c
+@@ -56,8 +56,6 @@ static ngx_str_t ngx_http_lua_content_l
+ ngx_string("Content-Length");
+
+
+-static ngx_int_t ngx_http_lua_set_content_length_header(ngx_http_request_t *r,
+-off_t len);
+ static ngx_int_t ngx_http_lua_adjust_subrequest(ngx_http_request_t *sr,
+ ngx_uint_t method, int forward_body,
+ ngx_http_request_body_t *body, unsigned vars_action,
+@@ -78,7 +76,7 @@ static void ngx_http_lua_cancel_subreq(n
+ static ngx_int_t ngx_http_post_request_to_head(ngx_http_request_t *r);
+ static ngx_int_t ngx_http_lua_copy_in_file_request_body(ngx_http_request_t
*r);
+ static ngx_int_t ngx_http_lua_copy_request_headers(ngx_http_request_t *sr,
+-ngx_http_request_t *r);
++ngx_http_request_t *pr, ngx_uint_t prcl);
+
+
+ /* ngx.location.capture is just a thin wrapper around
+@@ -622,8 +620,8 @@ ngx_http_lua_adjust_subrequest(ngx_http_
+ unsigned vars_action, ngx_array_t *extra_vars)
+ {
+ ngx_http_request_t *r;
+-ngx_int_trc;
+ ngx_http_core_main_conf_t *cmcf;
++ngx_uint_t prcl = 0;
+ size_t size;
+
+ r = sr->parent;
+@@ -633,46 +631,32 @@ ngx_http_lua_adjust_subrequest(ngx_http_
+ if (body) {
+ sr->request_body = body;
+
+-rc = ngx_http_lua_set_content_length_header(sr,
+-body->buf
+-? ngx_buf_size(body->buf)
+-: 0);
+-
+-if (rc != NGX_OK) {
+-return NGX_ERROR;
+-}
+-
+ } else if (!always_forward_body
+&& method != NGX_HTTP_PUT
+&& method != NGX_HTTP_POST
+&& r->headers_in.content_length_n > 0)
+ {
+-rc = ngx_http_lua_set_content_length_header(sr, 0);
+-if (rc != NGX_OK) {
+-return NGX_ERROR;
+-}
+-
+-#if 1
+ sr->request_body = NULL;
+-#endif
+
+ } else {
+-if (ngx_http_lua_copy_request_headers(sr, r) != NGX_OK) {
+-return NGX_ERROR;
++if (!r->headers_in.chunked) {
++prcl = 1;
+ }
+
+-if (sr->request_body) {
++if (sr->request_body && sr->request_body->temp_file) {
+
+ /* deep-copy the request body */
+
+-if (sr->request_body->temp_file) {
+-if (ngx_http_lua_copy_in_file_request_body(sr) != NGX_OK) {
+-return NGX_ERROR;
+-}
++if (ngx_http_lua_copy_in_file_request_body(sr) != NGX_OK) {
++return NGX_ERROR;
+ }
+ }
+ }
+
++if (ngx_http_lua_copy_request_headers(sr, r, prcl) != NGX_OK) {
Bug#964966: RFP: dont-track-me-google -- browser extension to prevent Google from making links ugly
Package: wnpp Severity: wishlist * Package name: dont-track-me-google Version : 4.22 Upstream Author : Rob Wu * URL : https://github.com/Rob--W/dont-track-me-google * License : Expat Programming Lang: JavaScript At the Google Search engine, search results are converted to an ugly link upon click. This link enables tracking for Google. For example, the search entry http://www.google.com/ (when searching for "Google") will be replaced with: https://encrypted.google.com/url?sa=t=j=Google=web=8=2=0CFgQFjAH=http%3A%2F%2Fwww.google.com%2F=Ej__TrCkJo2bOrSs2aIE=AFQjCNG5-9Jej-ukVeakTgwonqt2narbYg=f9f1dWcZoj6ZUC2Zxy9y2g This script removes Google's link-conversion/tracking feature. This speeds up loading search results and allows you to right-click or tap to copy the link URL. -- Jakub Wilk
Bug#964965: cron job should not call a potentially undefined shell function
Package: aide Version: 0.16.2-0.1~zg100+1 Severity: minor Hi, when the cron job fails early, we already have the trap handler established but onexit is not yet defined. This should be checked in the trap handler, so that we don't produce a double fault when an error happening (such as update-aide.conf failing) and calling the undefined function onexit in the handler. Greetings Marc -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.7-zgsrv20080 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) aide depends on no packages. Versions of packages aide recommends: ii aide-common 0.16.2-0.1~zg100+1 Versions of packages aide suggests: ii figlet 2.2.5-3 -- no debconf information
Bug#529962: mpack doesn't allow to specify a sender address
Package: mpack Version: 1.6-15 Followup-For: Bug #529962 Dear Maintainer, I believe that this bug (529962) is a duplicate of 211657 and should be merged into the latter. Thanks Sam -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mpack depends on: ii libc6 2.30-8 mpack recommends no packages. Versions of packages mpack suggests: pn inews ii postfix [mail-transport-agent] 3.5.4-1 -- no debconf information
Bug#964964: ruby-codemirror-rails: ftbfs with rails 6 in experimental and unmainatained.
Package: ruby-codemirror-rails Version: 5.16.0-1 Severity: important Control: forwarded -1 https://github.com/fixlr/codemirror-rails/issues/61 User: pkg-ruby-extras-maintain...@lists.alioth.debian.org Usertags: rails6-transition Hi, This package's autopkgtest failed with rails 6 currently in experimental. rails 6 will be uploaded to unstable in 2 weeks, so please make sure this package is ready for rails 6. The severity of this bug will be raised to serious after rails 6 is uploaded to unstable. Relevant error GEM_PATH= ruby2.7 -e gem\ \"codemirror-rails\" /usr/lib/ruby/2.7.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'railties' (< 6.0, >= 3.0) - did find: [railties-6.0.3.1] (Gem::MissingSpecVersionError) Checked in 'GEM_PATH=/home/debci/.gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0', execute `gem env` for more information from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1402:in `block in activate_dependencies' from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `each' from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1391:in `activate_dependencies' from /usr/lib/ruby/2.7.0/rubygems/specification.rb:1373:in `activate' from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:68:in `block in gem' from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:68:in `synchronize' from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:68:in `gem' from -e:1:in `' But it seems to be unmaintained upstream https://github.com/fixlr/codemirror-rails/issues/61 so it is better to remove this package and use libjs-codemirror directly. Another option may be rails-assets.org, but that service seems unmaintained as well. Full error log https://people.debian.org/~praveen/rails6-meta-build/autopkgtest/ruby-codemirror-rails.log
