Bug#892800: di-netboot-assistant: errors when $HOME not set
Package: di-netboot-assistant Version: 0.51 Severity: minor I have a puppet module that calls di-netboot-assistant to setup d-i images. When puppet runs the command, $HOME is not set. Because di-netboot-assistant uses "set -u" (line 3) when it attempts to use $HOME (line 56), the script exist with an error /usr/bin/di-netboot-assistant: line 56: HOME: unbound variable It's easy to repeat, just 'unset HOME'. Removing the -u from the set allows it to work fine (since the if on line 56 is just false when $HOME isn't set). -- Matt Taggart tagg...@debian.org
Bug#892799: libtgvoip: Incomplete debian/copyright?
Source: libtgvoip Version: 1.0.3-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: Nicholas Guriev Hi, I just ACCEPTed libtgvoip from NEW but noticed it was missing attribution in debian/copyright for at least common_audio/fft4g.c which looks like an embedded code copy. I would also prefer to see some clarification in debian/copyright about common_audio/signal_processing/spl_sqrt_floor.c. (This is not exhaustive so please check over the entire package carefully and address these on your next upload.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#892798: ruby-crack FTBFS uninitialized constant SafeYAML::Parse::Date::DateTime (NameError)
Package: ruby-crack version: 0.4.3-2 Severity: serious Autopkgtest also fails https://ci.debian.net/data/packages/unstable/amd64/r/ruby-crack/latest-autopkgtest/log.gz ┌──┐ │ Run tests for ruby2.5 from debian/ruby-tests.rake │ └──┘ RUBYLIB=/<>/debian/ruby-crack/usr/lib/ruby/vendor_ruby:. GEM_PATH=debian/ruby-crack/usr/share/rubygems-integration/all:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all ruby2.5 -S rake -f debian/ruby-tests.rake /usr/bin/ruby2.5 -w -I"lib:test" "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/hash_test.rb" "test/json_test.rb" "test/parser_test.rb" "test/string_test.rb" "test/xml_test.rb" /<>/test/hash_test.rb:10: warning: ambiguous first argument; put parentheses or a space even after `/' operator /<>/test/hash_test.rb:11: warning: ambiguous first argument; put parentheses or a space even after `/' operator /<>/test/hash_test.rb:12: warning: ambiguous first argument; put parentheses or a space even after `/' operator /<>/test/hash_test.rb:22: warning: ambiguous first argument; put parentheses or a space even after `/' operator /<>/test/hash_test.rb:23: warning: ambiguous first argument; put parentheses or a space even after `/' operator /<>/test/hash_test.rb:24: warning: ambiguous first argument; put parentheses or a space even after `/' operator /usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:22:in `': uninitialized constant SafeYAML::Parse::Date::DateTime (NameError) Did you mean? SafeYAML::Parse::Date::DATE_MATCHER from /usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:3:in `' from /usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:2:in `' from /usr/lib/ruby/vendor_ruby/safe_yaml/parse/date.rb:1:in `' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/vendor_ruby/safe_yaml/load.rb:14:in `' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /<>/lib/crack/json.rb:6:in `' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /<>/lib/crack.rb:6:in `' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /<>/test/test_helper.rb:3:in `' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /<>/test/hash_test.rb:1:in `' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:17:in `block in ' from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:5:in `select' from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:5:in `' rake aborted! Command failed with status (1): [ruby -w -I"lib:test" "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/hash_test.rb" "test/json_test.rb" "test/parser_test.rb" "test/string_test.rb" "test/xml_test.rb" ] Tasks: TOP => default => test (See full trace by running task with --trace) ERROR: Test "ruby2.5" failed. Exiting. dh_auto_install: dh_ruby --install /<>/debian/ruby-crack returned exit code 1 make: *** [debian/rules:6: binary] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Build finished at 2018-03-13T04:58:47Z signature.asc Description: OpenPGP digital signature
Bug#892797: sasview: should look for data files in home dir not package dir
Package: sasview Version: 4.2.0~git20180309-2 Severity: normal Currently when using the gui interface to open a new data file, the "Choose a file" dialog window starts from the package directory, /usr/lib/python2.7/dist-packages/sas/sasview. Of course no data files will be found there. The dialog should be configured to start from the user's home dir (or recently used, or somesuch). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sasview depends on: ii python2.7.14-4 ii python-numpy 1:1.13.3-2 ii python-pkg-resources 38.5.2-1 ii python-sasview4.2.0~git20180309-2 sasview recommends no packages. Versions of packages sasview suggests: ii sasview-doc 4.2.0~git20180309-2 -- no debconf information
Bug#892796: boost1.62: please backport patches from smart_ptr PR/47 for mips r6
Package: src:boost1.62 Version: 1.62.0+dfsg-5 mips r6 changes encoding of some insn, include ll/sc, if we .set mips2, it will generate old encodings for them. So we shouldn't use `.set mips2' for r6. https://github.com/boostorg/smart_ptr/pull/47 -- YunQiang Su
Bug#892795: conflicts with libcurl4
Package: feh Version: 2.23.2-1 # aptitude install feh The following packages have unmet dependencies: libcurl4 : Conflicts: libcurl3 but 7.58.0-2 is to be installed The following actions will resolve these dependencies: Remove the following packages: 1) curl [7.58.0-3 (experimental, now)] 2) libcurl4 [7.58.0-3 (experimental, now)]
Bug#815088: cron: sysv init script has "Required-Start: $remote_fs" but systemd service does not
(not sure to whom this question is directed) On Mon, Mar 12, 2018 at 7:59 PM, Michael Biebl wrote: > On Sun, 1 May 2016 22:32:33 +0200 Christian Kastner wrote: > > Control: tag -1 confirmed pending > > > > Hi Sandro, > > > > On 2016-02-18 16:45, Sandro Tosi wrote: > > > i just noticed the systemd service for cron doesnt define a depencency on > > > remote-fs.target , while the sysv init script have the "Required-Start: > > > $remote_fs". I think that dependency should be added. > > > > Thank you for spotting this, I have committed a fix. > > Why would a dependency on remote-fs.target be necessary? because that's the path of least surprise: on wheezy cron depended on remote_fs, while jessie cron service doesnt, so during that migration you would have expected cronjobs depending on remote fs to correctly be executed, but that's a wrong assumption as cron service is happy to start before NFS shares are mounted, thus failing the jobs depending on them. i'm well aware we can add a drop-in in /etc/systemd to add the dependency, but the point is to have sane defaults and do not surprise the administrators with an unannounced change of dependencies. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Hi Apollon, On 18-03-13 00:19:06, Apollon Oikonomopoulos wrote: > On 23:09 Mon 12 Mar , Georg Faerber wrote: > > On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote: > > > So, the version of ruby-gettext-setup is pretty outdated and > > > predates > > > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules > > > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext > > > default domain, causing breakage. This has been fixed upstream[1] in > > > 0.17. > > > > > > We should upgrade ruby-gettext-setup to the latest upstream version. > > > > I could take care of this, tomorrow. Just need someone to sponsor the > > upload. > > Please do! I'd be glad to sponsor this, ping me when you're ready or > if you need any help. I've pushed in git to branch debian/0.30-1. Please especially review eeff22b6, in particular the changes I've made to spec/lib/tasks/gettext_rake_spec.rb. (This file loads an rake task contained in lib/. I'm not really sure if I'm happy with my proposed change, however, I've tried various methods and didn't found anything else working besides this. Reasoning for this change: Upstreams code doesn't work if specs are run via autopkgtest, as lib/ is moved away during autopkgtest runs. In case you would like to change this: Please go ahead.) Thanks for reviewing, cheers, Georg signature.asc Description: Digital signature
Bug#860950: steam: crashes on startup
On Sun, Feb 18, 2018 at 1:04 AM, Clayton wrote: > [2018-02-18 12:50:27] Cleaning up... > [2018-02-18 12:50:27] Update complete, launching... > [2018-02-18 12:50:27] Shutdown tar: This does not look like a tar > archive xz: (stdin): File format not recognized > tar: Child returned status 1 > tar: Error is not recoverable: exiting now > find: ‘/home/user/.steam/ubuntu12_32/steam-runtime’: No such file or > directory This looks like an incomplete download. Try backing up your ubuntu12_32 folder, and execute steam again. If that works, the script will need to try to clean up after a failed download. Best wishes, Mike
Bug#789247: di-netboot-assistant: broken deb.d.o urls
On 03/10/2018 04:22 AM, Andreas B. Mundt wrote: Hm, the /debian/ should be inserted by the following in '/etc/di-netboot-assistant/di-netboot-assistant.conf' [1]: #Download Mirror # The variable MIRROR_REGEXPS contain a list of space separated sed # regular expression, to rewrite di-sources.list URLs, to match your # prefered mirror. For example: MIRROR_REGEXPS="s=://deb.debian.org/=://deb.debian.org/debian/=" I was already wondering why not to use the correct URL in 'di-sources.list', but kept that as it works fine for me. Can you check if you have the line in 'di-netboot-assistant.conf'? Perhaps it's there for historical reasons and we can/should remove it. Oh... I had just grabbed the latest di-sources.list to use on an older version of the package, I didn't know about that regexp thing in the config file... It's sort of a nice feature, it makes using a local mirror/proxy easier (assuming you know you can use that). But I suspect most mirrors would have a debian/ dir and if a user had one that _didn't_ then the regexp could be setup the other way to strip it out. So my vote would be fix the URLs in di-sources.list, comment out MIRROR_REGEXP in the conf, change it's regexps to provide an example of how it could be used. I guess the only concern is the existing conffiles that are out there and if that would break existing installs. If you changed both sources and conf at the same time, hopefully it would be clear. I guess if you go that route, wait until one of them needs another change anyway? -- Matt Taggart tagg...@debian.org
Bug#892413: nvidia-driver: PRIME Synchronization regression in 390.25 with kernel 4.15, fixed upstream
On Mon, 2018-03-12 at 18:31 +0100, Andreas Beckmann wrote: > On 2018-03-12 17:28, Luca Boccassi wrote: > > Yeah I suspected a new release would have happened soon so I didn't > > have a look at that yet. > > > > I'll look at 390.42 as soon as possible, and if still necessary, > > check > > that patch. > > It still applies ... module build test still running. > > > I don't use PRIME so I can't really say if it was broken or not at > > the > > moment. > > Me neither ... > > Andreas Seems to work fine on my desktop. Ship it :-) -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#869421: RFP: stlink -- STM32 stlink programmer tools
Control: retitle -1 ITP: stlink -- STM32 stlink programmer tools Control: owner -1 bl...@debian.org On Sun, 23 Jul 2017 14:19:23 +0200 cedric wrote: > Package: wnpp > Severity: wishlist > > * Package name: stlink > Version : 1.4.0 > Upstream Author : Jerry Jacobs > * URL : https://github.com/texane/stlink > * License : BSD > Programming Lang: C > Description : STM32 stlink programmer tools > > Open source version of the STMicroelectronics Stlink Tools, > can be used to program and debug STM32 MCU boards > > There is no similar tools in debian packages right now. > Building and debian package generation works fine. > I use it often. > Maybe it can be maintained by pkg-electronics team. > I am not a debian developper but I can help if needed. > > Cedric Hi, I intend to upload stlink in the next couple of days. I've sent a few packaging fixes on Github: https://github.com/texane/stlink/pull/683 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#840119: lowering no-pdiff prio to 99 doesn't help
# mv /etc/apt/apt.conf.d/00no-pdiff /etc/apt/apt.conf.d/99no-pdiff # apt-config dump | grep -i pdiff Acquire::IndexTargets::deb::Contents-deb::PDiffs "true"; Acquire::IndexTargets::deb::Contents-udeb::PDiffs "true"; Acquire::IndexTargets::deb::Contents-deb-legacy::PDiffs "true"; Acquire::IndexTargets::deb-src::Contents-dsc::PDiffs "true"; Acquire::PDiffs "false"; # apt update ... Get:13 http://ftp.debian.org/debian sid/main amd64 Contents (deb) 2018-03-12-0220.21.pdiff [2,704 B] ... -- sergio
Bug#883027: flare-engine: new upstream release 0.20
(copying Antoine Musso now) This e-mail below extends also to Antoine, or anybody else who wants to collaborate :) 2018-03-13 1:13 GMT+01:00 Manuel A. Fernandez Montecelo : > Hi, > > 2018-03-12 20:34 GMT+01:00 felipe : >> Hi. >> >> It seems Flare 1.0 was just released with the new Empyrean Campaign. >> >> Let me know if you need help packaging the new version. > > I asked them when receiving this bug report (bug request in github, > IIRC), they estimated like 3 months, and here we are :) > > Unfortunately at the moment I am a bit busy, so if you could prepare a > package for the new version it would be great! > > > Cheers. > -- > Manuel A. Fernandez Montecelo -- Manuel A. Fernandez Montecelo
Bug#883027: flare-engine: new upstream release 0.20
Hi, 2018-03-12 20:34 GMT+01:00 felipe : > Hi. > > It seems Flare 1.0 was just released with the new Empyrean Campaign. > > Let me know if you need help packaging the new version. I asked them when receiving this bug report (bug request in github, IIRC), they estimated like 3 months, and here we are :) Unfortunately at the moment I am a bit busy, so if you could prepare a package for the new version it would be great! Cheers. -- Manuel A. Fernandez Montecelo
Bug#892793: stretch-pu: package cron/128+deb9u2
Am 13.03.2018 um 00:43 schrieb Javier Fernández-Sanguino Peña: > +After=remote-fs.target nss-user-lookup.target Why is the remote-fs.target ordering necessary? That doesn't seem correct to me. -- 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#815088: cron: sysv init script has "Required-Start: $remote_fs" but systemd service does not
On Sun, 1 May 2016 22:32:33 +0200 Christian Kastner wrote: > Control: tag -1 confirmed pending > > Hi Sandro, > > On 2016-02-18 16:45, Sandro Tosi wrote: > > i just noticed the systemd service for cron doesnt define a depencency on > > remote-fs.target , while the sysv init script have the "Required-Start: > > $remote_fs". I think that dependency should be added. > > Thank you for spotting this, I have committed a fix. Why would a dependency on remote-fs.target be necessary? -- 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#892793: stretch-pu: package cron/128+deb9u2
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Fix bugs in cron that prevents it from working properly in environments where centralised user databases are used (e.g. LDAP, Windows AD). The changes introduce a dependency in the init.d file (for sssd) and in the service unit file to ensure that cron is started after these services are operative. Please review and, if possible, accept this version for stretch. Best regards Javier Fernandez-Sanguino diff -u cron-3.0pl1/debian/changelog cron-3.0pl1/debian/changelog --- cron-3.0pl1/debian/changelog +++ cron-3.0pl1/debian/changelog @@ -1,3 +1,17 @@ +cron (3.0pl1-128+deb9u2) stretch; urgency=medium + + * debian/cron.init: Add sssd to the services that should be started/stopped +before/after cron + * debian/cron.service: Add a dependency on remote-fs.target (Closes: #815088) + * debian/cron.service: Add dependency on nss-user-lookup.target in the +definition which properly fixes the issues when cron is started +before centralised user repositories are available (e.g. LDAP +or Active Directory). This should avoid errors in syslog similar to +the following: "crond[PID]: (CRON) bad username (/etc/cron.d/JOBNAME)" +(Closes: #767016, #801384, #783665) (LP: #1593317) + + -- Javier Fernández-Sanguino Peña Sun, 11 Mar 2018 22:32:18 +0100 + cron (3.0pl1-128+deb9u1) stretch; urgency=medium * Non-maintainer upload. diff -u cron-3.0pl1/debian/cron.init cron-3.0pl1/debian/cron.init --- cron-3.0pl1/debian/cron.init +++ cron-3.0pl1/debian/cron.init @@ -5,8 +5,8 @@ # Provides: cron # Required-Start:$remote_fs $syslog $time # Required-Stop: $remote_fs $syslog $time -# Should-Start: $network $named slapd autofs ypbind nscd nslcd winbind -# Should-Stop: $network $named slapd autofs ypbind nscd nslcd winbind +# Should-Start: $network $named slapd autofs ypbind nscd nslcd winbind sssd +# Should-Stop: $network $named slapd autofs ypbind nscd nslcd winbind sssd # Default-Start: 2 3 4 5 # Default-Stop: # Short-Description: Regular background program processing daemon diff -u cron-3.0pl1/debian/cron.service cron-3.0pl1/debian/cron.service --- cron-3.0pl1/debian/cron.service +++ cron-3.0pl1/debian/cron.service @@ -1,6 +1,7 @@ [Unit] Description=Regular background program processing daemon Documentation=man:cron(8) +After=remote-fs.target nss-user-lookup.target [Service] EnvironmentFile=-/etc/default/cron signature.asc Description: PGP signature
Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
On Mon, 12 Mar 2018 23:45:44 +0100 Michael Biebl wrote: [...] > Am 12.03.2018 um 23:16 schrieb Francesco Poli: [...] > > I've just performed the test, after commenting out the three above > > quoted lines. > > The bug was not triggered. > > Thanks for testing. Thanks to you for investigating and for asking me to perform the right test! ;-) > > > It really seems that the bug is caused by some interaction with > > clear_console ... > > I'm going to reassing to bash and merge with > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342 > > I'm not sure if it's a bug in Xorg or bash's clear_console, I'll leave > it up to the respective maintainers to reassign if necessary. Good. Looking forward to hearing from the bash Debian package maintainers and/or from the X Strike Force... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpKXQK8Albqe.pgp Description: PGP signature
Bug#892792: apt: Typo in apt 1.5~beta1 changelog
Package: apt Version: 1.6~beta1 Severity: minor Dear Maintainer, Paragraph "As for backwards compatibility, the options IssuerCert and SslForceVersion are not supported anymore, and any specified certificate files must in the PEM format (curl might have allowed DER files as well)." should read "must be in the PEM format" -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.15\.0-1-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.9\.0-6-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::VersionedKernelPackages:: "linux-cloud-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Periodic::MaxAge "30"; APT::Periodic::MinAge "2"; APT::Periodic::MaxSize "500"; APT::Update ""; APT::Update::Post-Invoke ""; APT::Update::Post-Invoke:: "touch /var/lib/apt/periodic/update-success-stamp 2>/dev/null || true"; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip:
Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
Am 12.03.2018 um 23:45 schrieb Michael Biebl: > Am 12.03.2018 um 23:16 schrieb Francesco Poli: >> It really seems that the bug is caused by some interaction with >> clear_console ... > > I'm going to reassing to bash and merge with > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342 > > I'm not sure if it's a bug in Xorg or bash's clear_console, I'll leave > it up to the respective maintainers to reassign if necessary. I will note, that clear_console is a debian specific addition to bash. -- 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#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
Control: reassign -1 bash Control: forcemerge 791342 -1 Am 12.03.2018 um 23:16 schrieb Francesco Poli: > On Sun, 11 Mar 2018 20:11:03 +0100 Michael Biebl wrote: > >> Am 11.03.2018 um 19:12 schrieb Francesco Poli: >> >>> My ~/.bash_logout is attached, but it's nothing special: it should be >>> identical to the one provided by the bash package in /etc/skel/ >> >> Can you comment out / remove the following three lines: >> >> if [ "$SHLVL" = 1 ]; then >> [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q >> fi >> >> and then test again, if you still encounter the problem. > > I've just performed the test, after commenting out the three above > quoted lines. > The bug was not triggered. Thanks for testing. > It really seems that the bug is caused by some interaction with > clear_console ... I'm going to reassing to bash and merge with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791342 I'm not sure if it's a bug in Xorg or bash's clear_console, I'll leave it up to the respective maintainers to reassign if necessary. Regards, Michael -- 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#874220: stretch update for openni2
* Adrian Bunk [2018-03-12 20:52]: On Mon, Sep 11, 2017 at 09:18:05PM +, Debian Bug Tracking System wrote: ... openni2 (2.2.0.33+dfsg-10) unstable; urgency=medium . * Add patch for arm. Thanks to Adrian Bunk (Closes: #874220) ... Thanks a lot for fixing this bug for unstable. It is still present in stretch, could you also fix it there? Alternatively, I can fix it for stretch if you don't object. Fell free to fix it :). Thanks Jochen signature.asc Description: PGP signature
Bug#852856: collaborate
On Mon, Mar 12, 2018 at 11:13:10PM +0100, Geert Stappers wrote: > > I'm not sure that's entirely appropriate. You can perfectly easily add > > some udev rules to urjtag, rather than expecting openocd to solve the > > problem for you. It can even be done in a way that means the 2 packages > > can co-exist. #852856 is a wishlist bug that essentially says "we do the > > same thing, I'd like to take advantage of the work you've already done > > rather than maintaining a similar list myself". > > In my words: > > Avoiding duplicate work. > > My plan: > > Applying the patches, become stakeholder of openocd package. > Working together. If you want to work together you have to have a discussion. I appreciate the bug has been languishing without a response but it pre-dates my involvement with the OpenOCD package and it's not been as high priority as getting the package up to date with upstream or dealing with security issues. On Mon, Mar 12, 2018 at 11:13:26PM +0100, Geert Stappers wrote: > On Mon, Mar 12, 2018 at 09:39:29AM +, Jonathan McDowell wrote: > > Is there a direct 1:1 mapping of devices that OpenOCD and urjtag > > support, or is one a subset of the other? > > Seen the question, but I don't see where it fits in the discussion > about a openocd file moving into seperate package. If one program is a strict subset of the other in terms of supported adaptors then it may make sense for the program with the larger support matrix to split a file out so that the other can take advantage of it. If the 2 programs support different adaptors then I'm not sure of the benefit; it becomes extra work on both parts to maintain the overlapping list? J. -- Avoid GOTOs completely if you can keep the program readable. This .sig brought to you by the letter L and the number 49 Product of the Republic of HuggieTag
Bug#892004: Please adapt to gnome-settings-daemon 3.28 by March 15
Hi, I am unable to do something this week. Could someone else apply the change and upload the package? Thanks, Joachim Am Samstag, den 10.03.2018, 21:47 -0500 schrieb Jeremy Bicha: > Please make your upload on or before March 15. Otherwise, we will need > to NMU your package for the gnome-settings-daemon 3.28 transition. > > On behalf of the Debian GNOME Team, > Jeremy Bicha > > -- Joachim “nomeata” Breitner Debian Developer nome...@debian.org • https://people.debian.org/~nomeata XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part
Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Hi Apollon, On 18-03-13 00:19:06, Apollon Oikonomopoulos wrote: > On 23:09 Mon 12 Mar , Georg Faerber wrote: > > On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote: > > > So, the version of ruby-gettext-setup is pretty outdated and > > > predates > > > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules > > > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext > > > default domain, causing breakage. This has been fixed upstream[1] in > > > 0.17. > > > > > > We should upgrade ruby-gettext-setup to the latest upstream version. > > > > I could take care of this, tomorrow. Just need someone to sponsor > > the upload. > > Please do! I'd be glad to sponsor this, ping me when you're ready or > if you need any help. Will do, thanks! Cheers, Georg signature.asc Description: Digital signature
Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Hi Georg, On 23:09 Mon 12 Mar , Georg Faerber wrote: > On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote: > > So, the version of ruby-gettext-setup is pretty outdated and > > predates > > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules > > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext > > default domain, causing breakage. This has been fixed upstream[1] in > > 0.17. > > > > We should upgrade ruby-gettext-setup to the latest upstream version. > > I could take care of this, tomorrow. Just need someone to sponsor the > upload. Please do! I'd be glad to sponsor this, ping me when you're ready or if you need any help. Cheers, Apollon
Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
On Sun, 11 Mar 2018 20:11:03 +0100 Michael Biebl wrote: > Am 11.03.2018 um 19:12 schrieb Francesco Poli: > > > My ~/.bash_logout is attached, but it's nothing special: it should be > > identical to the one provided by the bash package in /etc/skel/ > > Can you comment out / remove the following three lines: > > if [ "$SHLVL" = 1 ]; then > [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q > fi > > and then test again, if you still encounter the problem. I've just performed the test, after commenting out the three above quoted lines. The bug was not triggered. It really seems that the bug is caused by some interaction with clear_console ... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpokAgdAsNf5.pgp Description: PGP signature
Bug#892791: RFP: SLSK -- A backup utility and database for Linux Steam games
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org License: GPLv3 URL: https://github.com/supremesonicbrazil/SLSK Copyright (C) 2017-2018 Supremist (aka supremesonicbrazil) Description: Steam Linux Swiss Knife is an open-source program that aims to automate the backup and restore of Steam games, their saves and configs, centralizing paths in a local and extremely lightweight database.
Bug#892790: cross-toolchain-base-ports: Please add support for riscv64
Source: cross-toolchain-base-ports Version: 18 Severity: wishlist Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 Hello, We are in the process of bootstrapping a Debian port for the riscv64 architecture (https://wiki.debian.org/RISC-V). Adding this architecture to the cross-toolchain would simplify a lot the cross-compilation of packages. You will find attached a patch doing that for cross-toolchain-base-ports. Note that the control file of glibc has to be patched, as it doesn't provide riscv64 in the architecture list, due to missing support in dpkg/stable (see bugs #888793 and #890791). Thanks, Aurelien diff -Nru cross-toolchain-base-ports-18/debian/control cross-toolchain-base-ports-18.1/debian/control --- cross-toolchain-base-ports-18/debian/control +++ cross-toolchain-base-ports-18.1/debian/control @@ -25,7 +25,7 @@ libconfig-auto-perl, libfile-temp-perl, libconfig-auto-perl, libfile-homedir-perl, liblocale-gettext-perl, libunwind-dev [amd64 i386 x32] Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl, - binutils-alpha-linux-gnu, libc6-alpha-cross, linux-libc-dev-alpha-cross, binutils-hppa-linux-gnu, libc6-hppa-cross, linux-libc-dev-hppa-cross, binutils-m68k-linux-gnu, libc6-m68k-cross, linux-libc-dev-m68k-cross, binutils-mips64-linux-gnuabi64, libc6-mips64-cross, linux-libc-dev-mips64-cross, binutils-powerpc64-linux-gnu, libc6-ppc64-cross, linux-libc-dev-ppc64-cross, binutils-sh4-linux-gnu, libc6-sh4-cross, linux-libc-dev-sh4-cross, binutils-sparc64-linux-gnu, libc6-sparc64-cross, linux-libc-dev-sparc64-cross, binutils-powerpc-linux-gnu, libc6-powerpc-cross, linux-libc-dev-powerpc-cross, binutils-powerpc-linux-gnuspe, libc6-powerpcspe-cross, linux-libc-dev-powerpcspe-cross, binutils-mips64-linux-gnuabin32, libc6-mipsn32-cross, linux-libc-dev-mipsn32-cross, binutils-mips64el-linux-gnuabin32, libc6-mipsn32el-cross, linux-libc-dev-mipsn32el-cross, binutils-mipsisa32r6-linux-gnu, libc6-mipsr6-cross, linux-libc-dev-mipsr6-cross, binutils-mipsisa32r6el-linux-gnu, libc6-mipsr6el-cross, linux-libc-dev-mipsr6el-cross, binutils-mipsisa64r6-linux-gnuabin32, libc6-mipsn32r6-cross, linux-libc-dev-mipsn32r6-cross, binutils-mipsisa64r6el-linux-gnuabin32, libc6-mipsn32r6el-cross, linux-libc-dev-mipsn32r6el-cross, binutils-mipsisa64r6-linux-gnuabi64, libc6-mips64r6-cross, linux-libc-dev-mips64r6-cross, binutils-mipsisa64r6el-linux-gnuabi64, libc6-mips64r6el-cross, linux-libc-dev-mips64r6el-cross, + binutils-alpha-linux-gnu, libc6-alpha-cross, linux-libc-dev-alpha-cross, binutils-hppa-linux-gnu, libc6-hppa-cross, linux-libc-dev-hppa-cross, binutils-m68k-linux-gnu, libc6-m68k-cross, linux-libc-dev-m68k-cross, binutils-mips64-linux-gnuabi64, libc6-mips64-cross, linux-libc-dev-mips64-cross, binutils-powerpc64-linux-gnu, libc6-ppc64-cross, linux-libc-dev-ppc64-cross, binutils-riscv64-linux-gnu, libc6-riscv64-cross, linux-libc-dev-riscv64-cross, binutils-sh4-linux-gnu, libc6-sh4-cross, linux-libc-dev-sh4-cross, binutils-sparc64-linux-gnu, libc6-sparc64-cross, linux-libc-dev-sparc64-cross, binutils-powerpc-linux-gnu, libc6-powerpc-cross, linux-libc-dev-powerpc-cross, binutils-powerpc-linux-gnuspe, libc6-powerpcspe-cross, linux-libc-dev-powerpcspe-cross, binutils-mips64-linux-gnuabin32, libc6-mipsn32-cross, linux-libc-dev-mipsn32-cross, binutils-mips64el-linux-gnuabin32, libc6-mipsn32el-cross, linux-libc-dev-mipsn32el-cross, binutils-mipsisa32r6-linux-gnu, libc6-mipsr6-cross, linux-libc-dev-mipsr6-cross, binutils-mipsisa32r6el-linux-gnu, libc6-mipsr6el-cross, linux-libc-dev-mipsr6el-cross, binutils-mipsisa64r6-linux-gnuabin32, libc6-mipsn32r6-cross, linux-libc-dev-mipsn32r6-cross, binutils-mipsisa64r6el-linux-gnuabin32, libc6-mipsn32r6el-cross, linux-libc-dev-mipsn32r6el-cross, binutils-mipsisa64r6-linux-gnuabi64, libc6-mips64r6-cross, linux-libc-dev-mips64r6-cross, binutils-mipsisa64r6el-linux-gnuabi64, libc6-mips64r6el-cross, linux-libc-dev-mips64r6el-cross, libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386] Package: linux-libc-dev-alpha-cross @@ -88,6 +88,18 @@ libraries. They are NOT meant to be used to build third-party modules for your kernel. Use linux-headers-* packages for that. +Package: linux-libc-dev-riscv64-cross +Architecture: all +Multi-Arch: foreign +Depends: ${misc:Depends} +Provides: linux-kernel-headers-riscv64-cross, linux-libc-dev-riscv64-dcv1 +Built-Using: ${bu:linux} +Description: Linux Kernel Headers for development (for cross-compiling) + This package provides headers from the Linux kernel. These headers + are used by the installed headers for GNU glibc and other system + libraries. They are NOT meant to be used to build third-party modules for + your kernel. Use linux-headers-* packages for that. + Package: linux-libc-dev-sh4-cross Architecture: all Multi-Arch: foreign @@ -358,6 +370,32 @@ Built-Using: ${bu:glibc} Description: GNU C Lib
Bug#852856: collaborate
> I'm not sure that's entirely appropriate. You can perfectly easily add > some udev rules to urjtag, rather than expecting openocd to solve the > problem for you. It can even be done in a way that means the 2 packages > can co-exist. #852856 is a wishlist bug that essentially says "we do the > same thing, I'd like to take advantage of the work you've already done > rather than maintaining a similar list myself". In my words: Avoiding duplicate work. My plan: Applying the patches, become stakeholder of openocd package. Working together. Groeten Geert Stappers -- Leven en laten leven
Bug#852856: 1:1 or one a subset of the other
On Mon, Mar 12, 2018 at 09:39:29AM +, Jonathan McDowell wrote: > Is there a direct 1:1 mapping of devices that OpenOCD and urjtag > support, or is one a subset of the other? Seen the question, but I don't see where it fits in the discussion about a openocd file moving into seperate package. Groeten Geert Stappers -- Leven en laten leven
Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote: > On 21:04 Mon 12 Mar , Mykola Nikishov wrote: > > Package: puppet > > Version: 5.4.0-1 > > Followup-For: Bug #892737 > > > > I have librarian-puppet and found out that downgrading it to jessie > > will fix the problem. Downgrade will remove ruby-puppet-forge and > > ruby-gettext-setup. > > > > Seems ruby-gettext-setup causes this problem. > > So, the version of ruby-gettext-setup is pretty outdated and predates > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext > default domain, causing breakage. This has been fixed upstream[1] in > 0.17. > > We should upgrade ruby-gettext-setup to the latest upstream version. I could take care of this, tomorrow. Just need someone to sponsor the upload. Cheers, Georg signature.asc Description: Digital signature
Bug#892004: Please adapt to gnome-settings-daemon 3.28 by March 15
Hi, I am unable to do something this week. Could someone else apply the change and upload the package? Thanks, Joachim Am Samstag, den 10.03.2018, 21:47 -0500 schrieb Jeremy Bicha: > Please make your upload on or before March 15. Otherwise, we will need > to NMU your package for the gnome-settings-daemon 3.28 transition. > > On behalf of the Debian GNOME Team, > Jeremy Bicha > > -- Joachim “nomeata” Breitner Debian Developer nome...@debian.org • https://people.debian.org/~nomeata XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part
Bug#873224: Pending fixes for bugs in the sweethome3d package
tag 873224 + pending thanks Some bugs in the sweethome3d package are closed in revision 0982915f254a0da748a5ae5f5bd1238b8e3c9e6b in branch 'master' by Emmanuel Bourg The full diff can be seen at https://anonscm.debian.org/cgit/pkg-java/sweethome3d.git/commit/?id=0982915 Commit message: Fixed the build failure with Java 9 (Closes: #873224)
Bug#892789: prelude-manager: New upstream version 4.1.0
Source: prelude-manager Version: 3.1.0-4 Severity: wishlist prelude-manager 4.1 was released in 2017. Thanks Regards
Bug#874155: FTBFS with Java 9: overrides core packages
Control: tag -1 + patch Control: tag -1 - help The org.xml.sax classes should be removed from the package. Until that happens, the build failure can be solved with this patch: --- a/build.xml +++ b/build.xml @@ -4,7 +4,7 @@ - +
Bug#885204: gnucash: please migrate to guile-2.2
Hi Rob, On Tuesday, 26 December 2017 9:17:34 AM AEDT Rob Browning wrote: > I'd like to remove guile-2.0 before the buster release, so please > migrate to guile-2.2 when you can. I tried to build Gnucash with "guile-2.2" but "dh_strip" failed as follows: dh_strip --dbgsym-migration='gnucash-dbg (<< 1:2.6.13~)' strip: Unable to recognise the format of the input file `debian/gnucash/usr/ lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/2.2/report.go' dh_strip: strip --remove-section=.comment --remove-section=.note --strip- unneeded debian/gnucash/usr/lib/x86_64-linux-gnu/gnucash/gnucash/scm/ccache/ 2.2/report.go returned exit code 1 There is no such problem with "guile-2.0"... Any ideas what could be done about that? Thanks. Regards, Dmitry Smirnov. --- Journalism is printing what someone else does not want printed: everything else is public relations. -- George Orwell signature.asc Description: This is a digitally signed message part.
Bug#892737: [Pkg-puppet-devel] Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Control: reassign -1 ruby-gettext-setup Control: retitle -1 ruby-gettext-setup: outdated version, hijacks gettext and breaks puppet Control: found -1 0.7-1 Control: tags -1 severity serious Hi, On 21:04 Mon 12 Mar , Mykola Nikishov wrote: > Package: puppet > Version: 5.4.0-1 > Followup-For: Bug #892737 > > I have librarian-puppet and found out that downgrading it to jessie > will fix the problem. Downgrade will remove ruby-puppet-forge and > ruby-gettext-setup. > > Seems ruby-gettext-setup causes this problem. So, the version of ruby-gettext-setup is pretty outdated and predates Puppet's i18n system. When pulled in via i18n-enabled Puppet modules (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext default domain, causing breakage. This has been fixed upstream[1] in 0.17. We should upgrade ruby-gettext-setup to the latest upstream version. Regards, Apollon [1] https://github.com/puppetlabs/gettext-setup-gem/commit/0fcb0971faf094b0689bf302b04327a09de41c0e
Bug#892788: e2guardian: Please enable MITM Filtering HTTPS
Package: e2guardian Version: 3.4.0.3-2 Severity: wishlist Hi, Please configure and compile e2guardian with the --enable-sslmitm=yes flag set. Without this a content filter is not very useful on the modern internet. Thanks, Roger -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages e2guardian depends on: ii adduser 3.115 ii clamav 0.99.4+dfsg-1+deb9u1 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libpcre32:8.39-3 ii libstdc++6 6.3.0-18+deb9u1 ii perl5.24.1-3+deb9u2 ii zlib1g 1:1.2.8.dfsg-5 e2guardian recommends no packages. Versions of packages e2guardian suggests: ii clamav-freshclam 0.99.4+dfsg-1+deb9u1 ii squid 3.5.23-5+deb9u1 -- Configuration Files: /etc/e2guardian/e2guardian.conf changed: languagedir = '/usr/share/e2guardian/languages' language = 'ukenglish' loglevel = 2 logexceptionhits = 2 logfileformat = 1 dstatlocation = '/var/log/e2guardian/dstats.log' filterip = 192.168.0.2 filterports = 8080 proxyip = 127.0.0.1 proxyport = 3128 proxytimeout = 20 proxyexchange = 20 pcontimeout = 55 usecustombannedimage = on custombannedimagefile = '/usr/share/e2guardian/transparent1x1.gif' usecustombannedflash = on custombannedflashfile = '/usr/share/e2guardian/blockedflash.swf' filtergroups = 1 filtergroupslist = '/etc/e2guardian/lists/filtergroupslist' bannediplist = '/etc/e2guardian/lists/bannediplist' exceptioniplist = '/etc/e2guardian/lists/exceptioniplist' showweightedfound = on urlcachenumber = 1000 urlcacheage = 900 scancleancache = on phrasefiltermode = 2 preservecase = 0 hexdecodecontent = off forcequicksearch = off reverseaddresslookups = on reverseclientiplookups = on logclienthostnames = on prefercachedlists = off maxcontentfiltersize = 1024 maxcontentramcachescansize = 16384 maxcontentfilecachescansize = 65536 filecachedir = '/tmp' deletedownloadedtempfiles = on initialtrickledelay = 20 trickledelay = 10 downloadmanager = '/etc/e2guardian/downloadmanagers/fancy.conf' downloadmanager = '/etc/e2guardian/downloadmanagers/default.conf' contentscanner = '/etc/e2guardian/contentscanners/clamdscan.conf' contentscannertimeout = 60 contentscanexceptions = off recheckreplacedurls = off forwardedfor = off usexforwardedfor = off logconnectionhandlingerrors = on logsslerrors = off logchildprocesshandling = off maxchildren = 180 minchildren = 20 minsparechildren = 16 preforkchildren = 10 maxsparechildren = 32 maxagechildren = 500 maxips = 0 ipcfilename = '/tmp/.e2guardianipc' urlipcfilename = '/tmp/.e2guardianurlipc' ipipcfilename = '/tmp/.e2guardianipipc' nodaemon = off nologger = off logadblocks = off loguseragent = off softrestart = off mailer = '/usr/sbin/sendmail -t' cacertificatepath = '/etc/e2guardian/ssl/my_rootCA.crt' caprivatekeypath = '/etc/e2guardian/ssl/private_root.pem' certprivatekeypath = '/etc/e2guardian/ssl/private_cert.pem' generatedcertpath = '/var/log/e2guardian/generatedcerts/' /etc/e2guardian/e2guardianf1.conf changed: groupmode = 1 groupname = '' bannedphraselist = '/etc/e2guardian/lists/bannedphraselist' weightedphraselist = '/etc/e2guardian/lists/weightedphraselist' exceptionphraselist = '/etc/e2guardian/lists/exceptionphraselist' bannedsitelist = '/etc/e2guardian/lists/bannedsitelist' greysitelist = '/etc/e2guardian/lists/greysitelist' bannedsslsitelist = '/etc/e2guardian/lists/bannedsslsitelist' greysslsitelist = '/etc/e2guardian/lists/greysslsitelist' exceptionsitelist = '/etc/e2guardian/lists/exceptionsitelist' bannedurllist = '/etc/e2guardian/lists/bannedurllist' greyurllist = '/etc/e2guardian/lists/greyurllist' exceptionurllist = '/etc/e2guardian/lists/exceptionurllist' exceptionregexpurllist = '/etc/e2guardian/lists/exceptionregexpurllist' bannedregexpurllist = '/etc/e2guardian/lists/bannedregexpurllist' picsfile = '/etc/e2guardian/lists/pics' contentregexplist = '/etc/e2guardian/lists/contentregexplist' urlregexplist = '/etc/e2guardian/lists/urlregexplist' refererexceptionsitelist = '/etc/e2guardian/lists/refererexceptionsitelist' refererexceptionurllist = '/etc/e2guardian/lists/refererexceptionurllist' embededreferersitelist = '/etc/e2guardian/lists/embededreferersitelist' embededrefererurllist = '/etc/e2guardian/lists/embededrefererurllist' urlredirectregexplist = '/etc/e2guardian/lists/urlredirectregexplist' !! Not compiled !! authexceptionsitelist = '/etc/e2guardian/lists/authexceptionsitelist' !! Not compiled !! authexceptionurllist = '/etc/e2guardian/lists/authexceptionurllist' blockdownloads = off exceptionextensionlist = '/etc/e2guardian/lists/exceptionextensionlist' exceptionmimetypelist = '/etc/e2guardian/lists/exceptionmimetypel
Bug#882694: [sysadmin] Signatures on uncompressed archives
On 03/08/18 05:15, Uwe Kleine-König wrote: > Hello, > > I hope to have selected the right contact address for this mail, if not, > please tell me or forward accordingly. > > The kernel.org archive provides signatures for the software available > (which is great!). The method to verify these according to > > > https://www.kernel.org/category/signatures.html#using-gnupg-to-verify-kernel-signatures > > is to download the .tar.xz and the .tar.sign file, unxz the archive and > check the signature against the .tar file. > > For one this is inconvenient because most tools don't know > this scheme. In my case this is tooling from Debian to work with > upstream archives[1]. I know it's a problem for Debian, but changing this scheme for us would require significant retooling just as it would for Debian infra. The major upside of the current approach is that we are free to add new compressors, recompress existing archives with higher compression ratios, etc, without needing to re-sign all files. > But it also has an impact on security: As long as the signature isn't > verified I have to consider the .tar.xz "untrusted" and the less tools I > have to make operate on it the better. This scheme allows an attacker > that has control over a mirror to provide a .tar.xz that makes unxz do > undesirable things, see https://en.wikipedia.org/wiki/Zip_bomb for an > attack idea. Which is why we provide sha256sums.asc in each directory. Regards, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature
Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java
Le 08/03/2018 à 13:29, 殷啟聰 | Kai-Chung Yan a écrit : > I tried building Maven Dependency Tree 2.2 against Maven 3.x and found that > it uses removed APIs, and that patching it would make a huge code change. > Maybe someone else would have a better skill than me to do the job, but I > simply don't think this is a good or sustainable idea... It looks like Fedora has already done the job: https://src.fedoraproject.org/rpms/maven-plugin-bundle/blob/master/f/0001-Port-to-current-maven-dependency-tree.patch With this patch they build the bundle plugin 3.5.0 with maven-dependency-tree 3.0.
Bug#892787: python-asyncssh: CVE-2018-7749
Source: python-asyncssh Version: 1.11.1-1 Severity: grave Tags: patch security upstream Hi, the following vulnerability was published for python-asyncssh, although there should be not "servers" implemented in Debian depending on python3-asyncssh, still chosed an RC severity to have the fix certain included in next stable release (but expect that 1.12.1 land soon anyhow in unstable). CVE-2018-7749[0]: | The SSH server implementation of AsyncSSH before 1.12.1 does not | properly check whether authentication is completed before processing | other requests. A customized SSH client can simply skip the | authentication step. 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-2018-7749 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7749 [1] https://github.com/ronf/asyncssh/commit/c161e26cdc0d41b745b63d9f17b437f073bf7ba4 Regards, Salvatore
Bug#892786: linux,arm64: please enable modules needed for teres-i OSHW laptop
Source: linux Version: 4.15.4-1 Severity: wishlist Hi, I have the TERES I open hardware laptop from olimex https://www.olimex.com/Products/DIY-Laptop/ running with buster, but I had to recompile the kernel to get all the modules necessary to have a useable system. Mainlineing the devicetree file for the teres is work in progress, (see: https://lkml.org/lkml/2018/3/12/653 ) but most of the missing bit's in the kernel config are needed for all Allwinner A64 based boards anyway - many of which already have upstream support. Please enable the following configuration symbols for arm64 builds: 1) Relevant to all A64 based systems and other SoCs using the AXP803 PMIC: at least: CONFIG_MFD_AXP20X=y CONFIG_MFD_AXP20X_RSB=y CONFIG_REGULATOR_AXP20X=m CONFIG_INPUT_AXP20X_PEK=m (note about builtin vs. module: This is the combination I tested. It should be possible to have everything as modules so long as mkinitramfs puts them into the initrd. In theory we also need the regulator module in the initrd to power up the supply chain of the MMC hosts. In practice MMCs are already powered up by the boot loader, but we need at least the mfd part of the pmic driver, to get the kernel probing the devices. You might want to draw the line between builtin and module drivers in a saner way. I can test your configuration, once you have made up your mind.) probably also (untested yet, but will be demanded in the future obviously): CONFIG_PINCTRL_AXP209=m CONFIG_CHARGER_AXP20X=m CONFIG_BATTERY_AXP20X=m CONFIG_AXP20X_POWER=m CONFIG_AXP288_FUEL_GAUGE=m CONFIG_AXP20X_ADC=m CONFIG_AXP288_ADC=m 2) Relevant to A64 based systems, driver available since long and likely going to be enabled by default in upstream devicetrees starting with 4.17: CONFIG_SUNXI_WATCHDOG=m 3) Relevant at least to A64 based systems with backlight. Probably at the moment only the teres-i laptop: CONFIG_PWM_SUN4I=m CONFIG_BACKLIGHT_PWM=m 4) Maybe not relevant at the moment, but might be a sane default to include anyway: CONFIG_LEDS_PWM=m BTW, as you might have inferred from my message, I'm a bit unsure how you decide which drivers to enable. Do you have a script, that scan's the device trees for required drivers (if so it clearly failed to find the drivers listed in (1)), or do you rely solely on users speaking up when something is missing? Any hints on how to efficiently report missing drivers or upcoming upstream changes would be appreciated. Thanks for your consideration, Harald
Bug#892737: [Pkg-puppet-devel] Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Control: tags -1 - unreproducible moreinfo On 21:04 Mon 12 Mar , Mykola Nikishov wrote: > Package: puppet > Version: 5.4.0-1 > Followup-For: Bug #892737 > > I have librarian-puppet and found out that downgrading it to jessie > will fix the problem. Downgrade will remove ruby-puppet-forge and > ruby-gettext-setup. > > Seems ruby-gettext-setup causes this problem. Okay, it's actually ruby-semantic-puppet that resets the default text domain. Thanks for your feedback! Regards, Apollon
Bug#892785: zaqar-ui FTBFS: ImportError: No module named openstack_dashboard.test.settings
Source: zaqar-ui Version: 1.0.0~rc1-2 Severity: serious Tags: buster sid Some recent change in unstable makes zaqar-ui FTBFS: https://tests.reproducible-builds.org/debian/history/zaqar-ui.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/zaqar-ui.html ... debian/rules override_dh_auto_test make[1]: Entering directory '/build/1st/zaqar-ui-1.0.0~rc1' pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions py3versions: no X-Python3-Version in control file, using supported versions bash run_tests.sh -N --no-pep8 Running Zaqar UI tests Traceback (most recent call last): File "/build/1st/zaqar-ui-1.0.0~rc1/manage.py", line 23, in execute_from_command_line(sys.argv) File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 364, in execute_from_command_line utility.execute() File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 308, in execute settings.INSTALLED_APPS File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 56, in __getattr__ self._setup(name) File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 41, in _setup self._wrapped = Settings(settings_module) File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 110, in __init__ mod = importlib.import_module(self.SETTINGS_MODULE) File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) ImportError: No module named openstack_dashboard.test.settings Tests failed. make[1]: *** [debian/rules:10: override_dh_auto_test] Error 1
Bug#892784: zaqar FTBFS: test failures
Source: zaqar Version: 6.0.0-1 Severity: serious https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/zaqar.html ... == FAIL: zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_2___ zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_2___ -- _StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: action "queue_create", body {"queue_name": "skittle"}.}}} Traceback (most recent call last): File "/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py", line 50, in setUp self.assertEqual(201, resp['headers']['status']) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 201 != 204 == FAIL: zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_4__fail_ zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_4__fail_ -- _StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: action "queue_create", body {"queue_name": "skittle"}.}}} Traceback (most recent call last): File "/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py", line 50, in setUp self.assertEqual(201, resp['headers']['status']) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 201 != 204 == FAIL: zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_get_claim_nonexistent_queue zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_get_claim_nonexistent_queue -- _StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: action "queue_create", body {"queue_name": "skittle"}.}}} Traceback (most recent call last): File "/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py", line 50, in setUp self.assertEqual(201, resp['headers']['status']) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 201 != 204 == FAIL: zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_3__ zaqar.tests.unit.transport.websocket.v2.test_claims.ClaimsBaseTest.test_bad_claim_3__ -- _StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: action "queue_create", body {"queue_name": "skittle"}.}}} Traceback (most recent call last): File "/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_claims.py", line 50, in setUp self.assertEqual(201, resp['headers']['status']) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 201 != 204 == FAIL: zaqar.tests.unit.transport.websocket.v2.test_messages.MessagesBaseTest.test_post_invalid_ttl zaqar.tests.unit.transport.websocket.v2.test_messages.MessagesBaseTest.test_post_invalid_ttl -- _StringException: pythonlogging:'zaqar': {{{Response: API v2 txt, 204. Request: action "queue_create", body {"queue_name": "kitkat"}.}}} Traceback (most recent call last): File "/build/1st/zaqar-6.0.0/zaqar/tests/unit/transport/websocket/v2/test_messages.py", line 56, in setUp self.assertEqual(201, resp['headers']['status']) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 201 != 204 ===
Bug#892783: watcher FTBFS: test failures
Source: watcher Version: 1.4.1-3 Severity: serious https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/watcher.html ... == FAIL: watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_cached watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_cached -- _StringException: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "watcher/tests/common/test_clients.py", line 218, in test_clients_gnocchi_cached gnocchi = osc.gnocchi() File "watcher/common/exception.py", line 46, in wrapped return func(*args, **kw) File "watcher/common/clients.py", line 115, in gnocchi session=self.session) File "/usr/lib/python2.7/dist-packages/gnocchiclient/client.py", line 24, in Client return client_class(*args, **kwargs) TypeError: __init__() got an unexpected keyword argument 'interface' == FAIL: watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_endpoint watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_endpoint -- _StringException: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "watcher/tests/common/test_clients.py", line 211, in test_clients_gnocchi_diff_endpoint osc.gnocchi() File "watcher/common/exception.py", line 46, in wrapped return func(*args, **kw) File "watcher/common/clients.py", line 115, in gnocchi session=self.session) File "/usr/lib/python2.7/dist-packages/gnocchiclient/client.py", line 24, in Client return client_class(*args, **kwargs) TypeError: __init__() got an unexpected keyword argument 'interface' == FAIL: watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_vers watcher.tests.common.test_clients.TestClients.test_clients_gnocchi_diff_vers -- _StringException: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "watcher/tests/common/test_clients.py", line 202, in test_clients_gnocchi_diff_vers osc.gnocchi() File "watcher/common/exception.py", line 46, in wrapped return func(*args, **kw) File "watcher/common/clients.py", line 115, in gnocchi session=self.session) File "/usr/lib/python2.7/dist-packages/gnocchiclient/client.py", line 24, in Client return client_class(*args, **kwargs) TypeError: __init__() got an unexpected keyword argument 'interface' == FAIL: watcher.tests.common.test_service.TestService.test_build_topic_handler watcher.tests.common.test_service.TestService.test_build_topic_handler -- _StringException: Traceback (most recent call last): File "watcher/tests/common/test_service.py", line 94, in test_build_topic_handler dummy_service = service.Service(DummyManager) File "watcher/common/service.py", line 204, in __init__ self.conductor_topic, self.conductor_endpoints) File "watcher/common/service.py", line 249, in build_topic_handler access_policy=access_policy) File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 208, in get_rpc_server access_policy) File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 161, in __init__ raise TypeError("%s: endpoint=%s" % (errmsg, ep)) TypeError: 'target' is a reserved Endpoint attribute used for namespace and version filtering. It must be of type oslo_messaging.Target. Do not define an Endpoint method named 'target': endpoint= == FAIL: watcher.tests.common.test_service.TestService.test_init_service watcher.tests.common.test_service.TestService.test_init_service -- _StringException: Traceback (most recent call last): File "watcher/tests/common/test_service.py", line 101, in test_init_service dummy_service = service.Service(DummyManager) File "watcher/common/service.py", line 204, in __init__ self.conductor_topic, self.conductor_endpoints) File "watcher/common/service.py", line 249, in build_topic_handler access_policy=access_policy) File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 208, in get_rpc_server access_policy) File "/usr/lib/python2.7/dist-packages/oslo_messagi
Bug#884923: abiword: CVE-2017-17529
Jeremy, On Sun, Mar 11, 2018 at 08:45:42AM -0400, Jeremy Bicha wrote: > On Sun, Mar 11, 2018 at 8:40 AM, Salvatore Bonaccorso > wrote: > > Is abiword upstream still active? > > Yes. > > https://bugzilla.abisource.com/ > > Here's a git mirror of their svn repo. The git mirror is sometimes a > bit out of date. > https://github.com/AbiWord/abiword/commits/trunk Thanks, indeed for the pointer. Can you forward the issue to upstream? Regards, Salvatore
Bug#891511: ip route flush all does not work any more
On Mon, 12 Mar 2018 19:48:33 + Luca Boccassi wrote: > On Mon, 2018-03-05 at 08:51 -0800, Stephen Hemminger wrote: > > On Sun, 04 Mar 2018 22:07:37 + > > Luca Boccassi wrote: > > > > > On Mon, 26 Feb 2018 12:05:05 +0100 Wolfgang Walter > > @stw > > > m.de> wrote: > > > > Package: iproute2 > > > > Version: 4.15.0-2 > > > > > > > > Hello, > > > > > > > > after upgrading iproute2 from 4.14.1-2 to 4.15.0-2 > > > > > > > > ip route flush all > > > > > > > > seems not to work any more. It does not remove all ipv4 routes > > > > from > > > > > > the main > > > > table as it did before. Downgrading to 4.14.1-2 fixes the > > > > problem. > > > > > > > > Basically 4.15.0-2 removes the default route, but other routes > > > > are > > > > > > not > > > > removed. > > > > > > > > What still works is > > > > > > > > ip route flush table main > > > > > > > > > > > > Another thing which changed is that > > > > > > > > ip route ls all > > > > > > > > now does not show anything but the default route whereas it used > > > > to > > > > > > show all > > > > routes of the main table. > > > > > > Hi, > > > > > > Yes can confirm, it's easily reproduced. > > > > > > Stephen, do you know if is this a known change in behaviour? > > > > > > With 4.14.0: > > > > > > $ ip route ls all > > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 > > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > > metric 600 > > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > > 192.168.122.1 linkdown > > > > > > With 4.15.0: > > > > > > $ ip route ls all > > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 > > > > > > Further tests with 4.15.0: > > > > > > $ ip route ls table main > > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 > > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > > metric 600 > > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > > 192.168.122.1 linkdown > > > $ sudo ip route flush all > > > $ ip route ls all > > > $ ip route ls table main > > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > > metric 600 > > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > > 192.168.122.1 linkdown > > > > > > $ sudo ip route add default via 192.168.1.1 > > > $ ip route ls table main > > > default via 192.168.1.1 dev wlp2s0 > > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > > metric 600 > > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > > 192.168.122.1 linkdown > > > $ ip route ls all > > > default via 192.168.1.1 dev wlp2s0 > > > $ sudo ip route flush table main > > > $ ip route ls all > > > $ ip route ls table main > > > > Is it a kernel or iproute issue? Should be bisectable. > > Hi Stephen, > > It was caused by this commit: > > commit 9135c4d6037ff9f1818507bac0049fc44db8c3d2 > Author: Alexander Zubkov > Date: Sun Dec 17 12:09:00 2017 +0100 > > iproute: "list/flush/save default" selected all of the routes > > When running "ip route list default" and not specifying address family, > one will get all of the routes instead of just default only. The same > is for "exact default" and "match default". > > It behaves in such a way because default route with unspecified family > has the same all-zeroes value like no prefix specified at all. Thus > following code blindly ignores the fact, that prefix was actually > specified. > > This patch adds the flag PREFIXLEN_SPECIFIED to the default route too. > And then checks its value when filtering routes. > > > > Looking at the message, it looks like it might have been intentional? > But it looks like a backward-incompatible change to me > My expectation is that: # ip route flush is for flushing all routes. And the patch in question was for # ip route flush default The issue is that default means 0/0 (or::/0) which is also a wildcard for flushing all. Right now I am going to revert the original patch since it was only because ip didn't do what one user expected; not the same as breaking everyone else. pgprhkwai_wBZ.pgp Description: OpenPGP digital signature
Bug#890954: upload 65.0.3325.146-2
Please upload 65.0.3325.146-2 to experimental so we can test. Thanks.
Bug#886326: stretch-pu: package zssh/1.5c.debian.1-3.2+deb9u1
On Sat, Feb 10, 2018 at 07:20:51PM +0800, Boyuan Yang wrote: >... > As described in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769366#61 , Current > version > of zssh in Debian Stretch (on amd64 architecture, versioned > 1.5c.debian.1-3.2+b4) suffers from > RC bug #769366. I had little idea why this happened because a > no-change rebuild on Debian > Stretch would make zssh fully functional. >... > How does a rebuild solve it? I have no idea currently: It Just Works™. > I could have digged into > the problem but the time to be spent would not be efficient when a > simple rebuild solves it. > > I think those described above should make a stretch-pu for zssh reasonable. What actually fixed zssh in 1.5c.debian.1-4 is the following: * Bump debhelper compat to v10. After looking at the #388036 fix I tried v9 instead, and as expected this gave me a broken package, An actual fix would be something like: diff -Nru zssh-1.5c.debian.1/debian/control zssh-1.5c.debian.1/debian/control --- zssh-1.5c.debian.1/debian/control 2014-07-21 11:30:52.0 +0300 +++ zssh-1.5c.debian.1/debian/control 2018-03-12 22:33:59.0 +0200 @@ -2,7 +2,7 @@ Section: net Priority: optional Maintainer: Ben Wong -Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libncurses5-dev, libreadline-dev, autoconf, quilt +Build-Depends: cdbs, debhelper (>= 5), autotools-dev, libncurses5-dev, libreadline-dev, autoconf, quilt, dh-autoreconf Standards-Version: 3.7.2 Package: zssh diff -Nru zssh-1.5c.debian.1/debian/rules zssh-1.5c.debian.1/debian/rules --- zssh-1.5c.debian.1/debian/rules 2014-07-21 11:27:39.0 +0300 +++ zssh-1.5c.debian.1/debian/rules 2018-03-12 22:08:24.0 +0200 @@ -2,6 +2,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk +include /usr/share/cdbs/1/rules/autoreconf.mk include /usr/share/cdbs/1/rules/patchsys-quilt.mk DEB_INSTALL_DOCS_ALL += FAQ > Regards, > Boyuan Yang cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#892781: iselect: prefers slcurses over ncurses
Control: tags -1 + patch On 2018-03-12 21:12 +0100, Sven Joachim wrote: > Source: iselect > Version: 1.4.0-3 > > If libslang2-dev is installed on the build system, iselect's configure > script selects slcurses (slang's curses emulation) rather than ncurses, > which is not really desirable. Here is the relevant output: > > , > | CHECK: Curses Environment > | checking for additional include dir... none particular > | checking for additional library dir... none particular > | checking for grep that handles long lines and -e... /bin/grep > | checking for egrep... /bin/grep -E > | checking for ANSI C header files... yes > | checking for sys/types.h... yes > | checking for sys/stat.h... yes > | checking for stdlib.h... yes > | checking for string.h... yes > | checking for memory.h... yes > | checking for strings.h... yes > | checking for inttypes.h... yes > | checking for stdint.h... yes > | checking for unistd.h... yes > | checking ncurses/ncurses.h usability... no > | checking ncurses/ncurses.h presence... no > | checking for ncurses/ncurses.h... no > | checking for initscr in -lncurses... yes > | checking slcurses.h usability... yes > | checking slcurses.h presence... yes > | checking for slcurses.h... yes > | checking for SLcurses_initscr in -lslang... yes > | checking which Curses to use... S-Lang Curses > ` > > There is no ncurses/ncurses.h in Debian. The fix-ncurses-include-path.diff already took care of that for the header files in iselect, I have amended it to also correct the path in configure.in, which was enough to persuade "configure" to select ncurses rather than slcurses. :-) , | CHECK: Curses Environment | checking for additional include dir... none particular | checking for additional library dir... none particular | checking for grep that handles long lines and -e... /bin/grep | checking for egrep... /bin/grep -E | checking for ANSI C header files... yes | checking for sys/types.h... yes | checking for sys/stat.h... yes | checking for stdlib.h... yes | checking for string.h... yes | checking for memory.h... yes | checking for strings.h... yes | checking for inttypes.h... yes | checking for stdint.h... yes | checking for unistd.h... yes | checking ncurses.h usability... yes | checking ncurses.h presence... yes | checking for ncurses.h... yes | checking for initscr in -lncurses... yes | checking slcurses.h usability... yes | checking slcurses.h presence... yes | checking for slcurses.h... yes | checking for SLcurses_initscr in -lslang... yes | checking which Curses to use... GNU NCurses ` Cheers, Sven >From 4f1bc112817ccd00e456ab49d5ae6cec69f4 Mon Sep 17 00:00:00 2001 From: Sven Joachim Date: Mon, 12 Mar 2018 21:24:21 +0100 Subject: [PATCH] Also fix the path to ncurses.h in configure.in There is no ncurses/ncurses.h in Debian, and if libslang2-dev is installed on the build system, configure would prefer slcurses over ncurses. --- debian/patches/fix-ncurses-include-path.diff | 11 +++ 1 file changed, 11 insertions(+) diff --git a/debian/patches/fix-ncurses-include-path.diff b/debian/patches/fix-ncurses-include-path.diff index 4429533..7ef8e7a 100644 --- a/debian/patches/fix-ncurses-include-path.diff +++ b/debian/patches/fix-ncurses-include-path.diff @@ -22,3 +22,14 @@ Fixes the include path for the ncurses header files. #endif #ifdef USE_SLCURSES #include +--- iselect-1.3.1.orig/configure.in iselect-1.3.1/configure.in +@@ -61,7 +61,7 @@ x="none particular" + )dnl + AC_MSG_RESULT([$x]) + +-AC_CHECK_HEADER(ncurses/ncurses.h, HAVE_NCURSES_HEADER=YES, HAVE_NCURSES_HEADER=NO) ++AC_CHECK_HEADER(ncurses.h, HAVE_NCURSES_HEADER=YES, HAVE_NCURSES_HEADER=NO) + AC_CHECK_LIB(ncurses, initscr, HAVE_NCURSES_LIB=YES, HAVE_NCURSES_LIB=NO) + AC_CHECK_HEADER(slcurses.h, HAVE_SLCURSES_HEADER=YES, HAVE_SLCURSES_HEADER=NO) + OLIBS=$LIBS -- 2.16.2
Bug#892766: CVE-2017-15422
Control: tags 892766 + upstream fixed-upstream Hi Moritz, hi Laszlo, On Mon, Mar 12, 2018 at 07:54:37PM +0100, Moritz Muehlenhoff wrote: > Source: icu > Severity: grave > Tags: security > > Hi Laszlo, > https://chromereleases.googleblog.com/2017/12/stable-channel-update-for-desktop.html > refers to a ICU vulnerability, but there's little information what > fixes/fixed that. > > Could you reach out to upstream whether they've been in touch with them so > that > we can pinpoint this a specific task/commit? The upstream issue is now accessible, at https://bugs.chromium.org/p/chromium/issues/detail?id=774382 which refers to the interger overflow related to the persian calendar integer overflow, leading to oob read. The comment #16 indicates which change fixed the bug: https://bugs.chromium.org/p/chromium/issues/detail?id=774382#c16 which in turns would be integrated in the following upstream change: https://ssl.icu-project.org/trac/changeset/40654 Regards, Salvatore
Bug#892372: proftpd-mod-msg FTBFS with proftpd 1.3.6-1
On 09.03.2018 16:35, Francesco P. Lovergine wrote: > On Thu, Mar 08, 2018 at 05:27:10PM +0200, Adrian Bunk wrote: Hi, >> mod_msg.c:56:3: error: #error "mod_msg requires Controls support >> (--enable-ctrls)" >> # error "mod_msg requires Controls support (--enable-ctrls)" >> ^ >> > > This is another trivial fix, just s/USE_CTRLS/PR_USE_CTRLS/ in source. > Sorry, was not that easy. I'll contact tj directly; this module is not on github. Hilmar -- #206401 http://counter.li.org
Bug#892373: [INFO] Bug#892373: proftpd-mod-fsync FTBFS with proftpd 1.3.6-1
On 10.03.2018 08:44, Francesco Paolo Lovergine wrote: Hi Francesco, > Nave a look onto Castaglia's github repo > I've updated the git repo to 0.3, attached is the new orig.tar.gz. Hilmar -- #206401 http://counter.li.org proftpd-mod-fsync_0.3.orig.tar.gz Description: application/gzip
Bug#892371: proftpd-mod-vroot FTBFS with proftpd 1.3.6-1
On 09.03.2018 16:19, Francesco P. Lovergine wrote: > On Thu, Mar 08, 2018 at 05:25:20PM +0200, Adrian Bunk wrote: Hi Francesco, >> mod_vroot.c: In function 'vroot_pre_pass': >> mod_vroot.c:1651:7: error: 'pr_fs_t {aka struct fs_rec}' has no member >> named 'creat'; did you mean 'read'? >> fs->creat = vroot_creat; >> ^ >> > > This is fixed in 0.9.7, better upgrading. > I've pulled the two patches from github fixing this bug. They are in our git, feel free to upload. The new version does not bring many improvement IMHO, so this can be delayed. Hilmar -- #206401 http://counter.li.org
Bug#892781: iselect: prefers slcurses over ncurses
Source: iselect Version: 1.4.0-3 If libslang2-dev is installed on the build system, iselect's configure script selects slcurses (slang's curses emulation) rather than ncurses, which is not really desirable. Here is the relevant output: , | CHECK: Curses Environment | checking for additional include dir... none particular | checking for additional library dir... none particular | checking for grep that handles long lines and -e... /bin/grep | checking for egrep... /bin/grep -E | checking for ANSI C header files... yes | checking for sys/types.h... yes | checking for sys/stat.h... yes | checking for stdlib.h... yes | checking for string.h... yes | checking for memory.h... yes | checking for strings.h... yes | checking for inttypes.h... yes | checking for stdint.h... yes | checking for unistd.h... yes | checking ncurses/ncurses.h usability... no | checking ncurses/ncurses.h presence... no | checking for ncurses/ncurses.h... no | checking for initscr in -lncurses... yes | checking slcurses.h usability... yes | checking slcurses.h presence... yes | checking for slcurses.h... yes | checking for SLcurses_initscr in -lslang... yes | checking which Curses to use... S-Lang Curses ` There is no ncurses/ncurses.h in Debian. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.15.9-nouveau (SMP w/2 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)
Bug#892525: cups-daemon: Cannot print with HPLIP backend
Hello intrigeri, thank you for caring about the printing system. On Sat 10 Mar 2018 at 08:50:45 +0100, intrig...@debian.org wrote: > Package: cups-daemon > Version: 2.2.6-5 > Severity: normal > > Hi, > > for now this bug report is mostly a note to myself (and to whoever > wants to help investigating/fixing this problem). I don't know how much help I will be but I'll give it a try. > A few days ago on an up-to-date sid system I was unable to print with > the HPLIP backend. In the Journal I saw: > > /hpfax[4306]: [4306]: error: Failed to create /var/spool/cups/tmp/.hplip > > I don't know yet if this issue is AppArmor-related and will > investigate once I have access to that printer again in a few days. > /usr/lib/cups/backend/hpfax is supposed to be confined under the > third_party child profile which allows any "file" operation so in > theory AppArmor cannot trigger the above log line. Firstly: not being able to print and the error message may not be linked. Secondly: there is Debian bug report #789286: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789286 but it is not choc-a-bloc full of detail; the bug submitter wasn't pressed for details on any inability to print. Thirdly: LP #1490321 doesn't really lead anywhere: https://bugs.launchpad.net/hplip/+bug/1490321 Fourthly: FWIW, I'd guess AppArmor need not be involved. (But that is for you to decide). You should not need access to the printer. The wiki has details but it is only necessary in most cases to set up a print queue: lpadmin -p test -v file:/dev/null -E -m Then lp -d test and look at the error_log. Get the printer's PPD from 'lpinfo -m'. > (Probably unrelated, on cupsd startup I see: > > audit[14628]: AVC apparmor="DENIED" operation="capable" > profile="/usr/sbin/cupsd" pid=14628 comm="cupsd" capability=12 > capname="net_admin" > > I'll file a dedicated bug (+patch) for that one once I've confirmed > it's orthogonal to the HPLIP issue.) Not seen that. Cheers, Brian.
Bug#892782: CVE-2018-7728 / CVE-2018-7729 / CVE-2018-7730 / CVE-2018-7731
Package: libexempi3 Severity: important Tags: security There's a few denial of service bugs in exempi, please see https://security-tracker.debian.org/tracker/CVE-2018-7728 https://security-tracker.debian.org/tracker/CVE-2018-7729 https://security-tracker.debian.org/tracker/CVE-2018-7730 https://security-tracker.debian.org/tracker/CVE-2018-7731 Cheers, Moritz
Bug#892780: Several security issues
Source: cimg Severity: important Tags: security Please see these links for details and patches: https://security-tracker.debian.org/tracker/CVE-2018-7641 https://security-tracker.debian.org/tracker/CVE-2018-7640 https://security-tracker.debian.org/tracker/CVE-2018-7639 https://security-tracker.debian.org/tracker/CVE-2018-7638 https://security-tracker.debian.org/tracker/CVE-2018-7637 https://security-tracker.debian.org/tracker/CVE-2018-7589 https://security-tracker.debian.org/tracker/CVE-2018-7588 And then there's https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7587 where the upstream isn't clear, it would be great if you could clarify with upstream on the status. Cheers, Moritz
Bug#892779: libu2f-udev: Please support non-systemd
Package: libu2f-udev Version: 1.1.4-1 Severity: normal Dear Maintainer, The provided udev rules don't work if the system isn't running systemd. Instead, we have to do something like: ATTRS{idVendor}=="1050", GROUP="plugdev", MODE="0660" ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", GROUP="plugdev", MODE="0660" I'm not sure this is the best solution, but feature parity should be possible here. Thanks! -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (600, 'testing-debug'), (600, 'testing'), (400, 'unstable-debug'), (400, 'unstable'), (200, 'experimental-debug'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information
Bug#892778: phppgadmin: php need to recompile PHP using the --with-pgsql configure option
Control: tags -1 moreinfo Re: Norbert Schulz 2018-03-12 <152088427690.5326.6930878930288703978.report...@gondor.heim> > after istallation and configuration of phppgadmin the call of > http:///phppgadmin gives the following > information/(error) 'Your PHP installation does not support PostgreSQL. You > need to recompile PHP using the --with-pgsql configure > option.' Hi, this isn't phppgadmin's fault. Most likely, the php-pgsql module hasn't been enabled in your PHP installation. Christoph
Bug#892778: phppgadmin: php need to recompile PHP using the --with-pgsql configure option
Package: phppgadmin Version: 5.1+ds-2 Severity: normal Dear Maintainer, after istallation and configuration of phppgadmin the call of http:///phppgadmin gives the following information/(error) 'Your PHP installation does not support PostgreSQL. You need to recompile PHP using the --with-pgsql configure option.' Best regards Norbert -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 4.9.0-6-marvell 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) Versions of packages phppgadmin depends on: ii dpkg1.18.24 ii libapache2-mod-php 1:7.0+49 ii libapache2-mod-php7.0 [libapache2-mod-php] 7.0.27-0+deb9u1 ii libjs-jquery3.1.1-2 ii libphp-adodb5.20.9-1 ii php 1:7.0+49 ii php-pgsql 1:7.0+49 ii php7.0 [php]7.0.27-0+deb9u1 ii php7.0-pgsql [php-pgsql]7.0.27-0+deb9u1 Versions of packages phppgadmin recommends: ii apache2 [httpd] 2.4.25-3+deb9u3 Versions of packages phppgadmin suggests: ii postgresql 9.6+181+deb9u1 pn postgresql-doc pn slony1-bin -- Configuration Files: /etc/apache2/conf-available/phppgadmin.conf changed: Alias /phppgadmin /usr/share/phppgadmin DirectoryIndex index.php AllowOverride None Require all granted php_flag magic_quotes_gpc Off php_flag track_vars On #php_value include_path . AddType application/x-httpd-php .php Action application/x-httpd-php /cgi-bin/php AddType application/x-httpd-php .php Action application/x-httpd-php /cgi-bin/php /etc/phppgadmin/config.inc.php changed: http://www.postgresql.org/docs/%s/interactive/'; // Configuration for ajax scripts // Time in seconds. If set to 0, refreshing data using ajax will be disabled (locks and activity pages) $conf['ajax_refresh'] = 3; /** Plugins management * Add plugin names to the following array to activate them * Example: * $conf['plugins'] = array( * 'Example', * 'Slony' * ); */ $conf['plugins'] = array(); /* * Don't modify anything below this line * */ $conf['version'] = 19; ?> -- no debconf information
Bug#891511: ip route flush all does not work any more
On Mon, 2018-03-05 at 08:51 -0800, Stephen Hemminger wrote: > On Sun, 04 Mar 2018 22:07:37 + > Luca Boccassi wrote: > > > On Mon, 26 Feb 2018 12:05:05 +0100 Wolfgang Walter > @stw > > m.de> wrote: > > > Package: iproute2 > > > Version: 4.15.0-2 > > > > > > Hello, > > > > > > after upgrading iproute2 from 4.14.1-2 to 4.15.0-2 > > > > > > ip route flush all > > > > > > seems not to work any more. It does not remove all ipv4 routes > > > from > > > > the main > > > table as it did before. Downgrading to 4.14.1-2 fixes the > > > problem. > > > > > > Basically 4.15.0-2 removes the default route, but other routes > > > are > > > > not > > > removed. > > > > > > What still works is > > > > > > ip route flush table main > > > > > > > > > Another thing which changed is that > > > > > > ip route ls all > > > > > > now does not show anything but the default route whereas it used > > > to > > > > show all > > > routes of the main table. > > > > Hi, > > > > Yes can confirm, it's easily reproduced. > > > > Stephen, do you know if is this a known change in behaviour? > > > > With 4.14.0: > > > > $ ip route ls all > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > metric 600 > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > 192.168.122.1 linkdown > > > > With 4.15.0: > > > > $ ip route ls all > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 > > > > Further tests with 4.15.0: > > > > $ ip route ls table main > > default via 192.168.1.1 dev wlp2s0 proto static metric 600 > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > metric 600 > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > 192.168.122.1 linkdown > > $ sudo ip route flush all > > $ ip route ls all > > $ ip route ls table main > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > metric 600 > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > 192.168.122.1 linkdown > > > > $ sudo ip route add default via 192.168.1.1 > > $ ip route ls table main > > default via 192.168.1.1 dev wlp2s0 > > 169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown > > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.5 > > metric 600 > > 192.168.122.0/24 dev virbr0 proto kernel scope link src > > 192.168.122.1 linkdown > > $ ip route ls all > > default via 192.168.1.1 dev wlp2s0 > > $ sudo ip route flush table main > > $ ip route ls all > > $ ip route ls table main > > Is it a kernel or iproute issue? Should be bisectable. Hi Stephen, It was caused by this commit: commit 9135c4d6037ff9f1818507bac0049fc44db8c3d2 Author: Alexander Zubkov Date: Sun Dec 17 12:09:00 2017 +0100 iproute: "list/flush/save default" selected all of the routes When running "ip route list default" and not specifying address family, one will get all of the routes instead of just default only. The same is for "exact default" and "match default". It behaves in such a way because default route with unspecified family has the same all-zeroes value like no prefix specified at all. Thus following code blindly ignores the fact, that prefix was actually specified. This patch adds the flag PREFIXLEN_SPECIFIED to the default route too. And then checks its value when filtering routes. Looking at the message, it looks like it might have been intentional? But it looks like a backward-incompatible change to me -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#885823: evolution-rss: raising severity of gconf dependency bug
Control: severity -1 serious As announced [1], we are working to remove gconf from Debian. As part of this process, I am now raising the severity of this bug. Please try to port your package away from gconf. Otherwise, please consider requesting that your package be removed from Debian to help us complete this goal. [1] https://lists.debian.org/debian-devel/2018/02/msg00169.html On behalf of the Debian GNOME team, Jeremy Bicha
Bug#883027: flare-engine: new upstream release 0.20
Hi. It seems Flare 1.0 was just released with the new Empyrean Campaign. Let me know if you need help packaging the new version. On Wed, 29 Nov 2017 00:38:27 +0100 "Manuel A. Fernandez Montecelo" wrote: > Hi, > > 2017-11-29 0:23 GMT+01:00 Antoine Musso : > > Package: flare-engine > > Version: 0.19-3 > > Severity: wishlist > > > > Dear Maintainer, > > > > Upstream has released a new version 0.20 in August 2015. > > > > https://github.com/clintbellanger/flare-engine/releases > > Thanks for the suggestion. At the time they recommended to not update > to 0.20, to wait for 1.0, but I cannot find the reference now. > > They even have "Download 0.19" in the website, and conflicting views > on "what will happen next": > > http://flarerpg.org/blog/20140116 > > So I've been eagerly awaiting for something more recent than 0.20 for > a while, and thought about asking them. > > It would be great if you could ask them for the current plan, since > 0.20 is too old by now, if we refresh probably we want something more > recent. If not, I will try to remember in the next weeks -- quite > busy now. > > > Cheers. > -- > Manuel A. Fernandez Montecelo > >
Bug#892777: RFP: libjs-strophe.vcard -- strophe.js plugin which implements XEP-0054 VCard-temp
Package: wnpp Severity: wishlist * Package name: libjs-strophejs.vcard Version : 0.0.1 Upstream Author : "The strophe plugin developers" * URL : https://github.com/strophe/strophejs-plugin-vcard * License : MIT Programming Lang: JavaScript Description : strophe.js plugin which implements XEP-0054 VCard-temp Dependency for converse.js (#807275).
Bug#892776: RFP: libjs-strophe.register -- Strophe.js plugin for in-band registration (XEP-0077)
Package: wnpp Severity: wishlist * Package name: libjs-strophejs.register Version : 0.0.1 Upstream Author : "The strophe plugin developers" * URL : https://github.com/strophe/strophejs-plugin-register * License : MIT Programming Lang: JavaScript Description : Strophe.js plugin for in-band registration (XEP-0077) Dependency for converse.js (#807275).
Bug#892775: RFP: libjs-strophe.ping -- strophe.js plugin to provide XMPP Ping (XEP-0199)
Package: wnpp Severity: wishlist * Package name: libjs-strophejs.ping Version : 0.0.2 Upstream Author : "The strophe plugin developers" * URL : https://github.com/strophe/strophejs-plugin-ping * License : MIT Programming Lang: JavaScript Description : strophe.js plugin to provide XMPP Ping (XEP-0199) Dependency for converse.js (#807275).
Bug#892774: stretch-pu: package canna/3.7p3-14~deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu * Make cannakill a symlink to catdic, fixing the file conflict between canna-dbgsym and canna-utils-dbgsym. (Closes: #868541) diff -Nru canna-3.7p3/debian/canna.install canna-3.7p3/debian/canna.install --- canna-3.7p3/debian/canna.install2012-01-25 07:57:21.0 +0200 +++ canna-3.7p3/debian/canna.install2017-07-16 16:59:14.0 +0300 @@ -33,7 +33,6 @@ var/lib/canna/dic/canna/software.ctd var/lib/canna/dic/canna/suffix.ctd usr/bin/canlisp -usr/bin/cannakill usr/bin/crfreq usr/bin/crxdic usr/bin/crxgram diff -Nru canna-3.7p3/debian/changelog canna-3.7p3/debian/changelog --- canna-3.7p3/debian/changelog2015-10-05 12:19:37.0 +0300 +++ canna-3.7p3/debian/changelog2018-03-12 21:07:48.0 +0200 @@ -1,3 +1,19 @@ +canna (3.7p3-14~deb9u1) unstable; urgency=medium + + * QA upload. + * Rebuild for stretch. + + -- Adrian Bunk Mon, 12 Mar 2018 21:07:48 +0200 + +canna (3.7p3-14) unstable; urgency=medium + + * QA upload. + * Make cannakill a symlink to catdic, fixing the file conflict +between canna-dbgsym and canna-utils-dbgsym. (Closes: #868541) + * Add the missing lsb-base dependency to canna. + + -- Adrian Bunk Sun, 16 Jul 2017 16:59:14 +0300 + canna (3.7p3-13.1) unstable; urgency=medium * Non-maintainer upload to fix FTBFS. diff -Nru canna-3.7p3/debian/control canna-3.7p3/debian/control --- canna-3.7p3/debian/control 2015-10-05 12:11:44.0 +0300 +++ canna-3.7p3/debian/control 2017-07-16 16:59:14.0 +0300 @@ -12,7 +12,7 @@ Package: canna Architecture: any -Depends: ${misc:Depends}, ${shlibs:Depends}, adduser (>= 3.34), canna-utils +Depends: lsb-base, ${misc:Depends}, ${shlibs:Depends}, adduser (>= 3.34), canna-utils Suggests: canna-shion Description: input system for Japanese - server and dictionary Canna provides a unified user interface for Japanese input. It is based diff -Nru canna-3.7p3/debian/links canna-3.7p3/debian/links --- canna-3.7p3/debian/links2012-11-25 15:01:57.0 +0200 +++ canna-3.7p3/debian/links2017-07-16 16:59:14.0 +0300 @@ -1 +1,2 @@ -usr/bin/cannakill usr/bin/syncdic +usr/bin/catdic usr/bin/syncdic +usr/bin/catdic usr/bin/cannakill diff -Nru canna-3.7p3/debian/rules canna-3.7p3/debian/rules --- canna-3.7p3/debian/rules2013-06-08 22:15:37.0 +0300 +++ canna-3.7p3/debian/rules2017-07-16 16:59:14.0 +0300 @@ -59,8 +59,6 @@ (cd $(CURDIR)/debian/tmp/usr/bin/ && \ rm -f cpdic lsdic mkdic mvdic rmdic syncdic \ addwords delwords cannakill) - cp $(CURDIR)/debian/tmp/usr/bin/catdic \ - $(CURDIR)/debian/tmp/usr/bin/cannakill install -d -m 755 $(CURDIR)/debian/tmp/etc/canna/dics.dir.d install -m 644 $(CURDIR)/debian/tmp/var/lib/canna/dic/canna/dics.dir \ $(CURDIR)/debian/tmp/etc/canna/dics.dir.d/00canna.dics.dir
Bug#892773: RFP: libjs-strophe.disco -- strophe.js plugin for XEP-0030 Service Discovery
Package: wnpp Severity: wishlist * Package name: libjs-strophejs.disco Version : 0.0.2 Upstream Author : "The strophe plugin developers" * URL : https://github.com/strophe/strophejs-plugin-disco * License : MIT Programming Lang: JavaScript Description : strophe.js plugin for XEP-0030 Service Discovery Dependency for converse.js (#807275).
Bug#892772: live-boot: do_netsetup fails to detect ip address with ifconfig
Package: live-boot Version: 1:20170213 Severity: normal Tags: patch Dear Maintainer, The do_netsetup function in components/9990-networking.sh parses ifconfig to check if an IP address has been assigned. But the pattern matching does not work anymore on Stretch, so it always fails. I have opened a Merge Request on Salsa [1] with a fix from Sameer, a colleague of mine at $work. Thank you! -- Kind regards, Luca Boccassi [1] https://salsa.debian.org/live-team/live-boot/merge_requests/3 signature.asc Description: This is a digitally signed message part
Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Package: puppet Version: 5.4.0-1 Followup-For: Bug #892737 I have librarian-puppet and found out that downgrading it to jessie will fix the problem. Downgrade will remove ruby-puppet-forge and ruby-gettext-setup. Seems ruby-gettext-setup causes this problem. --8<---cut here---start->8--- librarian-puppet: Installed: 2.2.3-1 Candidate: 2.2.3-1 Version table: 2.2.3-2 70 60 tor+http://deb.debian.org/debian testing/main amd64 Packages 70 tor+http://deb.debian.org/debian unstable/main amd64 Packages *** 2.2.3-1 500 500 tor+http://deb.debian.org/debian stable/main amd64 Packages 100 /var/lib/dpkg/status 1.0.3-1 40 40 tor+http://deb.debian.org/debian jessie/main amd64 Packages 40 tor+http://deb.debian.org/debian oldstable/main amd64 Packages --8<---cut here---end--->8--- -- System Information: Debian Release: 9.4 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'stable'), (70, 'unstable'), (60, 'testing'), (50, 'experimental'), (40, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages puppet depends on: ii adduser 3.117 ii facter 3.10.0-3 ii hiera3.2.0-2 ii init-system-helpers 1.51 ii lsb-base 9.20170808 ii ruby 1:2.3.3 ii ruby-augeas 1:0.5.0-3+b5 ii ruby-deep-merge 1.1.1-1 ii ruby-shadow 2.5.0-1 Versions of packages puppet recommends: pn debconf-utils ii lsb-release9.20170808 ii ruby-selinux 2.7-2+b1 Versions of packages puppet suggests: pn ruby-hocon pn ruby-rrd -- Configuration Files: /etc/puppet/puppet.conf changed [not included] -- no debconf information
Bug#892771: RM: libgksu -- RoM; RoQA; unmaintained, security-sensitive
Package: ftp.debian.org X-Debbugs-Cc: libg...@packages.debian.org Please remove libgksu. See explanation at the related RM bug for gksu: https://bugs.debian.org/892768 On behalf of the Debian GNOME team, Jeremy Bicha
Bug#892770: RM: dolibarr/3.5.5+dfsg1-1+deb8u1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Same as #892024 for stretch, please also remove from jessie. Cheers, Moritz
Bug#890254: stretch update for gf2x
On Mon, Feb 12, 2018 at 05:51:03PM +, Debian Bug Tracking System wrote: >... > gf2x (1.2-4) unstable; urgency=medium > . >* Team upload. >* Actually disable HW-specific code also on i386. (Closes: #890254) >... Thanks a lot for fixing this bug for unstable. It is still present in stretch, could you also fix it there? Alternatively, I can fix it for stretch if you don't object. Thanks Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#892769: apcupsd: Exclusionary language in configuration files
Package: apcupsd Version: 3.14.14-0.3 Severity: minor Tags: upstream Can we get rid of the "We send an email message to root to notify him" language in the following configuration files? /etc/apcupsd/changeme /etc/apcupsd/commfailure /etc/apcupsd/commok /etc/apcupsd/offbattery /etc/apcupsd/onbattery I know the language is inherited from upstream, but it's jarring to see, every time I set up a new server, that the root user is assumed to be a "him". Furthermore, referencing "root" is less relevant now since Debian has replaced direct references to "root" in those files with a variable lookup for $SYSADMIN that is defined in /etc/apcupsd/apccontrol. Perhaps something more accurate (and automatically more gender neutral!) that encourages people to modify the $SYSADMIN variable in apccontrol rather than directly editing the referencing files, like: "An email notification is sent to the $SYSADMIN email address defined in /etc/apcupsd/apccontrol." -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/16 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) Versions of packages apcupsd depends on: ii init-system-helpers 1.48 ii libc62.24-11+deb9u1 ii libgcc1 1:6.3.0-18+deb9u1 ii libusb-0.1-4 2:0.1.12-30 ii libwrap0 7.6.q-26 Versions of packages apcupsd recommends: ii apcupsd-doc3.14.14-0.3 ii mailutils [mailx] 1:3.1.1-1 Versions of packages apcupsd suggests: pn apcupsd-cgi ii udev 232-25+deb9u1 -- Configuration Files: /etc/apcupsd/apcupsd.conf changed [not included] /etc/default/apcupsd changed [not included] -- no debconf information
Bug#892768: RM: gksu -- RoM; RoQA; unmaintained
Package: ftp.debian.org X-Debbugs-Cc: network-con...@packages.debian.org gksu has been deprecated for years. The intent of gksu is to allow running apps with elevated privileges but the recommended way to do that is for the app developer to use PolicyKit to request elevated privileges for the specific actions that need done instead of for the whole app to run as root. For the next major stable release of Debian (codenamed Buster), the Debian GNOME team plans to default to GNOME on Wayland where gksu does not even work. gksu is unmaintained (last upload 2014) and is considered a security vulnerability. Therefore, please remove it. On behalf of the Debian GNOME team, Jeremy Bicha
Bug#892766: CVE-2017-15422
Source: icu Severity: grave Tags: security Hi Laszlo, https://chromereleases.googleblog.com/2017/12/stable-channel-update-for-desktop.html refers to a ICU vulnerability, but there's little information what fixes/fixed that. Could you reach out to upstream whether they've been in touch with them so that we can pinpoint this a specific task/commit? Cheers, Moritz
Bug#892767: RM: network-config -- RoQA; unmaintained; depends on gksu
Package: ftp.debian.org X-Debbugs-Cc: network-con...@packages.debian.org Please remove network-config from Debian. It is the last thing keeping gksu in Debian unstable. The Debian GNOME team wants gksu removed since it is unmaintained and there are better ways (PolicyKit) to do security-sensitive actions. network-config's last upstream release was 10 years ago. network-config was orphaned in 2015 and then adopted by a Debian contributor. Since that initial upload, there have been no more uploads of the package. network-config was removed from Testing 6 months ago because of the gksu issue (bug originally filed almost 2 years ago). I emailed the Debian maintainer December 31 warning him about my intent to remove this package from Debian. I sent a follow-up two weeks later and again today. I received no response. https://bugs.debian.org/780195 Orphaned https://bugs.debian.org/822603 RC bug Thanks, Jeremy Bicha
Bug#874220: stretch update for openni2
On Mon, Sep 11, 2017 at 09:18:05PM +, Debian Bug Tracking System wrote: >... > openni2 (2.2.0.33+dfsg-10) unstable; urgency=medium > . >* Add patch for arm. > Thanks to Adrian Bunk (Closes: #874220) >... Thanks a lot for fixing this bug for unstable. It is still present in stretch, could you also fix it there? Alternatively, I can fix it for stretch if you don't object. Thanks Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#822603: Remove network-config from Debian?
I am filing a removal bug now. Please reply immediately if you object. Thanks, Jeremy Bicha On Tue, Jan 16, 2018 at 10:16 PM, Jeremy Bicha wrote: > On Sun, Dec 31, 2017 at 7:21 PM, Jeremy Bicha wrote: >> Hi, >> >> network-config was removed from Debian Testing because it depends on >> gksu [1]. The Debian GNOME team would like to remove gksu from Debian >> Unstable too but we need to fix or remove the reverse depends first. >> >> Can I file a Debian removal bug for network-config now? >> >> [1] https://bugs.debian.org/822603 >> >> Thanks, >> Jeremy Bicha > > network-config is now the last thing in Debian depending on gksu. The > Debian GNOME team wants to remove gksu since it is deprecated and no > longer maintained. Because network-config has already been removed > from Debian Testing since July for this issue and there has been no > response from the Debian maintainer for this package, I intend to > request that network-config be removed from Debian soon. It can be > reintroduced to Debian if this bug is fixed. > > Thanks > Jeremy Bicha
Bug#848315: ITP: node-cheerio -- Server-side jQuery implementation
Hi, node-domutils is in stable now. Do you still need a sponsor? Cheers
Bug#892765: aegisub: use lua or luajit
Package: src:aegisub Version: 3.2.2+dfsg-3 -- Dear maintainer, at the moment both liblua5.1-0-dev and libluajit-5.1-dev are required to build. I think one or the other exclusively should be enough. The best being to require first libluajit-5.1-dev if available and fallback on liblua5.1-0-dev. This way, aegisub will benefit from luajit's speed if possible but will build on more architectures as well thanks to lua's portability. Here is a patch for this. Also, right now, liblua5.1-0-dev is never used as pkg-config will only point to luajit which should be fixed I guess even if you're not interested in the patch. Last but not least, ppc64el's support in luajit is unsure in the long term, so with the patch, we ensure to be able to still have aegisub on this architecture even if luajit drops ppc64el support. Thanks, Regards. F. pgpogZFmf6X5o.pgp Description: PGP signature diff -Nru aegisub-3.2.2+dfsg/debian/control aegisub-3.2.2+dfsg/debian/control --- aegisub-3.2.2+dfsg/debian/control 2015-09-18 22:31:15.0 + +++ aegisub-3.2.2+dfsg/debian/control 2015-09-18 22:30:12.0 + @@ -22,8 +22,7 @@ libglu1-mesa-dev | libglu-dev, libhunspell-dev, libicu-dev, - liblua5.1-0-dev, - libluajit-5.1-dev, + libluajit-5.1-dev | liblua5.1-0-dev, libpulse-dev, libwxgtk3.0-dev, lua5.1 diff -Nru aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch --- aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch 2015-09-18 22:31:15.0 + +++ aegisub-3.2.2+dfsg/debian/patches/remove-vendor-luajit-dependency.patch 2015-09-18 22:30:12.0 + @@ -20,7 +20,7 @@ CFLAGS_LIBASS = @LIBASS_CFLAGS@ CFLAGS_LIBPULSE= @LIBPULSE_CFLAGS@ -CFLAGS_LUA = -I$(TOP)vendor/luajit/include -+CFLAGS_LUA = `pkg-config --cflags luajit` ++CFLAGS_LUA = `pkg-config --cflags luajit` `pkg-config --cflags lua51` CFLAGS_OPENAL = @OPENAL_CFLAGS@ CFLAGS_OSS = @OSS_CFLAGS@ CFLAGS_PORTAUDIO = @PORTAUDIO_CFLAGS@ @@ -29,7 +29,7 @@ LIBS_LIBASS= @LIBASS_LIBS@ LIBS_LIBPULSE = @LIBPULSE_LIBS@ -LIBS_LUA = $(TOP)vendor/luajit/src/libluajit.a -+LIBS_LUA = `pkg-config --libs luajit` ++LIBS_LUA = `pkg-config --libs luajit` `pkg-config --libs lua51` LIBS_OPENAL= @OPENAL_LIBS@ LIBS_PORTAUDIO = @PORTAUDIO_LIBS@ LIBS_PTHREAD = @PTHREAD_LIBS@ @@ -43,10 +43,10 @@ -$(d)auto4_lua_assfile.o_FLAGS := -I$(TOP)vendor/luajit/include -$(d)auto4_lua_dialog.o_FLAGS:= -I$(TOP)vendor/luajit/include -$(d)auto4_lua_progresssink.o_FLAGS := -I$(TOP)vendor/luajit/include -+$(d)auto4_lua.o_FLAGS := `pkg-config --cflags luajit` -+$(d)auto4_lua_assfile.o_FLAGS := `pkg-config --cflags luajit` -+$(d)auto4_lua_dialog.o_FLAGS:= `pkg-config --cflags luajit` -+$(d)auto4_lua_progresssink.o_FLAGS := `pkg-config --cflags luajit` ++$(d)auto4_lua.o_FLAGS := `pkg-config --cflags luajit` `pkg-config --cflags lua51` ++$(d)auto4_lua_assfile.o_FLAGS := `pkg-config --cflags luajit` `pkg-config --cflags lua51` ++$(d)auto4_lua_dialog.o_FLAGS:= `pkg-config --cflags luajit` `pkg-config --cflags lua51` ++$(d)auto4_lua_progresssink.o_FLAGS := `pkg-config --cflags luajit` `pkg-config --cflags lua51` $(src_OBJ): $(d)libresrc/bitmap.h $(d)libresrc/default_config.h pgp_fm3ypk_Ex.pgp Description: PGP signature
Bug#892764: stretch-pu: package i3-wm/4.13-1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu I would like to apply the attached update to the i3-wm package to satisfy a user request (#891919) for a backported upstream fix to address a crash when using window marks and restarting i3 in-place. Please let me know how to proceed. Thanks! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel, mipsel, arm64 Kernel: Linux 4.14.0-3-amd64 (SMP w/12 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) diff -Nru i3-wm-4.13/debian/changelog i3-wm-4.13/debian/changelog --- i3-wm-4.13/debian/changelog 2016-11-08 19:02:16.0 +0100 +++ i3-wm-4.13/debian/changelog 2018-03-12 19:16:41.0 +0100 @@ -1,3 +1,9 @@ +i3-wm (4.13-2) stable; urgency=medium + + * cherry-pick patch to “fix crash upon restart when using marks” (Closes: #891919) + + -- Michael Stapelberg Mon, 12 Mar 2018 19:16:41 +0100 + i3-wm (4.13-1) unstable; urgency=medium * New upstream release. diff -Nru i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch --- i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch 1970-01-01 01:00:00.0 +0100 +++ i3-wm-4.13/debian/patches/fix-mark-restart-crash.patch 2018-03-12 19:16:07.0 +0100 @@ -0,0 +1,112 @@ +Description: fix crash upon restart when using marks +Forwarded: not-needed +Origin: vendor, https://github.com/i3/i3/pull/2779/commits/a5d959cde44e88bffa23a93bdd174b07f280f0e9 +Author: hwangcc23 +Bug-Debian: 891919 + +--- + +From a5d959cde44e88bffa23a93bdd174b07f280f0e9 Mon Sep 17 00:00:00 2001 +From: +Date: Sun, 21 May 2017 14:34:29 +0800 +Subject: [PATCH] Fix the i3 crash caused by mark + restart commands + +This patch fixes the issue #2511(https://github.com/i3/i3/issues/2511). + +1). Memorize the marks, but only call con_mark once the container has finished parsing. (Credit: This is @Airblader's patch.) + +2). Add a test case 267-regress-mark-restart.t for regression test to check if mark and restart command crash i3. +--- + src/load_layout.c | 19 +-- + testcases/t/267-regress-mark-restart.t | 30 ++ + 2 files changed, 47 insertions(+), 2 deletions(-) + create mode 100644 testcases/t/267-regress-mark-restart.t + +diff --git a/src/load_layout.c b/src/load_layout.c +index f6f045d26..632c6ec76 100644 +--- a/src/load_layout.c b/src/load_layout.c +@@ -29,6 +29,8 @@ static bool parsing_focus; + static bool parsing_marks; + struct Match *current_swallow; + static bool swallow_is_empty; ++static int num_marks; ++static char **marks; + + /* This list is used for reordering the focus stack after parsing the 'focus' + * array. */ +@@ -148,6 +150,16 @@ static int json_end_map(void *ctx) { + floating_check_size(json_node); + } + ++if (num_marks > 0) { ++for (int i = 0; i < num_marks; i++) { ++con_mark(json_node, marks[i], MM_ADD); ++free(marks[i]); ++} ++ ++free(marks); ++num_marks = 0; ++} ++ + LOG("attaching\n"); + con_attach(json_node, json_node->parent, true); + LOG("Creating window\n"); +@@ -230,8 +242,10 @@ static int json_key(void *ctx, const unsigned char *val, size_t len) { + if (strcasecmp(last_key, "focus") == 0) + parsing_focus = true; + +-if (strcasecmp(last_key, "marks") == 0) ++if (strcasecmp(last_key, "marks") == 0) { ++num_marks = 0; + parsing_marks = true; ++} + + return 1; + } +@@ -261,7 +275,8 @@ static int json_string(void *ctx, const unsigned char *val, size_t len) { + char *mark; + sasprintf(&mark, "%.*s", (int)len, val); + +-con_mark(json_node, mark, MM_ADD); ++marks = srealloc(marks, (++num_marks) * sizeof(char *)); ++marks[num_marks - 1] = sstrdup(mark); + } else { + if (strcasecmp(last_key, "name") == 0) { + json_node->name = scalloc(len + 1, 1); +diff --git a/testcases/t/267-regress-mark-restart.t b/testcases/t/267-regress-mark-restart.t +new file mode 100644 +index 0..220d765b7 +--- /dev/null b/testcases/t/267-regress-mark-restart.t +@@ -0,0 +1,30 @@ ++#!perl ++# vim:ts=4:sw=4:expandtab ++# ++# Please read the following documents before working on tests: ++# • http://build.i3wm.org/docs/testsuite.html ++# (or docs/testsuite) ++# ++# • http://build.i3wm.org/docs/lib-i3test.html ++# (alternatively: perldoc ./testcases/lib/i3test.pm) ++# ++# • http://build.i3wm.org/docs/ipc.html ++# (or docs/ipc) ++# ++# • http://on
Bug#892762: zlib: rename stage1 profile to nobiarch
Source: zlib Version: 1:1.2.8.dfsg-5 Severity: minor Tags: patch User: helm...@debian.org Usertags: rebootstrap zlib uses the profile "stage1" for disabling multilib packages and thus easing architecture bootstrap. We noticed that "stage1" is a bad profile name, because it says nothing. It says "this is connected to bootstrapping somehow", but nothing more. Thus we started getting rid of "stage*" profiles and want to use descriptive profile names. What happens here is that multilib packages are disabled and that has a name (originally coined in the gcc packaging) "nobiarch". The "nobiarch" profile is already used by glibc and ncurses. It also is documented[1]. (The only other packages building multilibby stuff are blcr and readline.) Thus it would add consistency if zlib was using the same profile. Please consider applying the attached patch. Helmut [1] https://wiki.debian.org/BuildProfileSpec diff --minimal -Nru zlib-1.2.8.dfsg/debian/changelog zlib-1.2.8.dfsg/debian/changelog --- zlib-1.2.8.dfsg/debian/changelog2017-01-29 18:22:23.0 +0100 +++ zlib-1.2.8.dfsg/debian/changelog2018-03-12 18:37:53.0 +0100 @@ -1,3 +1,10 @@ +zlib (1:1.2.8.dfsg-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Rename profile stage1 to nobiarch. (Closes: #-1) + + -- Helmut Grohne Mon, 12 Mar 2018 18:37:53 +0100 + zlib (1:1.2.8.dfsg-5) unstable; urgency=low * Add loud warnings to the descriptions of all the multilib packages diff --minimal -Nru zlib-1.2.8.dfsg/debian/control zlib-1.2.8.dfsg/debian/control --- zlib-1.2.8.dfsg/debian/control 2017-01-29 18:22:23.0 +0100 +++ zlib-1.2.8.dfsg/debian/control 2018-03-12 18:37:51.0 +0100 @@ -4,7 +4,7 @@ Maintainer: Mark Brown Standards-Version: 3.9.8 Homepage: http://zlib.net/ -Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1) +Build-Depends: debhelper (>= 8.1.3~), binutils (>= 2.18.1~cvs20080103-2) [mips mipsel], gcc-multilib [amd64 i386 kfreebsd-amd64 mips mipsel powerpc ppc64 s390 sparc s390x] , dpkg-dev (>= 1.16.1) Package: zlib1g Architecture: any @@ -54,7 +54,7 @@ Package: lib64z1 Architecture: sparc s390 i386 powerpc mips mipsel -Build-Profiles: +Build-Profiles: Depends: ${shlibs:Depends}, ${misc:Depends} Replaces: amd64-libs (<< 1.4) Description: compression library - 64 bit runtime @@ -65,7 +65,7 @@ Package: lib64z1-dev Section: libdevel Architecture: sparc s390 i386 powerpc mips mipsel -Build-Profiles: +Build-Profiles: Depends: lib64z1 (= ${binary:Version}), zlib1g-dev (= ${binary:Version}), lib64c-dev, ${misc:Depends} Replaces: amd64-libs-dev (<< 1.4) Provides: lib64z-dev @@ -80,7 +80,7 @@ Package: lib32z1 Architecture: amd64 ppc64 kfreebsd-amd64 s390x -Build-Profiles: +Build-Profiles: Conflicts: libc6-i386 (<= 2.9-18) Depends: ${shlibs:Depends}, ${misc:Depends} Replaces: ia32-libs (<< 1.5) @@ -92,7 +92,7 @@ Package: lib32z1-dev Section: libdevel Architecture: amd64 ppc64 kfreebsd-amd64 s390x -Build-Profiles: +Build-Profiles: Conflicts: libc6-i386 (<= 2.9-18) Depends: lib32z1 (= ${binary:Version}), zlib1g-dev (= ${binary:Version}), lib32c-dev, ${misc:Depends} Provides: lib32z-dev @@ -108,7 +108,7 @@ Package: libn32z1 Architecture: mips mipsel -Build-Profiles: +Build-Profiles: Depends: ${shlibs:Depends}, ${misc:Depends} Description: compression library - n32 runtime zlib is a library implementing the deflate compression method found @@ -118,7 +118,7 @@ Package: libn32z1-dev Section: libdevel Architecture: mips mipsel -Build-Profiles: +Build-Profiles: Depends: libn32z1 (= ${binary:Version}), zlib1g-dev (= ${binary:Version}), libn32c-dev, ${misc:Depends} Provides: libn32z-dev Description: compression library - n32 - DO NOT USE EXCEPT FOR PACKAGING diff --minimal -Nru zlib-1.2.8.dfsg/debian/rules zlib-1.2.8.dfsg/debian/rules --- zlib-1.2.8.dfsg/debian/rules2017-01-29 18:22:17.0 +0100 +++ zlib-1.2.8.dfsg/debian/rules2018-03-12 18:37:49.0 +0100 @@ -34,7 +34,7 @@ CFLAGS += -O3 endif -ifeq (,$(filter stage1,$(DEB_BUILD_PROFILES))) +ifeq (,$(filter nobiarch,$(DEB_BUILD_PROFILES))) 32-ARCHS=amd64 ppc64 kfreebsd-amd64 s390x 64-ARCHS=s390 sparc i386 powerpc mips mipsel @@ -71,7 +71,7 @@ mn32=-mabi=n32 endif -endif # !stage1 +endif # !nobiarch UNALIGNED_ARCHS=i386 amd64 kfreebsd-i386 kfreebsd-amd64 hurd-i386 lpia ifneq (,$(findstring $(DEB_HOST_ARCH), $(UNALIGNED_ARCHS))) @@ -198,7 +198,7 @@ dh_compress -s dh_fixperms -s dh_makeshlibs -pzlib1g -V"zlib1g (>= 1:1.2.3.3.dfsg-1)" --add-udeb=zlib1g-udeb -ifeq (,$(filter stage1,$(DEB_BUILD_PROFILES))) +ifeq (,$(filter nobiarch,$(DEB_BUILD_PROFILES))) ifneq (,$(findstring $(DEB_HOST_ARCH), $(32-ARCHS))) dh_makeshlibs -plib32z1 -V"lib32z1 (>= 1:1.2.3.3.dfsg-1)" endif
Bug#892763: libpandoc-wrapper-perl should not use the stage1 profile
Source: libpandoc-wrapper-perl Version: 0.6.1-1 Severity: minor Tags: patch User: helm...@debian.org Usertags: rebootstrap libpandoc-wrapper-perl should not use the profile name "stage1". The reasoning can be found in a similar bug report against libpandoc-elements-perl (bug number pending). Please consider applying the attached patch. Helmut diff --minimal -Nru libpandoc-wrapper-perl-0.6.1/debian/changelog libpandoc-wrapper-perl-0.6.1/debian/changelog --- libpandoc-wrapper-perl-0.6.1/debian/changelog 2017-10-28 03:32:14.0 +0200 +++ libpandoc-wrapper-perl-0.6.1/debian/changelog 2018-03-12 19:00:25.0 +0100 @@ -1,3 +1,10 @@ +libpandoc-wrapper-perl (0.6.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Switch stage1 profile to nocheck. (Closes: #-1) + + -- Helmut Grohne Mon, 12 Mar 2018 19:00:25 +0100 + libpandoc-wrapper-perl (0.6.1-1) unstable; urgency=medium [ upstream ] diff --minimal -Nru libpandoc-wrapper-perl-0.6.1/debian/control libpandoc-wrapper-perl-0.6.1/debian/control --- libpandoc-wrapper-perl-0.6.1/debian/control 2017-10-28 03:30:07.0 +0200 +++ libpandoc-wrapper-perl-0.6.1/debian/control 2018-03-12 19:00:10.0 +0100 @@ -7,10 +7,10 @@ libmodule-build-tiny-perl, perl, # tests - libcapture-tiny-perl , - libpath-tiny-perl , - libpandoc-elements-perl , - libtest-exception-perl , + libcapture-tiny-perl , + libpath-tiny-perl , + libpandoc-elements-perl , + libtest-exception-perl , # runtime libfile-which-perl, libipc-run3-perl,
Bug#892761: libpandoc-elements-perl should not use the stage1 profile
Source: libpandoc-elements-perl Version: 0.33-2 Severity: minor Tags: patch User: helm...@debian.org Usertags: rebootstrap I noticed that libpandoc-elements-perl uses the "stage1" profile. We want to get rid of "stage*" profiles, because they are meaningless beyond "something with bootstrapping". In this case, it seems that the relevant dependencies are concerned with running a build-time test suite. We already have a documented[1] profile for that called "nocheck". When using it, one must also add "nocheck" to DEB_BUILD_OPTIONS which seems to be required here as well, but it is documented for the "nocheck" profile. Using the standard profile removes the need for checking whether "stage1" can be used safely, because "nocheck" requires that binary artifacts don't change. Please consider switching the profile in use. Helmut [1] https://wiki.debian.org/BuildProfileSpec diff --minimal -Nru libpandoc-elements-perl-0.33/debian/changelog libpandoc-elements-perl-0.33/debian/changelog --- libpandoc-elements-perl-0.33/debian/changelog 2017-08-28 19:52:28.0 +0200 +++ libpandoc-elements-perl-0.33/debian/changelog 2018-03-12 18:54:19.0 +0100 @@ -1,3 +1,10 @@ +libpandoc-elements-perl (0.33-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use nocheck profile for test dependencies. (Closes: #-1) + + -- Helmut Grohne Mon, 12 Mar 2018 18:54:19 +0100 + libpandoc-elements-perl (0.33-2) unstable; urgency=medium * Modernize Vcs-Browser field: Use git (not cgit) in path. diff --minimal -Nru libpandoc-elements-perl-0.33/debian/control libpandoc-elements-perl-0.33/debian/control --- libpandoc-elements-perl-0.33/debian/control 2017-08-28 19:49:33.0 +0200 +++ libpandoc-elements-perl-0.33/debian/control 2018-03-12 18:54:17.0 +0100 @@ -6,9 +6,9 @@ libmodule-build-tiny-perl, perl, # tests - libtest-exception-perl , - libtest-output-perl , - libtest-deep-perl , + libtest-exception-perl , + libtest-output-perl , + libtest-deep-perl , # runtime libhash-multivalue-perl, libipc-run3-perl,
Bug#880047: stretch update for postgrey
On Sat, Nov 25, 2017 at 10:36:10AM +, Debian Bug Tracking System wrote: >... > postgrey (1.36-5) unstable; urgency=medium > . >* debian/postgrey.init: create /var/run/postgrey if it > does not exist, patch provided by Laurent Bigonville . > (Closes: 756813, 880047) >... Thanks a lot for fixing this bug for unstable. It is still present in stretch, could you also fix it there? Alternatively, I can fix it for stretch if you don't object. An open question would be whether #867201 should then also be fixed in stretch, I've added Julien to the Cc. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#886328: live-boot: Please use /run/live instead of /lib/live/mount
On Fri, 23 Feb 2018 19:24:45 +0100 Raphael Hertzog wrote: > Hello, > > On Fri, 05 Jan 2018, intrigeri wrote: > > Benjamin Drung: > > > Therefore move /lib/live/mount to /run/live and skip the intermedia > > > /live mount points. This reduces code and complexity. > > > > As someone who had to repeatedly bang his head against exactly this > > part of the live-boot code (last time earlier this week), I can only > > agree with the proposed simplification idea. I didn't do a full code > > review though. > > I'm not familiar enough with this part either and I am unlikely to find > any obvious mistake. But I committed the patch anyway > > It would be nice if we could test the live-boot in git before I upload > it. > > Benjamin, did you test your changes with persistence enabled? > > To whoever is following, please test and report back. Thank you. Hi, I understand and appreciate the intent to simplify things - and by itself, I like the idea to move things to /run - but unfortunately changing mount points locations will break existing scripts. That is certainly the case for myself at $work - we have a lot of scripts to deal with installing&upgrading images, I've tested it, and they all break due to this change. In my case it's a derivative with proprietary bits, so I understand if that is treated as less important. But would it be possible to make this change optional, please? Or maybe have a backward-compatible symlinks? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#879198: Guide to installing
The following document: https://gist.github.com/gelim/a840a99d15cb765cb7b65105b72f00c4 is a guide to installing plain ShareLaTeX (without Docker). Basically, the author shows how to get the source for the Docker image and make the installation from it on a Ubuntu system. This would perhaps help a Debian packager. Note that this installation method is not supported by the upstream authors of ShareLaTeX (they only support installation of the Docker image provided by them). J.
Bug#892406: live-build: UEFI boot fails on SuperMicro dev board with AMI bios
On Sun, 2018-03-11 at 19:05 +0100, Thomas Schmitt wrote: > Hi, > > i managed to build a live-build ISO. > Its /boot/grub/efi.img contains > /efi/boot/bootia32.efi > /efi/boot/bootx64.efi > which both show by "strings" the embedded configuration with > search --file --set=root /.disk/info > The ISO 9660 filesystem contains a file > /.disk/info > > So the riddle is why this does not get into effect with that > particular > EFI implementation, and why a grub.cfg in the EFI System Partition > solves the problem. > > Does a debian-cd ISO boot properly on that EFI ? > E.g. > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9. > 4.0-amd64-netinst.iso > > > I meanwhile found out that the efi.img of debian-cd stems from > debian-cd_info.tar.gz created by > https://anonscm.debian.org/git/d-i/debian-installer.git/tree/build > /util/efi-image > and that its grub-mkimage run needs no -c option because it has an -m > option > with a grub.cfg file in the "memdisk" tarball. It's quite the same > tarball > as created by live-build in > https://salsa.debian.org/bluca/live-build/blob/master/scripts/buil > d/efi-image > > So it might be that debian-cd is affected as well. > If not, then differences between both ISOs might give hints about the > cause. > > > Have a nice day :) > > Thomas I am not sure why that EFI firmware is so picky - I'll try to find time and test a vanilla Debian image. Nevertheless, adding that grub.cfg file is necessary when using Secure Boot - the monolithic grub EFI image does not contain that string. It is built by this script in the grub2 repository: https://salsa.debian.org/grub-team/grub/blob/master/debian/build-efi-images Using that image is necessary with Secure Boot as that's what gets signed. Ubuntu has the same workaround in place. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#892413: nvidia-driver: PRIME Synchronization regression in 390.25 with kernel 4.15, fixed upstream
On 2018-03-12 17:28, Luca Boccassi wrote: > Yeah I suspected a new release would have happened soon so I didn't > have a look at that yet. > > I'll look at 390.42 as soon as possible, and if still necessary, check > that patch. It still applies ... module build test still running. > I don't use PRIME so I can't really say if it was broken or not at the > moment. Me neither ... Andreas
Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2
tags 796285 + pending thanks Fixed in Git, pending upload: https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b880cc522da37da97f8292fccadcd96e0432f372 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#826629: Fwd: [PATCH v5] Fix loading of module radeonfb on PowerMac
Control: tags -1 upstream confirmed pending -- Forwarded message -- On Tuesday, February 13, 2018 07:03:16 PM Mathieu Malaterre wrote: > When the linux kernel is build with (typical kernel ship with Debian > installer): > > CONFIG_FB=y > CONFIG_FB_OF=y > CONFIG_VT_HW_CONSOLE_BINDING=y > CONFIG_FB_RADEON=m > > The offb driver takes precedence over module radeonfb. It is then > impossible to load the module, error reported is: > > [ 96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007) > [ 96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem > 0x9800-0x9fff pref] > [ 96.551531] radeonfb (:00:10.0): cannot request region 0. > [ 96.551545] radeonfb: probe of :00:10.0 failed with error -16 > > This patch reproduce the behavior of the module radeon, so as to make it > possible to load radeonfb when offb is first loaded, see > commit a56f7428d753 ("drm/radeon: Add early unregister of firmware fb's"). > > Signed-off-by: Mathieu Malaterre > Link: https://bugs.debian.org/826629#57 > Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741 > Suggested-by: Lennart Sorensen > Cc: Bartlomiej Zolnierkiewicz > Cc: Benjamin Herrenschmidt > Cc: Tomi Valkeinen Patch queued for 4.17, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug#873160: python-pymad: pymad in stretch decodes to noise
On Wed, Aug 30, 2017 at 11:19:22AM +1000, Jamie Wilkinson wrote: > Bug 873673 contains the request to the release team. Did you make any progress preparing a 0.9-1+deb9u1 as advised by the release team? Thanks Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#892483: Moving to pkg-security
Preparing the package in pkg-security team. -- Alexander Kulak
Bug#892759: rpm can't handle packages built with zstd payloads
Package: rpm Version: 4.14.0+dfsg1-2 Severity: important Dear Maintainer, RPM v4.14 introduces support for packages compressed with zstd, and distributions are starting to consider/use it. However, for Debian to be able to be useful for building packages targeting these distributions, RPM needs to have zstd support enabled. Please enable zstd support so that packages using zstd will work on Debian. Thanks in advance. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.4-300.fc27.x86_64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rpm depends on: ii debugedit 4.14.0+dfsg1-2 ii libc6 2.27-1 ii libelf1 0.170-0.3 ii libpopt0 1.16-10+b2 ii librpm8 4.14.0+dfsg1-2 ii librpmbuild8 4.14.0+dfsg1-2 ii librpmio8 4.14.0+dfsg1-2 ii librpmsign8 4.14.0+dfsg1-2 ii perl 5.26.1-5 ii rpm-common4.14.0+dfsg1-2 ii rpm2cpio 4.14.0+dfsg1-2 rpm recommends no packages. Versions of packages rpm suggests: pn alien pn elfutils pn python pn rpm-i18n pn rpm2html pn rpmlint -- no debconf information
Bug#892760: antlr3: FTBFS with Java 9
Package: antlr3 Version: 3.5.2-8 Severity: normal User: debian-j...@lists.debian.org Usertags: default-java9 antlr3 fails to build with Java 9: [INFO] [INFO] Reactor Summary: [INFO] [INFO] ANTLR 3 Master build control POM ... SUCCESS [ 0.570 s] [INFO] ANTLR 3 Runtime SUCCESS [ 4.100 s] [INFO] ANTLR 3 Tool ... SUCCESS [ 6.755 s] [INFO] ANTLR 3 Maven plugin ... SUCCESS [ 1.580 s] [INFO] ANTLR 3 gUnit .. FAILURE [ 1.392 s] [INFO] ANTLR 3 gUnit Maven plugin . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 14.708 s [INFO] Finished at: 2018-03-12T17:41:21+01:00 [INFO] Final Memory: 12M/42M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar (default-cli) on project gunit: MavenReportException: Error while generating Javadoc: [ERROR] Exit code: 1 - ./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:30: error: package org.antlr.gunit.swingui.parsers does not exist [ERROR] import org.antlr.gunit.swingui.parsers.ANTLRv3Lexer; [ERROR] ^ [ERROR] ./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:31: error: package org.antlr.gunit.swingui.parsers does not exist [ERROR] import org.antlr.gunit.swingui.parsers.ANTLRv3Parser; [ERROR] ^ [ERROR] ./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:32: error: package org.antlr.gunit.swingui.parsers does not exist [ERROR] import org.antlr.gunit.swingui.parsers.StGUnitLexer; [ERROR] ^ [ERROR] ./antlr3/gunit/src/main/java/org/antlr/gunit/swingui/model/TestSuiteFactory.java:33: error: package org.antlr.gunit.swingui.parsers does not exist [ERROR] import org.antlr.gunit.swingui.parsers.StGUnitParser; [ERROR] ^ [ERROR] [ERROR] Command line was: /usr/lib/jvm/java-9-openjdk-amd64/bin/javadoc @options @packages [ERROR] [ERROR] Refer to the generated Javadoc files in './antlr3/gunit/target/apidocs' dir.