Bug#962246: webext-keepassxc-browser: Cannot connect to keepassxc from chromium
Hi Guillem, thank you for the verbose and helpful report, I appreciate it! :) I followed your pointer to the 'key' in the manifest of the extension, which - ideally - seems to be generated once, i.e., when an extension is uploaded to the Chromium extensions repository for the first time. Once generated it should not change anymore, if I understood it correctly. I documented for future me and other developers in debian/README.source how to obtain that key for the extension and added it in the package to manifest.json. I tried out with a clean Chromium and KeePassXC installation and could make the extension identify itself to KeePassXC with a permitted ID, add credentials for web sites in a KeePassXC database and make the extension receive stored credentials. An upload is pending! In case it turns out that key changes frequently, we need to think of a different solution again :) Thanks and cheers, Bruno signature.asc Description: This is a digitally signed message part
Bug#962315: ITP: libmmap-allocator -- STL allocator that mmaps files
Package: wnpp Severity: wishlist Subject: ITP: libmmap-allocator -- STL allocator that mmaps files Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: libmmap-allocator Version : 0.4.0 Upstream Author : Johannes Thoma * URL : https://github.com/ekg/mmap_allocator * License : LGPL Programming Lang: C Description : STL allocator that mmaps files When reading large files (>100MB) into memory, read() calls are usually not very space and time efficient, since the whole data is copiied at least once. Furthermore, when using STL containers (like a vector for example), data is copiied another time unless the location of the vector content as parameter to read() will be specified. . It would be nice to tell the vector a filename and have the vector mmap the file directly. This not only avoids the read() copiing (and the STL vector copiing) but also allows different processes that read the same file to see the same physical memory. Fortunately STL foresees an interface to do exactly this. . Libmmap-allocator helps to handle big files that contain unstructured data (like doubles or even text files), mmap_allocator is worth a try. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/libmmap-allocator
Bug#962314: golang-goprotobuf-dev: undefined: "github.com/golang/protobuf/proto".ProtoPackageIsVersion4
Package: golang-goprotobuf-dev Severity: wishlist Dear maintainer, This is a blocker for 962023. Could you update this package? This definition introduced in 1.4.0. Thanks -- System Information: Debian Release: bullseye/sid APT prefers groovy APT policy: (500, 'groovy') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-33-generic (SMP w/8 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN:zh (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: OpenPGP digital signature
Bug#962313: apt-listchanges: add syslog/log frontends and title disable option
Package: apt-listchanges Severity: wishlist At $work, we needed a way to direct apt-listchanges output to a file, which we review before sending tested updates to offline systems. We were able to achieve this through a hack running apt with pipetty, setting the pager command to a script and enabling the ignore options, but we wanted a cleaner way to do it. So I have implemented a log frontend with a log file option and a filter command option. I also added an option to disable the apt-listchanges title. Since it was easy to add I also added a syslog frontend for completeness. I wasn't sure if I should use a merge request or a bug, so I have submitted a merge request first and submitted this bug for completeness. https://salsa.debian.org/debian/apt-listchanges/-/merge_requests/5 https://salsa.debian.org/debian/apt-listchanges/-/merge_requests/5.patch https://salsa.debian.org/pabs/apt-listchanges/-/compare?from=debian-sid&to=frontends -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#962312: O: stl-manual -- C++-STL documentation in HTML
Package: wnpp Severity: normal I intend to orphan the stl-manual package. I want to adopt this package because I want to keep it updated in debian. The package description is: This is the documentation for the C++ Standard Template Library as found on SGIs Website.
Bug#962311: move virtualbox-guest-additions-iso from non-free to contrib
Package: virtualbox-guest-additions-iso Severity: normal X-Debbugs-CC: whonix-de...@whonix.org Dear maintainer, package virtualbox-guest-additions-iso is currently in Debian non-free repository. I believe this is might be a mistake. Copyright file [1] of the package is saying > Disclaimer: This package is formally not part of the Debian GNU/Linux distribution, because § 2 (2) of the VirtualBox PUEL license only allows the redistribution of "unmodified copies of the ISO installation medium", but not the source code. Putting the following term into search engines: "unmodified copies of the ISO installation medium" shows only years old search results. The VirtualBox licensing FAQ [2] does not mention the ISO. It only mentions the VirtualBox Extension Pack being under nonfree license Extension Pack Personal Use and Evaluation License (PUEL) [3]. [3] does not mention any ISO either. Editions page [4] stating: > Before version 4.0, there were two editions of VirtualBox: a full binary containing all features and an "Open Source Edition" (OSE) with source code. With version 4.0, there is only one version any more, which is open source, and the closed-source components have been moved to a separate extension pack. When installing from guest using guest additions ISO, there is no PUEL license prompt either. Source code organization page [5] mentions: > src/VBox/Additions/: The "Guest Additions" for Windows and Linux (and possibly more in the future); this is code that must be installed within a guest to optimize its performance and usability. The build system compiles this code into an ISO file that can be mounted as a VM's virtual CD-ROM drive, as described in the user manual. The VirtualBox guest additions source tree is apparently part of OSE. Therefore the build result should also be under OSE. VirtualBox extension pack source code was as far as I know never visible to the general public. Therefore reviewing the situation with today's knowledge, I wouldn't know why virtualbox-guest-additions-iso should be considered being under non-free PUEL license. I've also asked in the VirtualBox forums. [6] Could you therefore please kindly consider to move virtualbox-guest-additions-iso from non-free to contrib? Cheers, Patrick [1] https://metadata.ftp-master.debian.org/changelogs//non-free/v/virtualbox-guest-additions-iso/virtualbox-guest-additions-iso_6.1.8-1_copyright [2] https://www.virtualbox.org/wiki/Licensing_FAQ [3] https://www.virtualbox.org/wiki/VirtualBox_PUEL [4] https://www.virtualbox.org/wiki/Editions [5] https://www.virtualbox.org/wiki/Source_code_organization [6] https://forums.virtualbox.org/viewtopic.php?f=10&t=21374&p=477656#p477656
Bug#962310: chmod 0700 warning messages appears to be incorrect
Package: apt Version: 2.1.6 Severity: minor I noticed, due to the way I have apt setup, that it complains about chmoding some files. I was looking in the source for a way to bypass this message and noticed that 0700 is hard coded in the warning. In apt-pkg/acquire.cc:SetupAPTPartialDirectory() on lines 112 and 119 is where I noticed the message. The chown in the if statement shows it using a variable named mode. The warning message should reflect the mode it was trying to set.
Bug#962309: decopy: lists license files in debian/copyright
Package: decopy Version: 0.2.4.3-0.1 Severity: normal decopy lists license files in debian/copyright, while this is not necessary. See also: https://lintian.debian.org/tags/license-file-listed-in-debian-copyright.html For example, for dulwich it generates a stanza like this: Files: COPYING Copyright: 1989-1991, Free Software Foundation, Inc License: Apache-2 or GPL-2+ (which is actually incorrect since that file contains those two licenses but is not licensed under them) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages decopy depends on: ii bzip2 1.0.8-3 ii libimage-exiftool-perl 11.99-1 ii python3 3.8.2-3 ii python3-debian 0.1.37 ii python3-xdg 0.26-3 ii xz-utils5.2.4-1+b1 Versions of packages decopy recommends: ii python3-regex 0.1.20190819-2+b1 ii python3-tqdm 4.43.0-1 decopy suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/python3/dist-packages/decopy/dep5.py (from decopy package)
Bug#962308: ITP: ceed-cpp -- CEED (CEGUI unified editor) port to C++ and Qt 5
Package: wnpp Severity: wishlist Owner: Olek Wojnar * Package name: ceed-cpp Version : 1.0.0 Upstream Author : Vladimir Orlov * URL : https://github.com/cegui/ceed-cpp * License : GPL-3 Programming Lang: C++ Description : CEED (CEGUI unified editor) port to C++ and Qt 5 CEED C++ is a GPL3-licensed, cross-platform, C++ port of the (now unmaintained) python CEED. It provides a multi-tab CEGUI layout designer and imageset editor. ** The CEGUI package has been in Debian for years but it has limited usefulness without a means of creating/modifying GUIs. This package does that. The original version of CEED was written in Python, was messy, and was unmaintained. This package addresses those shortcomings.
Bug#961986: lix FTBFS: Error: undefined identifier `FracSec`, did you mean function `fracSec`?
tags 961986 +patch
thanks
Some googling of the error message led me via a few links to an upstream patch
at
https://github.com/Abscissa/SDLang-D/pull/70/commits/90e5bdad1d803a507b34d46c5ecf82cb1feb7cd4
I extracted the commit as a patch, tweaked the paths so it would apply to the
Debian lix package and I was able to get succesful builds in debian sid amd64
and raspbian bullseye-staging
My fix has been uploaded to raspbian, a debdiff is attached to this mail. No
intent to NMU in Debian.
(note: the pull request was squashed and merged and the other commit in the
pull request did not seem relevant, so I used the commit from the pull request
rather than the one from the main repo).
diff -Nru lix-0.9.29/debian/changelog lix-0.9.29/debian/changelog
--- lix-0.9.29/debian/changelog 2019-12-10 08:02:16.0 +
+++ lix-0.9.29/debian/changelog 2020-06-05 22:49:20.0 +
@@ -1,3 +1,10 @@
+lix (0.9.29-1+rpi1) bullseye-staging; urgency=medium
+
+ * Add patch from upstream pull request to fix build with new libphobos
+(Closes: 961986)
+
+ -- Peter Michael Green Fri, 05 Jun 2020 22:49:20
+
+
lix (0.9.29-1) unstable; urgency=medium
* New upstream version. (Closes: #941390)
diff -Nru lix-0.9.29/debian/patches/phobos-2.091.patch
lix-0.9.29/debian/patches/phobos-2.091.patch
--- lix-0.9.29/debian/patches/phobos-2.091.patch1970-01-01
00:00:00.0 +
+++ lix-0.9.29/debian/patches/phobos-2.091.patch2020-06-05
22:48:24.0 +
@@ -0,0 +1,39 @@
+Patch taken from
https://github.com/Abscissa/SDLang-D/pull/70/commits/90e5bdad1d803a507b34d46c5ecf82cb1feb7cd4
+with paths adjusted to apply to the Debian lix package.
+
+commit 90e5bdad1d803a507b34d46c5ecf82cb1feb7cd4
+Author: Steven Schveighoffer
+Date: Fri Mar 20 17:26:58 2020 -0400
+
+Remove FracSec usage if not available in Phobos (2.091+) Fixes #68.
+
+diff --git a/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
b/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
+index 593746c..074c705 100644
+--- a/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
b/sdlang-d-0.10.4/sdlang-d/src/sdlang/token.d
+@@ -24,9 +24,11 @@ struct DateTimeFrac
+ {
+ DateTime dateTime;
+ Duration fracSecs;
+- deprecated("Use fracSecs instead.") {
++ static if(is(FracSec)) {
++ deprecated("Use fracSecs instead.") {
+ @property FracSec fracSec() const { return
FracSec.from!"hnsecs"(fracSecs.total!"hnsecs"); }
+ @property void fracSec(FracSec v) { fracSecs = v.hnsecs.hnsecs;
}
++ }
+ }
+ }
+
+@@ -44,9 +46,11 @@ struct DateTimeFracUnknownZone
+ {
+ DateTime dateTime;
+ Duration fracSecs;
+- deprecated("Use fracSecs instead.") {
++ static if(is(FracSec)) {
++ deprecated("Use fracSecs instead.") {
+ @property FracSec fracSec() const { return
FracSec.from!"hnsecs"(fracSecs.total!"hnsecs"); }
+ @property void fracSec(FracSec v) { fracSecs = v.hnsecs.hnsecs;
}
++ }
+ }
+ string timeZone;
+
diff -Nru lix-0.9.29/debian/patches/series lix-0.9.29/debian/patches/series
--- lix-0.9.29/debian/patches/series2018-12-04 09:55:25.0 +
+++ lix-0.9.29/debian/patches/series2020-06-05 22:45:25.0 +
@@ -1 +1,2 @@
dub-i-dub-i-dub-dub-dub
+phobos-2.091.patch
Bug#962243: po4a: POD parser marks =begin/=for/=end format name for translation
Hello Guillem, thanks for the report. I agree that we should move on to Pod::Simple. I started a discussion with the pod-people for guidance, but the ball seems to be on my side now. Too bad I cannot get it rolling right now :( https://www.nntp.perl.org/group/perl.pod-people/2020/05/msg2106.html Any help would be really appreciated here... Thanks, Mt. On Fri, Jun 05, 2020 at 03:27:49AM +0200, Guillem Jover wrote: > Package: po4a > Version: 0.59.1-1 > Severity: normal > > Hi! > > The POD parser marks the format name in =begin/=for/=end tags as > translatable, but this text should not be translated as it is part of > the syntax. I've very briefly checked the po4a and Pod::Parser code > and didn't see an obvious way to handle this, but then realized that > Pod::Parser is being phased out in favor of Pod::Simple, which does > seem to support handling these tags explicitly. > > Here's a test case: > > ,--- format.pod --- > =head1 Title > > =begin format-block > > Some format-specific text. > > =end format-block > > Some B text. > > =for format-for More format-specific text. > `--- > > ,--- po4a-gettextize -f pod -m format.pod --- > […] > #. type: =head1 > #: format.pod:1 > msgid "Title" > msgstr "" > > #. type: =end > #: format.pod:3 format.pod:7 > msgid "format-block" > msgstr "" > > #. type: textblock > #: format.pod:5 > msgid "Some format-specific text." > msgstr "" > > #. type: textblock > #: format.pod:9 > msgid "Some B text." > msgstr "" > > #. type: =for > #: format.pod:11 > msgid "format-for More format-specific text." > msgstr "" > `--- > > Both «format-block» and «format-for» should not be appearing here. :) > > Thanks, > Guillem -- L'enseignement des résultats de la science n'est jamais un enseignement scientifique. -- Gaston Bachelard. signature.asc Description: PGP signature
Bug#962301: ITP: lomiri-ui-toolkit -- Qt Components for Lomiri Operating Environment
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: lomiri-ui-toolkit Version : 0.1.0 Upstream Author : Marius Gripsgard * URL : https://gitlab.com/ubports/core/lomiri-ui-toolkit/ * License : LGPL-3.0 (et al.) Programming Lang: C++ Description : Qt Components for Lomiri Operating Environment Qt Components for Lomiri offers a set of reusable user interface components for Qt Quick 2 / QML. . This is the essential UI toolkit for the Lomiri Operating Environment enhancing Qt5 to its needs. . This package will be maintained by the Debian UBports Packaging Team.
Bug#934666: nvidia-cuda-toolkit: include cuda runtime for arm64
Control: tag -1 moreinfo On 13/08/2019 09.04, Helmut Grohne wrote: > While the cuda > toolkit is only available for these architectures, the cuda runtime > should be available for arm64 as well. Is it possible to package that? If you can tell me where I can find the arm64 binaries ... Andreas
Bug#962307: RFS: anymeal/1.0-1 ITA -- Cookbook database for storing recipes
Package: sponsorship-requests Severity: wishlist Dear mentors, Hope you are all up and well. I am looking for a sponsor for my package "anymeal". It was part of Debian until 10 years ago and I finally got around to doing a full overhaul. * Package name: anymeal Version : 1.0-1 Upstream Author : Jan Wedekind * URL : https://wedesoft.github.io/anymeal/ * License : GPL-3+ * Vcs : https://github.com/wedesoft/anymeal Section : kde It builds those binary packages: anymeal - Cookbook database for storing recipes To access further information about this package, please visit the following URL: https://mentors.debian.net/package/anymeal Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.0-1.dsc Changes since the last upload: * new upstream release * dependencies have changed (e.g. using SQLite instead of MySQL) -- Jan Wedekind http://www.wedesoft.de/
Bug#962306: buster-pu: package b43-fwcutter/1:019-4+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to fix some bugs in b43-fwcutter with commits cherry-picked
from the package in sid:
* Run firmware removal commands under LC_ALL=C. (Closes: #960791)
-> installation/upgrade/removal was failing under (some)
non-English locales, e.g. de_*
* Do not fail while removing no longer existing files. (Closes: #956858)
-> after such a failure, even retrying it under LC_ALL=C would not
recover
* Add dependency on pciutils for lspci.
-> this is used in the postinst
* Add ca-certificates to Depends so that we can download over https.
-> the http download sites redirect to https URLs nowadays
The package is already uploaded.
Andreas
diff -Nru b43-fwcutter-019/debian/changelog b43-fwcutter-019/debian/changelog
--- b43-fwcutter-019/debian/changelog 2019-02-07 02:00:18.0 +0100
+++ b43-fwcutter-019/debian/changelog 2020-06-06 00:33:14.0 +0200
@@ -1,3 +1,16 @@
+b43-fwcutter (1:019-4+deb10u1) buster; urgency=medium
+
+ [ Andreas Beckmann ]
+ * QA upload.
+ * Run firmware removal commands under LC_ALL=C. (Closes: #960791)
+ * Do not fail while removing no longer existing files. (Closes: #956858)
+ * Add dependency on pciutils for lspci.
+
+ [ Raphaël Hertzog ]
+ * Add ca-certificates to Depends so that we can download over https.
+
+ -- Andreas Beckmann Sat, 06 Jun 2020 00:33:14 +0200
+
b43-fwcutter (1:019-4) unstable; urgency=medium
[ Andreas Beckmann ]
diff -Nru b43-fwcutter-019/debian/control b43-fwcutter-019/debian/control
--- b43-fwcutter-019/debian/control 2019-02-07 02:00:18.0 +0100
+++ b43-fwcutter-019/debian/control 2020-06-06 00:33:14.0 +0200
@@ -28,7 +28,9 @@
Architecture: all
Depends:
b43-fwcutter (>= ${source:Version}),
+ pciutils,
bzip2,
+ ca-certificates,
wget,
${misc:Depends},
Replaces:
@@ -52,6 +54,8 @@
Architecture: all
Depends:
b43-fwcutter (>= ${source:Version}),
+ pciutils,
+ ca-certificates,
wget,
${misc:Depends},
Description: firmware installer for the b43legacy driver
diff -Nru b43-fwcutter-019/debian/firmware-b43-installer.postinst
b43-fwcutter-019/debian/firmware-b43-installer.postinst
--- b43-fwcutter-019/debian/firmware-b43-installer.postinst 2019-02-07
02:00:18.0 +0100
+++ b43-fwcutter-019/debian/firmware-b43-installer.postinst 2020-06-06
00:33:14.0 +0200
@@ -11,7 +11,7 @@
DOWNLOAD="${BROADCOM_WL}.tar.bz2"
-URL="http://www.lwfinger.com/b43-firmware/${DOWNLOAD}";
+URL="https://www.lwfinger.com/b43-firmware/${DOWNLOAD}";
SHA512SUM="02487e76e3eca7fe97ce2ad7dc9c5d39fac82b8d5f7786cce047f9c85e2426f5b7ea085d84c7d4aae43e0fe348d603e3229211bab601726794ef633441d37a8b"
@@ -61,7 +61,7 @@
catalog="${FIRMWARE_INSTALL_DIR}/${B43}/firmware-${B43}-installer.catalog"
if [ -f "${catalog}" ]; then
echo "$0: Deleting old extracted firmware..." 1>&2
- xargs -r -0 -a "${catalog}" dpkg-query -S 2>&1 1>/dev/null | sed
-es',[^/]\+,,' | xargs -r rm --
+ LC_ALL=C xargs -r -0 -a "${catalog}" dpkg-query -S 2>&1 1>/dev/null |
sed -es',[^/]\+,,' | xargs -r rm -f --
rm "${catalog}"
fi
mkdir -p "${FIRMWARE_INSTALL_DIR}/${B43}"
diff -Nru b43-fwcutter-019/debian/firmware-b43-installer.prerm
b43-fwcutter-019/debian/firmware-b43-installer.prerm
--- b43-fwcutter-019/debian/firmware-b43-installer.prerm2019-02-07
02:00:18.0 +0100
+++ b43-fwcutter-019/debian/firmware-b43-installer.prerm2020-06-06
00:33:14.0 +0200
@@ -15,7 +15,7 @@
catalog="${FIRMWARE_INSTALL_DIR}/${B43}/firmware-${B43}-installer.catalog"
if [ -f "${catalog}" ]; then
echo "$0: Deleting installed firmware..." 1>&2
- xargs -r -0 -a "${catalog}" dpkg-query -S 2>&1 1>/dev/null |
sed -es',[^/]\+,,' | xargs -r rm --
+ LC_ALL=C xargs -r -0 -a "${catalog}" dpkg-query -S 2>&1
1>/dev/null | sed -es',[^/]\+,,' | xargs -r rm -f --
rm "${catalog}"
rmdir --ignore-fail-on-non-empty
"${FIRMWARE_INSTALL_DIR}/${B43}"
fi
diff -Nru b43-fwcutter-019/debian/firmware-b43legacy-installer.postinst
b43-fwcutter-019/debian/firmware-b43legacy-installer.postinst
--- b43-fwcutter-019/debian/firmware-b43legacy-installer.postinst
2019-02-07 02:00:18.0 +0100
+++ b43-fwcutter-019/debian/firmware-b43legacy-installer.postinst
2020-06-06 00:33:14.0 +0200
@@ -11,7 +11,7 @@
DOWNLOAD="${WL_APSTA}"
-URL="http://downloads.openwrt.org/sources/${WL_APSTA}";
+URL="https://downloads.openwrt.org/sources/${WL_APSTA}";
SHA512SUM="d89ed52045307449bbae79a4d1807cc6cd89ae67c4a22e8e8aa51c1396edbb6ed8b157cd0756faf8b660a537b48b62117c57967f2048245b5b102d9d9bca4bbd"
@@ -61,7 +61,7 @@
catalog="${FIRMWARE_INSTALL_DIR}/${B43}/firmware-${B43}-installer.catalog"
if [ -f "${catalog}" ]; then
echo "$0: Deleting old extracted fir
Bug#962304: amazon-ecr-credential-helper includes no documentation
Control: tags -1 + patch On Fri, Jun 05, 2020 at 10:23:33PM +, Noah Meyerhans wrote: > The ECR credential helper is used transparently by docker if the appropriate > statements are included in ~/.docker/config.json, but the installed package > contains no documentation describing this process. > > At a minimum, including the README.md from the source repository would help, > as > it contains this information. As discussed outside the BTS, there is a man page, but its name corresponds with a binary that a user would never directly execute (it is run automatically by docker). So it's not really clear which man page to consult to learn the proper configuration. So, it would still be helpful to have README.md in place. Alternatively, symlinking the manual page to something more easily discoverable could help. Since there's no binary named "amazon-ecr-credential-helper", it should not go in section 1. Section 7 seems most appropriate. But then the man page's header would be wrong. (it'd still reference section 1) The attached patch will install README.md to the appropriate place. noah diff -Nru amazon-ecr-credential-helper-0.3.1/debian/amazon-ecr-credential-helper.docs amazon-ecr-credential-helper-0.3.1/debian/amazon-ecr-credential-helper.docs --- amazon-ecr-credential-helper-0.3.1/debian/amazon-ecr-credential-helper.docs 1969-12-31 16:00:00.0 -0800 +++ amazon-ecr-credential-helper-0.3.1/debian/amazon-ecr-credential-helper.docs 2020-06-05 16:03:35.0 -0700 @@ -0,0 +1 @@ +README.md diff -Nru amazon-ecr-credential-helper-0.3.1/debian/changelog amazon-ecr-credential-helper-0.3.1/debian/changelog --- amazon-ecr-credential-helper-0.3.1/debian/changelog 2019-12-31 15:55:36.0 -0800 +++ amazon-ecr-credential-helper-0.3.1/debian/changelog 2020-06-05 16:04:11.0 -0700 @@ -1,3 +1,9 @@ +amazon-ecr-credential-helper (0.3.1-2) UNRELEASED; urgency=medium + + * Install README.md to /usr/share/doc (Closes: #962304) + + -- Noah Meyerhans Fri, 05 Jun 2020 16:04:11 -0700 + amazon-ecr-credential-helper (0.3.1-1) unstable; urgency=low [ Noah Meyerhans ]
Bug#934160: Bug#962254: NFS(v4) broken at 4.19.118-2
I've run into a problem which produces the same behavior as bug #934160, but attributed it elsewhere due to other observations. What are the version(s) of the Linux kernel being used on your server and clients? I've confirmed using a 4.9 kernel on a client instead of a 4.19 kernel also works around this issue. In fact one client using a kernel from 4.19.98+1+deb10u1 source doesn't display the issue, but one using 4.19.118+2 source does. This timeframe though doesn't match when you reported the issue. Could be there are several things working together to cause this. I haven't yet tried tried using NFS version 4.1, instead of 4.2. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#962305: libtommath: Documentation .pdf files embed time
Source: libtommath
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
When the build time and timezone vary, the resulting .pdf file includes
an embedded timestamp. It looks like doc/makefile attempts to make the
timestamp reproducible in the generated .pdf, but doesn't catch some
corner cases.
The patch to debian/rules sets FORCE_SOURCE_DATE, which is needed to get
texlive to respect SOURCE_DATE_EPOCH.
The other patch modifies doc/makefile to use SOURCE_DATE_EPOCH directly
rather than a reference timestamp file.
Thanks for maintaining libtommath!
live well,
vagrant
From 031c52564c767985e741a6b10aeedc624544a634 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Fri, 5 Jun 2020 21:26:02 +
Subject: [PATCH 1/2] debian/rules: export FORCE_SOURCE_DATE to allow .pdf
files to be generated reproducibly.
Without FORCE_SOURCE_DATE texlive does not respect SOURCE_DATE_EPOCH:
https://reproducible-builds.org/docs/source-date-epoch/
---
debian/rules | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/rules b/debian/rules
index 97dbb93..b00c0b5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,6 +19,7 @@ export PREFIX=/usr
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
export LIBPATH = $(PREFIX)/lib/$(DEB_HOST_MULTIARCH)
+export FORCE_SOURCE_DATE=1
%:
dh $@
--
2.20.1
From ef8c77d9c5fd62773b467fa6e7b1a5167c4f770b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Fri, 5 Jun 2020 21:55:05 +
Subject: [PATCH 2/2] Add patch to use UTC timezone for PDF generation.
---
debian/patches/series | 1 +
debian/patches/use-utc-timezone | 37 +
2 files changed, 38 insertions(+)
create mode 100644 debian/patches/use-utc-timezone
diff --git a/debian/patches/series b/debian/patches/series
index 1652816..198b971 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
increase-test-timeout
remove-undefined-macro
fix-shift-count-overflow-on-x32
+use-utc-timezone
diff --git a/debian/patches/use-utc-timezone b/debian/patches/use-utc-timezone
new file mode 100644
index 000..003b86f
--- /dev/null
+++ b/debian/patches/use-utc-timezone
@@ -0,0 +1,37 @@
+Author: Vagrant Cascadian
+Subject: Ensure the date is represented in UTC when generating PDF
+ files.
+Description: Use SOURCE_DATE_EPOCH directly rather than a timestamp
+ reference file which can vary between builds.
+ .
+ https://reproducible-builds.org/docs/source-date-epoch/
+
+Index: libtommath/doc/makefile
+===
+--- libtommath.orig/doc/makefile
libtommath/doc/makefile
+@@ -16,15 +16,12 @@ docs: manual
+
+ #LTM user manual
+ mandvi: bn.tex
+- cp bn.tex bn.bak
+- touch --reference=bn.tex bn.bak
+- (printf "%s" "\def\fixedpdfdate{"; date +'D:%Y%m%d%H%M%S%:z' -d @$$(stat --format=%Y bn.tex) | sed "s/:\([0-9][0-9]\)$$/'\1'}/g") > bn-deterministic.tex
++ (printf "%s" "\def\fixedpdfdate{"; date +'D:%Y%m%d%H%M%S%:z' -u -d @$(SOURCE_DATE_EPOCH) | sed "s/:\([0-9][0-9]\)$$/'\1'}/g") > bn-deterministic.tex
+ printf "%s\n" "\pdfinfo{" >> bn-deterministic.tex
+ printf "%s\n" " /CreationDate (\fixedpdfdate)" >> bn-deterministic.tex
+ printf "%s\n}\n" " /ModDate (\fixedpdfdate)" >> bn-deterministic.tex
+ cat bn.tex >> bn-deterministic.tex
+ mv bn-deterministic.tex bn.tex
+- touch --reference=bn.bak bn.tex
+ echo "hello" > bn.ind
+ latex bn ${silent_stdout}
+ latex bn ${silent_stdout}
+@@ -35,7 +32,6 @@ mandvi: bn.tex
+ manual: mandvi
+ pdflatex bn >/dev/null
+ sed -b -i 's,^/ID \[.*\]$$,/ID [<0> <0>],g' bn.pdf
+- mv bn.bak bn.tex
+ rm -f bn.aux bn.dvi bn.log bn.idx bn.lof bn.out bn.toc
+
+ clean:
--
2.20.1
signature.asc
Description: PGP signature
Bug#962254: NFS(v4) broken at 4.19.118-2
On Fri, Jun 05, 2020 at 08:36:31PM +0200, Salvatore Bonaccorso wrote: > This now let some rings bell, the described scenario is very similar > to what was reported in https://bugs.debian.org/934160 > > Respectively > https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and > https://bugzilla.redhat.com/show_bug.cgi?id=1667761 . Those do indeed seem similar and could be the same bug, but attributing the bug to a distinct package. Alternatively this is several bugs and *all* of them need to be present for the issue to occur. Seems I'll need to do some checking of the VM with the earlier kernel and see which updates cause it to break... -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#962304: amazon-ecr-credential-helper includes no documentation
Package: amazon-ecr-credential-helper Version: 0.2.0-1 Severity: normal The ECR credential helper is used transparently by docker if the appropriate statements are included in ~/.docker/config.json, but the installed package contains no documentation describing this process. At a minimum, including the README.md from the source repository would help, as it contains this information.
Bug#962303: ITP: dockerscript -- Builds and runs Dockerfiles in one command
Package: wnpp Severity: wishlist Owner: Denis Babochenko * Package name: dockerscript Version : 1.0.1 Upstream Author : Denis Babochenko * URL : https://github.com/stasmihailov/docker-script * License : GPL-2 Programming Lang: Bash Description : Builds and runs Dockerfiles in one command dockerscript is a cli docker plugin which enables execution of Dockerfiles via a single "docker script" command. This command builds an image, then starts a container with that image and attaches to it via a tty. For example, "docker script from ubuntu" starts an instance of ubuntu, since "from ubuntu" is a valid Dockerfile. You could pass a link to Dockerfile or directory containing it to this command, e.g. "docker script /path/to/my/Dockerfile" I personally use this package. Essentially, it is an effort to try make docker more accessible for basic prototyping. Some of prototyping use cases might be: - testing out some script / functionality in an isolated environment before running it locally - executing same Dockerfile in different Linux distributions to verify that it works on each of them - simple virtualization; for example, I created this request via debian which was ran by `docker script from debian` command, because `reportbug` is not available in ubuntu, which is may daily driver Also, I need a sponsor for this package, as I am not a Debian Developer and cannot upload it to a distro myself
Bug#962302: ITP: libips4o -- In-place Parallel Super Scalar Samplesort
Package: wnpp Severity: wishlist Subject: ITP: libips4o -- In-place Parallel Super Scalar Samplesort Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: libips4o Version : 0.0+git20190618.2206938 Upstream Author : Michael Axtmann * URL : https://github.com/vgteam/ips4o * License : BSD-2-Clause Programming Lang: C++ Description : In-place Parallel Super Scalar Samplesort This is the implementation of the algorithm presented in the eponymous paper, which contains an in-depth description of its inner workings, as well as an extensive experimental performance evaluation. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/libips4o
Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1
On Fri, 2020-06-05 at 13:14 -0500, Michael Shuler wrote: > On 6/5/20 10:37 AM, Adam D. Barratt wrote: > > On Thu, 2020-06-04 at 20:48 -0500, Michael Shuler wrote: > > > Thanks again, uploaded to mentors: > > > > > > RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA > > > certificates > > > https://bugs.debian.org/962245 > > I re-uploaded to mentors the updated 20200601~deb9u1 package > artifacts with the suggested changes committed. Thanks. Please feel free to get that version sponsored. Regards, Adam
Bug#962295: closed by Bernd Zeimetz (Re: Bug#962295: Package: pps-tools file has unexpected size)
Thank you Bernd. I understand now. :-) On Fri, Jun 5, 2020 at 3:00 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > This is an automatic notification regarding your Bug report > which was filed against the package: > > #962295: Package: pps-tools file has unexpected size > > It has been closed by Bernd Zeimetz . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Bernd Zeimetz < > be...@bzed.de> by > replying to this email. > > > -- > 962295: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962295 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Bernd Zeimetz > To: Henry Becker , 962295-d...@bugs.debian.org > Cc: > Bcc: > Date: Fri, 5 Jun 2020 20:52:02 +0200 > Subject: Re: Bug#962295: Package: pps-tools file has unexpected size > Hi, > > Raspbian is not Debian. > Broken raspbian mirrors are also not a Debian problem. > Talk to raspian people. > > You might want to consider to run Debian on your raspberry. > > > https://wiki.debian.org/RaspberryPi#Raspberry_Pi_3_.283.2C_3A.2B-.2C_3B.2B-.29 > > > Bernd > > On 6/5/20 8:40 PM, Henry Becker wrote: > > Package: > > > > Version: <1> > > > > > > > > * I entered the command apt install pps-tools and received the > > unexpected size error message. > > * I did run apt-get-update and apt-get update --fix missing, with > > identical results. > > * I am running Raspbian buster on a pi 3 B > > > > Thank you for your assistance. How will I know if and when this > > problem is resolved? > > > > > > > > Best regards > > > > Hank Becker > > > > > --- > > > > root@NTPServer:/home/pi# lsb_release -a > > No LSB modules are available. > > Distributor ID: Raspbian > > Description:Raspbian GNU/Linux 10 (buster) > > Release:10 > > Codename: buster > > root@NTPServer:/home/pi# > > > > > > > > > --- > > > > Here is the entire update transaction: > > > > root@NTPServer:/home/pi# apt install pps-tools > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > The following package was automatically installed and is no longer > required: > > rpi-eeprom-images > > Use 'sudo apt autoremove' to remove it. > > The following NEW packages will be installed: > > pps-tools > > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > > Need to get 12.2 kB of archives. > > After this operation, 60.4 kB of additional disk space will be used. > > Get:1 http://raspbian-us.ngc292.space/raspbian buster/main armhf > > pps-tools armhf 1.0.2-1 [12.2 kB] > > Err:1 http://raspbian-us.ngc292.space/raspbian buster/main armhf > > pps-tools armhf 1.0.2-1 > > File has unexpected size (32768 != 12164). Mirror sync in progress? > > [IP: 198.211.116.210 443] > > E: Failed to fetch https://113store.cr/es/ File has unexpected size > > (32768 != 12164). Mirror sync in progress? [IP: 198.211.116.210 443] > > E: Unable to fetch some archives, maybe run apt-get update or try with > > --fix-missing? > > > > > > > > -- > Bernd ZeimetzDebian GNU/Linux Developer > http://bzed.dehttp://www.debian.org > GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F > > > -- Forwarded message -- > From: Henry Becker > To: > Cc: > Bcc: > Date: Fri, 5 Jun 2020 14:40:43 -0400 > Subject: Package: pps-tools file has unexpected size > > Package: > > Version: <1> > > > >- I entered the command apt install pps-tools and received the >unexpected size error message. >- I did run apt-get-update and apt-get update --fix missing, with >identical results. >- I am running Raspbian buster on a pi 3 B > > Thank you for your assistance. How will I know if and when this > problem is resolved? > > > > Best regards > > Hank Becker > > --- > > root@NTPServer:/home/pi# lsb_release -a > No LSB modules are available. > Distributor ID: Raspbian > Description:Raspbian GNU/Linux 10 (buster) > Release:10 > Codename: buster > root@NTPServer:/home/pi# > > > > --- > > Here is the entire update transaction: > > root@NTPServer:/home/pi# apt install pps-tools > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following package was automatically installed and is no longer > required: > rpi-eeprom-images > Use 'sudo apt autoremove' to remove it. > The following NEW packages will be installed: > pps-tools > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded
Bug#962299: frogatto-data: Depends on removed ttf-dejavu package
Source: frogatto-data Severity: grave Version: 1.3.1+dfsg-1 Tags: sid bullseye X-Debbugs-CC: mquin...@debian.org vch...@debian.org Dear Debian frogatoo-data maintainers, Your package depends on package ttf-dejavu, which has been a transitional package for 7 years and was just removed in favor of fonts-dejavu. Please properly update your package dependencies and remove any hardcoded references to ttf-dejavu in the source code. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#962300: dmraid: dmraid fails do install in a debootstrapped chroot
Source: dmraid Severity: grave Dear Maintainer, On an amd64 host I created armel chroot with qemu-debootstrap. I attempted to install dracut which pulled dmraid and other packages. After installing all packages but dmraid apt install shows following messages (with set -x added to dmraid.postinst) --8<---cut here---start->8--- # LANG=C apt install dracut Reading package lists... Done Building dependency tree Reading state information... Done dracut is already the newest version (048+80-2). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up dmraid (1.0.0.rc16-8) ... + command -v update-initramfs + udevadm trigger --subsystem-match=block --action=change Failed to scan devices: No such file or directory dpkg: error processing package dmraid (--configure): installed dmraid package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: dmraid E: Sub-process /usr/bin/dpkg returned an error code (1) --8<---cut here---end--->8--- I'd expect the package to install regardles of available devices. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel Kind regards, -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics signature.asc Description: PGP signature
Bug#961042: Wrong package?
Thanks for explanation. Regards Anton Am Fr., 5. Juni 2020 um 07:06 Uhr schrieb Helmut Grohne : > Hi Anton, > > On Thu, Jun 04, 2020 at 10:33:53PM +0200, Anton Gladky wrote: > > I do not quite understand how #961042 can be fixed in yade. > > Could you please check, whether the bug is properly assigned? > > The bug is properly assigned to python3-future. It just shows up in your > view, because it affects yade. It cannot be fixed in yade. Still cross > building yade is broken and this bug documents a cause for that > situation. > > Helmut > >
Bug#962297: frogatto-data: Invalid Vcs-* fields
Source: frogatto-data Severity: important Version: 1.3.1+dfsg-1 Tags: sid bullseye X-Debbugs-CC: mquin...@debian.org vch...@debian.org Dear Debian frogatoo-data maintainers, Your package still references obsolete anonscm.debian.org URLs in Vcs-* fields. Please consider fixing them. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#962298: override: libncurses5-dev:oldlibs/optional, libncursesw5-dev:oldlibs/optional, libtinfo-dev:oldlibs/optional
Package: ftp.debian.org Severity: normal Please change the section of libncurses5-dev, libncursesw5-dev and libtinfo-dev to oldlibs. These are empty transitional packages for libncurses-dev.
Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"
Control: tags -1 + patch On Fri, 5 Jun 2020 20:58:43 +0200 Joachim Reichel wrote: > tag 962236 + upstream > forwarded 962236 > https://savannah.nongnu.org/bugs/index.php?58504 > thanks > > Hi Francesco, Hello Joachim, > > thanks for your report. Thanks for your prompt reply! :-) > I forwarded it as bug (or rather feature request) #58504. Great! I managed to better understand the Perl code that handles the interaction between normalize-ogg and normalize-audio. I have just prepared a patch that fixes the bug. I am attaching it to this message. It's simple enough and should therefore not be covered by copyright. In case it turns out to be copyrighted, it's released under the same terms as normalize-ogg (that is to say: GNU GPL v2 or later). With my patch applied, I get: $ normalize-ogg -a -7.5dBFS --tmpdir /dev/shm -b -n -v -v *.ogg Decoding track01.ogg... Decoding track02.ogg... Decoding track03.ogg... Decoding track04.ogg... Decoding track05.ogg... Decoding track06.ogg... Decoding track07.ogg... Decoding track08.ogg... Decoding track09.ogg... Decoding track10.ogg... Decoding track11.ogg... Decoding track12.ogg... Running normalize... Computing levels... levelpeak -6.8533dBFS 0.dBFS /dev/shm/track01.ogg.11643.wav -8.0583dBFS 0.dBFS /dev/shm/track02.ogg.11643.wav -7.1047dBFS 0.dBFS /dev/shm/track03.ogg.11643.wav -7.2339dBFS 0.dBFS /dev/shm/track04.ogg.11643.wav -7.7699dBFS 0.dBFS /dev/shm/track05.ogg.11643.wav -7.1890dBFS 0.dBFS /dev/shm/track06.ogg.11643.wav -8.0084dBFS 0.dBFS /dev/shm/track07.ogg.11643.wav -7.6048dBFS 0.dBFS /dev/shm/track08.ogg.11643.wav -7.4123dBFS 0.dBFS /dev/shm/track09.ogg.11643.wav -7.5195dBFS 0.dBFS /dev/shm/track10.ogg.11643.wav -8.1773dBFS 0.dBFS /dev/shm/track11.ogg.11643.wav -7.5512dBFS 0.dBFS /dev/shm/track12.ogg.11643.wav Standard deviation is 0.39 dB -7.5314dBFS average level 0.031363dB volume adjustment which is what I wanted to see. Please note that I had to pass the "-v" option twice, since normalize-ogg adds the "--frontend" option, thus decreasing the default verbosity of normalize-audio. By the way, maybe the same modification could be applied even for the code that deals with the "not mix or batch mode", around line 765... Please test the patch and forward it upstream, if you agree. Thank you so much for your kind help! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE normalize-ogg_showstats.diff.gz Description: application/gzip pgp4f19OmtEgj.pgp Description: PGP signature
Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong
On 05 Jun 2020 19:02, Petter Reinholdtsen wrote: > > I discovered what the problem is. The test [ $res ] do not work the way > you want it to. It need to compare with 0, like this: Which is kind of strange, and makes autopkgtest very hard to use since this works fine when run locally like so: # cd # autopkgtest -- null Everything passes when run this way. Easy fix now that you've pointed it out, but passing strange. > diff --git a/debian/tests/test01 b/debian/tests/test01 > index 1c0d63f..73e1fac 100755 > --- a/debian/tests/test01 > +++ b/debian/tests/test01 > @@ -1,4 +1,5 @@ > #!/bin/sh > + > cd debian/tests > > echo "info: compiling" > @@ -7,7 +8,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test01.exp $AUTOPKGTEST_TMP/test01.act > res=$? > -if [ $res ] ; then > +if [ 0 = $res ] ; then > echo "success: test01 produced proper results" > else > echo "error: test01 did not produce proper results" > diff --git a/debian/tests/test02 b/debian/tests/test02 > index fb85d2e..cb4359d 100755 > --- a/debian/tests/test02 > +++ b/debian/tests/test02 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test02.exp $AUTOPKGTEST_TMP/test02.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test02 produced proper results" > else > echo "error: test02 did not produce proper results" > diff --git a/debian/tests/test03 b/debian/tests/test03 > index c028d8b..07d679c 100755 > --- a/debian/tests/test03 > +++ b/debian/tests/test03 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test03.exp $AUTOPKGTEST_TMP/test03.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test03 produced proper results" > else > echo "error: test03 did not produce proper results" > diff --git a/debian/tests/test04 b/debian/tests/test04 > index fd2a6ad..ee31d4a 100755 > --- a/debian/tests/test04 > +++ b/debian/tests/test04 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test04.exp t$AUTOPKGTEST_TMP/est04.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test04 produced proper results" > else > echo "error: test04 did not produce proper results" > > -- > Happy hacking > Petter Reinholdtsen > -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#962296: hotspot: Please package new upstream version (1.2.0)
Package: hotspot Version: 1.1.0+git20190211-1 Tags: sid bullseye Severity: normal Dear Debian hotspot maintainers, The upstream of hotspot has released new version (1.2.0). Please consider packaging it. Thanks! -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"
forwarded 962236 https://savannah.nongnu.org/bugs/index.php?58504 thanks
Bug#962236: normalize-audio: "normalize-ogg -b -n -v" shows less info than "normalize-audio -b -n -v"
tag 962236 + upstream forwarded 962236 https://savannah.nongnu.org/bugs/index.php?58504 thanks Hi Francesco, thanks for your report. I forwarded it as bug (or rather feature request) #58504. Best regards, Joachim
Bug#952901: shotcut: Segmentation fault on 4K monitor
Hi Celelibi Upstream says he's unable to reproduce the problem you have (however he doesn't exactly have the same build), and I'm not able to try, since I don't have access to a 4K monitor. However shortly there should be a new version, probably in experimental, if you have the chance to try that? Best,
Bug#949234: debconf: unable to initialize frontend: Dialog in firmware-b43-installer
Control: tag -1 moreinfo On Sat, 18 Jan 2020 16:32:37 + Jesse57901 wrote: > When running firmware-b43-installer after unpacking and setting up gives > message (debconf:unable to initialize frontend: Dialog). Complete readout > from installer: > > Unpacking firmware-b43-installer (1:019-4) ... > Setting up firmware-b43-installer (1:019-4) ... > debconf: unable to initialize frontend: Dialog > debconf: (Dialog frontend requires a screen at least 13 lines tall and 31 > columns wide.) > debconf: falling back to frontend: Readline How exactly did you observe the problem? a) you ran the command in an extremely small terminal -> no error b) you ran the command in a "regularly sized" terminal, but debconf/Dialog did not recognize it -> we should reassign the bug to debconf (or dialog), since it does not seem specific to b43-* Andreas
Bug#962271: libncurses5-dev: Dependency issue
Thanks a lot Sven. Everything is clear now. On Fri, Jun 5, 2020 at 9:36 PM Sven Joachim wrote: > On 2020-06-05 20:35 +0300, Mohammed Alnajdi wrote: > > > Hey Sven, > > Thanks for the fast reply. > > > >> I fail to see how it does that, could you please elaborate? > > https://packages.debian.org/buster/libncurses5-dev has a dependency of > > https://packages.debian.org/buster/libncurses-dev which has a > dependency of > > libncurses6 > > so the tree of dependency libncurses5-dev > libncurses-dev > > > libncurses6 which i believe is not right in terms of the version i am > > wanting to install. > > If i want to install the latest ncurses i would go with libncurses-dev > but > > i picked libncurses5-dev which is version 5 not 6 so why i am getting > > ncurses6 ? > > As the package description tells you, libncurses5-dev is a transitional > package, and you are not really expected to install it. There are two > reasons why it exists: > > - Upgrades from stretch, where apt would otherwise have uninstalled > libncurses5-dev. It is better to pull in libncurses-dev, so that you > don't have to install it manually. > > - Lots of packages build-depend on libncurses5-dev, and I did not want > to file dozens or even hundreds of bugs to change them when a > transitional package solves the problem. > > >> Sorry, not going to happen. In general Debian only provides -dev > >> packages for the latest ABI of libraries, and ncurses is no exception, > >> especially as its API has not changed. > > example python3-dev, python2-dev. > > Those have actually incompatible APIs and need to coexist. By contrast, > any software that worked with libncurses5 should continue to work with > libncurses6 after recompiling. Which is what Debian did for hundreds of > packages. :-) > > > If this is expected behavior than sorry. I am new to this i upgraded from > > stretch to buster and it took me to think issue. > > It is expected behavior, although the libncurses5-dev package should > probably be removed at some point in the future. > > Cheers, >Sven >
Bug#962245: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
On 6/5/20 10:35 AM, Adrian Bunk wrote: Except for keeping debian/NEWS you were actually backporting everything that was possible, this was not a 20161130+nmu1+deb9u2 release that cherry-picked only one or few changes. Given the nature of ca-certificates it was IMHO the correct decision to backport as much as possible, it is just not "backporting as little as possible". Since similar updates to stable releases might happen in the future, I would recommend that you try to get build and runtime dependencies in unstable to a level that allows rebuilding the package in all supported Debian releases. For compatibility with buster this would include staying at dh compat <= 12. "Backporting everything possible" changes are often safest when the only change in the ~deb10u1 source package is the entry in debian/changelog. I uploaded an updated package for 20200601~deb9u1 to mentors and updated #962155 for approval. Backporting the latest changes to stable and oldstable was the essence of a conversation on making that simpler with this package. These uploads get us a lot closer. The branch diffs are not far off now. Stretch has an openssl version without `openssl rehash`, but that is not a large diff. Both stretch & buster will have python->python3 difference from unstable on the next release, but that's also not a large diff. I hadn't thought about leaving older compat and standards in unstable, I generally try to keep lintian pleased.. not a bad idea, if no one minds much. Thanks again - I'll update this RFS when #962155 comes back from the release team. Michael
Bug#962295: Package: pps-tools file has unexpected size
Package: Version: <1> * I entered the command apt install pps-tools and received the unexpected size error message. * I did run apt-get-update and apt-get update --fix missing, with identical results. * I am running Raspbian buster on a pi 3 B Thank you for your assistance. How will I know if and when this problem is resolved? Best regards Hank Becker --- root@NTPServer:/home/pi# lsb_release -a No LSB modules are available. Distributor ID: Raspbian Description:Raspbian GNU/Linux 10 (buster) Release:10 Codename: buster root@NTPServer:/home/pi# --- Here is the entire update transaction: root@NTPServer:/home/pi# apt install pps-tools Reading package lists... Done Building dependency tree Reading state information... Done The following package was automatically installed and is no longer required: rpi-eeprom-images Use 'sudo apt autoremove' to remove it. The following NEW packages will be installed: pps-tools 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 12.2 kB of archives. After this operation, 60.4 kB of additional disk space will be used. Get:1 http://raspbian-us.ngc292.space/raspbian buster/main armhf pps-tools armhf 1.0.2-1 [12.2 kB] Err:1 http://raspbian-us.ngc292.space/raspbian buster/main armhf pps-tools armhf 1.0.2-1 File has unexpected size (32768 != 12164). Mirror sync in progress? [IP: 198.211.116.210 443] E: Failed to fetch https://113store.cr/es/ File has unexpected size (32768 != 12164). Mirror sync in progress? [IP: 198.211.116.210 443] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Bug#962271: libncurses5-dev: Dependency issue
On 2020-06-05 20:35 +0300, Mohammed Alnajdi wrote: > Hey Sven, > Thanks for the fast reply. > >> I fail to see how it does that, could you please elaborate? > https://packages.debian.org/buster/libncurses5-dev has a dependency of > https://packages.debian.org/buster/libncurses-dev which has a dependency of > libncurses6 > so the tree of dependency libncurses5-dev > libncurses-dev > > libncurses6 which i believe is not right in terms of the version i am > wanting to install. > If i want to install the latest ncurses i would go with libncurses-dev but > i picked libncurses5-dev which is version 5 not 6 so why i am getting > ncurses6 ? As the package description tells you, libncurses5-dev is a transitional package, and you are not really expected to install it. There are two reasons why it exists: - Upgrades from stretch, where apt would otherwise have uninstalled libncurses5-dev. It is better to pull in libncurses-dev, so that you don't have to install it manually. - Lots of packages build-depend on libncurses5-dev, and I did not want to file dozens or even hundreds of bugs to change them when a transitional package solves the problem. >> Sorry, not going to happen. In general Debian only provides -dev >> packages for the latest ABI of libraries, and ncurses is no exception, >> especially as its API has not changed. > example python3-dev, python2-dev. Those have actually incompatible APIs and need to coexist. By contrast, any software that worked with libncurses5 should continue to work with libncurses6 after recompiling. Which is what Debian did for hundreds of packages. :-) > If this is expected behavior than sorry. I am new to this i upgraded from > stretch to buster and it took me to think issue. It is expected behavior, although the libncurses5-dev package should probably be removed at some point in the future. Cheers, Sven
Bug#960947: sensors-applet: Please switch from libpanel-applet to libgnome-panel
Thank you for taking care of this! Sam
Bug#962292: Help needed: Bug#962292: ITP: flye -- de novo assembler for single molecule sequencing reads using repeat graphs
Control: tags -1 help Hi, I made some progress with this package and I actually expected it to work but there seems to be some issue with a minimap2 call. So if you clone the repository, build and install the package please follow the docs/USAGE.md document for testing by wget https://zenodo.org/record/1172816/files/E.coli_PacBio_40x.fasta flye --pacbio-raw E.coli_PacBio_40x.fasta --out-dir out_pacbio --genome-size 5m --threads 4 For me it runs a couple of minutes but than it exits with an error which is logged here: tail out_pacbio/flye.log [2020-06-05 18:48:06] INFO: Generating sequence [2020-06-05 18:51:45] DEBUG: Writing FASTA [2020-06-05 18:51:45] DEBUG: Peak RAM usage: 2 Gb ---End assembly log [2020-06-05 18:51:45] root: DEBUG: Disjointigs length: 4888051, N50: 4850514 [2020-06-05 18:51:45] root: INFO: >>>STAGE: consensus [2020-06-05 18:51:45] root: INFO: Running Minimap2 [2020-06-05 18:51:45] root: ERROR: Error running minimap2, terminating. See the alignment error log for details: out_pacbio/10-consensus/minimap.stderr [2020-06-05 18:51:45] root: ERROR: Command '['/bin/bash', '-c', 'set -o pipefail; /usr/bin/minimap2 out_pacbio/10-consensus/chunks.fasta E.coli_PacBio_40x.fasta -x map-pb -t 4 -a -p 0.5 -N 10 --sam-hit-only -L -Q --secondary-seq | /usr/bin/samtools view -T out_pacbio/10-consensus/chunks.fasta -u - | /usr/bin/samtools sort -T out_pacbio/10-consensus/sort_200605_185145 -O bam -@ 4 -l 1 -m 1G']' returned non-zero exit status 1. [2020-06-05 18:51:45] root: ERROR: Pipeline aborted (explicit paths shortened) I tried the very command that is actually run: $ /usr/bin/minimap2 out_pacbio/10-consensus/chunks.fasta E.coli_PacBio_40x.fasta -x map-pb -t 4 -a -p 0.5 -N 10 --sam-hit-only -L -Q --secondary-seq [ERROR] unknown option in "E.coli_PacBio_40x.fasta" Exit code: 1 It seems to me as if the code is creating a broken minimap2 command and I wonder whether anybody could fix this. BTW, it would also help if we could find a shorter sequence example than the given one that could be used for an autopkgtest. For my taste its unnecessarily long. Thanks for any help Andreas. [1] https://salsa.debian.org/med-team/flye On Fri, Jun 05, 2020 at 07:39:20PM +0200, Andreas Tille wrote: > Package: wnpp > Severity: wishlist > > Subject: ITP: flye -- de novo assembler for single molecule sequencing reads > using repeat graphs > Package: wnpp > Owner: Andreas Tille > Severity: wishlist > > * Package name: flye > Version : 2.7.1 > Upstream Author : , The Regents of the University of California > * URL : https://github.com/fenderglass/Flye > * License : BSD-3-Clause > Programming Lang: C > Description : de novo assembler for single molecule sequencing reads > using repeat graphs > Flye is a de novo assembler for single molecule sequencing reads, such > as those produced by PacBio and Oxford Nanopore Technologies. It is > designed for a wide range of datasets, from small bacterial projects to > large mammalian-scale assemblies. The package represents a complete > pipeline: it takes raw PacBio / ONT reads as input and outputs polished > contigs. Flye also has a special mode for metagenome assembly. > > Remark: This package is maintained by Debian Med Packaging Team at >https://salsa.debian.org/med-team/flye > > ___ > 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#962254: NFS(v4) broken at 4.19.118-2
Hi Elliott, Thanks for the additional information. On Fri, Jun 05, 2020 at 10:43:49AM -0700, Elliott Mitchell wrote: > On Fri, Jun 05, 2020 at 08:44:26AM +0200, Salvatore Bonaccorso wrote: > > > > On Thu, Jun 04, 2020 at 10:16:07PM -0700, Elliott Mitchell wrote: > > > Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and > > > linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken. > > > Mounting an appropriate filesystem became unreliable, and once mounted > > > behavior is unpredictable. > > > > > > In particular in the problematic case `umask 022 ; touch foo ; ls -l foo` > > > yields a -rw-rw-rw- file. > > > > > > This occurs if *both* the server *and* client are on 4.19.118+2. I have > > > confirmed this does NOT occur if the server is on a 4.9 kernel. I have > > > also confirmed this does NOT occur if the client is on a 4.9 or > > > 4.19.98+1+deb10u1 kernel. > > > > I cannot reproducde the described behaviour. Can you give more details > > on your setup? > > > > How do you export the filesystem? > > What is the underlying filesystem exported? > > How and whith which options do clients mount the NFS share? > > Presently it is a whole directories being exported to hosts. The > filesystem on the server is ZFS. > > Client is mounting hard,intr. Client is using cachefilesd, but that > appears unrelated to the issue. > > As this is NFSv4 (v2 and v3 are thoroughly disabled on the server), TCP > is being used. The port is non-standard. > > I'm uncertain I properly tried server on 4.9, client on 4.19.118+2 (could > be this is strictly 4.19.118+2 NFSv4 client code). This now let some rings bell, the described scenario is very similar to what was reported in https://bugs.debian.org/934160 Respectively https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and https://bugzilla.redhat.com/show_bug.cgi?id=1667761 . Salvatore
Bug#962281: RFS: sysbench/1.0.20+ds-1 -- multi-threaded benchmark tool for database systems
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sysbench" * Package name: sysbench Version : 1.0.20+ds-1 Upstream Author : Alexey Kopytov * URL : https://github.com/akopytov/sysbench * License : GPL-2+ * Vcs : https://salsa.debian.org/jcfp-guest/sysbench Section : misc It builds those binary packages: sysbench - multi-threaded benchmark tool for database systems To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sysbench Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sysbench/sysbench_1.0.20+ds-1.dsc Changes since the last upload: * New upstream release. * Bump Standards-Version to 4.5.0 (from 4.4.1; no further changes). * Bump compat level to 13 (from 12). * Rules: use execute_before instead of overriding dh_auto_build. * Copyright: bump years for upstream and packaging. * Patches: add 06 to prevent git commit hash from becoming part of the program's version string. * Control: restore support for building on armhf, tests no longer hang on that platform. Thanks! pgpE7L9GvuFrY.pgp Description: OpenPGP digital signature
Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1
On 6/5/20 10:37 AM, Adam D. Barratt wrote:
On Thu, 2020-06-04 at 20:48 -0500, Michael Shuler wrote:
Thanks again, uploaded to mentors:
RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
https://bugs.debian.org/962245
I re-uploaded to mentors the updated 20200601~deb9u1 package artifacts
with the suggested changes committed.
I see there was some additional feedback on the RFS, which is why this
hasn't been uploaded yet.
It makes sense to combine the release via stretch-updates and buster-
updates, so we can release a single SUA and users don't have to stagger
updates. On that basis, I'll hold off on that until we have more idea
what's happening with the stretch update.
Yes, Adrian was super helpful with this style of backporting latest.
With that advice, here is the current package debdiff from latest
version, which gets us where we want:
$ debdiff ca-certificates_20200601_all.deb
ca-certificates_20200601~deb9u1_all.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: openssl (>= [-1.1.1),-] {+1.0.0),+} debconf (>= 0.5) | debconf-2.0
Installed-Size: [-381-] {+380+}
Version: [-20200601-] {+20200601~deb9u1+}
Updated changelog adds the removal of email-only roots from stretch:
ca-certificates (20200601~deb9u1) stretch; urgency=medium
* Rebuild for stretch.
* Merge changes from 20200601
- d/control
* This release updates the Mozilla CA bundle to 2.40, blacklists
distrusted Symantec roots, and blacklists expired "AddTrust External
Root". Closes: #956411, #955038, #911289, #961907
* Fix permissions on /usr/local/share/ca-certificates when using
symlinks.
Closes: #916833
* Remove email-only roots from mozilla trust store. Closes: #721976
Attached is the updated debdiff.gz from oldstable->this_backport and
those stats:
diffstat for ca-certificates-20161130+nmu1+deb9u1
ca-certificates-20200601~deb9u1
.gitignore | 12
debian/NEWS | 393 ---
debian/ca-certificates.postinst |8
debian/changelog| 231 +
debian/copyright| 14
mozilla/blacklist.txt | 54
mozilla/certdata.txt| 4927
mozilla/certdata2pem.py |2
mozilla/nssckbi.h |6
9 files changed, 2734 insertions(+), 2913 deletions(-)
Kind regards,
Michael Shuler
ca-certificates_20200601~deb9u1.debdiff.gz
Description: application/gzip
Bug#962254: NFS(v4) broken at 4.19.118-2
On Fri, Jun 05, 2020 at 08:44:26AM +0200, Salvatore Bonaccorso wrote: > > On Thu, Jun 04, 2020 at 10:16:07PM -0700, Elliott Mitchell wrote: > > Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and > > linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken. > > Mounting an appropriate filesystem became unreliable, and once mounted > > behavior is unpredictable. > > > > In particular in the problematic case `umask 022 ; touch foo ; ls -l foo` > > yields a -rw-rw-rw- file. > > > > This occurs if *both* the server *and* client are on 4.19.118+2. I have > > confirmed this does NOT occur if the server is on a 4.9 kernel. I have > > also confirmed this does NOT occur if the client is on a 4.9 or > > 4.19.98+1+deb10u1 kernel. > > I cannot reproducde the described behaviour. Can you give more details > on your setup? > > How do you export the filesystem? > What is the underlying filesystem exported? > How and whith which options do clients mount the NFS share? Presently it is a whole directories being exported to hosts. The filesystem on the server is ZFS. Client is mounting hard,intr. Client is using cachefilesd, but that appears unrelated to the issue. As this is NFSv4 (v2 and v3 are thoroughly disabled on the server), TCP is being used. The port is non-standard. I'm uncertain I properly tried server on 4.9, client on 4.19.118+2 (could be this is strictly 4.19.118+2 NFSv4 client code). -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#962294: RFS: btrfs-progs/5.6-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "btrfs-progs" * Package name: btrfs-progs Version : 5.6-1~bpo10+1 Upstream Author : linux-bt...@vger.kernel.org * URL : http://btrfs.wiki.kernel.org/ * License : GPL-2 * Vcs : https://salsa.debian.org/debian/btrfs-progs/tree/debian Section : admin It builds these binary packages: btrfs-progs - Checksumming Copy on Write Filesystem utilities libbtrfs0 - Checksumming Copy on Write Filesystem utilities (runtime library) libbtrfs-dev - Checksumming Copy on Write Filesystem utilities (development headers) libbtrfsutil1 - Checksumming Copy on Write Filesystem utilities (runtime util library) libbtrfsutil-dev - Checksumming Copy on Write Filesystem utilities (util development headers) python3-btrfsutil - Checksumming Copy on Write Filesystem utilities (python3 bindings) btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_5.6-1~bpo10+1.dsc Changes since the last upload: * Rebuild for buster-backports. . btrfs-progs (5.6-1) unstable; urgency=medium . * New upstream release. * Versioned symbols. * Slightly improve long descs. * Drop old -dbgsym migration. * Don't skip scan if modprobe fails (eg. due to built-in). Closes: #956174. . btrfs-progs (5.4.1-2) unstable; urgency=medium . * Declare Breaks: on versions of libgcc-s1 that produce bad initramfs. Closes: #950556. . btrfs-progs (5.4.1-1) unstable; urgency=medium . * New upstream release. . btrfs-progs (5.4-1) unstable; urgency=medium . * New upstream release. . btrfs-progs (5.3.1-1) unstable; urgency=medium . * New upstream point release. * Update symbols -- they're versioned upstream now. . btrfs-progs (5.3-1) unstable; urgency=medium . * New upstream release. * Fix FTBFS with new asciidoctor. * Update symbols. Regards, Nicholas
Bug#962293: RFP: virt-v2v -- Convert a guest from a foreign hypervisor to run on KVM
Package: wnpp Severity: wishlist * Package name: virt-v2v Version : 1.42.0 Upstream Author : Richard W.M. Jones, Red Hat Inc. * URL : http://libguestfs.org/ * License : GPL-2+ Programming Lang: OCaml Description : Convert a guest from a foreign hypervisor to run on KVM Virt-v2v converts a single guest from a foreign hypervisor to run on KVM. It can read Linux and Windows guests running on VMware, Xen, Hyper-V and some other hypervisors, and convert them to KVM managed by libvirt, OpenStack, oVirt, Red Hat Virtualisation (RHV) or several other targets. It can modify the guest to make it bootable on KVM and install virtio drivers so it will run quickly. It was developed as part of libguestfs from 1.28 up to 1.41.7, and has since been split into its own repository.[1][2][3] It was shipped in buster and it would be great to see it return to sid. I whipped up a package for my own use.[4] It is functional, but I'm still following up on a few issues with upstream. Deficiencies I'm aware of are noted in debian/TODO.md. Let me know if there's anything else I can do to help. Thanks, Kevin [1]: https://www.redhat.com/archives/libguestfs/2019-July/msg00102.html [2]: https://www.redhat.com/archives/libguestfs/2019-October/msg00085.html [3]: https://www.redhat.com/archives/libguestfs/2020-March/msg00053.html [4]: https://salsa.debian.org/kevinoid/virt-v2v
Bug#962262: Acknowledgement (opendmarc fails many emails without apparent reason)
Dear Maintainer I think I got it. Maybe updating the manpage would be very helpfull for other people who stumble over the same problem. DMARC needs to do an SPF check. Well I have milter-greylist already performing SPF check, so I configured what I tought would make opendmarc ignore the SPF check and assuming an email that went that far already passed SPF check (which is true in my case). Now I understand, opendmarc need to do SPF check itself. Only this way the result ever returns 'pass'. SPFSelfValidate true Problem solved. I wonder if I could make milter-greylist to create a header which would satisfy opendmarc but I could not find any documentation of the Authentication-Result: header. -Benoît-
Bug#962265: patch for sword ICU 67.1 detection
Control: tags -1 +patch Hi, It seems your upstream is inactive. It was me who patched sword for ICU 63.1 and here is the patch for the ICU 67.1 version. Please apply this soon. Thanks, Laszlo/GCS Description: fix ICU checking Let still search for icu-config but use pkg-config method after that. Forwarded: no Author: Laszlo Boszormenyi (GCS) Last-Update: 2020-06-05 --- --- sword-1.8.1+dfsg.orig/configure.ac +++ sword-1.8.1+dfsg/configure.ac @@ -238,9 +238,19 @@ if test x$with_icu = xyes; then AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_" AM_CFLAGS="$AM_CFLAGS -D_ICU_" else - echo "*** The icu-config script installed by icu could not be found" - echo "*** compiling without ICU support" - with_icu=no + PKG_CHECK_MODULES([ICU], [icu-i18n >= 63.1], [found_icu=yes]) + if test "$found_icu" = "yes"; then + PKG_CHECK_MODULES([ICU_IO], [icu-io >= 63.1]) + ICU_IOLIBS="$ICU_IO_LIBS" + with_icu=yes + LIBS="$LIBS $ICU_LIBS $ICU_IOLIBS" + AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_" + AM_CFLAGS="$AM_CFLAGS -D_ICU_" + else + echo "*** The icu-config script installed by icu could not be found" + echo "*** compiling without ICU support" + with_icu=no + fi fi fi
Bug#962292: ITP: flye -- de novo assembler for single molecule sequencing reads using repeat graphs
Package: wnpp Severity: wishlist Subject: ITP: flye -- de novo assembler for single molecule sequencing reads using repeat graphs Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: flye Version : 2.7.1 Upstream Author : , The Regents of the University of California * URL : https://github.com/fenderglass/Flye * License : BSD-3-Clause Programming Lang: C Description : de novo assembler for single molecule sequencing reads using repeat graphs Flye is a de novo assembler for single molecule sequencing reads, such as those produced by PacBio and Oxford Nanopore Technologies. It is designed for a wide range of datasets, from small bacterial projects to large mammalian-scale assemblies. The package represents a complete pipeline: it takes raw PacBio / ONT reads as input and outputs polished contigs. Flye also has a special mode for metagenome assembly. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/flye
Bug#962271: libncurses5-dev: Dependency issue
Hey Sven, Thanks for the fast reply. > I fail to see how it does that, could you please elaborate? https://packages.debian.org/buster/libncurses5-dev has a dependency of https://packages.debian.org/buster/libncurses-dev which has a dependency of libncurses6 so the tree of dependency libncurses5-dev > libncurses-dev > libncurses6 which i believe is not right in terms of the version i am wanting to install. If i want to install the latest ncurses i would go with libncurses-dev but i picked libncurses5-dev which is version 5 not 6 so why i am getting ncurses6 ? > Sorry, not going to happen. In general Debian only provides -dev > packages for the latest ABI of libraries, and ncurses is no exception, > especially as its API has not changed. example python3-dev, python2-dev. If this is expected behavior than sorry. I am new to this i upgraded from stretch to buster and it took me to think issue. On Fri, Jun 5, 2020 at 6:20 PM Sven Joachim wrote: > Control: severity -1 normal > Control: tags -1 moreinfo wontfix > > On 2020-06-05 14:35 +0300, Mohammed Alnajdi wrote: > > > Package: libncurses5-dev > > Version: 6.1+20181013-2+deb10u2 > > Severity: serious > > Justification: Installing libncurses5-dev installs libncurses6 from > > libncurses-dev and not > > > > Hello, I noticed that if i install libncurses5-dev i get libncurses6 > which > > breaks software which still relay on libncurse5. > > I fail to see how it does that, could you please elaborate? > > > I believe installing > > libncurses5-dev should bring everything that is libncurses5 not > > libncurses6. > > Sorry, not going to happen. In general Debian only provides -dev > packages for the latest ABI of libraries, and ncurses is no exception, > especially as its API has not changed. > > If for some reason you need to compile software against the old ABI, use > a chroot for that, e.g. with Debian 9 in it. Or build ncurses yourself. > > Cheers, >Sven >
Bug#962291: 9base: please include ssam executable
Package: 9base Version: 1:6-7+b1 Severity: wishlist Dear Maintainer, It would be great to include the `ssam` executable in the 9base package, as that is an excellent way to execute structured regular expressions on a linux system. The script is present upstream: https://git.suckless.org/9base/file/ssam/ssam.html Thanks, Karl -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages 9base depends on: ii libc6 2.28-10 9base recommends no packages. Versions of packages 9base suggests: pn wmii2 -- no debconf information
Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong
I discovered what the problem is. The test [ $res ] do not work the way you want it to. It need to compare with 0, like this: diff --git a/debian/tests/test01 b/debian/tests/test01 index 1c0d63f..73e1fac 100755 --- a/debian/tests/test01 +++ b/debian/tests/test01 @@ -1,4 +1,5 @@ #!/bin/sh + cd debian/tests echo "info: compiling" @@ -7,7 +8,7 @@ echo "info: compiling" echo "info: running" cmp -s test01.exp $AUTOPKGTEST_TMP/test01.act res=$? -if [ $res ] ; then +if [ 0 = $res ] ; then echo "success: test01 produced proper results" else echo "error: test01 did not produce proper results" diff --git a/debian/tests/test02 b/debian/tests/test02 index fb85d2e..cb4359d 100755 --- a/debian/tests/test02 +++ b/debian/tests/test02 @@ -7,7 +7,7 @@ echo "info: compiling" echo "info: running" cmp -s test02.exp $AUTOPKGTEST_TMP/test02.act res=$? -if [ $res ] ; then +if [ 0 == $res ] ; then echo "success: test02 produced proper results" else echo "error: test02 did not produce proper results" diff --git a/debian/tests/test03 b/debian/tests/test03 index c028d8b..07d679c 100755 --- a/debian/tests/test03 +++ b/debian/tests/test03 @@ -7,7 +7,7 @@ echo "info: compiling" echo "info: running" cmp -s test03.exp $AUTOPKGTEST_TMP/test03.act res=$? -if [ $res ] ; then +if [ 0 == $res ] ; then echo "success: test03 produced proper results" else echo "error: test03 did not produce proper results" diff --git a/debian/tests/test04 b/debian/tests/test04 index fd2a6ad..ee31d4a 100755 --- a/debian/tests/test04 +++ b/debian/tests/test04 @@ -7,7 +7,7 @@ echo "info: compiling" echo "info: running" cmp -s test04.exp t$AUTOPKGTEST_TMP/est04.act res=$? -if [ $res ] ; then +if [ 0 == $res ] ; then echo "success: test04 produced proper results" else echo "error: test04 did not produce proper results" -- Happy hacking Petter Reinholdtsen
Bug#962152: ca-certificates 20200601~deb10u1 flagged for acceptance
package release.debian.org tags 962152 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: ca-certificates Version: 20200601~deb10u1 Explanation: update Mozilla CA bundle to 2.40, blacklist distrusted Symantec roots and expired "AddTrust External Root"
Bug#962290: smuxi-frontend-gnome: freezes when I click on the channel with a recent notification
Package: smuxi-frontend-gnome Version: 1.0.7-5 Severity: important When I get a notification while I'm not im my smuxi window, if I immediately click on the highlighted channel, then the application freezes and I have no other choice than to kill it. If I first click in a non-highlighted channel, and then click on the highlighted channel, then everything works as usual. This is very annoying... -- System Information: Debian Release: bullseye/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages smuxi-frontend-gnome depends on: ii libdbus-glib2.0-cil 0.6.0-1 ii libdbus2.0-cil 0.8.1-2 ii libglade2.0-cil 2.12.40-3 ii libglib2.0-02.64.3-1 ii libglib2.0-cil 2.12.40-3 ii libgtk2.0-0 2.24.32-4 ii libgtk2.0-cil 2.12.40-3 ii libgtkspell02.0.16-1.3 ii liblog4net1.2-cil 1.2.10+dfsg-7 ii libmessagingmenu12.10-cil 1.0.1-1 ii libmono-corlib4.5-cil 6.8.0.105+dfsg-3 ii libmono-posix4.0-cil6.8.0.105+dfsg-3 ii libmono-system-core4.0-cil 6.8.0.105+dfsg-3 ii libmono-system-web4.0-cil 6.8.0.105+dfsg-3 ii libmono-system4.0-cil 6.8.0.105+dfsg-3 ii libnotify0.4-cil0.4.0~r3032-7 ii librsvg2-common 2.48.4+dfsg-1 ii mono-runtime6.8.0.105+dfsg-3 ii smuxi-engine1.0.7-5 Versions of packages smuxi-frontend-gnome recommends: ii gnome-shell [notification-daemon] 3.36.2-1 ii notification-daemon3.20.0-4 ii ssh-askpass-gnome [ssh-askpass]1:8.2p1-4 smuxi-frontend-gnome suggests no packages. -- no debconf information
Bug#962289: gnutls28: CVE-2020-13777: session resumption works without master key allowing MITM
Source: gnutls28 Version: 3.6.13-4 Severity: grave Tags: security upstream Forwarded: https://gitlab.com/gnutls/gnutls/-/issues/1011 Control: found -1 3.6.4-1 Control: found -1 3.6.7-4+deb10u3 Hi Andreas, The following vulnerability was published for gnutsl28, filling it as RC given the resulting in authentication bypass possibility, but if you do not agree please downgrade. CVE-2020-13777[0]: | GnuTLS 3.6.x before 3.6.14 uses incorrect cryptography for encrypting | a session ticket (a loss of confidentiality in TLS 1.2, and an | authentication bypass in TLS 1.3). The earliest affected version is | 3.6.4 (2018-09-24) because of an error in a 2018-09-18 commit. Until | the first key rotation, the TLS server always uses wrong data in place | of an encryption key derived from an application. If you want I can try to help preparing as well a corresponding buster-security update. The issue was introduced in 3.6.4 upstream, so stretch is not affected. 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-2020-13777 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13777 [1] https://gnutls.org/security-new.html#GNUTLS-SA-2020-06-03 [2] https://gitlab.com/gnutls/gnutls/-/issues/1011 Regards, Salvatore
Bug#961913: kmail: the access and reading of the received messages is often very slow
forwarded 961913 https://bugs.kde.org/422336 thanks Forwarded to: Bug 422336 - kmail: the access and reading of the received messages is often very slow https://bugs.kde.org/422336 Also relates to: Bug 367892 - During folder synchronisation Akonadi blocks out other operations like deleting or viewing mails https://bugs.kde.org/367892 Thanks, -- Martin
Bug#962037: [Pkg-javascript-devel] Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Bug#962037: Plan B for not being able to replicate upstream exports exactly
On Fri, Jun 5, 2020 at 5:11 pm, Pirate Praveen wrote: On Fri, Jun 5, 2020 at 3:10 pm, Pirate Praveen wrote: This is likely broken by node-merge-stream update from 1.0 to 2.0. node-merge-stream is a build dependeny of node-autolinker. Tried building with autolinker 3.x in embed-autolinker-3 branch, but the same failure. I tried to run the upstream test suite for node-autolinker (yarnpkg install, yarnpkg test), but it seems gulp 3 is segfaulting in debian, tried with node 10 and 12 via npm with the same results. I had seen the same failure when trying to run gulp in node-puka as well. All unit tests passed on autolinker master which has gulp 4 with merge-stream 2.0, so it is not merge-stream change that broke.
Bug#962288: ros-actionlib build depends on libboost-signals-dev that is removed in boost1.71
Source: ros-actionlib Version: 1.12.0-4 Severity: serious Tags: ftbfs Control: block 961995 by -1 https://buildd.debian.org/status/package.php?p=ros-actionlib libboost-signals-dev is removed in boost1.71.
Bug#962287: ros-image-common FTBFS with boost 1.71
Source: ros-image-common Version: 1.11.13-7 Severity: serious Tags: ftbfs Control: block 961995 by -1 https://buildd.debian.org/status/package.php?p=ros-image-common ... -- Found Python: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found version "3.8") found components: Development CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:117 (find_package): Could not find a package configuration file provided by "boost_python3.8" (requested version 1.71.0) with any of the following names: boost_python3.8Config.cmake boost_python3.8-config.cmake Add the installation prefix of "boost_python3.8" to CMAKE_PREFIX_PATH or set "boost_python3.8_DIR" to a directory containing one of the above files. If "boost_python3.8" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:182 (boost_find_component) /usr/share/cmake-3.16/Modules/FindBoost.cmake:443 (find_package) camera_calibration_parsers/CMakeLists.txt:7 (find_package) -- Configuring incomplete, errors occurred! The Ubuntu diff (linked from tracker.debian.org) seems to contain a fix (untested).
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Quoting Ondřej Surý (2020-06-05 17:13:00) > On 5 Jun 2020, at 17:06, Jonas Smedegaard wrote: > > Sorry, I was too fast - indeed we don't do the above (we do not > > probe for and tie to a specific package version) - but I am > > confused: why is it not reliable to use the provided ABI? > > The uwsgi-plugin-php is a sort of special case, as the phpapi- > can be resolved with any SAPI (CLI, CGI, apache2, FCGI) and you need > to depend on a specific SAPI. > > Or just wait for php-default 76 to migrate as that solves the problem > with allowing multiple PHP versions to be installed, so if you depend > on libphp-embed, it will pull php-common and that version has: > > Breaks: […] > php5.6-common, > php5.6-common (<< 5.6.18+dfsg-10~), > php5.6-json (<< 1.3.9-2~), > php7.0-common, > php7.0-common (<< 7.0.3-11~), > php7.1-common, > php7.2-common, > php7.3-common > > So, it ensures that only PHP 7.4 can be installed. Thanks for clarifying (I vaguely recall having this kind of conversation before, but maybe not with you specifically). - 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#962286: ros-dynamic-reconfigure build depends on libboost-signals-dev that is removed in boost1.71
Source: ros-dynamic-reconfigure Version: 1.6.0-3 Severity: serious Tags: ftbfs Control: block 961995 by -1 https://buildd.debian.org/status/package.php?p=ros-dynamic-reconfigure libboost-signals-dev is removed in boost1.71.
Bug#962155: stretch-pu: package ca-certificates/20200601~deb9u1
On Thu, 2020-06-04 at 20:48 -0500, Michael Shuler wrote: > Thanks again, uploaded to mentors: > > RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates > https://bugs.debian.org/962245 I see there was some additional feedback on the RFS, which is why this hasn't been uploaded yet. It makes sense to combine the release via stretch-updates and buster- updates, so we can release a single SUA and users don't have to stagger updates. On that basis, I'll hold off on that until we have more idea what's happening with the stretch update. Regards, Adam
Bug#960321: burp: flaky arm64 autopkgtest: .../src/test/clientscript failed
I advised the upstream maintainer[1] and temporary placed the flag "flaky" for the "burp-builtin-test" test[2]. Thank you so much. References: [1]: https://github.com/grke/burp/issues/866 [2]: https://salsa.debian.org/debian/burp/-/commit/513e4c37a59f5cea98bc7723188c2ed0cb70f776 signature.asc Description: OpenPGP digital signature
Bug#962245: RFS: ca-certificates/20200601~deb9u1 [RC] -- Common CA certificates
On Fri, Jun 05, 2020 at 08:06:28AM -0500, Michael Shuler wrote: > On 6/5/20 4:15 AM, Adrian Bunk wrote: > > Compared to 20200601 and 20200601~deb10u1 this contains the following > > additional files: > > > > /usr/share/ca-certificates/mozilla/AddTrust_Low-Value_Services_Root.crt > > /usr/share/ca-certificates/mozilla/Camerfirma_Chambers_of_Commerce_Root.crt > > /usr/share/ca-certificates/mozilla/Camerfirma_Global_Chambersign_Root.crt > > /usr/share/ca-certificates/mozilla/Certum_Root_CA.crt > > /usr/share/ca-certificates/mozilla/D-TRUST_Root_CA_3_2013.crt > > /usr/share/ca-certificates/mozilla/SwissSign_Platinum_CA_-_G2.crt > > /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.crt > > /usr/share/ca-certificates/mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.crt > > /usr/share/doc/ca-certificates/NEWS.Debian.gz > > > > The additional NEWS.Debian.gz is either correct or harmless, > > the additional certificates are not. > > > > This is due to the backport missing the "Remove email-only roots from > > mozilla trust store" (#721976) change that is in 20200601. > > Great catch, thanks, result of using currentver~debXuY as discussed with > some people for better update recognition, while backporting as little as > possible. Except for keeping debian/NEWS you were actually backporting everything that was possible, this was not a 20161130+nmu1+deb9u2 release that cherry-picked only one or few changes. Given the nature of ca-certificates it was IMHO the correct decision to backport as much as possible, it is just not "backporting as little as possible". Since similar updates to stable releases might happen in the future, I would recommend that you try to get build and runtime dependencies in unstable to a level that allows rebuilding the package in all supported Debian releases. For compatibility with buster this would include staying at dh compat <= 12. "Backporting everything possible" changes are often safest when the only change in the ~deb10u1 source package is the entry in debian/changelog. >... > > Please update the stretch-pu request with that fixed and let me know > > when the corrected debdiff is approved. > > Will do, thank you for the feedback. Thanks for your work on ca-certificates. > Kind regards, > Michael cu Adrian
Bug#962271: libncurses5-dev: Dependency issue
Control: severity -1 normal Control: tags -1 moreinfo wontfix On 2020-06-05 14:35 +0300, Mohammed Alnajdi wrote: > Package: libncurses5-dev > Version: 6.1+20181013-2+deb10u2 > Severity: serious > Justification: Installing libncurses5-dev installs libncurses6 from > libncurses-dev and not > > Hello, I noticed that if i install libncurses5-dev i get libncurses6 which > breaks software which still relay on libncurse5. I fail to see how it does that, could you please elaborate? > I believe installing > libncurses5-dev should bring everything that is libncurses5 not > libncurses6. Sorry, not going to happen. In general Debian only provides -dev packages for the latest ABI of libraries, and ncurses is no exception, especially as its API has not changed. If for some reason you need to compile software against the old ABI, use a chroot for that, e.g. with Debian 9 in it. Or build ncurses yourself. Cheers, Sven
Bug#962285: screengrab: Hangs when copy button is pressed - proably sync with dbus
Package: screengrab Version: 1.101-1 Severity: normal Dear Maintainer, Currently when I take a screenshot, and then press "Copy" button. Screegrab UI freezes for around minute. I downloaded source package and recompiled it with debugging symbols. And it seems that it hangs on dbus communication for some reason (gdb output attached). Probably there is currently some problem with mine dbus-server, but should this be done asynchronously. Notification shouldn't break normal work of screengrab? -- System Information: Debian Release: 10.4 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages screengrab depends on: ii libc62.28-10 ii libgcc1 1:8.3.0-6 ii libkf5windowsystem5 5.54.0-1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u1 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u1 ii libqt5gui5 5.11.3+dfsg1-1+deb10u1 ii libqt5network5 5.11.3+dfsg1-1+deb10u1 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u1 ii libqt5x11extras5 5.11.3-2 ii libqt5xdg3 3.3.1-2 ii libstdc++6 8.3.0-6 ii libx11-xcb1 2:1.6.4-3 ii libxcb-xfixes0 1.13.1-2 screengrab recommends no packages. screengrab suggests no packages. -- no debconf information Thread 1 "screengrab" received signal SIGINT, Interrupt. 0x7502e00c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) bt #0 0x7502e00c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x75bfc23b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x76d3924a in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #3 0x76ceb4f1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #4 0x76cebbed in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #5 0x76cf6f3d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #6 0x76cf70a5 in QDBusInterface::QDBusInterface(QString const&, QString const&, QString const&, QDBusConnection const&, QObject*) () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #7 0x555ba608 in DBusNotifier::DBusNotifier (this=0x55a38e30, parent=0x0) at /home/emil/programy/screengrab-1.101/src/core/dbusnotifier.cpp:40 #8 0x5558dbb5 in Core::sendNotify (this=0x55635cd0, message=...) at /home/emil/programy/screengrab-1.101/src/core/core.cpp:462 #9 0x5558dc97 in Core::copyScreen (this=0x55635cd0) at /home/emil/programy/screengrab-1.101/src/core/core.cpp:473 #10 0x555ba29c in QtPrivate::FunctorCall, QtPrivate::List<>, void, void (Core::*)()>::call(void (Core::*)(), Core*, void**) (f=(void (Core::*)(Core * const)) 0x5558dbee , o=0x55635cd0, arg=0x7fffd5a0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:134 #11 0x555ba0be in QtPrivate::FunctionPointer::call, void>(void (Core::*)(), Core*, void**) (f=(void (Core::*)(Core * const)) 0x5558dbee , o=0x55635cd0, arg=0x7fffd5a0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:167 #12 0x555b9a97 in QtPrivate::QSlotObject, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x55a392f0, r=0x55635cd0, a=0x7fffd5a0, ret=0x0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:396 #13 0x75dcc9a3 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x76717f02 in QAction::triggered(bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #15 0x7671a520 in QAction::activate(QAction::ActionEvent) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #16 0x76805b0d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x76805d45 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x768ef8aa in QToolButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #19 0x7675c4d8 in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #20 0x768ef953 in QToolButton::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #21 0x7671e4c1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #22 0x76725bb8 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #23 0x75da34f9 in QCore
Bug#962284: mailman: File "/usr/lib/mailman/cron/cull_bad_shunt", line 77 SyntaxError with Python 3
Package: mailman Version: 1:2.1.29-1+deb10u1 Severity: normal Got the following this morning, after switching to Python 3: From: r...@pfeifferfamily.net (Cron Daemon) To: l...@pfeifferfamily.net Subject: Cron [ -x /usr/lib/mailman/cron/cull_bad_shunt ] && /usr/lib/mailman/cron/cull_bad_shunt Date: Fri, 05 Jun 2020 04:30:01 -0600 Content-Type: text/plain; charset=UTF-8 X-Bogosity: Ham, tests=bogofilter, spamicity=0.28, version=1.2.4 File "/usr/lib/mailman/cron/cull_bad_shunt", line 77 except getopt.error, msg: ^ SyntaxError: invalid syntax The issue appears to be that Python3 no longer accepts the comma in an except block. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (550, 'experimental'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mailman depends on: ii apache2 [httpd]2.4.43-1 ii cron [cron-daemon] 3.0pl1-136 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.30-4 ii logrotate 3.16.0-3 ii lsb-base 11.1.0 ii python 2.7.17-2 ii python-dnspython 1.16.0-1 ii ucf3.0038+nmu1 Versions of packages mailman recommends: ii exim4-daemon-light [mail-transport-agent] 4.93-15 Versions of packages mailman suggests: pn listadmin ii lynx 2.9.0dev.5-1 pn mailman3-full pn spamassassin -- debconf information excluded
Bug#962274: libcamera-dev: cannot compile a trivial program against libcamera
Control: retitle -1 libcamera-dev: cannot compile a trivial program against
libcamera
On Fri, 05 Jun 2020 at 14:01:47 +0100, Simon McVittie wrote:
> ../spa/plugins/libcamera/libcamera_wrapper.cpp:46:10: fatal error:
> libcamera/camera.h: No such file or directory
>46 | #include
> | ^~~~
Actually it seems the preferred header might be the
meta-header.
> A simple compile/link/execute autopkgtest is an excellent way to detect
> this class of problem before it affects dependent packages. The one I
> contributed to libsndfile-dev in 1.0.28-8 is a recent example. If there
> isn't a minimal standalone test in the libcamera source package, just
> writing a main() that instantiates some simple object like PixelFormat
> should work.
I tried to do the equivalent of this, and in addition to the missing
-I/usr/include/libcamera, there seems to be a missing dependency on
something (I don't know what) that provides :
$ cat t.cpp
#include
int main (void)
{
libcamera::logSetStream(std::cerr);
return 0;
}
$ g++ t.cpp `pkg-config --cflags --libs camera`
t.cpp:1:10: fatal error: libcamera/libcamera.h: No such file or directory
1 | #include
| ^~~
compilation terminated.
$ g++ t.cpp `pkg-config --cflags --libs camera` -I/usr/include/libcamera
In file included from /usr/include/libcamera/libcamera/stream.h:17,
from /usr/include/libcamera/libcamera/camera.h:18,
from /usr/include/libcamera/libcamera/libcamera.h:13,
from t.cpp:1:
/usr/include/libcamera/libcamera/pixelformats.h:14:10: fatal error:
linux/drm_fourcc.h: No such file or directory
14 | #include
| ^~~~
compilation terminated.
$ dpkg -S linux/drm_fourcc.h
dpkg-query: no path found matching pattern *linux/drm_fourcc.h*
$ apt-file search linux/drm_fourcc.h
(no output)
Is this package usable as-is? Presumably it was tested in some way
before upload, but I'm not sure how it would have worked. If it isn't
usable, then this bug should probably be grave.
(It's possible that this is fixed in the latest source version in unstable,
but that version FTBFS due to #960758, so an updated libcamera-dev binary
package isn't currently available.)
smcv
Bug#962283: boinc: 7.16.15 was erroneously tagged as a release
Package: boinc Version: 7.16.15+dfsg-1 Severity: important Bug report to self - to prevent transition to testing Version 7.16.15 was erroneously tagged by upstream. It is not an official release. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages boinc depends on: ii boinc-client 7.16.15+dfsg-1 ii boinc-manager 7.16.15+dfsg-1 boinc recommends no packages. boinc suggests no packages. -- no debconf information
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
> On 5 Jun 2020, at 17:06, Jonas Smedegaard wrote: > > Sorry, I was too fast - indeed we don't do the above (we do not probe > for and tie to a specific package version) - but I am confused: why is > it not reliable to use the provided ABI? The uwsgi-plugin-php is a sort of special case, as the phpapi- can be resolved with any SAPI (CLI, CGI, apache2, FCGI) and you need to depend on a specific SAPI. Or just wait for php-default 76 to migrate as that solves the problem with allowing multiple PHP versions to be installed, so if you depend on libphp-embed, it will pull php-common and that version has: Breaks: […] php5.6-common, php5.6-common (<< 5.6.18+dfsg-10~), php5.6-json (<< 1.3.9-2~), php7.0-common, php7.0-common (<< 7.0.3-11~), php7.1-common, php7.2-common, php7.3-common So, it ensures that only PHP 7.4 can be installed. Ondrej -- Ondřej Surý ond...@sury.org signature.asc Description: Message signed with OpenPGP
Bug#962186: [pkg-uWSGI-devel] Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
[ sent again, 2 mails merged with 7bit headers to please Debian MTAs ]
Hi Ondřej,
Quoting Ondřej Surý (2020-06-05 16:20:21)
> Hi Alex,
>
> you can depend on libphp-embed and then prepare the substvars like this:
>
> echo "libphp-embed:Depends=libphp$(phpquery -V | head -1)-embed“ >
> debian/uwsgi-plugin-php.substvars
>
> and then in debian/control you would use
>
> Depends: ${libphp-embed:Depends}
>
> instead of
>
> Depends: libphp-embed
We (Alex and I) believe that we do similar to the above: Binary package
uwsgi-plugin-php currently in unstable depends on virtual package
phpapi-20190902 which (if I understand correctly) is equivalent of using
above method.
Why is it not reliable to use the provided ABI?
Can we ask you to please look at the package uwsgi-plugin-php and tell
what we do wrong (or tell us if you agree that what we do already is
indeed supposed to be adequate)
Kind regards,
- 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#962282: pupnp-1.8: CVE-2020-13848
Source: pupnp-1.8 Version: 1:1.8.4-2 Severity: important Tags: security upstream Forwarded: https://github.com/pupnp/pupnp/issues/177 Hi, The following vulnerability was published for pupnp-1.8. CVE-2020-13848[0]: | Portable UPnP SDK (aka libupnp) 1.12.1 and earlier allows remote | attackers to cause a denial of service (crash) via a crafted SSDP | message due to a NULL pointer dereference in the functions | FindServiceControlURLPath and FindServiceEventURLPath in | genlib/service_table/service_table.c. 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-2020-13848 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13848 [1] https://github.com/pupnp/pupnp/issues/177 [2] https://github.com/pupnp/pupnp/commit/c805c1de1141cb22f74c0d94dd5664bda37398e0 Regards, Salvatore
Bug#962262: Acknowledgement (opendmarc fails many emails without apparent reason)
Additional Infos: History file entry of such an failing email: job 055AOEWZ026900 reporter magma.woody.ch received 1591352655 ipaddr 2a00:1450:4864:20::52c from gmail.com mfrom gmail.com spf -1 pdomain gmail.com policy 18 rua mailto:mailauth-repo...@google.com pct 100 adkim 114 aspf 114 p 110 sp 113 align_dkim 5 align_spf 5 action 2
Bug#941937: apt: Unexpected linkage dependency on libsystemd
(I guess the last email was the disagree email, and this one is the positive one, idk, I just missed those two points) On Fri, Jun 05, 2020 at 04:15:07PM +0200, Adam Borowski wrote: > On Fri, Jun 05, 2020 at 10:34:47AM +0200, Julian Andres Klode wrote: > > On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > Why even a warning? All the inhibit thing does is to prevent the admin from > doing something stupid (rebooting during an upgrade), and even that has > non-fatal results. Debian had no inhibit at all for decades and the sky > wasn't falling -- so it's a purely facultative option. If the system has > been booted using systemd and systemd is in an usable state (no changing > archs, etc) then inhibit will work -- otherwise, that particular handhold > won't be there. I agree. The thing is, we silently ignore failures to inhibit. This means it works fine on non-systemd systems - as it always did. Adding a warning on systems where it should work (stat(/run/systemd/system) == 0) would make it easy to discover regressions, but it's ultimately not super useful, as people won't read it anyway, especially if it's a background process doing this. > > > This is a best effort thing, there's nothing sensible we can do if it > > fails, except for logging a warning, and that does not help a lot. We > > don't want to issue an error obviously because you still want to be able > > to upgrade the system if your dbus is down or stuff. > > Just silently ignore a failure to inhibit. That's what we do right now. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR
thanks Boyuan noted. I am changing Architecture:all and uploaded. with regards. On Fri, Jun 5, 2020 at 8:25 PM Boyuan Yang wrote: > On Fri, 5 Jun 2020 09:35:07 +0630 "Ko Ko Ye`" > wrote: > > -- Forwarded message - > > From: Ko Ko Ye` > > Date: Fri, Jun 5, 2020 at 9:32 AM > > Subject: Re: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect > > > > Have you seen that bartm bot closed your RFS report again? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961899;msg=19 > > It is due to that you removed your package from mentors.debian.net ( > https://mentors.debian.net/package/wifi-qr) and re-add it. When it gets > removed, the bot will detect it and close the bug report automatically. > You are expected to reopen the wrongly-closed bug report. > > Please *DO* *NOT* unnecessarily remove and readd your package on > mentors.debian.net. You can always make a re-upload onto > mentors.debian.net with the same package name and same version name. > The mentors.debian.net site supports such behavior. > (This does not apply to Debian's official archive, though.) > > -- > Regards, > Boyuan Yang > -- with regards *Ko Ko Ye`* +95 97989 22022 +95 94500 22022 +95 9731 47907 kokoye2...@gmail.com kokoye2...@ubuntu.com skype: kokoye2007 jitsi: kokoye2007 http://ubuntu-mm.net http://wiki.ubuntu.com/kokoye2007 http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
Bug#927329: Update Arduino from 1.8.2 to 1.8.9
Hello, I just got caught by the too old version of arduino in sid. Your last message seemed quite positive... Did you make any progress in packaging a new version? Thanks, -- Félix signature.asc Description: PGP signature
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Fri, Jun 05, 2020 at 04:15:07PM +0200, Adam Borowski wrote: > On Fri, Jun 05, 2020 at 10:34:47AM +0200, Julian Andres Klode wrote: > > On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > > > systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@ > > > > Let's try this again: We run dpkg multiple times. We need to run dpkg > > up to a safe point where you can shutdown without ending with a broken > > system you possibly can't recover from. > > dpkg already does that. In fact, it uses really slow methods to increase > chance of survival on ancient unsafe filesystems like ext2. If dpkg being > interrupted leaves a system unrecoverable, that would be a severity:critical > bug and a fat regression over what we enjoyed for decades. > > And that's for interrupting dpkg inside one invocation. Between invocations > the committed state is even more consistent, and fsynced to the disk. > That's completely irrelevant. We cannot reboot in a state with unconfigured packages, because apt cannot recover from that. I've broken plenty of systems interrupting apt and then had to dpkg -i /var/cache/apt/archives/*.deb until apt got to a point where it was working again. > > > > and let it be something else in other distros? > > > > What are you on about now? Other distros can make their own choices, > > and build apt without the systemd dependency. > > This is bug tracker for _Debian_ not Ubuntu. Ubuntu is systemd-only, > Debian is not. And APT works fine without systemd. You can have libsystemd0 installed or that libelogind thing without having to run systemd. Whoa, crazy, right? If you want to switch your init system, do it from a live disc, not on a live system. > > > > And if you want something that works equally well > > > to systemd's inhibit, why not use systemd-inhibit in the first place? > > > > We are using the library that was designed for that purpose. You don't > > call binaries you've got a library for. That would be a hack. > > Except that the library is fragile, thus shouldn't be used this way from a > vital component of the system without being able to handle failures. > > Solutions include: > * dlopen()ing the library > * executing a binary > -- of which, the latter provides more isolation thus is safer. Both are complicated, fragile, hacks. The first one we did before with udev, and it ended up being broken for multiple years. The latter you need to come up with an RPC protocol to have the forked binary fork the individual dpkgs. Neither are solutions. > > I mean, I guess I could just create a filter and archive emails to > > the bug automatically, but this still means everyone else gets > > trolled. > > Would you accept a NMU fixing this, then? A person uploading such an NMU should have his upload rights revoked. We could move both systemd users (I guess) to use libglib2.0's gdbus library. We have no interest in doing this at the moment, as we don't need it and libsystemd0 pulls in less than libglib2.0 does on almost all systems. Since this is affecting every system, we can't just keep growing the set of packages installed by default. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532
On Fri, Jun 05, 2020 at 04:35:54PM +0200, Adam Borowski wrote: > On Fri, Jun 05, 2020 at 03:35:23PM +0200, Bill Allombert wrote: > > On Fri, Jun 05, 2020 at 03:23:11PM +0200, Ansgar wrote: > > > There is an updated version (RFC 5322) that should be used instead. > > > Notably RFC 5322 is more restrictive on the local part (whitespace and > > > escape sequences are no longer allowed except as obsolete syntax). > > > > > > Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in > > > local parts (and other places). That should probably be allowed as > > > well. > > > > > > So, Policy should probably: > > > - Refer to RFC 5322. > > > - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax"). > > > Are there packages actually using the obsolete syntax ? Can this be > > checked by Lintian ? > > Running Lintian on the whole archive is costly. Sure. But a lintian test for this is probably required if we are going to add it to policy. Cheers, -- Bill. Imagine a large red swirl here.
Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
Hi Alex,
you can depend on libphp-embed and then prepare the substvars like this:
echo "libphp-embed:Depends=libphp$(phpquery -V | head -1)-embed“ >
debian/uwsgi-plugin-php.substvars
and then in debian/control you would use
Depends: ${libphp-embed:Depends}
instead of
Depends: libphp-embed
Alternatively
You can of course walk through the full list returned by phpquery -V and build
a separate version
of the plugin for each available PHP version, but you would still have to
prepare the substvars.
Cheers,
Ondrej
--
Ondřej Surý
ond...@sury.org
> On 5 Jun 2020, at 16:02, Alexandre Rossi wrote:
>
>>> I do not have much experience with shared object libraries, but as
>>> libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could
>>> not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so :
>>> passing -lphp7.4 to the linker still goes back to linking to libphp7.so .
>>
>> Don't we already do that by depending on PHP ABI?
>>
>> If phpapi-20190902 is provided by multiple binary incompatible package
>> releases, then it seems to me that there is a bug in PHP packaging!
>>
>> If you agree (i.e. if I haven't again misunderstood the issue) then I
>> think this bug should be reassigned to src:php7.4 as we already follow
>> their mechanism for locking in on a specific ABI.
>
> I agree:
> - uwsgi-plugin-php depends on libphp-embed, phpapi-20190902
> - in bullseye, libphp-embed pulls libphp7.3-embed and phpapi-20190902
> pulls php7.4-cli
> - libphp7.so point to libphp7.3.so
> - uwsgi-plugin-php (built against 7.4) segfaults...
>
> I could not find any way to express that uwsgi-plugin-php depends
> on libphp7.4.so and not libphp7.3-embed, other than depending on
> libphp7.4-embed explicitely.
>
> What do the php folks think?
>
> Alex
>
signature.asc
Description: Message signed with OpenPGP
Bug#961899: Fwd: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR
Now I believe their's only one issue left: You marked the package to be Architecture:any. However, I do not see any differences for your package across difference hardware architecture. Could you explain the reason of using Architecture:any? If the built package would be exactly the same across all architectures, maybe Architecture:all should be used. After solving this problem, I believe your package should be ready for upload. -- Best, Boyuan Yang 在 2020-06-05星期五的 09:35 +0630，Ko Ko Ye`写道： > > > -- Forwarded message - > From: Ko Ko Ye` > Date: Fri, Jun 5, 2020 at 9:32 AM > Subject: Re: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect > with QR > To: Boyuan Yang <073p...@gmail.com> > now its available at > > https://mentors.debian.net/package/wifi-qr > > https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1-1.dsc signature.asc Description: This is a digitally signed message part
Bug#962280: r-cran-gwidgetstcltk autopkgtest failures: "xvfb-run: error: Xvfb failed to start"
Submitted a fix in the VCS: https://salsa.debian.org/r-pkg-team/r-cran-gwidgetstcltk/-/merge_requests/1
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Fri, Jun 05, 2020 at 10:34:47AM +0200, Julian Andres Klode wrote: > On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > > systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@ > > Let's try this again: We run dpkg multiple times. We need to run dpkg > up to a safe point where you can shutdown without ending with a broken > system you possibly can't recover from. dpkg already does that. In fact, it uses really slow methods to increase chance of survival on ancient unsafe filesystems like ext2. If dpkg being interrupted leaves a system unrecoverable, that would be a severity:critical bug and a fat regression over what we enjoyed for decades. And that's for interrupting dpkg inside one invocation. Between invocations the committed state is even more consistent, and fsynced to the disk. > Stop telling us what to do, you don't have a clue. > > dpkg being invoked as a process is a hack, a workaround because dpkg's > library is unusable, it's not a design decision. > in fact ... it's a lot of issues. There are a lot of design breakages in dpkg, but this isn't one. I believe I did enough reinventing of dpkg to have a clue. > > and let it be something else in other distros? > > What are you on about now? Other distros can make their own choices, > and build apt without the systemd dependency. This is bug tracker for _Debian_ not Ubuntu. Ubuntu is systemd-only, Debian is not. > > And if you want something that works equally well > > to systemd's inhibit, why not use systemd-inhibit in the first place? > > We are using the library that was designed for that purpose. You don't > call binaries you've got a library for. That would be a hack. Except that the library is fragile, thus shouldn't be used this way from a vital component of the system without being able to handle failures. Solutions include: * dlopen()ing the library * executing a binary -- of which, the latter provides more isolation thus is safer. > > This dbus voodoo looks a lot like a race condition to me anyway. If > > systemd-logind is going down before dpkg can send out dbus message, > > which probably can happen during shutdown, who's going to process this > > message and inhibit shutdown? `Inhibitor` doesn't do anything with > > returned `Fd` > > Don't talk about stuff you don't know anything about. It does not help > you. What we do with the fd is what we're supposed to do - keep it open > until we are done. Closing the fd is what releases the inhibitor. As long as dbus and logind survive. Try eg. crossgrading architectures to see them fail completely -- which is not a problem with other tools. > Right, let's just fail if we can't inhibit, because we don't support > non-systemd systems. Winner! That's Ubuntu, not Debian. The GR was clear -- option F which would have dropped support for non-systemd has been rejected. We ship multiple other rc systems: sysv-rc, openrc, runit, container-specific tools, etc. And we even financially sponsor development of non-systemd stuff. Systemd doesn't even _work_ on some popular containers, and it doesn't work either on some non-obscure setups (like, my personal workstation). This is fine with Debian; you as a core Ubuntu dev are biased towards it, but for me, Ubuntu being systemd-only is a hardship. As qemu fails to properly emulate hardware I work on, I need to use small dingy boxes instead of my fat one just to test if Ubuntu is ok. For this reason, validating $dayjob stuff on Ubuntu done by me is less adequate than it should be. > Sure, I mean we could check if we are actually running on systemd and > then log a warning, but then we also don't work with the libsystemd > shims if they gain support for this, so why bother? Why even a warning? All the inhibit thing does is to prevent the admin from doing something stupid (rebooting during an upgrade), and even that has non-fatal results. Debian had no inhibit at all for decades and the sky wasn't falling -- so it's a purely facultative option. If the system has been booted using systemd and systemd is in an usable state (no changing archs, etc) then inhibit will work -- otherwise, that particular handhold won't be there. > This is a best effort thing, there's nothing sensible we can do if it > fails, except for logging a warning, and that does not help a lot. We > don't want to issue an error obviously because you still want to be able > to upgrade the system if your dbus is down or stuff. Just silently ignore a failure to inhibit. > This bug is open to document our decision, not for people to harass > us. Maybe this was a bad idea and I should have closed and archived > it to avoid it attracting trolls. And hide problems, right? > I mean, I guess I could just create a filter and archive emails to > the bug automatically, but this still means everyone else gets > trolled. Would you accept a NMU fixing this, then? > debian developer - deb.li/jak | jak-linux.or
Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532
On Fri, 2020-06-05 at 15:35 +0200, Bill Allombert wrote:
> Are there packages actually using the obsolete syntax ?
Not checked yet. Stuff probably breaks with whitespace in local parts.
> Can this be checked by Lintian ?
Lintian uses Email::Address::XS. That seems to allow Unicode (allowed
by RFC 6532, but not by RFC 822), but also doesn't flag obsolete syntax
(whitespace). It accepts the address `käse <"kä se"@example.com>`:
perl -mEmail::Address::XS -E '
my $x = Email::Address::XS->parse(q{käse <"kä se"@example.com>});
say $x->is_valid();
'
So it is more generous than Policy either way.
Ansgar
Bug#962186: uwsgi-plugin-php: CI fails with SIG_SEGV in bullseye
> > I do not have much experience with shared object libraries, but as > > libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could > > not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so : > > passing -lphp7.4 to the linker still goes back to linking to libphp7.so . > > Don't we already do that by depending on PHP ABI? > > If phpapi-20190902 is provided by multiple binary incompatible package > releases, then it seems to me that there is a bug in PHP packaging! > > If you agree (i.e. if I haven't again misunderstood the issue) then I > think this bug should be reassigned to src:php7.4 as we already follow > their mechanism for locking in on a specific ABI. I agree: - uwsgi-plugin-php depends on libphp-embed, phpapi-20190902 - in bullseye, libphp-embed pulls libphp7.3-embed and phpapi-20190902 pulls php7.4-cli - libphp7.so point to libphp7.3.so - uwsgi-plugin-php (built against 7.4) segfaults... I could not find any way to express that uwsgi-plugin-php depends on libphp7.4.so and not libphp7.3-embed, other than depending on libphp7.4-embed explicitely. What do the php folks think? Alex
Bug#909630: no sysvinit scripts installed or available
Hello, I also interrested in non systemd init script. I will try to wrote what is needed. For now i try with http://www.trek.eu.org/devel/sysd2v/ but it’s not working. It’s look like the only apparent line causing issue during the install is in /var/lib/dpkg/info/gitlab.postinst : 524 -> systemctl restart gitlab-sidekiq I just comment it and restart the installation but i suspect it cause non visible trouble with some chown somewhere. Also i have some bug to reach some ressources(assets) and some routes (log/sign out) but it may come from my apache2 configuration. (i crrently use the recipe from https://github.com/gitlabhq/gitlab-recipes/blob/master/web-server/apache/gitlab-ssl-apache24.conf) If someone have a good tutorial for making relevant init script i take it thx. J. 0x053A41EF03878A98.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#962280: r-cran-gwidgetstcltk autopkgtest failures: "xvfb-run: error: Xvfb failed to start"
Package: r-cran-gwidgetstcltk Version: 0.0-55.1-2 Severity: normal Dear Maintainer, r-cran-gwidgetstcltk is more often than not failing its autopkgtests with the following error: BEGIN TEST runRUnit.R xvfb-run: error: Xvfb failed to start (see https://ci.debian.net/packages/r/r-cran-gwidgetstcltk/). This appears to be caused by the test script iterating over a list of test files and spawning xvfb-run for each of them, without waiting for the previous instance to clean up after itself, thus often resulting in the server number not being free. Passing "-a" to xvfb-run (to get a free server number for each instance) appears to fix the problem reliably.
Bug#962279: ITP: iddawc -- OAuth2 and OIDC client library
Package: wnpp Severity: wishlist Owner: Nicolas Mora X-Debbugs-CC: Debian IoT Maintainers * Package name : iddawc Version : 0.9.5 Upstream Author : Nicolas Mora * URL : https://github.com/babelouest/iddawc * License : LGPL-2.1 Programming Lang: C Description : OAuth2 and OIDC client library Handles the OAuth2 and OpenID Connect authentication process flow from the client side. . - Generates requests based on input parameters - Parses response - Validates response values -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhAWwL8wo75dEyPJT/oITlEC9IrkFAl7PnT0ACgkQ/oITlEC9 Irl4XxAAu0ryW6tHuze5yCAE7rKrQNsSnT0zd6PaAkBa8CAFdALnISWBBC/TEDQB W+yO2rYvpll3gjUkshdCPmNQ6uwUusdoCmZMKE1N+pFGCjsmIVTh88T6RUHngAcR jEN0DwsdWJpAs0Kz6ulromHttHBhObH/5sfN9l6Jo+lAGeFLqv8TKNl62OVxCG5k rlFzc2wTTf3bvquFMWBontrFRCNG8apcEtaV7KK25Bzai74le9KBqZ7hwJNPXK+8 2NmbdDd4Q+UefbksNvwZ9YGVKU2JrtdLbWK/O+vO49nr8lRc56Oz1CDmKDfedrXJ RZKaRGvgNaSjf5hSz95a9Q6Has7dH6PivSsJCVdqEAKxgLJmDCsf54tcmrukX1gq q0fIUs0SXC2GHYoJSyv+Jcik20U33ntiYW3HFlm+KDG4kjh9EtSYWauD/+UfzwRs 7Ox1z9YwlGOW8c4ppwyY+OhwHWOtbZNoBe2urVLbrVZLYVDgh+qlXZx9oyY83IO0 HTn/EWg1zjijnC/VFHQADRQo6aVFSnPOEx6Z+toLyTskbmwZttrV7vpMozmB0GLN 959/19NIMzck3+0LYFBGVRAs9AM45eevrMlK+IRKBSGkcKHVitekBJ4p1tCdFSUB dncmok7QPJ8IaNqHHsFoxFGDxWzcnIiagn779p6vtRDh4QvZmbc= =yhs1 -END PGP SIGNATURE-
Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR
On Fri, 5 Jun 2020 09:35:07 +0630 "Ko Ko Ye`" wrote: > -- Forwarded message - > From: Ko Ko Ye` > Date: Fri, Jun 5, 2020 at 9:32 AM > Subject: Re: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect Have you seen that bartm bot closed your RFS report again? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961899;msg=19 It is due to that you removed your package from mentors.debian.net ( https://mentors.debian.net/package/wifi-qr) and re-add it. When it gets removed, the bot will detect it and close the bug report automatically. You are expected to reopen the wrongly-closed bug report. Please *DO* *NOT* unnecessarily remove and readd your package on mentors.debian.net. You can always make a re-upload onto mentors.debian.net with the same package name and same version name. The mentors.debian.net site supports such behavior. (This does not apply to Debian's official archive, though.) -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532
On Fri, 2020-06-05 at 15:23 +0200, Ansgar wrote:
> So, Policy should probably:
> - Refer to RFC 5322.
> - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax").
> - Allow the extensions from RFC 6532.
Maybe Policy should also refer to either `mailbox` or `name-addr` for
the Maintainer field (`name-addr` requires angle brackets `<>`) and
either `mailbox-list`, `address-list`, or even `group-list` (would also
allow groups) for Uploaders.
`mailbox` allows plain address (without angle brackets `<>`); the
display-name is optional in `name-addr` as well, so that might be a
small change, but one could require it to be non-empty.
That is a small change for Uploaders as it would allow bare addresses.
Currently Uploaders would be something like
name-addr-list = name-addr *("," name-addr)
which doesn't exist in RFC 5322.
Personally I would probably just make Maintainer a `name-addr` and
Uploaders either `mailbox-list` (most restrictive) or `group-list`
(most permissive). Debian-specific constructs should probably be
avoided.
Ansgar
Bug#962218: gnutls28: build fails on IPv6-only buildds
On 2020-06-05 Julien Cristau wrote: > On Thu, Jun 04, 2020 at 11:19:31PM +0200, Julien Cristau wrote: > > The arch:all failure is at grnet and that buildd has both v4 and v6 > > addresses, so presumably unrelated. > > > A further give-back seems to have worked, so 3.6.13-4 managed to build > on all arches and move to testing now. Thank you!
Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532
On Fri, Jun 05, 2020 at 03:23:11PM +0200, Ansgar wrote: > Package: debian-policy > > 5.6.2 Maintainer currently states: > > +--- > | The package maintainer’s name and email address. The name must come > | first, then the email address inside angle brackets <> (in RFC822 > | format). > | > | If the maintainer’s name contains a full stop then the whole field > | will not work directly as an email address due to a misfeature in the > | syntax specified in RFC822 > +--- > > There is an updated version (RFC 5322) that should be used instead. > Notably RFC 5322 is more restrictive on the local part (whitespace and > escape sequences are no longer allowed except as obsolete syntax). > > Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in > local parts (and other places). That should probably be allowed as > well. > > So, Policy should probably: > - Refer to RFC 5322. > - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax"). Hello Ansgar, Are there packages actually using the obsolete syntax ? Can this be checked by Lintian ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#941937: apt: Unexpected linkage dependency on libsystemd
пт, 5 июн. 2020 г. в 11:34, Julian Andres Klode : > This is a best effort thing, there's nothing sensible we can do if it > fails, except for logging a warning, and that does not help a lot. We > don't want to issue an error obviously because you still want to be able > to upgrade the system if your dbus is down or stuff. > So this was added to prevent dpkg from running if the system is going down, but if the system is going down and dbus isn't up then dpkg is going to yolo anyway and this "works as intended"? Nice. Indeed, this entire discussion is completely pointless. > Stop talking. > > This bug is open to document our decision, not for people to harass > us. Maybe this was a bad idea and I should have closed and archived > it to avoid it attracting trolls. > I thought i was writing to the issue tracker and not to your personal blog, this interface is very confusing. I'm sorry, i didn't mean to violate your privacy.
Bug#892325: linphone: please package linphone 4.0
On Thu, 8 Mar 2018 12:52:03 +0100 "Dr. Tobias Quathamer" wrote: > > I think dropping the deprecated GTK client is fine. Please, whatever happens, the gtk version of linphone should *not* be dropped. It is much more "old fashioned" in appearance than the new Qt version but is infinitely more useful as a working phone. The new Qt linphone doesn't even have a working call history!
Bug#962278: Incron crash with an "*** unhandled exception occurred ***"
Package: incron Version: 0.5.10-3+b2 Severity: heavy Problem: --- Incron crash with an "*** unhandled exception occurred ***" if directories are deleted while Incron is monitoring them. Error is reproducible. # rm -Rf /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/Folder\ Test1/* If command to erase of pathes and/or files is moved to an own script (no 'rm') and the handling is smoother (via "sleep") and after the erase immediately an "service intron reload" take place, then intron crashes after (her max.) 3 to 4 pathes. Sometimes I received only „service incrond stopped“ in syslog. Solution: --- I have not found a workaround. Side effect: -- After executing commands „rm …“ and then „service incron reload“ in own script I see following messages in syslog: Jun 4 22:43:34 systemd[1]: Starting file system events scheduler... Jun 4 22:43:34 ncrond[3623]: loading system tables Jun 4 22:43:34 systemd[1]: incron.service: PID file /run/incrond.pid not readable (yet?) after start: No such file or directory and then Jun 4 22:43:34 systemd[1]: Started file system events scheduler. Jun 4 22:43:34 incrond[3623]: loading table Auser.conf Jun 4 22:43:34 incrond[3623]: loading table Buser.conf Jun 4 22:43:34 incrond[3623]: loading table example.conf Jun 4 22:43:34 incrond[3623]: cannot create watch for system table example.conf: (2) No such file or directory Jun 4 22:43:34 incrond[3623]: cannot create watch for system table example.conf: (2) No such file or directory Jun 4 22:43:34 incrond[3623]: cannot create watch for system table example.conf: (2) No such file or directory Jun 4 22:43:34 incrond[3623]: cannot create watch for system table example.conf: (2) No such file or directory ... Jun 4 22:43:34 incrond[3623]: loading table nextA.conf ... - Syslog: - Jun 04 22:57:48 incrond[18195]: (system::example.conf) CMD (/opt/scripts/incron_del_cron.sh /var/lib/univention-appcenter/apps/mycloud/data/mycloud-data /var/lib/univention-appcenter/apps/mycloud/data/mycloud-data/user Jun 04 22:57:49 incrond[18195]: *** unhandled exception occurred *** Jun 04 22:57:49 incrond[18195]: void InotifyWatch::SetEnabled(bool): enabling watch failed Jun 04 22:57:49 incrond[18195]: error: (2) No such file or directory Jun 04 22:57:49 incrond[18195]: stopping service Jun 04 22:57:49 systemd[1]:incron.service: Main process exited, code=exited, status=1/FAILURE Jun 04 22:57:49 systemd[1]:incron.service: Unit entered failed state. Jun 04 22:57:49 systemd[1]:incron.service: Failed with result 'exit-code'. --- Debian - # uname -v #1 SMP Debian 4.9.210-1 (2020-01-20) - Conf-files: - # ls -lah /etc/incron.d/example.conf -rw-r--r-- 1 root root 8,3K Jun 4 22:57 /etc/incron.d/example.conf etc/incond.d/example.conf (there are various other conf files in this incron directory, which all monitor other directories. There are no directory duplicates) -- /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/ IN_ATTRIB,IN_CLOSE_WRITE,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_MOVE_SELF,IN_MOVED_FROM,IN_MOVED_TO,IN_ONLYDIR,IN_NO_LOOP /opt/scripts/incron_del_cron.sh /var/lib/univention-appcenter/apps/myloud/data/myloud-data $@ $# $% /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/Folder\ Test1/ IN_ATTRIB,IN_CLOSE_WRITE,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_MOVE_SELF,IN_MOVED_FROM,IN_MOVED_TO,IN_ONLYDIR,IN_NO_LOOP /opt/scripts/incron_del_cron.sh /var/lib/univention-appcenter/apps/myloud/data/myloud-data $@ $# $% /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/Folder\ Test1/subfolder1/ IN_ATTRIB,IN_CLOSE_WRITE,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_MOVE_SELF,IN_MOVED_FROM,IN_MOVED_TO,IN_ONLYDIR,IN_NO_LOOP /opt/scripts/incron_del_cron.sh /var/lib/univention-appcenter/apps/myloud/data/myloud-data $@ $# $% /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/Folder\ Test1/Subfolder2/ IN_ATTRIB,IN_CLOSE_WRITE,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_MOVE_SELF,IN_MOVED_FROM,IN_MOVED_TO,IN_ONLYDIR,IN_NO_LOOP /opt/scripts/incron_del_cron.sh /var/lib/univention-appcenter/apps/myloud/data/myloud-data $@ $# $% /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/Folder\ Test1/subfolder3/ IN_ATTRIB,IN_CLOSE_WRITE,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_MOVE_SELF,IN_MOVED_FROM,IN_MOVED_TO,IN_ONLYDIR,IN_NO_LOOP /opt/scripts/incron_del_cron.sh /var/lib/univention-appcenter/apps/myloud/data/myloud-data $@ $# $% /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/Folder\ Test2/ IN_ATTRIB,IN_CLOSE_WRITE,IN_CREATE,IN_DELETE,IN_DELETE_SELF,IN_MOVE_SELF,IN_MOVED_FROM,IN_MOVED_TO,IN_ONLYDIR,IN_NO_LOOP /opt/scripts/incron_del_cron.sh /var/lib/univention-appcenter/apps/myloud/data/myloud-data $@ $# $% /var/lib/univention-appcenter/apps/myloud/data/myloud-data/user/files/Folder\ Test2
Bug#961332: Fwd: Bug#961332: gnome-flashback: System indicators (volume, bluetooth, ...) do not appear
On Fri, Jun 5, 2020 at 2:36 PM Timothy Allen wrote: > On 5/6/20 21:02, Alberts Muktupāvels wrote: > > I do know that gnome-flashback is used with i3, but it is not really > > supported. Doesn't i3 have its own indicators or something like that? > > i3 has a "bar" which is a bit like GNOME's mini-commander applet - it > displays output of a command (that by default shows things like battery > charge and system load), but it doesn't have any interactive bits other > than a system tray. In particular, it doesn't include a volume control, > so I really appreciated the one from gnome-flashback. > https://github.com/muktupavels/sound-applet Quick version based on code from gnome-flashback before it was converted to System Indicators applet. -- Alberts Muktupāvels
Bug#925375: ucf: UCF_FORCE_CONFFNEW=1 and dpkg --force-confnew broken
Control: reassign -1 ucf Control: retitle -1 ucf: Use DPKG_FORCE to handle dpkg --force-* options On Mon, 2020-05-11 at 22:39:10 -0700, Manoj Srivastava wrote: > severity 925375 wishlist > retitle 925375 dpkg could set confnew/confold env variables for ucf > Yes, dpkg and ucf are independent, and they usually operate on > different files. dpkg does not take any action specificallyy witgh ucf > in mind, that is the domain of the maintainer scripts installed by > individual packages. Perhaps the communication might be better > > As for UCF_FORCE_CONFFNEW, there is a treadeoff betweem just > replacing the configuration file versus leaving random files all over > /etc; the default action is to not clutter. As you have > discovcered. RETAIN_OLD=YES allows the user to override that choice. So, dpkg has supported setting a DPKG_FORCE environment variable since 1.19.5, one of the reasons was precisely having ucf in mind. :) The exact semantics are documented in dpkg(1). Thanks, Guillem
Bug#962277: debian-policy: Maintainer address: move away from RFC822 to RFC5322 + RFC6532
Package: debian-policy 5.6.2 Maintainer currently states: +--- | The package maintainer’s name and email address. The name must come | first, then the email address inside angle brackets <> (in RFC822 | format). | | If the maintainer’s name contains a full stop then the whole field | will not work directly as an email address due to a misfeature in the | syntax specified in RFC822 +--- There is an updated version (RFC 5322) that should be used instead. Notably RFC 5322 is more restrictive on the local part (whitespace and escape sequences are no longer allowed except as obsolete syntax). Furthermore RFC 6532 extends RFC 5322 and allows non-ascii-UTF-8 in local parts (and other places). That should probably be allowed as well. So, Policy should probably: - Refer to RFC 5322. - Forbid the obsolete syntax (RFC 5322, Section 4 "Obsolete Syntax"). - Allow the extensions from RFC 6532. Ansgar
Bug#961841: fontforge FTBFS on 64bit big endian: test failures
It appears that upstream commit was already cherry-picked in https://salsa.debian.org/fonts-team/fontforge/-/commit/ad2b5f648241de5920a6f7f738dea091290a0af0, so all it needs is a release (and ideally a mention to this bug in the changelog next to the "add patches cherry-picked upstream to fix a range of issues" line). >
