Bug#908463: [Pkg-privacy-maintainers] Bug#908463: torbrowser-launcher: Fails to start "Web Content" processes due to outdated AppArmor policy
On Sat, Sep 15, 2018 at 2:11 PM, intrigeri wrote: > Roger Shimizu: >> On Mon, Sep 10, 2018 at 11:58 PM, gregor herrmann wrote: >>> On Mon, 10 Sep 2018 10:43:32 -0400, Antoine Beaupré wrote: >>> After upgrading to 0.2.9-4, adequate complains: >>> >>> torbrowser-launcher: obsolete-conffile >>> /etc/apparmor.d/local/torbrowser.Tor.tor >>> torbrowser-launcher: obsolete-conffile >>> /etc/apparmor.d/local/torbrowser.Browser.plugin-container >>> torbrowser-launcher: obsolete-conffile >>> /etc/apparmor.d/local/torbrowser.Browser.firefox > >> Sorry, I don't have these errors when upgrading package. > > To reproduce, I think you need 1. adequate installed; > 2. upgrading from a specific version of the package. I confirmed I already had adequate installed previously. $ dpkg -l adequate Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--=-=-== ii adequate 0.15.1all Debian package quality testing tool On Sun, Sep 16, 2018 at 2:35 AM, gregor herrmann wrote: >> > After getting rid of them, I have a starting torbrowser again. >> > >> > Looks like some dpkg-maintscript-helper(1) magic is needed here ... >> >> Could you provide an example, or even patch? >> Thanks! > > After looking at the package/repo: > > The files under /etc/apparmor.d/local were created in 0.2.9-1 (with > the upstream import) and were removed in 0.2.9-2, probably with > 0016-Remove-apparmor-local-path-from-setup.py.patch. Or maybe with > debian/patches/0015-AppArmor-remove-boilerplate-from-local-override-file.patch. > Or with both :) > > This is somewhat confusing but 0.2.9-1 seems to be the only release > with > > drwxr-xr-x root/root 0 2018-01-29 15:17 ./etc/apparmor.d/local/ > -rw-r--r-- root/root 134 2018-01-28 19:33 > ./etc/apparmor.d/local/torbrowser.Browser.firefox > -rw-r--r-- root/root 133 2018-01-28 19:33 > ./etc/apparmor.d/local/torbrowser.Browser.plugin-container > -rw-r--r-- root/root 133 2018-01-28 19:33 > ./etc/apparmor.d/local/torbrowser.Tor.tor > > (That also means that adequate must have warned me earlier?) > > Anyway, these conffiles are not shipped any more; either that's a > mistake or they need to be properly removed. I tried to install 0.2.9-1 and upgrade to 0.2.9-4, but still didn't reproduced. I tested it again after enabling adequate by set 'Adequate::Enabled "true";' in /etc/apt/apt.conf.d/20adequate But same result. BTW. Old packages can be found on snapshot.d.o [1]. [1] http://snapshot.debian.org/package/torbrowser-launcher/ # dpkg -i torbrowser-launcher_0.2.9-1_amd64.deb (Reading database ... 272854 files and directories currently installed.) Preparing to unpack torbrowser-launcher_0.2.9-1_amd64.deb ... Unpacking torbrowser-launcher (0.2.9-1) over (0.2.9-1) ... Setting up torbrowser-launcher (0.2.9-1) ... Processing triggers for desktop-file-utils (0.23-1) ... Processing triggers for mime-support (3.60) ... Processing triggers for man-db (2.7.6.1-2) ... # dpkg -i torbrowser-launcher_0.2.9-4_amd64.deb (Reading database ... 272854 files and directories currently installed.) Preparing to unpack torbrowser-launcher_0.2.9-4_amd64.deb ... Unpacking torbrowser-launcher (0.2.9-4) over (0.2.9-1) ... Setting up torbrowser-launcher (0.2.9-4) ... Installing new version of config file /etc/apparmor.d/torbrowser.Browser.firefox ... Installing new version of config file /etc/apparmor.d/torbrowser.Browser.plugin-container ... Installing new version of config file /etc/apparmor.d/torbrowser.Tor.tor ... Processing triggers for desktop-file-utils (0.23-1) ... Processing triggers for mime-support (3.60) ... Processing triggers for man-db (2.7.6.1-2) ... > There is already debian/torbrowser-launcher.maintscript which IMO > needs three new lines: > > rm_conffile /etc/apparmor.d/local/torbrowser.Tor.tor 0.2.9-2~ > torbrowser-launcher > rm_conffile /etc/apparmor.d/local/torbrowser.Browser.plugin-container > 0.2.9-2~ torbrowser-launcher > rm_conffile /etc/apparmor.d/local/torbrowser.Browser.firefox 0.2.9-2~ > torbrowser-launcher > > Or maybe s/0.2.9-2~/0.2.9-5~/ , if I'm reading dpkg-maintscript-helper(1) > correctly. Thanks for the hint! I'll try this snippet. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#908124: libh2o-evloop-dev: Depends on libwslay to link but doesn't say so in pkg-config file
Control: reassign -1 libh2o-evloop0.13 2.2.5+dfsg1-6 Control: retitle -1 libh2o-evloop.so must be linked with libwslay Control: severity -1 serious On Thu, Sep 06, 2018 at 01:54:15PM +0200, Chris Hofstaedtler wrote: > Package: libh2o-evloop-dev > Version: 2.2.5+dfsg1-6 > Severity: important > > Hi, > > the libh2o-evloop shared library needs symbols from libwslay, but the > pkg-config file does not specify this. As such, downstream users of > libh2o-evloop need to manually add -lwslay to their command lines. > > Please add -lwslay to libh2o-evloop.pc. > > Errors etc: > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libh2o-evloop.so: > undefined reference to `wslay_event_want_read’. > ... Thanks for your report. The actual bug is that libh2o-evloop.so is not linked with libwslay: https://buildd.debian.org/status/fetch.php?pkg=h2o=amd64=2.2.5%2Bdfsg1-6=1528159162=0 ... dh_shlibdeps -a dpkg-shlibdeps: warning: symbol wslay_event_want_write used by debian/libh2o-evloop0.13/usr/lib/x86_64-linux-gnu/libh2o-evloop.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_context_server_init used by debian/libh2o-evloop0.13/usr/lib/x86_64-linux-gnu/libh2o-evloop.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_want_read used by debian/libh2o-evloop0.13/usr/lib/x86_64-linux-gnu/libh2o-evloop.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_recv used by debian/libh2o-evloop0.13/usr/lib/x86_64-linux-gnu/libh2o-evloop.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_context_free used by debian/libh2o-evloop0.13/usr/lib/x86_64-linux-gnu/libh2o-evloop.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_set_error used by debian/libh2o-evloop0.13/usr/lib/x86_64-linux-gnu/libh2o-evloop.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_send used by debian/libh2o-evloop0.13/usr/lib/x86_64-linux-gnu/libh2o-evloop.so.0.13.5 found in none of the libraries ... dpkg-shlibdeps: warning: symbol wslay_event_want_write used by debian/libh2o0.13/usr/lib/x86_64-linux-gnu/libh2o.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_recv used by debian/libh2o0.13/usr/lib/x86_64-linux-gnu/libh2o.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_send used by debian/libh2o0.13/usr/lib/x86_64-linux-gnu/libh2o.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_context_server_init used by debian/libh2o0.13/usr/lib/x86_64-linux-gnu/libh2o.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_want_read used by debian/libh2o0.13/usr/lib/x86_64-linux-gnu/libh2o.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_set_error used by debian/libh2o0.13/usr/lib/x86_64-linux-gnu/libh2o.so.0.13.5 found in none of the libraries dpkg-shlibdeps: warning: symbol wslay_event_context_free used by debian/libh2o0.13/usr/lib/x86_64-linux-gnu/libh2o.so.0.13.5 found in none of the libraries ... > Thanks, > Chris 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#908942: libio-socket-ssl-perl: FTBFS: Connection refused at t/verify_fingerprint.t line 49 and tests hang
-=| gregor herrmann, 17.09.2018 00:18:35 +0200 |=- > On Sun, 16 Sep 2018 14:42:05 +, Damyan Ivanov wrote: > > > The test passes a thousand runs if the server child ignores SIGPIPE, > > so this looks like the TLSv1.3 shutdown problem when the client makes > > a fast SSL shutdown without waiting for the confirmation from the > > server, then exits, then exits and the server sending its confirmation > > gets SIGPIPEd. > > > https://rt.cpan.org/Ticket/Display.html?id=126899 also talks about > issues around SIGPIPE. > And there's a new 2.060, maybe we should try and check from there. Oh, nice. Thanks for that notification. I was delving in internals trying to avoid ignoring SIGPIPE. Upstream seems to have gone the other way, ignoring SIGPIPE and documenting the situation. It it suits them, I think it is alright :) I'll run the test suite a hundred times and upload the new upstream release. -- dam
Bug#908986: npm: adequate reports broken symlinks for modules within npm
Package: npm Version: 5.8.0+ds3-1 Severity: normal Usertags: broken-symlink adequate User: debian...@lists.debian.org Dear Maintainer, While updating my system came across the following - $ adequate npm npm: broken-symlink /usr/share/npm/node_modules/.bin/mkdirp -> ../mkdirp/bin/cmd.js npm: broken-symlink /usr/share/npm/node_modules/.bin/nopt -> ../nopt/bin/nopt.js npm: broken-symlink /usr/share/npm/node_modules/.bin/opener -> ../opener/opener.js npm: broken-symlink /usr/share/npm/node_modules/.bin/rimraf -> ../rimraf/bin.js npm: broken-symlink /usr/share/npm/node_modules/.bin/semver -> ../semver/bin/semver npm: broken-symlink /usr/share/npm/node_modules/.bin/which -> ../which/bin/which npm: broken-symlink /usr/share/npm/node_modules/npm-lifecycle/node_modules/.bin/node-gyp -> ../node-gyp/bin/node-gyp.js Looking forward for the symlinks to be fixed. Thank you for maintaining the package in Debian. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (100, 'unstable-debug'), (100, 'experimental-debug'), (100, 'experimental'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages npm depends on: ii node-abbrev 1.0.9-1 ii node-ansi 0.3.0-2 ii node-ansi-regex 3.0.0-1 ii node-ansistyles 0.1.3-1 ii node-aproba 1.2.0-1 ii node-archy 1.0.0-1 ii node-bluebird 3.5.1+dfsg2-2 ii node-boxen 1.2.2-1 ii node-call-limit 1.1.0-1 ii node-config-chain 1.1.11-1 ii node-detect-indent 5.0.0-1 ii node-detect-newline 2.1.0-1 ii node-editor 1.0.0-1 ii node-from2 2.3.0-1 ii node-fs-vacuum 1.2.10-2 ii node-fs-write-stream-atomic 1.0.10-4 ii node-glob 7.1.2-6 ii node-graceful-fs4.1.11-1 ii node-gyp3.6.2-2 ii node-has-unicode2.0.1-2 ii node-hosted-git-info2.5.0-1 ii node-iferr 1.0.2-1 ii node-import-lazy3.0.0.REALLY.2.1.0-1 ii node-inflight 1.0.6-1 ii node-inherits 2.0.3-1 ii node-ini1.3.5-1 ii node-is-npm 1.0.0-1 ii node-json-parse-better-errors 1.0.2-2 ii node-jsonstream 1.3.2-1 ii node-latest-version 3.1.0-1 ii node-lazy-property 1.0.0-3 ii node-lockfile 0.4.1-1 ii node-lru-cache 4.1.1-2 ii node-marked-man 0.3.0-2 ii node-minimatch 3.0.4-3 ii node-mississippi3.0.0-1 ii node-mkdirp 0.5.1-1 ii node-move-concurrently 1.0.1-1 ii node-nopt 3.0.6-3 ii node-normalize-package-data 2.4.0-1 ii node-npmlog 4.1.2-1 ii node-once 1.4.0-2 ii node-opener 1.4.3-1 ii node-osenv 0.1.4-1 ii node-path-is-inside 1.0.2-1 ii node-promise-inflight 1.0.1-1 ii node-qw 1.0.1-1 ii node-read 1.0.7-1 ii node-read-package-json 2.0.13-1 ii node-request2.26.1-1 ii node-resolve-from 4.0.0-1 ii node-retry 0.10.1-1 ii node-rimraf 2.6.2-1 ii node-safe-buffer5.1.2-1 ii node-semver 5.5.1-1 ii node-semver-diff2.1.0-2 ii node-sha2.0.1-1 ii node-slide 1.1.6-2 ii node-sorted-object 2.0.1-1 ii node-ssri 5.2.4-2 ii node-stream-iterate 1.2.0-4 ii node-strip-ansi 4.0.0-1 ii node-tar4.4.4+ds1-2 ii node-text-table 0.2.0-2 ii node-uid-number 0.0.6-1 ii node-unique-filename1.1.0+ds-2 ii node-unpipe 1.0.0-1 ii node-validate-npm-package-name 3.0.0-1 ii node-which 1.3.0-2 ii node-wrappy 1.0.2-1 ii node-write-file-atomic 2.3.0-1 ii node-xdg-basedir3.0.0-1 ii node-yargs 10.0.3-2 ii nodejs 8.11.2~dfsg-1 npm recommends no packages. npm suggests no packages. -- no debconf information
Bug#908985: npm: adequate reports broken symlinks for modules within npm
Package: npm Version: 5.8.0+ds3-1 Severity: normal Usertags: broken-symlink adequate User: debian...@lists.debian.org Dear Maintainer, While updating my system came across the following - $ adequate npm npm: broken-symlink /usr/share/npm/node_modules/.bin/mkdirp -> ../mkdirp/bin/cmd.js npm: broken-symlink /usr/share/npm/node_modules/.bin/nopt -> ../nopt/bin/nopt.js npm: broken-symlink /usr/share/npm/node_modules/.bin/opener -> ../opener/opener.js npm: broken-symlink /usr/share/npm/node_modules/.bin/rimraf -> ../rimraf/bin.js npm: broken-symlink /usr/share/npm/node_modules/.bin/semver -> ../semver/bin/semver npm: broken-symlink /usr/share/npm/node_modules/.bin/which -> ../which/bin/which npm: broken-symlink /usr/share/npm/node_modules/npm-lifecycle/node_modules/.bin/node-gyp -> ../node-gyp/bin/node-gyp.js Looking forward for the symlinks to be fixed. Thank you for maintaining the package in Debian. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (100, 'unstable-debug'), (100, 'experimental-debug'), (100, 'experimental'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages npm depends on: ii node-abbrev 1.0.9-1 ii node-ansi 0.3.0-2 ii node-ansi-regex 3.0.0-1 ii node-ansistyles 0.1.3-1 ii node-aproba 1.2.0-1 ii node-archy 1.0.0-1 ii node-bluebird 3.5.1+dfsg2-2 ii node-boxen 1.2.2-1 ii node-call-limit 1.1.0-1 ii node-config-chain 1.1.11-1 ii node-detect-indent 5.0.0-1 ii node-detect-newline 2.1.0-1 ii node-editor 1.0.0-1 ii node-from2 2.3.0-1 ii node-fs-vacuum 1.2.10-2 ii node-fs-write-stream-atomic 1.0.10-4 ii node-glob 7.1.2-6 ii node-graceful-fs4.1.11-1 ii node-gyp3.6.2-2 ii node-has-unicode2.0.1-2 ii node-hosted-git-info2.5.0-1 ii node-iferr 1.0.2-1 ii node-import-lazy3.0.0.REALLY.2.1.0-1 ii node-inflight 1.0.6-1 ii node-inherits 2.0.3-1 ii node-ini1.3.5-1 ii node-is-npm 1.0.0-1 ii node-json-parse-better-errors 1.0.2-2 ii node-jsonstream 1.3.2-1 ii node-latest-version 3.1.0-1 ii node-lazy-property 1.0.0-3 ii node-lockfile 0.4.1-1 ii node-lru-cache 4.1.1-2 ii node-marked-man 0.3.0-2 ii node-minimatch 3.0.4-3 ii node-mississippi3.0.0-1 ii node-mkdirp 0.5.1-1 ii node-move-concurrently 1.0.1-1 ii node-nopt 3.0.6-3 ii node-normalize-package-data 2.4.0-1 ii node-npmlog 4.1.2-1 ii node-once 1.4.0-2 ii node-opener 1.4.3-1 ii node-osenv 0.1.4-1 ii node-path-is-inside 1.0.2-1 ii node-promise-inflight 1.0.1-1 ii node-qw 1.0.1-1 ii node-read 1.0.7-1 ii node-read-package-json 2.0.13-1 ii node-request2.26.1-1 ii node-resolve-from 4.0.0-1 ii node-retry 0.10.1-1 ii node-rimraf 2.6.2-1 ii node-safe-buffer5.1.2-1 ii node-semver 5.5.1-1 ii node-semver-diff2.1.0-2 ii node-sha2.0.1-1 ii node-slide 1.1.6-2 ii node-sorted-object 2.0.1-1 ii node-ssri 5.2.4-2 ii node-stream-iterate 1.2.0-4 ii node-strip-ansi 4.0.0-1 ii node-tar4.4.4+ds1-2 ii node-text-table 0.2.0-2 ii node-uid-number 0.0.6-1 ii node-unique-filename1.1.0+ds-2 ii node-unpipe 1.0.0-1 ii node-validate-npm-package-name 3.0.0-1 ii node-which 1.3.0-2 ii node-wrappy 1.0.2-1 ii node-write-file-atomic 2.3.0-1 ii node-xdg-basedir3.0.0-1 ii node-yargs 10.0.3-2 ii nodejs 8.11.2~dfsg-1 npm recommends no packages. npm suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/
Bug#908938: [WORKAROUND] alsa-utils: amixer does not unmute pulseaudio
Dnia September 16, 2018 6:00:46 PM UTC, Elimar Riesebieter napisał(a): >* Łukasz Stelmach [2018-09-16 17:56 +0200]: > >> Łukasz Stelmach writes: > >> The following command can be used as a workaround >> >> pactl set-sink-mute 0 toggle > >How do you unmute then? Both commands above, amixer and pactl, toggle (change the state to opposite) muting. Only amixer is somehow unable to flip from 'muted' to 'unmuted' properly. Hence, this report. -- Łukasz Stelmach z podróży
Bug#900819: gimp: Dependency on liblcms2-2 needs tightening
Control: reopen -1 Control: forcemerge -1 906731 Well a simple rebuild didn't work. I'm not sure what more we should be doing here. It feels clumsy if we need to bump the version of liblcms2-dev that gimp Build-Depends on every time there we do a gimp upload after a new lcms2 version in Debian. Thanks, Jeremy Bicha
Bug#908964: evince: reports "! SyncTeX Error : No file?" at startup
On Sun, Sep 16, 2018 at 11:48 PM Jason Crain wrote: > Evince recently updated its embedded copy of synctex and the new version is > more verbose. Debian's evince is actually using the distro copy of synctex now. Thanks, Jeremy Bicha
Bug#900579: RFS: libminini/1.2.a-1 [ITP]
Adam Borowski 于2018年9月16日周日 上午4:36写道： > > symbols file produces: > > > _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Ba > se 1.2.a-1 Hmm seems like a new symbol in gcc8... anyway fixed and reuploaded. Lintian clean and sbuild amd54/i386 passed. Thanks for your attention on this package.
Bug#908964: evince: reports "! SyncTeX Error : No file?" at startup
Control: forwarded -1 https://gitlab.gnome.org/GNOME/evince/issues/983 On September 16, 2018 1:34:14 PM MDT, Julian Gilbey wrote: >evince has recently regularly (always?) started reporting "! SyncTeX >Error : No file?" when I open a PDF to view it. I have no idea why >this would be; the PDF files in question are unrelated to TeX. Evince recently updated its embedded copy of synctex and the new version is more verbose.
Bug#908968: ext3grep: FTBFS with DH 10/11
Hi Adrian, Em dom, 16 de set de 2018 às 18:31, Adrian Bunk escreveu: > > > > ext3-grep fails to build from source when using debhelper 10 or 11. It > > builds > > fine with debhelper 11 and compat 9. > > compat 9 does not default to autoreconf. You are right. I forgot it... > > When building, the following error is shown: > > > > aclocal: error: non-option arguments are not accepted: '@ACLOCAL_CWFLAGS@'. > > aclocal: Try '/usr/bin/aclocal --help' for more information. > > autoreconf: aclocal failed with exit status: 1 > >... > > The fix should be something like: > - in Makefile.am replace @ACLOCAL_CWFLAGS@ with -I m4 > - copy the https://github.com/CarloWood/cwautomacros/tree/master/m4 > directory into ext3grep Working fine now! Thanks! I will send a team upload. Regards, Eriberto
Bug#908984: breezy: autopkgtests fail on 32 bit architectures
Source: breezy Version: 3.0.0~bzr7096-1 Severity: important X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Please investigate these autopkgtest failures on Ubuntu 18.10: https://autopkgtest.ubuntu.com/packages/b/breezy/cosmic/i386 https://autopkgtest.ubuntu.com/packages/b/breezy/cosmic/armhf Log excerpt (this is repeated many times) Traceback (most recent call last): OverflowError: Python int too large to convert to C long Thanks, Jeremy Bicha
Bug#908926: intel-mkl: [INTL:de] initial German debconf translation
control: tags -1 +pending Hi Helge, Thanks for the translation. Already fixed in git repo: 1d28203424cf7f84851157f7372ef00c39098d74
Bug#908983: libosinfo: Please upgrade to 1.2.0
Source: libosinfo Version: 1.1.0-1 Severity: wishlist Please upgrade libosinfo to 1.2.0. With this release you can drop the libsoup-gnome2.4-dev build dependency. In its place, you could add libcurl4-gnutls-dev but it's only used for 2 network tests which we don't want to run anyway. The tests are skipped unless the environment variable LIBOSINFO_NETWORK_TESTS is set. The git repo is now at https://gitlab.com/libosinfo/libosinfo/ https://gitlab.com/libosinfo/libosinfo/blob/master/NEWS Thanks, Jeremy Bicha
Bug#898969: dnssec-trigger: fails with OpenSSL 1.1.1 due to too-small key
Package: dnssec-trigger Version: 0.15+repack-1 Followup-For: Bug #898969 Control: retitle -1 dnssec-trigger: fails with OpenSSL 1.1.1 due to too-small key and unknown ca Control: severity -1 serious If I delete the existing keys and recreate them with dnssec-trigger- control-setup (since dnssec-triggerd-keygen is broken) and restart dnssec-triggerd, I get an error repeating over and over again: error: remote control failed ssl crypto error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca I realised this is because of my existing dnssec-trigger-panel process. I also noticed that the unbound TLS key is also insecure and needs to be replaced too otherwise dnssec-triggerd cannot control unbound to add forwarders and make other changes. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dnssec-trigger depends on: ii gir1.2-nm-1.0 1.12.2-3 ii libc6 2.27-6 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-02.58.0-3 ii libgtk2.0-0 2.24.32-3 ii libldns21.7.0-3+b2 ii libssl1.1 1.1.1-1 ii python3 3.6.5-3 ii python3-gi 3.28.3-1 ii python3-lockfile1:0.12.2-2 ii unbound 1.7.3-1 dnssec-trigger recommends no packages. dnssec-trigger suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#905090: wine-development: Causing SEGV when using Qt.
On Thu, Sep 6, 2018 at 8:49 PM Michael Gilbert wrote: > This might be this upstream bug: > https://bugs.winehq.org/show_bug.cgi?id=45199 > > 3.13 was the first version built with gcc8. You could try rebuilding > with either gcc7 or with -O1 instead of -O2. The latest upload 3.16-1 is built with -O1. Would you mind testing whether that has any effect on this problem? Best wishes, Mike
Bug#908982: ranger: new upstream version
Package: ranger Version: 1.8.1-0.2 Severity: normal from __future__ import ranger -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (510, 'unstable'), (510, 'testing'), (509, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ranger depends on: ii less487-0.1+b1 ii python 2.7.15-3 Versions of packages ranger recommends: ii file1:5.34-2 ii python-chardet 3.0.4-1 ii w3m-img 0.5.3-36+b1 Versions of packages ranger suggests: ii atool 0.39.0-7 ii caca-utils 0.99.beta19-2+b3 ii elinks 0.12~pre6-13 pn highlight ii poppler-utils 0.63.0-2 ii sudo 1.8.23-2 ii w3m0.5.3-36+b1 -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/python2.7/dist-packages/ranger/config/rc.conf (from ranger package) debsums: changed file /usr/lib/python2.7/dist-packages/ranger/config/rifle.conf (from ranger package) debsums: changed file /usr/lib/python2.7/dist-packages/ranger/container/directory.py (from ranger package) debsums: changed file /usr/lib/python2.7/dist-packages/ranger/core/linemode.py (from ranger package) debsums: changed file /usr/lib/python2.7/dist-packages/ranger/data/scope.sh (from ranger package)
Bug#908412: Followup
control: tag -1 confirmed control: severity -1 important On Sun, Sep 16, 2018 at 8:57 PM Jiri Palecek wrote: > I think this bug is caused by the addition of the Diablo patch. > Certainly, removing it fixed it. I already knew as much since it was the only substantive change in that upload. I agree that it is a sledgehammer taken to the problem it tries to solve, and I had already started working on it. Thank you for confirming that it causes breakage. Best wishes, Mike
Bug#908176: Bug#907925: jhead: Interger overflow while running jhead
Thanks a lot! Regards, Hanfang Salvatore Bonaccorso 于2018年9月17日周一 上午3:08写道： > Control: retitle 907925 jhead: CVE-2018-17088: Integer overflow in > gpsinfo.c while running jhead > Control: retitle 908176 jhead: CVE-2018-16554: Buffer overflow in > gpsinfo.c while running jhead > > Hi > > On Fri, Sep 07, 2018 at 10:48:26AM +0200, Salvatore Bonaccorso wrote: > > Control: retitle -1 jhead: CVE-2018-16554: Interger overflow while > running jhead > > I checked with MITRE on the relative CVE assignments for #907925 and > #908176 and MITRE confirmed they should be as follows: > > #907925: > jhead: CVE-2018-17088: Integer overflow in gpsinfo.c while running jhead > > #908176: > jhead: CVE-2018-16554: Buffer overflow in gpsinfo.c while running jhead > > Regards, > Salvatore >
Bug#908412: Followup
Hello,
I think this bug is caused by the addition of the Diablo patch.
Certainly, removing it fixed it.
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -870,6 +870,9 @@ static SHORT alloc_tls_slot( LDR_MODULE
size = dir->EndAddressOfRawData - dir->StartAddressOfRawData;
if (!size && !dir->SizeOfZeroFill && !dir->AddressOfCallBacks)
return -1;
+ if (!tls_dirs)
+ return -1;
+
for (i = 0; i < tls_module_count; i++)
{
if (!tls_dirs[i].StartAddressOfRawData &&
!tls_dirs[i].EndAddressOfRawData &&
I think the patch is simply wrong. It doesn't really fix any obvious bug
in the logic and certainly shouldn't "fix out-of-bounds read when
tls_dirs is empty" as the code already doesn't access tls_dirs when it
is empty, bc. tls_module_count should be zero then. The code that
follows clearly handles tls_dirs being null by allocating some memory
and setting tls_dirs.
If anything, the patch fixes Diablo by obstructing normal function of
the loader. I don't think that is a wise move to make.
Do you have any indication of an actual out-of-bounds read happening
there when running Diablo? Or what exactly were you thinking when
writing the patch? The messages on the board (
https://us.battle.net/forums/en/bnet/topic/20760475943?page=4) indicate
some Windows users also see crashes.
I suggest the patch should be abandoned.
Regards
Jiri Palecek
Bug#908353: ncbi-tools6 FTCBFS: uses the build architecture compiler
Andreas Tille writes: > I've applied the suggested patch in Git and would have uploaded. However, > for whatever reason the quilt patches do not apply and gbp buildpackage > fails. I give up here and leave the final upload to you. OK, thanks. I'm not sure why the patches didn't work for you, but will look into this report in general; my priority at the moment is just ncbi-entrez-direct, which has fallen badly behind. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#908818: [Pkg-zsh-devel] Bug#908818: Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)
Upstream has committed 551ff842721d6ca83727dbe6cd40178f46cc8201 (43464: Another attachtty() fix). I haven't been able to reproduce the issue so I can't confirm that commit fixes it.
Bug#902056: unable to user user shell with user's env
But at leas I'm not able to run user shell with user's home. 'sudo -su user' doesn't work and 'sudo -Esu user' saves my $HOME (and all my other env). -- sergio.
Bug#906852: proposed NMU
As TB60 hit stable, it's urgent to fix Firetray as well, as at least for my
use case Thunderbird became useless. (Ok, I use unstable on my GUI
machines, but most others don't.)
Here's a proposed NMU with the fix from
https://github.com/firetray-updates/FireTray
and my metadata fix at
https://github.com/firetray-updates/FireTray/pull/1
Alas, the debdiff is quite hairy -- Quantum Thunderbird required a lot of
changes, and the missing images were fatal. Thus, please do review!
I'll put it into DELAYED/7 so you'll be able to get applied-diff package
from https://ftp-master.debian.org/deferred/ -- and, so there's some clock
in case no one of you guys responds. But I'd really prefer if someone could
take a look, especially as the package in stable needs to be fixed as well.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
diff -Nru firetray-0.6.1+dfsg/debian/changelog
firetray-0.6.1+dfsg/debian/changelog
--- firetray-0.6.1+dfsg/debian/changelog2016-05-04 22:45:17.0
+0200
+++ firetray-0.6.1+dfsg/debian/changelog2018-09-17 00:58:46.0
+0200
@@ -1,3 +1,12 @@
+firetray (0.6.1+dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix for Thunderbird 60 (by Fritjof Toelstede, Gabriele, and me).
+Closes: #906852, #895451.
+ * Firefox and Iceweasel are no longer supported.
+
+ -- Adam Borowski Mon, 17 Sep 2018 00:58:46 +0200
+
firetray (0.6.1+dfsg-1) unstable; urgency=medium
[ foudfou ]
diff -Nru firetray-0.6.1+dfsg/debian/control firetray-0.6.1+dfsg/debian/control
--- firetray-0.6.1+dfsg/debian/control 2016-05-04 22:45:14.0 +0200
+++ firetray-0.6.1+dfsg/debian/control 2018-09-17 00:50:10.0 +0200
@@ -17,7 +17,9 @@
Breaks: ${xpi:Breaks}
Provides: ${xpi:Provides}
Enhances: ${xpi:Enhances}
-Description: system tray extension for Firefox, Thunderbird, etc.
- FireTray is a system tray extension for Firefox and related
- applications. It supports setting up a custom icon, hiding to the tray
- instead of closing, displaying the number of unread mails, and more.
+Description: system tray extension for Thunderbird
+ FireTray is a system tray extension for Thunderbird. It supports setting
+ up a custom icon, hiding to the tray instead of closing, displaying the
+ number of unread mails, and more.
+ .
+ FireFox and versions of Thunderbird prior to 57 are no longer supported.
diff -Nru
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch
---
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch
2016-05-04 22:45:39.0 +0200
+++
firetray-0.6.1+dfsg/debian/patches/0003-Do-not-ship-useless-winnt-files.patch
2018-09-09 12:40:48.0 +0200
@@ -6,11 +6,11 @@
src/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
-diff --git a/src/Makefile b/src/Makefile
-index 512f2f7..ff81aed 100755
a/src/Makefile
-+++ b/src/Makefile
-@@ -97,8 +97,6 @@ chrome_sources := $(chrome_sources_js)
\
+Index: firetray-0.6.1+dfsg/src/Makefile
+===
+--- firetray-0.6.1+dfsg.orig/src/Makefile
firetray-0.6.1+dfsg/src/Makefile
+@@ -97,8 +97,6 @@ chrome_sources := $(chrome_sources_js)
$(wildcard $(chrome_source_root)/skin/icons/*.png)
\
$(wildcard $(chrome_source_root)/skin/icons/*.svg)
\
$(wildcard
$(chrome_source_root)/skin/icons/linux/hicolor/22x22/*/*.png) \
@@ -19,7 +19,7 @@
$(wildcard $(chrome_source_root)/locale/*/*.dtd)
\
$(wildcard $(chrome_source_root)/locale/*/*.properties)
-@@ -111,9 +109,7 @@ modules_sources := $(wildcard $(modules_dir)/*.js)
\
+@@ -111,9 +109,7 @@ modules_sources := $(wildcard $(modules_
$(wildcard $(modules_dir)/ctypes/*.jsm) \
$(wildcard $(modules_dir)/ctypes/linux/*.jsm) \
$(wildcard $(modules_dir)/ctypes/linux/gtk?/*.jsm) \
diff -Nru firetray-0.6.1+dfsg/debian/patches/0004-TB60.patch
firetray-0.6.1+dfsg/debian/patches/0004-TB60.patch
--- firetray-0.6.1+dfsg/debian/patches/0004-TB60.patch 1970-01-01
01:00:00.0 +0100
+++ firetray-0.6.1+dfsg/debian/patches/0004-TB60.patch 2018-09-17
00:55:21.0 +0200
@@ -0,0 +1,3958 @@
+Description: Thunderbird 60 support
+ Thunderbirds below 57, Firefox, Ice*, SeaMonkey, ChatZilla and Zotero
+ are no longer supported.
+ .
+ Unsquashed patches are at https://github.com/firetray-updates/FireTray
+
Bug#902056: may be not a bug
Really I'm already not sure if this is a bug as sudo is alias to sudo -E, and $ /usr/bin/sudo -E ls works. -- sergio.
Bug#908981: libetonyek: Please package tools
Source: libetonyek Version: 0.1.8-1 Severity: normal Thanks for packaging libetonyek. The upstream sources include some useful command line tools under src/conv such as "key2text". The current packaging builds these tools, but then fails to actually include them in a binary package. There's even an unused libetonyek-tools.install, though the contents seem to have just been copied from the libvisio packaging: https://sources.debian.org/src/libetonyek/0.1.8-1/debian/libetonyek-tools.install/ Please add a libetonyek-tools binary package which includes these command line tools. Cheers, Olly
Bug#902056: should be "No ssh-agent could be contacted"
$ sudo ls ... /var/log/auth.log: sudo: pam_ssh_agent_auth: Beginning pam_ssh_agent_auth for user sergio sudo: pam_ssh_agent_auth: Attempting authentication: `sergio' as `sergio' using /etc/ssh/sudo_authorized_keys sudo: pam_ssh_agent_auth: Contacted ssh-agent of user sergio (1000) $ /usr/bin/sudo ls ... /var/log/auth.log: sudo: pam_ssh_agent_auth: Beginning pam_ssh_agent_auth for user sergio sudo: pam_ssh_agent_auth: Attempting authentication: `sergio' as `sergio' using /etc/ssh/sudo_authorized_keys sudo: pam_ssh_agent_auth: No ssh-agent could be contacted -- sergio.
Bug#908937: Info received (Bug#908937: ghostscript breaks ocrmypdf autopkgtest)
v6.2.4 is now available. On Sun, 16 Sep 2018 at 14:06 Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Sean Whitton > > If you wish to submit further information on this problem, please > send it to 908...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 908937: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908937 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#908980: transition: qrencode (ongoing, apparently uncoordinated)
Package: release.debian.org Severity: normal User:release.debian@packages.debian.org Usertags: transition Control: forwarded -1https://release.debian.org/transitions/html/auto-qrencode.html Control: block -1 by 908929 X-Debbugs-CC:qrenc...@packages.debian.org oops, send this to the list instead of the bug submission address, resending. Hi debian-release, I thought I would let you know that there appears to be a libqrencode transition going on and this transition seems to be uncoordinated (at least I can find no recent mention of it in the debian-release archives). An automated transition tracker has been set-up at https://release.debian.org/transitions/html/auto-qrencode.html It appears that no binnmus have been scheduled in Debian for this transition yet, the packages listed as "good" either don't depend on the shared library or had a sourceful upload since the libqrencode upload. Over in raspbian our auto-binnmuer did schedule binnmus for this transition. All of them built successfully. However google-authenticator uses libqrencode through dlopen/dlsym rather than through the headers provided by libqrencode, so it needs sourceful changes (to both the upstream source and debian/control). Seehttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908929
Bug#908979: jayway-jsonpath: FTBFS on all
package: jayway-jsonpath version: 2.0.0-4 severity: serious Hi, The latest version of jayway-jsonpath in unstable fails on all: https://buildd.debian.org/status/package.php?p=jayway-jsonpath Cheers, Ivo
Bug#908061: RFS: rapid-photo-downloader/0.9.11-1
On 2018-09-10 12:13:00, Antoine Beaupré wrote: > On 2018-09-08 14:37:00, Jörg Frings-Fürst wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> Hello Antoine, >> >> many thanks for your review. > > Hi! > > A pleasure working with you! > >> Am Mittwoch, den 05.09.2018, 13:01 -0400 schrieb Antoine Beaupré: >>> Control: owner -1 anar...@debian.org >>> >>> On 2018-09-05 18:39:07, Jörg Frings-Fürst wrote: >>> > -BEGIN PGP SIGNED MESSAGE- >>> > Hash: SHA512 >>> > >>> > Package: sponsorship-requests >>> > Severity: normal >>> > >>> > Dear mentors, >>> > >>> > I am looking for a sponsor for my package "rapid-photo- >>> > downloader" >>> >>> Hi! >>> >>> As the uploader for the package, I'll be happy to sponsor this. >>> >>> I've reviewed your changes and they seem mostly good. However, they >>> seem >>> to omit some changes I've uploaded to the git repository 4 weeks ago: >>> >>> https://salsa.debian.org/debian/rapid-photo-downloader >>> >>> ... namely: >>> >>> >> https://salsa.debian.org/debian/rapid-photo-downloader/commit/ff0358a5e0783fb2464391cd06d02021a881ccae >>> >> https://salsa.debian.org/debian/rapid-photo-downloader/commit/c0027837223b83325d653a59146e16d2206fcccf >>> >>> Those are necessary (I think?) to completely fix #900709. >>> >>> With those changes, I'll be happy to do the upload. >>> >> >> Sorry. I have first sync only the release 0.9.9-2. Your commits are now >> included. The package is uploaded to mentors[1]. > > Understood. I had a conflict when merging the code from salsa with yours > because you keep the removed patch commented out (I just removed the > line) in debian/patches/series. I've also removed the unused patches > from debian/patches so we have only this one patch remaining. > > Another thing that's missing from the above .dsc file is the > "python3-colour" Depends. Any idea why that's also missing? > > I've pushed my resulting merge to salsa for now. > >>> I would also encourage you to register on salsa.debian.org and upload >>> your changes there, as it will make future collaboration easier: it >>> would have avoided such confusion, for example. >>> >> >> I do not use salsa because of the existing user restrictions. > > What do you mean by that? Hi! Any update here? A. -- We live in capitalism. Its power seems inescapable. So did the divine right of kings. Any human power can be resisted and changed by human beings. Resistance and change often begin in art, and very often in our art—the art of words. - Ursula Le Guin
Bug#908978: openvswitch: FTBFS on armel, mips, mips64el, mipsel
package: openvswitch version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-3 severity: serious Hi, The latest version of openvswitch in unstable fails on armel, mips, mips64el, mipsel: https://buildd.debian.org/status/package.php?p=openvswitch Cheers, Ivo
Bug#908977: nbd-client: systemd doesn's start nbd exports
Package: nbd-client Version: 1:3.18-1 Severity: normal Without systemd /etc/init.d/nbd-client will start all shares from /etc/nbdtab at bootup. With systemd user need to manually add each share with "systemctl enable nbd@nbdX.service". Behaviour must be the same! Please make systemd to start all shares from nbdtab. While it's not fixed, please add brief explanation about "systemctl enable nbd@nbdX.service" workaround.
Bug#897755: fixed in fswatch 1.12.0+repack-3
Not still, again is the better word for. will fix it in the next days again. Cheers Alf
Bug#685706: libc-bin: order of /etc/ld.so.conf.d/*.conf
On 2018-09-16 02:38, Alexander Huynh wrote: > Hello all, > > I have a branch on Salsa [0] that would provide ordering for the two files I > currently see placed in /etc/ld.so.conf.d/: > > * libc.conf > * $(uname -m)-linux-gnu.conf > > I've also done a sweep of the rest of the repo, adding ordering to other files > that could appear in /etc/ld.so.conf.d/. This only changes the name of the files, which is the trivial part. As those are conf files, the problem is to handle them during the package upgrade, probably using dpkg-maintscript-helper. During the whole upgrade process, the biarch compat files (old or new version) should never have bigger priority than the corresponding native one, as it might render the libc unusable for some weird multiarch + multilib configurations. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#897072: RFS: btrfs-progs/4.17-1~bpo9+1
Hi Chris,
On Fri, Sep 14, 2018 at 07:44:30PM +0100, Chris Lamb wrote:
> Nicholas,
>
> > [I] wrote the attached convenience script ;-) Unfortunately the
> > script requires a manual 'apt policy package'
>
> Codswallop. *grin*
Indeed! :-D
> How about (untested):
>
> $ rmadison --suite=stretch-backports $(dpkg-parsechangelog -SSource) \
> | awk '{ print $3 }' | grep . || echo '0~'
Thank you, I didn't yet know about these parts of devscripts. I'll
get to work studying rmadison and will work on a backport script that
will get the latest version from stretch, stretch/updates, or
stretch-backports, then use that for the -v$LATEST_VERSION_IN_STRETCH,
and otherwise do the right thing for a package NEW to stretch.
rmadison has nice output so this looks possible with a single query!
Truly, thank you!
Nicholas
signature.asc
Description: PGP signature
Bug#908976: ITP: gost -- local copy tool of Security Tracker (Redhat/Debian) written in go)
Package: wnpp Owner: Nobuhiro Iwamatsu Severity: wishlist * Package name: gost Version : 0.1.0 Upstream Author : Teppei Fukuda * URL : https://github.com/knqyf263/gost * License : Expat Programming Lang: Go Description : local copy tool of Security Tracker (Redhat/Debian) written in go gost builds a local copy of Security Tracker(Redhat/Debian). After you register CVEs to watch list, gost notify via E-mail/Slack if there is an update. The pronunciation of gost is the same as the English word "ghost".
Bug#908942: libio-socket-ssl-perl: FTBFS: Connection refused at t/verify_fingerprint.t line 49 and tests hang
On Sun, 16 Sep 2018 14:42:05 +, Damyan Ivanov wrote: > The test passes a thousand runs if the server child ignores SIGPIPE, > so this looks like the TLSv1.3 shutdown problem when the client makes > a fast SSL shutdown without waiting for the confirmation from the > server, then exits, then exits and the server sending its confirmation > gets SIGPIPEd. https://rt.cpan.org/Ticket/Display.html?id=126899 also talks about issues around SIGPIPE. And there's a new 2.060, maybe we should try and check from there. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Sonny Terry: Playing With The Thing signature.asc Description: Digital Signature
Bug#908705: g_icon_to_string output includes some garbage prefix
Control: tags -1 + upstream confirmed On Fri, 14 Sep 2018 at 16:04:41 -0300, Damián Barberón wrote: > The patches pushed recently from the upstream fixes this. They have not been merged yet, so tagging this upstream rather than fixed-upstream. The merge request is: https://gitlab.gnome.org/GNOME/glib/merge_requests/305 smcv
Bug#908798: dbus-glib FTCBFS: fails running the host dbus-binding-tool
Control: tags -1 + pending On Fri, 14 Sep 2018 at 06:01:36 +0200, Helmut Grohne wrote: > I know that dbus-glib is deprecated, but I have one more bug report for > it: It fails to cross build. The reason is running the host > dbus-binding-tool. Now in the last upload, you split that out to > libdbus-glib-1-dev-bin and ./configure has an option > --with-dbus-binding-tool. And yes, that makes dbus-glib cross build > successfully. Please consider applying the attached patch. Applied (with a slightly expanded changelog message) for the next upload. Thanks, smcv
Bug#908975: column: outdated version lacking the option -o (--output-separator) implemented 5 years ago
Package: util-linux Version: 2.32.1-0.1 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I searched the internet for a way to format MarkDown tables in vim. I found a StackOverflow thread recommending to use the new version of 'column' with its -o option (output separator). Unfortuantely, even Buster still contains the outdated version. While vim may have alternative ways like the tabular plugin, other programs do not (for example the kakoune editor). links that may be helpful: The Launchpad page blames debian for incorrectly identifying the bsdutils version of column as the newer one: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1705437 The -o option was implemented 5 years ago: https://gitlab.apertis.org/packaging/util-linux/commit/47bd8ddc5b72739cf30f287ce84c984eb05b124e *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii fdisk 2.32.1-0.1 ii libaudit1 1:2.8.4-2 ii libblkid1 2.32.1-0.1 ii libc6 2.27-6 ii libmount1 2.32.1-0.1 ii libpam0g 1.1.8-3.8 ii libselinux12.8-1+b1 ii libsmartcols1 2.32.1-0.1 ii libsystemd0239-9 ii libtinfo6 6.1+20180714-1 ii libudev1 239-9 ii libuuid1 2.32.1-0.1 ii login 1:4.5-1.1 ii zlib1g 1:1.2.11.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.0.4-4 ii util-linux-locales 2.32.1-0.1 -- no debconf information
Bug#908974: Update qbittorrent package
Package: qbittorrent Version: 3.3.7 Hello, I'm part of qBittorrent team (https://github.com/qbittorrent/qBittorrent) We are in throubles because the qbittorrent versión in Debian repositories is really old and it has a lot of already fixed bugs. Every day we receive new issues related to that old package and they flooding us. We are only 5 develores with more tan 2500 issues open. Please, could you update the package? Thank you, regards.
Bug#908967: initramfs-tools: mount fails with rootfstype=auto
On Sun, 2018-09-16 at 20:26 +, Josua Mayer wrote: > Package: initramfs-tools > Version: 0.130 > Severity: normal > > Dear Maintainer, > > I encountered a strange problem mounting the rootfs with a freshly > debootstrapped system. > Note: possible duplicate of #845302 but due to the details I found it > probably warrants its own topic. [...] It's a similar issue, *but* for the root filesystem automatic detection is the default. Instead of "rootfstype=auto" you should not specify rootfstype at all. Ben. -- Ben Hutchings Humour is the best antidote to reality. signature.asc Description: This is a digitally signed message part
Bug#897755: fixed in fswatch 1.12.0+repack-3
found 897755 1.12.0+repack-5 thanks This is still happening in buster/sid, please see: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fswatch.html for details. Thanks.
Bug#908968: ext3grep: FTBFS with DH 10/11
On Sun, Sep 16, 2018 at 05:35:33PM -0300, Joao Eriberto Mota Filho wrote: > Package: ext3grep > Version: 0.10.2-3+b1 > Severity: important > Tags: upstream > > ext3-grep fails to build from source when using debhelper 10 or 11. It builds > fine with debhelper 11 and compat 9. compat 9 does not default to autoreconf. > When building, the following error is shown: > > aclocal: error: non-option arguments are not accepted: '@ACLOCAL_CWFLAGS@'. > aclocal: Try '/usr/bin/aclocal --help' for more information. > autoreconf: aclocal failed with exit status: 1 >... The fix should be something like: - in Makefile.am replace @ACLOCAL_CWFLAGS@ with -I m4 - copy the https://github.com/CarloWood/cwautomacros/tree/master/m4 directory into ext3grep > Regards, > > Eriberto >... 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#908973: osinfo-db: New upstream release 20180903
Source: osinfo-db Version: 0.20180628-1 Severity: wishlist There is a new 20180903 release for osinfo-db. I don't know if any other project uses it, but this data affects the ISOs available for download in the GNOME Boxes app. This update should allow for Ubuntu 18.04 LTS to be presented as an option there. Thanks, Jeremy Bicha
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
Yes, I can backport the 7.x fixes to the 6.x release branch upstream. The result is a loss of the ability to set or retain PDF metadata fields other than pure ASCII. All characters that can't be represented in ASCII are getting replaced with '?'. (As far as I can tell, the Ghostscript commit intended to removing Unicode metadata in DOCINFO for only PDF/A-1 but removed it for PDF/A-2 and A-3 as well, and this was likely not what they intended. I will report that separately in their bug tracker. It doesn't need to be dealt with in Debian.) On Sun, 16 Sep 2018 at 12:16 Sean Whitton wrote: > Hello, > > On Sun 16 Sep 2018 at 08:40PM +0200, Paul Gevers wrote: > > > Dear Sean, > > > > On 16-09-18 20:30, Sean Whitton wrote: > >> Paul: does preventing regressions in testing take precedence? > > > > Normally, yes temporarily (we are not blocking yet), but ghostscript was > > uploaded with urgency high. That means that regressions are ignored and > > without an RC bug, ghostscript will migrate to testing tomorrow (if my > > counting is correct). > > Thanks. I should have been clearer that I was asking about /all/ > regressions in testing, rather than just autopkgtests. > > >> If so, > >> this bug should be reassigned to ghostscript and raised to RC severity. > > > > I don't follow what you mean by this sentence. > > I meant that if preventing a test suite failure in testing took > priority, we would want to stop ghostscript from migrating. Anyway, > it's moot. > > > ocrmypdf can stay in testing as long as it doesn't have an RC bug itself. > > > > So just to make it clear: if this change making ocrmypdf totally > > unusable and you still want ghostscript to migrate to testing to fix > > multiple CVE's, than assigning this bug to ocrmypdf and raising it to RC > > level will start the autoremoval process. If you think it is worth > > searching for a solution in ghostscript to avoid it breaking ocrmypdf, > > than reassign this bug to ghostscript and raise the severity to RC level > > to avoid migration. > > Right. > > I don't know if OCRmyPDF in testing counts as RC-buggy right now, > because I don't know the ramifications of the GhostScript changes; I'm > going to wait on upstream. > > -- > Sean Whitton >
Bug#908972: RFA: hhvm -- HipHop Virtual Machine, a JIT replacement for PHP - main runtime
Package: wnpp Severity: normal We (the current maintainers, Faidon and myself) are orphaning HHVM. Upstream has shifted development focus from a generic PHP runtime towards providing a Hack runtime (https://en.wikipedia.org/wiki/Hack_(programming_language). It's not a simple package to maintain and the fast-paced development cycle makes it mostly unsuitable for inclusion to a stable release (there's an LTS release every six months which is then maintained for roughly a year only), but if anyone wants to adopt it, I'll be happy to give you an introduction. If there's no adopter by end of the year (end of the currently packaged 3.24 LTS branch), I'll request removal from the archive. Cheers, Moritz
Bug#908681: libsane1: pointless package rename
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Julien,
Am Mittwoch, den 12.09.2018, 16:14 +0200 schrieb Julien Cristau:
> Package: libsane1
> Severity: serious
>
> Hi,
>
> libsane was renamed to libsane1 for apparently no good
> reason. Renames
> for library packages should be tied to ABI breakage (and associated
> SONAME changes).
>
According to Debian Policy 8.6.2, renaming of the SONAME and the
library package name is possible for non-backwards compatible ABI
changes.
The SONAME is for a longer time 1:
$ objdump -p ./libsane.so.1.0.27 | grep SONAME
SONAME libsane.so.1
$ objdump -p ./libsane.so.1.0.25 | grep SONAME
SONAME libsane.so.1
Between libsane.so.1.0.25 and libsane.so.1.0.27 are some symbols
removed. Therefore the change the library from libsane to libsane1
are possible.
> Either there was ABI breakage and the SONAME should be bumped (and
> Provides: libsane would be wrong), or there wasn't and the package
> name
> change ought to be reverted.
>
The changes
- -Breaks: libsane (<<1.0.27-1)
- -Replaces: libsane (<<1.0.27-1)
- -Pre-Depends: ${misc:Pre-Depends}
+Conflicts: libsane (<< 1.0.27-1~)
+Replaces: libsane (<< 1.0.27-1~)
+Provides: libsane (= ${binary:Version})
were requested by Jeremy Bicha and taken over after consultation with
my mentor.
> I don't know which it is, and when I asked I didn't get a clear
> answer,
> so I'll ask again here.
>
> Cheers,
> Julien
CU
Jörg
- --
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56
Old pgp Key: BE581B6E (revoked since 2014-12-31).
Jörg Frings-Fürst
D-54470 Lieser
git: https://jff.email/cgit/
Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst
My wish list:
- Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluewxkACgkQCfifPIyh
0l2hrxAAukOnYhcZIW8DUY3k/3f3l+7OcWrZs2fS3nvg3NvxGAVIATksbFXswCAm
o0G+LFRUOrZWwgnIMxTL85acnszIZ3u8RglmWbKjlmK5wJ/d8xeefU4ZizrWHVJY
g7HBI7tgkXk2H2eVmVIMT3B+hiVSBSShpTi1x3Mhq0IYs/1j8dlDNQ7tvU3iPkoU
75UoZQC55JS15CZLE6LAqESqgP9FPtSlAvHdLUqF9hS5jITdUpLr+Fbxg0fYszQq
rw+8+yw6BYumkfGhru4wC9BisxpfL8wjsmNQkeat2H02+X/93NaZvl6TNApe6Any
gCPVRHlAyyEUbfgfONLsGkP2aKV07izc+RSg9jwW5qDat+tM1qjT4MfXxWNnGz22
dKSjcOhudut8807R6M2e/6yJpOPAumXMOLjY7UPmfmgxKsbFsDgCH2+IWL0xFnkG
yGj6zHrjCOzO2zIBmtcxG6CdeYTCp+k95QKKTTQEPG9x9POy9wBjN+HC95r7L7Bh
Ne9yueBoKgSYxXhfuENXvwHJvKfVPAcH6jKlhYUegS0XGTkKliGhCdC4K0clxMA7
Vfph57wuU535j3rZCRI/l1s8vvUxeh4THT597xNMS3U2jz2ksLM9h+PEJy+Lx9hB
yJOdWv0dTvG7C7acflepG1yL3FuDMKauYPVvhz9BADKGcahpCBM=
=C/cV
-END PGP SIGNATURE-
Bug#907568: dmesg: bad localization on --help
Control: tags -1 + upstream l10n Hi Robbie Harwood, Thanks for your bug report regarding dmesg localization. This is not a debian specific issue, so could you please submit your problem description directly to upstream where it can be fixed? Thanks. You'll find information about upstream in https://sources.debian.org/src/util-linux/2.32.1-0.1/debian/upstream/metadata/ (which you can ofcourse also obtain via 'apt-get source util-linux'). Regards, Andreas Henriksson
Bug#908583: auto-multiple-choice: Suggestion to set (or allow setting) catalog tags above the question
Control: forwarded -1 https://project.auto-multiple-choice.net/issues/588 This looks sensible: thanks. Forwarded to the upstream bugtracker. Regards, Alexis Bienvenüe.
Bug#905528: Bug #905528,mount: nofail
Control: tags -1 + upstream wontfix Hi, On Thu, Aug 23, 2018 at 12:59:43PM -0400, Phillip Susi wrote: > reopen 905528 > reassign 905528 util-linux > retitle 905528 nofail flag description misleading > thanks > > I misunderstood the description before. I interpreted it as using > nofail still causes boot failure. After offline discussion with the > reporter, he was saying that the man page for mount and fstab both say > that the nofail flag means "do not report errors for this device if it > does not exist". This is true for mount as it simply reports an error ( > or not ) and moves on. Agreed, but then ofcourse the caller of mount could handle this is who knows how many ways > However, since systemd is doing the mounting > these days, its behavior without nofail is not to simply report an error > and move on, but to hold up the boot process waiting for the device to > appear. It would be nice if at least the fstab man page would note the > systemd behavior so it does not make it sound like the only thing that > will happen if you don't use nofail is to get an error message. I don't think it's util-linux place to document how systemd (or any other similar system) works. Certainly not as a downstream debian patch. In my opinion this is basically a misdirected bug report that I'd suggest tag wontfix and close. Ofcourse if someone comes up with a suggested wording and submits it to the upstream mailing list chances are probably high that something fruitful will come out of that. Regards, Andreas Henriksson
Bug#908970: spamassassin: CVE-2018-11780: potential remote code execution bug with the PDFInfo plugin
Source: spamassassin Version: 3.4.1-1 Severity: grave Tags: security Hi, The following vulnerability was published for spamassassin. CVE-2018-11780[0]: potential remote code execution bug with the PDFInfo plugin It is fixed in new upstream version 3.4.2. 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-11780 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11780 [1] https://www.openwall.com/lists/oss-security/2018/09/16/1 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#833856: refind: diff for NMU version 0.11.2-1.1
Control: tags 900712 + patch
Dear maintainer,
I've prepared an NMU for refind (versioned as 0.11.2-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.
I’ve pushed the change in the nmu_l10n branch on Salsa.
Regards.
David
diff -Nru refind-0.11.2/debian/changelog refind-0.11.2/debian/changelog
--- refind-0.11.2/debian/changelog 2017-12-04 13:39:01.0 -1000
+++ refind-0.11.2/debian/changelog 2018-08-31 20:59:13.0 -1000
@@ -1,3 +1,28 @@
+refind (0.11.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload, fixing longstanding l10n issues.
+
+ [ Helmut Grohne ]
+ * Fix FTCBFS: (Closes: #896829)
+- Pass ARCH= to make
+- Let dh_auto_build pass cross tools to make
+
+ [ Helge Kreutzmann ]
+ * Debconf translation updates:
+- French, thanks Julien Patriarca (Closes: #833856)
+- Netherlands, thanks Frans Spiesschaert (Closes: #834610)
+- Brazilian Portuguese, thanks Adriano Rafael Gomes (Closes: #834934)
+- German, thanks Chris Leick (Closes: #843766)
+- Portuguese, thanks Rui Branco (Closes: #858748, #898283)
+- Russian, thanks Lev Lamberov (Closes: #883140)
+- Spanish, thanks Jonathan Bustillos (Closes: #900712)
+
+ [ Tianon Gravi ]
+ * Update Vcs-* to point to Salsa
+ * Update Homepage to https
+
+ -- Helge Kreutzmann Sat, 01 Sep 2018 08:59:13 +0200
+
refind (0.11.2-1) unstable; urgency=medium
* Update to 0.11.2 upstream release
diff -Nru refind-0.11.2/debian/control refind-0.11.2/debian/control
--- refind-0.11.2/debian/control 2017-12-04 12:02:14.0 -1000
+++ refind-0.11.2/debian/control 2018-08-08 04:10:28.0 -1000
@@ -5,9 +5,9 @@
Priority: optional
Standards-Version: 3.9.8
Build-Depends: debhelper (>= 9), gnu-efi
-Homepage: http://www.rodsbooks.com/refind
-Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/refind.git
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/refind.git
+Homepage: https://www.rodsbooks.com/refind
+Vcs-Browser: https://salsa.debian.org/debian/refind
+Vcs-Git: https://salsa.debian.org/debian/refind.git
Package: refind
Architecture: amd64 arm64 i386
diff -Nru refind-0.11.2/debian/po/de.po refind-0.11.2/debian/po/de.po
--- refind-0.11.2/debian/po/de.po 1969-12-31 14:00:00.0 -1000
+++ refind-0.11.2/debian/po/de.po 2018-08-08 04:02:59.0 -1000
@@ -0,0 +1,49 @@
+# refind debconf translation
+# Copyright (C) 2006 Christoph Pfisterer, 2012-2016 Roderick W. Smith.
+# This file is distributed under the same license as the refind package.
+# Copyright (C) of this file Chris Leick 2016.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: refind 0.10.4-1\n"
+"Report-Msgid-Bugs-To: ref...@packages.debian.org\n"
+"POT-Creation-Date: 2015-12-12 18:35-0500\n"
+"PO-Revision-Date: 2016-11-01 10:42+0100\n"
+"Last-Translator: Chris Leick \n"
+"Language-Team: de \n"
+"Language: de\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid "Automatically install rEFInd to the ESP?"
+msgstr "rEFInd automatisch auf der ESP installieren?"
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"It is necessary to install rEFInd to the EFI System Partition (ESP) for it "
+"to control the boot process."
+msgstr ""
+"Es ist notwendig, rEFInd auf die EFI-Systempartition (ESP) zu installieren, "
+"damit es den Systemstart steuern kann."
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"Not installing the new rEFInd binary on the ESP may leave the system in an "
+"unbootable state. Alternatives to automatically installing rEFInd include "
+"running /usr/sbin/refind-install by hand or installing the rEFInd binaries "
+"manually by copying them from subdirectories of /usr/share/refind-{version}."
+msgstr ""
+"Wenn das neue rEFInd-Programm nicht auf der ESP installiert wird, wird das "
+"System möglicherweise in einem nicht mehr startbaren Zustand verbleiben. "
+"Alternaitiv zur automatischen Installation können Sie "
+"/usr/sbin/refind-install von Hand ausführen oder die rEFInd-Programme manuell "
+"installieren, indem Sie sie manuell aus den Unterverzeichnissen von "
+"/usr/share/refind-{Version} kopieren."
diff -Nru refind-0.11.2/debian/po/es.po refind-0.11.2/debian/po/es.po
--- refind-0.11.2/debian/po/es.po 1969-12-31 14:00:00.0 -1000
+++ refind-0.11.2/debian/po/es.po 2018-08-08 04:08:49.0 -1000
@@ -0,0 +1,70 @@
+# refind po-debconf translation to Spanish.
+# Copyright (C) 2018 Software in the Public Interest
+# This file is distributed under the same license as the refind package.
+#
+# - Initial translation
+# Jonathan Bustillos , 2018.
+#
+# Traductores, si no conocen el formato PO, merece la pena leer la
+# documentación de gettext, especialmente las secciones dedicadas a este
+# formato, por ejemplo ejecutando:
+# info -n '(gettext)PO Files'
+# info -n '(gettext)Header Entry'
+#
+# Equipo de
Bug#908971: spamassassin: CVE-2018-11781: local user code injection in the meta rule syntax
Source: spamassassin Version: 3.4.1-1 Severity: grave Tags: security upstream Hi, The following vulnerability was published for spamassassin. CVE-2018-11781[0]: local user code injection in the meta rule syntax It is fixed in new upstream version 3.4.2. 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-11781 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11781 [1] https://www.openwall.com/lists/oss-security/2018/09/16/1 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#908969: spamassassin: CVE-2017-15705: denial of service vulnerability
Source: spamassassin Version: 3.4.1-1 Severity: grave Tags: security upstream Hi, The following vulnerability was published for spamassassin. CVE-2017-15705[0]: denial of service vulnerability It is fixed upstream in new 3.4.2 release. 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-2017-15705 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15705 [1] https://www.openwall.com/lists/oss-security/2018/09/16/1 Please adjust the affected versions in the BTS as needed. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#908968: ext3grep: FTBFS with DH 10/11
Package: ext3grep Version: 0.10.2-3+b1 Severity: important Tags: upstream ext3-grep fails to build from source when using debhelper 10 or 11. It builds fine with debhelper 11 and compat 9. When building, the following error is shown: aclocal: error: non-option arguments are not accepted: '@ACLOCAL_CWFLAGS@'. aclocal: Try '/usr/bin/aclocal --help' for more information. autoreconf: aclocal failed with exit status: 1 I sent a question about it to automake mailing list[1]. Regards, Eriberto [1] http://lists.gnu.org/archive/html/automake/2018-09/msg00012.html -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages ext3grep depends on: ii libc6 2.27-6 ii libgcc1 1:8.2.0-6 ii libstdc++6 8.2.0-6 ext3grep recommends no packages. ext3grep suggests no packages. -- no debconf information
Bug#907194: su: yields breakage without "-", not properly documented
Control: tags -1 + wontfix Hello Vincent Lefevre, On Fri, Aug 24, 2018 at 05:17:34PM +0200, Vincent Lefevre wrote: > Package: util-linux > Version: 2.32.1-0.1 > Severity: important [...] > The fundamental problem is that it's not at all defined what "su" > without -l actually wants to be: (This is still unfixed/undefined AFAIK.) [...] > AFAICS, the behaviour of "su" without -l either needs to be properly > defined and fixed, or it should be completely deprecated, perhaps > making it do the same thing as -l. In my personal opinions 'su' should likely be deprecated in its entirety. Ofcourse that won't happen over night. There are lots of scripts to rewrite to use setpriv (and sometimes possibly runuser where suitable) instead of su. Lots of users to teach to always use sudo. Most likely there are also standards documents that needs to be adressed and revisioned. Your help welcome! ;) (FWIW, I'm thinking we should merge the setpriv package into util-linux and make setpriv command Essential. The reason we separated it out doesn't seem to apply anymore. A merge request would certainly be welcome!) [...] > First, the default behavior should never be discouraged: if there is > something wrong, then it should be fixed. [...] I normally very much agree, but as usual there's a bigger picture to take into account here. The entire existance of su today basically boils down to (obsolete?) standards adherence, backwards and sanity compatibility. Basically su is all about legacy. Secondly, the util-linux implementation is all about PAM, which allows you to configure the behaviour so that the application doesn't have to implement it in C code (as the old su implementation did for certain things). Unfortunately what we've seen here is that quite a few people have built up a habit of relying on debian-specific peculiarities which was very noticable when we switched. I've tried too gather the opinions of fellow maintainers and domain experts what we should choose when we can only pick one debian-legacy-compatibility and being more compatible with basically every other linux distribution. Everyone has pointed in the same direction, leaving the debian-peculiarities of su behind us. (There has also been some discussion about smoothing out some of the bumps by updating pam configurations, sometimes used in other distributions already. Again domain experts have suggested not doing it.) Please note hovever that plain 'su' was just as bad of an idea before we switched su implementation as it remains to be today. People simply need to learn to stop using su at some point (or keep shooting their own feet off until they learn). If you really want to help, I think the first best step would be to lobby the debian installer team to make the 'root password' prompt only show up in 'expert level' installs and thus giving everyone sudo installed and setup by default (as far too few users are aware of that they'll get today by leaving the root password prompt blank). Sorry, but I don't really see anything to fix in util-linux here (certainly not anything debian-specific, please discuss upstream changes on the upstream mailing list. A patch to make the su manpage easier to read for users would likely be warmly welcomed there). I'm thus tagging this wontfix. Hopefully my comments above atleast helps shine some light on the situation. Regards, Andreas Henriksson
Bug#908967: boot logs
Please find the boot logs attached U-Boot 2018.01-02296-g457cdd60c3 (May 17 2018 - 22:59:22 +0200), Build: jenkins-u-boot-imx6-variant=sdhc-2 CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 48C Reset cause: WDOG Board: MX6 HummingBoard Watchdog enabled DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 auto-detected panel HDMI Display: HDMI (1024x768) In:serial Out: serial Err: serial Net: FEC starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 297 bytes read in 121 ms (2 KiB/s) i.MX6 1: default 2: hack Enter choice: 1 1: default Retrieving file: /boot/extlinux/../initrd 8817476 bytes read in 690 ms (12.2 MiB/s) Retrieving file: /boot/extlinux/../zImage 7137904 bytes read in 535 ms (12.7 MiB/s) append: root=UUID=febfadf2-ffa2-48ad-9802-d7b67b5e7818 rootfstype=auto rootwait Retrieving file: /boot/extlinux/../dtb-dir/imx6q-hummingboard.dtb 45535 bytes read in 854 ms (51.8 KiB/s) ## Flattened Device Tree blob at 1800 Booting using the fdt blob at 0x1800 Using Device Tree in place at 1800, end 1800e1de Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.9.124-imx6-sr (abuild@ddd2fcb3ed55) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Sat Sep 15 05:01:08 UTC 2018 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt:Machine model: SolidRun HummingBoard Dual/Quad [0.00] Reserved memory: created CMA memory pool at 0x2c00, size 320 MiB [0.00] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [0.00] Memory policy: Data cache writealloc [0.00] percpu: Embedded 14 pages/cpu @db6ba000 s26764 r8192 d22388 u57344 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260416 [0.00] Kernel command line: root=UUID=febfadf2-ffa2-48ad-9802-d7b67b5e7818 rootfstype=auto rootwait [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 686640K/1048576K available (9216K kernel code, 418K rwdata, 3088K rodata, 1024K init, 549K bss, 34256K reserved, 327680K cma-reserved, 262144K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0a0 (10208 kB) [0.00] .init : 0xc0e0 - 0xc0f0 (1024 kB) [0.00] .data : 0xc0f0 - 0xc0f68880 ( 419 kB) [0.00].bss : 0xc0f68880 - 0xc0ff1dd8 ( 550 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] L2C-310 errata 752271 769419 enabled [0.00] L2C-310 enabling early BRESP for Cortex-A9 [0.00] L2C-310 full line of zeros enabled for Cortex-A9 [0.00] L2C-310 ID prefetch enabled, offset 16 lines [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled [0.00] L2C-310 cache controller enabled, 16 ways, 1024 kB [0.00] L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76470001 [0.00] Switching to timer-based delay loop, resolution 333ns [0.08] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns [0.24] clocksource: mxc_timer1: mask: 0x max_cycles: 0x, max_idle_ns: 637086815595 ns [0.001250] Console: colour dummy device 80x30 [0.001747] console [tty0] enabled [0.001778] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=3000) [0.001813] pid_max: default: 32768 minimum: 301 [0.001922] Security Framework initialized [0.001949] SELinux: Initializing. [
Bug#908967: initramfs-tools: mount fails with rootfstype=auto
Package: initramfs-tools Version: 0.130 Severity: normal Dear Maintainer, I encountered a strange problem mounting the rootfs with a freshly debootstrapped system. Note: possible duplicate of #845302 but due to the details I found it probably warrants its own topic. Steps: - used debootstrap with --variant=minbase to create an armhf rootfs - added custom packages such as vendor kernel, systemd, initramfs-tools - created extlinux.conf to boot - bootargs: root=UUID=... rootfstype=auto rootwait Observations: - root=/dev/mmcblk0p1 rootfstype=auto: fails - root=/dev/mmcblk0p1 rootfstype=ext4: works - root=UUID=... rootfstype=ext4: works How did I find this? I added "set -x" to - /usr/share/initramfs-tools/init - /usr/share/initramfs-tools/scripts/init-bottom/udev The serial console then finally revealed what is going wrong. When it fails (rootfstype=auto): + [ auto != unknown ] + mount -r -t auto /dev/mmcblk0p1 /root mount: No such device When it works (rootfstype=ext4): + [ ext4 != unknown ] + mount -r -t ext4 /dev/mmcblk0p1 /root [9.979060] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null) So I see two solutions: - If rootfstype=auto, and the actual type is known through a previous call to blkid, e.g. while running fsck, use the known type - fix the mount command to deal with type auto I am submitting the full boot logs by email as follow-up. Yours sincerely Josua Mayer -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 8.5M Sep 16 20:04 /boot/initrd.img-4.9.124-imx6-sr -- /proc/cmdline root=UUID=febfadf2-ffa2-48ad-9802-d7b67b5e7818 rootfstype=ext4 rootwait -- /proc/filesystems ext3 ext2 ext4 vfat fuseblk f2fs -- lsmod Module Size Used by bnep 20480 2 mxc_v4l2_capture 40960 0 ipu_bg_overlay_sdc 16384 1 mxc_v4l2_capture ipu_still 16384 1 mxc_v4l2_capture ipu_prp_enc16384 1 mxc_v4l2_capture ipu_csi_enc16384 1 mxc_v4l2_capture ipu_fg_overlay_sdc 20480 1 mxc_v4l2_capture hci_uart 49152 0 btbcm 16384 1 hci_uart nvmem_core 24576 1 hci_uart ov5647_camera_mipi 36864 0 v4l2_int_device16384 3 ov5647_camera_mipi,ipu_csi_enc,mxc_v4l2_capture xt_connmark16384 2 iptable_nat16384 0 nf_conntrack_ipv4 16384 3 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_nat_ipv416384 1 iptable_nat nf_nat 24576 1 nf_nat_ipv4 nf_conntrack 106496 4 nf_conntrack_ipv4,xt_connmark,nf_nat_ipv4,nf_nat iptable_mangle 16384 1 iptable_filter 16384 0 ir_lirc_codec 16384 0 galcore 372736 0 ir_rc6_decoder 16384 0 lirc_dev 20480 1 ir_lirc_codec rc_rc6_mce 16384 0 gpio_ir_recv 16384 0 bluetooth 360448 12 hci_uart,bnep,btbcm rfkill 24576 4 bluetooth ip_tables 24576 3 iptable_mangle,iptable_filter,iptable_nat x_tables 28672 4 iptable_mangle,ip_tables,iptable_filter,xt_connmark imx_sdma 28672 8 virt_dma 16384 1 imx_sdma -- /etc/initramfs-tools/modules -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=auto KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- /proc/mdstat Personalities : unused devices: -- mkinitramfs hooks /etc/initramfs-tools/hooks/: imx-sdma /usr/share/initramfs-tools/hooks: dmsetup fsck fuse keymap klibc-utils kmod ntfs_3g resume thermal udev -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 4.9.124-imx6-sr (SMP w/2 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 initramfs-tools depends on: ii initramfs-tools-core 0.130 ii linux-base4.5 initramfs-tools recommends no packages. Versions of packages initramfs-tools suggests: pn bash-completion -- no debconf information
Bug#908849: gerbera: No linefeed before CONNECTION header
Control: tags -1 confirmed fixed-upstream Control: forwarded -1 https://github.com/gerbera/gerbera/pull/316 Hi, On 15/09/2018 01:17, Pelzi wrote: > Package: gerbera > Version: 1.1.0+dfsg-2+b2 > Severity: normal > > Dear Maintainer, > > Try to play an audio track served by gerbera using the uPnP protocol. This > leads to an ordinary http get from client (here VLC running on Mac OS). > > As a result, Gerbera will send back an http answer, consisting of an HTTP > header and content (which is intended to be streamed by the client). Gerbera > adds "CONNECTION: close" to the last line of the header, whichever that is, > e.g.: Accept-Ranges: bytesCONNECTION: close > (In certain situations the last header line might happen to be the > Content-Disposition heder and in that case, VLC turns out to be > uncapable of parsing the header at all and will refuse to play the respective > track.) > > Instead, Gerbera should add another line to the header, i.e. > Accept-Ranges: bytes > CONNECTION: close > These lines must be separated by CR LF, as always in HTTP. Thanks for the bug report. I can confirm this bug. I think it's fixed by the above upstream PR (not in any released version). I'll see if I can cherry-pick it at the next upload of gerbera. James signature.asc Description: OpenPGP digital signature
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Tollef Fog Heen writes: >This should be implemented in Debian Policy by declaring that a a ^^^ You've this doubled 'a' on two occasions in this text. Presumaly we would not want to see new packages adopting the use of vendor-specific patch series prior to Buster. Do we need to make the "SHOULD NOT" conditional on the package already having a vendor-specific patch series at the time of this resolution? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#908966: libiptcdata0-dev: ships libiptcdata.pc in literally /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
Package: libiptcdata0-dev
Version: 1.0.5-1
Severity: serious
Justification: makes tracker-miners ftbfs
Tags: ftbfs
Control: affects -1 + src:tracker-miners
libiptcdata.pc is now shipped in literally
/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig. That is semantically
equivalent to it being absent. Consequently, the autopkgtest for
tracker-miners fails. tracker-miners also fails to build from source.
If you want to use such an expansion in libiptcdata0-dev.install, you
must Build-Depends: dh-exec, add a #! line and make the file executable.
It might be easiert to just add
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) to
DEB_CONFIGURE_EXTRA_FLAGS though.
Helmut
Bug#908965: stretch-pu: package postgrey/1.36-3+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Create the pid file in a subdirectory that is owned by the postgrey user, avoiding problems with removing or overwriting the pid file. diff -Nru postgrey-1.36/debian/changelog postgrey-1.36/debian/changelog --- postgrey-1.36/debian/changelog 2016-08-28 21:18:34.0 +0300 +++ postgrey-1.36/debian/changelog 2018-09-16 22:01:59.0 +0300 @@ -1,3 +1,12 @@ +postgrey (1.36-3+deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * debian/postgrey.init: create /var/run/postgrey if it +does not exist, patch provided by Laurent Bigonville . +(Closes: 756813, 880047) + + -- Adrian Bunk Sun, 16 Sep 2018 22:01:59 +0300 + postgrey (1.36-3) unstable; urgency=medium * debian/patches: diff -Nru postgrey-1.36/debian/postgrey.init postgrey-1.36/debian/postgrey.init --- postgrey-1.36/debian/postgrey.init 2016-08-28 21:18:34.0 +0300 +++ postgrey-1.36/debian/postgrey.init 2018-09-16 22:01:59.0 +0300 @@ -26,7 +26,7 @@ DESC="postfix greylisting daemon" DAEMON_USER=postgrey -PIDFILE=/var/run/$DAEMON_NAME.pid +PIDFILE=/var/run/postgrey/$DAEMON_NAME.pid SCRIPTNAME=/etc/init.d/$DAEMON_NAME # Gracefully exit if the package has been removed. @@ -55,6 +55,14 @@ # 0 if daemon has been started # 1 if daemon was already running # 2 if daemon could not be started + if [ ! -d /var/run/postgrey/ ] + then +mkdir /var/run/postgrey/ +chown $DAEMON_USER: /var/run/postgrey/ +chmod 0755 /var/run/postgrey/ +# Restore selinux context +[ -x /sbin/restorecon ] && /sbin/restorecon /var/run/postgrey/ + fi start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
Bug#908964: evince: reports "! SyncTeX Error : No file?" at startup
Package: evince Version: 3.30.0-2 Severity: normal evince has recently regularly (always?) started reporting "! SyncTeX Error : No file?" when I open a PDF to view it. I have no idea why this would be; the PDF files in question are unrelated to TeX. Best wishes, Julian -- System Information: Debian Release: buster/sid APT prefers stretch APT policy: (500, 'stretch'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evince depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.0-1 ii evince-common3.30.0-2 ii gsettings-desktop-schemas3.28.0-1 ii libatk1.0-0 2.28.1-1 ii libc62.27-6 ii libcairo-gobject21.15.12-1 ii libcairo21.15.12-1 ii libevdocument3-4 3.30.0-2 ii libevview3-3 3.30.0-2 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-0 2.56.1-2 ii libgnome-desktop-3-173.30.0-1 ii libgtk-3-0 3.22.30-2 ii libnautilus-extension1a 3.30.0-1 ii libpango-1.0-0 1.42.4-1 ii libpangocairo-1.0-0 1.42.4-1 ii libsecret-1-00.18.6-2 ii shared-mime-info 1.9-2 Versions of packages evince recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.10-1 ii dbus-x11 [dbus-session-bus] 1.12.10-1 Versions of packages evince suggests: ii gvfs 1.36.2-1 ii nautilus-sendto 3.8.6-2 ii poppler-data 0.4.9-2 ii unrar1:5.5.8-1 -- no debconf information
Bug#907524: [python-guess-language] Support for python 2.7
On 09/09/18 07:31, Tomasz Buchert wrote: > would it be possible to create an official release/download on > bitbucket so that I can pull it? Otherwise I will have to import a > semi-random git hash. That is upstream's call. What do you think spirit? :) Otherwise, the PR was merged in the default branch already. I don't think is uncommon to version with the date in which the repo was pulled. For example: $ dpkg --compare-versions 0.5.2-4 lt 0.5.2.git20180916-1 && echo "True" True $ dpkg --compare-versions 0.5.2.git20180916-1 lt 0.5.3 && echo "True" True /luciano
Bug#908494: lightning: no icon to access calendar after upgrade to TB 60
Am 15.09.18 um 23:03 schrieb George B.: > I have now recreated the issue on a clean install of Sid in a VM. > > Steps were: > > - install from 9.5.0-netinst ISO with basic packages option > - change sources.list to point to sid and dist-upgrade > - install xorg wdm awesome thunderbird-l10n-en-gb lightning Aha, no Gnome or KDE environment, I was thinking about some non standard DE or tiling window manager already ... I will try adjust the same setup as you describe here, will take some time as I'm not at home for some days. Can image this is a problem by xorg or wayland. O.k. we will see. > There is no longer any debconf error below (sending this from the VM) > but no useful information unfortunately. If you haven't installed any classical DE nor any stuff around this it quite obvious debconf will show an increased list. But normally the list is more longish so I always get a bit "nervous" if the list of debconf is really short. And yes, I was some kind right. Giving all the information about your running environment is really really important! We can't test and check all the possible variants of DEs or window managers. > I have looked in my config editor and there is no settings that match > "extensions.installedDistroAddon". There shouldn't be any of such keys on a fresh install and it's a known problem by Mozilla introduced by broken updates. Should also not happen within Debian as we do a dedicated packaging of Lightning, but as people can also install Lighning locally we have no control about this in the end. -- Regards Carsten Schoenert
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
Hello, On Sun 16 Sep 2018 at 08:40PM +0200, Paul Gevers wrote: > Dear Sean, > > On 16-09-18 20:30, Sean Whitton wrote: >> Paul: does preventing regressions in testing take precedence? > > Normally, yes temporarily (we are not blocking yet), but ghostscript was > uploaded with urgency high. That means that regressions are ignored and > without an RC bug, ghostscript will migrate to testing tomorrow (if my > counting is correct). Thanks. I should have been clearer that I was asking about /all/ regressions in testing, rather than just autopkgtests. >> If so, >> this bug should be reassigned to ghostscript and raised to RC severity. > > I don't follow what you mean by this sentence. I meant that if preventing a test suite failure in testing took priority, we would want to stop ghostscript from migrating. Anyway, it's moot. > ocrmypdf can stay in testing as long as it doesn't have an RC bug itself. > > So just to make it clear: if this change making ocrmypdf totally > unusable and you still want ghostscript to migrate to testing to fix > multiple CVE's, than assigning this bug to ocrmypdf and raising it to RC > level will start the autoremoval process. If you think it is worth > searching for a solution in ghostscript to avoid it breaking ocrmypdf, > than reassign this bug to ghostscript and raise the severity to RC level > to avoid migration. Right. I don't know if OCRmyPDF in testing counts as RC-buggy right now, because I don't know the ramifications of the GhostScript changes; I'm going to wait on upstream. -- Sean Whitton signature.asc Description: PGP signature
Bug#907925: jhead: Interger overflow while running jhead
Control: retitle 907925 jhead: CVE-2018-17088: Integer overflow in gpsinfo.c while running jhead Control: retitle 908176 jhead: CVE-2018-16554: Buffer overflow in gpsinfo.c while running jhead Hi On Fri, Sep 07, 2018 at 10:48:26AM +0200, Salvatore Bonaccorso wrote: > Control: retitle -1 jhead: CVE-2018-16554: Interger overflow while running > jhead I checked with MITRE on the relative CVE assignments for #907925 and #908176 and MITRE confirmed they should be as follows: #907925: jhead: CVE-2018-17088: Integer overflow in gpsinfo.c while running jhead #908176: jhead: CVE-2018-16554: Buffer overflow in gpsinfo.c while running jhead Regards, Salvatore
Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source
Control: reassign -1 glyphslib Control: found -1 3.0.2-3 Control: tags -1 + fixed-upstream This has been fixed upstream in glyphslib: https://github.com/googlei18n/glyphsLib/pull/428 - Fabian signature.asc Description: This is a digitally signed message part
Bug#908963: nut: autopkgtest depends on python-unit which isn't in Debian anymore
Source: nut Version: 2.7.4-8 User: debian...@lists.debian.org Usertags: fails-always Dear maintainers, I was looking into the failure of your package on the ci.debian.org infrastructure. Your autopkgtest depends on python-unit, which has been removed from Debian unstable, testing and stable. Could you please have a look and fix your autopkgtest? Thanks for considering. Paul https://ci.debian.net/packages/n/nut/testing/amd64/ signature.asc Description: OpenPGP digital signature
Bug#908960: stretch-pu: package rtkit/0.11-4+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
* Move dbus and polkit from Recommends to Depends
rtkit can't do much really without either of them so bump them to Depends.
(Closes: #881342)
Read #881342 if you are interested in the nasty details of
what can happen without them.
diff -Nru rtkit-0.11/debian/changelog rtkit-0.11/debian/changelog
--- rtkit-0.11/debian/changelog 2015-10-25 00:44:21.0 +0300
+++ rtkit-0.11/debian/changelog 2018-09-16 21:49:03.0 +0300
@@ -1,3 +1,12 @@
+rtkit (0.11-4+deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Move dbus and polkit from Recommends to Depends
+rtkit can't do much really without either of them so bump them to Depends.
+(Closes: #881342)
+
+ -- Adrian Bunk Sun, 16 Sep 2018 21:49:03 +0300
+
rtkit (0.11-4) unstable; urgency=medium
* Remove stale ubuntu.series file.
diff -Nru rtkit-0.11/debian/control rtkit-0.11/debian/control
--- rtkit-0.11/debian/control 2015-10-25 00:44:21.0 +0300
+++ rtkit-0.11/debian/control 2018-09-16 21:49:03.0 +0300
@@ -22,11 +22,10 @@
Architecture: any
Depends:
adduser,
+ dbus,
+ policykit-1,
${misc:Depends},
${shlibs:Depends}
-Recommends:
- dbus,
- policykit-1
Description: Realtime Policy and Watchdog Daemon
RealtimeKit is a D-Bus system service that changes the
scheduling policy of user processes/threads to SCHED_RR
Bug#908961: cargo: debian/rules overrides DEB_BUILD_PROFILES
Source: cargo Version: 0.29.0-1 debian/rules sets DEB_BUILD_PROFILES. The variable is not meant to be changed during build. Changing it can lead to inconsistency between tools run by debian/rules and tools run outside debian/rules, but it also overrides a user configuration. Please use a different variable for skipping tests for certain architectures. Note that you don't have to check for the nocheck profile. Checking the nocheck option is sufficient, because the spec requires that nocheck is added to DEB_BUILD_OPTIONS whenever it is present in DEB_BUILD_PROFILES. Simply setting DEB_BUILD_PROFILES=nocheck without setting DEB_BUILD_OPTIONS is a build profile specification violation. Helmut
Bug#908962: wine: please add q4wine package to Suggests
Package: wine Version: 3.0.2-3 Severity: wishlist Dear maintainer, Please add q4wine package to Suggests of wine package. Best regards, Boris
Bug#893792: Re : Bug#893792: balsa: Unable to send mail since the latest upgrade
Le 16/09/2018 17:23:14, Jeremy Bicha a écrit : > I suspect that no one on the Debian GNOME team uses balsa. > Since you reported this bug, there has been a bugfix release (2.5.6) > for balsa and many other changes in Debian Unstable. Are you still > able to reproduce this issue? > If so, does 2.5.3-4 from Debian Testing still work? You can close the bug. Thank you, nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
Control: reassign 908937 ocrmypdf Quoting Paul Gevers (2018-09-16 11:25:47) > ginggs already noted this: > > this patch fixes 1 of the 3 failing tests > https://github.com/jbarlow83/OCRmyPDF/commit/517b385fe5cb2195023100a807e6f18dc7e6faea#diff-b61a6d542f9036550ba9c401c80f00ef At http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=e997c68 linked from above the change is described as a deliberate change in Ghostscript, so reassigning this to ocrmypdf. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#908959: gpgme1.0: autopkgtest depends on python3.5 which is not in testing
Source: gpgme1.0 Version: 1.11.1-1 User: debian...@lists.debian.org Usertags: fails-always Dear maintainers, I was looking into the failure of your package on the ci.debian.org infrastructure when run in testing. One of your autopkgtests depends on python3.5, which isn't supported anymore in testing/buster and it seems gpgme1.0 doesn't either. Could you please have a look and fix your autopkgtest? Thanks for considering. Paul https://ci.debian.net/data/autopkgtest/testing/amd64/g/gpgme1.0/994336/log.gz signature.asc Description: OpenPGP digital signature
Bug#908958: stretch-pu: package xmotd/1.17.3b-9+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu xmotd in stretch currently just crashes. diff -Nru xmotd-1.17.3b/debian/changelog xmotd-1.17.3b/debian/changelog --- xmotd-1.17.3b/debian/changelog 2016-09-10 22:07:47.0 +0300 +++ xmotd-1.17.3b/debian/changelog 2018-09-16 21:30:35.0 +0300 @@ -1,3 +1,15 @@ +xmotd (1.17.3b-9+deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * debian/patches/bugfix/fix-warnings-hardening-build.patch: +- Fix most compile time warnings and avoid crash with hardening + flags (acknowledgments to Christoph Pleger for the patch) + (Closes: #889740). +- Backported to stretch is a partial version of this patch + sufficient to fix the crash. + + -- Adrian Bunk Sun, 16 Sep 2018 21:30:35 +0300 + xmotd (1.17.3b-9) unstable; urgency=medium * Make debian/copyright DEP5 compliant. diff -Nru xmotd-1.17.3b/debian/patches/bugfix/fix-warnings-hardening-build.patch xmotd-1.17.3b/debian/patches/bugfix/fix-warnings-hardening-build.patch --- xmotd-1.17.3b/debian/patches/bugfix/fix-warnings-hardening-build.patch 1970-01-01 02:00:00.0 +0200 +++ xmotd-1.17.3b/debian/patches/bugfix/fix-warnings-hardening-build.patch 2018-09-16 21:30:35.0 +0300 @@ -0,0 +1,75 @@ +Remove compiler and linker warnings +Index: xmotd-1.17.3b/atom.c +=== +--- xmotd-1.17.3b.orig/atom.c 2018-02-13 10:44:27.104309051 +0100 xmotd-1.17.3b/atom.c 2018-02-13 10:44:27.096309028 +0100 +@@ -29,6 +29,7 @@ + */ + #include + ++#include + #include + #include + #include +Index: xmotd-1.17.3b/textmode.c +=== +--- xmotd-1.17.3b.orig/textmode.c 2018-02-13 10:44:27.104309051 +0100 xmotd-1.17.3b/textmode.c 2018-02-13 10:44:27.096309028 +0100 +@@ -40,6 +40,9 @@ + #include + + #include "maindefs.h" ++#include "prototypes.h" ++ ++extern time_t motdChanged(); + + void + runInTextMode(argc, argv) +Index: xmotd-1.17.3b/xmotd.c +=== +--- xmotd-1.17.3b.orig/xmotd.c 2018-02-13 10:44:27.104309051 +0100 xmotd-1.17.3b/xmotd.c 2018-02-13 11:06:49.756282943 +0100 +@@ -70,6 +70,7 @@ + + #include "maindefs.h" + #include "main.h" ++#include "prototypes.h" + + extern time_t motdChanged(); + extern messageptr freeMessage(); +Index: xmotd-1.17.3b/Imakefile +=== +--- xmotd-1.17.3b.orig/Imakefile 2018-02-13 10:44:27.104309051 +0100 xmotd-1.17.3b/Imakefile2018-02-13 10:44:27.096309028 +0100 +@@ -60,7 +60,7 @@ + + SRCS = main.c xmotd.c changed.c textmode.c usage.c browser.c logo.c atom.c + OBJS = main.o xmotd.o changed.o textmode.o usage.o browser.o logo.o atom.o +-INCLS = maindefs.h appdefs.h main.h ++INCLS = maindefs.h appdefs.h main.h prototypes.h + + CDEBUGFLAGS = -g + MANSUFFIX = 8 +Index: xmotd-1.17.3b/Makefile +=== +--- xmotd-1.17.3b.orig/Makefile2018-02-13 10:44:27.104309051 +0100 xmotd-1.17.3b/Makefile 2018-02-13 10:44:27.096309028 +0100 +@@ -497,7 +497,7 @@ + + SRCS = main.c xmotd.c changed.c textmode.c usage.c browser.c logo.c atom.c + OBJS = main.o xmotd.o changed.o textmode.o usage.o browser.o logo.o atom.o +-INCLS = maindefs.h appdefs.h main.h ++INCLS = maindefs.h appdefs.h main.h prototypes.h + + CDEBUGFLAGS = -g + MANSUFFIX = 8 +Index: xmotd-1.17.3b/prototypes.h +=== +--- /dev/null 1970-01-01 00:00:00.0 + xmotd-1.17.3b/prototypes.h 2018-02-13 10:46:01.608588566 +0100 +@@ -0,0 +1,5 @@ ++#ifndef _XMOTD_PROTOTYPES_H ++#define _XMOTD_PROTOTYPES_H ++void updateTimeStamp(char *motdfile); ++char * getTimeStampName(void); ++#endif diff -Nru xmotd-1.17.3b/debian/patches/series xmotd-1.17.3b/debian/patches/series --- xmotd-1.17.3b/debian/patches/series 2016-09-10 22:07:47.0 +0300 +++ xmotd-1.17.3b/debian/patches/series 2018-09-16 21:30:35.0 +0300 @@ -6,3 +6,4 @@ debian/enable-xpm.diff -p1 debian/html-support-gone.diff -p1 debian/unqualify-xmotd-in-manpage.diff -p1 +bugfix/fix-warnings-hardening-build.patch
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
Dear Sean, On 16-09-18 20:30, Sean Whitton wrote: > Paul: does preventing regressions in testing take precedence? Normally, yes temporarily (we are not blocking yet), but ghostscript was uploaded with urgency high. That means that regressions are ignored and without an RC bug, ghostscript will migrate to testing tomorrow (if my counting is correct). > If so, > this bug should be reassigned to ghostscript and raised to RC severity. I don't follow what you mean by this sentence. > But ISTM that ocrmypdf is less important, so ghostscript should be > allowed to migrate and ocrmypdf should be kicked out. ocrmypdf can stay in testing as long as it doesn't have an RC bug itself. So just to make it clear: if this change making ocrmypdf totally unusable and you still want ghostscript to migrate to testing to fix multiple CVE's, than assigning this bug to ocrmypdf and raising it to RC level will start the autoremoval process. If you think it is worth searching for a solution in ghostscript to avoid it breaking ocrmypdf, than reassign this bug to ghostscript and raise the severity to RC level to avoid migration. Paul signature.asc Description: OpenPGP digital signature
Bug#908937: ghostscript breaks ocrmypdf autopkgtest
Hello, On Sun 16 Sep 2018 at 11:20AM +0200, Paul Gevers wrote: > With a recent upload of ghostscript [9.25] the autopkgtest of ocrmypdf > [6.2.3] fails in testing when that autopkgtest is run with the binary > packages of ghostscript from unstable. It passes when run with only > packages from testing. I copied some of the output at the bottom of > this report. James: how easily could we backport the GhostScript change to OCRmyPDF 6.x series? If not easily, and you still think that pikepdf's API will stabilise in time for Debian's upcoming stable release, maybe OCRmyPDF should just be kept out of testing for the timebeing. Paul: does preventing regressions in testing take precedence? If so, this bug should be reassigned to ghostscript and raised to RC severity. But ISTM that ocrmypdf is less important, so ghostscript should be allowed to migrate and ocrmypdf should be kicked out. -- Sean Whitton signature.asc Description: PGP signature
Bug#908933: debian-policy: typo in document in section 3.4 page no 15 line number 16 needs improvement.
control: tag -1 +moreinfo Hello, On Sun 16 Sep 2018 at 03:24PM +0530, Jaikumar Sharma wrote: > [M]y personal opinion is, would have been better if we could have used > 'administrative details' . This would not be right; there is a difference in meaning between 'administrative details' and 'administrivia'. > Also, looks odd in the > debian-policy document as last three characters of this word stands > seperated from the rest of the characters of this word - may be > because of font used in the document or something. Hmm? Can you provide a screenshot, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Hello, On Sat 15 Sep 2018 at 07:06PM +0200, Tollef Fog Heen wrote: > A first draft is below, feedback on wording and content appreciated. LGTM, thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#908956: stretch-pu: package gphoto2-cffi/0.3~a1-1.1~deb9u1
Thanks for noticing that this also affects stable and should be fixed there. I should have noticed that too, in hindsight. On Sun, 16 Sep 2018 at 19:45, Adrian Bunk wrote: > Package: release.debian.org > Severity: normal > Tags: stretch > User: release.debian@packages.debian.org > Usertags: pu > > python3-gphoto2cffi in stretch is currently completely > broken, just trying to import it fails: > > $ python3 > Python 3.5.3 (default, Jan 19 2017, 14:11:04) > [GCC 6.3.0 20170118] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import gphoto2cffi > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/gphoto2cffi/__init__.py", line 1, > in > from .gphoto2 import (Camera, list_cameras, supported_cameras, > File "/usr/lib/python3/dist-packages/gphoto2cffi/gphoto2.py", line 15, > in > from . import errors, backend > File "/usr/lib/python3/dist-packages/gphoto2cffi/backend.py", line 56, > in > 'extract_exif': _lib.GP_FILE_OPERATION_EXIF}) > File "/usr/lib/python3.5/enum.py", line 243, in __call__ > return cls._create_(value, names, module=module, qualname=qualname, > type=type, start=start) > File "/usr/lib/python3.5/enum.py", line 343, in _create_ > enum_class = metacls.__new__(metacls, class_name, bases, classdict) > File "/usr/lib/python3.5/enum.py", line 114, in __new__ > enum_class = super().__new__(metacls, cls, bases, classdict) > TypeError: type() argument 1 must be str, not bytes > >>> > -- Best regards, Aigars Mahinovsmailto:aigar...@debian.org #--# | .''`.Debian GNU/Linux (http://www.debian.org)| | : :' : Latvian Open Source Assoc. (http://www.laka.lv) | | `. `'Linux Administration and Free Software Consulting | | `- (http://www.aiteki.com) | #--#
Bug#908957: stretch-pu: package z3/4.4.1-0.4~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Installing multiple architectures of python-z3 at the
same time fails during installation, remove the incorrect
Multi-Arch: same.
diff -Nru z3-4.4.1/debian/changelog z3-4.4.1/debian/changelog
--- z3-4.4.1/debian/changelog 2016-09-26 08:28:12.0 +0300
+++ z3-4.4.1/debian/changelog 2018-09-16 20:46:04.0 +0300
@@ -1,3 +1,18 @@
+z3 (4.4.1-0.4~deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for stretch.
+
+ -- Adrian Bunk Sun, 16 Sep 2018 20:46:04 +0300
+
+z3 (4.4.1-0.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove the incorrect Multi-Arch: same of python-z3,
+thanks to Helmut Grohne. (Closes: #874237)
+
+ -- Adrian Bunk Sun, 09 Sep 2018 22:28:32 +0300
+
z3 (4.4.1-0.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru z3-4.4.1/debian/control z3-4.4.1/debian/control
--- z3-4.4.1/debian/control 2016-07-20 14:07:58.0 +0300
+++ z3-4.4.1/debian/control 2018-09-09 22:28:32.0 +0300
@@ -61,7 +61,6 @@
Package: python-z3
Section: python
Architecture: any
-Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: libz3-dev (= ${binary:Version}), ${misc:Depends}, ${python:Depends},
${shlibs:Depends}
Description: theorem prover from Microsoft Research - Python bindings
Bug#874526: Keyboard grab doesn't work under Wayland
Control: severity -1 important On Wed, Sep 6, 2017 at 6:03 PM Josh Triplett wrote: > [I don't know whether this bug lies in gnome-boxes or gnome-shell or > some combination of both. Release-critical because this completely > breaks the ability to log into many Windows VMs with gnome-boxes under > the default GNOME Wayland session.] I am downgrading the severity since there is a workaround in the keyboard menu in the headerbar. > The mechanism gnome-boxes uses to grab the keyboard doesn't work under > the default GNOME Wayland session. This makes it impossible to send > Ctrl-Alt-Delete; it always goes to gnome-shell instead. I can't reproduce this bug. Boxes does correctly grab the keyboard and tells me that it has in its headerbar. If you look in the Boxes app menu, there is an item called Shortcuts. If you click it, it tells you that the shortcut for keyboard grab is Ctrl + L Alt. I mean have you tried Ctrl + R Alt + Delete ? If you can still reproduce, please provide a more detailed test case. What guest OS are you using? How can you tell that Ctrl+Alt+Delete isn't being sent to the guest? Thanks, Jeremy Bicha
Bug#908938: [WORKAROUND] alsa-utils: amixer does not unmute pulseaudio
* Łukasz Stelmach [2018-09-16 17:56 +0200]: > Łukasz Stelmach writes: > > > Elimar Riesebieter writes: > >> * Łukasz Stelmach [2018-09-16 11:23 +0200]: > >>> I've got PulseAudio running, so amixer (and alsamixer) controls the > >>> default PA output. I use the following command to control muting of > >>> audio. > >>> > >>> amixer -q -c 0 sset Master toggle > > The following command can be used as a workaround > > pactl set-sink-mute 0 toggle How do you unmute then? Elimar -- Experience is something you don't get until just after you need it!
Bug#863231: munin-plugins-core: apt_all uses different statefiles for reading and writing
Package: munin-plugins-core Followup-For: Bug #863231 Control: retitle -1 Plugins "apt" and "apt_all" use state file with same name in different locations Control: forwarded -1 https://github.com/munin-monitoring/munin/issues/1072 Hello, ok - I took another look at the issue. Sadly it is a bit more complicated :( We have two different plugins: apt and apt_all. They behave as follows: = apt = * default state file (defined in plugin code): /var/lib/munin-node/plugin-state/root/plugin-apt.state * configuration in /etc/munin/plugin-conf.d/munin-node: [apt] user root Result: * the cron job uses the root/ state file * the plugin uses the root/ state file = apt_all = * default state file (defined in plugin code): /var/lib/munin-node/plugin-state/nobody/plugin-apt.state * no configuration in /etc/munin/plugin-conf.d/munin-node: Result: * the cron job uses the nobody/ state file * the plugin uses the nobody/ state file Thus both plugins can work on their own without a problem. (even though the differing locations are a bit of a mess) If both plugins are enabled, the cron job that we ship with our package executes only the "apt_all" code (thus writing to nobody/). But this is not complicated enough - there is another detail! :) Usage of the state files: * apt: * cron job: check the age of its timestamp in order to run "apt-get update" from time to time A "timestamp" line is also written to the file - but no one reads it. * plugin: call "apt-get upgrade" and output the resulting values (the statefile is not used at all) * apt_all: * cron job: update the state file if necessary: calculate the "value" statements (via "apt-get upgrade") for the plugin output and store these in the state file); afterwards "apt update" is called for updating the current set of known packages (bug: "apt-get update" should be called first) * plugin: update the state file (only if necessary due to its age) and afterwards just print its current content Thus the differing locations of both plugins are currently a good thing (by accident), since their content differs (arbitrary timestamp line vs. wanted output of plugin). The current behaviour seems to be: * only "apt" plugin enabled: proper results * only "apt_all" plugin enabled: proper results * "apt" and "apt_all" enabled: proper results (the "apt_all update" causes the "apt-get update" call that the "apt" plugin requires) Thus (based on a mixture of various unexpected details) both plugins should currently work as intended. But obviously these plugins leave lots of room for improvements, clarifications and maybe merging/abandoning. Thus retitling this bug with regard to the filename confusion. I created an upstream issue: https://github.com/munin-monitoring/munin/issues/1072 Cheers, Lars
Bug#908742: Want way to reset tar-ignore list
Guillem Jover writes ("Re: Bug#908742: Want way to reset tar-ignore list"):
> Hmm, I found this bug description and the problem from the referenced
> bug to be a bit of a mismatch. I checked the notmuch referenced history
> where I noticed in commit 514fb397c9f7cfc80f0b14bd28bb2acdb4cd30ca that
> the problem was the standalone tar-ignore option. The current options
> file now contains:
>
> ,--- debian/source/options
> single-debian-patch
> tar-ignore=.git
> tar-ignore=performance-test/download/*.tar.xz
> `---
Yes. From the point of view of dgit's call to dpkg-source, that's a
workaround, really. (From the point of view of other uses of notmuch
I think it is a bugfix, or a workaround for #908747, depending on how
you look at things.)
> With that in mind, I'm not sure whether your request is to ignore
> *only* those standalone tar-ignore options or any of them regarldess
> of these taking an argument or not?
No, dgit wants to completely control the ignore list.
> Because I'd think in general you'd want to honor the ignore rules from
> the source package itself, except for the dpkg-source defaults. OTOH I
> guess those same ignores would be covered by things such as .gitignore
> or similar VCS-specific files.
dgit is working from a git commit and therefore has a git tree object
which already contains exactly the right set of files. (That tree
object may have been influenced by .gitignore but that happened
earlier.) dgit needs to convert that into a source package, so it
calls dpkg-source.
So dgit needs represent in the source package exactly all files that
are in the tree object, regardless of the contents of the
debian/source/options.
If the tree object contains files which were ignored by a tar-ignore
implied by debian/source/options, then that is arguably some kind of
bug, but dgit needs to be able to work with buggy source packages
which appear in the actually-existing archive, and with commits (and
trees) made by downstream users who do not understand (or perhaps even
agree with) the maintainer's debian/source/options and the implied
tar-ignore.
> I think both options, never-add-tar-ignore-defaults-even-if-specified
> and clear-all-tar-ignore are valid, and I might add both, just wanted
> to make sure I understand which one you are requesting here.
So I think I want --clear-all-tar-ignore.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#908956: stretch-pu: package gphoto2-cffi/0.3~a1-1.1~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
python3-gphoto2cffi in stretch is currently completely
broken, just trying to import it fails:
$ python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gphoto2cffi
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/gphoto2cffi/__init__.py", line 1, in
from .gphoto2 import (Camera, list_cameras, supported_cameras,
File "/usr/lib/python3/dist-packages/gphoto2cffi/gphoto2.py", line 15, in
from . import errors, backend
File "/usr/lib/python3/dist-packages/gphoto2cffi/backend.py", line 56, in
'extract_exif': _lib.GP_FILE_OPERATION_EXIF})
File "/usr/lib/python3.5/enum.py", line 243, in __call__
return cls._create_(value, names, module=module, qualname=qualname,
type=type, start=start)
File "/usr/lib/python3.5/enum.py", line 343, in _create_
enum_class = metacls.__new__(metacls, class_name, bases, classdict)
File "/usr/lib/python3.5/enum.py", line 114, in __new__
enum_class = super().__new__(metacls, cls, bases, classdict)
TypeError: type() argument 1 must be str, not bytes
>>>
diff -Nru gphoto2-cffi-0.3~a1/debian/changelog
gphoto2-cffi-0.3~a1/debian/changelog
--- gphoto2-cffi-0.3~a1/debian/changelog2016-04-04 22:28:11.0
+0300
+++ gphoto2-cffi-0.3~a1/debian/changelog2018-09-16 20:31:17.0
+0300
@@ -1,3 +1,17 @@
+gphoto2-cffi (0.3~a1-1.1~deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for stretch.
+
+ -- Adrian Bunk Sun, 16 Sep 2018 20:31:17 +0300
+
+gphoto2-cffi (0.3~a1-1.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Add upstream fix to unbreak python3-gphoto2cffi. (Closes: #896238)
+
+ -- Adrian Bunk Mon, 27 Aug 2018 22:41:25 +0300
+
gphoto2-cffi (0.3~a1-1) unstable; urgency=low
* Updated upstream version merging changes
diff -Nru
gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch
gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch
---
gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch
1970-01-01 02:00:00.0 +0200
+++
gphoto2-cffi-0.3~a1/debian/patches/0001-Make-enum-descriptors-strs-not-bytestrings-7.patch
2018-08-27 22:34:41.0 +0300
@@ -0,0 +1,43 @@
+From 88ed97764365fea5f72a6f2c9aba0323b7fd93a8 Mon Sep 17 00:00:00 2001
+From: Johannes Baiter
+Date: Thu, 7 Jul 2016 16:14:37 +0200
+Subject: Make enum descriptors strs, not bytestrings (#7)
+
+---
+ gphoto2cffi/backend.py | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/gphoto2cffi/backend.py b/gphoto2cffi/backend.py
+index c49db11..21edc4b 100644
+--- a/gphoto2cffi/backend.py
b/gphoto2cffi/backend.py
+@@ -48,7 +48,7 @@ LOG_LEVELS = {
+ _lib.GP_LOG_DEBUG: logging.DEBUG}
+
+
+-FILE_OPS = IntEnum(b'FileOperations', {
++FILE_OPS = IntEnum('FileOperations', {
+ 'remove': _lib.GP_FILE_OPERATION_DELETE,
+ 'extract_preview': _lib.GP_FILE_OPERATION_PREVIEW,
+ 'extract_raw': _lib.GP_FILE_OPERATION_RAW,
+@@ -56,7 +56,7 @@ FILE_OPS = IntEnum(b'FileOperations', {
+ 'extract_exif': _lib.GP_FILE_OPERATION_EXIF})
+
+
+-CAM_OPS = IntEnum(b'CameraOperations', {
++CAM_OPS = IntEnum('CameraOperations', {
+ 'capture_image': _lib.GP_OPERATION_CAPTURE_IMAGE,
+ 'capture_video': _lib.GP_OPERATION_CAPTURE_VIDEO,
+ 'capture_audio': _lib.GP_OPERATION_CAPTURE_AUDIO,
+@@ -65,7 +65,7 @@ CAM_OPS = IntEnum(b'CameraOperations', {
+ 'trigger_capture': _lib.GP_OPERATION_TRIGGER_CAPTURE})
+
+
+-DIR_OPS = IntEnum(b'DirectoryOperations', {
++DIR_OPS = IntEnum('DirectoryOperations', {
+ 'remove': _lib.GP_FOLDER_OPERATION_REMOVE_DIR,
+ 'create': _lib.GP_FOLDER_OPERATION_MAKE_DIR,
+ 'delete_all': _lib.GP_FOLDER_OPERATION_DELETE_ALL,
+--
+2.11.0
+
diff -Nru gphoto2-cffi-0.3~a1/debian/patches/series
gphoto2-cffi-0.3~a1/debian/patches/series
--- gphoto2-cffi-0.3~a1/debian/patches/series 2016-04-04 22:24:03.0
+0300
+++ gphoto2-cffi-0.3~a1/debian/patches/series 2018-08-27 22:41:25.0
+0300
@@ -0,0 +1 @@
+0001-Make-enum-descriptors-strs-not-bytestrings-7.patch
Bug#908494: lightning: Same problem for me
Package: lightning Version: 1:60.0-3 Followup-For: Bug #908494 Dear Maintainer, Upgrade from 52.9.1-1 to 60.x after upgrade the calendar is not working anymore I thunderbird 52.9.1-1 in the addon page the lightnig is showed as 5.4.9.1, last update form 16.9.2018. After upgrade to 60.x there calender is showed 6.2 last updated in Jan 2010. I also have tested all suggestions from mozilla, mentioned in https://support.mozilla.org/en-US/kb/calendar-updates-issues-thunderbird without success. Also the console or dev tools tells nothing. I have also created a topic in a german forum to get some help, there is also a scrrenshot from the addon page. https://debianforum.de/forum/viewtopic.php?f=29=170751 For now I have downgraded to 52.9.1-1 which solved this for me. regards Micha -- 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.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lightning depends on: ii thunderbird 1:60.0-3 lightning recommends no packages. Versions of packages lightning suggests: pn calendar-google-provider ii fonts-lyx 2.3.0-3 -- no debconf information
Bug#908512: Docked apps icons appear broken (with a standard icon)
reassign 908512 libgnustep-gui 0.26.2-3 thanks On Mon, Sep 10, 2018 at 07:32:16PM +0200, Gürkan Myczko wrote: > And the following GNUstep applications (once the apps are launched, > an icon appears). but for TalkSoup.app, VolumeControl.app, and > TextEdit.app they are not 64x64, more like 32x32... This is a known issue; I believe it is fixed in git master. I'll backport the patches at some point.
Bug#893541: stretch-pu: package isort/4.2.5+ds1-2+deb9u1
Control: tags -1 - moreinfo
On Mon, Jun 25, 2018 at 04:18:53AM +0200, Andreas Beckmann wrote:
> Control: tag -1 moreinfo
>
> On Mon, 19 Mar 2018 21:36:15 +0200 Adrian Bunk wrote:
> > Fix the dependencies of python-isort from empty to:
> > Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~)
>
> There is at least python-pkg-resources missing, too. #902327
Thanks for noticing, updated debdiff is attached.
The dependency changes are now:
python-isort
{+Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~)+}
isort
Depends: python3-isort, {+python3-pkg-resources,+} python3:any (>= 3.0~)
> Andreas
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
diff -Nru isort-4.2.5+ds1/debian/changelog isort-4.2.5+ds1/debian/changelog
--- isort-4.2.5+ds1/debian/changelog2016-07-20 01:31:43.0 +0300
+++ isort-4.2.5+ds1/debian/changelog2018-09-16 20:06:57.0 +0300
@@ -1,3 +1,14 @@
+isort (4.2.5+ds1-2+deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Add missing dependency on python3-pkg-resources. Thanks to
+Andreas Beckmann for reporting the issue. (Closes: #902327)
+ * Fix dependencies of the python2 package by using the correct
+${python:Depends} substvar instead of ${python3:Depends}. Thanks to Paul
+Wise for catching it. (Closes: #884682)
+
+ -- Adrian Bunk Sun, 16 Sep 2018 20:06:57 +0300
+
isort (4.2.5+ds1-2) unstable; urgency=medium
* Add python-isort package for Python 2 module (closes: #802582).
diff -Nru isort-4.2.5+ds1/debian/control isort-4.2.5+ds1/debian/control
--- isort-4.2.5+ds1/debian/control 2016-07-20 01:32:16.0 +0300
+++ isort-4.2.5+ds1/debian/control 2018-09-16 20:06:39.0 +0300
@@ -22,7 +22,8 @@
Package: isort
Architecture: all
-Depends: python3-isort, ${misc:Depends}, ${python3:Depends}
+Depends: python3-isort, python3-pkg-resources,
+ ${misc:Depends}, ${python3:Depends}
Description: utility for sorting Python imports
isort is a Python utility / library to sort imports alphabetically, and
automatically separated into sections. It provides a command line
@@ -33,7 +34,7 @@
Package: python-isort
Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}
+Depends: ${misc:Depends}, ${python:Depends}
Description: library for sorting Python imports (Python 2)
isort is a Python utility / library to sort imports alphabetically, and
automatically separated into sections. It provides a command line
Bug#883851: kodi: Crash Loop when inserting Audio CD
Hello all, I think this bug is a duplicate of #885606 (or vice versa). Because the stack looks quite similar, especially the line in libcdio.so.17 matches in both log files: /lib/x86_64-linux-gnu/libcdio.so.17(+0x8937) Kind regards, Bernhard
Bug#893792: balsa: Unable to send mail since the latest upgrade
On Thu, Mar 22, 2018 at 9:09 AM Nicolas Patrois wrote: > Till the latest upgrade, Balsa can’t send mail anymore. > The remote server complains that: > * It doesn’t support STARTTLS when I try with TLS, > * the password is wrong when I try with SSL. > But the password is OK and TLS used to work until yesterday. I suspect that no one on the Debian GNOME team uses balsa. Since you reported this bug, there has been a bugfix release (2.5.6) for balsa and many other changes in Debian Unstable. Are you still able to reproduce this issue? If so, does 2.5.3-4 from Debian Testing still work? Thanks, Jeremy Bicha
Bug#888747: [keepalived] same Problem
Package: keepalived Version: 1:1.3.2-1 --- Please enter the report below this line. --- Same Problem, After boot or reboot, keepalived couldn't start. "service keepalived restart" is possible and works immidiatley after login. This happens on more then 10 Installations. Writing ip_vs into /etc/modules doesn't solve the problem. HTH, Magnus --- System information. --- Architecture: Kernel: Linux 4.9.0-8-amd64 Debian Release: 9.5 500 stable security.debian.org 500 stable repo.skype.com 500 stable dl.google.com 500 stable debian.mirror.iphh.net 500 jessie packages.cisofy.com 500 bionic packages.microsoft.com 500 artful packages.microsoft.com --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- Magnus Wagner Stiftung Deutsches Historisches Museum Unter den Linden 2 10117 Berlin Tel: 030 20304 113 http(s)://www.dhm.de
Bug#908955: /usr/lib/libglide3.so.3: undefined symbol: __LINE__
Package: libglide3 Version: 2002.04.10ds1-12 Severity: grave I known no one has such a card to test it, but I've just got one compiling xdraw3.o with -fdollars-in-identifiers causes __LINE__ to became an undefined symbol even if specifying -x assembler-with-cpp because is used as $__LINE__ -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libglide3 depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.27-6 ii libx11-6 2:1.6.6-1 ii libxext6 2:1.3.3-1+b2 ii libxxf86dga1 2:1.1.4-1+b3 ii libxxf86vm11:1.1.4-1+b2 pn pciutils libglide3 recommends no packages. libglide3 suggests no packages.
Bug#705534: directly setting Aptitude::UI::Default-Package-View also does not work
I tried to circumvent the theme system because … https://lists.debian.org/debian-user/2008/12/msg00582.html> The theme system is utterly broken, perhaps? That would be my first > guess... > > Daniel but directly setting Aptitude::UI::Default-Package-View to the dselect-theme section defined in aptitude-defaults also wouldn't work. Apart from the header, the screen is completely black - apart from a character in the center. And that changes with the cursor up/down keys.. from the invisible list, package info tabs open when pressing enter! But they have the same broken display. When selecting theme "Vertical-Split", the tab key will move the cursor to the right half of the screen while for "dselect", it jumps to the bottom half. So maybe the widths/heights don't get set properly? The only thing I actually wanted to achieve actually is shrinking the info area to less than half of the screen... setting > aptitude::UI::Default-Package-View::desc::RowExpand "no"; > aptitude::UI::Default-Package-View::desc::Height "5"; seemingly was overly optimistic (E: Couldn't parse layout: unknown view item type "")...
Bug#908769: Removing extensions fixed the problem
I saw in the log some issues with extensions (see below). So I saw through https://extensions.gnome.org/local/ that there was some extensions in "ERROR" state. I removed those and now it works, more specifically I removed workspace-grid Sep 16 13:08:15 floko gnome-software[21013]: no app for changed window-l...@gnome-shell-extensions.gcampax.github.com Sep 16 13:08:15 floko gnome-shell[20848]: Object St.Bin (0x5579a3f83fa0), has been already deallocated - impossible to access to it. This might be caused by the fact that the object has been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: == Stack trace for context 0x5579a28be340 == Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #0 0x5579a2c874a0 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:947 (0x7fe15c9041a8 @ 275) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #1 0x5579a2c87408 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:937 (0x7fe15c904120 @ 128) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #2 0x5579a2c87368 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:1102 (0x7fe15c9044d8 @ 296) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #3 0x5579a2c872d8 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:1280 (0x7fe15c9049a0 @ 16) .. I attached the full log Now I wonder if this is a bug in the extension or if the gnome-shell shouldn't allow this bug to happen Sep 16 13:08:15 floko gnome-shell[1034]: Screen lock is locked down, not locking Sep 16 13:08:15 floko gnome-shell[1034]: Failed to set power save mode for output DP-3: Permission denied Sep 16 13:08:15 floko gnome-shell[1034]: Failed to set power save mode for output eDP-1: Permission denied Sep 16 13:08:15 floko gnome-shell[1034]: An active wireless connection, in infrastructure mode, involves no access point? Sep 16 13:08:15 floko gnome-software[21013]: no app for changed window-l...@gnome-shell-extensions.gcampax.github.com Sep 16 13:08:15 floko gnome-shell[20848]: Object St.Bin (0x5579a3f83fa0), has been already deallocated - impossible to access to it. This might be caused by the fact that the object has been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #0 0x5579a2c874a0 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:947 (0x7fe15c9041a8 @ 275) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #1 0x5579a2c87408 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:937 (0x7fe15c904120 @ 128) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #2 0x5579a2c87368 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:1102 (0x7fe15c9044d8 @ 296) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #3 0x5579a2c872d8 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:1280 (0x7fe15c9049a0 @ 16) Sep 16 13:08:15 floko gnome-shell[20848]: Object St.Bin (0x5579a3f85500), has been already deallocated - impossible to access to it. This might be caused by the fact that the object has been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #0 0x5579a2c874a0 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:948 (0x7fe15c9041a8 @ 304) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #1 0x5579a2c87408 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:937 (0x7fe15c904120 @ 128) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #2 0x5579a2c87368 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:1102 (0x7fe15c9044d8 @ 296) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #3 0x5579a2c872d8 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:1280 (0x7fe15c9049a0 @ 16) Sep 16 13:08:15 floko gnome-shell[20848]: Object St.Bin (0x5579a3f85500), has been already finalized. Impossible to set any property to it. Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #0 0x5579a2c87368 i /home/koike/.local/share/gnome-shell/extensions/workspace-g...@mathematical.coffee.gmail.com/extension.js:1104 (0x7fe15c9044d8 @ 339) Sep 16 13:08:15 floko org.gnome.Shell.desktop[20848]: #1 0x5579a2c872d8 i
Bug#906461: florence: diff for NMU version 0.6.3-1.1
On Fri, Sep 14, 2018 at 04:48:03PM +0200, Jérémy Bobbio wrote: > Hi! > > On 14/09/2018 15:51, Adrian Bunk wrote: > > I've prepared an NMU for florence (versioned as 0.6.3-1.1) and uploaded > > it to DELAYED/14. Please feel free to tell me if I should cancel it. > > Thanks! > > Feel free to upload it right away or even take over the package. > I sadly still haven't found enough time and energy to adjust packages to > my current (non-)involvement in Debian. Unfortunately I do not have a personal interest in this package, I was just fixing some release critical bugs. But if you want to orphan this package (and other packages?), I can do the WNPP bug sending so that other people have the opportunity to adopt. > Lunar 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#908954: linux-image-4.18.0-1-amd64: Please add CONFIG_PINCTRL_AMD=y to support Elantech touchpad
Package: src:linux Version: 4.18.6-1 Severity: normal Dear Maintainer, I would suggest to enable CONFIG_PINCTRL_AMD=y to support Elantech touchpad like the one found the Lenovo IdeaPad 320-15ABR. Without the aforementioned option, the device is simply not available. Recompiling the kernel, with the option enabled, solves the issue. Cheers, Laurento -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64)
