Bug#930850: texlive-latex-extra: Update listings macro separator
Hi Norbert, On Fri, 21 Jun 2019, Xavier Gendre wrote: This bug can be fixed with: sed -i -e 's/&/:/' /usr/share/texlive/texmf-dist/tex/latex/lstaddons/lstlinebgrd.sty Did you follow the advice specifically added in the bug report template: In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. Yes, I read this advice and hesitated to send my report because of that. It seemed important to point out a non-functional package. This command was just a workaround. Please consult the original package author so that they fix the bug, upload to CTAN. After that it will arrive in TeX Live and thus in Debian. So, please, could you contact Martin Scharrer, his email address can be found in the README or pdf texdoc lstaddons (I wont post it here) I will do it! Regards, Xavier
Bug#720362: xautolock: -locknow does always lock
Control: retitle 720362 -locknow does not always lock I would like to second the proposed fix. A locker should do its best to lock when explicitly requested to do so. The "-disable" command disables *auto* locking, but should not disable an explicit lock request. Similarly, I think it is also reasonable for an explicit lock request to re-enable auto locking. Either way, a "-locknow" attempt after a "-disable" should exit non-zero with a message to stderr rather than failing silently. See also bug 930897. Thanks.
Bug#930897: xautolock silently fails if locker exits non-zero
Package: xautolock Version: 1:2.2-5.1+b1 Hello, The locker executable passed with the "-locker" option may exit non-zero if it fails to lock the display for some reason. In this case, it seems that "xautolock -locknow" should also exit non-zero, indicating that the lock operation failed. It should also write the error to stderr. This would, in my opinion, be the preferred behavior. However, perhaps xautolock is designed to immediately accept the "-locknow" command, and the non-zero exit code indicates that the command was received. Even in this case, xautolock should write a message to stderr so the problem can be logged to e.g. ~/.xsession-errors. Currently, xautolock does nothing, silently failing to lock but never indicating this anywhere. Similarly, a "-locknow" attempt after a "-disable" should exit non-zero. For example: ``` $ xautolock -disable $ xautolock -locknow # <-- This is ignored $ echo $? 0 ``` The "-locknow" command is silently ignored; it should exit non-zero. See also bug 720362, which describes an alternative way to fix this. Thanks.
Bug#579066: maximum lock time limit
I would like to second this. In some cases, I need to use an auto-locker but with a lock time of more than one hour. It is hard to imagine that there is a good reason for this arbitrary restriction. Thanks
Bug#930761: RFP: PyMuPDF -- python bindings for MuPDF
Hi, I added a number of changes to the packaging repository here: https://salsa.debian.org/python-team/modules/pymupdf I added a bunch of files to Files-Excluded, namely some files that are patched copies from mupdf itself (but we don't need them because we rely on the patched Debian mupdf package) as well as fitz.py and fitz_wrap.c that are autogenerated by SWIG. I also got into more detail with the licenses and added more paragraphs to d/copyright. There is still a question about the overall license because information in `setup.py` and `PKG-INFO` conflicts. I contacted upstream about it. Lastly, I patched `setup.py` to rebuild fitz.py and fitz_wrap.c with SWIG. Sean: since I removed several files from upstreams tarball with Files-Excluded, I also replaced the contents of that git repository with the new version that now doesn't have any of these files. I incorporated your commit but you'll have to clone the repository again. Thanks! cheers, josch signature.asc Description: signature
Bug#930860: linux-image-4.19.0-5-amd64: USB Camera seen as multiple devices
On Fri, Jun 21, 2019 at 04:07:25PM +0200, Seba Kerckhof wrote: > Under Debian 10 rc1, when I plug in my USB camera (the very common logitech > c930e), 2 devices are added (e.g. /dev/video0 and /dev/video1). > > v4l-info works on /dev/video0, but fails on /dev/video1 > (VIDIOC_G_FMT(VIDEO_CAPTURE): Invalid argument). When I try to access the > device using gstreamer it tells me that /dev/video1 is not a capture device. This is the feature added in commit 088ead25524583e2200aa99111bea2f66a86545a. media: uvcvideo: Add a metadata device node Some UVC video cameras contain metadata in their payload headers. This patch extracts that data, adding more clock synchronisation information, on both bulk and isochronous endpoints and makes it available to the user space on a separate video node, using the V4L2_CAP_META_CAPTURE capability and the V4L2_BUF_TYPE_META_CAPTURE buffer queue type. By default, only the V4L2_META_FMT_UVC pixel format is available from those nodes. However, cameras can be added to the device ID table to additionally specify their own metadata format, in which case that format will also become available from the metadata node. Guennadi, sorry but this feels more like a bug than a feature to me, and at least three other people have reported it as a bug without working out the cause. * https://bugs.debian.org/930860 * https://bugzilla.kernel.org/show_bug.cgi?id=199193 * https://bugzilla.kernel.org/show_bug.cgi?id=199575 Seba, thanks for reporting this. I met this feature while working on a closed-source application, added a workaround to ignore cameras that don't support normal video capture, and haven't yet got round to replying to the Bugzilla reports above. I'd be happy if someone else took on that task. BR, Steve
Bug#901931: This is a packaging problem
The bug was closed but it is not fixed, as explained in last comments. The fix is not to be expected from a new version of timidity as it rather is a packaging bug. As stated in https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/ (cited above by Gabriele Stilli), the timidity user should not be added to "audio" group. This is indeed what the timidity-daemon.postinst does at line 17, 44-51. So my understanding is that the packaging needs to be fixed. Side note : https://bugs.launchpad.net/ubuntu/+source/timidity/+bug/1793640 is the corresponding bug in Ubuntu.
Bug#930896: ITP: ruby-aws-sdk-s3 -- AWS SDK for Ruby - Amazon S3
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-aws-sdk-s3 Version : 1.43.0 Upstream Author : Amazon Web Services * URL : https://github.com/aws/aws-sdk-ruby3 * License : Apache-2.0 Programming Lang : Ruby Description : AWS SDK for Ruby - Amazon S3 aws-sdk-s3 is an official Amazon S3 AWS SDK for Ruby. It basically provides Amazon Simple Storage Service (Amazon S3). . This gem is part of the AWS SDK for Ruby.
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On Fri, Jun 21, 2019 at 11:18:14PM +0200, Aurelien Jarno wrote: > On 2019-06-21 21:40, Steve McIntyre wrote: > > > I know there have been disk issues reported on one of the new machines > > (yay!), possibly that's the cause here. I don't have direct login > > access myself to be able to check. Aurelien - could you take a look > > The failure on arm-ubc-02 is just due to the VM shutting down, likely > when there was some issues with the disk or migrating the VMs. That's > why the package has been given-back immediately. Hi Aurelien, As of 2019-06-21 23:34:12 UTC, the buildd status page [1] indicates "BD-Uninstallable": > Dependency installability problem for openjdk-11 on arm64: > > Installability of build dependencies not tested yet I'm not sure what that means. Perhaps it needs to be poked again? Thank you for helping us with this! tony [1] https://buildd.debian.org/status/package.php?p=openjdk-11=buster signature.asc Description: PGP signature
Bug#930895: ITP: ruby-aws-sdk-kms -- AWS SDK for Ruby - KMS
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-aws-sdk-kms Version : 1.22.0 Upstream Author : Amazon Web Services * URL : https://github.com/aws/aws-sdk-ruby3 * License : Apache-2.0 Programming Lang : Ruby Description : AWS SDK for Ruby - KMS aws-sdk-kms is an official KMS for AWS SDK for Ruby. It basically provides Key Management Service (KMS). . This gem is part of the AWS SDK for Ruby.
Bug#930850: texlive-latex-extra: Update listings macro separator
Hi Xavier, On Fri, 21 Jun 2019, Xavier Gendre wrote: > This bug can be fixed with: > sed -i -e 's/&/:/' > /usr/share/texlive/texmf-dist/tex/latex/lstaddons/lstlinebgrd.sty Did you follow the advice specifically added in the bug report template: > In particular, bugs that are related to up-upstream, i.e., neither > Debian nor TeX Live (upstream), but the original package authors, > will be closed immediately. Please consult the original package author so that they fix the bug, upload to CTAN. After that it will arrive in TeX Live and thus in Debian. So, please, could you contact Martin Scharrer, his email address can be found in the README or pdf texdoc lstaddons (I wont post it here) Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#802648: [Aptitude-devel] Bug#802648: aptitude: definite loop when searching "youk" in "youtube-dl" package info page
Control: tags -1 + pending 2016-06-12 13:25 Manuel A. Fernandez Montecelo: I've been investigating this again and I believe that it's actually a problem with the cwidget library, that has happened since forever. This happens also for example with devscripts and rhythmbox-plugins, which have a long description which makes the main/first subtree (the one with the package name, the second subtree is "Depends") to also "fill" my terminal (expand more than a screenful vertically), like youtube-dl. It doesn't happen with libwiretap5 even if the description is quite long, for example. I think that it has to do with how the cwidget implementation moves the view to jump to where the term being searched appears, and that gets confused when the contents are off the screen or something similar. The backtrace points to line 854 in ./src/cwidget/widgets/tree.cc with the line: while(curr!=start && !matches(*curr)) and with aptitude's menu_tree.cc, line 82. Searching for "yo" in "youtube-dl" screen doesn't produce the desired effect (I presume), of searching e.g. inside the Description field. When the screen starts at line "zero" [1], with incsearch enabled, "y" jumps to the line below [2], after "yo" jumps to the last line (below [3]), after "you" the same (and at this point it didn't hang yet, one can delete with backspace etc). With "youk" enters the infinite loop. If one presses "yok", or "youk", it also triggers the infinite loop. It will need quite some debugging, and probably a new cwidget release to get this fixed. Marking as pending. I append here the commit message: Avoid endless loop when searching in "package info screen" (Closes: #802648) Long explanation because it took a long while to dig all this info and understand the problem, and if this is recorded it can help to explain many of the problems and circumstances that concur. When the widget in focus is large (mostly a package with a very long description that is larger than the screen; and the view is completely filled by this description and doesn't there are no other tree nodes in focus --like the main package name at the top, or Depends or others in the bottom--), then a search which doesn't lead to other elements of the tree enters in an endless loop. As the original report explains, this is triggered for example with the package "youtube-dl" which contains a long description with many of the websites that it supports, in the "package info screen", and when the scroll is moved 1 line down, so the only thing visible (even in a moderately large screen) is part of this description. When typing "/" to start search and then "you", the page starts to jump for the incremental search (matching for example the first version of the package that appears as node under "Versions of youtube-dl"), but then if a further "k" is typed, as the original reported did (presumably to verify if the program supported sites named "youku" and "youku:show" that appear in the description), it doesn't match any other node in the tree and it entered an endless loop. The code does not support search within this kind of special node, which it could do; but failing that what it should happen instead is that, in the absence of matches, it goes back to the original view. The reason why this happens is not fully understood, the code is messy and difficult to grok. It seems that the loops expect to stop when either there's a match or when "curr == start" (so it went through all elems and didn't find a match), but this never ends up happening, either because the iteration (which involves C++ operators and iterators traversing either hierarchical or flat version of the tree) doesn't really go through all of the nodes or because they are not considered because they are "out of view". The node where the description appears is not a regular node of the tree, it is one bolted with many package related fields like Description and Homepage, but different from the rest of the nodes of the tree which are only package names, versions, dependencies and so on. The code was clearly designed with these simpler nodes in mind, and the node with the Description is clearly an abuse of the concept. So basically the best solution found to avoid the endless loop was to just stop when the loop goes through "end" for second time, if there were no matches. It's not optimal, but acceptable in terms of performance, specially having into account that it's not an operation performed in tight loops and the difference is not noticeable with other searches. A proper solution would mean to really redesign both cwidget and packages using it like aptitude so the info page is not designed as a tree and then riding one of the nodes with all sorts of extra information which is not searchable. Cheers. -- Manuel A. Fernandez Montecelo
Bug#930894: ITP: ruby-aws-sdk-core -- AWS SDK for Ruby - Core
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-aws-sdk-core Version : 3.56.0 Upstream Author : Amazon Web Services * URL : https://github.com/aws/aws-sdk-ruby * License : Apache-2.0 Programming Lang : Ruby Description : AWS SDK for Ruby - Core aws-sdk-core provides API clients for AWS. . This gem is part of the official AWS SDK for Ruby.
Bug#905022: gcc-8 documentation packages
Hello, вт, 21 мая 2019 г. в 16:58, Dmitry Eremin-Solenikov : > > Hello, > > I've updated gcc-doc/gcc-doc-defaults packages to support new gcc-8 > documentation generation. NMU Packages are uploaded to > mentors.debian.net > for review, git trees are put on salsa.debian.org/gcc-doc (-defaults). It's been nearly a month without any response. Is it an expected thing before buster release? Or should I contact debian-mentors looking for sponsors for these packages? -- With best wishes Dmitry
Bug#930893: augeas-lenses: dovecot lens cannot parse default /etc/dovecot/conf.d/10-mail.conf
Package: augeas-lenses Version: 1.12.0-1 Severity: important Augeas cannot parse the default Dovecot /etc/dovecot/conf.d/10-mail.conf file because it cannot parse the "!" in the "protocol !indexer-worker" block on line 268. This means that Puppet cannot modify this file on a default Debian buster system. This is fixed upstream with https://github.com/hercules-team/augeas/commit/5aede84cbddeee48d2722c5e36b53f2b2b596cf4 and should probably be backported to the version in buster. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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 augeas-lenses depends on no packages. augeas-lenses recommends no packages. Versions of packages augeas-lenses suggests: pn augeas-doc -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#930892: ITP: ruby-aws-sigv4 -- AWS Signature Version 4 library
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-aws-sigv4 Version : 1.1.0 Upstream Author : Amazon Web Services * URL : https://github.com/aws/aws-sdk-ruby * License : Apache-2.0 Programming Lang : Ruby Description : AWS Signature Version 4 library aws-sigv4 is an Amazon Web Services Signature Version 4 signing ligrary. It generates sigv4 signature for HTTP requests. . It is a part of aws-sdk.
Bug#930891: ITP: ruby-aws-partitions -- Provides information about AWS partitions, regions, and services
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-aws-partitions Version : 1.177.0 Upstream Author : Amazon Web Services * URL : https://github.com/aws/aws-sdk-ruby * License : Apache-2.0 Programming Lang : Ruby Description : Provides information about AWS partitions, regions, and services aws-partitions provides interfaces to enumerate AWS partitions, regions, and services. . This is a part of aws-sdk.
Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.
Source: ghdl Version: 0.36+20190617 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) When Debianized GHDL package is build it fails with message Error: No installed ghdl backend found. Terminating! in context install -m 755 -p libghdl-0_37_dev.so ../../debian/tmp/usr/lib/ghdl/mcode/ ../../debian/tmp/usr/bin/ghdl --disp-standard --std=87 > ../../debian/tmp/usr/lib/ghdl/mcode/vhdl/src/std/standard.v87 Error: No installed ghdl backend found. Terminating! make[2]: *** [Makefile:131: install] Error 2 make[2]: Leaving directory '/home/user/repo/ghdl/ghdl-git/builddir/mcode' make[1]: *** [debian/rules:140: override_dh_auto_install] Error 2 make[1]: Leaving directory '/home/user/repo/ghdl/ghdl-git' make: *** [debian/rules:54: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 The reason for the problem is the file /debian/ghdl.wrapper which prevents install when there is not already installed some "ghdl" package because it ignores "ghdl-mcode" already redy to be run in "debian/tmp/usr/bin" directory. Extending of file to find executables in the wrapper directory solves the problem #!/bin/sh set -e backend="$GHDL_BACKEND" ghdl_bin_dir="$(cd "$(dirname "$0")" ; pwd)" if [ ! -x "/usr/bin/ghdl-$backend" -a ! -x "$ghdl_bin_dir/ghdl-$backend" ]; then if [ -x "$ghdl_bin_dir/ghdl-mcode" ]; then backend=mcode elif [ -x "$ghdl_bin_dir/ghdl-gcc" ]; then backend=gcc elif [ -x "$ghdl_bin_dir/ghdl-llvm" ]; then backend=llvm elif [ -x /usr/bin/ghdl-mcode ]; then backend=mcode elif [ -x /usr/bin/ghdl-gcc ]; then backend=gcc elif [ -x /usr/bin/ghdl-llvm ]; then backend=llvm else echo >&2 "Error: No installed ghdl backend found. Terminating!" exit 2 fi fi if [ -x "$ghdl_bin_dir/ghdl-$backend" ]; then exec "$ghdl_bin_dir/ghdl-$backend" "$@" else exec "/usr/bin/ghdl-$backend" "$@" fi -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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
Bug#930889: ITP: ruby-ahoy-matey -- Simple, powerful analytics for Rails
Package: wnpp Severity: wishlist Owner: Utkarsh Gupta * Package name : ruby-ahoy-matey Version : 3.0.0 Upstream Author : Andrew Kane * URL : https://github.com/ankane/ahoy * License : Expat Programming Lang : Ruby Description : Simple, powerful analytics for Rails Track visits and events in Ruby, JavaScript, and native apps. Data is stored in your database by default so you can easily combine it with other data. . To track emails, check out Ahoy Email, and for A/B testing, check out Field Test.
Bug#930888: augeas-lenses: postfix master lens cannot parse default /etc/postfix/master.cf
Package: augeas-lenses Version: 1.12.0-1 Severity: important Tags: upstream The default augeas lens for Postfix's master.cf cannot parse the default configuration file. The configuration file contains the following line: postlog unix-dgram n - n - 1 postlogd Augeas does not understand the "unix-dgram" portion, since the lens contains a list of enumerated types and it is not among them. This prevents Puppet from being used to modify this file on a stock Debian buster system. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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 augeas-lenses depends on no packages. augeas-lenses recommends no packages. Versions of packages augeas-lenses suggests: pn augeas-doc -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#930794: unblock: intel-microcode/3.20190618.1
On Fri, 21 Jun 2019, Paul Gevers wrote: > On 20-06-2019 20:05, Henrique de Moraes Holschuh wrote: > > unblock intel-microcode/3.20190618.1 > > Unblocked, thanks. Thanks! > Just one question, the reason why all the binary blobs are different in > the package is that because the builds by Intel aren't reproducible? > I.e. they are rebuild every time? git tells me they're the same on the source tree, and diff -ru after a dpkg-deb -x also told me they're the same on the binary debs... debdiff told me they differ on the source package, but I haven't managed to find out why. I decided to trust dpkg-deb + diff on the generated binaries... For the record, this was the first time something like this happened, but this was also the first time I tried debdiff from devscripts 2.19.5~bpo9+1. And it also told me the data on the older packages also differed -- but they went through older versions of debdiff just fine! -- so I went with "this release of debdiff seems broken". Might have something to do with the use of a symlink. -- Henrique Holschuh
Bug#928185: unblock: openjdk-11/11.0.3+7-4
Hi, On 2019-06-21 21:40, Steve McIntyre wrote: > On Fri, Jun 21, 2019 at 04:29:18PM -0400, Sam Hartman wrote: > >> "tony" == tony mancill writes: > > > >tony> Hi Paul, > > > >tony> I emailed ar...@buildd.debian.org regarding that this morning > >tony> (at 13:35 UTC), but haven't received a response yet. Perhaps > >tony> related, but the first arm64 build failed for the upload to > >tony> unstable last week. The build failed on arm-ubc-02 but then > >tony> succeeded on arm-conova-02. I don't know if someone manually > >tony> triggered the retry, but a few hours after the arm64 failure, > >tony> another build was underway and successful. > > > >Happened to be in the room with SteMcIntyre, who is not actually an > >arm64 buildd admin, but who volunteered to prod people. > >He also suggested that you could copy the debian-arm list as well as > >buildd admins. > Hey Tony, > > Looking at that log now... > > The build is running and failing on arm-ubc-03, which is one of the > new buildds at UBC that have just been recently commissioned. It's odd > that there's no explicit failure message for the build, just a build > timeout. The new buildds are way slower per core than the existing arm64 buildds, however they also have much more cores. It means that some timeout might have to be adjusted. For now I have given-back the package, let's see what happens. > I know there have been disk issues reported on one of the new machines > (yay!), possibly that's the cause here. I don't have direct login > access myself to be able to check. Aurelien - could you take a look The failure on arm-ubc-02 is just due to the VM shutting down, likely when there was some issues with the disk or migrating the VMs. That's why the package has been given-back immediately. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#885923: Bug#930722: arc, arcanist: Both ship arc binary
On Wed, Jun 19, 2019 at 6:18 AM Julian Andres Klode wrote: > > Package: arc,arcanist > Severity: serious > > arc: /usr/bin/arc > arcanist: /usr/bin/arc > > One of them needs to be renamed, or both. As one who has made use of various incarnations of the 'arc' program since the 1990s, and as one who has been thinking about adopting the 'arc' package in Debian, I note that the 'arc' package has been in Debian since 2004 while 'arcanist' has only been in Debian since 2015. Therefore 'arcanist' has likely been violating policy since it was brought into Debian. It's also interesting that the popcon for 'arc' (~1000) is some 10 times what 'arcanist' (~100) has, likely because 'arc' is an archiver. I also find it interesting that bug number 919697 was opened on 'arcanist' as 'Serious' back in January about the same problem, noting that "arcanist: file conflict with arc" but was then downgraded to normal the maintainer. So that maintainer could have fixed the problem at least when he uploaded a new version of the 'arcanist' package in February, if he hadn't been aware of the problem until then. -- Robert J. Clay rjc...@gmail.com j...@rocasa.us
Bug#930887: CVE-2019-10153
Package: fence-agents Severity: important Tags: security Please see https://bugzilla.redhat.com/show_bug.cgi?id=1716286 Cheers, Moritz
Bug#930886: CVE-2019-12900
Package: bzip2 Version: 1.0.6-9 Severity: important Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12900 Cheers, Moritz
Bug#930885: CVE-2019-12904
Package: libgcrypt20 Version: 1.8.4-5 Severity: important Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904 >From a quick glance amd64 and the arms seem to use assembly implementations, but this seems to affect i386, mips and s390x? Cheers, Moritz
Bug#930868: apt-cacher-ng: cron.daily script always fails with 502 Connection closed
Thanks, Eduard, for the swift reply. It turns out that a recent change to the /etc/hosts.allow was blocking access from localhost ([::1]/128), which the daily cron script (specifically the 'acngtool') needs to work. My bad. Sorry for the noise. Please close this bug. Thanks again, -S.M.
Bug#930884: feature request: with Windows and FreeBSD and MacOS desktop, you can ship the libraries together with your application. With Linux desktop: still not :-(.
Package: ld-linux.so.X When we, I, write an application on Linux, we do installation from the repositories (or even the installation of "-dev" packages in addition if "soft symlink" is missing) for the needed shared libraries (fore exeample: Firebird, ...). But, once the application is finished, I will uninstall everything about Firebird, and from the content of the download of its *.tar.gz, I must create a client installation with AppImage + its yaml scripts (my choice). It's not so easy. The problem is that on *nix the escape like on Window or MacOS ( putting dlls together with the application !!!) doesn't work, making versioning issues more complex, specially when using official packaging systems ==> "DLL-hell" now only exists under *nix \ Linux. Can Linux improve its binary compatibility and be less forced in its package management (specially: versioning on Desktop. It's really always "DLL-hell": if you want to start distributing the libraries\packages and resulting files apart, on Linux Desktop, then you get into the dependency problems). Honestly, I think that the Linux ELF's program loader ( ld-linux.so.X ), on Linux idiosyncrasy directories, would require an evolution that would make Linux as convenient as Windows or MacOS from the point of view of desktop developments, i. e. starting by ***first*** looking in the same directory as the loaded application, if the NEEDED library would not be there, by the best of luck. -- Best regards
Bug#930883: ITP: guider -- runtime performance analyzer tool
Package: wnpp Severity: wishlist Owner: Salvatore Bonaccorso * Package name: guider Version : 3.9.5 Upstream Author : Peace Lee * URL : https://github.com/iipeace/guider/ * License : GPL Programming Lang: Python Description : runtime performance analyzer tool Guider is a runtime performance analyzer tool measuring various system resources and allowing to trace system behaviour. The description itself will need to gain some improvement and a more detailed description of the various commands which range from monitor, profile and visualize.
Bug#923203: pulseaudio: fails to start without manual configuration
Control: severity -1 grave Control: tags -1 +patch (patch is https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/5) On Fri, Jun 21, 2019 at 11:37:48AM +0200, Tobias Hansen wrote: > I just updated by system from stretch to buster and after that there was no > sound in GNOME because pulseaudio was not started. > It can be easily worked around by setting "autospawn = yes" in > ~/.config/pulse/client.conf but it's quite an annoying regression. > > Can this still be fixed for buster? Can we make it an RC bug? It should have been tagged a long time ago, but I believe that's a good idea. The bug is severe -- makes the package effectively useless for a good part of users (those on any inits other than systemd), has a pending fix, and the fix has went through maintainer's review with no comments since 3 weeks ago. I just did some extra tests, just in case -- upgrades work for me; and obviously the functionality itself. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8" ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs? ⠈⠳⣄
Bug#930882: unblock: schleuder/3.4.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, Please unblock schleuder 3.4.0-2. I've just uploaded it to unstable, it ships a fix to allow Schleuder handle mails produced by Mutt 1.12.0, which was recently released, with protected headers. Without this fix, Schleuder is unable to handle these messages, and crashes. The problem was reported by a user some days ago [1]; a fix was proposed [2], which is tested and already used in production. Please find the debdiff attached. unblock schleuder/3.4.0-2 Thanks for your work, cheers, Georg [1] https://0xacab.org/schleuder/schleuder/issues/430 [2] https://0xacab.org/schleuder/schleuder/merge_requests/290 diff -Nru schleuder-3.4.0/debian/changelog schleuder-3.4.0/debian/changelog --- schleuder-3.4.0/debian/changelog 2019-02-14 17:10:34.0 + +++ schleuder-3.4.0/debian/changelog 2019-06-21 19:05:42.0 + @@ -1,3 +1,15 @@ +schleuder (3.4.0-2) unstable; urgency=medium + + * debian/patches: +- Pull in upstream patch to handle mails with protected headers as + introduced in Mutt 1.12.0, which was recently released. These headers + are just contained within the plain body of a mail produced by Mutt, + they are not further wrapped into a specifically marked MIME-part. + Schleuder fails to handle such messages, accordingly, this patch fixes + this behaviour. (Closes: #930870) + + -- Georg Faerber Fri, 21 Jun 2019 19:05:42 + + schleuder (3.4.0-1) unstable; urgency=medium * New upstream release. diff -Nru schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch --- schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch 1970-01-01 00:00:00.0 + +++ schleuder-3.4.0/debian/patches/0017-mutt-protected-headers.patch 2019-06-21 19:05:42.0 + @@ -0,0 +1,107 @@ +Description: Handle protected headers produced by Mutt 1.12.0 + Mutt 1.12.0, which was recently released, introduced protected headers. These + headers are just contained within the plain body of a mail produced by Mutt, + they are not further wrapped into a specifically marked MIME-part. Schleuder + fails to handle such messages, accordingly, this patch fixes this behaviour. +Origin: upstream +Forwarded: not-needed +Applied-Upstream: 0651daf54a520906583aa6de4bb3854575fcb963 +Last-Update: 2019-06-20 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: schleuder/lib/schleuder/mail/message.rb +=== +--- schleuder.orig/lib/schleuder/mail/message.rb schleuder/lib/schleuder/mail/message.rb +@@ -55,7 +55,7 @@ module Mail + new.protected_headers_subject = self.subject.dup + + # Delete the protected headers which might leak information. +-if new.parts.first.content_type == "text/rfc822-headers; protected-headers=v1" ++if new.parts.first && new.parts.first.content_type == "text/rfc822-headers; protected-headers=v1" + new.parts.shift + end + end +Index: schleuder/spec/fixtures/mutt_protected_headers.txt +=== +--- /dev/null schleuder/spec/fixtures/mutt_protected_headers.txt +@@ -0,0 +1,47 @@ ++From schleu...@example.org Thu Jun 13 15:19:33 2019 ++Received: from 127.0.0.1 (helo=localhost.localdomain) ++ by mail.example.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) ++ (Exim 4.92) ++ id 1hbPdc-0007GN-6b ++ for schleu...@example.org; Thu, 13 Jun 2019 15:19:32 +0200 ++Date: Thu, 13 Jun 2019 15:19:30 +0200 ++From: dev ++To: schleu...@example.org ++Subject: ... ++Message-ID: <20190613131930.ABC@xyz> ++MIME-Version: 1.0 ++Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; ++ boundary="z6Eq5LdranGa6ru8" ++Content-Disposition: inline ++ ++ ++--z6Eq5LdranGa6ru8 ++Content-Type: application/pgp-encrypted ++Content-Disposition: attachment ++ ++Version: 1 ++ ++--z6Eq5LdranGa6ru8 ++Content-Type: application/octet-stream ++Content-Disposition: attachment; filename="msg.asc" ++ ++-BEGIN PGP MESSAGE- ++ ++hQIMA691X8Gl2MArAQ//SFZyc/TD/9PYMddJcUIp4F85wsoCUZUaVLpKBzUZdrLv ++rln9bgaou4MiUXF8ZTSqq2ET6A3X7+wpDjs79KiDJnILUmguGDT2KTkyD8lxP9nd ++oIKtqKdf95AYGmItYkaQqdZf1No2q4ZBQNWXp8+LZgxINn5AW+9wuOo8F9w+tyZJ ++8r9jlj5TJ0YnVp5FieKMMyxiSOCGX8lAaqi4TbML35OWrnL8Decsz5tTX4jfqr8L ++cvNuIpa863WkbZxMxLEEn4/yC6upmOnU3eSZ9M/UoXiqgBsd01KEoOvmIIPOgGce ++IaCxO4zuoPvtcQsuinlLCI2oX9mpex6iTMGmD1J0G9FNGI3OHkwZcahw+4/3dv9K ++jfUjm6XwndtYi6ifAPAf8M8RT84hFlZKqR7IpGmpqWnLZx6BcFV0RDu8GCIPD6Fr ++UeLu1hGLD3SMbKy9zSR4lDSkMRvCUumXAebtEvfp7dfQ9Z8I866J5/9EZIDH88M1 ++Rb9agaBlwwr8Oy0hzC3rwvLyqXi1KD79f+YmGL0yatYPTm37qCE+QdfXCkesN6jg ++SV3zjtpBalP0KMCtAhouFf6xDz615nWvC5NRh2yzYOhSVfmZEVrB9Zz7GZx8rsMi ++2U0ALYJIc6EI0uc/sLZ9dYu6hBa72VmSe90zS5IE2ZYB24GnzXV95iMsvH35/4vS
Bug#930881: want dgit --quilt=debcherry
Package: dgit
Version: 8.3
Severity: wishlist
See this mail from David Bremner. I think it should be possible to
have dgit run git-debcherry rather than its own quilt linarisatio.
This new mode would be useable with both split and unsplit view. I'm
not sure which should be the default.
Ian.
From: David Bremner
To: Ian Jackson
Cc: debian-de...@lists.debian.org
Subject: Re: Survey: git packaging practices / repository format
Date: Wed, 29 May 2019 18:36:01 -0300
Ian Jackson writes:
> Hi. Thanks for your contributions which I am trying to capture, but I
> don't think I fully understand them.
>
> David Bremner writes ("Re: Survey: git packaging practices / repository
format"):
>> With modified upstream files in the main branch, plus debian/*, but
>> usually no d/patches I use a seperate (manually
>> rebased) branch for patches, and export those at dsc creation time using
>> a gitpkg hook
>
> Is this the same setup as described by Simon McVittie for xorg
> packages (eg, mesa) ?
I don't think so. My own usage is "purer" and doesn't involve quilt;
the mention of d/patches is probably a red herring here; I only
mentioned because I remember that some users of git-debcherry like(d) to
commit exported patches to be compatible(ish) with gbp.
> If not I don't understand, because you say both that the upstream
> files are modified in your main branch, and that there are patches in
> d/patches but that is in a separate branch.
> Are the same changes
> represented twice, then, on two git branches ?
The patch branch (which is just a regular git branch), is just a linear
sequence of commits on upstream.
> You say "a gitpkg hook". Is the hook script in Debian or is it ad
> hoc ? My table would perhaps want to name it.
yes, it is /usr/share/gitpkg/hooks/quilt-patches-deb-export-hook (in
the package gitpkg).
>
>> With unmodified upstream files in the main branch, plus debian/*, but
>> usually no d/patches, I use git-debcherry to generate a quilt series at
>> dsc build time.
>
> I think I understand this one a bit better than the one above.[1]
> What constraints are there on the main branch, for this to work ?
>
There are no (known) constraints on the main branch, but the degree to
which it "works" varies. It guarantees the same working tree as you
started with, but not a one-to-one mapping between git commits and quilt
patches. In particular there can be a "debcherry-fixup-patch" containing
some changes that could not be nicely linearized into patches.
> [1] git-debcherry solves a very similar problem to dgit's quilt
> linearisation, which is used for example by dgit to construct `3.0
> (quilt)' patches out of the commits made by an NMUer.
Yes, that's why I pointed git-debcherry out to you when you started
designing dgit :P
> And I think git-debrebase branches are always suitable for use with
> git-debcherry, but git-debrebase knows how to make patches itself so
> you don't need git-debcherry then.)
Sure, except if you have a project already using git-debcherry, where I
guess git-debrebase might not work.
git-debcherry itself does not modify history, only generates source
packages. There is a companion script 'git-refresh' that I think
was never packaged (attached for reference). The idea is to bring
patches to the tip of history again, which I guess is a simplified
version of what git-debrebase does.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On Fri, Jun 21, 2019 at 04:29:18PM -0400, Sam Hartman wrote: >> "tony" == tony mancill writes: > >tony> Hi Paul, > >tony> I emailed ar...@buildd.debian.org regarding that this morning >tony> (at 13:35 UTC), but haven't received a response yet. Perhaps >tony> related, but the first arm64 build failed for the upload to >tony> unstable last week. The build failed on arm-ubc-02 but then >tony> succeeded on arm-conova-02. I don't know if someone manually >tony> triggered the retry, but a few hours after the arm64 failure, >tony> another build was underway and successful. > >Happened to be in the room with SteMcIntyre, who is not actually an >arm64 buildd admin, but who volunteered to prod people. >He also suggested that you could copy the debian-arm list as well as >buildd admins. Hey Tony, Looking at that log now... The build is running and failing on arm-ubc-03, which is one of the new buildds at UBC that have just been recently commissioned. It's odd that there's no explicit failure message for the build, just a build timeout. I know there have been disk issues reported on one of the new machines (yay!), possibly that's the cause here. I don't have direct login access myself to be able to check. Aurelien - could you take a look please? -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#930880: Local variables don't work
Package: elpa-debian-el Version: 37.8 File: /usr/share/emacs/site-lisp/elpa-src/debian-el-37/apt-sources.el Don't disable local variables set in files please. # cat /etc/apt/sources.list.d/jidanni.list deb http://opensource.nchc.org.tw/debian/ experimental main contrib non-free deb http://opensource.nchc.org.tw/debian/ unstable main contrib non-free # Local Variables: # compile-command: "perl -nwle 's!//\K[a-z.]+tw!ftp.tw.debian.org! && print;' jidanni.list | tee temp.list" # End:
Bug#930869: needed then
Control: severity -1 wishlist Control: retitle -1 needs purging of quirks On Fri, Jun 21, 2019 at 10:22:16PM +0200, Michael Biebl wrote: > >>> But, do we even have an alternative for suspending remotely? > >> Not really, pm-utils is not needed. > > Could you then please educate me what the replacement is? > > I'm not here to educate you. > You are too smart anyways. Thanks for kind words. No alternative means we can't remove pm-utils. You're right that the quirks are obsolete and unmaintained, and should be purged away. There's no hope for machine vendors' ACPI implementations to get into sane states within our lifetime, but handling the brokenness is done in the kernel these days. But, such clean-up is not a task for deepest parts of the freeze. For now, pm-utils works fine, at least within my use cases. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Bug#930879: Please disable panfrost when moving out of experimental
Source: mesa Version: 19.1.0-1 Severity: normal Hey, Panfrost debuted in mesa 19.1.0, but it's stil really early days. Some of my collegues hacking on panfrost mentioned they'd feel quite uneasy if 19.1 with panfrost enabled made its way into testing and creating a bad image for panfrost. The hopes are that from 19.2 it will be ready for somewhat wider consumption. Sjoerd -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-5-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#928185: unblock: openjdk-11/11.0.3+7-4
> "tony" == tony mancill writes: tony> Hi Paul, tony> I emailed ar...@buildd.debian.org regarding that this morning tony> (at 13:35 UTC), but haven't received a response yet. Perhaps tony> related, but the first arm64 build failed for the upload to tony> unstable last week. The build failed on arm-ubc-02 but then tony> succeeded on arm-conova-02. I don't know if someone manually tony> triggered the retry, but a few hours after the arm64 failure, tony> another build was underway and successful. Happened to be in the room with SteMcIntyre, who is not actually an arm64 buildd admin, but who volunteered to prod people. He also suggested that you could copy the debian-arm list as well as buildd admins.
Bug#930877: nageru FTCBFS: cannot use bin2h as a generator
On Fri, Jun 21, 2019 at 09:48:58PM +0200, Helmut Grohne wrote: > nageru fails to cross build from source, because meson refuses to run > the host binary bin2h. As it happens, bin2h is not installed by nageru. > Its behaviour is architecture-independent. For these reasons we can mark > it native. After doing so, nageru cross builds successfully. Please > consider applying the attached patch. Hi, Applied in upstream git, but won't be uploaded to Debian yet due to the freeze. Thanks for the patch! /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#930869: Don't release with buster
On Fri, Jun 21, 2019 at 08:53:32PM +0200, Michael Biebl wrote: > Am 21.06.19 um 20:05 schrieb Adam Borowski: > > But, do we even have an alternative for suspending remotely? > > What do you mean by that? So here we have a computer. No GUI tools. No emulation of GUI tools. And I want to suspend it (then WoL back). > > Until that is present, pm-utils is needed -- and even then, it should > > preferably be replaced by wrappers, not removed. > > Not really, pm-utils is not needed. Could you then please educate me what the replacement is? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On Fri, Jun 21, 2019 at 09:35:29PM +0200, Paul Gevers wrote: > Hi tony, > > On 20-06-2019 15:44, tony mancill wrote: > > I interpret this exchange to mean that 11.0.3+7-5 is still the version > > preferred by the OpenJDK Team and so have uploaded that, built against > > buster and with distribution set the buster. > > > > Let me know if I misinterpreted and should upload with a different > > version, and thank you for the discussion and patience with this one. > > The build on arm64 failed. Can you please investigate? > > https://buildd.debian.org/status/fetch.php?pkg=openjdk-11=arm64=11.0.3%2B7-5=1561082322=0 Hi Paul, I emailed ar...@buildd.debian.org regarding that this morning (at 13:35 UTC), but haven't received a response yet. Perhaps related, but the first arm64 build failed for the upload to unstable last week. The build failed on arm-ubc-02 but then succeeded on arm-conova-02. I don't know if someone manually triggered the retry, but a few hours after the arm64 failure, another build was underway and successful. I mention the machine names because arm-ubc-02 and arm-ubc-03 are running the same version of sbuild, which is newer than the version of sbuild running on arm-conova-02. But perhaps there are other differences as well. If I don't hear something back by tonight, I'll try to reach the arm64 buildd admins via IRC. Thanks, tony signature.asc Description: PGP signature
Bug#930878: fix_db.pl should insist on being run by root
Package: debconf Version: 1.5.72 Severity: wishlist File: /usr/share/debconf/fix_db.pl fix_db.pl really should have a check for being root at the top, else tons of wrong error messages are produced. $ /usr/share/debconf/fix_db.pl 2>&1 | wc 21 2662854
Bug#930797: unblock: xen/4.11.1+92-g6c33308a8d-1
Control: tags -1 moreinfo Hi Hans, On 20-06-2019 21:14, Hans van Kranenburg wrote: > * Note that the fixes for XSA-297 will only have effect when also loading > updated cpu microcode with MD_CLEAR functionality. When using the > intel-microcode package to include microcode in the dom0 initrd, it > has to > be loaded by Xen. Please refer to the hypervisor command line > documentation about the 'ucode=scan' option. I asked this question recently for another unblock report (not by you) as well, but don't you think this is worth mentioning in NEWS? So that people that use apt-listchanges are warned about this? Paul signature.asc Description: OpenPGP digital signature
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Control: tags -1 moreinfo Hi Samuel On 20-06-2019 20:38, Samuel Henrique wrote: > I'm asking for the unblock of ruby-airbrussh > because a critical bug was solved in the last upload. > > The bug is related to the package throwing an exception when dealing > with non UTF-8 characters coming from SSH. Can you elaborate a bit why the severity? (Would have been nice to have that description in the bug you didn't file). Looking at the upstream bug, it may just be confusing to the user and ugly of course as rsync was said to keep on running. Is rsync in Debian broken in the same way? > I decided to upload the latest release instead of patching the previous > release Which still means review work by us. We do have quite some unblocks coming in this last freeze moment. Paul signature.asc Description: OpenPGP digital signature
Bug#930876: infnoise FTCBFS: multiple reasons
Source: infnoise Version: 0.3.1+dfsg-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs infnoise fails to cross build from source, because it does not pass cross tools to make. The easiest way of fixing that is using dh_auto_build. It keeps failing, because it does not find -lftdi1. This happens, because its libfdti detection only searches for the build architecture libftdi, but we're interested in the host architecture one here. The attached patch fixes both and makes infnoise cross buildable. Please consider applying it. Helmut diff --minimal -Nru infnoise-0.3.1+dfsg/debian/changelog infnoise-0.3.1+dfsg/debian/changelog --- infnoise-0.3.1+dfsg/debian/changelog2019-02-23 18:20:31.0 +0100 +++ infnoise-0.3.1+dfsg/debian/changelog2019-06-21 20:35:48.0 +0200 @@ -1,3 +1,12 @@ +infnoise (0.3.1+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_build pass cross tools to make. (Closes: #-1) ++ cross.patch: Detect the host libftdi instead of the build libftdi. + + -- Helmut Grohne Fri, 21 Jun 2019 20:35:48 +0200 + infnoise (0.3.1+dfsg-1) unstable; urgency=medium * New upstream release, with manpages. diff --minimal -Nru infnoise-0.3.1+dfsg/debian/patches/cross.patch infnoise-0.3.1+dfsg/debian/patches/cross.patch --- infnoise-0.3.1+dfsg/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100 +++ infnoise-0.3.1+dfsg/debian/patches/cross.patch 2019-06-21 20:35:48.0 +0200 @@ -0,0 +1,11 @@ +--- infnoise-0.3.1+dfsg.orig/software/Makefile.linux infnoise-0.3.1+dfsg/software/Makefile.linux +@@ -10,7 +10,7 @@ + -DGIT_DATE=\"$(GIT_DATE)\"\ + -DLINUX + +-FOUND = $(shell /sbin/ldconfig -p | grep --silent libftdi.so && echo found) ++FOUND = $(shell $(CC) -o /dev/null -x c /dev/null -shared -lftdi 2>/dev/null && echo found) + ifeq ($(FOUND), found) + FTDI= -lftdi + else diff --minimal -Nru infnoise-0.3.1+dfsg/debian/patches/series infnoise-0.3.1+dfsg/debian/patches/series --- infnoise-0.3.1+dfsg/debian/patches/series 2019-02-19 10:35:20.0 +0100 +++ infnoise-0.3.1+dfsg/debian/patches/series 2019-06-21 20:35:48.0 +0200 @@ -1 +1,2 @@ service-documentation.patch +cross.patch diff --minimal -Nru infnoise-0.3.1+dfsg/debian/rules infnoise-0.3.1+dfsg/debian/rules --- infnoise-0.3.1+dfsg/debian/rules2019-02-19 10:49:18.0 +0100 +++ infnoise-0.3.1+dfsg/debian/rules2019-06-21 20:35:47.0 +0200 @@ -13,7 +13,7 @@ dh_auto_clean -Dsoftware/tools override_dh_auto_build: - make -C software -f Makefile.linux CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -fPIC -IKeccak -DGIT_VERSION=\\\"$(DEB_VERSION_UPSTREAM)\\\" -DGIT_COMMIT=\\\"Debian\\\" -DGIT_DATE=\\\"$(shell date --utc +%FT%T%:z -d @$(SOURCE_DATE_EPOCH))\\\"" + dh_auto_build --buildsystem=makefile -- -f Makefile.linux CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -fPIC -IKeccak -DGIT_VERSION=\\\"$(DEB_VERSION_UPSTREAM)\\\" -DGIT_COMMIT=\\\"Debian\\\" -DGIT_DATE=\\\"$(shell date --utc +%FT%T%:z -d @$(SOURCE_DATE_EPOCH))\\\"" dh_auto_build -Dsoftware/tools -- CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)" override_dh_auto_configure:
Bug#930875: unblock: pdns/4.1.6-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
Please unblock package pdns 4.1.6-3 which contains fixes for two CVEs:
CVE-2019-10162: Denial of service via crafted zone records
CVE-2019-10163: Denial of service via NOTIFY packets
Please find the debdiff from -2 below.
Thanks,
Chris
unblock pdns/4.1.6-3
diff -Nru pdns-4.1.6/debian/changelog pdns-4.1.6/debian/changelog
--- pdns-4.1.6/debian/changelog 2019-03-31 12:48:59.0 +
+++ pdns-4.1.6/debian/changelog 2019-06-21 19:07:07.0 +
@@ -1,3 +1,12 @@
+pdns (4.1.6-3) unstable; urgency=medium
+
+ * Fix Denial of service via crafted zone records (CVE-2019-10162)
+using patch from upstream.
+ * Fix Denial of service via NOTIFY packets (CVE-2019-10163)
+using patch from upstream.
+
+ -- Chris Hofstaedtler Fri, 21 Jun 2019 19:07:07 +
+
pdns (4.1.6-2) unstable; urgency=high
[ Salvatore Bonaccorso ]
diff -Nru pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch
pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch
--- pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch
1970-01-01 00:00:00.0 +
+++ pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch
2019-06-21 19:07:07.0 +
@@ -0,0 +1,29 @@
+diff --git pdns-4.1.8/pdns/mastercommunicator.cc
pdns-4.1.8-invalidrecords/pdns/mastercommunicator.cc
+index 456957a..ce0355c 100644
+--- pdns-4.1.8/pdns/mastercommunicator.cc
pdns-4.1.8-invalidrecords/pdns/mastercommunicator.cc
+@@ -50,6 +50,7 @@ void CommunicatorClass::queueNotifyDomain(const DomainInfo&
di, UeberBackend* B)
+ FindNS fns;
+
+
++ try {
+ if (d_onlyNotify.size()) {
+ B->lookup(QType(QType::NS), di.zone);
+ while(B->get(rr))
+@@ -77,6 +78,16 @@ void CommunicatorClass::queueNotifyDomain(const DomainInfo&
di, UeberBackend* B)
+ hasQueuedItem=true;
+ }
+ }
++ }
++ catch (PDNSException ) {
++L << Logger::Error << "Error looking up name servers for " << di.zone <<
", cannot notify: " << ae.reason << endl;
++return;
++ }
++ catch (std::exception ) {
++L << Logger::Error << "Error looking up name servers for " << di.zone <<
", cannot notify: " << e.what() << endl;
++return;
++ }
++
+
+ set alsoNotify(d_alsoNotify);
+ B->alsoNotifies(di.zone, );
diff -Nru
pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch.asc
pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch.asc
--- pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch.asc
1970-01-01 00:00:00.0 +
+++ pdns-4.1.6/debian/patches/CVE-2019-10162-4.1.8-invalidrecords.patch.asc
2019-06-21 19:07:07.0 +
@@ -0,0 +1,12 @@
+-BEGIN PGP SIGNATURE-
+
+iQFOBAABCgA4FiEE1jAMq8v0abvjkuUDogjtT4r1hEYFAl0I6mcaHHJlbWkuZ2Fj
+b2duZUBwb3dlcmRucy5jb20ACgkQogjtT4r1hEZxXgf9G4rXQ3xmE6pPTnwkN+9P
+nrqhjIrbhIS8t2KNVqLjUADhxHOli8lLj84f/fLnJgRabA5mz7iFVhpcHmocJADI
+lldJsjke6qbG+oduP90TsOD0wTWvibdxpoyrQlE0KvZua7geI5nSudEAVFW/SdhQ
+ynWGCgEodG35QkLOYlF19iSkd7x52Hx8MvMUF3YDZU/IjAVIIVmS4ZdaYz32T3ih
+OfpMFcOsu7Lsk8RkecK9Hegkv9ohqXGGcfz8rGsyF0gBGqTOhZ2rPqEj66jG4x++
+wLNPOkFpJYKLW+tkPzj0ra56/zjmOPrWbZWlEORnlmrU9ZS9nYG5gfYJuPNAveCq
+Mw==
+=SR9f
+-END PGP SIGNATURE-
diff -Nru pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch
pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch
--- pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch
1970-01-01 00:00:00.0 +
+++ pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch
2019-06-21 19:07:07.0 +
@@ -0,0 +1,16 @@
+diff --git pdns-4.1.8/pdns/communicator.cc
pdns-4.1.8-busyloop/pdns/communicator.cc
+index 7db5a3e..7fd59e4 100644
+--- pdns-4.1.8/pdns/communicator.cc
pdns-4.1.8-busyloop/pdns/communicator.cc
+@@ -136,7 +136,10 @@ void CommunicatorClass::mainloop(void)
+ if (extraSlaveRefresh)
+ slaveRefresh();
+ }
+-else {
++else {
++ // eat up extra posts to avoid busy looping if many posts were done
++ while (d_any_sem.tryWait() == 0) {
++ }
+ break; // something happened
+ }
+ // this gets executed at least once every second
diff -Nru pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch.asc
pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch.asc
--- pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch.asc
1970-01-01 00:00:00.0 +
+++ pdns-4.1.6/debian/patches/CVE-2019-10163-4.1.8-busyloop.patch.asc
2019-06-21 19:07:07.0 +
@@ -0,0 +1,12 @@
+-BEGIN PGP SIGNATURE-
+
+iQFOBAABCgA4FiEE1jAMq8v0abvjkuUDogjtT4r1hEYFAl0I6mcaHHJlbWkuZ2Fj
+b2duZUBwb3dlcmRucy5jb20ACgkQogjtT4r1hEZbcQf/XTC6bDxmwt4tEXXN6hXQ
++ArS6zRED2pbxCAipxvHtbj9xqhk343aNfrG4Y8kl32AmJuP76yGfNrFeiNtPWgA
Bug#930877: nageru FTCBFS: cannot use bin2h as a generator
Source: nageru
Version: 1.8.4-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
nageru fails to cross build from source, because meson refuses to run
the host binary bin2h. As it happens, bin2h is not installed by nageru.
Its behaviour is architecture-independent. For these reasons we can mark
it native. After doing so, nageru cross builds successfully. Please
consider applying the attached patch.
Helmut
--- nageru-1.8.4.orig/shared/meson.build
+++ nageru-1.8.4/shared/meson.build
@@ -31,7 +31,7 @@
include_directories: top_include,
link_with: [shared, protobuf_lib])
-bin2h = executable('bin2h', 'bin2h.cpp')
+bin2h = executable('bin2h', 'bin2h.cpp', native : true)
bin2h_gen = generator(bin2h, \
output: ['@PLAINNAME@.cpp'],
arguments : ['@INPUT@', '@PLAINNAME@', '@OUTPUT@'])
Bug#930874: [ERROR] Failed to locate cgroup mountpoints.
Package: ctop Version: 1.0.0-2 Severity: important anthony@Zia:~$ ctop [ERROR] Failed to locate cgroup mountpoints. But it's mounted, and being used: $ ls /sys/fs/cgroup/ cgroup.controllers cgroup.procscgroup.threads system.slice cgroup.max.depthcgroup.stat init.scope user.slice cgroup.max.descendants cgroup.subtree_control machine.slice Possibly ctop doesn't understand the cgroup2 unified hierarchy? -- System Information: Debian Release: 10.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (150, 'stable'), (100, 'experimental-debug'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ctop depends on: ii python3 3.7.3-1 ctop recommends no packages. ctop suggests no packages. -- no debconf information
Bug#928185: unblock: openjdk-11/11.0.3+7-4
Hi tony, On 20-06-2019 15:44, tony mancill wrote: > I interpret this exchange to mean that 11.0.3+7-5 is still the version > preferred by the OpenJDK Team and so have uploaded that, built against > buster and with distribution set the buster. > > Let me know if I misinterpreted and should upload with a different > version, and thank you for the discussion and patience with this one. The build on arm64 failed. Can you please investigate? https://buildd.debian.org/status/fetch.php?pkg=openjdk-11=arm64=11.0.3%2B7-5=1561082322=0 Paul signature.asc Description: OpenPGP digital signature
Bug#930872: tomcat9: CVE-2019-10072
Source: tomcat9 Version: 9.0.16-4 Severity: important Tags: security upstream Control: clone -1 -2 Control: reassign -2 src:tomcat8 8.5.39-1 Control: retitle -2 tomcat8: CVE-2019-10072 Hi, The following vulnerability was published for tomcat9. CVE-2019-10072[0]: | The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 | connection window exhaustion on write in Apache Tomcat versions | 9.0.0.M1 to 9.0.19 and 8.5.0 to 8.5.40 . By not sending WINDOW_UPDATE | messages for the connection window (stream 0) clients were able to | cause server-side threads to block eventually leading to thread | exhaustion and a DoS. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-10072 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10072 [1] https://lists.apache.org/thread.html/df1a2c1b87c8a6c500ecdbbaf134c7f1491c8d79d98b48c6b9f0fa6a@%3Cannounce.tomcat.apache.org%3E Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#930836: rt-tests FTCBFS: Missing architecture of dependency libnuma-dev
Control: tag -1 + pending Hello Helmut, On 6/21/19 3:59 PM, Helmut Grohne wrote: > On Fri, Jun 21, 2019 at 02:55:53PM +0200, Uwe Kleine-König wrote: >> On 6/21/19 1:36 PM, Nguyen Hoang Tung wrote: >>> rt-tests fails to cross build because its dependency, libnuma-dev:armhf, >>> is missing.Using armhf architecture of the dependency can solve this >>> problem. >> >> I'm pretty sure your patch is wrong. Goes your problem away if you >> replace DEB_BUILD_ARCH by DEB_TARGET_ARCH in debian/rules? > > What Nguyen Hoang Tung writes is mostly correct. The cross build fails > for armhf. Adding the dependency probably makes it succeed. > > http://crossqa.debian.net/src/rt-tests quite nicely shows the pattern. > The mipsen have the libnuma-dev dependency and they do cross. > > However that's not the intended solution. Clearly, someone intended > rt-tests to be built without numa support for armhf. Matching on > DEB_BUILD_ARCH is as wrong as DEB_TARGET_ARCH. The terms "build", "host" > and "target" are explained in man dpkg-architecture. Thanks for chiming in here. I changed it to DEB_HOST_ARCH now. > Also debian/rules is inconsistent with debian/control. Someone should > fix that up. e.g. ppc64 and x32 differ. I admit it's ugly, but without consequences as NUMA defaults to 1 in the cases that were not explicitly mentioned. Fixed en passant. See https://git.pengutronix.de/cgit/ukl/rt-tests/commit/?id=8f976d1680dd3bbdc434b1a8eab56226f5b66022 Best regards and thanks for your time, Uwe signature.asc Description: OpenPGP digital signature
Bug#930671: libauthen-radius-perl: most basic usage stopped working
On Thu, 20 Jun 2019 16:55:18 +0300, Niko Tyni wrote:
> Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=129869
> I've reported this upstream with the attached proposed patch.
> Will wait a bit before applying the patch for Debian in case upstream
> has comments.
Upstream has now closed the CPAN RT ticket and released a 0.31
version which fixes the issue (differently).
I've "backported" the fix (i.e. took most of the 0.31 diff and added
it as a quilt patch) and pushed it to git. For convenience I'm also
attaching the patch here.
Feri, could you try this patch as well so that we can be sure that it
works before we proceed with an upload and unblock request?
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Joan Baez: Suzanne
Description: Fixed check_pwd() method when dictionaries are not loaded
and attribute ID is used instead of Name.
.
Backported from upstream release 0.31
Origin: https://metacpan.org/source/PORTAONE/Authen-Radius-0.31
Bug: https://rt.cpan.org/Ticket/Display.html?id=129869
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=129869
Bug-Debian: https://bugs.debian.org/930671
Author: porta...@cpan.org
Reviewed-by: gregor herrmann
Last-Update: 2019-06-21
--- a/Radius.pm
+++ b/Radius.pm
@@ -184,6 +184,9 @@
sub send_packet {
my ($self, $type, $retransmit) = @_;
+
+$self->{attributes} //= '';
+
my $data;
my $length = 20 + length($self->{attributes});
@@ -554,7 +557,7 @@
sub get_attributes {
my $self = shift;
my ( $vendor, $vendor_id, $name, $id, $length, $value, $type, $rawvalue, $tag, @a );
-my ($attrs) = $self->{attributes};
+my $attrs = $self->{attributes} // '';
$self->set_error;
@@ -598,12 +601,13 @@
my ($attr) = @_;
if (defined $attr->{'Vendor'}) {
return ($dict_vendor_name{ $attr->{'Vendor'} }{'id'} // int($attr->{'Vendor'}));
-} else {
+} elsif (exists $dict_name{$attr->{'Name'}} ) {
# look up vendor by attribute name
my $vendor_name = $dict_name{$attr->{'Name'}}{'vendor'} or return NO_VENDOR;
my $vendor_id = $dict_vendor_name{$vendor_name}{'id'} or return NO_VENDOR;
return $vendor_id;
}
+return NO_VENDOR;
}
sub _encode_enum {
@@ -847,7 +851,7 @@
sub add_attributes {
my ($self, @attr) = @_;
-my ($a, $vendor, $id, $type, $value);
+my ($a, $vendor, $id, $type, $value, $need_tag);
my @a = ();
$self->set_error;
@@ -862,7 +866,11 @@
$attr_name = $1;
}
-die 'unknown attr name '.$attr_name if (! exists $dict_name{$attr_name});
+if (! exists $dict_name{$attr_name}) {
+# no dictionaries loaded, $attr_name must be attribute ID
+push @a, $attr;
+next;
+}
$id = $dict_name{$attr_name}{id} // int($attr_name);
$vendor = vendorID($attr);
@@ -892,10 +900,21 @@
}
for $a (@a) {
-$id = $dict_name{ $a->{Name} }{id} // int($a->{Name});
-$type = $a->{Type} // $dict_name{ $a->{Name} }{type};
-$vendor = vendorID($a);
-my $need_tag = (defined $a->{Tag}) || $dict_name{ $a->{Name} }{has_tag};
+if (exists $dict_name{ $a->{Name} }) {
+my $def = $dict_name{ $a->{Name} };
+$id = $def->{id};
+# allow to override Type (why?)
+$type = $a->{Type} // $def->{type};
+$need_tag = $a->{Tag} // $def->{has_tag};
+}
+else {
+# ID must be a value for Name
+$id = int($a->{Name});
+$type = $a->{Type};
+$need_tag = $a->{Tag};
+}
+
+# we do not support 0 value for Tag
if ($need_tag) {
$a->{Tag} //= 0;
if ($a->{Tag} < 1 || $a->{Tag} > 31) {
@@ -904,12 +923,15 @@
}
}
+$vendor = vendorID($a);
if ($vendor eq WIMAX_VENDOR) {
-# WiMAX uses non-standard VSAs - include the continuation byte
+#TODO WiMAX uses non-standard VSAs - include the continuation byte
}
unless (defined($value = $self->_encode_value($vendor, $id, $type, $a->{Name}, $a->{Value}, $a->{Tag}))) {
-print STDERR "Unable to encode attribute $a->{Name} ($id, $type, $vendor) with value '$a->{Value}'\n" if $debug;
+printf STDERR "Unable to encode attribute %s (%s, %s, %s) with value '%s'\n",
+$a->{Name}, $id // '?', $type // '?', $vendor, $a->{Value}
+if $debug;
next;
}
@@ -1337,7 +1359,9 @@
'C', 'C', 'C' or 'C'. The C may be
Vendor's name from the dictionary or their integer id. For tagged attributes
(RFC2868) tag can be specified in C using 'Name:Tag' format, or by
-using C pair. TAG value is
Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3
Control: retitle -1 unblock: ghc/8.4.4+dfsg1-3 Hi Ilias, On 20-06-2019 04:20, Ilias Tsitsimpis wrote: > Attached is the updated file. Scheduling as we speak. Can you please keep an eye on it and ping this bug if you spot something not going well or when everything is finished? It's unclear to me how I should track that properly. Paul signature.asc Description: OpenPGP digital signature
Bug#930871: arbtt: unsupported tags leads to error
Package: arbtt Version: 0.10.1-1 Severity: important arbtt seems to have written data which it is unable to read back for me: $ arbtt-stats -t Processing data [===>.] 11%arbtt-stats: Unsupported TimeLogEntry version tag 0 CallStack (from HasCallStack): error, called at src/Data.hs:90:15 in main:Data I'm unable to get it to output anything from the stream, it always stops at what seems to be the same place. Versions of packages arbtt depends on: ii libatomic18.3.0-6 ii libc6 2.28-10 ii libffi6 3.2.1-9 ii libgmp10 2:6.1.2+dfsg-4 ii libpcre3 2:8.39-12 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.4-2 ii libxrandr22:1.5.1-1 ii libxss1 1:1.2.3-1 -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#930687: unblock: rdesktop/1.8.6-2
Hi László, On 18-06-2019 18:19, László Böszörményi (GCS) wrote: > The debdiff is a bit large, but hopefully can be accepted for Buster. Unblocked because of the security team position. Thanks. Paul signature.asc Description: OpenPGP digital signature
Bug#930868: apt-cacher-ng: cron.daily script always fails with 502 Connection closed
Hallo,
* Steven Monai [Fri, Jun 21 2019, 10:13:47AM]:
> Package: apt-cacher-ng
> Version: 3.2-2
> Severity: normal
>
> Dear Maintainer,
>
> I am running apt-cacher-ng on buster. Fairly recently, I began to receive
> daily emails from cron with the following body:
>
>
> /etc/cron.daily/apt-cacher-ng:
> Error: cannot fetch
> http://localhost:3142/acng-report.html?doExpire=Start+Expiration=aOe,
> HTTP/1.1 502 Connection closed
> run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 2
>
>
> I have tried running a cache cleanup via the web interface
> http://myhost:3142/ .
> No good.
>
> I have also tried purging apt-cacher-ng, and then reinstalling, thinking
> that clearing the cache and resetting all configuration would solve the
> problem. No good.
>
> So I am at a loss. Somehow, the daily cron script for apt-cacher-ng now
> always fails, and it seems there is no way to fix it. Even purging the
> package, which should remove all state related to apt-cacher-ng, does not
> solve it. This suggests to me that something else on my server is breaking
> the cron script. But what could that be?
>
> I am running shorewall firewall, and I use /etc/{hosts.allow,hosts.deny}
> to limit network access to the proxy that apt-cacher-ng provides, but
> those have never caused an issue like this before.
>
> Any guidance would be appreciated.
Uhm, maybe some application (syscall) firewall. Is apparmor in the game?
Can you enter the web interface from a browser and run password-protected
tasks there?
Otherwise, time to dig in the mud:
First, set the Debug option in the config. 7 should do.
Also disable the password temporarily, in security.conf (restore later).
Call that URL from shell environment (with quotes due to &, of course).
Does this work?
If not, strace it. What happens with the connect call?
Also observe the daemon: strace -f -p $(pidof apt-cacher-ng)
Eventually check /var/log/apt-cacher-ng/apt-cacher.err for further
clues.
Please report whether this investigation provided you with any useful
inspiration.
Good luck!
Eduard.
--
ja dann gib mal bitte ne addy
Eine die kewl funzen tut?
jupp
Bug#930869: Don't release with buster
Am 21.06.19 um 20:05 schrieb Adam Borowski: > On Fri, Jun 21, 2019 at 07:42:00PM +0200, Michael Biebl wrote: >> Package: pm-utils >> Version: 1.4.1-18 >> Severity: serious >> >> As former maintainer of pm-utils, I don't want to see pm-utils released >> with buster. >> pm-utils is a set of hacks/scripts which back in the days were necessary >> to successfully suspend/hibernate your system. > > But, do we even have an alternative for suspending remotely? What do you mean by that? > Until that is present, pm-utils is needed -- and even then, it should > preferably be replaced by wrappers, not removed. > Not really, pm-utils is not needed. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930804: linux-image-4.19.0-5-amd64: After kernel upgrade the nvidia driver doesn't load.
Control: forcemerge 930743 -1 This is fixed in version 4.19.37-5. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Bug#930428: debootstrap should ensure matching _apt uid
On Thu, 2019-06-20 at 20:33 +0200, Philipp Kern wrote: > On 20/06/2019 09:50, Ansgar Burchardt wrote: > > Ansgar Burchardt writes: > > > (I don't maintain debootstrap.) > > > > > > I don't think it is a good idea to require debootstrap to know about > > > such details. > > > > > > For limiting network access, I would recommend instead using network > > > namespaces (to only provide limited network access for all processes) > > > and/or user namespaces (if filtering for single UIDs is really needed). > > > These do not require any uids to match between in- and outside. > > > > And sadly the submitter's address bounced my mail as the mail provider > > the submitter uses cannot parse RFC-5321 mail addresses correctly. > > Well, you can use -submitter@ if you already know that your domain is > problematic. Even re-reading the RFC I'm not sure why that's a bug. RFC > 5321 references RFC 1035's definition of the label, which specifies that > a needs to be first in the label. [...] No, RFC 1035 says that starting each label with a letter "will result in fewer problems with many applications". But RFC 1123 says a label *can* begin with a digit, and that there is no ambiguity with IP literals because TLDs start with a letter. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Bug#930870: schleuder: fails to handle mails with protected headers as produced by Mutt 1.12.0
Package: schleuder Version: 3.4.0-1 Severity: important Tags: fixed fixed-upstream pending Forwarded: https://0xacab.org/schleuder/schleuder/issues/430 Mutt 1.12.0, which was recently released, introduced protected headers. These headers are just contained within the plain body of a mail produced by Mutt, they are not further wrapped into a specifically marked MIME-part. Schleuder fails to handle such messages. A fix addressing this issue is available upstream. Cheers, Georg signature.asc Description: PGP signature
Bug#863046: crash in menu->client
it's a problem in libjsoncpp library please archive the issue but marked that any other changes in libjsoncpp can again produce same error: https://bugs.debian.org/733974 i if dessire can be archived, but i thing (due debvian does not use the build in jsoncpp of minetest sources) must be take in more carefully i made packages for those people that need solution over current instllation THAT CANNOT BE UPGRADE DUE HARDWARE ARE NOT SUPPORTED BY NEWER KERNEL, also due Debian are too bussines-protocol complicated (several years later i must find the bug mby myselft event play the game) current: ttps://build.opensuse.org/project/show/home:vegnuli:minetest in future i'll move it to https://build.opensuse.org/project/show/home:vegnuli:games Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#923871: [Pkg-acpi-devel] Bug#923871: acpid: please provide runscript file
On Fri, 2019-06-21 at 10:17 +, Dmitry Bogatov wrote: > [ You replied in private, I took liberty to put BTS back into CC ] And what or who gave you the right to put my private comments into the public BTS? At the very least this is very rude, especially given that you did it on purpose. > > Feel free to upload directly, or if you want, fully take over the > > package. As it stands the package is essentially orphaned as I have > > neither the time not the usage for it anymore. I was thinking of > > officially orphaning it after the release. > > Thank you for your response. > > If you are positive on orphaning package, probably filing Orphan bug > right now would simplify some things: my upload would additionally > reassign maintenance to QA group. Please read what I wrote. There is a reason why I want to do this *after* the release. > I think it is very important for orphaned packages have QA group as > maintainer, otherwise it could scare away prospective new maintainer. Thanks for the lecture. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#930869: Don't release with buster
On Fri, Jun 21, 2019 at 07:42:00PM +0200, Michael Biebl wrote: > Package: pm-utils > Version: 1.4.1-18 > Severity: serious > > As former maintainer of pm-utils, I don't want to see pm-utils released > with buster. > pm-utils is a set of hacks/scripts which back in the days were necessary > to successfully suspend/hibernate your system. But, do we even have an alternative for suspending remotely? Until that is present, pm-utils is needed -- and even then, it should preferably be replaced by wrappers, not removed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ⢿⡄⠘⠷⠚⠋⠀ ./configure --host=zx-spectrum --build=pdp11 ⠈⠳⣄
Bug#926691: python-rsa: Missing manpages for binaries
Hi, attached a version, that does not scribble my name into each manpage. python-rsa-manpages.tar.gz Description: application/tgz
Bug#930869: Don't release with buster
Package: pm-utils Version: 1.4.1-18 Severity: serious As former maintainer of pm-utils, I don't want to see pm-utils released with buster. pm-utils is a set of hacks/scripts which back in the days were necessary to successfully suspend/hibernate your system. Nowadays, those hacks do more more harm then good. Upstream is dead for years, so there is no-one around anymore to update the software to drop all the hacks that are no longer necessary. In its current state, we would do a disservice to our users, if we released the software with buster. -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pm-utils depends on: pn powermgmt-base Versions of packages pm-utils recommends: ii ethtool 1:4.19-1 pn hdparm ii kbd 2.0.4-4 ii procps 2:3.3.15-2 pn vbetool Versions of packages pm-utils suggests: pn cpufrequtils pn radeontool ii wireless-tools 30~pre9-13
Bug#930868: apt-cacher-ng: cron.daily script always fails with 502 Connection closed
Package: apt-cacher-ng
Version: 3.2-2
Severity: normal
Dear Maintainer,
I am running apt-cacher-ng on buster. Fairly recently, I began to receive
daily emails from cron with the following body:
/etc/cron.daily/apt-cacher-ng:
Error: cannot fetch
http://localhost:3142/acng-report.html?doExpire=Start+Expiration=aOe,
HTTP/1.1 502 Connection closed
run-parts: /etc/cron.daily/apt-cacher-ng exited with return code 2
I have tried running a cache cleanup via the web interface http://myhost:3142/ .
No good.
I have also tried purging apt-cacher-ng, and then reinstalling, thinking
that clearing the cache and resetting all configuration would solve the
problem. No good.
So I am at a loss. Somehow, the daily cron script for apt-cacher-ng now
always fails, and it seems there is no way to fix it. Even purging the
package, which should remove all state related to apt-cacher-ng, does not
solve it. This suggests to me that something else on my server is breaking
the cron script. But what could that be?
I am running shorewall firewall, and I use /etc/{hosts.allow,hosts.deny}
to limit network access to the proxy that apt-cacher-ng provides, but
those have never caused an issue like this before.
Any guidance would be appreciated.
Thanks,
-S.M.
-- Package-specific info:
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apt-cacher-ng depends on:
ii adduser3.118
ii debconf [debconf-2.0] 1.5.71
ii dpkg 1.19.7
ii libbz2-1.0 1.0.6-9
ii libc6 2.28-10
ii libgcc11:8.3.0-6
ii liblzma5 5.2.4-1
ii libssl1.1 1.1.1c-1
ii libstdc++6 8.3.0-6
ii libsystemd0241-5
ii libwrap0 7.6.q-28
ii lsb-base 10.2019051400
ii zlib1g 1:1.2.11.dfsg-1
apt-cacher-ng recommends no packages.
Versions of packages apt-cacher-ng suggests:
pn avahi-daemon
pn doc-base
ii libfuse2 2.9.9-1
-- debconf information:
apt-cacher-ng/bindaddress: keep
apt-cacher-ng/cachedir: keep
apt-cacher-ng/port: keep
* apt-cacher-ng/tunnelenable: false
apt-cacher-ng/gentargetmode: No automated setup
apt-cacher-ng/proxy: keep
Bug#930858: throw out GNU tar, too. And binutils.
> "Crash confirmed. Buthis program is not expected to be able to deal > with arbitrarily broken input. All I'm going to do about it is add a > SIGSEGV handler." > here we have an upstream maintainer explicitly saying that an > image-processing program is not suitable for use on arbitrary input So what about GNU tar where restoring an untrusted tarball, _or_ restoring a tarball as root when an user who owns any files contained within the tarballs is logged on, is not supported either? Or, btrfs-receive with the same problem (but at least you _can_ do it securely as an user, with an unobvious and still poorly documented way). Or, binutils that can't be used to analyze untrusted input either? Sometimes input validation would massively extend the amount of tuits needed, beyond the author's resources. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#930687: unblock: rdesktop/1.8.6-2
On Tue, Jun 18, 2019 at 06:19:33PM +0200, László Böszörményi (GCS) wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hi Release Team, > > There's several security issues fixed with rdesktop 1.8.6 and while it > has some regressions, I've backported the needed fixes for the -2 > package version. > As upstream notes: "This is a security release to address various > buffer overflow and overrun issues in the rdesktop protocol handling. > rdesktop will now detect any attempts to access invalid areas and > refuse to continue. Users are adviced to upgrade as soon as possible." > > The debdiff is a bit large, but hopefully can be accepted for Buster. JFTR, we'll likely also rebase stretch to that version (we did similarly for 1.8.4 in a previous DSA). Cheers, Moritz
Bug#930867: unblock: libvirt/5.0.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libvirt It fixes 4 CVEs and adds an apparmor rule to make the life of people using spice with certificates easier. Cheers, -- Guido unblock libvirt/5.0.0-4 -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#335791: Present in Stretch
On Thu, 3 Nov 2011 21:50:31 -0700 Isaac Dunham wrote: > It looks like this has not been fixed; I'm getting the same error under a > fully updated squeeze. > > -- > Isaac Dunham > > still present on debian stretch im cc: to Kim F. Storm, maybe can help to add a simple patch to reeplace the code to get the domain. Saludos! -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar
Bug#930866: sshguard: Either VCS fields are outdated or git repository is not uptodate
Package: sshguard Version: 2.3.1-1 Severity: normal apt-get source sshguard recommends getting it from https://salsa.debian.org/debian/sshguard.git but the last commit there is old, version 1.7.1 related. Could you please either update/remove the VCS field, or push to the git repository on salsa. Thanks Norbert -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.1.12 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sshguard depends on: ii libc6 2.28-10 ii lsb-base 10.2019051400 Versions of packages sshguard recommends: ii nftables 0.9.0-2 sshguard suggests no packages.
Bug#930858: gif2png: "not expected to be able to deal with arbitrarily broken input"
On Fri, Jun 21, 2019 at 02:58:00PM +0100, Colin Watson wrote: > At the very least, the limitation that this program cannot safely be > used with untrusted input needs to be prominently documented (I'd > suggest the package description and the manual page). web2png would be > harder to replace this way, but at least people wanting to make > straightforward use of gif2png should perhaps be advised to use some > other image processing system instead whose maintainers have a more > reasonable approach to reports of undefined behaviour in their programs. Thanks for reporting this! Let's just remove the package, we have properly maintained (and heavily fuzzed) alternatives like imagemagick/graphicsmagick's convert and web2png seems to be entirely a fringe use case. Cheers, Moritz
Bug#930862: [Pkg-dpdk-devel] Bug#930862: Please correctly expose dpdk includes and libs
On Fri, 2019-06-21 at 16:41 +0200, Thomas Goirand wrote: > Package: libdpdk-dev > Severity: important > > Hi, > > I tried to build OpenVSwitch with dpdk support in Debian, trying to > converge with the Ubuntu package, to ease compatibility and all. > However, I discovered that the issue in Debian is the DPDK package > itself, which isn't exposing itself correctly. Here's the output > of the ./configure --with-dpdk when it fails: > > --- SNIP --- > > checking for DPDK... yes > checking for library containing get_mempolicy... -lnuma > configure: error: Could not find DPDK library in default search path, > Use --with-dpdk to specify the DPDK library installed in non-standard > location > make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 1 > > --- SNAP --- > > To me, it just looks like DPDK isn't packaged to the right folder. > If you want to try yourself, you can attempt to build what's in > the Git here: > > I've pushed the dpdk support of OVS into a debian/with-dpdk-support. > > If there's a way to fix the Debian build with a parameter to > --with-dpdk, please let me know, but as much as I tried, there's > simply no way to fix without modifying the dpdk package. > > I'll try to see how I can fix the DPDK package and see if I can > send you a patch, though I haven't figured out how to do this yet. > > Cheers, > > Thomas Goirand (zigo) Hi, Thanks for working on OVS. You need a version of OVS that supports pkg-config. Myself and Christian fixed that upstream a number of months ago, although I cannot remember which version the fixes are in. The older versions are looking for a linker script (libdpdk.so) which doesn't exist anymore upstream. Note that dpdk is exactly the same in Debian and Ubuntu - we jointly maintain it from the same source base. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#930865: unblock: bochs/2.6.9+dfsg-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, Please unblock package bochs It adds a couple of missing files which are required for some features added for Buster. (#930770.) diff --git a/debian/bochs.install b/debian/bochs.install index 3574eb6..ba50552 100644 --- a/debian/bochs.install +++ b/debian/bochs.install @@ -6,6 +6,7 @@ usr/lib/bochs/plugins/libbx_biosdev.so* usr/lib/bochs/plugins/libbx_busmouse.so* usr/lib/bochs/plugins/libbx_cmos.so* usr/lib/bochs/plugins/libbx_dma.so* +usr/lib/bochs/plugins/libbx_e1000.so* usr/lib/bochs/plugins/libbx_es1370.so* usr/lib/bochs/plugins/libbx_eth_*.so* usr/lib/bochs/plugins/libbx_extfpuirq.so* @@ -33,6 +34,7 @@ usr/lib/bochs/plugins/libbx_svga_cirrus.so* usr/lib/bochs/plugins/libbx_unmapped.so* usr/lib/bochs/plugins/libbx_usb_*.so* usr/lib/bochs/plugins/libbx_vga.so* +usr/lib/bochs/plugins/libbx_voodoo.so* usr/share/bochs/keymaps usr/share/man/man1/bochs.1.gz usr/share/man/man5/bochsrc.5.gz diff --git a/debian/changelog b/debian/changelog index 49ef391..03212f7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +bochs (2.6.9+dfsg-3) unstable; urgency=medium + + * Ship the Voodoo and e1000 plugins; thanks to Christian Ehrhardt for +the patch. Closes: #930770. LP: #1830094. + + -- Stephen Kitt Thu, 20 Jun 2019 10:37:44 +0200 + bochs (2.6.9+dfsg-2) unstable; urgency=medium * Discard .note.gnu.property section explicitly when building BIOS ROM unblock bochs/2.6.9+dfsg-3 Regards, Stephen -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#930864: unblock: bind9/1:9.11.5.P4+dfsg-5.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi
Please unblock package bind9 (it builds udeb's so would need an ack
from kibi as well). It fixes CVE-2019-6471, #930746 ("A race condition
when discarding malformed packets can cause BIND to exit with an
assertion failure").
I realize this is very short before the last date possible for unblock
requests.
unblock bind9/1:9.11.5.P4+dfsg-5.1
Regards,
Salvatore
diff -Nru bind9-9.11.5.P4+dfsg/debian/changelog
bind9-9.11.5.P4+dfsg/debian/changelog
--- bind9-9.11.5.P4+dfsg/debian/changelog 2019-05-03 19:44:57.0
+0200
+++ bind9-9.11.5.P4+dfsg/debian/changelog 2019-06-21 11:24:31.0
+0200
@@ -1,3 +1,11 @@
+bind9 (1:9.11.5.P4+dfsg-5.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * move item_out test inside lock in dns_dispatch_getnext() (CVE-2019-6471)
+(Closes: #930746)
+
+ -- Salvatore Bonaccorso Fri, 21 Jun 2019 11:24:31 +0200
+
bind9 (1:9.11.5.P4+dfsg-5) unstable; urgency=medium
* AppArmor: Allow /var/tmp/krb5_* (owner-only) for Samba AD DLZ.
diff -Nru
bind9-9.11.5.P4+dfsg/debian/patches/0015-move-item_out-test-inside-lock-in-dns_dispatch_getne.patch
bind9-9.11.5.P4+dfsg/debian/patches/0015-move-item_out-test-inside-lock-in-dns_dispatch_getne.patch
---
bind9-9.11.5.P4+dfsg/debian/patches/0015-move-item_out-test-inside-lock-in-dns_dispatch_getne.patch
1970-01-01 01:00:00.0 +0100
+++
bind9-9.11.5.P4+dfsg/debian/patches/0015-move-item_out-test-inside-lock-in-dns_dispatch_getne.patch
2019-06-21 11:24:31.0 +0200
@@ -0,0 +1,56 @@
+From: Mark Andrews
+Date: Tue, 19 Mar 2019 14:14:21 +1100
+Subject: move item_out test inside lock in dns_dispatch_getnext()
+Origin:
https://gitlab.isc.org/isc-projects/bind9/commit/3a9c7bb80d4a609b86427406d9dd783199920b5b
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-6471
+Bug-Debian: https://bugs.debian.org/930746
+
+(cherry picked from commit 60c42f849d520564ed42e5ed0ba46b4b69c07712)
+---
+ lib/dns/dispatch.c | 12
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c
+index 408beda3679d..3278db4a07c2 100644
+--- a/lib/dns/dispatch.c
b/lib/dns/dispatch.c
+@@ -134,7 +134,7 @@ struct dns_dispentry {
+ isc_task_t *task;
+ isc_taskaction_taction;
+ void *arg;
+- boolitem_out;
++ boolitem_out;
+ dispsocket_t*dispsocket;
+ ISC_LIST(dns_dispatchevent_t) items;
+ ISC_LINK(dns_dispentry_t) link;
+@@ -3422,13 +3422,14 @@ dns_dispatch_getnext(dns_dispentry_t *resp,
dns_dispatchevent_t **sockevent) {
+ disp = resp->disp;
+ REQUIRE(VALID_DISPATCH(disp));
+
+- REQUIRE(resp->item_out == true);
+- resp->item_out = false;
+-
+ ev = *sockevent;
+ *sockevent = NULL;
+
+ LOCK(>lock);
++
++ REQUIRE(resp->item_out == true);
++ resp->item_out = false;
++
+ if (ev->buffer.base != NULL)
+ free_buffer(disp, ev->buffer.base, ev->buffer.length);
+ free_devent(disp, ev);
+@@ -3573,6 +3574,9 @@ dns_dispatch_removeresponse(dns_dispentry_t **resp,
+ isc_task_send(disp->task[0], >ctlevent);
+ }
+
++/*
++ * disp must be locked.
++ */
+ static void
+ do_cancel(dns_dispatch_t *disp) {
+ dns_dispatchevent_t *ev;
+--
+2.20.1
+
diff -Nru bind9-9.11.5.P4+dfsg/debian/patches/series
bind9-9.11.5.P4+dfsg/debian/patches/series
--- bind9-9.11.5.P4+dfsg/debian/patches/series 2019-05-03 19:44:57.0
+0200
+++ bind9-9.11.5.P4+dfsg/debian/patches/series 2019-06-21 11:24:31.0
+0200
@@ -12,3 +12,4 @@
0012-CVE-2018-5743-Limiting-simultaneous-TCP-clients-is-i.patch
0013-Replace-atomic-operations-in-bin-named-client.c-with.patch
0014-Disable-broken-Ed448-support.patch
+0015-move-item_out-test-inside-lock-in-dns_dispatch_getne.patch
Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"
Sean Whitton dijo [Fri, Jun 21, 2019 at 02:36:05PM +0100]: > My reading of the conclusion to #904558 is that the recommendation to > form a working group is a recommendation that can be directed only to > the developer body as a whole, not to the Policy process. That's > because actually implementing in the archive some new mechanism for > maintscripts is a prerequisite to any Policy change requiring packages > to use that new mechanism. In other words, what the working group would > be tasked with doing is beyond the scope of the Policy process. We do > design work as part of the Policy process, but we don't write code. > > Assuming that the T.C.'s recommendation is the right way to proceed > here, and someone doesn't come up with any other way to unblock things, > the wontfix+stalled status will remain until and unless the working > group actually forms, designs and implements something, and starts using > it in the archive. There is no role for the Policy process (and thus no > role for the Policy Editors qua Policy Editors) until that occurs. > > So, by all means insist on the recommendation, but so far as I can tell > that's something which does not involve either the Policy process or the > T.C., but simply the body of Debian contributors qua contributors. I completely agree with you - My idea to kickstart this at DC19 is not for TC and Policy Editors leading a session, but rather us (as individuals) expressing the issue at a BoF trying to get more eyeballs (and, more important, more brains) on it. > Stepping back a bit, tagging this bug wontfix+stalled is part of the > broader attempts, in which the Policy Editors are engaged, to more > sharply delineate the boundaries of the Policy process. We want to get > to the point where the only bugs that we have listed are either > highly actionable, or tagged wontfix. For a bug to be highly actionable > is for it to be the case that someone with enough time and background > knowledge can sit down, think through the problem, and come up with at > least a first version of a change proposal. > > I think that a large number of very-difficult-to-action bugs strongly > discourages people from getting involved. It makes Policy seem like a > sprawling, unmanageable morass of difficult problems. That isn't how > things are, because while there are indeed a lot of hard problems, they > are largely independent of each other, and tackling individual > debian-policy bugs really does improve Debian. However, it is much > harder to see that when half of the open bugs are more than five years > old yet not tagged wontfix. Right. This is a bug where I was quite happy that the TC decided to declare it outside of its functions - And it is just fitting that it's outside the Policy as well. We don't have a commonly implemented practice to document / show / follow. This should go to the developer body at large. signature.asc Description: PGP signature
Bug#928631: Question
Can I confirm that this is a problem with AMD graphics only--or will this affect all systems regardless of Video card type?
Bug#930863: RM: synphot-data [all] -- RoM; obsolete arch:all package
Package: ftp.debian.org Severity: normal Please remove the synphot-data package from contrib, since it is no longer built by src:pysynphot. Thanks Ole
Bug#930862: Please correctly expose dpdk includes and libs
Package: libdpdk-dev Severity: important Hi, I tried to build OpenVSwitch with dpdk support in Debian, trying to converge with the Ubuntu package, to ease compatibility and all. However, I discovered that the issue in Debian is the DPDK package itself, which isn't exposing itself correctly. Here's the output of the ./configure --with-dpdk when it fails: --- SNIP --- checking for DPDK... yes checking for library containing get_mempolicy... -lnuma configure: error: Could not find DPDK library in default search path, Use --with-dpdk to specify the DPDK library installed in non-standard location make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 1 --- SNAP --- To me, it just looks like DPDK isn't packaged to the right folder. If you want to try yourself, you can attempt to build what's in the Git here: I've pushed the dpdk support of OVS into a debian/with-dpdk-support. If there's a way to fix the Debian build with a parameter to --with-dpdk, please let me know, but as much as I tried, there's simply no way to fix without modifying the dpdk package. I'll try to see how I can fix the DPDK package and see if I can send you a patch, though I haven't figured out how to do this yet. Cheers, Thomas Goirand (zigo)
Bug#672369: "FIXME: MISSING XINCLUDE CONTENT" in reference manual
Control: tags 672369 - jessie stretch fixed-upstream Control: forwarded 672369 https://gitlab.gnome.org/GNOME/gtk/issues/723 On Fri, 21 Jun 2019 at 13:48:06 +, Debian Bug Tracking System forwarded: > > # PRETTY_NAME="Debian GNU/Linux 9 (stretch)" > > tags 672369 + stretch > Bug #672369 [libgtk-3-doc] "FIXME: MISSING XINCLUDE CONTENT" in reference > manual > Added tag(s) stretch. This appears to still be present in buster/sid, which means that instead of adding more suite-specific tags, we should remove the suite-specific tags and let the bug tracking system's version tracking capabilities work out which suites have the bug (the answer is: all of them). There is a patch upstream, although it's a couple of years old and might not be directly applicable to current upstream source code. The bug tracking system thought this had been fixed upstream, but that was incorrect: the upstream bug was closed when upstream bug tracking migrated to Gitlab. If you are interested in fixing this, testing the patch that was sent upstream and converting it into a merge request would be very useful. smcv
Bug#930154: inkscape: extension-error-log complaint. An improper .inx file?
On Fri 21/Jun/2019 15:53:49 +0200 Mattia Rizzolo wrote: > But as I mentioned, those messages are completely harmless, so you can > safely ignore these errors. In fact, the misbehavior I was after turned out to be unrelated. Thank you anyway. Best Ale signature.asc Description: OpenPGP digital signature
Bug#930861: vanessa-adt FTCBFS: does not pass --host to ./configure
Source: vanessa-adt Version: 0.0.9-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs vanessa-adt fails to cross build from source, because it does not pass --host to ./configure. The easiest way of fixing that - using dh_auto_configure - makes vanessa-adt cross buildable. Please consider applying the attached patch. Helmut diff -u vanessa-adt-0.0.9/debian/changelog vanessa-adt-0.0.9/debian/changelog --- vanessa-adt-0.0.9/debian/changelog +++ vanessa-adt-0.0.9/debian/changelog @@ -1,3 +1,10 @@ +vanessa-adt (0.0.9-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1) + + -- Helmut Grohne Fri, 21 Jun 2019 16:05:17 +0200 + vanessa-adt (0.0.9-2) unstable; urgency=medium * Use dh-autoreconf diff -u vanessa-adt-0.0.9/debian/rules vanessa-adt-0.0.9/debian/rules --- vanessa-adt-0.0.9/debian/rules +++ vanessa-adt-0.0.9/debian/rules @@ -3,7 +3,6 @@ # GNU copyright 1997 to 1999 by Joey Hess. pwd:=$(shell pwd) -cfg:=--prefix=/usr DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk @@ -14,7 +13,7 @@ build-stamp: dh_testdir dh_autoreconf - ./configure $(cfg) + dh_auto_configure $(MAKE) V=1 touch build-stamp
Bug#930802: Fwd: Bug#930802: nvidia-driver: NVIDIA module fails to load (Operation not permitted)
-- Forwarded message - From: floris Date: Fri, Jun 21, 2019 at 6:31 AM Subject: Re: Bug#930802: nvidia-driver: NVIDIA module fails to load (Operation not permitted) To: Ignacio Vargas Ignacio Vargas schreef op 2019-06-20 23:56: > Package: nvidia-driver > Version: 418.74-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Today upon boot up, Xorg failed to start. Checking logs I found it was > not picking up the NVIDIA propietary driver. > I tried reinstalling the nvidia-driver metapackage and rebooted - > module still failed to load. > > I attempted to load it manually to check the error message, and this > is what I got: > > $ sudo /sbin/modprobe -v nvidia > install modprobe -i nvidia-current $CMDLINE_OPTS > insmod /lib/modules/4.19.0-5-amd64/updates/dkms/nvidia-current.ko > modprobe: ERROR: could not insert 'nvidia_current': Invalid argument > modprobe: ERROR: ../libkmod/libkmod-module.c:979 command_do() Error > running install command for nvidia > modprobe: ERROR: could not insert 'nvidia': Operation not permitted > > I also checked the output of dkms > $ sudo dkms status > nvidia-current, 418.74, 4.19.0-5-amd64, x86_64: installed > > Similar information appears in the systemctl logs. > > Running the modprobe above without sudo gives me a “Key expired” > message on the nvidia module, which would suggest a > conflict with Secure Boot, but that is disabled on my BIOS (I’ve > double checked). I already tried booting on different > kernel versions (4.19.0-5, 4.19.0-4, 4.19.0-3) and all gave the same > error. > > As it stands, the package seems unusable in its current state. I had > to revert back to nouveau to get Xorg back up > for now. It had been working well up until yesterday, but I'm not sure > how to check aptitude's logs for a list of the > packages that were updated only yesterday. > > Regards, > Does $ sudo dpkg-reconfigure nvidia-kernel-dkms work? > It had been working well up until yesterday, but I'm not sure > how to check aptitude's logs for a list of the > packages that were updated only yesterday. check /var/log/apt/history.log --- Floris -- Ignacio Vargas
Bug#930802: Fwd: Bug#930802: nvidia-driver: NVIDIA module fails to load (Operation not permitted)
-- Forwarded message - From: Ignacio Vargas Date: Fri, Jun 21, 2019 at 8:35 AM Subject: Re: Bug#930802: nvidia-driver: NVIDIA module fails to load (Operation not permitted) To: floris I tried $ sudo dpkg-reconfigure nvidia-kernel-dkms and it completed successfully. Trying to load the module afterwards failed with the same error though. /var/log/apt/history.log reveals that these were the packages I updated the day before the breakage occurred: Upgrade: libkrb5-3:amd64 (1.17-2, 1.17-3), libkrb5-3:i386 (1.17-2, 1.17-3), libgssapi-krb5-2:amd64 (1.17-2, 1.17-3), libgssapi-krb5-2:i386 (1.17-2, 1.17-3), krb5-multidev:amd64 (1.17-2, 1.17-3), libkrb5-dev:amd64 (1.17-2, 1.17-3), linux-libc-dev:amd64 (4.19.37-3, 4.19.37-4), linux-libc-dev:i386 (4.19.37-3, 4.19.37-4), *linux-image-4.19.0-5-amd64:amd64 (4.19.37-3, 4.19.37-4)*, libkdb5-9:amd64 (1.17-2, 1.17-3), libk5crypto3:amd64 (1.17-2, 1.17-3), libk5crypto3:i386 (1.17-2, 1.17-3), linux-compiler-gcc-8-x86:amd64 (4.19.37-3, 4.19.37-4), krb5-locales:amd64 (1.17-2, 1.17-3), libkadm5srv-mit11:amd64 (1.17-2, 1.17-3), libkrb5support0:amd64 (1.17-2, 1.17-3), libkrb5support0:i386 (1.17-2, 1.17-3), libgssrpc4:amd64 (1.17-2, 1.17-3), linux-headers-4.19.0-5-amd64:amd64 (4.19.37-3, 4.19.37-4), firefox:amd64 (67.0.2-1, 67.0.3-1), linux-kbuild-4.19:amd64 (4.19.37-3, 4.19.37-4), libkadm5clnt-mit11:amd64 (1.17-2, 1.17-3), linux-headers-4.19.0-5-common:amd64 (4.19.37-3, 4.19.37-4) The only package that seemed related to the bug was the new kernels. So I updated again today Upgrade: linux-image-4.19.0-5-amd64:amd64 (4.19.37-4, 4.19.37-5), firefox:amd64 (67.0.3-2, 67.0.4-1) I rebooted, and the NVIDIA module was loaded automatically without problems or needing further intervention. I can only assume the bug was actually with the new kernels. Either way, the bug is solved. Sorry for the inconvenience, it seems like nvidia-driver wasn't at fault at all. On Fri, Jun 21, 2019 at 6:31 AM floris wrote: > Ignacio Vargas schreef op 2019-06-20 23:56: > > Package: nvidia-driver > > Version: 418.74-1 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > > > Today upon boot up, Xorg failed to start. Checking logs I found it was > > not picking up the NVIDIA propietary driver. > > I tried reinstalling the nvidia-driver metapackage and rebooted - > > module still failed to load. > > > > I attempted to load it manually to check the error message, and this > > is what I got: > > > > $ sudo /sbin/modprobe -v nvidia > > install modprobe -i nvidia-current $CMDLINE_OPTS > > insmod /lib/modules/4.19.0-5-amd64/updates/dkms/nvidia-current.ko > > modprobe: ERROR: could not insert 'nvidia_current': Invalid argument > > modprobe: ERROR: ../libkmod/libkmod-module.c:979 command_do() Error > > running install command for nvidia > > modprobe: ERROR: could not insert 'nvidia': Operation not permitted > > > > I also checked the output of dkms > > $ sudo dkms status > > nvidia-current, 418.74, 4.19.0-5-amd64, x86_64: installed > > > > Similar information appears in the systemctl logs. > > > > Running the modprobe above without sudo gives me a “Key expired” > > message on the nvidia module, which would suggest a > > conflict with Secure Boot, but that is disabled on my BIOS (I’ve > > double checked). I already tried booting on different > > kernel versions (4.19.0-5, 4.19.0-4, 4.19.0-3) and all gave the same > > error. > > > > As it stands, the package seems unusable in its current state. I had > > to revert back to nouveau to get Xorg back up > > for now. It had been working well up until yesterday, but I'm not sure > > how to check aptitude's logs for a list of the > > packages that were updated only yesterday. > > > > Regards, > > > > Does > $ sudo dpkg-reconfigure nvidia-kernel-dkms > work? > > > > It had been working well up until yesterday, but I'm not sure > > how to check aptitude's logs for a list of the > > packages that were updated only yesterday. > > check > /var/log/apt/history.log > > --- > Floris > -- Ignacio Vargas -- Ignacio Vargas
Bug#930860: linux-image-4.19.0-5-amd64: USB Camera seen as multiple devices
Subject: linux-image-4.19.0-5-amd64: USB Camera seen as multiple devices Package: src:linux Version: 4.19.37-3 Severity: normal Dear Maintainer, Under Debian 10 rc1, when I plug in my USB camera (the very common logitech c930e), 2 devices are added (e.g. /dev/video0 and /dev/video1). v4l-info works on /dev/video0, but fails on /dev/video1 (VIDIOC_G_FMT(VIDEO_CAPTURE): Invalid argument). When I try to access the device using gstreamer it tells me that /dev/video1 is not a capture device. In stretch I don't see this behavior. Attached are syslog, dmesg, v4l-info for both devices, udevadm for both devices, lsusb, lspci. Let me know if any other logs can be of help. -- Package-specific info: ** Version: Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=ad69d3ff-8ba0-4056-8b20-af76f97710d3 ro quiet ** Tainted: OE (12288) * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: [11617.258674] CPU1 is up [11617.258703] smpboot: Booting Node 0 Processor 2 APIC 0x1 [11617.259262] cache: parent cpu2 should not be sleeping [11617.259628] CPU2 is up [11617.259651] smpboot: Booting Node 0 Processor 3 APIC 0x3 [11617.260174] cache: parent cpu3 should not be sleeping [11617.260383] CPU3 is up [11617.264501] ACPI: Waking up from system sleep state S3 [11617.288324] sd 3:0:0:0: [sda] Starting disk [11617.290109] nuvoton-cir 00:01: activated [11617.600757] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [11617.602296] ata4.00: configured for UDMA/133 [11617.602300] ahci :00:1f.2: port does not support device sleep [11617.837249] OOM killer enabled. [11617.837251] Restarting tasks ... [11617.838774] pci_bus :01: Allocating resources [11617.838798] pci_bus :02: Allocating resources [11617.840146] pci_bus :01: Allocating resources [11617.840170] pci_bus :02: Allocating resources [11617.854187] done. [11617.854476] PM: suspend exit [11617.994227] usb 1-2: new high-speed USB device number 22 using xhci_hcd [11618.054633] e1000e: enp0s25 NIC Link is Down [11618.073483] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready [11618.142428] usb 1-2: New USB device found, idVendor=413c, idProduct=1010, bcdDevice= 1.00 [11618.142430] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [11618.142431] usb 1-2: Product: USB 2.0 Hub [MTT] [11618.142969] hub 1-2:1.0: USB hub found [11618.143025] hub 1-2:1.0: 4 ports detected [11618.290319] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready [11618.430237] usb 1-2.1: new low-speed USB device number 23 using xhci_hcd [11618.534751] usb 1-2.1: New USB device found, idVendor=046d, idProduct=c016, bcdDevice= 3.40 [11618.534756] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [11618.534760] usb 1-2.1: Product: Optical USB Mouse [11618.534763] usb 1-2.1: Manufacturer: Logitech [11618.540272] input: Logitech Optical USB Mouse as /devices/pci:00/:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:046D:C016.000F/input/input42 [11618.540603] hid-generic 0003:046D:C016.000F: input,hidraw0: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on usb-:00:14.0-2.1/input0 [11618.618239] usb 1-2.4: new low-speed USB device number 24 using xhci_hcd [11618.726332] usb 1-2.4: New USB device found, idVendor=413c, idProduct=2110, bcdDevice=75.00 [11618.726338] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [11618.726341] usb 1-2.4: Product: Dell Wired Multimedia Keyboard [11618.726344] usb 1-2.4: Manufacturer: Dell [11618.739881] input: Dell Dell Wired Multimedia Keyboard as /devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/0003:413C:2110.0010/input/input43 [11618.798704] hid-generic 0003:413C:2110.0010: input,hidraw1: USB HID v1.10 Keyboard [Dell Dell Wired Multimedia Keyboard] on usb-:00:14.0-2.4/input0 [11618.809944] input: Dell Dell Wired Multimedia Keyboard Mouse as /devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.1/0003:413C:2110.0011/input/input44 [11618.810269] input: Dell Dell Wired Multimedia Keyboard System Control as /devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.1/0003:413C:2110.0011/input/input45 [11618.870430] input: Dell Dell Wired Multimedia Keyboard Consumer Control as /devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.1/0003:413C:2110.0011/input/input46 [11618.870712] hid-generic 0003:413C:2110.0011: input,hiddev0,hidraw2: USB HID v1.10 Mouse [Dell Dell Wired Multimedia Keyboard] on usb-:00:14.0-2.4/input1 [11624.976315] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [11624.976357] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready [11677.088792] PM: suspend entry (deep) [11677.088794] PM: Syncing filesystems ... done. [11677.100389] Freezing user space processes ... (elapsed 0.001 seconds) done. [11677.102331] OOM killer disabled. [11677.102332]
Bug#930859: firewalld changes zones order after service restart
Package: firewalld Version: 0.4.4.2-1 Almost each time I invoke “systemctl restart firewalld” zones in INPUT_ZONES_SOURCE have a different order. Because of that an access to a server can be broken. Detailed description can be found here: https://github.com/firewalld/firewalld/issues/166 The patch is available here: https://github.com/firewalld/firewalld/commit/7bbe82ef4ce391af68dfb5299d1c2b1f944b77be I am using Debian Stretch. asamusev@debian9:/home/asamusev# uname -a Linux lab-debian9-01 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux Best regards, Alexander Samusev
Bug#930836: rt-tests FTCBFS: Missing architecture of dependency libnuma-dev
Hi Uwe, On Fri, Jun 21, 2019 at 02:55:53PM +0200, Uwe Kleine-König wrote: > On 6/21/19 1:36 PM, Nguyen Hoang Tung wrote: > > rt-tests fails to cross build because its dependency, libnuma-dev:armhf, > > is missing.Using armhf architecture of the dependency can solve this > > problem. > > I'm pretty sure your patch is wrong. Goes your problem away if you > replace DEB_BUILD_ARCH by DEB_TARGET_ARCH in debian/rules? What Nguyen Hoang Tung writes is mostly correct. The cross build fails for armhf. Adding the dependency probably makes it succeed. http://crossqa.debian.net/src/rt-tests quite nicely shows the pattern. The mipsen have the libnuma-dev dependency and they do cross. However that's not the intended solution. Clearly, someone intended rt-tests to be built without numa support for armhf. Matching on DEB_BUILD_ARCH is as wrong as DEB_TARGET_ARCH. The terms "build", "host" and "target" are explained in man dpkg-architecture. TL;DR: sed -i -e s/DEB_BUILD_ARCH/DEB_HOST_ARCH/ debian/rules Also debian/rules is inconsistent with debian/control. Someone should fix that up. e.g. ppc64 and x32 differ. Helmut
Bug#903907: interest /usr/share/slib should be interest-noawait
Hey there, Ubuntu made that change a year ago without issue reported, attached debdiff in case that helps to consider doing the change in Debian as well? (it should simply the upgrader work and lower the delta without distro) Thanks for considering diff -Nru guile-2.2-2.2.4+1/debian/changelog guile-2.2-2.2.4+1/debian/changelog --- guile-2.2-2.2.4+1/debian/changelog 2019-06-02 18:17:15.0 +0200 +++ guile-2.2-2.2.4+1/debian/changelog 2019-06-05 10:14:39.0 +0200 @@ -1,3 +1,10 @@ +guile-2.2 (2.2.4+1-2ubuntu1) eoan; urgency=low + + * Merge from Debian unstable. Remaining changes: +- Convert triggers to noawait + + -- Gianfranco Costamagna Wed, 05 Jun 2019 10:14:39 +0200 + guile-2.2 (2.2.4+1-2) unstable; urgency=medium * Backport upstream fix for after-gc-hook test failures. Replace diff -Nru guile-2.2-2.2.4+1/debian/guile-libs.triggers guile-2.2-2.2.4+1/debian/guile-libs.triggers --- guile-2.2-2.2.4+1/debian/guile-libs.triggers2019-06-01 22:15:02.0 +0200 +++ guile-2.2-2.2.4+1/debian/guile-libs.triggers2019-06-03 12:27:22.0 +0200 @@ -1 +1 @@ -interest /usr/share/slib +interest-noawait /usr/share/slib
Bug#930858: gif2png: "not expected to be able to deal with arbitrarily broken input"
Package: gif2png Version: 2.5.8-1+b2 Severity: grave Tags: security Justification: user security hole I happened to notice the entry for 2.5.14 (which I realise is newer than the one in Debian) on http://www.catb.org/~esr/gif2png/NEWS: "Redirect segfault to a graceful exit. Tired of meaningless fuzzer bugs." This is from https://gitlab.com/esr/gif2png/issues/5, where the upstream maintainer says: "Crash confirmed. Buthis program is not expected to be able to deal with arbitrarily broken input. All I'm going to do about it is add a SIGSEGV handler." I understand that security vulnerabilities happen and that normally they are patched and life goes on. But this is a different case: here we have an upstream maintainer explicitly saying that an image-processing program is not suitable for use on arbitrary input, and explicitly adding code to defeat fuzzers that might otherwise help to find bugs in it. I'm honestly flabbergasted by this approach to what must surely be undefined behaviour in C code. I suppose that one might still safely use gif2png to convert one's own website if all it had to deal with was trusted images. However, this is an undocumented limitation, and it's quite easy to believe that unsuspecting people might try to use gif2png as part of a larger system where the input files cannot be trusted, such as an image-upload widget on a website. At the very least, the limitation that this program cannot safely be used with untrusted input needs to be prominently documented (I'd suggest the package description and the manual page). web2png would be harder to replace this way, but at least people wanting to make straightforward use of gif2png should perhaps be advised to use some other image processing system instead whose maintainers have a more reasonable approach to reports of undefined behaviour in their programs. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gif2png depends on: ii libc62.28-10 ii libpng16-16 1.6.36-6 Versions of packages gif2png recommends: ii python 2.7.16-1 gif2png suggests no packages. -- no debconf information Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#930154: inkscape: extension-error-log complaint. An improper .inx file?
Control: tag -1 confirmed On Fri, Jun 07, 2019 at 08:08:08PM +0200, Alessandro Vesely wrote: > I'm experiencing a strange behavior of Inkscape, and, trying to investigate, I > found an extension-errors.log which I attach. Thanks for bringing this up. > In fact, I have: … > Is that normal? Yes, it's normal and harmless, but we can still improve the situation. There are actually two separated errors in the log: > Extension "Sketch Input" failed to load because a dependency was not met. > Dependency: > type: executable > location: path > string: skconvert This is one, due to the plugin sk_input.inx - we can't quite fix this unless we just remove the extension, because skconvert is not packaged in debian. > Extension "Win32 Vector Print" failed to load because the extension is > designed for Windows only. This is caused by an improper .inx file for this > extension. An improper .inx file could have been caused by a faulty > installation of Inkscape. This is the other, and well, here we should really just stop shipping that extension, as it's useless in Linux :) Probably the upstream build system should not install that extension in !windows, I'll work out a patch with upstream. As an aside, I know upstream has been working on a new way to ship and share extensions, so all this may be for naught with the next major release. But as I mentioned, those messages are completely harmless, so you can safely ignore these errors. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#930857: POW: fv crashes while reading a file
Package: ftools-pow Version: 5.5+dfsg-1 Severity: serious When starting fv with almost any file and trying to display the content, fv crashes. Backtrace: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7708a535 in __GI_abort () at abort.c:79 #2 0x770e1508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x771ec28d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x770e7c1a in malloc_printerr (str=str@entry=0x771edff8 "double free or corruption (out)") at malloc.c:5341 #4 0x770e9730 in _int_free (av=0x77223c40 , p=0x56518dc0, have_lock=) at malloc.c:4306 #5 0x75e25ee1 in wcsinit (alloc=alloc@entry=1, naxis=2, wcs=wcs@entry=0x56518440, npvmax=64, npvmax@entry=-1, npsmax=8, npsmax@entry=-1, ndpmax=ndpmax@entry=-1) at wcs.c:173 #6 0x75e27241 in wcsini (alloc=alloc@entry=1, naxis=, wcs=wcs@entry=0x56518440) at wcs.c:141 #7 0x74cc74c3 in PowInitWCS (WCS=0x56518440, n=) at PowWCS.c:31 #8 0x74cc7975 in PowParseWCS (interp=interp@entry=0x55570070, WCS=WCS@entry=0x56518440, argc=argc@entry=5, argv=0x56293cd0) at PowWCS.c:113 #9 0x74cc85e1 in PowWCSInitCurve (clientData=, interp=0x55570070, argc=7, argv=) at PowWCS.c:362 [...] The problem is that PowWCS.c:31 the wrong field is initialized.
Bug#930666: Please document consensus on use of dh sequencer
I believe that both Russ's text and Sean's revised text capture the project level discussions. I also believe that given those discussions the issues are well understood enough for us to move forward relatively quickly if new issues are not raised here. I believe that Russ has adequately responded to the issue that Bill raised. As such, at least under my understanding of the policy process, I think I've reached the necessary conclusions to second a proposal on this bug. So, I second Sean's revisions to Russ's proposed wording. --Sam signature.asc Description: PGP signature
Bug#332539: Use-after-free
On 2019-06-21, at 08:41:47 +0100, Jeremy Sowden wrote: > Running wmail under valgrind reveals the following when deleting an > unread message: > > ==917== Invalid read of size 8 > ==917==at 0x10C778: ??? (in /usr/bin/wmail) > ==917==by 0x10D9B4: ??? (in /usr/bin/wmail) > ==917==by 0x10D9F6: ??? (in /usr/bin/wmail) > ==917==by 0x49F083F: ??? (in /lib/x86_64-linux-gnu/libc-2.28.so) > ==917==by 0x4AA77E3: poll (poll.c:29) > ==917==by 0x4FACCF6: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) > ==917==by 0x4FAE919: xcb_wait_for_event (in > /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) > ==917==by 0x48BBC67: _XReadEvents (in > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) > ==917==by 0x48AAD4F: XNextEvent (in > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) > ==917==by 0x487150A: DAEventLoopForWindow (in > /usr/lib/x86_64-linux-gnu/libdockapp.so.3.0.0) > ==917==by 0x10B05B: ??? (in /usr/bin/wmail) > ==917==by 0x49DD09A: (below main) (libc-start.c:308) > ==917== Address 0x5546570 is 0 bytes inside a block of size 32 free'd > ==917==at 0x48369AB: free (vg_replace_malloc.c:530) > ==917==by 0x10D47D: ??? (in /usr/bin/wmail) > ==917==by 0x10D61E: ??? (in /usr/bin/wmail) > ==917==by 0x10DA65: ??? (in /usr/bin/wmail) > ==917==by 0x49F083F: ??? (in /lib/x86_64-linux-gnu/libc-2.28.so) > ==917==by 0x4AA77E3: poll (poll.c:29) > ==917==by 0x4FACCF6: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) > ==917==by 0x4FAE919: xcb_wait_for_event (in > /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) > ==917==by 0x48BBC67: _XReadEvents (in > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) > ==917==by 0x48AAD4F: XNextEvent (in > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) > ==917==by 0x487150A: DAEventLoopForWindow (in > /usr/lib/x86_64-linux-gnu/libdockapp.so.3.0.0) > ==917==by 0x10B05B: ??? (in /usr/bin/wmail) > ==917== Block was alloc'd at > ==917==at 0x483577F: malloc (vg_replace_malloc.c:299) > ==917==by 0x10BEE2: ??? (in /usr/bin/wmail) > ==917==by 0x10C03D: ??? (in /usr/bin/wmail) > ==917==by 0x10D6AA: ??? (in /usr/bin/wmail) > ==917==by 0x10DA65: ??? (in /usr/bin/wmail) > ==917==by 0x49F083F: ??? (in /lib/x86_64-linux-gnu/libc-2.28.so) > ==917==by 0x4AA77E3: poll (poll.c:29) > ==917==by 0x4FACCF6: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) > ==917==by 0x4FAE919: xcb_wait_for_event (in > /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0) > ==917==by 0x48BBC67: _XReadEvents (in > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) > ==917==by 0x48AAD4F: XNextEvent (in > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0) > ==917==by 0x487150A: DAEventLoopForWindow (in > /usr/lib/x86_64-linux-gnu/libdockapp.so.3.0.0) > [...] When the list of sender names is updated by re-reading the messages in the mail-box, a flag is supposed to be set to inform the code that draws the ticker to restart. However, the code that frees the sender names for deleted mails did not set it. This meant that if the ticker was displaying the sender of a mail which had been deleted it would continue doing so after the name had been freed. J. signature.asc Description: PGP signature
Bug#930855: udev: USB Camera seen as multiple devices
Control: tags -1 + moreinfo Am 21.06.19 um 15:00 schrieb Seba Kerckhof: > Package: udev > Version: 241-5 > Severity: normal > > Dear Maintainer, > > Under Debian 10 rc1, when I plug in my USB camera (the very common logitech > c930e), 2 devices are added (e.g. /dev/video0 and /dev/video1). > > v4l-info works on /dev/video0, but fails on /dev/video1 > (VIDIOC_G_FMT(VIDEO_CAPTURE): Invalid argument). When I try to access the > device using gstreamer it tells me that /dev/video1 is not a capture device. > > In stretch I don't see this behavior. > > Attached are syslog, dmesg, v4l-info for both devices, udevadm for both > devices, lsusb, lspci. Those devices are created by the kernel, so you might want to bring that up with the kernel maintainers. Any specific reasons why you filed this against the udev package? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#930320: inkscape: crash on rotate
Control: tag -1 moreinfo Hi, On Mon, Jun 10, 2019 at 04:12:07PM +0200, Bardot Jerome wrote: > I try to repeat a shape configuration. But when i try to rotate my group of > shape inkscape crash. I can't quite reproduce it, so I hope you can help me with some extra details. > I add 2 screenshots in order to show the configuration. You seem to have forgotten those screenshots. > I have a 1 first part only compose of a circle. It will be the the center of > the rotation. > > The second part is a group of circles (ctrl+G). > I move the rotation point of the group to the part 1 center. > I duplicate the part 2 (circles group) and try to rotate it. > If i rotate left to right without go back there is no trouble but if i go back > (left to right and after right to left) inkscape bugs. > > The same is occured if i first rotate to left and back. Could you please produce a test document and leave it right before the rotation? Even best if you could do a short screencast to show what you exactly do. > Debian Release: 10.0 > APT prefers testing Given that you are running testing, could you also test out the package currently in experimental? (Which is not going to be marked as stable that quickly, and most likely I'll fix this crash in a stable update if possible, but just to check if that's already fixed in next releases). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#802501: Concluding "What should happen when maintscripts fail to restart a service?"
Hello Gunnar,
On Thu 20 Jun 2019 at 11:18am -0500, Gunnar Wolf wrote:
>> ~ ~ ~
>>
>> In #904558, I did not ask the T.C. to rule on what maintscripts should
>> do when they fail to restart a service. Rather, I asked them to weigh
>> in on the decision between the options described above, given that the
>> Policy Changes Process had failed to achieve consensus. However, in the
>> message closing #904558, the T.C. indicated that they declined to issue
>> a ruling about what maintscripts should do when they fail to restart a
>> service. So the second option described above, corresponding to the
>> 'ctte' usertag, has been taken off the table.
>>
>> That leaves us with the question of whether to leave #802501 open, in
>> the absence of the possibility of closing it by having the T.C. make a
>> call. Given that this bug has already been filed (at least) twice, I
>> think it would be best for us to leave it open. So I'm tagging
>> wontfix+stalled.
>
> I want to interpret this wontfix+stalled, and the TC answer ("The
> Technical Committee does not engage in design of new proposals and
> policies") don't mean this problem will just lay dormant and unsolved
> forever. As Marga said in her mail closing this bug, «While we
> recognize that this is a problem worth fixing, this is not something
> that we can fix as a body and need the help of the Developers to do
> it.»
>
> I want to insist on our recommendation to create a work group of
> developers to tackle this issue. Maybe we can start it off as a BoF
> session in DC19?
My reading of the conclusion to #904558 is that the recommendation to
form a working group is a recommendation that can be directed only to
the developer body as a whole, not to the Policy process. That's
because actually implementing in the archive some new mechanism for
maintscripts is a prerequisite to any Policy change requiring packages
to use that new mechanism. In other words, what the working group would
be tasked with doing is beyond the scope of the Policy process. We do
design work as part of the Policy process, but we don't write code.
Assuming that the T.C.'s recommendation is the right way to proceed
here, and someone doesn't come up with any other way to unblock things,
the wontfix+stalled status will remain until and unless the working
group actually forms, designs and implements something, and starts using
it in the archive. There is no role for the Policy process (and thus no
role for the Policy Editors qua Policy Editors) until that occurs.
So, by all means insist on the recommendation, but so far as I can tell
that's something which does not involve either the Policy process or the
T.C., but simply the body of Debian contributors qua contributors.
Stepping back a bit, tagging this bug wontfix+stalled is part of the
broader attempts, in which the Policy Editors are engaged, to more
sharply delineate the boundaries of the Policy process. We want to get
to the point where the only bugs that we have listed are either
highly actionable, or tagged wontfix. For a bug to be highly actionable
is for it to be the case that someone with enough time and background
knowledge can sit down, think through the problem, and come up with at
least a first version of a change proposal.
I think that a large number of very-difficult-to-action bugs strongly
discourages people from getting involved. It makes Policy seem like a
sprawling, unmanageable morass of difficult problems. That isn't how
things are, because while there are indeed a lot of hard problems, they
are largely independent of each other, and tackling individual
debian-policy bugs really does improve Debian. However, it is much
harder to see that when half of the open bugs are more than five years
old yet not tagged wontfix.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#930746: bind9: CVE-2019-6471: A race condition when discarding malformed packets can cause BIND to exit with an assertion failure
hi Ondřej, On Fri, Jun 21, 2019 at 02:14:33PM +0200, Ondřej Surý wrote: > Hi Salvatore, > > thanks for the debdiff. That looks good to me and if you have time > to do the upload, please do so. Thanks for confirming, will upload shortly. I have filled a respective merge request here: https://salsa.debian.org/dns-team/bind9/merge_requests/5 . Regards, Salvatore
Bug#930356: CVE-2019-12760
On Fri, 21 Jun 2019 at 13:15:23 +0200, Piotr Ożarowski wrote: > that's because python-jedi is a mutli-tarball source package and parso > was part of it at the beginning. Last time I checked gbp didn't > support it (or I don't know how to use it) so it was easier for me to > keep it outside DPMT. I guess there's no reason not to move parso into > DPMT now. gbp can do multi-tarball source packages with "component =" in debian/gbp.conf. Take a look at yquake2 in contrib for a working example. smcv
Bug#930836: rt-tests FTCBFS: Missing architecture of dependency libnuma-dev
Hello, On 6/21/19 1:36 PM, Nguyen Hoang Tung wrote: > rt-tests fails to cross build because its dependency, libnuma-dev:armhf, > is missing.Using armhf architecture of the dependency can solve this > problem. I'm pretty sure your patch is wrong. Goes your problem away if you replace DEB_BUILD_ARCH by DEB_TARGET_ARCH in debian/rules? Best regards Uwe signature.asc Description: OpenPGP digital signature
Bug#930758: runit: Add a test for switching init (systemd-->runit)
[2019-06-20 02:07] Lorenzo Puliti > Hi, Hi! > while experimenting with autopkgtest i manage to write a small test > that, starting from a systemd qemu machine, installs runit-init and reboot > into > it, checking if there is a working getty to login with and if essential > services (syslog, udev ..) are up. > While the test is very simple it could be useful to have something like > this around to make sure that the compat layer in /run/initctl will not > get broken (by systemd) and that some future development in stage1/2 will not > break the runit-init boot. > I have tested it on my pc, the last attach is the output of the test Sounds good, let's see. > Subject: [PATCH 1/3] Provide a service for a getty on serial tty > > diff --git a/debian/getty-ttyS0/run b/debian/getty-ttyS0/run > new file mode 100755 > index 000..31dccf6 > --- /dev/null > +++ b/debian/getty-ttyS0/run > @@ -0,0 +1,8 @@ > +#!/bin/sh > +NAME=getty-ttyS0 > +if pgrep -x agetty -t ttyS0; then > +sv d getty-ttyS0 > +echo "already another getty on ttyS0" > +fi > +exec 2>&1 > +exec chpst -P fgetty /dev/ttyS0 As I understand it, you assume that fgetty is present. Currently, runit does not have hard dependency of 'fgetty'. Can this runscript be made to fallback on "getty" from util-linux? > >From 374b79ae1c811b668668f22f57e77a6d352670a4 Mon Sep 17 00:00:00 2001 > From: Lorenzo Puliti > Date: Mon, 17 Jun 2019 14:43:55 +0200 > Subject: [PATCH 2/3] Prepare source for autopkgtest > > Add a stanza in debian/control and a debian/tests directory > needed for autopkgtest > --- > debian/control | 1 + > debian/tests/control | 1 + > 2 files changed, 2 insertions(+) > create mode 100644 debian/tests/control > > diff --git a/debian/control b/debian/control > index 23300e5..0764231 100644 > --- a/debian/control > +++ b/debian/control > @@ -13,6 +13,7 @@ Build-Depends: bash-completion, > doc-base, > Vcs-Browser: https://salsa.debian.org/debian/runit > Vcs-Git: https://salsa.debian.org/debian/runit.git > +Testsuite: autopkgtest > > Package: runit > Architecture: any > diff --git a/debian/tests/control b/debian/tests/control > new file mode 100644 > index 000..8d1c8b6 > --- /dev/null > +++ b/debian/tests/control > @@ -0,0 +1 @@ Are you sure this is needed? I believe autopkgtest tests are run without "Testsuite" field in debian/control. In my "gdbm" package, they do. > Subject: [PATCH 3/3] add a test for switching to runit-init > > Add a smoke test for the switch systemd --> runit-init > --- > --- a/debian/tests/control > +++ b/debian/tests/control > @@ -1 +1,7 @@ > - > +Tests: init-switch > +Depends: runit, > + runit-init, > + getty-run, > + fgetty, > + psmisc, > +Restrictions: needs-root, isolation-machine, breaks-testbed I am positive that runit-init implies getty-run. Maybe this list could be shinked even futher? > diff --git a/debian/tests/init-switch b/debian/tests/init-switch > new file mode 100755 > index 000..1e09238 > --- /dev/null > +++ b/debian/tests/init-switch > @@ -0,0 +1,60 @@ > + #!/bin/sh > + set -e > + > + > + if [ -z "$AUTOPKGTEST_REBOOT_MARK" ]; then > +if [ -d /run/systemd/system ]; then > +init=systemd > +elif [ -e /run/initctl ]; then > +init=sysv > +else > +init=unknown-init > +fi > +echo "testbed is running with $init" > + > +if [ -e /tmp/autopkgtest-reboot ]; then > +echo "enabling the serial getty" > +ln -s /etc/sv/getty-ttyS0 /etc/service/ > +echo "Done" > +/tmp/autopkgtest-reboot-prepare runit > +echo "reboot" > +reboot > +else > +echo "testbed does not support reboot" > +echo "can't perform this test" > +exit 1 > +fi > + else > +echo "detecting runit-init" > +if [ -e /run/runit.stopit ]; then > +echo "OK" > +else > +echo "init is not runit" && exit 1 > +fi > +# searching for runsvdir is pointless, since autopkgtest use serial getty > +#to connect with the qemu-system, and getty-S0 starts only after > runsvdir.. > +#echo "detecting runsvdir" > +#if pidof runsvdir; then > +#echo "OK" > +#else > +#echo "stage 2 failed to start runsvdir" && exit 1 > +#fi Can we remove this commented code? > +echo "detecting gettys" > +if pidof fgetty; then > +echo "OK" > +else > +echo " no getty to perform login with " && exit 1 > +fi > +echo "Detecting active services.." > +sv status /etc/service/* > +service udev status > +service rsyslog status > +service cron status > +service dbus status Why are these 'service' calls? Do 'service' support runit already? > +# service --status-all # not usable since some services will exit > nonzero with [?] > +# we can test also ssh-server here if runit-init will recommend it Not going to happen. Many users install all recommends; pulling ssh server without user
Bug#930856: autopkgtest-build-qemu: captures something from host
Package: autopkgtest Version: 5.10 Severity: normal Dear Maintainer, I fail to create qemu image: (ins).. sudo autopkgtest-build-qemu unstable debian-unstable Load spec file /tmp/tmp.MVjau2ZRda Exec: ['qemu-img', 'create', '-f', 'raw', 'debian-unstable.raw', '20G'] Exec: ['parted', '-s', 'debian-unstable.raw', 'mklabel', 'msdos'] Exec: ['parted', '-m', 'debian-unstable.raw', 'print'] Exec: ['parted', '-s', 'debian-unstable.raw', 'mkpart', 'primary', 'ext2', '0%', '100%'] Exec: ['kpartx', '-asv', 'debian-unstable.raw'] remembering /dev/mapper/loop0p1 as root Exec: ['/sbin/mkfs', '-t', 'ext4', '/dev/mapper/loop0p1'] Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmpybhuhyix'] Exec: ['debootstrap', '--variant', '-', 'unstable', '/tmp/tmpybhuhyix', 'http://deb.debian.org/debian'] ERROR: Command failed: debootstrap --variant - unstable /tmp/tmpybhuhyix http://deb.debian.org/debian b"W: Cannot check Release signature; keyring file not available /usr/share/keyrings/devuan-archive-keyring.gpg\nI : Retrieving InRelease \nI: Retrieving Packages \nI: Validating Packages \nI: Resolving dependencies of required packages...\nI: Resolving dependencies of base packages...\nI: Checking component main on http://deb.debian.org/d ebian...\nE: Couldn't find these debs: devuan-keyring devuan-baseconf\n" b'' Something went wrong, cleaning up! Exec: ['umount', '/tmp/tmpybhuhyix'] Exec: ['kpartx', '-dsv', 'debian-unstable.raw'] The host system actually uses Devuan repostiories and actually have "devuan-keyring" package installed (alongside with "debian-keyring"), but why debootstrap tries to validate Debian release with Devuan keyring and how could I override this? -- Note, that I send and fetch email in batch, once in a few days. pgplOCZ5xx8Dd.pgp Description: PGP signature
