Bug#931714: marked as done (node-request-promise: autopkgtest fails)
Your message dated Wed, 10 Jul 2019 05:51:50 + with message-id and subject line Bug#931714: fixed in node-request-promise 4.2.4-2 has caused the Debian Bug report #931714, regarding node-request-promise: autopkgtest fails to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931714 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: node-request-promise Version: 4.2.4-1 Severity: important Both autopkgtest tests fail with the following message: 8< autopkgtest [16:10:50]: test require: [--- ### ### The "request" library is not installed automatically anymore. ### But is a dependency of "request-promise". ### Please install it with: ### npm install request --save ### /usr/share/nodejs/request-promise/lib/rp.js:23 throw err; ^ Error: Cannot find module 'request' at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15) at Function.Module._load (internal/modules/cjs/loader.js:507:25) at Module.require (internal/modules/cjs/loader.js:637:17) at require (internal/modules/cjs/helpers.js:22:18) at /usr/share/nodejs/request-promise/lib/rp.js:11:16 at module.exports (/usr/lib/nodejs/stealthy-require/lib/index.js:62:23) at Object. (/usr/share/nodejs/request-promise/lib/rp.js:10:19) at Module._compile (internal/modules/cjs/loader.js:689:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10) at Module.load (internal/modules/cjs/loader.js:599:32) at tryModuleLoad (internal/modules/cjs/loader.js:538:12) at Function.Module._load (internal/modules/cjs/loader.js:530:3) at Module.require (internal/modules/cjs/loader.js:637:17) at require (internal/modules/cjs/helpers.js:22:18) at [eval]:1:1 at Script.runInThisContext (vm.js:96:20) at Object.runInThisContext (vm.js:303:38) at Object. ([eval]-wrapper:6:22) at Module._compile (internal/modules/cjs/loader.js:689:30) at evalScript (internal/bootstrap/node.js:587:27) at startup (internal/bootstrap/node.js:265:9) at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3) >8 Please fix it --- End Message --- --- Begin Message --- Source: node-request-promise Source-Version: 4.2.4-2 We believe that the bug you reported is fixed in the latest version of node-request-promise, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 931...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ying-Chun Liu (PaulLiu) (supplier of updated node-request-promise package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 10 Jul 2019 12:57:03 +0800 Source: node-request-promise Binary: node-request-promise Architecture: source all Version: 4.2.4-2 Distribution: unstable Urgency: low Maintainer: Debian Javascript Maintainers Changed-By: Ying-Chun Liu (PaulLiu) Description: node-request-promise - simplified HTTP request client with Promise support Closes: 931714 Changes: node-request-promise (4.2.4-2) unstable; urgency=low . * Fix autopkgtest fail (Closes: #931714) Checksums-Sha1: bb32a90a828c4bc5aef90c756785d0635551e04e 2285 node-request-promise_4.2.4-2.dsc 05cfb867e0fca8ae5020c154abc8c3cebf24d009 2316 node-request-promise_4.2.4-2.debian.tar.xz a0a3cbe12afa50c80796d47145047d6d492f019e 13624 node-request-promise_4.2.4-2_all.deb c2d3285ed1d7836501385841f5ffb53c14f2aa9f 13285 node-request-promise_4.2.4-2_amd64.buildinfo Checksums-Sha256: 97aa610e7a617a469ff0642dc6d5ab7482309bae7b54300e0aa80d9102812a86 2285 node-request-promise_4.2.4-2.dsc 83b9b32236187f13405d1d941fd74194bf961ff4996c9ffe409bf56903e39082 2316 node-request-promise_4.2.4-2.debian.tar.xz 01d74b0508bb4a69665fa6f4905c915fe197b3c8336792e47f94134ea5d18b53 13624 node-request-promise_4.2.4-2_all.deb 0bd67150398bea89aa12cf2c595774c347b24dc7e9d5de2d5343f5fa2c57a7a0 13285 node-request-promise_4.2.4-2_amd64.buildinfo Files: 1deaa44a142ec6f29b379ce90abf81f4 2285 javascript optional node-request-promise_4.2.4-2.dsc d32ab5dc1436d06dd219851ea6467779 2316 javascript optional
Bug#931756: bindgraph stop action fails
Package: bindgraph Version: 0.2a-6 Severity: serious Tags: patch Hello, the sysv init script for bindgraph fails on the stop action with the message start-stop-daemon: matching only on non-root pidfile /var/run/servergraph/bindgraph.pid is insecure Relevant other bugs are 923421, 921016, and 921557. What works for me is adding -u daemon to the start-stop-daemon call on line 63. Bye, Joerg signature.asc Description: PGP signature
Bug#878487: marked as done (checkinstall: Segmentation fault when invoking `checkinstall cmake -P cmake_install.cmake`)
Your message dated Wed, 10 Jul 2019 05:07:21 +
with message-id
and subject line Bug#878487: fixed in checkinstall 1.6.2-5
has caused the Debian Bug report #878487,
regarding checkinstall: Segmentation fault when invoking `checkinstall cmake -P
cmake_install.cmake`
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
878487: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878487
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: checkinstall
Version: 1.6.2-4
Severity: grave
Tags: patch upstream
Justification: renders package unusable
Dear Maintainer,
in installwatch.c, _xstat64() is missing check for initialization
As a consequence of this, if `__xstat64()` is the first function called from
the library, then no initalization is performed and the program segfaults when
trying to call `true_xstat64()` which is uninitialized
This causes a segmentation fault on Debian Stretch when invoking e.g.:
`checkinstall cmake -P cmake_install.cmake`
I filed the bug upstream: https://bugtrack.izto.org:4442/show_bug.cgi?id=171
Patch:
diff --git a/installwatch/installwatch.c b/installwatch/installwatch.c
index 8e6c616..51493b1 100644
--- a/installwatch/installwatch.c
+++ b/installwatch/installwatch.c
@@ -3746,6 +3746,9 @@ int __xstat64(int version,const char *pathname,struct
stat64 *info) {
instw_t instw;
int status;
+ if (!libc_handle)
+ initialize();
+
#if DEBUG
debug(2,"stat64(%s,%p)\n",pathname,info);
#endif
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 4.4.87-ti-xenomai-r121 (PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages checkinstall depends on:
ii dpkg-dev 1.18.24
ii file 1:5.30-1
ii libc6 2.24-11
Versions of packages checkinstall recommends:
ii make 4.1-9.1
Versions of packages checkinstall suggests:
ii gettext 0.19.8.1-2
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: checkinstall
Source-Version: 1.6.2-5
We believe that the bug you reported is fixed in the latest version of
checkinstall, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 878...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Stephen Gelman (supplier of updated checkinstall package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 09 Jul 2019 23:01:02 -0500
Source: checkinstall
Architecture: source
Version: 1.6.2-5
Distribution: unstable
Urgency: medium
Maintainer: Stephen Gelman
Changed-By: Stephen Gelman
Closes: 878487
Changes:
checkinstall (1.6.2-5) unstable; urgency=medium
.
* New maintainer
* Move VCS to salsa
* Update to debhelper compat level 12
* Update to Standards-Version 4.4.0 (no change)
* Minor lintian fixes
* Test installcheck when building the package using included tests
* Fix segfault relating to _xstat64() (Thanks to Giulio Moro for the fix!)
(Closes: #878487)
Checksums-Sha1:
128bead0e367d2bda200784696726f9c75f950ba 2111 checkinstall_1.6.2-5.dsc
cf35654014723b48c6ba424549577bdd709601fa 16368
checkinstall_1.6.2-5.debian.tar.xz
ebfe3be33dfdd0dd0bcad7f74df80e4af14b3a4c 5704
checkinstall_1.6.2-5_amd64.buildinfo
Checksums-Sha256:
81dcc16ab833d9273425697b95a53f9329ec3d6ce19199bec039a9aadb755152 2111
checkinstall_1.6.2-5.dsc
c589bb94a5fe93e007da47892581cfd08b20648b0f8c9a4c6df7d6252592c792 16368
checkinstall_1.6.2-5.debian.tar.xz
ed78c01c040c334d4de30eeb23134a0b6cb15cf752dbea6b56c31f01ef01f68e 5704
checkinstall_1.6.2-5_amd64.buildinfo
Files:
37cb6590d20298a61395c1f677d9b651 2111 admin optional checkinstall_1.6.2-5.dsc
f562acf092537667a8632a8fc03b7f4d 16368 admin optional
checkinstall_1.6.2-5.debian.tar.xz
98147c79e22217292fa566325caacad1 5704 admin optional
checkinstall_1.6.2-5_amd64.buildinfo
-BEGIN PGP SIGNATURE-
iQJGBAEBCgAwFiEEPwDop1BN06KlsbfijqM4hED8f1wFAl0lbssSHHNzZ2VsbUBk
Bug#878487: checkinstall bug
Thanks for reporting this and providing a patch! I just uploaded checkinstall 1.6.2-5 which includes your patch. Unfortunately this didn’t make it into buster but once this fixed version migrates to testing I will upload it to buster-backports. Thanks! Stephen
Bug#931750: telegram-desktop: Packace uninstallable due to alleged lack of dependency
It happens because you've installed some packages from the experimental repository where Telegram Desktop was built against Qt 5.11.3. Now you have to downgrade version of libqt5core5a. Install it from stable repo, for example. Also I would recommend you to decrease priority of the experimental repository.
Bug#931750: telegram-desktop: Packace uninstallable due to alleged lack of dependency
Package: telegram-desktop
Severity: grave
Justification: renders package unusable
I am unable to install this package.
For some reason it got uninstalled on Saturday after Buster's release and when
I try to install it, apt claims that it depends on qtbase-abi-5-11-3.
As the maintainer certaily knows, that's a metapackage that is provided by
libqt5core5a, which *is* installed on my system.
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (900, 'stable'), (800, 'experimental'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.utf8), LANGUAGE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to
en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages telegram-desktop depends on:
ii libavcodec58 7:4.1.3-1
ii libavformat58 7:4.1.3-1
ii libavutil567:4.1.3-1
ii libc6 2.28-10
ii libgcc11:9.1.0-7
ii libglib2.0-0 2.61.1-1
ii liblzma5 5.2.4-1
ii libminizip11.1-8+b1
ii libopenal1 1:1.19.1-1
ii libopus0 1.3-1
ii libqt5core5a 5.12.4+dfsg-4
ii libqt5dbus55.12.4+dfsg-4
ii libqt5gui5 5.12.4+dfsg-4
ii libqt5network5 5.12.4+dfsg-4
ii libqt5widgets5 5.12.4+dfsg-4
ii libssl1.1 1.1.1c-1
ii libstdc++6 9.1.0-7
ii libswresample3 7:4.1.3-1
ii libswscale57:4.1.3-1
ii libx11-6 2:1.6.7-1
ii libxxhash0 0.7.0-1
ii qt5-image-formats-plugins 5.12.4-1
pn qtbase-abi-5-11-3
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages telegram-desktop recommends:
ii fonts-open-sans 1.11-1
*** /home/fmneto/temp.txt
magi: /home/fmneto#> sudo apt install telegram-desktop
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
telegram-desktop : Depends: qtbase-abi-5-11-3
E: Unable to correct problems, you have held broken packages.
magi: /home/fmneto#> sudo aptitude install telegram-desktop
The following NEW packages will be installed:
telegram-desktop{b}
0 packages upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 16.8 MB of archives. After unpacking 44.4 MB will be used.
The following packages have unmet dependencies:
telegram-desktop : Depends: qtbase-abi-5-11-3 which is a virtual package,
provided by:
- libqt5core5a (5.11.3+dfsg1-1), but 5.12.4+dfsg-4
is installed
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) telegram-desktop [Not Installed]
Accept this solution? [Y/n/q/?]
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
magi: /home/fmneto#> sudo apt install libqt5core5a
Reading package lists... Done
Building dependency tree
Reading state information... Done
libqt5core5a is already the newest version (5.12.4+dfsg-4).
libqt5core5a set to manually installed.
Bug#880497: pytimechart: diff for NMU version 1.0.0~rc1-3.3
Package: pytimechart
Version: 1.0.0~rc1-3.2
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for pytimechart (versioned as 1.0.0~rc1-3.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru pytimechart-1.0.0~rc1/debian/changelog pytimechart-1.0.0~rc1/debian/changelog
--- pytimechart-1.0.0~rc1/debian/changelog 2015-03-26 02:25:04.0 -0300
+++ pytimechart-1.0.0~rc1/debian/changelog 2019-07-09 16:15:49.0 -0300
@@ -1,3 +1,11 @@
+pytimechart (1.0.0~rc1-3.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add missing dependencies: python-fonttools, python-kiwisolver.
+Thanks to Antonio Ospite . (Closes #880497)
+
+ -- William Grzybowski Tue, 09 Jul 2019 16:15:49 -0300
+
pytimechart (1.0.0~rc1-3.2) unstable; urgency=low
* Non-maintainer upload with maintainer's permission.
diff -Nru pytimechart-1.0.0~rc1/debian/control pytimechart-1.0.0~rc1/debian/control
--- pytimechart-1.0.0~rc1/debian/control 2015-03-26 02:24:05.0 -0300
+++ pytimechart-1.0.0~rc1/debian/control 2019-07-09 16:06:11.0 -0300
@@ -13,7 +13,8 @@
Package: pytimechart
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
- python-enthoughtbase, python-chaco, python-wxgtk3.0, python-gtk2
+ python-enthoughtbase, python-chaco, python-wxgtk3.0, python-gtk2,
+ python-fonttools, python-kiwisolver
XB-Python-Version: ${python:Versions}
Description: GUI Viewer for Linux kernel traces
PyTimechart provides explorability and overall visualization of Linux
signature.asc
Description: This is a digitally signed message part
Bug#931490: marked as done (should not be removed from Buster (important for visually impaired users)))
Your message dated Tue, 9 Jul 2019 22:27:30 +0200 with message-id <443dceef-cba7-9937-24aa-a0db201aa...@debian.org> and subject line Re: should not be removed from Buster (important for visually impaired users)) has caused the Debian Bug report #931490, regarding should not be removed from Buster (important for visually impaired users)) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931490: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931490 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: revelation Version: 0.4.14-3 Severity: grave Tags: ipv6 Hello I am sorry that I report this so close to Buster release but I just noticeed that in the Debian Buster release notes it is said that Revelation is removed from the Buster. Release notes suggests that passwords can be exported from Revelation and then imported to keepass2 password manager. Unfortunately that is not an option if you are blind or other visually impaired user like I am. Keepass2 password manager is not accessible with the Orca screen reader. So it is not accessible if you are visually impaired. I am still using Debian Stretch, but this problem most likeyly applies to Buster too. I have tried every graphical password manager I can find in Debian Stretch and Revelation isthe only graphical password managerwhich is accessible with the Orca screen reader. None of the other graphical password managers are accessible with the Orca screen reader. So Revelation is really the only accessible graphical password manager for the visually impaired users. So now if Revelation password manager is is not in Buster then suddenly visually impaired users have no way to store their passwords and no way to access passwords already stored in Revelation. This is not ok, it is not ok to remove Revelation from Debian when there is no other accessible password manger and no way to use keepass2 because it is not accessible with Orca screen reader. Please include Revelation in Buster. -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages revelation depends on: ii gconf2 3.2.6-4+b1 ii gnome-extra-icons 1.1-3 ii gnome-icon-theme 3.12.0-2 ii python 2.7.13-2 ii python-cracklib2.9.2-5 ii python-crypto 2.6.1-7 ii python-dbus1.2.4-1+b1 ii python-gnome2 2.28.1+dfsg-1.2 ii python-gobject 3.22.0-2 ii python-gtk22.24.0-5.1 ii shared-mime-info 1.8-1+deb9u1 revelation recommends no packages. revelation suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Hi Mika, On Sat, 06 Jul 2019 14:13:01 +0300 =?utf-8?q?Mika_Hanhij=C3=A4rvi?= wrote: > I am sorry that I report this so close to Buster release but I just noticeed > that in the Debian Buster release notes it is said that Revelation is removed > from the Buster. Release notes suggests that passwords can be exported from > Revelation and then imported to keepass2 password manager. Unfortunately that > is not an option if you are blind or other visually impaired user like I am. > Keepass2 password manager is not accessible with the Orca screen reader. So it > is not accessible if you are visually impaired. I am still using Debian > Stretch, but this problem most likeyly applies to Buster too. I have tried > every graphical password manager I can find in Debian Stretch and Revelation > isthe only graphical password managerwhich is accessible with the Orca screen > reader. None of the other graphical password managers are accessible with the > Orca screen reader. So Revelation is really the only accessible graphical > password manager for the visually impaired users. > > So now if Revelation password manager is is not in Buster then suddenly > visually impaired users have no way to store their passwords and no way to > access passwords already stored in Revelation. > > This is not ok, it is not ok to remove Revelation from Debian when there is no > other accessible password manger and no way to use keepass2 because it is not > accessible with Orca screen reader. > > Please include Revelation in Buster. I am terribly sorry to say that the release team and the accessibility team only learned about your bug
Processed: your mail
Processing commands for cont...@bugs.debian.org: > retitle 931730 libfile-stripnondeterminism-perl: build dependency cycle with > libmonkey-patch-perl Bug #931730 [libfile-stripnondeterminism-perl] libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl Changed Bug title to 'libfile-stripnondeterminism-perl: build dependency cycle with libmonkey-patch-perl' from 'libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl'. > thanks Stopping processing here. Please contact me if you need assistance. -- 931730: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931730 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl
Hi Niko, > the recently added libmonkey-patch-perl dependency in > libfile-stripnondeterminism-perl has unfortunately resulted in a build > dependency cycle […] > I see this new dependency was introduced for normalizing zip archives > (#858431) by changing the Archive::Zip behaviour on the fly. Is this > fixable on the Archive::Zip side? I guess in theory but if I recall the details correctly, I don't /think/ this was going to be a trivial patch to Archive::Zip and my Perl-fu is/was a bit weak. Would pkg-perl apply and upload a patch anyway? Here's a link to my long comment given that I just dug it up for my own benefit: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/commit/f40f555085eeb086bfd4ee1fca1012550790a12d#40676c4ac877689b2966fdabb71ac3686de48aeb_227_224 ... although I would concede that this doesn't speak to the plausibility of the aforementioned patch. > Alternatively, would it be possible to weaken the cycle somehow, for > instance by making this dependency optional and having the packages that > actually need it declare an explicit build dependency ? Would adding a restriction be of use to you? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#931730: libfile-stripnondeterminism-perl: build dependency cycle with libsub-identify-perl
Package: libfile-stripnondeterminism-perl Version: 1.2.0-2 Severity: serious User: debian-p...@lists.debian.org Usertags: perl-5.30-transition X-Debbugs-Cc: debhel...@packages.debian.org, debian-p...@lists.debian.org Hi, the recently added libmonkey-patch-perl dependency in libfile-stripnondeterminism-perl has unfortunately resulted in a build dependency cycle: libsub-identify-perl Build-Depends: debhelper debhelper Depends: dh-strip-nondeterminism dh-strip-nondeterminism Depends: libfile-stripnondeterminism-perl libfile-stripnondeterminism-perl Depends: libmonkey-patch-perl libmonkey-patch-perl Depends: libsuper-perl libsuper-perl Depends: libsub-identify-perl This is a problem for Perl major version transitions because libsub-identify-perl is arch:any and needs to be rebuilt against the new Perl, but its build dependencies will now be uninstallable until it is rebuilt. We need to break the cycle. I see this new dependency was introduced for normalizing zip archives (#858431) by changing the Archive::Zip behaviour on the fly. Is this fixable on the Archive::Zip side? Alternatively, would it be possible to weaken the cycle somehow, for instance by making this dependency optional and having the packages that actually need it declare an explicit build dependency ? Thanks for considering, -- Niko Tyni nt...@debian.org
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Tue, Jul 9, 2019 at 15:55:02 +0200, Christoph Berg wrote: > Re: David Kalnischkies 2019-07-09 <20190709133107.gvib2ibj6w36j447@crossbow> > > A Release file can declare that it will "soon" change its the value of > > a field to foo and apt clients can notify users about this so > > Fwiw, I think this is seriously overengineered. We can't really test > it, and there's high chances the feature will break (itself or > something else) more than it might fix in practise. > Definitely agreed. I think overall what you're trying to do here (the whole "notify the user they're out of date" thing) does not belong in apt. IMO it belongs in higher level tools that are going to heavily depend on the use case and so there's not really a good generic answer you can come up with at the lowest (apt) level. Cheers, Julien
Processed: Re: Bug#931669: ephoto doesn't even start up
Processing control commands: > severity -1 normal Bug #931669 [ephoto] ephoto doesn't even start up Severity set to 'normal' from 'grave' -- 931669: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931669 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931669: ephoto doesn't even start up
Control: severity -1 normal Hi Michael, I bet there's no rendering engine package installed. You can check with: dpkg -l libevas1-engines*. If so, installing libevas1-engines-x should fix the issue. Currently, ephoto Depends on libevas1, which Recommends libevas1-engines*. That can't be tightened to Depends without creating a circular dependency (libevas1-engines* Depends on libevas1). If apt's config disables recommends, it'll leave you in this situation. I've been trying to avoid making all EFL packages depend on the engines, but maybe it's time to give that up. You're the second person to run into this. Thanks, Ross On Mon, Jul 08, 2019 at 10:57:39PM -0500, Michael Meier wrote: > Package: ephoto > Version: 1.5-2 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I've just installed ephoto to try it out. I didn't get very far. It doesn't > even start up. If I try to start it up on the console, that's what it tells > me: > > ERR<26189>:ecore_evas lib/elementary/efl_ui_win.c:5300 > _elm_win_finalize_internal() Cannot create window. > ## Copy & Paste the below (until EOF) into a terminal, then hit Enter > > eina_btlog << EOF > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71dcc0c 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71dd901 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71decd3 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b84c6a 0x7f5ce690 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b870c1 0x7f5ce690 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d127a7 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8750c 0x7f5ce690 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d127a7 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0f8e4 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690 > /usr/bin/ephoto 0x563c68457604 0x563c6843b000 > /usr/bin/ephoto 0x563c68444b7f 0x563c6843b000 > /usr/bin/ephoto 0x563c684448dc 0x563c6843b000 > /lib/x86_64-linux-gnu/libc.so.6 0x7f5ce641e09b 0x7f5ce63fa000 > /usr/bin/ephoto 0x563c6844491a 0x563c6843b000 > EOF > > ERR<26189>:eo lib/eo/eo.c:993 _efl_add_internal_end() Object of class > 'Efl.Ui.Win_Legacy' - Not all of the object constructors have been executed. > ## Copy & Paste the below (until EOF) into a terminal, then hit Enter > > eina_btlog << EOF > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71dcc0c 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71dd901 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71decd3 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0f9bc 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690 > /usr/bin/ephoto 0x563c68457604 0x563c6843b000 > /usr/bin/ephoto 0x563c68444b7f 0x563c6843b000 > /usr/bin/ephoto 0x563c684448dc 0x563c6843b000 > /lib/x86_64-linux-gnu/libc.so.6 0x7f5ce641e09b 0x7f5ce63fa000 > /usr/bin/ephoto 0x563c6844491a 0x563c6843b000 > EOF > > ERR<26189>:evas_main lib/evas/canvas/evas_object_smart.c:718 > _efl_canvas_group_efl_object_destructor() efl_canvas_group_del() was not > called > on this object: 0x40007457 (Efl.Ui.Win_Legacy) > ## Copy & Paste the below (until EOF) into a terminal, then hit Enter > > eina_btlog << EOF > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71dcc0c 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71dd901 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7f5ce71decd3 0x7f5ce71b3000 > /usr/lib/x86_64-linux-gnu/libevas.so.1 0x7f5ce6f9c2c8 0x7f5ce6f02000 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b7025c 0x7f5ce690 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6be29a4 0x7f5ce690 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b82d9b 0x7f5ce690 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0fcec 0x7f5ce6d01000 > /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690 > /usr/bin/ephoto 0x563c68457604 0x563c6843b000 > /usr/bin/ephoto 0x563c68444b7f 0x563c6843b000 > /usr/bin/ephoto 0x563c684448dc 0x563c6843b000 > /lib/x86_64-linux-gnu/libc.so.6 0x7f5ce641e09b 0x7f5ce63fa000 > /usr/bin/ephoto 0x563c6844491a 0x563c6843b000 > EOF > > 1 rmm@RMMbook ~ % ERR<26198>:efreet_desktop lib/efreet/efreet_desktop.c:986 > efreet_desktop_generic_fields_parse() no Name or _Name fields in file > '/home/rmm/.local/share/applications/_home_rmm_local_eclipse_jee-2018-12_eclipse_.desktop' > ## Copy & Paste the
Bug#929506: gbrowse FTBFS: tests fail
Hi Carnë, On Tue, Jul 09, 2019 at 04:53:31PM +0100, Carnë Draug wrote: > On Tue, 9 Jul 2019 at 10:33, Andreas Tille wrote: > > > > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gbrowse_2.56+dfsg-4.rbuild.log.gz > > I have checked the output from that link and it's getting a lot of > "Can't locate Bio/DB/SeqFeature/Store.pm in @INC (you may need to > install the Bio::DB::SeqFeature::Store module)" and another for > Bio::DB::GFF. > > These module used to be part of the BioPerl distribution but has been > moved out to their own distribution, both of which have already been > released. > > Their distributions are: > > Bio-DB-SeqFeature [1,2] > Bio-DB-GFF [3,4] > > [1] https://github.com/bioperl/Bio-DB-SeqFeature/ > [2] https://metacpan.org/release/Bio-DB-SeqFeature > [3] https://github.com/bioperl/Bio-DB-GFF/ > [4] https://metacpan.org/release/Bio-DB-GFF Thanks for analysing this issue. Do you volunteer to create these packages? Kind regards Andreas. -- http://fam-tille.de
Bug#929506: gbrowse FTBFS: tests fail
On Tue, 9 Jul 2019 at 10:33, Andreas Tille wrote: > > Hi Carnė, > > I have not checked but I could imagine that this issue is somehow > connected to the the new upstream version of bioperl. Since you > intended to to restructure the bioperl packages I think this is a good > point in time. Since you are way more involved in bioperl than I I'd be > more than happy if you do this fully according to your own opinion. > Please let me know if you need any help. > [...] > This is also observed by reproducible builds using pbuilder: > > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gbrowse_2.56+dfsg-4.rbuild.log.gz I have checked the output from that link and it's getting a lot of "Can't locate Bio/DB/SeqFeature/Store.pm in @INC (you may need to install the Bio::DB::SeqFeature::Store module)" and another for Bio::DB::GFF. These module used to be part of the BioPerl distribution but has been moved out to their own distribution, both of which have already been released. Their distributions are: Bio-DB-SeqFeature [1,2] Bio-DB-GFF [3,4] [1] https://github.com/bioperl/Bio-DB-SeqFeature/ [2] https://metacpan.org/release/Bio-DB-SeqFeature [3] https://github.com/bioperl/Bio-DB-GFF/ [4] https://metacpan.org/release/Bio-DB-GFF
Bug#931635: marked as done (pg_upgradecluster writes data_directory to postgresql.auto.conf, and gets confused by it on the next upgrade [DATA LOSS])
Your message dated Tue, 09 Jul 2019 14:47:56 + with message-id and subject line Bug#931635: fixed in postgresql-common 203 has caused the Debian Bug report #931635, regarding pg_upgradecluster writes data_directory to postgresql.auto.conf, and gets confused by it on the next upgrade [DATA LOSS] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931635: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931635 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: postgresql-common Version: 200 Severity: critical Tags: buster sid In postgresql-common 200, pg_upgradecluster learned how to copy the contents of postgresql.auto.conf (where ALTER SYSTEM stores its data; #810615). Internally, adapt_conffiles() gets invoked twice, once for postgresql.conf and once for postgresql.auto.conf. This function is also responsible for setting data_directory in the new cluster. Unfortunately, it does this both for postgresql.conf (correct) and postgresql.auto.conf (where ALTER SYSTEM itself refuses to set data_directory, but having a file with it is syntactically ok). At this point, both clusters operate normally, and no harm is done because postgresql.auto.conf contains the correct data_directory setting. However, if this cluster gets upgraded *again*, this extra postgresql.auto.conf setting will confuse the "update config file" logic in postgresql-common's PgCommon.pm. The effect is that on the second upgrade, the new data_directory setting for the 3rd cluster will be written to the postgresql.auto.conf file of the *2nd* cluster. (And the 3rd cluster has a verbatim copy of the old postgresql.auto.conf from the 2nd cluster.) At this point, all three clusters still operate normally because pg_ctlcluster/pg_ctl can still launch the clusters, despite the bad data_directory settings in postgresql.auto.conf. Symptoms of the problem at this point are: * `pg_lsclusters` shows the wrong Data directory for the 2nd and 3rd cluster Ver Cluster Port Status OwnerData directory Log file 9.5 main5433 down postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.5-main.log 9.6 main5432 online postgres /var/lib/postgresql/9.5/main /var/log/postgresql/postgresql-9.6-main.log * `ps` shows the wrong data directory on the postgres command line: /usr/lib/postgresql/9.6/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.6/main/postgresql.conf The really bad problem now using `pg_dropcluster` will wipe the data directory OF THE WRONG CLUSTER. Oops. (And sorry.) I have a patch ready, including testsuite coverage. I'll also upload a 200+deb10u2 package to buster-proposed-updates. Christoph --- End Message --- --- Begin Message --- Source: postgresql-common Source-Version: 203 We believe that the bug you reported is fixed in the latest version of postgresql-common, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 931...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christoph Berg (supplier of updated postgresql-common package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 09 Jul 2019 16:16:57 +0200 Source: postgresql-common Architecture: source Version: 203 Distribution: unstable Urgency: medium Maintainer: Debian PostgreSQL Maintainers Changed-By: Christoph Berg Closes: 507133 931635 Changes: postgresql-common (203) unstable; urgency=medium . DATA LOSS WARNING: pg_upgradecluster from postgresql-common 200 .. 202 will corrupt the data_directory setting when used *twice* to upgrade a cluster (e.g. 9.6 -> 10 -> 11). This update fixes the original problem, and also heals affected clusters on the next upgrade. No additional steps are required. . https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931635 . * pg_createcluster: Allow clusters with owner gid 0. (salsa-ci uses that.) * pg_createcluster: If there are --auth options in createcluster.conf's initdb_options, don't update pg_hba.conf. * pg_upgradecluster: Don't accidentally set (the wrong!) data_directory in postgresql.auto.conf. (Closes: #931635)
Processed: Re: Bug#931714: node-request-promise: autopkgtest fails
Processing control commands: > severity -1 grave Bug #931714 [node-request-promise] node-request-promise: autopkgtest fails Warning: Unknown package 'node-request-promise' Severity set to 'grave' from 'important' Warning: Unknown package 'node-request-promise' -- 931714: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931714 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#921194: amarok: Amarok depends on libmariadbd18, which doesn't exist any longer
Package: amarok Version: 2.9.0-1+b1 Followup-For: Bug #921194 Dear maintainer. The amarok builds just fine as per the steps outlined in https://wiki.debian.org/BuildingTutorial#Rebuild_without_changes No source changes are necessary. I guess the only thing needed is the actual libmariadb* dep version bump. It would be *really* great to have amarok back :) Roman.
Bug#926712: evolution-ews: CVE-2019-3890
On Wed, 2019-07-03 at 11:38 +0100, Luca Boccassi wrote: > On Mon, 17 Jun 2019 11:39:13 +0100 Luca Boccassi < > bl...@debian.org > > > wrote: > > On Tue, 9 Apr 2019 15:52:52 +0200 Sylvain Beucler < > > > > b...@beuc.net > > > > > wrote: > > > Package: evolution-ews > > > Version: 3.30.5-1 > > > X-Debbugs-CC: > > t...@security.debian.org > > > > > Severity: grave > > > Tags: security > > > > > > Hi, > > > > > > The following vulnerability was published for evolution-ews. > > > > > > CVE-2019-3890[0]: > > > No description was found (try on a search engine) > > > > > > If you fix the vulnerability please also make sure to include the > > > CVE (Common Vulnerabilities & Exposures) id in your changelog > > entry. > > > For further information see: > > > > > > [0] > > https://security-tracker.debian.org/tracker/CVE-2019-3890 > > > > > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3890 > > > > https://gitlab.gnome.org/GNOME/evolution-ews/issues/27 > > > > https://gitlab.gnome.org/GNOME/evolution-ews/issues/36 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1678313 > > > > > Note: depends on evolution-data-server patch > > > > > > Cheers! > > > Sylvain Beucler / Debian LTS > > > > Dear Maintainers, > > > > I have backported the required patches and tested them on Buster, > > they > > seem to work fine. > > > > I have opened PRs against the 2 repos on Salsa, but they both > > require > > a > > new debian/buster branch to be created as debian/master has moved > > on > > to > > new releases: > > > > > > https://salsa.debian.org/gnome-team/evolution-data-server/merge_requests/1 > > > > https://salsa.debian.org/gnome-team/evolution-ews/merge_requests/2 > > > > It would be great if we could have evolution-ews in Buster, as it's > > the > > only way to use exchange/o365 for Debian users. > > > > Thanks! > > Dear Maintainers, > > As things stand, Buster users will have no way to use a GUI email > client with an Exchange/OWA/O365 email server. They will have to stay > on Stretch and completely skip Buster, or move to a different > distribution. If they were to upgrade from Stretch to Buster, their > email accounts would simply disappear from their evolution instances, > without any explanation nor warning. > > I'd like to propose to upload the changes mentioned above to > unstable, > let them migrate to Bullseye and then upload to buster-backports, so > that users on Buster have at least that path to avoid breaking this > functionality. This needs to be done before 3.32 moved from > experimental to unstable of course. > > I'd be more than happy to do all of the above work via NMUs. The > evolution-data-server change is backward compatible and does not > require a rebuild of reverse dependencies. Are there any objections > to > this idea? > > Thank you! Dear Maintainers, Uploaders and Gnome Team, As mentioned in the previous mail, I intend to upload to DELAYED/7 NMUs for evolution-data-server and evolution-ews on Friday afternoon (GMT- ish). I am attaching the debdiffs for both. Please let me know if there are any objections. If there are no objections and the NMUs are not cancelled and make it to unstable, and then migrate to bullseye, I then intend to upload the equivalent ~bpo binary NMUs to buster-backports. This way, stretch users that enabled buster-backports before the dist upgrade should have an upgrade path that allows them not to lose their inboxes, calendars and so on. Thank you! -- Kind regards, Luca Boccassi diff -Nru evolution-data-server-3.30.5/debian/changelog evolution-data-server-3.30.5/debian/changelog --- evolution-data-server-3.30.5/debian/changelog 2019-02-04 13:14:07.0 + +++ evolution-data-server-3.30.5/debian/changelog 2019-07-09 14:52:09.0 +0100 @@ -1,3 +1,11 @@ +evolution-data-server (3.30.5-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Backport Let-child-source-with-none-authentication-method-use.patch. +Necessary to fix #926712 (CVE-2019-3890) in evolution-ews + + -- Luca Boccassi Tue, 09 Jul 2019 14:52:09 +0100 + evolution-data-server (3.30.5-1) unstable; urgency=medium * New upstream release diff -Nru evolution-data-server-3.30.5/debian/patches/Let-child-source-with-none-authentication-method-use.patch evolution-data-server-3.30.5/debian/patches/Let-child-source-with-none-authentication-method-use.patch --- evolution-data-server-3.30.5/debian/patches/Let-child-source-with-none-authentication-method-use.patch 1970-01-01 01:00:00.0 +0100 +++ evolution-data-server-3.30.5/debian/patches/Let-child-source-with-none-authentication-method-use.patch 2019-06-17 10:46:30.0 +0100 @@ -0,0 +1,23 @@ +Author: Milan Crha +Description: Let child source with 'none' authentication method use collection source authentication + That might be the same as having set NULL authentication method. +Bug: https://gitlab.gnome.org/GNOME/evolution-ews/issues/27 +Bug-Debian:
Processed: severity of 931712 is important
Processing commands for cont...@bugs.debian.org: > severity 931712 important Bug #931712 [node-duplexer3] node-duplexer3 provides node-duplexer2 but is not usable Severity set to 'important' from 'grave' > thanks Stopping processing here. Please contact me if you need assistance. -- 931712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931712 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931712: node-duplexer3 provides node-duplexer2 but is not usable
After more search, the problem is that if /usr/lib/nodejs/duplexer2 isn't cleaned by dpkg, the link isn't created and the /usr/lib/nodejs/duplexer2 stays empty.
Bug#931424: openjdk-13 should not be part of a Debian release
Control: severity 931424 important As documented in https://lists.debian.org/debian-java/2019/07/msg9.html the openjdk-13 packages (and follow-up non OpenJDK LTS releases should get a little bit more exposure. We just should make sure that these packages are not part of any Debian release.
Processed: openjdk-13 should not be part of a Debian release
Processing control commands: > severity 931424 important Bug #931424 [src:openjdk-13] openjdk-13 should stay in unstable for now Severity set to 'important' from 'serious' -- 931424: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931424 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931214: marked as done (ImportError: No module named oslo.config)
Your message dated Tue, 09 Jul 2019 14:12:55 + with message-id and subject line Bug#931214: fixed in python-os-collect-config 10.3.0-1 has caused the Debian Bug report #931214, regarding ImportError: No module named oslo.config to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931214: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931214 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: python-os-collect-config Version: 0.1.15-1 Severity: grave Justification: renders package unusable Dear Maintainer, I'm trying to use os-collect-config in a Debian stretch instance in an openstack cluster. However, running it immediately leads to an import error: ``` root@epic-sky-gate-server-texage5etawq:/home/debian# os-collect-config Traceback (most recent call last): File "/usr/bin/os-collect-config", line 6, in from os_collect_config.collect import __main__ File "/usr/lib/python2.7/dist-packages/os_collect_config/collect.py", line 25, in from openstack.common import log File "/usr/lib/python2.7/dist-packages/os_collect_config/openstack/common/log.py", line 43, in from oslo.config import cfg ImportError: No module named oslo.config root@epic-sky-gate-server-texage5etawq:/home/debian# cat /etc/debian_version 9.9 root@epic-sky-gate-server-texage5etawq:/home/debian# dpkg -l python-oslo.config 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 python-oslo.config1:3.17.0-3all Common code for Openstack Projects (configuration API) - Python 2.x ``` Here is a reproducer using Docker and Dockers debian:buster image: ```Dockerfile FROM debian:buster ENV DEBIAN_FRONTEND=noninteractive RUN apt-get update RUN apt-get upgrade -y RUN apt-get install -y python-os-collect-config RUN dpkg -l RUN dpkg -S /usr/lib/python2.7/dist-packages/os_collect_config/openstack/common/log.py RUN grep '' /etc/apt/sources.list /etc/apt/sources.list.d/* || true RUN os-collect-config --help ``` I'm attaching the output of running docker build on the above. Regards, Jorrit Fahlke. -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core) 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 python-os-collect-config depends on: ii dpkg 1.18.25 ii python 2.7.13-2 ii python-anyjson 0.3.3-1 ii python-eventlet0.19.0-6 ii python-iso8601 0.1.11-1 ii python-keystoneclient 1:3.2.0-4 ii python-lxml3.7.1-1 ii python-oslo.config 1:3.17.0-3 ii python-pbr 1.10.0-1 ii python-requests2.12.4-1 ii python-six 1.10.0-3 python-os-collect-config recommends no packages. python-os-collect-config suggests no packages. -- no debconf information -- Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics, University of Münster, Orleans-Ring 10, D-48149 Münster Tel: +49 251 83 35146 Fax: +49 251 83 32729 Interpunktion, Orthographie und Grammatik der Email ist frei erfunden. Eine Übereinstimmung mit aktuellen oder ehemaligen Regeln wäre rein zufällig und ist nicht beabsichtigt. signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Source: python-os-collect-config Source-Version: 10.3.0-1 We believe that the bug you reported is fixed in the latest version of python-os-collect-config, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 931...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Thomas Goirand (supplier of updated python-os-collect-config package) (This message was generated automatically at their
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
Re: David Kalnischkies 2019-07-09 <20190709133107.gvib2ibj6w36j447@crossbow> > A) For a user with "debian stable" in sources.list the change of the > Codename from buster to bullseye is a giant leap which should not > be done carelessly or even automatically in the background. I agree that stopping "apt-get update" here makes sense. > B) For a user with "debian buster" in sources.list the change of the > Suite from e.g. stable to oldstable is an important event as well; not > right at this moment as there is a grace period, but security support is > about to end and plans should be set in motion on how to deal with that. Refusing to continue with non-interactive (!) operation here is totally wrong. The system is configured perfectly fine to use "buster", and just because buster is moving from testing to stable, or stable to oldstable doesn't justify breaking 100s of installations in my data center. The message that I should probably be looking into dist-upgrading my data center will be sent to me in form of debian-announce, the general news, or whatever other mechanism. I need to get that message once, not once per system. What I don't need is 100s of systems breaking "apt-get update" because that means I won't get monitoring messages about security updates either (where one message per system makes sense). > APT isn't a newspaper, but at least for me it seems wrong that the one > tool people associate with getting packages has absolutely nothing to > say about big events at the vendor who issues my packages. If you chose to send a message, that's ok, but the message must not break non-interactive, unattended apt-get operation. (At the very least, don't break "apt-get". For more fancy things, there's "apt".) > A Release file can declare that it will "soon" change its the value of > a field to foo and apt clients can notify users about this so Fwiw, I think this is seriously overengineered. We can't really test it, and there's high chances the feature will break (itself or something else) more than it might fix in practise. Christoph
Processed: affects 931712
Processing commands for cont...@bugs.debian.org: > affects 931712 node-request-promise node-module-deps node-multipipe > node-static-module node-stream-combiner2 Bug #931712 [node-duplexer3] node-duplexer3 provides node-duplexer2 but is not usable Added indication that 931712 affects node-request-promise, node-module-deps, node-multipipe, node-static-module, and node-stream-combiner2 > thanks Stopping processing here. Please contact me if you need assistance. -- 931712: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931712 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Jul 08, 2019 at 12:19:36PM +0200, Julian Andres Klode wrote: > Anyway, this was not my thing so I might be misrepresenting or missing > things :) First of all: I am happy that I still manage to "break the world" (FSVO world) – in other words that is "my thing" , but I mostly forgot about it as it was implemented two years ago at the start of the last release cycle so that everyone would have enough time to cry at me … worked brilliantly I guess… Anyway, that apt is enforcing the metadata isn't changing is a security feature in that if you don't check an attacker can reply to a request to foo-security with foo – perfectly signed and everything so apt has no chance to detect this and the user believes everything is fine – even seeing files downloaded from -security – while the user never receives data for -security. foo has no Valid-Until header so the attacker can keep that up for basically ever. Compared to that serving old versions of -security itself is guarded by Valid-Until. Not serving any data has basically the same result, but the errors involved might eventually raise some alarm bells. So that is a good strategy to keep you from ever installing security upgrades. So, after establishing that metadata shouldn't change all the time, lets look at the individual metadata pieces. Th recent thread on (not) using suite/codename/version to refer to a release is not only done in documentation and sources.list, but also in configuration for example in apt_preferences (which apt could check theoretically) and unattended- upgrades (which apt can't realistically check). Many of these configuration pieces for break silently and/or run guard automatic processes. People are also not very consistent in that they refer to an release in different ways depending on the situation: While the sources.list might refer to buster, the config for unattended upgrades could easily refer to packages from stable to install automatically. A) For a user with "debian stable" in sources.list the change of the Codename from buster to bullseye is a giant leap which should not be done carelessly or even automatically in the background. B) For a user with "debian buster" in sources.list the change of the Suite from e.g. stable to oldstable is an important event as well; not right at this moment as there is a grace period, but security support is about to end and plans should be set in motion on how to deal with that. (A & B assume Debian for brevity. In other repos changes can have even bigger/different effects, but that mail would get even longer if I would write yet more examples) Both situations deserve nagging the user in my opinion – preferably with a pointer to specific details [which apt clients do if a Release-Notes field is present in the Release file] – even if we ignore the risk of breaking existing configuration on the system. APT isn't a newspaper, but at least for me it seems wrong that the one tool people associate with getting packages has absolutely nothing to say about big events at the vendor who issues my packages. That said, while I might be able to hold my ground on A) with the remark that setting Acquire::AllowReleaseInfoChange::Codename "true" on system where you know that upgrade processes can be ignored. (setting it to true by default and letting d-i disable it for >= standard feels dirty). On B) I got serious backlash through and I might agree given that I said "grace period" myself and an apt client is basically removing that period now. Not really what I wanted… As such I would propose what Julian has hinted at already as we talked about it on IRC yesterday: A Release file can declare that it will "soon" change its the value of a field to foo and apt clients can notify users about this so they can prepare (or, for that matter help testing if they feel like it). In exchange, if the change happens and apt knows it announced it before it can choose to accept the change without explicit user confirmation & I would propose enabling that for the Suite field. So, lets see how that might look for Debian buster if I "will have had" deployed a time machine: On 2019-06-11, perhaps a bit earlier: $ cat buster/Release Codename: buster Future-Codename: bullseye Suite: testing Future-Suite: stable Future-Version: 10.0 Future-Release-Notes: https://example.org/preparing-for-buster $ apt update N: Repository '…' changes its 'Suite' value from 'testing' to 'stable' soon. N: Repository '…' changes its 'Codename' value from 'buster' to 'bullseye' soon. N: Repository '…' changes its 'Version' value from '' to '10.0' soon. N: More information about this can be found online in the Release notes at: https://example.org/preparing-for-buster Some of these N: will be wrong depending on how you choose to refer to the repository in your sources.list – I guess we could filter with some heuristics – or not, I kinda like how that lists the options. Anyway, as N are notices they do not change the exit status
Bug#930531: marked as done (grub2-common: grub-install --force-extra-removable does not work properly with Secure Boot)
Your message dated Tue, 09 Jul 2019 13:38:05 + with message-id and subject line Bug#930531: fixed in grub2 2.04-1 has caused the Debian Bug report #930531, regarding grub2-common: grub-install --force-extra-removable does not work properly with Secure Boot to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 930531: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930531 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: grub2-common Version: 2.02+dfsg1-18 Severity: serious Hey Colin, Now that we have shim and signed binaries in the archive, the extra code to install grubXXX.efi to the removable media path has to take this into account too, or people using secure boot will end up with broken systems that won't boot. Looking into code to do this now. -- Package-specific info: *** BEGIN /proc/mounts /dev/mapper/tack--vg-lv_root / ext4 rw,relatime,errors=remount-ro 0 0 /dev/sda2 /boot ext2 rw,relatime,block_validity,barrier,user_xattr,acl,stripe=4 0 0 /dev/sda1 /boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_scratch /scratch ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_scratch /var/www/mirror ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/buster-amd64-ae95d8fb-ca7e-4d82-8da8-45d8e8dc78bc ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/buster-amd64-ae95d8fb-ca7e-4d82-8da8-45d8e8dc78bc/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/buster-amd64-ae95d8fb-ca7e-4d82-8da8-45d8e8dc78bc/tmp ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-410245e6-819e-42a5-a194-9ae0b254ef7f ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/sid-410245e6-819e-42a5-a194-9ae0b254ef7f/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-410245e6-819e-42a5-a194-9ae0b254ef7f/tmp ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-4568a602-5a45-4ec9-9103-fb115cc4f1a4 ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/sid-4568a602-5a45-4ec9-9103-fb115cc4f1a4/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-4568a602-5a45-4ec9-9103-fb115cc4f1a4/tmp ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-6544df41-9ed7-490a-8f32-df7aa7cb09cb ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/sid-6544df41-9ed7-490a-8f32-df7aa7cb09cb/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-6544df41-9ed7-490a-8f32-df7aa7cb09cb/tmp ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-6616ad0e-5db2-4d38-96a4-2680a17ca733 ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/sid-6616ad0e-5db2-4d38-96a4-2680a17ca733/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-6616ad0e-5db2-4d38-96a4-2680a17ca733/tmp ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-9471e88b-b7e3-4973-b8d2-07dd531b56a8 ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/sid-9471e88b-b7e3-4973-b8d2-07dd531b56a8/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-9471e88b-b7e3-4973-b8d2-07dd531b56a8/tmp ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-96cd9c31-1413-45a3-aa51-fc4ab220b5e9 ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/sid-96cd9c31-1413-45a3-aa51-fc4ab220b5e9/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-96cd9c31-1413-45a3-aa51-fc4ab220b5e9/tmp ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-9b8885af-ce11-40f2-8ded-b907cf102d0f ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_home /run/schroot/mount/sid-9b8885af-ce11-40f2-8ded-b907cf102d0f/home ext4 rw,relatime,errors=remount-ro 0 0 /dev/mapper/tack--vg-lv_root /run/schroot/mount/sid-9b8885af-ce11-40f2-8ded-b907cf102d0f/tmp ext4
Bug#931038: marked as done (missing Recommends: for shim-signed)
Your message dated Tue, 09 Jul 2019 13:38:05 + with message-id and subject line Bug#931038: fixed in grub2 2.04-1 has caused the Debian Bug report #931038, regarding missing Recommends: for shim-signed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931038: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931038 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: grub2 Version: 2.02+dfsg1-19 Severity: serious Tags: patch The grub-efi-amd64-signed package recommends shim-signed, but the equivalent grub-efi-ia32-signed and grub-efi-arm64-signed packages are missing the same Recommends: Simple tweak needed to the signing-template, MR ready as soon as I get a bug# from the BTS for this. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- Source: grub2 Source-Version: 2.04-1 We believe that the bug you reported is fixed in the latest version of grub2, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 931...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Colin Watson (supplier of updated grub2 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 09 Jul 2019 11:48:01 +0100 Source: grub2 Architecture: source Version: 2.04-1 Distribution: unstable Urgency: medium Maintainer: GRUB Maintainers Changed-By: Colin Watson Closes: 918700 923855 928628 930290 930531 931038 Changes: grub2 (2.04-1) unstable; urgency=medium . * New upstream release. * debian/upstream/signing-key.asc: Add signing key of new upstream maintainer (Daniel Kiper). . grub2 (2.04~rc1-3) experimental; urgency=medium . [ Will Thompson ] * Fix --disable-quiet-boot. . [ Steve Langasek ] * If we don't have writable grubenv and we're on EFI, always show the menu (merged from Ubuntu). . [ Steve McIntyre ] * Make all the signed EFI arches have a Recommends: from grub-efi-ARCH-signed to shim-signed, not just amd64. Closes: #931038 * Add myself to Uploaders . [ Colin Watson ] * Squash linuxefi* patches into a single patch. . grub2 (2.04~rc1-2) experimental; urgency=medium . [ Colin Watson ] * debian/build-efi-images: Add tpm on x86_64-efi (thanks, Chris Coulson). . [ Steve McIntyre ] * Add the ntfs module to signed UEFI images. Closes: #923855 * Add the cpuid module to signed UEFI images. Closes: #928628 * Add the play module to signed UEFI images. Closes: #930290 * Add an extra di-specific version of the UEFI netboot image with a different baked-in prefix value. Helps to fix #928750. * Deal with --force-extra-removable with signed shim too. Closes: #930531 . grub2 (2.04~rc1-1) experimental; urgency=medium . * New upstream release candidate. - getroot: Save/restore CWD more reliably on Unix (closes: #918700). * Rename patches to use "-" as a separator rather than "_" (except when referring to a file, function, or command containing a "_"). * Fix format of debian/copyright. Checksums-Sha1: 832056d4d5af6a9d355fe5500efd7368dae9fbe4 7152 grub2_2.04-1.dsc 3ed21de7be5970d7638b9f526bca3292af78e0fc 6393864 grub2_2.04.orig.tar.xz d6df202a9bfa89abe2d7f288c1d438197c6f371a 833 grub2_2.04.orig.tar.xz.asc b123422da475b2e27a24238d9a3c3b761b76070a 1048688 grub2_2.04-1.debian.tar.xz Checksums-Sha256: 41d29cc645fd4bf34ce293267ea10411315d41949c0ec40f44aa0ea001e9787b 7152 grub2_2.04-1.dsc e5292496995ad42dabe843a0192cf2a2c502e7ffcc7479398232b10a472df77d 6393864 grub2_2.04.orig.tar.xz 955cc63196020e3a70dbb1834ec8b6a1808b1100bc878431c52aa0dd7e6a2532 833 grub2_2.04.orig.tar.xz.asc 454ea9fda65ec121eed2f0e2cc97ffcd77d3412fc953e048c6487c34bbab9b40 1048688 grub2_2.04-1.debian.tar.xz Files: 57d567efd0a5d21700ecfcd5ab035541 7152 admin optional
Bug#931712: node-duplexer3 provides node-duplexer2 but is not usable
Package: node-duplexer3
Version: 0.1.4-4
Severity: grave
node-duplexer3 provides node-duplexer2: /usr/lib/nodejs/duplexer2 is a
symblik to /usr/lib/nodejs/duplexer3. Nodejs now looks at package.json
"name" field and refuse to load it:
$ node -e 'require("duplexer2")'
internal/modules/cjs/loader.js:583
throw err;
^
Error: Cannot find module 'duplexer2'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
at Function.Module._load (internal/modules/cjs/loader.js:507:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at [eval]:1:1
at Script.runInThisContext (vm.js:96:20)
at Object.runInThisContext (vm.js:303:38)
at Object. ([eval]-wrapper:6:22)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at evalScript (internal/bootstrap/node.js:587:27)
This renders some packages unusable.
2 ways:
- provide a valid /usr/lib/nodejs/duplexer2
- require to patch package that use it (node-multipipe for example)
Bug#931709: marked as done (diffoscope: testsuite failure on all archs)
Your message dated Tue, 09 Jul 2019 13:34:16 + with message-id and subject line Bug#931709: fixed in diffoscope 117 has caused the Debian Bug report #931709, regarding diffoscope: testsuite failure on all archs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931709: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931709 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: diffoscope Version: 116 Severity: serious Justification: autopkgtests failures are RC since bullseye Tags: patch Hello, you have an autopkgtest failure on sid for version 116, due to missing tools at runtime. While we are at it, there are a few tools that aren't available everywhere, due to different architectures, so I crafted a patch that should make hopefully testsuite pass everywhere. diff -Nru diffoscope-116/debian/tests/pytest diffoscope-116ubuntu1/debian/tests/pytest --- diffoscope-116/debian/tests/pytest 2019-07-07 16:54:29.0 +0200 +++ diffoscope-116ubuntu1/debian/tests/pytest 2019-07-09 08:46:17.0 +0200 @@ -10,7 +10,7 @@ export LIBGUESTFS_MEMSIZE=128 if [ "$(basename "$0")" = "pytest-with-recommends" ]; then export DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS=1 -export DIFFOSCOPE_TESTS_MISSING_TOOLS="cbfstool otool lipo wasm2wat" +export DIFFOSCOPE_TESTS_MISSING_TOOLS="apktool zipinfo pedump oggDump ppudump cbfstool otool lipo wasm2wat" fi cp -r tests "$ADTTMP" --- diffoscope-116/debian/tests/control.in 2019-07-07 16:54:29.0 +0200 +++ diffoscope-116ubuntu1/debian/tests/control.in 2019-07-09 08:46:17.0 +0200 @@ -7,7 +7,7 @@ Depends: diffoscope, black, python3-pytest, file, linux-image-amd64 [amd64] | linux-image-generic [amd64], %RECOMMENDS%, %PYRECOMMENDS% Tests: pytest -Depends: diffoscope, python3-pytest, file +Depends: diffoscope, python3-pytest, file, python3-tlsh Tests: basic-command-line Depends: diffoscope please accept if possible this patch. NB some tools such as pedump should be available everywhere, but mono is explictly disabling it on arm64... I'm doing a test build enabling it to see what happens https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/17243705 thanks Gianfranco --- End Message --- --- Begin Message --- Source: diffoscope Source-Version: 117 We believe that the bug you reported is fixed in the latest version of diffoscope, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 931...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Chris Lamb (supplier of updated diffoscope package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 09 Jul 2019 10:24:54 -0300 Source: diffoscope Binary: diffoscope Built-For-Profiles: nocheck Architecture: source all Version: 117 Distribution: unstable Urgency: medium Maintainer: Reproducible builds folks Changed-By: Chris Lamb Description: diffoscope - in-depth comparison of files, archives, and directories Closes: 931709 Changes: diffoscope (117) unstable; urgency=medium . [ Chris Lamb ] * Add support for file 5.37. Thanks again to Christoph Biedl for the heads-up in advance. (Closes: reproducible-builds/diffoscope/#57) * Apply patch from Gianfranco Costamagna to fix autopkgtest failures in Debian. (Closes: #931709) . [ Holger Levsen ] * debian/control: Bump Standards-Version to 4.4.0. Checksums-Sha1: 2b83b7656404f43ed003d4210454c8cd15276097 4660 diffoscope_117.dsc d388a8d6b53910a281147269c10133d04e19e82c 1118640 diffoscope_117.tar.xz a9fc0c8429c5a46a4e2520eeb0498b06f317bd5c 131232 diffoscope_117_all.deb 473fecc54bb55a61fe72027a21541108129d04c3 6764 diffoscope_117_amd64.buildinfo Checksums-Sha256: b66e54cfd7a330f7930bd6aaa8ce6dd75583ed10da2d11acd88768e307fdf0e5 4660 diffoscope_117.dsc dbac3c0f96ee61da72ef31310ff5611eab405b7c199ff13e657b0025c756a90c 1118640 diffoscope_117.tar.xz e306a0962d1807724550f0f5c7e8b3e76c4a5d931c104a10d0985d9323eea86e 131232 diffoscope_117_all.deb 26f81df01ab965b6d051af2783c9c64cd523f667d9dc377fd6e71eabe995900a 6764 diffoscope_117_amd64.buildinfo Files:
Processed: Bug#931709 marked as pending in diffoscope
Processing control commands: > tag -1 pending Bug #931709 [src:diffoscope] diffoscope: testsuite failure on all archs Added tag(s) pending. -- 931709: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931709 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931709: marked as pending in diffoscope
Control: tag -1 pending Hello, Bug #931709 in diffoscope reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/reproducible-builds/diffoscope/commit/8e811480e6e8a8ee74149ebfca2c60e72c4aa4e1 Apply patch from Gianfranco Costamagna to fix autopkgtest failures in Debian. (Closes: #931709) (this message was generated automatically) -- Greetings https://bugs.debian.org/931709
Bug#931709: diffoscope: testsuite failure on all archs
Source: diffoscope Version: 116 Severity: serious Justification: autopkgtests failures are RC since bullseye Tags: patch Hello, you have an autopkgtest failure on sid for version 116, due to missing tools at runtime. While we are at it, there are a few tools that aren't available everywhere, due to different architectures, so I crafted a patch that should make hopefully testsuite pass everywhere. diff -Nru diffoscope-116/debian/tests/pytest diffoscope-116ubuntu1/debian/tests/pytest --- diffoscope-116/debian/tests/pytest 2019-07-07 16:54:29.0 +0200 +++ diffoscope-116ubuntu1/debian/tests/pytest 2019-07-09 08:46:17.0 +0200 @@ -10,7 +10,7 @@ export LIBGUESTFS_MEMSIZE=128 if [ "$(basename "$0")" = "pytest-with-recommends" ]; then export DIFFOSCOPE_TESTS_FAIL_ON_MISSING_TOOLS=1 -export DIFFOSCOPE_TESTS_MISSING_TOOLS="cbfstool otool lipo wasm2wat" +export DIFFOSCOPE_TESTS_MISSING_TOOLS="apktool zipinfo pedump oggDump ppudump cbfstool otool lipo wasm2wat" fi cp -r tests "$ADTTMP" --- diffoscope-116/debian/tests/control.in 2019-07-07 16:54:29.0 +0200 +++ diffoscope-116ubuntu1/debian/tests/control.in 2019-07-09 08:46:17.0 +0200 @@ -7,7 +7,7 @@ Depends: diffoscope, black, python3-pytest, file, linux-image-amd64 [amd64] | linux-image-generic [amd64], %RECOMMENDS%, %PYRECOMMENDS% Tests: pytest -Depends: diffoscope, python3-pytest, file +Depends: diffoscope, python3-pytest, file, python3-tlsh Tests: basic-command-line Depends: diffoscope please accept if possible this patch. NB some tools such as pedump should be available everywhere, but mono is explictly disabling it on arm64... I'm doing a test build enabling it to see what happens https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/17243705 thanks Gianfranco
Processed: tagging 931654
Processing commands for cont...@bugs.debian.org: > tags 931654 + sid bullseye Bug #931654 [node-json3] node-json3: json3 is no more maintained Added tag(s) bullseye and sid. > thanks Stopping processing here. Please contact me if you need assistance. -- 931654: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931654 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#929450: caml-crush, build-dependencies unsatisfiable on armel
Followup-For: Bug #929450 Control: tag -1 - bullseye sid The armel binaries have been removed from sid. Andreas
Processed: Re: caml-crush, build-dependencies unsatisfiable on armel
Processing control commands: > tag -1 - bullseye sid Bug #929450 [caml-crush] caml-crush, build-dependencies unsatisfiable on armel Removed tag(s) sid and bullseye. -- 929450: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929450 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Don't release with buster
Processing control commands: > severity -1 serious Bug #930869 [pm-utils] Don't release with buster Severity set to 'serious' from 'wishlist' -- 930869: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930869 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#929506: gbrowse FTBFS: tests fail
Hi Carnë, I have not checked but I could imagine that this issue is somehow connected to the the new upstream version of bioperl. Since you intended to to restructure the bioperl packages I think this is a good point in time. Since you are way more involved in bioperl than I I'd be more than happy if you do this fully according to your own opinion. Please let me know if you need any help. Kind regards Andreas. On Sat, May 25, 2019 at 08:39:20AM +0200, Helmut Grohne wrote: > Source: gbrowse > Version: 2.56+dfsg-4 > Severity: serious > Tags: ftbfs sid > > gbrowse fails to build from source using sbuild in unstable: > > | Test Summary Report > | --- > | t/00.compile.t (Wstat: 4608 Tests: 87 Failed: 18) > | Failed tests: 1, 3, 5, 7, 10, 15, 17-18, 25, 28, 30, 32 > | 34, 40, 44, 46, 59, 86 > | Non-zero exit status: 18 > | t/01.yeast.t(Wstat: 512 Tests: 0 Failed: 0) > | Non-zero exit status: 2 > | Parse errors: Bad plan. You planned 7 tests but ran 0. > | t/02.rearchitecture.t (Wstat: 512 Tests: 0 Failed: 0) > | Non-zero exit status: 2 > | Parse errors: Bad plan. You planned 90 tests but ran 0. > | t/03.render.t (Wstat: 512 Tests: 0 Failed: 0) > | Non-zero exit status: 2 > | Parse errors: No plan found in TAP output > | t/04.remoteserver.t (Wstat: 512 Tests: 0 Failed: 0) > | Non-zero exit status: 2 > | Parse errors: Bad plan. You planned 43 tests but ran 0. > | t/05.deferredrendering.t (Wstat: 512 Tests: 0 Failed: 0) > | Non-zero exit status: 2 > | Parse errors: No plan found in TAP output > | t/06.featuresearch.t(Wstat: 512 Tests: 0 Failed: 0) > | Non-zero exit status: 2 > | Parse errors: Bad plan. You planned 26 tests but ran 0. > | t/07.karyotype.t(Wstat: 512 Tests: 0 Failed: 0) > | Non-zero exit status: 2 > | Parse errors: Bad plan. You planned 3 tests but ran 0. > | Files=10, Tests=93, 2 wallclock secs ( 0.03 usr 0.00 sys + 1.88 cusr > 0.27 csys = 2.18 CPU) > | Result: FAIL > | Failed 8/10 test programs. 18/93 subtests failed. > | dh_auto_test: perl Build test --verbose 1 "TEST_FILES=t/02.rearchitecture.t > t/05.deferredrendering.t t/00.compile.t t/01.yeast.t t/07.balancer.t > t/08.calign.t" returned exit code 255 > | make[1]: *** [debian/rules:23: override_dh_auto_test] Error 2 > | make[1]: Leaving directory '/<>' > | make: *** [debian/rules:12: build] Error 2 > | dpkg-buildpackage: error: debian/rules build subprocess returned exit > status 2 > > This is also observed by reproducible builds using pbuilder: > > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gbrowse_2.56+dfsg-4.rbuild.log.gz > > According to reproducible builds, it does not fail in buster or earlier. > > Helmut > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#926591: marked as done (libelogind0: does not ship SONAME link /lib//libelogind.so.0 -> libsystemd.so.0.25.0)
Your message dated Tue, 09 Jul 2019 08:47:01 +
with message-id
and subject line Bug#926591: fixed in elogind 241.3-1+debian1
has caused the Debian Bug report #926591,
regarding libelogind0: does not ship SONAME link /lib//libelogind.so.0
-> libsystemd.so.0.25.0
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
926591: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926591
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libelogind0
Version: 241.1-1+debian1
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package does not ship the
SONAME link for its library (Policy 8.1).
That link got created later by ldconfig.
>From the attached log (scroll to the bottom...):
0m16.6s DEBUG: Starting command: ['chroot', '/srv/piuparts/tmp/tmpL2PdQe',
'tmp/scripts/pre_remove_40_find_unowned_lib_links']
0m17.2s DUMP:
UNOWNED SYMLINK /lib/x86_64-linux-gnu/libelogind.so.0 -> libsystemd.so.0.25.0
0m17.2s DEBUG: Command ok: ['chroot', '/srv/piuparts/tmp/tmpL2PdQe',
'tmp/scripts/pre_remove_40_find_unowned_lib_links']
I think the symlink setup is overly complicated by using both
/lib and /usr/lib. You should either move everything to /lib
(if that is really required for compatibility with libsystemd0)
or just restrict to /usr/lib (as done in my patch).
I also think you don't need libsystemd.so.0.25.0 symlinks at all,
a libsystemd.so.0 -> libelogind.so.0 symlink should be sufficient.
This produces some noise in piuparts tests and therefore I'd like
to see it fixed for buster.
Andreas
>From 331f7543426163abf628ae13feee4c2253e930c8 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann
Date: Sun, 7 Apr 2019 13:32:25 +0200
Subject: [PATCH] simplify compat symlink setup
---
debian/changelog | 3 +++
debian/libelogind0.links | 3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 572ae4b8f..9ff0bef1d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ elogind (241.1-2~wip1) UNRELEASED; urgency=medium
[ Andreas Messer ]
* Retire package maintenance
+ [ Andreas Beckmann ]
+ * Simplify compat symlink setup. (Closes: #xx)
+
-- Andreas Messer Fri, 15 Mar 2019 18:06:50 +0100
elogind (241.1-1) unstable; urgency=medium
diff --git a/debian/libelogind0.links b/debian/libelogind0.links
index 47785742c..dd1a34455 100755
--- a/debian/libelogind0.links
+++ b/debian/libelogind0.links
@@ -1,3 +1,2 @@
#! /usr/bin/dh-exec
-usr/lib/${DEB_HOST_MULTIARCH}/libelogind.so.0.25.0
lib/${DEB_HOST_MULTIARCH}/libsystemd.so.0.25.0
-lib/${DEB_HOST_MULTIARCH}/libsystemd.so.0.25.0
lib/${DEB_HOST_MULTIARCH}/libsystemd.so.0
+usr/lib/${DEB_HOST_MULTIARCH}/libelogind.so.0
usr/lib/${DEB_HOST_MULTIARCH}/libsystemd.so.0
--
2.11.0
libelogind0_241.1-1+debian1.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: elogind
Source-Version: 241.3-1+debian1
We believe that the bug you reported is fixed in the latest version of
elogind, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 926...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Mark Hindley (supplier of updated elogind package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 09 Jul 2019 08:51:27 +0100
Source: elogind
Architecture: source
Version: 241.3-1+debian1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ecosystem Init Diversity Team
Changed-By: Mark Hindley
Closes: 926591
Changes:
elogind (241.3-1+debian1) unstable; urgency=medium
.
[ Mark Hindley ]
* New upstream release v241.3.
* Upgrade to Standards Version 4.4.0 (no changes).
* Correctly license AppStream metadata as CC0-1.0 in d/copyright.
.
[ Andreas Messer ]
* Retire from maintenance of this package.
.
[ Andreas Beckmann ]
* Simplify libsystemd.so compatibility symlink setup. (Closes: #926591)
Checksums-Sha1:
960067dd4f512852c8278b3cdd2084efc4b02e79 2590 elogind_241.3-1+debian1.dsc
bc60623b90da52c958fb9ae721b0fa2424a9b8a9 1401391 elogind_241.3.orig.tar.gz
