Bug#969260: openfjx: FTBFS (gstreamer)
tony mancill: > Hi Chris! Hello again Tony :) > On Sat, Sep 05, 2020 at 05:43:17AM +, Chris Knadle wrote: >> Chris Knadle: >>> For what it's worth, I used a clean cowbuilder sid chroot that was fully >>> upgraded to build openjfx 11.0.7+0-4 and the package built fine. The build >>> log >>> is about 808kB -- I'll send it to the bug report if desired. Offhand I'm not >>> sure what's going on either. It's probably wishful thinking that the >>> cowbuilder >>> build log will be comparable to the buildd build logs, but I'll have a look. >> >> Okay, I've compared the cowbuilder logs and the buildd logs and there are a >> number of differences, and to me it looks like buildd might be using gcc-10 >> where my cowbuilder build may not be. The buildd logs show many warning/error >> lines of variables "first defined here" and that's indicative of a gcc-10 >> problem, along with many other errors and warnings that the cowbuilder build >> didn't show. >> >> I was given some hints about this in bug #957546: >> >>Common build failures are new warnings resulting in build failures with >>-Werror turned on, or new/dropped symbols in Debian symbols files. >>For other C/C++ related build failures see the porting guide at >>http://gcc.gnu.org/gcc-10/porting_to.html > > Thank you for taking a look at this. I suspect that you're on to > something with gcc-10, but if that's the case, I'm worried about my > entire build toolchain with respect to gcc-10 bugs. Just to be sure, I > created a fresh chroot with: > >sudo sbuild-createchroot sid /path/to/chroot > > And the package still builds correctly for me, and "gcc -v" in that > chroot shows gcc 10.2: > > $ schroot -c sid-amd64-sbuild -u root > (sid-amd64-sbuild)root@lark:~# gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper > OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa > OFFLOAD_TARGET_DEFAULT=1 > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.0-6' > --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs > --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr > --with-gcc-major-version-only --program-suffix=-10 > --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug > --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new > --enable-gnu-unique-object --disable-vtable-verify --enable-plugin > --enable-default-pie --with-system-zlib --enable-libphobos-checking=release > --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch > --disable-werror --with-arch-32=i686 --with-abi=m64 > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic > --enable-offload-targets=nvptx-none=/build/gcc-10-OZNiN5/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-OZNiN5/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa > --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > Supported LTO compression algorithms: zlib zstd > gcc version 10.2.0 (Debian 10.2.0-6) I got the *exact* same output from cowbuilder when checking 'gcc -v' -- I literally copied the above from your email, copied the output from 'gcc -v' in my cowbuilder chroot, ran 'diff -u' on the files, and came back identical. So ... yeah ... I also don't quite know what's going on either. I /suspect/ it's a GCC-10 issue because of the particular warning/error messages, so it seems to make _sense_ that it would be some GCC-10 issue, however both your and my local build chroots should be using GCC-10 and build fine. So ... ? > So I'm confused about what's different on the buildd system. I will > keep poking at it. Something to try if you've got time: Try doing a "colordiff -u" on the log output from your successful sbuild vs the failed sbuild output from the buildd's; that should give a colorized output of where there are differences in lines, and maybe there will be a hint as to something that's different on the buildd's, like different GCC options, and also where the build "starts to go wrong". Maybe you've done that already, but if not that might give us some hints. I'm building an sbuild chroot and will see if I can poke at this some also. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#970006: unused-override is reported with new tag name
Hi Jelmer, On Fri, Sep 11, 2020 at 5:08 AM Jelmer Vernooij wrote: > > For example, see iio-sensor-proxy. Its debian/source/lintian-overrides has: > > iio-sensor-proxy: binary-without-manpage usr/bin/monitor-sensor > iio-sensor-proxy: binary-without-manpage usr/sbin/iio-sensor-proxy > iio-sensor-proxy: systemd-service-file-missing-documentation-key > lib/systemd/system/iio-sensor-proxy.service That is not quite what I am seeing. I believe these overrides are incorrectly listed as source overrides in d/source/lintian-overrides. [1] The tags are for installation packages, so their overrides in the source package remain unused (one unrelated tag was removed): % bin/lintian /mirror/debian/pool/main/i/iio-sensor-proxy/iio-sensor-proxy_3.0-1.dsc I: iio-sensor-proxy source: unused-override no-manual-page usr/bin/monitor-sensor I: iio-sensor-proxy source: unused-override no-manual-page usr/sbin/iio-sensor-proxy I: iio-sensor-proxy source: unused-override systemd-service-file-missing-documentation-key lib/systemd/system/iio-sensor-proxy.service P: iio-sensor-proxy source: renamed-tag binary-without-manpage => no-manual-page in line 2 P: iio-sensor-proxy source: renamed-tag binary-without-manpage => no-manual-page in line 3 As a courtesy, Lintian also reminds the user that the tag was renamed. For the installation package, on the other hand, Lintian reports (some unrelated tags were removed): % bin/lintian /mirror/debian/pool/main/i/iio-sensor-proxy/iio-sensor-proxy_3.0-1_amd64.deb W: iio-sensor-proxy: no-manual-page usr/bin/monitor-sensor W: iio-sensor-proxy: no-manual-page usr/sbin/iio-sensor-proxy I: iio-sensor-proxy: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/iio-sensor-proxy.service I: iio-sensor-proxy: systemd-service-file-missing-documentation-key lib/systemd/system/iio-sensor-proxy.service I: iio-sensor-proxy: systemd-service-file-missing-install-key lib/systemd/system/iio-sensor-proxy.service As far as I can tell, Lintian reports what was intended. Can you please try moving the file in [1] to debian/iio-sensor-proxy.lintian-overrides? Kind regards Felix Lechner [1] https://sources.debian.org/src/iio-sensor-proxy/3.0-1/debian/source/lintian-overrides/
Bug#962573: Include SRBDS Support
Hi, On 9/11/20 9:59 PM, sylvestre...@ledru.info wrote: > Did you try to propose them upstream first? like written in my first message, this is already upstream. There is just no new upstream release, hence it would be nice if you (preferably) upload a snapshot of the git head, or, cherry-pick the mentioned commit. If you prefer the latter, I can prepare the patches to cherry-pick if you like me to. Regards, Daniel
Bug#963867: new upstream
Control: tag -1 patch I've gone ahead and taken a shot at the packaging [1]. I'm running it locally on several machines (the new FINGERPRINT option is great). If there's any more legwork to run on this, let me know. I'd love to help out. Antonio [1] https://salsa.debian.org/debian/dma/-/merge_requests/2
Bug#970126: ITP: r-cran-argparser -- Command-Line Argument Parser
Package: wnpp Severity: wishlist Subject: ITP: r-cran-argparser -- Command-Line Argument Parser Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-cran-argparser Version : 0.6 Upstream Author : David J. H. Shih * URL : https://cran.r-project.org/package=argparser * License : GPL-3+ Programming Lang: GNU R Description : Command-Line Argument Parser Cross-platform command-line argument parser written purely in R with no external dependencies. It is useful with the Rscript front-end and facilitates turning an R script into an executable script. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-argparser
Bug#968567: linux-image-4.19.0-10-amd64: kernel failure when writing on a GFS2 partition
Hi Salvatore, Thanks for chasing this up, I've just built the 4.19.144 vanilla kernel with the referenced commit applied and can confirm that this issue no longer occurs on writing to a mounted gfs2 filesystem. Cheers, Dan. From: Salvatore Bonaccorso on behalf of Salvatore Bonaccorso Sent: Friday, 11 September 2020 11:15 PM To: Craig, Daniel (CASS, Marsfield) ; 968...@bugs.debian.org <968...@bugs.debian.org> Cc: Nicolas Courtel Subject: Re: Bug#968567: linux-image-4.19.0-10-amd64: kernel failure when writing on a GFS2 partition Hi Daniel, hi Nicolas, On Thu, Sep 10, 2020 at 04:47:20AM +, Craig, Daniel (CASS, Marsfield) wrote: > Hi, > > I can confirm the existence of this CPU soft-lock bug with gfs2. > > I won't worry about reproducing the kernel bug message, but I have > done a bit of digging and if I revert the following commit, added in > the 4.19.130 release then this fixes issue for me. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y=c91cffd0fd010c06d67f3a9a528b858ce28c60fb > > Note that the problem is still present in the latest upstream > release in the 4.19 series (4.19.144) > > I've reported this bug in the kernel bugzilla, referenced here: > > https://bugzilla.kernel.org/show_bug.cgi?id=209217 Upstream did had a look at this see (you both were CC'ed on that thread though) the thread starting at https://lore.kernel.org/stable/20200910194319.GA131386@eldamar.local/ and suggested that upstream commit cbcc89b630447ec7836aa2b9242d9bb1725f5a61 is definitely needed. Would it be possible for you to test a build with that commit added on top? (Note the patch would need a slight refresh when applying on top of 4.19.144 for context changes). https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 explains how to test a single patch on top of the packaging, or you can try 4.19.144 with the cherry-picked commit. That would be much appreciated. Regards, Salvatore
Bug#970123: ITP: fenicsx-performance-tests -- solvers for testing the parallel performance of DOLFIN-X
Package: wnpp Severity: wishlist Owner: Drew Parsons X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org, lu...@debian.org * Package name: fenicsx-performance-tests Version : git20200719.42769f8 Upstream Author : Chris N. Richardson * URL : https://github.com/FEniCS/performance-test * License : MIT Programming Lang: C++ Description : solvers for testing the parallel performance of DOLFIN-X This package contains solvers for testing the parallel performance of DOLFIN-X and the underlying linear solvers. It tests elliptic equations - Poisson equation and elasticity - in three dimensions. DOLFINX-X is the next-generation solver for the FEniCS project. The intention of this package is help demonstrate and monitor the HPC performance of Debian's FEniCS/DOLFIN-X packages. HPC compute time has been graciously offered for HPC package testing by France's Grid5000 consortium, grid5000.fr. To be maintained alongside fenics/dolfinx under the Debian Science Team.
Bug#960132: mdadm: mdcheck_start.service trying to start unexisting file
On Sun, 10 May 2020 02:16:57 +0700 Павел Мотырев wrote: > There is a patch in attachment, that adds missed scripts into the > package during build process. syslog-events is already installed by a dh_installexamples call. Also, I'm not sure why this would need to install the mdcheck script into the udeb. So I end up with this (sorry for my mail client line wrapping the context lines): diff -Nru mdadm-4.1/debian/rules mdadm-4.1/debian/rules --- mdadm-4.1/debian/rules 2019-03-11 22:58:03.0 -0500 +++ mdadm-4.1/debian/rules 2020-09-11 17:08:40.0 -0500 @@ -63,6 +63,7 @@ install -Dm0755 debian/mkconf $(DESTDIR)/usr/share/mdadm/mkconf install -Dm0755 debian/checkarray $(DESTDIR)/usr/share/mdadm/checkarray + install -Dm0755 misc/mdcheck $(DESTDIR)/usr/share/mdadm/mdcheck install -Dm0755 debian/bugscript $(DESTDIR)/usr/share/bug/mdadm/script install -Dm0755 udeb/mdadm $(DESTDIR_UDEB)/sbin/mdadm install -Dm0755 udeb/mdmon $(DESTDIR_UDEB)/sbin/mdmon -- Richard signature.asc Description: OpenPGP digital signature
Bug#946979: lists.debian.org: Have a mailing list archive for the JavaScript team.
Hi Alexander, On Fri, Sep 11, 2020 at 1:26 AM Alexander Wirt wrote: > Please follow the instructions in > https://www.debian.org/MailingLists/HOWTO_start_list > and provide me with the needed information (Name, Rationale, > Descriptions and so on). If I'm understanding the guide correctly, from the "Moving existing mailing lists to lists.debian.org" section, I feel that I don't really need a name, rationale, and so on, right? Because we want to move away from the existing alioth-lists.d.net service to lists.d.o. The JavaScript team's current list is https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/ and we'd appreciate having lists.debian.org/debian-js instead. And it'd be great to have the existing archive to be imported as well! Please let me know if I'm not correctly parsing the mentioned guide. - u
Bug#970122: lexgrog: NAME section: does not recognize the \[...] form for a "dash"
Package: man-db Version: 2.9.3-2 Severity: normal Dear Maintainer, * What led up to the situation? Searching the database with "man -k web" * What was the outcome of this action? ... cweb (1) - (unknown subject) ... ## An example is in the manual "cweb.1" in the "texlive-binaries" Debian package. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.17-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages man-db depends on: ii bsdextrautils 2.36-3 ii bsdmainutils 12.1.7 ii debconf [debconf-2.0] 1.5.74 ii dpkg 1.20.5 ii groff-base 1.22.4-5 ii libc6 2.31-3 ii libgdbm6 1.18.1-5.1 ii libpipeline1 1.5.3-1 ii libseccomp22.4.3-1+b1 ii zlib1g 1:1.2.11.dfsg-2 man-db recommends no packages. Versions of packages man-db suggests: pn apparmor ii elinks [www-browser] 0.13.2-1 ii firefox-esr [www-browser] 78.2.0esr-1 ii groff 1.22.4-5 ii less 551-2 ii lynx [www-browser] 2.9.0dev.5-1 ii w3m [www-browser] 0.5.3-38+b1 -- Configuration Files: /etc/manpath.config changed [not included] -- debconf information excluded -- Bjarni I. Gislason
Bug#970113: Network scanning fails without proper permissions
Dear Maintainer, the issue reported in #950646 might be a similar or the same. Kind regards, Bernhard
Bug#921707: glowing bear blocked by libjs-pako
block 921707 by 877730 thanks Gave this another go today and to replace the 3rdparty bundled zlib.js/inflate.js file with pako from Debian, I need libjs-pako (#877730). I thought about bundling inflate.min.js as-is, but I haven't been able to reproduce it from the non-minimised source. It seems the tooling upstream zlib.js uses to minimize the file has changed since the file was bundled (ant -> grunt). -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#969663: Upstream version 4.5.0
Importing the new upstream version 4.5.0 will need the enclosed changes. Upstream commit dfee8d03468f25667a95902008933e3c4080d38d introduced an ABI change that might have to be dealt with: Unifying wolfSSL_sk_SSL_CIPHER_dup and wolfSSL_sk_X509_dup to wolfSSL_sk_dup. From: Bastian Germann Date: Fri, 11 Sep 2020 21:32:31 +0200 Subject: Disable upstream patches --- --- a/debian/patches/series +++ b/debian/patches/series @@ -1,8 +1,4 @@ utf8.patch -rename-hash-type.patch -rename-validate-date-function.patch -b07dfa425dc9416c4188830e79fd26.patch -c8b87eab5f2fe2ae2c3527bbfb33db6ed8b55999.patch reproducible-build.patch improve-clean-target.patch dfsg.patch From: Bastian Germann Date: Fri, 11 Sep 2020 22:17:59 +0200 Subject: Keep the same tls/ssl versions --- --- a/debian/rules +++ b/debian/rules @@ -20,7 +20,8 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all override_dh_auto_configure: dh_auto_configure -- \ --enable-distro \ - --enable-tls13 \ + --enable-sslv3 \ + --enable-tlsv10 \ --disable-examples \ --disable-silent-rules
Bug#970120: Updating the genshi Uploaders list
Source: genshi Version: 0.7.1-5 0.7.3-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the genshi package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970119: Updating the flufl.testing Uploaders list
Source: flufl.testing Version: 0.7-1 0.7-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the flufl.testing package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970116: Updating the enum34 Uploaders list
Source: enum34 Version: 1.1.6-2 1.1.6-4 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the enum34 package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970118: Updating the flufl.password Uploaders list
Source: flufl.password Version: 1.3-2 1.3-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the flufl.password package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970121: Updating the gtimelog Uploaders list
Source: gtimelog Version: 0.11.2-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the gtimelog package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970115: Updating the dirtbike Uploaders list
Source: dirtbike Version: 0.3-2.1 0.3-7 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the dirtbike package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970117: Updating the flufl.enum Uploaders list
Source: flufl.enum Version: 4.1.1-1 4.1.1-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the flufl.enum package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970114: Updating the cov-core Uploaders list
Source: cov-core Version: 1.15.0-2 1.15.0-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the cov-core package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#970113: Network scanning fails without proper permissions
Package: sane-backends
Version: 1.0.27-3.2
Since the upgrade to Buster, I've been unable to use the network
scanning function of SANE.
I can see the scanner fine on the host with the scanner attached:
user@scanhost: scanimage -L
device `avision:libusb:001:014' is a Hewlett-Packard ScanJet 8200
flatbed scanner
However, there is no "net" connection. "scanimage -L" from a remote
host with "/etc/sane.d/net.conf" set to point to the scanner host also
shows no scanner available.
If I create "/etc/udev/rules.d/60-scanner.rules" with:
SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="0b01",
OWNER="saned", GROUP="saned", MODE="0666"
and restart udev (service udev restart), then unplug and replug the
scanner in, I can now see the scanner over the network:
user@scanhost: scanimage -L
device `avision:libusb:001:014' is a Hewlett-Packard ScanJet 8200
flatbed scanner
device `net:192.168.74.12:avision:libusb:001:014' is a Hewlett-Packard
ScanJet 8200 flatbed scanner
device `net:localhost:avision:libusb:001:014' is a Hewlett-Packard
ScanJet 8200 flatbed scanner
device `net:127.0.0.1:avision:libusb:001:014' is a Hewlett-Packard
ScanJet 8200 flatbed scanner
and
user@remotehost: scanimage -L
device `net:192.168.74.12:avision:libusb:001:014' is a Hewlett-Packard
ScanJet 8200 flatbed scanner
James
Bug#962573: Include SRBDS Support
Hello, On 2020-09-11 20:48, Daniel Baumann wrote: Hi, thank you again for maintaining spectre-meltdown-checker in debian. I'm aware that there's no new upstream release since quite a while, yet it would be very handy to have the above mentioned commits merged in the debian package. Would you accept patches for it? Did you try to propose them upstream first? Thanks Sylvestre
Bug#936208: bist: diff for NMU version 0.5.2-1.2
Attached the patch for my NMU. Cheers, Moritz diff -Nru bist-0.5.2/debian/changelog bist-0.5.2/debian/changelog --- bist-0.5.2/debian/changelog 2016-01-26 12:47:31.0 +0100 +++ bist-0.5.2/debian/changelog 2020-09-11 20:36:59.0 +0200 @@ -1,3 +1,10 @@ +bist (0.5.2-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Drop unused python build dep (Closes: #936208) + + -- Moritz Muehlenhoff Fri, 11 Sep 2020 20:36:59 +0200 + bist (0.5.2-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru bist-0.5.2/debian/control bist-0.5.2/debian/control --- bist-0.5.2/debian/control 2016-01-26 12:47:18.0 +0100 +++ bist-0.5.2/debian/control 2020-09-11 20:36:39.0 +0200 @@ -10,7 +10,6 @@ , pkg-config , libcairo2-dev , libpango1.0-dev - , python , libncurses5-dev , libplot-dev , libexpat1-dev
Bug#937288: piggyphoto: Python2 removal in sid/bullseye
On Fri, Sep 11, 2020 at 09:51:24PM +0200, Aigars Mahinovs wrote: > Agreed. It was packaged as a reverse dependency for other software, > but other problems eventually prevented the packaging of that. Ack, I've just filed an RM bug. Cheers, Moritz
Bug#970112: RM: piggyphoto -- RoQA; Depends on Python 2, dead upstream, no reverse deps
Package: ftp.debian.org Severity: normal Please remove piggyphoto. It depends on Python 2, is dead upstream and there are no reverse deps. Acked by the maintainer in #937288. Cheers, Moritz
Bug#957156: Fix for compilation error under gcc 10
Hello, I'm not the original author but the maintainer of the unofficial https://github.com/speed47/dvdisaster version. I happen to already have fixed this compilation issue. The patch is trivial and attached to this message. Best Regards, Stéphane. diff --git a/dvdisaster.c b/dvdisaster.c index 6840fd5..da616b9 100644 --- a/dvdisaster.c +++ b/dvdisaster.c @@ -22,6 +22,11 @@ #include "dvdisaster.h" +struct _RawBuffer *rawbuffer_forward; +struct _DefectiveSectorHeader *dsh_forward; +struct _DeviceHandle *dh_forward; +struct _Image *dh_image; + /* * The all-famous main() loop */ diff --git a/dvdisaster.h b/dvdisaster.h index f536040..e729e96 100644 --- a/dvdisaster.h +++ b/dvdisaster.h @@ -438,10 +438,10 @@ typedef struct _CrcBlock *** forward declarations ***/ -struct _RawBuffer *rawbuffer_forward; -struct _DefectiveSectorHeader *dsh_forward; -struct _DeviceHandle *dh_forward; -struct _Image *dh_image; +extern struct _RawBuffer *rawbuffer_forward; +extern struct _DefectiveSectorHeader *dsh_forward; +extern struct _DeviceHandle *dh_forward; +extern struct _Image *dh_image; /*** *** bitmap.c
Bug#937288: piggyphoto: Python2 removal in sid/bullseye
Agreed. It was packaged as a reverse dependency for other software, but other problems eventually prevented the packaging of that. On Fri, 11 Sep 2020 at 21:42, Moritz Mühlenhoff wrote: > > On Fri, Aug 30, 2019 at 07:30:59AM +, Matthias Klose wrote: > > Package: src:piggyphoto > > Version: 0.1dev-git20141014 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Aigars, > piggyphoto is dead upstream, the last commit is from a decade ago > and there are no reverse deps, let's remove it from the archive? > > Cheers, > Moritz -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Bug#970110: RM: python-versuchung -- RoQA; unmaintained, RC-buggy, unused, no rev deps
Package: ftp.debian.org Severity: normal Please remove python-versuchung. It's unmaintained (last upload in 2014, no followup to Py2 RC bugs in a year) and there are no reverse deps. Cheers, Moritz
Bug#970111: enigmail: Upgrade to migration version 2.2.x for Thunderbird 78
Package: enigmail Version: 2:2.1.6+ds1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Please consider uploading the latest 2.2 version of Enigmail to support the ongoing Thunderbird upgrade to version 78. This version includes a migration wizard for existing Enigmail configurations, which will become obsolete due to the integration of PGP support in Thunderbird. Since the Thunderbird 78 package in Debian contains a Breaks: on Enigmail << 2.2, it will cause Enigmail to be removed when upgrading Thunderbird. This will lead to users missing out on the conversion wizard. d/watch refers to the project homepage and not the Gitlab page, so it currently doesn't detect these new versions. The code for Enigmail 2.2 can be found here: https://gitlab.com/enigmail/enigmail/-/tags It's possible that Enigmail 2.2 no longer contains functionality for Thunderbird << 78, so careful testing of the package is needed. Thunderbird 78 is currently only available in experimental, so an upload to experimental first would be a good idea. Thank you. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages enigmail depends on: ii gnupg2.2.20-1 ii gpg-agent [gnupg-agent] 2.2.20-1 ii thunderbird 1:68.12.0-1 Versions of packages enigmail recommends: ii pinentry-qt [pinentry-x11] 1.1.0-4 enigmail suggests no packages. -- no debconf information
Bug#970109: rust-derive-builder has unsatisfiable dependency on non-existent rust-compiletest-rs
Package: librust-derive-builder+compiletest-rs-dev Version: 0.9.0-2 Severity: grave User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu groovy The librust-derive-builder+compiletest-rs-dev package is uninstallable because it depends on librust-compiletest-rs-0.3+default-dev, which does not exist anywhere in Debian, including in the NEW queue. We should not have uninstallable packages in the archive. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#937288: piggyphoto: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:30:59AM +, Matthias Klose wrote: > Package: src:piggyphoto > Version: 0.1dev-git20141014 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html Aigars, piggyphoto is dead upstream, the last commit is from a decade ago and there are no reverse deps, let's remove it from the archive? Cheers, Moritz
Bug#970096: buster-pu: package libdbi-perl/1.642-1+deb10u1
Hi Xavier, On Fri, Sep 11, 2020 at 06:02:00PM +0200, Xavier Guimard wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: debian-p...@lists.debian.org > > [ Reason ] > libdbi-perl is vulnerable to (low) security bug (CVE-2020-14392) > > [ Impact ] > libdbi-perl may crash if an attacker can give a malformed login > > [ Tests ] > No new test, current passed > > [ Risks ] > This patch is very simple > > [ 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 ] > Returned values are more tested > diff --git a/debian/changelog b/debian/changelog > index d2e35cc..d0ad39a 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,10 @@ > +libdbi-perl (1.642-1+deb10u1) buster; urgency=medium > + > + * Fix memory corruption in XS functions when Perl stack is reallocated > +(Closes: CVE-2020-14392) Note that there is as well CVE-2020-14393, could you add the fix for this one as well? Regards, Salvatore
Bug#968707: thunderbird: Please allow Enigmail 2.2.x with Thunderbird 78
> any idea when Enigmail 2.2.x will finds it's way into unstable? Ubuntu > already is using this version in Groovy Gorilla. Note that the 2.2 addon is not mentioned anywhere on the Enigmail homepage and the Debian watch doesn't detect it either, because it points to the homepage and not the project's Gitlab page. You can find it on https://gitlab.com/enigmail/enigmail/-/tags though.
Bug#970108: RM: mandrill -- RoQA; unmaintained, RC-buggy, no rdeps, unused
Package: ftp.debian.org Severity: normal Please remove mandrill. It's RC-buggy, the last upload was in 2016, there are no reverse deps and popcon is practically non-existent. Cheers, Moritz
Bug#969609: [Pkg-rust-maintainers] Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
Ximin, On Tue, Sep 08, 2020 at 09:23:49PM +0100, Ximin Luo wrote: > You keep filing these same bugs. I have told you this many times before > already: this is just how rust packaging works, Britney's migration policy > already prevents these packages from reaching Debian Testing, so there is > no problem, no users are affected. > You filing these bug reports accomplishes nothing, except delay & annoy > other Rust packagers who forget to close these pointless bugs, thereby > unnecessarily blocking any fixed packages from actually reaching Debian > Testing. Oftentimes the fix is also not to update the package itself, but > to upload another package. Due to the idiosyncracies of the BTS, not > everyone knows how to close these bugs correctly (notfound -1 $version) > and it will result in further delays. > Please stop filing these bug reports, they only create extra unnecessary > work for other people, and make Debian worse for users, by slowing down > the stream of fixes. Britney already prevents Testing migration. It is not credible to me that this is "just how rust packaging works". The bugs I am filing are against packages that have been uninstallable in unstable for more than 4 months. The missing dependencies are not in the NEW queue, and there are no ITP bugs filed for them. There is no reason to believe, without filing these bugs, that anyone on the rust packaging team is doing anything about these missing dependencies. And filing bug reports in the Debian BTS is the standard way in Debian to document bugs in packages. And it is unacceptable that Debian maintainers don't know how to operate the Debian BTS. So no, I will not stop filing bugs against RC-buggy packages that the Rust maintainers are clearly not taking care of. If you don't want bug reports, you have the option to stop uploading packages that are RC buggy from the moment they're accepted into the archive. > Steve Langasek: > > Source: rust-zstd > > Version: 0.5.1-1 > > Severity: grave > > > > The rust-zstd package has both a dependency and a build-dependency on > > librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in > > Debian. Presumably it would be built by a rust-zstd-safe package, but no > > such package exists, including in the Debian NEW queue. > > > > The binaries of rust-zstd that are in Debian were clearly not built on the > > autobuilders, and all other architectures besides amd64 are unable to build > > this package. > > > > > > ___ > > Pkg-rust-maintainers mailing list > > pkg-rust-maintain...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers > > > > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#970107: RM: servefile -- RoQA; unmaintained, RC-buggy
Package: ftp.debian.org Severity: normal Please remove servefile. It's RC-buggy (Py2), hasn't seen an upload since 2015 and no followup to any of the open bugs. Cheers, Moritz
Bug#970106: lintian-info.1.gz is a dangling symlink
Package: lintian Version: 2.94.0 Severity: normal Hello, $ man lintian-info man: warning: /usr/share/man/man1/lintian-info.1.gz is a dangling symlink No manual entry for lintian-info See 'man 7 undocumented' for help when manual pages are not available. I see this is already fixed in git[1], so just report this bug for others who hit this problem to locate it quicker. Best regards Uwe [1] https://salsa.debian.org/lintian/lintian/-/commit/0cb2170036d65a28afd669ea894b319709a12e6f -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35-2 ii bzip2 1.0.6-9.2~deb10u1 ii diffstat1.62-1 ii dpkg1.19.7 ii dpkg-dev1.19.7 ii file1:5.35-4+deb10u1 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.64-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.23-1 ii libcpanel-json-xs-perl 4.19-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1 ii libdevel-size-perl 0.83-1+b1 ii libdpkg-perl1.19.7 ii libemail-address-xs-perl1.04-1+b2 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004000-1 ii liblist-compare-perl0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.003004-2 ii libmoox-aliases-perl0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.108-1 ii libperlio-gzip-perl 0.19-1+b6 ii libproc-processtable-perl 0.59-2 ii libsereal-decoder-perl 4.017+ds-1 ii libsereal-encoder-perl 4.017+ds-1 ii libtext-glob-perl 0.10-1 ii libtext-levenshteinxs-perl 0.03-4+b7 ii libtext-markdown-discount-perl 0.12-1 ii libtext-xslate-perl 3.5.8-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b2 ii libtimedate-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.004004-1 ii libunicode-utf8-perl0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libyaml-libyaml-perl0.82+repack-1 ii lzip1.21-8 ii lzop1.03-4+b1 ii man-db 2.8.5-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-3 ii unzip 6.0-23+deb10u1 ii xz-utils5.2.4-1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35-2 ii libtext-template-perl 1.55-1 -- no debconf information
Bug#937102: mysql-workbench: Python2 removal in sid/bullseye
On Tue, Sep 01, 2020 at 07:11:46PM +1000, Dmitry Smirnov wrote: > On Tuesday, 1 September 2020 4:57:56 AM AEST Moritz Mühlenhoff wrote: > > There's radio silence on https://bugs.mysql.com/bug.php?id=98839, > > They are not very transparent and their public bug tracker is somewhat > redundant, I think... They are also slow to make transitional changes... > > > > let's remove? > > I'd like to keep it for as long as possible please, unless you insist. > > MySQL-Workbench will be very difficult to re-introduce due to slow ftp- > masters processing time for a package with that size and complexity. > It was very difficult to introduce for a first time as it required a > long and tedious review. > I'm not looking forward to go through the process again... Fair enough, let's give upstream some more time, then. Cheers, Moritz
Bug#964399: Should ganglia be removed?
On Sun, Jul 26, 2020 at 01:31:08PM +0200, Moritz Mühlenhoff wrote: > Hi Marcos, > > I overlooked this in my inbox.. > > On Tue, Jul 07, 2020 at 11:15:58PM +0200, Marcos Fouces wrote: > > Hello Moritz > > > > I did some work time ago on ganglia [1] but i never get this work > > published due to unactive/unresponsive uploaders. > > > > I also done some work on ganglia-web and ganglia-linux-modules packages > > (also unpublished). > > > > I believe that it is still a good piece of software that deserve its > > place on Debian so i would like to step up as uploader (co-uploaders > > welcome!) if needed. > > > > I also would like to maintain it under pkg-security team umbrella. > > > > Please, let me know your thoughs. > > Do you have a plan how to deal with the plugins in Python 2? Will > you port them yourself or rather drop them? > > Packaging it under the pkg-security umbrella feels a little off/odd, > but if you think Ganglia is still useful in 2020 and want to adopt > it and fix the bugs, sure please go ahead :-) Are you still interested in adopting ganglia? Otherwise I'll file an RM bug soon. Cheers, Moritz
Bug#970105: lintian-info -t stopped working
Package: lintian Version: 2.93.0 Severity: normal Hello, I just updated to lintian 2.93.0 (from 2.82.0) and found that lintian-info isn't working any more as before: $ lintian-info -t systemd-service-file-missing-install-key Unknown option: t error parsing options The changelog for 2.92.0 has: * Split bin/lintian-info into separate annotate-lintian-hints and explain-lintian-tags. Obviously this was an API-changer. :-\ Maybe lintian-info can be made a wrapper around the two new commands with a compatible API or if this isn't considered sensible it can better be removed. Best regards Uwe -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (800, 'stable-updates'), (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable'), (499, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35-2 ii bzip2 1.0.6-9.2~deb10u1 ii diffstat1.62-1 ii dpkg1.19.7 ii dpkg-dev1.19.7 ii file1:5.35-4+deb10u1 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.64-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.23-1 ii libcpanel-json-xs-perl 4.19-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1 ii libdevel-size-perl 0.83-1+b1 ii libdpkg-perl1.19.7 ii libemail-address-xs-perl1.04-1+b2 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004000-1 ii liblist-compare-perl0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.003004-2 ii libmoox-aliases-perl0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.108-1 ii libperlio-gzip-perl 0.19-1+b6 ii libproc-processtable-perl 0.59-2 ii libsereal-decoder-perl 4.017+ds-1 ii libsereal-encoder-perl 4.017+ds-1 ii libtext-glob-perl 0.10-1 ii libtext-levenshteinxs-perl 0.03-4+b7 ii libtext-markdown-discount-perl 0.12-1 ii libtext-xslate-perl 3.5.8-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b2 ii libtimedate-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.004004-1 ii libunicode-utf8-perl0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libyaml-libyaml-perl0.82+repack-1 ii lzip1.21-8 ii lzop1.03-4+b1 ii man-db 2.8.5-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-3 ii unzip 6.0-23+deb10u1 ii xz-utils5.2.4-1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35-2 ii libtext-template-perl 1.55-1 -- no debconf information
Bug#937269: peframe: Python2 removal in sid/bullseye
On Thu, Dec 26, 2019 at 03:57:53PM +0100, Sascha Steinbiss wrote: > Just an update: Python 3 compatibility is indeed introduced in the latest > upstream version, however, that version also adds some new dependencies that > would need to be packaged and pass NEW. For example, python-virustotal-api, > which has been in NEW for quite some time. I have also looked at adding > python-oletools, but that will also need new dependencies of its own. > I’ll try work on this eventually, unless someone else is interested and has > some spare time. Are you still actively working on this one or should we rather remove peframe for now? Cheers, Moritz
Bug#970104: rust-gstreamer has unsatisfiable dependency on non-existent rust-futures-core-preview
Source: rust-gstreamer Version: 0.14.5-2 Severity: grave User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu groovy The librust-gstreamer+futures-dev package is uninstallable because it depends on librust-futures-core-preview-0.3+default-dev, which does not exist anywhere in Debian, including in the NEW queue. We should not have uninstallable packages in the archive. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#970103: xe FTCBFS: does not pass cross tools to make
Source: xe Version: 0.11-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs xe fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - makes xe cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru xe-0.11/debian/changelog xe-0.11/debian/changelog --- xe-0.11/debian/changelog2020-02-15 20:40:02.0 +0100 +++ xe-0.11/debian/changelog2020-09-11 20:59:00.0 +0200 @@ -1,3 +1,10 @@ +xe (0.11-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Fri, 11 Sep 2020 20:59:00 +0200 + xe (0.11-4) unstable; urgency=medium * Update authorship information diff --minimal -Nru xe-0.11/debian/rules xe-0.11/debian/rules --- xe-0.11/debian/rules2020-02-15 20:40:02.0 +0100 +++ xe-0.11/debian/rules2020-09-11 20:58:56.0 +0200 @@ -6,7 +6,7 @@ dh $@ override_dh_auto_build: - $(MAKE) $(shell dpkg-buildflags --export=configure) + dh_auto_build -- $(shell dpkg-buildflags --export=configure) override_dh_auto_install: dh_auto_install -- PREFIX=/usr
Bug#937187: olefile: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:29:10AM +, Matthias Klose wrote: > Package: src:olefile > Version: 0.46-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. Matthias, can you please drop the Py2 package at this point? The only reverse dep is python-pil with never entered testing intentionally anyway. Cheers, Moritz
Bug#937184: offlineimap: Python2 removal in sid/bullseye
On Sun, Aug 02, 2020 at 06:24:44PM +0300, Ilias Tsitsimpis wrote: > Control: severity -1 serious > > On Sun, Jul 26, 2020 at 01:21PM, Moritz Mühlenhoff wrote: > > Nine months later there's no progress, let's remove? > > Agreed. > > Raising the severity to serious to remove from testing, and then I will > request for removal. offlineimap has been dropped from testing since ~ three weeks, let's proceed with removal from unstable, then? Cheers, Moritz
Bug#962573: Include SRBDS Support
Hi, thank you again for maintaining spectre-meltdown-checker in debian. I'm aware that there's no new upstream release since quite a while, yet it would be very handy to have the above mentioned commits merged in the debian package. Would you accept patches for it? Regards, Daniel
Bug#970102: src:barman: fails to migrate to testing for too long: maintainer built arch:all binaries
Source: barman Version: 2.10-2 Severity: serious Control: close -1 2.11-1 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:barman 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=barman signature.asc Description: OpenPGP digital signature
Bug#970101: src:libhinawa: fails to migrate to testing for too long: reverse-dependency not ready yet
Source: libhinawa Version: 1.4.5-1 Severity: serious Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 968026 Control: affects -1 src:hinawa-utils 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:libhinawa 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 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=libhinawa signature.asc Description: OpenPGP digital signature
Bug#970100: src:angelscript: fails to migrate to testing for too long: FTBFS on mips64el
Source: angelscript Version: 2.34.0+ds-1.1 Severity: serious Control: close -1 2.34.0+ds-3.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:angelscript 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=angelscript signature.asc Description: OpenPGP digital signature
Bug#970099: CVE-2019-20907 CVE-2020-8492
Package: python2.7
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team
Two security issues from past the 2.7.18 release. Backports
from 3.x are attached (I'm planning to submit these for 10.6).
Cheers,
Moritz
>From 47a2955589bdb1a114d271496ff803ad73f954b8 Mon Sep 17 00:00:00 2001
From: "Miss Islington (bot)"
<31488909+miss-isling...@users.noreply.github.com>
Date: Wed, 15 Jul 2020 05:36:36 -0700
Subject: [PATCH] bpo-39017: Avoid infinite loop in the tarfile module
(GH-21454) (#21485)
Avoid infinite loop when reading specially crafted TAR files using the tarfile
module
(CVE-2019-20907).
(cherry picked from commit 5a8d121a1f3ef5ad7c105ee378cc79a3eac0c7d4)
Co-authored-by: Rishi
diff --git a/Lib/tarfile.py b/Lib/tarfile.py
index adf91d5..574a6bb 100644
--- a/Lib/tarfile.py
+++ b/Lib/tarfile.py
@@ -1400,6 +1400,8 @@ class TarInfo(object):
length, keyword = match.groups()
length = int(length)
+if length == 0:
+raise InvalidHeaderError("invalid header")
value = buf[match.end(2) + 1:match.start(1) + length - 1]
keyword = keyword.decode("utf8")
Backport of 0b297d4ff1c0e4480ad33acae793fbaf4bf015b4, trimmed down to the
fix for CVE-2020-8492
Co-Authored-By: Serhiy Storchaka
diff --git a/Lib/urllib2.py b/Lib/urllib2.py
index 8b634ad..11a62a4 100644
--- a/Lib/urllib2.py
+++ b/Lib/urllib2.py
@@ -856,8 +856,15 @@ class AbstractBasicAuthHandler:
# allow for double- and single-quoted realm values
# (single quotes are a violation of the RFC, but appear in the wild)
-rx = re.compile('(?:.*,)*[ \t]*([^ \t]+)[ \t]+'
-'realm=(["\']?)([^"\']*)\\2', re.I)
+rx = re.compile('(?:^|,)' # start of the string or ','
+'[ \t]*'# optional whitespaces
+'([^ \t]+)' # scheme like "Basic"
+'[ \t]+'# mandatory whitespaces
+# realm=xxx
+# realm='xxx'
+# realm="xxx"
+'realm=(["\']?)([^"\']*)\\2',
+re.I)
# XXX could pre-emptively send auth info already accepted (RFC 2617,
# end of section 2, and section 1.2 immediately after "credentials"
Bug#970065: [pkg-go] Bug#970065: golang-pault-go-archive: bullseye: /updates -> -security
forwarded 970065 https://github.com/paultag/go-archive/pull/8 thanks ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#967894: pan: Build-Depends on libgtkspell-dev, probably unnecessarily
On vendredi 11 septembre 2020 18:47:33 CEST Simon McVittie wrote: > From a brief look at configure.ac, it seems that might be just so it has > the necessary GTK 2 macros to run autoreconf successfully? You're right. I've forwarded your suggestion upstream: https://gitlab.gnome.org/GNOME/pan/-/issues/116 Unfortunately, I've already uploaded pan to fix the gtkspell dependency so this patch will be part of next release (ETA unknown) All the best Dod
Bug#943552: update
Control: tags -1 help -- All the dependencies are now packaged and I can now build tracecompass. But when I try to use the launcher to launch the built application I get errors. I have attached the error log. Will appreciate any help or pointers to fix the problem. -- Regards Sudip config.ini org.eclipse.equinox.simpleconfigurator Install location: file:/home/sudip/trace-compass/ Configuration file: file:/home/sudip/trace-compass/configuration/config.ini loaded Configuration location: file:/home/sudip/trace-compass/configuration/ Framework located: file:/home/sudip/trace-compass/plugins/eclipse-osgi-3.15.300.jar Loading extension: reference:file:eclipse-osgi-compatibility-state-1.1.800.jar eclipse.properties not found Framework classpath: file:/home/sudip/trace-compass/plugins/eclipse-osgi-3.15.300.jar file:/home/sudip/trace-compass/plugins/ file:/home/sudip/trace-compass/plugins/eclipse-osgi-compatibility-state-1.1.800.jar Debug options: file:/home/sudip/.options not found Time to load bundles: 37 Starting application: 1590 !SESSION 2020-09-07 20:36:38.848 --- eclipse.buildId=unknown java.version=11.0.8 java.vendor=Debian BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_GB Command-line arguments: -consolelog -clean -debug -data @noDefault !ENTRY org.eclipse.e4.ui.workbench 4 0 2020-09-07 20:36:41.208 !MESSAGE Unable to create class 'org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon' from bundle '43' !STACK 0 org.eclipse.e4.core.di.InjectionException: Unable to process "CommandProcessingAddon.broker": no actual value was found for the argument "IEventBroker". at org.eclipse.e4.core.internal.di.InjectorImpl.reportUnresolvedArgument(InjectorImpl.java:482) at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:473) at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:129) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:405) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:346) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:227) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:94) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:60) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:37) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:289) at org.eclipse.ui.internal.Workbench.lambda$createAndRunWorkbench$1(Workbench.java:579) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:557) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:154) at org.eclipse.tracecompass.internal.tracing.rcp.ui.Application.start(Application.java:95) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594) at org.eclipse.equinox.launcher.Main.run(Main.java:1447) at org.eclipse.equinox.launcher.Main.main(Main.java:1420) !ENTRY org.eclipse.e4.ui.workbench 4 0 2020-09-07 20:36:41.211 !MESSAGE Unable to create class 'org.eclipse.e4.ui.internal.workbench.addons.ContextProcessingAddon' from bundle '43' !STACK 0 org.eclipse.e4.core.di.InjectionException: Unable to process "ContextProcessingAddon.broker": no actual value was found for the argument "IEventBroker". at org.eclipse.e4.core.internal.di.InjectorImpl.reportUnresolvedArgument(InjectorImpl.java:482) at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:473) at org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:129) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:405) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:346) at
Bug#967894: pan: Build-Depends on libgtkspell-dev, probably unnecessarily
On Fri, 11 Sep 2020 at 17:47:58 +0200, Dominique Dumont wrote: > However pan still depends on libgtk2.0-dev even though Debian's build is done > with Gtk3. >From a brief look at configure.ac, it seems that might be just so it has the necessary GTK 2 macros to run autoreconf successfully? If that's the case, you could replace AM_PATH_GTK_2_0($GTK_REQUIRED,,exit 1,gthread) with PKG_CHECK_MODULES([GTK], [gtk+-2.0 >= $GTK_REQUIRED, gthread-2.0]) which is basically equivalent and should be upstreamable. (AM_PATH_GTK_2_0 also does a test-build of some C code against GTK, but that's basically unnecessary this decade, because pkg-config is well-understood by now.) smcv
Bug#969493: closed by Debian FTP Masters (reply to Craig Small ) (Bug#969493: fixed in net-snmp 5.9+dfsg-2)
Hi Craig, On 11-09-2020 12:03, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:nanook package: > > #969493: src:nanook: fails to migrate to testing for too long: maintainer > built arch:all binaries > > It has been closed by Debian FTP Masters > (reply to Craig Small ). I'm pretty sure you closed the wrong bug with your net-snmp upload. You may want to close the right bug manually (no need to open this one, it's rightfully closed). Paul signature.asc Description: OpenPGP digital signature
Bug#970098: buster-pu: package orocos-kdl/1.4.0-7+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
orocos-kdl ships KDLConfig.cmake providing a cmake variable with the
location of the header files. For Debian this is /usr/include, but it's
written as ${CMAKE_CURRENT_LIST_DIR}/../../../include. This breaks with
gcc > 5 and cmake < 3.16 if the path is added as -isystem to the
compiler.
This is the case for the ROS packages using orocos-kdl, as discussed in
https://github.com/ros/rosdistro/issues/26526.
[ Impact ]
If this is not approve the downstream users would need to add a
workaround to make use of the development package.
[ Tests ]
There is an autopkgtest in place, making sure that the headers are still
found. Also this was tested manually.
[ Risks ]
I think the change is trivial and I don't see a risk.
[ 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 ]
As /usr/include is a default include path, the patch simply removes the
extra path.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 9dc72bf..91e8724 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+orocos-kdl (1.4.0-7+deb10u2) buster; urgency=medium
+
+ * Add patch for include path
+KDLConfig.cmake exports ${CMAKE_CURRENT_LIST_DIR}/../../../include as an
+include path, which resolves to /usr/include. This breaks with gcc > 5 and
+cmake < 3.16 as discussed in
+https://github.com/ros/rosdistro/issues/26526.
+As /usr/include is a default include path, the patch simply removes the
+extra path.
+
+ -- Jochen Sprickerhof Fri, 11 Sep 2020 18:15:58 +0200
+
orocos-kdl (1.4.0-7+deb10u1) buster; urgency=medium
* Add patch for python3 std string conversion (Closes: #956254)
diff --git a/debian/patches/0007-Don-t-export-usr-include-as-include-path.patch
b/debian/patches/0007-Don-t-export-usr-include-as-include-path.patch
new file mode 100644
index 000..017e061
--- /dev/null
+++ b/debian/patches/0007-Don-t-export-usr-include-as-include-path.patch
@@ -0,0 +1,24 @@
+From: Jochen Sprickerhof
+Date: Fri, 11 Sep 2020 09:06:41 +0200
+Subject: Don't export /usr/include as include path
+
+It's not needed and breaks cmake < 3.16.
+
+cf. https://github.com/ros/rosdistro/issues/26526
+---
+ orocos_kdl/KDLConfig.cmake.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/orocos_kdl/KDLConfig.cmake.in b/orocos_kdl/KDLConfig.cmake.in
+index a099c19..3a9b738 100644
+--- a/orocos_kdl/KDLConfig.cmake.in
b/orocos_kdl/KDLConfig.cmake.in
+@@ -5,7 +5,7 @@
+ # orocos_kdl_PKGCONFIG_DIR - directory containing the .pc pkgconfig files
+
+ # Compute paths
+-set(orocos_kdl_INCLUDE_DIRS
"${CMAKE_CURRENT_LIST_DIR}/../../../include;@Boost_INCLUDE_DIRS@;@Eigen_INCLUDE_DIR@")
++set(orocos_kdl_INCLUDE_DIRS "@Boost_INCLUDE_DIRS@;@Eigen_INCLUDE_DIR@")
+
+ set(orocos_kdl_LIBRARIES orocos-kdl)
+
diff --git a/debian/patches/series b/debian/patches/series
index da119f6..2c9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
0002-Support-in-tree-compilation.patch
0003-Don-t-install-OrocosKDLTargets.patch
0005-Fixed-python3-std-string-conversion-issue.patch
+0007-Don-t-export-usr-include-as-include-path.patch
Bug#970087: ITP: mrc -- resource compiler to store data in ELF object files
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: mrc Version : 1.2.2 Upstream Author : Maarten L. Hekkelman * URL : http://github.com/mhekkel/mrc * License : BSD-2-Clause-FreeBSD Programming Lang: C++ Description : resource compiler to store data in ELF object files Many applications come with supplementary data. This data is usually stored on disk as regular files. The disadvantage of this procedure is that an application cannot simply be copied to another location or computer and expected to function properly. Resources are a way to overcome this problem by including all data inside the executable file. The mrc resource compiler can create object files containing both the data and an index. This data can then be accessed from within an application using C++ classes. A header file to include in your C++ application is provided. As a resource in mrc of course. I'm the author of libzeep, a C++ based web application framework and in combination with mrc I can create web based application with a C++ backend, all combined in a single executable that's easily distributable. Libzeep is already sponsored by the Med team.
Bug#969559: curl segmentation fauls on any https URL
Dear Maintainer, hello Bruce Momjian, with the last informations the issue is perfectly reproducible. It looks like a use after free caused by statically stored function pointers in libengine-pkcs11-openssl / libp11. That led to following upstream bug: https://github.com/OpenSC/libp11/issues/328 This got fixed in this commit: https://github.com/OpenSC/libp11/commit/e64496a198d4d2eb0310a22dc21be8b81367d319 This commit is not yet included in an upstream release tag. Therefore this error is also visible in current testing. I hope it is ok to reassign to libengine-pkcs11-openssl. Kind regards, Bernhard
Bug#970097: ITP: r-bioc-dupradar -- Assessment of duplication rates in RNA-Seq datasets
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-dupradar -- Assessment of duplication rates in RNA-Seq datasets Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-bioc-dupradar Version : 1.18.0 Upstream Author : Sergi Sayols * URL : https://bioconductor.org/packages/dupRadar/ * License : GPL-3 Programming Lang: GNU R Description : Assessment of duplication rates in RNA-Seq datasets Duplication rate quality control for RNA-Seq datasets. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-dupradar
Bug#955488: nat-rtsp-dkms: Does not build with kernel >= 5.3
Source: nat-rtsp Version: 0.7+4.18-0.1 Followup-For: Bug #955488 I've been hit by this bug (trying to use it with the kernel 5.7.0-0.bpo.2-amd64). My workaround has been to manually apply the patch from https://github.com/openwrt/packages/pull/11468 Regards, Vincent -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel, mipsel Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#878332: linux > 4.11: Raspberry pi 2 hangs at boot with lpae kernel
On 10.09.20 at 18:34, Gunnar Wolf wrote: > At the time of my bug report, I had not tested it yet. I checked right > now, downloading an image from raspi.debian.net, and installing the > -lpae kernel, I can confirm it boots correctly all the way to: > > root@rpi2-20200910:~# uname -a > Linux rpi2-20200910 4.19.0-10-armmp-lpae #1 SMP Debian 4.19.132-1 > (2020-07-24) armv7l GNU/Linux Thanks again for testing :-) signature.asc Description: OpenPGP digital signature
Bug#970096: buster-pu: package libdbi-perl/1.642-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-p...@lists.debian.org
[ Reason ]
libdbi-perl is vulnerable to (low) security bug (CVE-2020-14392)
[ Impact ]
libdbi-perl may crash if an attacker can give a malformed login
[ Tests ]
No new test, current passed
[ Risks ]
This patch is very simple
[ 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 ]
Returned values are more tested
diff --git a/debian/changelog b/debian/changelog
index d2e35cc..d0ad39a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libdbi-perl (1.642-1+deb10u1) buster; urgency=medium
+
+ * Fix memory corruption in XS functions when Perl stack is reallocated
+(Closes: CVE-2020-14392)
+
+ -- Xavier Guimard Thu, 10 Sep 2020 10:04:13 +0200
+
libdbi-perl (1.642-1) unstable; urgency=medium
[ Xavier Guimard ]
diff --git a/debian/patches/CVE-2020-14392.patch
b/debian/patches/CVE-2020-14392.patch
new file mode 100644
index 000..99c7a3e
--- /dev/null
+++ b/debian/patches/CVE-2020-14392.patch
@@ -0,0 +1,318 @@
+Description: Fix memory corruption in XS functions when Perl stack is
reallocated
+ Macro ST(*) returns pointer to Perl stack. Other Perl functions which use
+ Perl stack (e.g. eval) may reallocate Perl stack and therefore pointer
+ returned by ST(*) macro is invalid.
+ .
+ Construction like this:
+ .
+ ST(0) = dbd_db_login6_sv(dbh, imp_dbh, dbname, username, password, attribs) ?
_sv_yes : _sv_no;
+ .
+ where dbd_db_login6_sv() driver function calls eval may lead to
+ reallocating Perl stack and therefore invalidating ST(0) pointer.
+ So that construction would cause memory corruption as left part of
+ assignment is resolved prior executing dbd_db_login6_sv() function.
+ .
+ Correct way how to handle this problem: First call dbd_db_login6_sv()
+ function and then call ST(0) to retrieve stack pointer.
+ .
+ In this patch are fixes all occurrences of such constructions.
+ .
+ When running perl under valgrind I got memory corruption in DBD::ODBC
+ driver in that dbd_db_login6_sv() function due to above problem.
+Author: Pali
+Origin: upstream, https://github.com/perl5-dbi/dbi/commit/ea99b6aa
+Bug: https://security-tracker.debian.org/tracker/CVE-2020-14392
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard
+Last-Update: 2020-09-10
+
+--- a/DBI.xs
b/DBI.xs
+@@ -5252,9 +5252,12 @@
+ SV *col
+ SV *ref
+ SV *attribs
++PREINIT:
++SV *ret;
+ CODE:
+ DBD_ATTRIBS_CHECK("bind_col", sth, attribs);
+-ST(0) = boolSV(dbih_sth_bind_col(sth, col, ref, attribs));
++ret = boolSV(dbih_sth_bind_col(sth, col, ref, attribs));
++ST(0) = ret;
+ (void)cv;
+
+
+@@ -5492,21 +5495,27 @@
+ FETCH(h, keysv)
+ SV *h
+ SV *keysv
++PREINIT:
++SV *ret;
+ CODE:
+-ST(0) = dbih_get_attr_k(h, keysv, 0);
++ret = dbih_get_attr_k(h, keysv, 0);
++ST(0) = ret;
+ (void)cv;
+
+ void
+ DELETE(h, keysv)
+ SV *h
+ SV *keysv
++PREINIT:
++SV *ret;
+ CODE:
+ /* only private_* keys can be deleted, for others DELETE acts like FETCH
*/
+ /* because the DBI internals rely on certain handle attributes existing
*/
+ if (strnEQ(SvPV_nolen(keysv),"private_",8))
+-ST(0) = hv_delete_ent((HV*)SvRV(h), keysv, 0, 0);
++ret = hv_delete_ent((HV*)SvRV(h), keysv, 0, 0);
+ else
+-ST(0) = dbih_get_attr_k(h, keysv, 0);
++ret = dbih_get_attr_k(h, keysv, 0);
++ST(0) = ret;
+ (void)cv;
+
+
+--- a/Driver.xst
b/Driver.xst
+@@ -60,7 +60,7 @@
+ #ifdef dbd_discon_all
+
+ # disconnect_all renamed and ALIAS'd to avoid length clash on VMS :-(
+-void
++bool
+ discon_all_(drh)
+ SV *drh
+ ALIAS:
+@@ -68,7 +68,9 @@
+ CODE:
+ D_imp_drh(drh);
+ PERL_UNUSED_VAR(ix);
+-ST(0) = dbd_discon_all(drh, imp_drh) ? _sv_yes : _sv_no;
++RETVAL = dbd_discon_all(drh, imp_drh);
++OUTPUT:
++RETVAL
+
+ #endif /* dbd_discon_all */
+
+@@ -102,7 +104,7 @@
+ MODULE = DBD::~DRIVER~PACKAGE = DBD::~DRIVER~::db
+
+
+-void
++bool
+ _login(dbh, dbname, username, password, attribs=Nullsv)
+ SV *dbh
+ SV *dbname
+@@ -118,14 +120,16 @@
+ char *p = (SvOK(password)) ? SvPV(password,lna) : (char*)"";
+ #endif
+ #ifdef dbd_db_login6_sv
+-ST(0) = dbd_db_login6_sv(dbh, imp_dbh, dbname, username, password,
attribs) ? _sv_yes : _sv_no;
++RETVAL = dbd_db_login6_sv(dbh, imp_dbh, dbname, username, password,
attribs);
+ #elif defined(dbd_db_login6)
+-ST(0) = dbd_db_login6(dbh, imp_dbh, SvPV_nolen(dbname), u, p, attribs) ?
_sv_yes : _sv_no;
++RETVAL = dbd_db_login6(dbh, imp_dbh, SvPV_nolen(dbname), u, p, attribs);
+ #else
+
Bug#804722: git-buildpackage: import-dsc creates impractical merge commits after new upstream releases
I've been hitting this recently and wondering whether the current behaviour is by accident or design (I'm surprised it's at least five years old) but I concur with the filer that a much simpler, two-step merge (merge upstream, then apply debian diff as the next commit) would be *far* easier to work with. Do the maintainers have a view? -- Jonathan Dowland
Bug#967894: pan: Build-Depends on libgtkspell-dev, probably unnecessarily
On mardi 4 août 2020 15:26:06 CEST you wrote: > Looking at the buildd log, it seems like libgtkspell-dev is probably > unnecessary - presumably it's left over from pan's GTK 2 history. You're right. I'll remove this dependency. However pan still depends on libgtk2.0-dev even though Debian's build is done with Gtk3. I'll check with upstream what's going on.. All the best Dod
Bug#775147: emscripten: does not work at all with optimization enabled
Sylvestre Ledru wrote: > emscripten developers implemented fastcomp, a LLVM backend. This > requires a patched version of LLVM and this could not go in Debian > packages. fastcomb is no longer default backend since emscripten v1.39.0: > v1.39.0: 10/18/2019 > --- > - The emsdk defaults to the upstream backend (instead of fastcomp) >from this release onward (but both backends are still fully >supported). See >https://emscripten.org/docs/compiling/WebAssembly.html#backends - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#961843: buster-pu: package lighttpd/1.4.53-4
Since two months have been passed, may I ask about the status of this request? The requested debdiff has been attached above and these patches fix potential and actual security issues in backend applications which can be hard to debug or even recognise (meaning a security issue exists without the knowledge of the admin/user). Many thanks for your efforts on this. Best regards, Micha
Bug#970011: linux: missing build dependency on kernel-wedge in stage1 build
Control: tag -1 pending On Thu, 2020-09-10 at 06:59 +0200, Helmut Grohne wrote: > Source: linux > Version: 5.8.7-1 > Severity: important > User: helm...@debian.org > Usertags: rebootstrap > > Hi, > > I'm run into a bootstrap failure caused by linux: > https://jenkins.debian.net/job/rebootstrap_hppa_gcc10/9/ > > dh_prep > > dh_prep: warning: All requested packages have been excluded (e.g. via a > > Build-Profile or due to architecture restrictions). > > kernel-wedge install-files 5.8.0-1 > > bash: kernel-wedge: command not found > > make[2]: Leaving directory '/tmp/buildd/linux/linux-5.8.7' > > make[2]: *** [debian/rules.real:573: install-udeb_hppa] Error 127 > > make[1]: Leaving directory '/tmp/buildd/linux/linux-5.8.7' > > make[1]: *** [debian/rules.gen:89: binary-arch_hppa] Error 2 > > make: *** [debian/rules:43: binary-arch] Error 2 > > dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit > > status 2 > > What we see here is that kernel-wedge is not found while cross building > linux with the stage1 profile for hppa. This seems to be a recent thing. > It used to work earlier. I'm not sure yet, how many other architectures > are affected. This is specific to hppa. It recently gained transitional metapackages with no build-profiles set, and that made the condition here true: install-udeb_$(ARCH): # Logically we should check for %-di here, but that would break test builds ifneq (,$(filter linux-image-%,$(packages_enabled))) ... endif endif # enabled > A kernel-wedge dependency is there, but it is tagged . That > used to be true. It should still be true; there is no reason to run kernel-wedge, and it would fail if it was installed anyway. [...] > While looking into linux' build profiles I was wondering whether we > still need stage1. linux gained a number of functional profiles > including pkg.linux.nokernel, pkg.linux.notools and pkg.linux.nosource. > Their combination does not exactly reproduce stage1, but it is close. > I'm wondering whether we can simply switch any stage1 user to using the > combination of these three and be done. I haven't tried whether this > actually works yet, but I believe it is feasible and you get the idea. I think that would be more fragile than the clearly defined stage1. Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Bug#970094: ITP: r-cran-ragg -- Graphic Devices Based on AGG
Package: wnpp Severity: wishlist Subject: ITP: r-cran-ragg -- Graphic Devices Based on AGG Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-cran-ragg Version : 0.3.1 Upstream Author : Thomas Lin Pedersen * URL : https://cran.r-project.org/package=ragg * License : MIT Programming Lang: GNU R Description : Graphic Devices Based on AGG Anti-Grain Geometry (AGG) is a high-quality and high-performance 2D drawing library. The 'ragg' package provides a set of graphic devices based on AGG to use as alternative to the raster devices provided through the 'grDevices' package. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-ragg
Bug#970092: ITP: r-cran-downlit -- Syntax Highlighting and Automatic Linking
Package: wnpp Severity: wishlist Subject: ITP: r-cran-downlit -- Syntax Highlighting and Automatic Linking Package: wnpp Owner: Steffen Moeller Severity: wishlist * Package name: r-cran-downlit Version : 0.1.0 Upstream Author : Hadley Wickham, RStudio * URL : https://cran.r-project.org/package=downlit * License : MIT Programming Lang: GNU R Description : Syntax Highlighting and Automatic Linking Syntax highlighting of R code, specifically designed for the needs of 'RMarkdown' packages like 'pkgdown', 'hugodown', and 'bookdown'. It includes linking of function calls to their documentation on the web, and automatic translation of ANSI escapes in output to the equivalent HTML. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-downlit
Bug#911189: gpgme-json packaging
Sascha Wilde writes: > As a first step I created a merge request to deploy gpgme-json together > with the library: > https://salsa.debian.org/debian/gpgme/-/merge_requests/1 After realizing that the current MR breaks multi arch compatibility for the library I revised it and added a new -bin package, which for now only provides gpgme-json. I also added a rudimentary man page for gpgme-json. > Next I will look into creating specific packages with browser > manifests... I have implemented that and created a new merge request: https://salsa.debian.org/debian/gpgme/-/merge_requests/2 In addition to the new -bin package two more new packages are created: - libgpgme-chromium-native-messaging - libgpgme-firefox-native-messaging Each of the packages provides a native messaging manifest for the respective browser which allows using GPGME via gpgme-json for a set of well known extensions. For now the only supported extension is mailvelope but more could be easily added later on. Upstream encourages distributors to create manifest packages for their distributions, therefor I think adding these packages here is The Right Thing To Do™. Some remarks/requests for comment: 1. Currently the manifest installed for chromium is installed as: /etc/chromium/native-messaging-hosts/gpgmejson.json Upstream recommends a slightly different file name schema[0]: /etc/chromium/native-messaging-hosts/com.my_company.my_application.json As you can see, following this recommendation would mean adding a domain. I'm not sure whether to follow this scheme, and if so, which domain to add: org.debian, org.gnupg or ..? 2. The manifest for chromium is automatically marked configuration file, as it resides under /etc, which IMO is correct. A sysadmin might want to edit the manifest, e.g. to add the IDs of further extensions. However: the manifest for firefox is installed as /usr/lib/mozilla/native-messaging-hosts/gpgmejson.json (This is dictated by firefox searching for global manifests in that place). So it is not automatically marked as configuration. And as of compatibility level 12 of debhelper it seems to be no longer possible to mark the file as configuration manually (dh_installdeb simply ignores any debian/package.conffiles. Is there a way to work around this? For the reason given above I think the manifest should be marked as a conffile for firefox, too... cheers, sascha [0] https://developer.chrome.com/apps/nativeMessaging -- Sascha Wilde OpenPGP key: 4365844304077279 http://www.intevation.de/ http://www.intevation.de/~wilde/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: PGP signature
Bug#970091: RFS: xlbiff/4.3-1 [ITA] -- Displays From and Subject lines of your new mail
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xlbiff": * Package name: xlbiff Version : 4.3-1 Upstream Author : e...@edsantiago.com (Ed Santiago) * URL : http://www.edsantiago.com/xlbiff/ * License : Expat * Vcs : https://github.com/edsantiago/xlbiff Section : mail It builds those binary packages: xlbiff - Displays From and Subject lines of your new mail To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xlbiff/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xlbiff/xlbiff_4.3-1.dsc Changes since the last upload: xlbiff (4.3-1) unstable; urgency=low . * new maintainer (closes: #485647) * new upstream version: - rename manual page from xlbiff.1x to xlbiff.1 - change default mail path directory from /var/spool/mail to /var/mail - update default font resource (#743835) * distribute example bulk support files: README.bulk, Bcheck, Bscan * remove xlbiff.form from /usr/share/doc; it is already in /usr/share/mh < Stephen
Bug#970090: lvm2: Cache mode "writeback" is not compatible with cache policy "cleaner".
Package: lvm2 Version: 2.03.02-3 Severity: wishlist Dear Maintainer, when trying to use the cleaner cachepolicy in writeback mode, lvm2 fails like this: Cache mode "writeback" is not compatible with cache policy "cleaner". However, the kernel suports this combination, which is very useful to avoid cache migrations but sitll have a hotspot writeback cache. It would be nice if lvm2 also supported this combination (can't see why it dosn't, in fact). -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.6.19-050619-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.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 lvm2 depends on: ii dmeventd 2:1.02.155-3 ii dmsetup 2:1.02.171-3 ii libaio1 0.3.112-3 ii libblkid1 2.33.1-0.1 ii libc6 2.30-4 ii libdevmapper-event1.02.1 2:1.02.171-3 ii libdevmapper1.02.12:1.02.171-3 ii libreadline5 5.2+dfsg-3+b13 ii libselinux1 3.1-2 ii libsystemd0 246.4-1 ii libudev1 241-7~deb10u4 ii lsb-base 10.2019051400 Versions of packages lvm2 recommends: ii thin-provisioning-tools 0.7.6-2.1 lvm2 suggests no packages. -- Configuration Files: /etc/lvm/lvmlocal.conf changed [not included] -- debconf information excluded
Bug#968567: linux-image-4.19.0-10-amd64: kernel failure when writing on a GFS2 partition
Hi Daniel, hi Nicolas, On Thu, Sep 10, 2020 at 04:47:20AM +, Craig, Daniel (CASS, Marsfield) wrote: > Hi, > > I can confirm the existence of this CPU soft-lock bug with gfs2. > > I won't worry about reproducing the kernel bug message, but I have > done a bit of digging and if I revert the following commit, added in > the 4.19.130 release then this fixes issue for me. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y=c91cffd0fd010c06d67f3a9a528b858ce28c60fb > > Note that the problem is still present in the latest upstream > release in the 4.19 series (4.19.144) > > I've reported this bug in the kernel bugzilla, referenced here: > > https://bugzilla.kernel.org/show_bug.cgi?id=209217 Upstream did had a look at this see (you both were CC'ed on that thread though) the thread starting at https://lore.kernel.org/stable/20200910194319.GA131386@eldamar.local/ and suggested that upstream commit cbcc89b630447ec7836aa2b9242d9bb1725f5a61 is definitely needed. Would it be possible for you to test a build with that commit added on top? (Note the patch would need a slight refresh when applying on top of 4.19.144 for context changes). https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 explains how to test a single patch on top of the packaging, or you can try 4.19.144 with the cherry-picked commit. That would be much appreciated. Regards, Salvatore
Bug#970088: systemd: Add trigger to update systemd-boot installation
Package: systemd Version: 246.4-1 Severity: wishlist Dear maintainers, it would be very nice if it would be possible to add a trigger to the postinst of the systemd package which runs "bootctl update" if systemd-boot is installed on the machine. Could you add this feature? Thank you and best regards, Jan -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-8 ii libapparmor1 2.13.4-3 ii libaudit11:2.8.5-3+b1 ii libblkid12.36-3 ii libc62.31-3 ii libcap2 1:2.43-1 ii libcrypt11:4.4.17-1 ii libcryptsetup12 2:2.3.4-1 ii libgcrypt20 1.8.6-2 ii libgnutls30 3.6.15-1 ii libgpg-error01.38-2 ii libidn2-02.3.0-1 ii libip4tc21.8.5-3 ii libkmod2 27+20200310-2 ii liblz4-1 1.9.2-2 ii liblzma5 5.2.4-1+b1 ii libmount12.36-3 ii libpam0g 1.3.1-5 ii libpcre2-8-0 10.34-7 ii libseccomp2 2.4.3-1+b1 ii libselinux1 3.1-2 ii libsystemd0 246.4-1 ii libzstd1 1.4.5+dfsg-4 ii mount2.36-3 ii systemd-timesyncd [time-daemon] 246.4-1 ii util-linux 2.36-3 Versions of packages systemd recommends: ii dbus 1.12.20-1 Versions of packages systemd suggests: ii policykit-10.105-29 ii systemd-container 246.4-1 Versions of packages systemd is related to: ii dracut 050+65-1 pn initramfs-tools ii libnss-systemd 246.4-1 ii libpam-systemd 246.4-1 ii udev 246.4-1 -- no debconf information
Bug#970089: lua-say: autopkgtest failure
Source: lua-say Version: 1.3-1-4 Severity: normal Tag: patch Dear Maintainer, lua-say has an autopkgtest failure at the moment because a warning is raised in stderr: autopkgtest [09:19:35]: test dh-lua-tests: - - - - - - - - - - results - - - - - - - - - - dh-lua-tests FAIL stderr: dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) We have two options to fix this issue: 1) bump the debhelper compatibility level version to something greater than 9 (preferred solution); or 2) patch the d/t/control to add the allow-stderr restriction. This is blocking dh-lua/27 migration in Ubuntu, therefore I am uploading 2) to Ubuntu right now. FWIW the patch is attached. -- Lucas Kanashiro diff --color -Nru lua-say-1.3-1/debian/changelog lua-say-1.3-1.new/debian/changelog --- lua-say-1.3-1/debian/changelog 2016-07-25 12:08:30.0 -0300 +++ lua-say-1.3-1.new/debian/changelog 2020-09-11 09:46:44.64123 -0300 @@ -1,3 +1,10 @@ +lua-say (1.3-1-5) UNRELEASED; urgency=medium + + * d/t/control: add allow-stderr restriction. It fixes an autopkgtest +regression. + + -- Lucas Kanashiro Fri, 11 Sep 2020 09:45:56 -0300 + lua-say (1.3-1-4) unstable; urgency=medium * Add lua-busted to test dependencies, so tests pass on CI diff --color -Nru lua-say-1.3-1/debian/tests/control lua-say-1.3-1.new/debian/tests/control --- lua-say-1.3-1/debian/tests/control 2016-07-25 11:48:43.0 -0300 +++ lua-say-1.3-1.new/debian/tests/control 2020-09-11 09:20:13.098023456 -0300 @@ -1,3 +1,3 @@ Tests: dh-lua-tests -Restrictions: rw-build-tree +Restrictions: rw-build-tree, allow-stderr Depends: @, dh-lua, lua-busted
Bug#969206: 969206: additional info
Hello, I have attempted patching out dependencies in Gemfile, namely, rails and roadie-rails, to accept later major releases. However, I ran into the following autopkgtest failures. First of all, 'service apache2 restart' fails in autopkgtest on schroot. It tries to execute 'systemctl', which apparently is not there, as systemd package does not seem to be installed there. Nevertheless, this issue could be circumvented by replacing 'service apache2 restart' with 'apachectl restart' (not sure about side effects, but at least Apache2 starts). With this patch I continued with autopkgtest 'command1', which checks whether the main page of Redmine loads. And this check failed with "Redmine 500 error", with the following message in error log: Completed 500 Internal Server Error in 208ms (ActiveRecord: 25.5ms | Allocations: 74866) NotImplementedError (Subclasses must implement a find_templates(name, prefix, partial, details, locals = []) method): config/initializers/10-patches.rb:74:in `block in find_all' config/initializers/10-patches.rb:69:in `find_all' lib/redmine/sudo_mode.rb:63:in `sudo_mode' I have little idea, but this might be a signal of incompatibility with new ruby-rails. Andrius
Bug#935203: tomcat9: systemd and /var/lib/tomcat9/policy/
Hello, I've just installed the following from stretch-backports: $ dpkg --list | grep tomcat9 | cut -c1-60 ii libtomcat9-java 9.0.16-4~bpo9+1 ii tomcat9 9.0.16-4~bpo9+1 ii tomcat9-common 9.0.16-4~bpo9+1 And got the following error on initial start-up: [2020-09-10 14:59:31] [info] mkdir: cannot create directory ‘/var/lib/tomcat9/policy’: Read-only file system I then did a 'mkdir' and tried to do a chown/chgrp to the tomcat user/group and got: [2020-09-10 15:12:39] [info] rm: cannot remove '/var/lib/tomcat9/policy': Read-only file system I copied over the config file: $ sudo cp -p /lib/systemd/system/tomcat9.service /etc/systemd/system/ And tried adding the following line: ReadWritePaths=/var/lib/tomcat9/policy/ Did not help. I then put: ReadWritePaths=/var/lib/tomcat9/ and things were okay. Further, on package installation, the package was expecting a "tomcat" group because a 'chown' failed: Creating config file /etc/tomcat9/tomcat-users.xml with new version chown: invalid group: ‘root:tomcat’ I did a 'vigr' and created a "tomcat" group with the same GID as "tomcat8" and that allowed the installation to finish.
Bug#970086: Unversioned Python removal in sid/bullseye
Control: tags -1 + patch
this is the last package preventing migration of python-defaults to testing.
Uploading that fix to the delayed queue.
diff -Nru android-platform-build-8.1.0+r23/debian/changelog android-platform-build-8.1.0+r23/debian/changelog
--- android-platform-build-8.1.0+r23/debian/changelog 2020-05-10 10:32:25.0 +0200
+++ android-platform-build-8.1.0+r23/debian/changelog 2020-09-11 13:37:07.0 +0200
@@ -1,3 +1,10 @@
+android-platform-build (1:8.1.0+r23-4.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Explicitly build using dh-python and python2. Closes: #970086.
+
+ -- Matthias Klose Fri, 11 Sep 2020 13:37:07 +0200
+
android-platform-build (1:8.1.0+r23-4) unstable; urgency=medium
* Team upload.
diff -Nru android-platform-build-8.1.0+r23/debian/control android-platform-build-8.1.0+r23/debian/control
--- android-platform-build-8.1.0+r23/debian/control 2020-05-10 10:32:25.0 +0200
+++ android-platform-build-8.1.0+r23/debian/control 2020-09-11 13:37:07.0 +0200
@@ -7,7 +7,8 @@
Chirayu Desai
Build-Depends:
debhelper-compat (= 12),
- javahelper
+ javahelper,
+ dh-python, python2
Build-Depends-Arch:
android-libandroidfw-dev (>= 1:8.1.0+r23~),
android-liblog-dev (>= 1:8.1.0+r23~),
@@ -76,7 +77,7 @@
Architecture: all
Depends:
${misc:Depends},
- python:any
+ ${python:Depends}
Description: Tools from AOSP that process event-log-tags files
This package contains Python scripts from AOSP repository platform/build that
process event-log-tags (.logtags) files. It contains:
diff -Nru android-platform-build-8.1.0+r23/debian/rules android-platform-build-8.1.0+r23/debian/rules
--- android-platform-build-8.1.0+r23/debian/rules 2020-05-10 10:32:25.0 +0200
+++ android-platform-build-8.1.0+r23/debian/rules 2020-09-11 13:37:07.0 +0200
@@ -46,7 +46,7 @@
jh_build --javacopts="-source 7" --no-javadoc --main=com.android.signtos.SignTos $@ tools/signtos/
%:
- dh $@ --with javahelper
+ dh $@ --with javahelper,python2
override_dh_auto_build-arch: makeparallel zipalign ziptime
Bug#966846: Kernel panic (4.19.0-10): RIP __cgroup_bpf_run_filter_skb
Hi Sébastien, On Fri, Sep 11, 2020 at 11:41:16AM +0200, Sébastien NOBILI wrote: > Hi, > > More than a week after, no problem with this build, working fine > 24/7. Thanks for confirming that. We are planning to rebase the version for the next point release and so will contain the fix. Regards, Salvatore
Bug#970086: Unversioned Python removal in sid/bullseye
Package: src:android-platform-build Version: 1:8.1.0+r23-4 Severity: serious Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2unversioned Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html We will keep some Python2 package as discussed in https://lists.debian.org/debian-python/2020/07/msg00039.html but removing the unversioned python packages python-minimal, python, python-dev, python-dbg, python-doc. Your package either build-depends, depends on one of those packages. Please either convert these packages to Python3, or if that is not possible, replaces the dependencies on the unversioned Python packages with one of the python2 dependencies (python2, python2-dev, python2-dbg, python2-doc). Please check for dependencies, build dependencies AND autopkg tests. If there are questions, please refer to the wiki page for the removal: https://wiki.debian.org/Python/2Removal, or ask for help on IRC #debian-python, or the debian-pyt...@lists.debian.org mailing list.
Bug#969889: linux-image-5.8.0-1-amd64: fails to load
duplicate Bug #969889 linux-image-5.8.0-1-amd64: fails to load kernel modules, X does not work Reverting to: linux-image-5.7.0-3-amd64 works http://deb.debian.org/debian/ unstable non-free contrib main nvidia graphics Lars
Bug#940427: RFA: golang-github-syncthing-notify
> For now, I intend to do my best to keep maintaining this package. > However, I will probably retitle this bug with the 'O:' prefix at some > point, indicating that I have orphaned it. Hi, I'm interested in helping out the Debian Go team and considering this is something I use constantly, I would definitely be willing to help maintain it. > Feel free to upload a new version of the package and remove me from the > uploaders in debian/control. > > Feel free to contact me with any questions. Also note that I always > willing to sponsor uploads! I had a look at the tracker and it seems this just requires an update and standards bump at the moment, is this correct? -- Thanks, Jai
Bug#970085: Missing qml module dependencies for ausweisapp2
On 9/11/20 11:22 AM, Allison Karlitskaya wrote: > Installing ausweisapp2 on a relatively clean system (ie: no other Qt/QML > apps) misses installation of some required dependencies: > Installing the following extra dependencies fixes the problem: > (...) > $ sudo apt install qml-module-qtgraphicaleffects qml-module-qtqml > qml-module-qtquick-layouts There should really be a meta-package for this QML stuff which pulls in all the necessary packages. Since I cannot test the package on all possible desktop configurations, these situations will probably happen again in the future when new QML dependencies are pulled in. I'll fix that in the next upload *sigh*. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970084: corosync: Corosync becomes unresponsive and disconnects from the rest of the cluster when primary link is lost
On Fri, Sep 11, 2020 at 11:45:54AM +0200, Valentin Vidic wrote: > This might be a knet problem. Can you test if just installing knet > libs from backports with corosync 3.0.1-2+deb10u1 solves the issue > you are seeing? Also knet update for buster has not been approved yet, but can be tracked here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950488 -- Valentin
Bug#970085: Missing qml module dependencies for ausweisapp2
On 9/11/20 12:00 PM, John Paul Adrian Glaubitz wrote: > On 9/11/20 11:22 AM, Allison Karlitskaya wrote: > Since I cannot test the package on all possible desktop configurations, these > situations will probably happen again in the future when new QML dependencies > are pulled in. And I just realized my previous change added the dependencies to the Build-Dependencies field not to the Depends field of the binary package AusweisApp2 [1]. Adrian > [1] > https://salsa.debian.org/debian/ausweisapp2/-/commit/c13b4b1f5cb034452a07bfa485c54df2b8d1a372 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970084: corosync: Corosync becomes unresponsive and disconnects from the rest of the cluster when primary link is lost
On Fri, Sep 11, 2020 at 11:22:19AM +0200, Eugen Wick wrote: > * Tests with Corosync 3.0.3 from debian testing. > We installed packages from debian testing and fulfilled dependencies from > debian backports. > > # > apt install libnozzle1=1.16-2~bpo10+1 libknet1=1.16-2~bpo10+1 libnl-3-200 > libnl-route-3-200 libknet-dev=1.16-2~bpo10+1 ./corosync_3.0.3-2_amd64.deb > ./libcorosync-common4_3.0.3-2_amd64.deb > # > The described problem does not occur with the 3.0.3 version from debian > testing. This might be a knet problem. Can you test if just installing knet libs from backports with corosync 3.0.1-2+deb10u1 solves the issue you are seeing? -- Valentin
Bug#966846: Kernel panic (4.19.0-10): RIP __cgroup_bpf_run_filter_skb
Hi, More than a week after, no problem with this build, working fine 24/7. Sébastien
Bug#970085: Missing qml module dependencies for ausweisapp2
Package: ausweisapp2 Version: 1.20.2-1 Installing ausweisapp2 on a relatively clean system (ie: no other Qt/QML apps) misses installation of some required dependencies: $ sudo apt install ausweisapp2 ... $ AusweisApp2 ... default2020.09.11 11:19:14.860 398030 W unknown(unknown:0) : QQmlApplicationEngine failed to load component default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:32) : qrc:/qml/main.qml:32:1: module "QtGraphicalEffects" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:30) : qrc:/qml/main.qml:30:1: module "QtQuick" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:28) : qrc:/qml/main.qml:28:1: module "QtQml" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:32) : qrc:/qml/main.qml:32:1: module "QtGraphicalEffects" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:30) : qrc:/qml/main.qml:30:1: module "QtQuick" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:28) : qrc:/qml/main.qml:28:1: module "QtQml" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:32) : qrc:/qml/main.qml:32:1: module "QtGraphicalEffects" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:30) : qrc:/qml/main.qml:30:1: module "QtQuick" is not installed default2020.09.11 11:19:14.860 398030 W unknown(/qml/main.qml:28) : qrc:/qml/main.qml:28:1: module "QtQml" is not installed ... (and the main app window isn't shown). Installing the following extra dependencies fixes the problem: $ sudo apt install qml-module-qtgraphicaleffects qml-module-qtqml qml-module-qtquick-layouts Thanks for packaging AusweisApp! This makes my life a lot easier. :)
Bug#970084: corosync: Corosync becomes unresponsive and disconnects from the rest of the cluster when primary link is lost
Package: corosync Version: 3.0.1-2+deb10u1 Severity: important Dear Maintainer, * What led up to the situation? ** 2 Node Cluster Corosync 3.0.1 on Debian Buster. ** 2 Knet Links - ring0 on eth0 (front facing if) ring1 on eth1 (back-to-back link). ** Services running on cluster-node01. ** Cluster is running just fine, both nodes are online and see each other. ** crm_mon shows 2 online nodes and running resources without errors. * What exactly did you do (or not do) that was effective (or ineffective)? For failover testing we disconnected the eth0 interface on the active node (cluster-node01). * What was the outcome of this action? ** Situation on the active node (cluster-node01) Corosync on the node becomes unresponsive. It does not respond to commands like corosync-cfgtool and corosync-quorumtool. in crm_mon however the cluster status just looks fine. It claims both nodes are online and services are healthy. corosync logs however indicates that the cluster is disconnected. ### corosync.log Sep 11 10:06:45 [1946] cluster-node01 corosync warning [MAIN ] Totem is unable to form a cluster because of an operating system or network fault (reason: totem is continuously in gather state). The most common cause of this message is that the local firewall is configured improperly. # ** Situation on the passive node (cluster-node02) Corosync does respond to commands like corosync-cfgtool and shows that cluster-node01 is offline on all links. # ### corosync.log ### Sep 11 10:06:09 [1941] cluster-node02 corosync info[KNET ] link: host: 1 link: 0 is down Sep 11 10:06:09 [1941] cluster-node02 corosync info[KNET ] host: host: 1 has 1 active links Sep 11 10:06:10 [1941] cluster-node02 corosync notice [TOTEM ] Token has not been received in 2250 ms Sep 11 10:06:11 [1941] cluster-node02 corosync notice [TOTEM ] A processor failed, forming new configuration. Sep 11 10:06:15 [1941] cluster-node02 corosync notice [TOTEM ] A new membership (2:16) was formed. Members left: 1 Sep 11 10:06:15 [1941] cluster-node02 corosync notice [TOTEM ] Failed to receive the leave message. failed: 1 Sep 11 10:06:15 [1941] cluster-node02 corosync warning [CPG ] downlist left_list: 1 received Sep 11 10:06:15 [1941] cluster-node02 corosync notice [QUORUM] Members[1]: 2 Sep 11 10:06:15 [1941] cluster-node02 corosync notice [MAIN ] Completed service synchronization, ready to provide service. Sep 11 10:06:16 [1941] cluster-node02 corosync info[KNET ] link: host: 1 link: 1 is down Sep 11 10:06:16 [1941] cluster-node02 corosync info[KNET ] host: host: 1 has 0 active links Sep 11 10:06:16 [1941] cluster-node02 corosync warning [KNET ] host: host: 1 has no active links # # ## corosync-cfgtool -s ## root@cluster-node02:~# corosync-cfgtool -s Printing link status. Local node ID 2 LINK ID 0 addr= ###.###.###.### status: node 0: link enabled:1 link connected:0 node 1: link enabled:1 link connected:1 LINK ID 1 addr= ###.###.###.### status: node 0: link enabled:1 link connected:1 node 1: link enabled:0 link connected:1 # # # crm_mon -rfA1 ### root@cluster-node02:~# crm_mon -rfA1 Stack: corosync Current DC: cluster-node02 (version 2.0.1-9e909a5bdd) - partition with quorum Last updated: Fri Sep 11 10:45:53 2020 Last change: Fri Sep 11 10:42:26 2020 by root via cibadmin on cluster-node02 2 nodes configured 7 resources configured Online: [ cluster-node02 ] OFFLINE: [ cluster-node01 ] # Pacemaker does therefore try to perform a failover. * What outcome did you expect instead? With our configuration the cluster should not take any action and both nodes should see each other on link1. * Tests with Corosync 3.0.3 from debian testing. We installed packages from debian testing and fulfilled dependencies from debian backports. # apt install libnozzle1=1.16-2~bpo10+1 libknet1=1.16-2~bpo10+1 libnl-3-200 libnl-route-3-200 libknet-dev=1.16-2~bpo10+1 ./corosync_3.0.3-2_amd64.deb ./libcorosync-common4_3.0.3-2_amd64.deb # The described problem does not occur with the 3.0.3 version from debian testing. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (550, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages corosync depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii libc62.28-10 ii libcfg7 3.0.1-2+deb10u1 ii libcmap4 3.0.1-2+deb10u1 ii libcorosync-common4 3.0.1-2+deb10u1 ii libcpg4
Bug#961584: lxc-stop fails with exit code 1
Hi Pebs, Thanks for checking this. On Sat, 5 Sep 2020 23:23:30 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= wrote:> > LXC's devs told me that 4.0.4 should solve it. I'm uploading this > release now. Please don't hesitate to tell me if it helps. Run a pipeline removing the pinning of lxc, and the behaviour seems to be the same. Image building: https://salsa.debian.org/ina/pipeline/-/jobs/990332 > Setting up lxc (1:4.0.4-1) .. Running lxc: https://salsa.debian.org/ina/pipeline/-/jobs/990352 > : failure: ['sudo', 'timeout', '600', 'lxc-stop', '--quiet', '--kill', '--name', 'ci-254-b2fcad5f'] failed (exit status 1, stderr '') Please let me know if you want us to test something else. Abrazos, > > -- > Pierre-Elliott Bécue > GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 > It's far easier to fight for one's principles than to live up to them. -- - ina signature.asc Description: OpenPGP digital signature
Bug#960863: Help needed with perl-tk NMU
-=| Dominic Hargreaves, 10.09.2020 21:21:51 +0100 |=- > Hi all > > I didn't hear back from Colin, and so I think in order to unblock > the perl 5.32 transition we need to NMU either a targeted fix for > perl 5.32 compatibility, or the new upstream release. I'm not sure > which is more appropriate given the time since the last release in > Debian. > > Any takers? I'm a bit short on time myself, these days. > > See http://perl.debian.net/ for the test repository you might need > to verify fixes. I tried the "new upstream release" route because otherwise there would be several patches to import, one of them adding 10k-lines ppport.h The result is at https://salsa.debian.org/dmn/perl-tk and builds with per 5.32. There are many lintian/hardening warnings, but since this is a NMU, the changes are bare minimum. I haven't tested the resulting package yet, will have to find a way to do so without disturbing the rest of the system. (perhaps docker+vnc would help). Cheers, dam
Bug#969976: transition: pdal
On 9/10/20 3:13 PM, Sebastiaan Couwenberg wrote: > On 9/10/20 9:06 AM, Emilio Pozuelo Monfort wrote: >> On 09/09/2020 17:53, Bas Couwenberg wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >>> Control: forwarded -1 >>> https://release.debian.org/transitions/html/auto-pdal.html >>> >>> PDAL bumped its SONAME requiring a transition. >>> >>> All packages except paraview rebuilt successfully as summarized below. >>> >>> The paraview FTBFS is unrelated to PDAL. >>> >>> >>> Transition: pdal >>> >>> libpdal-base10 (2.1.0+ds-2+b1) -> libpdal-base12 (2.2.0+ds-1~exp1) >>> libpdal-util10 (2.1.0+ds-2+b1) -> libpdal-util12 (2.2.0+ds-1~exp1) >>> >>> The status of the most recent rebuilds is as follows. >>> >>> cloudcompare (2.10.3-4) OK >>> grass(7.8.3-1) OK >>> paraview (5.7.0-4) FTBFS (#957660) >> >> Go ahead. > > Thanks! pdal (2.2.0+ds-1) has been uploaded to unstable and is built & > installed on all release architectures. Thanks for scheduling the binNMUs, grass has built successfully. It looks like openmpi 4.0.5 broke things (#970036), preventing cloudcompare and paraview from being rebuilt. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#887085: systemd units are pushed to salsa
On Thu, Sep 10, 2020 at 22:15, Pirate Praveen wrote: We currently use debhelper compat 10 for this (like gitlab), but we need to find out how to do it in newer debhelper compat versions. I think changing dh_installinit to dh_installsystemd in newer compat level will do the trick.
Bug#970083: multiple spaces in symbols files
Package: src:dpkg Version: 1.20.5 Severity: minor symbols files with more than one space between the symbol name and the minor version are rejected. This should either be documented in deb-symbols(5), or accepted in symbols files. while looking for the documentation, I saw that dpkg-gensymbols(1) refers to deb-symbols(5) for the format, however comments in symbols files are only documented in dpkg-gensymbols(1).
Bug#887085: support libjemalloc usage for better memory usage
On Fri, Sep 11, 2020 at 14:04, Pirate Praveen wrote: Include this change in systemd units too https://github.com/diaspora/diaspora/pull/7919 I think setting LD_PRELOAD in diaspora.conf to /usr/lib/$(dpkg-architecture -q DEB_HOST_GNU_TYPE)/libjemalloc.so.2 should be enough (but we should evalauate this in postinst and set the value)
Bug#970063: debian-paketmanagement-buch: bullseye: /updates -> -security
Control: tag -1 + confirmed Control: severity -1 + important Hi Paul, Paul Wise wrote: > In the section "Inhalt der automatisch generierten Liste der > Paketmirrors" there is a reference to stable/updates but with the > release of Debian bullseye this reference will be broken since Debian > has switched to using bullseye-security for bullseye. Thanks for the reminder! 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#887085: support libjemalloc usage for better memory usage
Include this change in systemd units too https://github.com/diaspora/diaspora/pull/7919
Bug#495023:
Hallo guten Morgen, ich habe dir vor ein paar Tagen eine E-Mail geschickt, aber keine Antwort, bitte antworte dringend
Bug#970082: ITP: r-bioc-monocle -- Clustering, differential expression, and trajectory analysis for
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-monocle -- Clustering, differential expression, and trajectory analysis for Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-bioc-monocle Version : 2.16.0 Upstream Author : Copyright: (FIXME: year)-2020 Cole Trapnell * URL : https://bioconductor.org/packages/monocle/ * License : Artistic-2.0 Programming Lang: GNU R Description : Clustering, differential expression, and trajectory analysis for single- cell RNA-Seq Monocle performs differential expression and time-series analysis for single-cell expression experiments. It orders individual cells according to progress through a biological process, without knowing ahead of time which genes define progress through that process. Monocle also performs differential expression analysis, clustering, visualization, and other useful tasks on single cell expression data. It is designed to work with RNA-Seq and qPCR data, but could be used with other types as well. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-monocle
