Bug#953964: ITP: python-strictyaml -- Strict, typed YAML parser for Python
Hi, I have filled an ITP [1] before realizing that it was already open here. I have a 1.1.1-1 version ready to upload to mentors, would that be OK for you that I publish it under your ITP? Your ITP was published almost 1 year ago with no answers to status update requests in this bug. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976690 Best regards, Romain.
Bug#976694: radvd systemd unit installed in subdirectory -> invalid
On Sun, Dec 06, 2020 at 10:20:10PM -0300, Adilson dos Santos Dantas wrote: > I can confirm this bug and I have fixed it with a little change on the > file radvd.install and rebuild the package. I'm attaching this file below Thanks > so you can copy into the debian folder. Done ( https://salsa.debian.org/debian/radvd/-/commit/4e762f020101bb407e755b12ad83c284bf1d94ad ) > Best regards, > Adilson dos Santos Dantas Regards Geert Stappers -- Silence is hard to parse
Bug#976701: ITP: libnetconf2 -- NETCONF protocol library
Package: wnpp Severity: wishlist Owner: Ondřej Surý -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libnetconf2 Version : 1.1.16 Upstream Author : CESNET, z.s.p.o. * URL : https://github.com/CESNET/libnetconf2 * License : Apache-2.0. Programming Lang: C, C++ Description : NETCONF protocol library NETCONF library in C intended for building NETCONF clients and servers. NETCONF is the NETwork CONFiguration protocol introduced by IETF. . libnetconf2 is a NETCONF library in C handling NETCONF authentication and all NETCONF RPC communication both server and client-side. Note that NETCONF datastore implementation is not a part of this library. The library supports both NETCONF 1.0 (RFC 4741) as well as NETCONF 1.1 (RFC 6241). The main features include: . * NETCONF over SSH (RFC 4742, RFC 6242), using libssh. * NETCONF over TLS (RFC 7589), using OpenSSL. * DNSSEC SSH Key Fingerprints (RFC 4255) * NETCONF over pre-established transport sessions (using this mechanism the communication can be tunneled through sshd(8), for instance). * NETCONF Call Home (RFC 8071). * NETCONF Event Notifications (RFC 5277), -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl/N2eRfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcK5sw/8CqwvPrMo3m7Bg7foEUEazfK7hucklmf8l4L0biC3sITTwIj2YdniVJnw eUNCU+TUO+AEae9qOhj0LWqzH6CW62u8YWfJ0TvbTV3uhmwwhRCK+MuE4VoI4bxH YDReimFSTgJ1rPD+Kt2ueF9TDpiO6V88om5r5oAhaVHUcclNZmtXJ6sWOxytlWI4 FGAhsLqhi0Mfvk9oLQ9ijbcQtynuLyHBmgx5QpWgMfB0Bst+/MdpI1dSaoDqWrmE 08kBN/2KHq48Fw/NZGZyPS7y+9n3rwHSGesz/jpQTJEUYwC1gt+ZfnMUw+0DrK8X PiLlS+I9XDQT+r3au6bZhi1nUIvWs7vhRmiUzMsGoII62BwKeuSIq0gjw6FqOSOy Zbe9XGgBgq63XdMSIFF3nt12N+YpmdZGAECeIpwXofCohQSoeC1NZpoX5voHECXT 94PmmDzaT9kmZ6fvfqo4WnrPWgLxowLFAkeZCUjfnfruJebxyiX0TZ+bbWcxeiVB w0ez1qP8w9TF+jgsuORXRksrZacrhbgseOG00Vc3jUZSnT45rKOAUMsuRO11Ymt7 4EiDClqRCxyXuQqSxBgxikF2QwkTXyiCb7e/vI0q4yMO4OAKSMGjYe2SgQFNy1cY f9cnrGHMH4joYS2lqEjNYrujckJ3/Qr46pWP8WRPnFjKMgdROeU= =xph4 -END PGP SIGNATURE-
Bug#976694: radvd systemd unit installed in subdirectory -> invalid
Control: tags -1 pending On Mon, Dec 07, 2020 at 01:55:17AM +0100, Mara Sophie Grosch wrote: > > radvd version 1:2.18-2 installs the systemd unit file at > /lib/systemd/system/radvd.service/radvd.service > > As you can see, there is a subdirectory named like the unit file in > between. This prevents radvd from starting. Oops. Fix is work in progress. Thanks for the report. Regards Geert Stappers -- Silence is hard to parse
Bug#975488: lammps FTBFS: error: format not a string literal and no format arguments
Control: severity -1 normal Per reproducible builds [1], lammps starting building again around 2020-11-30. The recent binNMU for Python 3.9 only was also successful. [1] https://tests.reproducible-builds.org/debian/history/amd64/lammps.html
Bug#925818: rocksdb: ftbfs with GCC-9
Hi Paul, On Sun, Dec 6, 2020 at 9:27 PM Paul Gevers wrote: > On Wed, 27 Mar 2019 19:47:52 + Matthias Klose wrote: > > The package fails to build in a test rebuild on at least amd64 with > > gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The > > severity of this report will be raised before the bullseye release, > > so nothing has to be done for the buster release. > > Do you intend to fix this soon in unstable too? The freeze of bullseye > is near and we'd want to have this bug fixed. Yeah, it's a bit confusing why someone tagged this as affecting experimental. I could _not_ confirm that the FTBFS happens there. Currently this goes in three paths. Try to find a patch for the Sid version of RocksDB, file a transition request for the experimental version (this would be the best ATM). Then I've patched and packaged the new upstream version, but as it switches to CMake build system it needs more testing. Cheers, Laszlo/GCS
Bug#976218: nagios-plugins-contrib: diff for NMU version 27.20200511+1+nmu1 (was: Bug#976218: file breaks nagios-plugins-contrib autopkgtest: SSL_CERT UNKNOWN www.debian.org: Unable to fetch a valid c
Control: tags 976218 + patch
Control: tags 976218 + pending
Dear maintainer,
to resolve this issue, I've prepared a NMU for nagios-plugins-contrib
(versioned as 27.20200511+1+nmu1), and uploaded it to DELAYED/5. Please
feel free to tell me if I should delay it longer.
Regards.
Christop
diff -Nru nagios-plugins-contrib-27.20200511+1/debian/changelog
nagios-plugins-contrib-27.20200511+1+nmu1/debian/changelog
--- nagios-plugins-contrib-27.20200511+1/debian/changelog 2020-05-11
17:08:39.0 +0200
+++ nagios-plugins-contrib-27.20200511+1+nmu1/debian/changelog 2020-12-06
21:20:03.0 +0100
@@ -1,3 +1,10 @@
+nagios-plugins-contrib (27.20200511+1+nmu1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Cherry-pick upstream fix for check_ssl_cert. Closes: #976218
+
+ -- Christoph Biedl Sun, 06 Dec 2020
21:20:03 +0100
+
nagios-plugins-contrib (27.20200511+1) unstable; urgency=medium
* [b6d2915] Fixing tests (again)
diff -Nru
nagios-plugins-contrib-27.20200511+1/debian/patches/check_ssl_cert/adjust-for-file-5.39
nagios-plugins-contrib-27.20200511+1+nmu1/debian/patches/check_ssl_cert/adjust-for-file-5.39
---
nagios-plugins-contrib-27.20200511+1/debian/patches/check_ssl_cert/adjust-for-file-5.39
1970-01-01 01:00:00.0 +0100
+++
nagios-plugins-contrib-27.20200511+1+nmu1/debian/patches/check_ssl_cert/adjust-for-file-5.39
2020-12-06 21:20:03.0 +0100
@@ -0,0 +1,20 @@
+Subject: Fixes #212 ("Unable to fetch a valid certificate issuer certificate")
+Origin: v1.119.0
+Upstream-Author: mat...@corti.li
+Date: Wed Jul 1 21:35:12 2020 +0200
+Bug-Debian: https://bugs.debian.org/976218
+
+Root cause: The file(1) program changed the output to "certificate" in
+versio 5.39
+
+--- a/check_ssl_cert/check_ssl_cert_1.98.0/check_ssl_cert
b/check_ssl_cert/check_ssl_cert_1.98.0/check_ssl_cert
+@@ -2450,7 +2450,7 @@
+ # check the result
+ if ! "${FILE_BIN}" "${ISSUER_CERT_TMP}" | grep -E -q ':
(ASCII|PEM)' ; then
+
+-if "${FILE_BIN}" "${ISSUER_CERT_TMP}" | grep -q ': data' ;
then
++if "${FILE_BIN}" "${ISSUER_CERT_TMP}" | grep -E -q
'(data|Certificate)' ; then
+
+ if [ -n "${DEBUG}" ] ; then
+ echo "[DBG] OCSP: converting issuer certificate from
DER to PEM"
diff -Nru nagios-plugins-contrib-27.20200511+1/debian/patches/series
nagios-plugins-contrib-27.20200511+1+nmu1/debian/patches/series
--- nagios-plugins-contrib-27.20200511+1/debian/patches/series 2020-05-11
17:08:39.0 +0200
+++ nagios-plugins-contrib-27.20200511+1+nmu1/debian/patches/series
2020-12-06 21:20:03.0 +0100
@@ -54,3 +54,4 @@
percona-nagios-plugins/python2to3
check_email_delivery/check_smtp_send-hello
dsa/python2to3
+check_ssl_cert/adjust-for-file-5.39
signature.asc
Description: PGP signature
Bug#976700: transition: wireshark ( late notice :-( )
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I'm sorry, I missed that libvirt started shipping a wireshark plugin and thus started depending on libwiresharkX in libvirt-wireshark. Please trigger rebuilds of libvirt in unstable, I have already uploaded wireshark before noticing the reverse dependency. Libvirt rebuilt for me locally with the new wireshark packages. Thank you, Balint
Bug#926922: kodi: Please package new upstream release
Hi Nicholas, 7 грудня 2020 р. 02:09:21 UTC, Nicholas D Steeves написав(-ла): >Hi, > >On Fri, Nov 13, 2020 at 02:14:54PM +0100, Tobias Frost wrote: >> Control: retitle -1 kodi: Please package (stable) version 18.9 >> >> My kodi instance tells me that there is an stable release 18.9… >> So maybe, while we wait for 19 to be released, can we get this version ;-) >> > >FWIW, at this stage in the bullseye cycle I agree with Vasyl's >decision to prioritise work on 19.0 prereleases, because ultimately we >all want to see 19.0 in bullseye. Exactly. > >19.0~alpha3 is the latest version in experimental, and 19.0~beta1, the >next prerelease is the latest available upstream. Beta2 dropped tonight. What I will do in a day or two: * Fix regression in upstream PR#18706 * Complete routine upstreaming second part of PR#18779 * Build 19.0~beta2 and push it to upstream closingbthis bug >BTW, Vasyl, is upstream aware of our freeze schedule and deadlines for >a 19.0 stable release? Yes, Dave and Ross are aware. We expect RC early New Year so beta2 definitely goes to unstable! -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
Bug#976235: enlightenment: e switches off screen|monitor
On Mon, Dec 07, 2020 at 12:43:35AM +0100, enno wrote: > > "Ross" == Ross Vandegrift writes: > > [...] - it might be useful to run `xrandr` in > > flwm and a bare X session to compare with E's output regarding > > your displays. > > xrandr on flwm and on pure X diff -q 0: > LVDS connected primary 1600x900+0+0 (normal left inverted right x axis y > axis) 310mm x 174mm >1600x900 59.90*+ 39.93 >1440x900 59.99 >1280x854 59.95 >1280x800 59.96 >1280x720 59.97 >1152x768 59.95 >1024x768 59.95 >800x600 59.96 >848x480 59.94 >720x480 59.94 >640x480 59.94 > DisplayPort-0 disconnected (normal left inverted right x axis y axis) > DisplayPort-1 disconnected (normal left inverted right x axis y axis) > DisplayPort-2 disconnected (normal left inverted right x axis y axis) > VGA-0 disconnected (normal left inverted right x axis y axis) > > So all three cases use LVDS and know the precise measurements of my display, > just e seems to need something additional which alas is not in the dependency > list i suppose. Well, not quite - this output shows that X knows the measurements of your LVDS display, ie, your laptop's built-in panel. The external screen are not detected - that confirms this is not a problem in E. Since X doesn't detect a display connected to the other outputs, E is disabling them. I bet flwm doesn't have any knowledge of xrandr, and just runs on any X display it finds. I don't know why the connection would be misreported - probably a bug in the video driver. Ross
Bug#976699: 247 breaks some by-label mounts
Package: udev Version: 247.1-3 I have a fairly straightforward virtualized kvm guest or two here using ext4 volumes on a paritioned virtio block device. Just a root volume, swap partition, tmpfs for /tmp and a volume for /var all configured in /etc/fstab. After upgrading to 247 the /var volume fails to mount if fstab uses LABEL=/var. It will work if I switch to UUID=..., change the label name to something that doesn't require escaping, or if I downgrade everything to 246. upstream bug https://github.com/systemd/systemd/issues/17772 if I had to guess. -- Jamie Heilman http://audible.transient.net/~jamie/
Bug#976698: ITP: antlr4-python3-runtime -- ANTLR 4.9 runtime for Python 3.7
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: antlr4-python3-runtime Version : 4.9 Upstream Author : Eric Vergnaud, Terence Parr, Sam Harwell * URL : http://www.antlr.org * License : BSD Programming Lang: Python Description : ANTLR 4.9 runtime for Python 3.7 Binary package names: python3-antlr4-python3-runtime
Bug#976694: radvd systemd unit installed in subdirectory -> invalid
Package: radvd Version: 1:2.18-2 Severity: important Dear Maintainer, radvd version 1:2.18-2 installs the systemd unit file at /lib/systemd/system/radvd.service/radvd.service As you can see, there is a subdirectory named like the unit file in between. This prevents radvd from starting. Version 1:2.18-1 is ok in this regard. Best regards Mara Sophie Grosch -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages radvd depends on: ii adduser 3.118 ii libc6 2.31-5 ii lsb-base 11.1.0 radvd recommends no packages. radvd suggests no packages. -- no debconf information
Bug#974705: Changes to job handling cause hangs in wait
On Thu, Dec 03, 2020 at 01:27:51PM +0100, Michael Biebl wrote: > > Hm, so I applied this change and switched backed to dash, but now I get > > autopkgtest systemd --test-name=timedated -s -- lxc -s autopkgtest-sid > ... > disable NTP > enable NTP > Terminated > autopkgtest [13:21:42]: test timedated: ---] > autopkgtest [13:21:42]: test timedated: - - - - - - - - - - results - - - - > - - - - - - > timedatedFAIL non-zero exit status 143 > > > Running with sh -x > ... > + kill 825 > + wait 825 > Terminated > > > Herbert, any idea what going wrong there? > (systemd 247.1-2 and dash 0.5.11+git20200708+dd9ef66-2) Sorry, my bad. wait(1) with no arguments ignores the error status of the child and always return zero. wait(1) specifically on a child obviously returns the error status of that child. Since the child was killed, we need to ignore that, so this works for me: wait $MONPID 2> /dev/null || : Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#976697: webext-umatrix: no longer developed upstream, remove or switch to LibreMatrix or?
Package: webext-umatrix Version: 1.4.0+dfsg-1 Severity: seriousX-Debbugs-CC: Ximin Luo uMatrix is no longer developed upstream: https://github.com/gorhill/uMatrix This repository has been archived by the owner. It is now read-only. This was discussed on Hacker News at the time: https://news.ycombinator.com/item?id=24532973 The upstream author has stated they no longer have time for it: https://github.com/uBlockOrigin/uMatrix-issues/issues/291#issuecomment-694988696 I've archived uMatrix's repo, I can't and won't be spending any more time on this project, and neither on all such issues. I think that uMatrix now isn't suitable to ship in bullseye. These are the options for solving this issue: uMatrix could be removed in favour of uBlock Origin's advanced mode. uMatrix could be removed and LibreMatrix packaged, I think this is a community fork so it should be a drop-in replacement. https://www.librematrix.com/ https://github.com/LibreMatrix/LibreMatrix Something else? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#976674: RFS: menu-cache/1.1.0-1.1 [NMU] [RC] -- LXDE implementation of the freedesktop Menu's cache (libexec)
Control: tag -1 + pending On Sun, 06 Dec 2020 20:41:17 +0100, Mateusz Łukasik wrote: > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "menu-cache": Uploaded to DELAYED/2; thanks for your work! Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Tracy Chapman: Talkin' Bout a Revolution signature.asc Description: Digital Signature
Bug#957533: menu-cache: diff for NMU version 1.1.0-1.1
Control: tags 957533 + patch
Control: tags 957533 + pending
Dear maintainer,
Mateusz Łukasik has prepared an NMU for menu-cache (versioned as
1.1.0-1.1) and I've uploaded it to DELAYED/2. Please feel free to
tell me if I should delay it longer.
Regards.
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Caridad Cuervo: Yo no lloro mas
diff -Nru menu-cache-1.1.0/debian/changelog menu-cache-1.1.0/debian/changelog
--- menu-cache-1.1.0/debian/changelog 2017-11-04 01:11:57.0 +0100
+++ menu-cache-1.1.0/debian/changelog 2020-11-12 20:40:31.0 +0100
@@ -1,3 +1,10 @@
+menu-cache (1.1.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Take from Fedora patch for fix FTBFS with gcc-10. (Closes: #957533)
+
+ -- Mateusz Łukasik Thu, 12 Nov 2020 20:40:31 +0100
+
menu-cache (1.1.0-1) unstable; urgency=medium
* Replacing build dependency on libfm-dev with libfm-extra-dev
diff -Nru menu-cache-1.1.0/debian/patches/menu-cache-1.1.0-0001-Support-gcc10-compilation.patch menu-cache-1.1.0/debian/patches/menu-cache-1.1.0-0001-Support-gcc10-compilation.patch
--- menu-cache-1.1.0/debian/patches/menu-cache-1.1.0-0001-Support-gcc10-compilation.patch 1970-01-01 01:00:00.0 +0100
+++ menu-cache-1.1.0/debian/patches/menu-cache-1.1.0-0001-Support-gcc10-compilation.patch 2020-11-12 20:36:19.0 +0100
@@ -0,0 +1,108 @@
+From 1ce739649b4d66339a03fc0ec9ee7a2f7c141780 Mon Sep 17 00:00:00 2001
+From: Mamoru TASAKA
+Date: Fri, 24 Jan 2020 13:33:00 +0900
+Subject: [PATCH] Support gcc10 compilation
+
+gcc10 now defaults to -fno-common, and with gcc10 menu-cache compilation fails like
+
+/bin/ld: menu-merge.o:menu-cache-gen/menu-tags.h:167: multiple definition of `DirDirs'; main.o:menu-cache-gen/menu-tags.h:167: first defined here
+/bin/ld: menu-merge.o:menu-cache-gen/menu-tags.h:164: multiple definition of `AppDirs'; main.o:menu-cache-gen/menu-tags.h:164: first defined here
+/bin/ld: menu-merge.o:menu-cache-gen/menu-tags.h:52: multiple definition of `menuTag_Layout'; main.o:menu-cache-gen/menu-tags.h:52: first defined here
+
+
+This patch fixes compilation with gcc10: properly declaring variables in header with "extern", and also removing some unneeded variables in header files.
+---
+ menu-cache-gen/menu-tags.h | 55 --
+ 1 file changed, 17 insertions(+), 38 deletions(-)
+
+diff --git a/menu-cache-gen/menu-tags.h b/menu-cache-gen/menu-tags.h
+index f3fd7d3..f71c0bc 100644
+--- a/menu-cache-gen/menu-tags.h
b/menu-cache-gen/menu-tags.h
+@@ -22,38 +22,17 @@
+ #include
+ #include
+
+-FmXmlFileTag menuTag_Menu;
+-FmXmlFileTag menuTag_AppDir;
+-FmXmlFileTag menuTag_DefaultAppDirs;
+-FmXmlFileTag menuTag_DirectoryDir;
+-FmXmlFileTag menuTag_DefaultDirectoryDirs;
+-FmXmlFileTag menuTag_Include;
+-FmXmlFileTag menuTag_Exclude;
+-FmXmlFileTag menuTag_Filename;
+-FmXmlFileTag menuTag_Or;
+-FmXmlFileTag menuTag_And;
+-FmXmlFileTag menuTag_Not;
+-FmXmlFileTag menuTag_Category;
+-FmXmlFileTag menuTag_MergeFile;
+-FmXmlFileTag menuTag_MergeDir;
+-FmXmlFileTag menuTag_DefaultMergeDirs;
+-FmXmlFileTag menuTag_Directory;
+-FmXmlFileTag menuTag_Name;
+-FmXmlFileTag menuTag_Deleted;
+-FmXmlFileTag menuTag_NotDeleted;
+-FmXmlFileTag menuTag_OnlyUnallocated;
+-FmXmlFileTag menuTag_NotOnlyUnallocated;
+-FmXmlFileTag menuTag_All;
+-FmXmlFileTag menuTag_LegacyDir;
+-FmXmlFileTag menuTag_KDELegacyDirs;
+-FmXmlFileTag menuTag_Move;
+-FmXmlFileTag menuTag_Old;
+-FmXmlFileTag menuTag_New;
+-FmXmlFileTag menuTag_Layout;
+-FmXmlFileTag menuTag_DefaultLayout;
+-FmXmlFileTag menuTag_Menuname;
+-FmXmlFileTag menuTag_Separator;
+-FmXmlFileTag menuTag_Merge;
++extern FmXmlFileTag menuTag_AppDir;
++extern FmXmlFileTag menuTag_DirectoryDir;
++extern FmXmlFileTag menuTag_Include;
++extern FmXmlFileTag menuTag_Exclude;
++extern FmXmlFileTag menuTag_Filename;
++extern FmXmlFileTag menuTag_Or;
++extern FmXmlFileTag menuTag_And;
++extern FmXmlFileTag menuTag_Not;
++extern FmXmlFileTag menuTag_Category;
++extern FmXmlFileTag menuTag_All;
++extern FmXmlFileTag menuTag_LegacyDir;
+
+ typedef enum {
+ MERGE_NONE, /* starting value */
+@@ -152,19 +131,19 @@ typedef struct {
+ } MenuRule;
+
+ /* requested language(s) */
+-char **languages;
++extern char **languages;
+
+ /* list of menu files to monitor */
+-GSList *MenuFiles;
++extern GSList *MenuFiles;
+
+ /* list of menu dirs to monitor */
+-GSList *MenuDirs;
++extern GSList *MenuDirs;
+
+ /* list of available app dirs */
+-GSList *AppDirs;
++extern GSList *AppDirs;
+
+ /* list of available dir dirs */
+-GSList *DirDirs;
++extern GSList *DirDirs;
+
+ /* parse and merge menu files */
+ MenuMenu *get_merged_menu(const char *file, FmXmlFile **xmlfile, GError **error);
+@@ -177,7 +156,7 @@ gboolean save_menu_cache(MenuMenu *layout,
Bug#976685: dash -x output seems broken
More examples: $ dash -c 'echo ///' /// $ dash -c 'echo "///"' // $ dash -c "echo '///'" // $ dash -c 'echo ' $ dash -c 'echo ""' // $ dash -c "echo ''" // $ dash -c 'echo ' $ dash -c 'echo ""' // $ dash -c "echo ''" //
Bug#976696: smartmontools: install drivedb.h to /usr and copy into /var in postinst when missing/outdated
Package: smartmontools
Version: 7.1-1
Severity: importantUsertags: varmisuse
The current system of shipping drivedb.h in /var has some downsides:
* debsums will complain if the user has ever ran update-smart-drivedb
* if smartmontools is updated to a newer Debian revision after the
user ran update-smart-drivedb, then the user's updates will be
overwritten and reverted by the update of the package.
Please install drivedb.h to /usr and then add code to the postinst that
will copy the /usr drivedb.h into /var when the /var drivedb.h is
either missing or is an older copy of the file.
Unfortunately, while the package contains a drivedb.h with a valid
Subversion $Id value, the file downloaded by update-smart-drivedb does
not contain a valid version number in the $Id value, so it will be hard
to determine if the downloaded file is newer or older than the /usr
drivedb.h. Looking at the code this seems to be because the default URL
does not contain the $Id header and only the "sf" and "trac" URLs do
contain correct $Id headers. Since git doesn't support $Id substitution
it would probably be a good idea for upstream to add a version number
to the file that isn't dependent on Subversion $Id substitution, which
could then be used for fixing this issue.
$ sudo apt -qq reinstall smartmontools
$ grep -F '$Id' /var/lib/smartmontools/drivedb/drivedb.h
{ "$Id: drivedb.h 5008 2019-12-28 21:40:37Z chrfranke $",
$ sudo rm -f /var/lib/smartmontools/drivedb/drivedb.h
$ sudo update-smart-drivedb
/var/lib/smartmontools/drivedb/drivedb.h updated from
branches/RELEASE_7_0_DRIVEDB
$ grep -F '$Id' /var/lib/smartmontools/drivedb/drivedb.h
{ "$Id$",
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages smartmontools depends on:
ii debianutils 4.11.2
ii libc62.31-5
ii libcap-ng0 0.7.9-2.2
ii libgcc-s1 [libgcc1] 10.2.0-19
ii libselinux1 3.1-2+b1
ii libstdc++6 10.2.0-19
ii libsystemd0 246.6-4
ii lsb-base 11.1.0
smartmontools recommends no packages.
Versions of packages smartmontools suggests:
ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2
ii curl 7.72.0-1
ii gpg2.2.20-1
pn gsmartcontrol
ii lynx 2.9.0dev.6-1
ii smart-notifier 0.28-6
ii wget 1.20.3-1+b3
-- no debconf information
-- debsums errors found:
debsums: changed file /var/lib/smartmontools/drivedb/drivedb.h (from
smartmontools package)
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#976189: Bug 9761189 - How to fix
Hello Maintainer:
Came across this as well and did some digging to find the cause. Found that
Python 3.9 removed the getiterator attribute and replaced it with iter.
To fix, in file "/usr/lib/python3/dist-packages/catfish_lib/Builder.py" at
line 87 changed this line:
ele_widgets = tree.getiterator("object")
to
ele_widgets = tree.iter("object")
Also found one more line in the file needed to be changed (as I scanned to
see if "getiterator" was mentioned anywhere else in the file) and it's this
code at line 112:
ele_signals = tree.getiterator("signal")
Changed it to show:
ele_signals = tree.iter("signal")
Saved the original with .orig extension then saved changed file as
Builder.py.
Tested catfish again from terminal and it started right up and functioned
normally as I tested several searches. As I never did a patch diff before,
if anyone can create a patch from my notes here feel free to do so.
Cheers!
-R
Bug#976685: dash -x output seems broken
retitle 976685 dash regression in handling of /// thanks
Bug#926922: kodi: Please package new upstream release
Hi, On Fri, Nov 13, 2020 at 02:14:54PM +0100, Tobias Frost wrote: > Control: retitle -1 kodi: Please package (stable) version 18.9 > > My kodi instance tells me that there is an stable release 18.9… > So maybe, while we wait for 19 to be released, can we get this version ;-) > FWIW, at this stage in the bullseye cycle I agree with Vasyl's decision to prioritise work on 19.0 prereleases, because ultimately we all want to see 19.0 in bullseye. 19.0~alpha3 is the latest version in experimental, and 19.0~beta1, the next prerelease is the latest available upstream. BTW, Vasyl, is upstream aware of our freeze schedule and deadlines for a 19.0 stable release? Regards, Nicholas signature.asc Description: PGP signature
Bug#976680: update-apparmor-samba-profile generates invalid file if share path in smb.conf between double quotes
Package: samba Version: 2:4.13.2+dfsg-3 Severity: normal X-Debbugs-Cc: frede...@frehi.be I have a share in smb.conf configured like this: [Classical music] comment = Classical music path = "/mnt/storage2/Classical music" guest ok = no browseable = yes read only = yes valid users = foo vfs objects = btrfs update-apparmor-samba-profile then puts this in the /etc/apparmor.d/samba/smbd- shares file: ""/mnt/storage2/Classical music"/" rk, ""/mnt/storage2/Classical music"/**" rwkl, Which results in this error: # apparmor_parser -r /etc/apparmor.d/usr.sbin.smbd AppArmor parser error for /etc/apparmor.d/usr.sbin.smbd in /etc/apparmor.d/samba/smbd-shares at line 5: Lexer found unexpected character: '"' (0x22) in state: INITIAL -- Package-specific info: * /etc/samba/smb.conf present, but not attached * /var/lib/samba/dhcp.conf not present -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (400, 'unstable'), (250, 'stable'), (160, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages samba depends on: ii adduser 3.118 ii dpkg 1.20.5 ii init-system-helpers 1.59 ii libbsd0 0.10.0-1 ii libc62.31-5 ii libgnutls30 3.6.15-4 ii libldb2 2:2.2.0-3+b1 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpopt0 1.18-2 ii libpython3.9 3.9.1~rc1-2 ii libtalloc2 2.3.1-2+b1 ii libtasn1-6 4.16.0-2 ii libtdb1 1.4.3-1+b1 ii libtevent0 0.10.2-1 ii libwbclient0 2:4.13.2+dfsg-3 ii lsb-base 11.1.0 ii procps 2:3.3.16-5 ii python3 3.9.0-3 ii python3-dnspython2.0.0-1 ii python3-samba2:4.13.2+dfsg-3 ii samba-common 2:4.13.2+dfsg-3 ii samba-common-bin 2:4.13.2+dfsg-3 ii samba-libs 2:4.13.2+dfsg-3 ii tdb-tools1.4.3-1+b1 Versions of packages samba recommends: pn attr ii logrotate 3.17.0-2 pn python3-markdown pn samba-dsdb-modules ii samba-vfs-modules 2:4.13.2+dfsg-3 Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb pn ldb-tools pn ntp | chrony pn smbldap-tools pn ufw ii winbind2:4.13.2+dfsg-3 -- no debconf information
Bug#922699: Caja crash when copying paste
Hi. Can you make a patch for Debian 10 stable ? We have Caja 1.20.3 and when I copy/paste a folder to make a clone copy (duplication), caja crashes. I can reproduce this on all my Debian stable computers. It's happen only when the folder contains sub-folders or/and files. Thank you. Maxime.
Bug#976695: vim-ctrlp does not work with packadd!
Package: vim-ctrlp Version: 1.81-1 Severity: important Dear Maintainer, You annunced NEWS. use packadd! but, vim said: E919: ディレクトリが 'packpath' の中にありません: "pack/*/opt/ctrlp" This means vim can't find ctrlp in "pack/*/opt/ctrlp" I have redoed "vam install ctrlp" -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vim-ctrlp depends on: ii neovim 0.4.4-1 ii vim 2:8.2.1913-1+b2 ii vim-gtk3 [vim] 2:8.2.1913-1+b2 ii vim-nox [vim] 2:8.2.1913-1+b2 vim-ctrlp recommends no packages. Versions of packages vim-ctrlp suggests: ii vim-addon-manager 0.5.10 -- no debconf information
Bug#976056: nvidia-legacy-340xx-driver: Fails to build with kernel 5.9.11 (package linux-image-5.9.0-4-amd64)
It was quite disappointing to see (or not see) the GUI/WM stop working after a causal system update (not upGrade). I was able to get the system somewhat back to normal by using the NOUVEAU driver instead of NVIDIA. BTW, even that was kind of tricking because the Nvidia driver blacklisted Nouveau at /etc/modprobe.d/nvidia-blacklists-nouveau.conf which remained even after purging everything related to Nvidia via APT. PS.: For some reason, the laptop no longer revived with Nouveau after a suspend (closing the laptop's lid). That was "bypassed" in the meantime by editing /etc/systemd/logind.conf and replacing all "suspends" with "ignores". Again, that was very disappointing !8-(. What happened with the golden 'Do no harm, don't break users' rule?! On Sun, Dec 6, 2020 at 1:33 PM Paolo Inaudi wrote: > > @jim_p Is it possible for you to avoid putting all system information > and Xorg logs in every message? > It makes the thread very difficult to follow on the online bug tracker. > > I too rolled back to linux-image-5.9.0-3-amd64 which works, hope it > won't be my very last kernel version. > > -- > To unsubscribe, send mail to 976056-unsubscr...@bugs.debian.org.
Bug#976693: Package: installation-reports
Package: installation-reports Boot method: CD Image version: https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-10.6.0-i386-netinst.iso Date: Sun 06 Dec 2020 10:39:27 AM MST Machine: Compaq Pavilion ze4220 Processor: Mobile Intel(R) Celeron(R) CPU 1.70G Memory: 8KiB L2 cache, 1GiB System Memory Partitions: $ df -Tl Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs465008 0465008 0% /dev tmpfs tmpfs961404496 91644 5% /run /dev/sda1 ext4 119193408 3760732 109334964 4% / tmpfs tmpfs 480692 0480692 0% /dev/shm tmpfs tmpfs 5120 4 5116 1% /run/lock tmpfs tmpfs 480692 0480692 0% /sys/fs/cgroup tmpfs tmpfs96136 16 96120 1% /run/user/1000 $ sudo parted GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: ATA CHN-mSATAM3-128 (scsi) Disk /dev/sda: 128GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start EndSizeType File system Flags 1 1049kB 125GB 125GB primary ext4boot 2 125GB 128GB 3488MB extended 5 125GB 128GB 3488MB logical linux-swap(v1) Output of lspci -knn (or lspci -nn): $ sudo lspci -knn 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] RS200 Host Bridge [1002:cab2] (rev 02) Kernel driver in use: agpgart-ati 00:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RS200/RS250 AGP Bridge [1002:7010] 00:02.0 USB controller [0c03]: ULi Electronics Inc. USB 1.1 Controller [10b9:5237] (rev 03) Subsystem: Hewlett-Packard Company USB 1.1 Controller [103c:002a] Kernel driver in use: ohci-pci Kernel modules: ohci_pci 00:06.0 Multimedia audio controller [0401]: ULi Electronics Inc. M5451 PCI AC-Link Controller Audio Device [10b9:5451] (rev 02) Subsystem: Hewlett-Packard Company M5451 PCI AC-Link Controller Audio Device [103c:002a] Kernel driver in use: snd_ali5451 Kernel modules: snd_ali5451 00:07.0 ISA bridge [0601]: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge [Aladdin IV/V/V+] [10b9:1533] Subsystem: ULi Electronics Inc. ALi M1533 Aladdin IV/V ISA Bridge [10b9:1533] Kernel modules: alim1535_wdt, alim7101_wdt 00:08.0 Modem [0703]: ULi Electronics Inc. M5457 AC'97 Modem Controller [10b9:5457] Subsystem: Hewlett-Packard Company M5457 AC'97 Modem Controller [103c:002a] 00:0a.0 CardBus bridge [0607]: O2 Micro, Inc. OZ601/6912/711E0 CardBus/SmartCardBus Controller [1217:6972] Subsystem: Hewlett-Packard Company OZ601/6912/711E0 CardBus/SmartCardBus Controller [103c:002a] Kernel driver in use: yenta_cardbus Kernel modules: yenta_socket 00:10.0 IDE interface [0101]: ULi Electronics Inc. M5229 IDE [10b9:5229] (rev c4) Subsystem: Hewlett-Packard Company M5229 IDE [103c:002a] Kernel driver in use: pata_ali Kernel modules: pata_ali, ata_generic 00:11.0 Bridge [0680]: ULi Electronics Inc. M7101 Power Management Controller [PMU] [10b9:7101] Subsystem: Hewlett-Packard Company M7101 Power Management Controller [PMU] [103c:002a] Kernel driver in use: ali1535_smbus Kernel modules: i2c_ali1535, i2c_ali15x3, alim7101_wdt 00:12.0 Ethernet controller [0200]: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller [100b:0020] Subsystem: Hewlett-Packard Company DP83815 (MacPhyter) Ethernet Controller [103c:002a] Kernel driver in use: natsemi Kernel modules: natsemi 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RS200M [Radeon IGP 330M/340M/345M/350M] [1002:4337] Subsystem: Hewlett-Packard Company RS200M [Radeon IGP 330M/340M/345M/350M] [103c:002a] Kernel driver in use: radeon Kernel modules: radeonfb, radeon 02:00.0 Network controller [0280]: Broadcom Limited BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02) Subsystem: Linksys WPC54G v3 802.11g Wireless-G Notebook Adapter [1737:0048] Kernel driver in use: b43-pci-bridge Kernel modules: ssb Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Format stuck at 33%; console log shows IDE lost interrupt errors; system freezes In the past I have successfully installed Ubuntu 16.04 with a 120GB hard drive on this same system. I
Bug#976692: please enable pytests and autopkgtests
Source: peewee Version: 3.13.1+dfsg-1 Severity: normal Dear Peewee Maintainers, Peewee does not yet run pytests when building, nor non-superficial autopkgtests. At this time I am seeing what appears to be a Peewee-related failure in Vorta: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/peewee.py", line 3057, in execute_sql cursor.execute(sql, params or ()) sqlite3.OperationalError: no such table: eventlogmodel During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/build/1st/vorta-0.7.1/.pybuild/cpython3_3.8_vorta/build/vorta/borg/borg_thread.py", line 236, in run log_entry.save() File "/usr/lib/python3/dist-packages/peewee.py", line 6431, in save rows = self.update(**field_dict).where(self._pk_expr()).execute() File "/usr/lib/python3/dist-packages/peewee.py", line 1845, in inner return method(self, database, *args, **kwargs) File "/usr/lib/python3/dist-packages/peewee.py", line 1916, in execute return self._execute(database) File "/usr/lib/python3/dist-packages/peewee.py", line 2400, in _execute cursor = database.execute(self) File "/usr/lib/python3/dist-packages/peewee.py", line 3070, in execute return self.execute_sql(sql, params, commit=commit) File "/usr/lib/python3/dist-packages/peewee.py", line 3064, in execute_sql self.commit() File "/usr/lib/python3/dist-packages/peewee.py", line 2831, in __exit__ reraise(new_type, new_type(exc_value, *exc_args), traceback) File "/usr/lib/python3/dist-packages/peewee.py", line 183, in reraise raise value.with_traceback(tb) File "/usr/lib/python3/dist-packages/peewee.py", line 3057, in execute_sql cursor.execute(sql, params or ()) peewee.OperationalError: no such table: eventlogmodel https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/vorta_0.7.1-2.rbuild.log.gz Failed builds on other archs do not provide as useful backtraces. Please enable build-time pytests and non-superficial autopkgtests so that it will become clear that the fault is in my package, if the fault is in my package :-) Thank you, Nicholas
Bug#975370: xdg-utils: CVE-2020-27748: local file inclusion vulnerability
On Sunday, November 29, 2020 1:40:17 AM EST Nicholas Guriev wrote: > Proposed change offers to completely remove `attach` parameter. I don't > like to break existing features. It appears that it only removes the attach parameter for Thunderbird in that commit. Perhaps that's because other mail clients handle hidden attachments better. With xdg-email as packaged now KMail does in fact show an extra large warning about a hidden attachment (IIRC they had a related CVE not too long ago), but attachments seem to be visible in Thunderbird in any case. It appears upstream versions of Thunderbird don't respect the ?attach parameter in mailto URIs, but xdg-email parses the URI into Thunderbird-style command-line arguments. These, as given from xdg-email, are considered trusted input and honored, as opposed to if mailto:foo?attach=bar were given to Thunderbird directly. xdg-email's conversion thus causes a misinterpretation of trust by Thunderbird. Thunderbird's intent to not support the ?attach parameter for untrusted clicks from browsers, but still allow non-URI command-line specified attachments seems a reasonable compromise. A solution which might let xdg-email practice the same is to honor the attachment, and convert it to a Thunderbird command-line parameter, if invoked as xdg-email --attach foo mailto:bar but discard it if invoked as xdg-email mailto:bar?attach=foo Indeed this seems to have been the intent from the description of the merge request: https://gitlab.freedesktop.org/xdg/xdg-utils/-/merge_requests/28 It looks like Reportbug's xdg-email backend uses the latter functionality, but it would probably be a trivial change to switch to the --attach form. signature.asc Description: This is a digitally signed message part.
Bug#976691: lambda-align2: build fix for newer glibc
Source: lambda-align2 Version: 2.0.0-8 Severity: important tags: patch Hello, lambda-align2 FTBFS with glibc 2.32, that will probably go in experimental or unstable soon. The following patch seems to fix the issue, due to a deprecated and removed header file --- lambda-align2-2.0.0.orig/src/shared_misc.hpp +++ lambda-align2-2.0.0/src/shared_misc.hpp @@ -26,7 +26,6 @@ #include #include #include -#include #include #include Please have a look and apply if possible. thanks Gianfranco
Bug#976690: ITP: python-strictyaml -- type-safe YAML parser that parses and validates a restricted subset of the YAML specification.
Package: wnpp Severity: wishlist Owner: Romain Porte X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org, debian-pyt...@lists.debian.org * Package name: python-strictyaml Version : 1.1.1 Upstream Author : Colm O'Connor * URL : https://hitchdev.com/strictyaml * License : MIT Programming Lang: Python Description : type-safe YAML parser that parses and validates a restricted subset of the YAML specification. This package is introduced as a dependency for the python-gftools package, that I also intent to package. I intent to mainain this package under the umbrella of the Debian Python Team. signature.asc Description: PGP signature
Bug#968730: fixed in nifticlib 3.0.1-1
control: reopen -1 control: notifxed -1 3.0.1-1 Hello, how can three different binaries provide the very same old -dev library? what happens now is that apt gets the old real cruft binary -dev package, and not the virtual provided one (because it seems to have higher priority). So the rebuilds won't pick up the new library. I think you have multiple ways to solve: 1) restore the old dev package as a binary package that depends on the three new split -dev 2) fix and patch all the reverse dependencies to depend on the right subpackage (or all if they need them all). Or something else I'm not aware right now. G. On Fri, 04 Dec 2020 15:00:41 + Debian FTP Masters wrote: > Source: nifticlib > Source-Version: 3.0.1-1 > Done: Andreas Tille > > We believe that the bug you reported is fixed in the latest version of > nifticlib, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 968...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Andreas Tille (supplier of updated nifticlib package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Tue, 01 Dec 2020 22:17:54 +0100 > Source: nifticlib > Binary: libnifti-doc libnifti2-2 libnifti2-2-dbgsym libnifti2-dev > libnifticdf-dev libnifticdf2 libnifticdf2-dbgsym libniftiio-dev libniftiio2 > libniftiio2-dbgsym libznz-dev libznz3 libznz3-dbgsym nifti-bin > nifti-bin-dbgsym > Architecture: source all amd64 > Version: 3.0.1-1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Med Packaging Team > > Changed-By: Andreas Tille > Description: > libnifti-doc - NIfTI library API documentation > libnifti2-2 - IO libraries for the NIfTI-1 data format > libnifti2-dev - IO libraries for the NIfTI-1 data format (development) > libnifticdf-dev - NIfTI functions to compute cumulative distributions > (development) > libnifticdf2 - NIfTI functions to compute cumulative distributions > libniftiio-dev - development low-level IO libraries for the NIfTI-1 data > format (n > libniftiio2 - low-level IO libraries for the NIfTI-1 data format (niftiio) > libznz-dev - low-level IO library znzlib for the NIfTI-1 data format > libznz3- low-level IO library znzlib for the NIfTI-1 data format > nifti-bin - tools shipped with the NIfTI library > Closes: 968730 > Changes: > nifticlib (3.0.1-1) unstable; urgency=medium > . >* Team upload. >* New upstream version > Closes: #968730 >* Standards-Version: 4.5.1 (routine-update) >* debhelper-compat 13 (routine-update) >* Make source package Section: science >* Separate binary packages for libznz, libniftiio, libnifticdf > Checksums-Sha1: > 4681c06fac5af0e49d0fbca060272c9c5c1b500a 2564 nifticlib_3.0.1-1.dsc
Bug#976689: scribus: Exporting page spread as single page
Package: scribus Version: 1.5.6.1+dfsg-1+b1 Severity: wishlist X-Debbugs-Cc: wiiliamchung...@gmail.com Dear Maintainer, It would be nice to be able to export (2) facing pages as a single PDF spread. Currently, export options only allow for all facing pages to be exported individually. Thanks for the awesome software! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (100, 'experimental'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/24 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages scribus depends on: ii ghostscript 9.52.1~dfsg-1 ii libc62.31-4 ii libcairo21.16.0-4 ii libcdr-0.1-1 0.1.6-2 ii libcups2 2.3.3op1-2 ii libfontconfig1 2.13.1-4.2 ii libfreehand-0.1-10.1.2-3 ii libfreetype6 2.10.2+dfsg-4 ii libgcc-s110.2.0-19 ii libgraphicsmagick-q16-3 1.4+really1.3.35+hg16348-1+b1 ii libharfbuzz-icu0 2.6.7-1 ii libharfbuzz0b2.6.7-1 ii libhunspell-1.7-01.7.0-3 ii libicu67 67.1-4 ii libjpeg62-turbo 1:2.0.5-1.1 ii liblcms2-2 2.9-4+b1 ii libmspub-0.1-1 0.1.4-3+b1 ii libopenscenegraph161 3.6.5+dfsg1-7 ii libopenthreads21 3.6.5+dfsg1-7 ii libpagemaker-0.0-0 0.0.4-1 ii libpng16-16 1.6.37-3 ii libpodofo0.9.6 0.9.6+dfsg-5 ii libpoppler10220.09.0-3 ii libpython3.9 3.9.1~rc1-2 ii libqt5core5a 5.15.1+dfsg-4 ii libqt5gui5 5.15.1+dfsg-4 ii libqt5network5 5.15.1+dfsg-4 ii libqt5opengl55.15.1+dfsg-4 ii libqt5printsupport5 5.15.1+dfsg-4 ii libqt5widgets5 5.15.1+dfsg-4 ii libqt5xml5 5.15.1+dfsg-4 ii libqxp-0.0-0 0.0.2-1+b1 ii librevenge-0.0-0 0.0.4-6+b1 ii libstdc++6 10.2.0-19 ii libtiff5 4.1.0+git191117-2 ii libvisio-0.1-1 0.1.7-1+b1 ii libxml2 2.9.10+dfsg-6.3 ii libzmf-0.0-0 0.0.2-1+b3 ii scribus-data 1.5.6.1+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages scribus recommends: ii cups-bsd2.3.3op1-2 ii fonts-dejavu2.37-2 ii fonts-liberation1:1.07.4-11 ii hyphen-pt-pt [hyphen-hyphenation-patterns] 1:7.0.1-1 ii icc-profiles-free 2.0.1+dfsg-1 ii xfonts-scalable 1:1.0.3-1.1 Versions of packages scribus suggests: pn icc-profiles pn scribus-doc pn scribus-template pn texlive-latex-recommended -- no debconf information
Bug#976675: syncthing-gtk: First-time wizard fails due to a socket-handling syntax-error and 2 python3 encoding-errors
Package: syncthing-gtk
Version: 0.9.4.4+ds+git20200927+d09a2ef-3
Severity: normal
Tags: patch
-- System Information:
Debian Release: bullseye/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages syncthing-gtk depends on:
ii gir1.2-glib-2.01.66.1-1
ii gir1.2-gtk-3.0 3.24.23-2
ii gir1.2-notify-0.7 0.7.9-1
ii gir1.2-rsvg-2.02.50.2+dfsg-1
ii libgtk-3-0 3.24.23-2
ii python33.8.6-1
ii python3-bcrypt 3.1.7-4
ii python3-dateutil 2.8.1-4
ii python3-gi 3.38.0-1+b1
ii python3-gi-cairo 3.38.0-1+b1
Versions of packages syncthing-gtk recommends:
ii gir1.2-appindicator3-0.1 0.4.92-8
ii syncthing 1.10.0~ds1-1
Versions of packages syncthing-gtk suggests:
ii nemo-python 4.6.0-2+b1
-- no debconf information
--- a/usr/lib/python3/dist-packages/syncthing_gtk/wizard.py 2020-09-27 15:20:42.0 +0300
+++ b/usr/lib/python3/dist-packages/syncthing_gtk/wizard.py 2020-11-20 13:10:43.692550279 +0200
@@ -674,7 +674,7 @@
try:
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind((self.parent.syncthing_options["listen_ip"], port))
- s.listen(0.1)
+ s.listen(0)
s.close()
# Good, port is available
self.parent.output_line("syncthing-gtk: chosen port %s" % (port,))
@@ -734,9 +734,9 @@
))
self.ct_textnode(xml, gui, "user", self.parent.syncthing_options["user"])
self.ct_textnode(xml, gui, "password", bcrypt.hashpw(
-self.parent.syncthing_options["password"],
+self.parent.syncthing_options["password"].encode('utf8'),
bcrypt.gensalt()
- ))
+ ).decode('utf8'))
self.ct_textnode(xml, gui, "apikey", self.apikey)
gui.setAttribute("enabled", "true")
gui.setAttribute("tls", "false")
OpenPGP_signature
Description: OpenPGP digital signature
Bug#976138: qmidiarp: died unexpectedly in non/new-session-manager(NSM)
Hello Rooz, Maybe you should try to use the upstream release of the same version and see if the same error occurs in qmidiarp. This would help a lot: If upstream has the same bug, please inform the upstream developer of that bug. If not, One, you, me, ... could investigate more. Thanks, Ben Le 30/11/2020 à 14:15, Benoît Rouits a écrit : Hello, I tried and can confirm with a bit more information: As a workadround, if we close qmidiarp before to quit, the bug is not there. The bug seems to be in qmidiarp when restored by nsm: [...] jack process callback registered Session callback registered [nsmd] ../src/nsmd.cpp:1995 osc_reply(): Client "QMidiArp" replied with: OK in 1044.477000ms [nsmd] ../src/nsmd.cpp:582 wait_for_replies(): Done waiting [nsmd] ../src/nsmd.cpp:1180 tell_all_clients_session_is_loaded(): Telling all clients that session is loaded... [nsmd] ../src/nsmd.cpp:1172 tell_client_session_is_loaded(): Telling client QMidiArp that session is loaded. [nsmd] ../src/nsmd.cpp:1342 load_session_file(): Loaded. [nsmd] ../src/nsmd.cpp:1635 osc_open(): Loaded [nsmd] ../src/nsmd.cpp:1666 osc_open(): Done ASSERT failure in QList::at: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 544 The assertion fails in QMidiArp (which is the sole Qt app). Sad I cannot know more in details. Le 30/11/2020 à 11:17, rooz a écrit : Package: qmidiarp Version: 0.6.5-3 Severity: normal X-Debbugs-Cc: rosea.grammost...@gmail.com Dear Maintainer, Start non-session-manager, add qmidiarp to session. Make a change. Save. Close. Restart session. Client QmidiArp died unexpectedly -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-rt-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qmidiarp depends on: ii libasound2 1.2.3.2-1+b1 ii libc6 2.31-4 ii libgcc-s1 [libgcc1] 10.2.0-16 ii libjack-jackd2-0 [libjack-0.125] 1.9.16~dfsg-1 ii liblo7 0.31-1 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5gui5 5.15.1+dfsg-2 ii libqt5widgets5 5.15.1+dfsg-2 ii libstdc++6 10.2.0-16 Versions of packages qmidiarp recommends: ii jackd 5+nmu1 qmidiarp suggests no packages. -- no debconf information
Bug#976688: updatedb systemd service generates incomplete database
Package: plocate Version: 1.1.1-1 Severity: normal X-Debbugs-Cc: roderich.sch...@gmail.com I noticed that locate doesn't report any files in /usr, e.g. $ locate libx | grep /usr # no output Turns out that databases generated by calling updatedb directly and using the systemd service are different: root@nuc8:~# rm /var/lib/plocate/plocate.db root@nuc8:~# /usr/sbin/updatedb.plocate root@nuc8:~# ls -l /var/lib/plocate/plocate.db -rw-r- 1 root plocate 35532841 Dec 7 00:35 /var/lib/plocate/plocate.db root@nuc8:~# rm /var/lib/plocate/plocate.db root@nuc8:~# systemctl start plocate-updatedb.service root@nuc8:~# ls -l /var/lib/plocate/plocate.db -rw-r- 1 root plocate 32733304 Dec 7 00:37 /var/lib/plocate/plocate.db The culprit seems to be ProtectSystem=full in plocate-updatedb.service. systemd.exec(5) has: ProtectSystem= Takes a boolean argument or the special values "full" or "strict". If true, mounts the /usr/ and the boot loader directories (/boot and /efi) read-only for processes invoked by this unit. If set to "full", the /etc/ directory is mounted read-only, too. Does systemd achieve read-only mounts by using bind-mounts which are pruned by default? Cheers, Roderich -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-rc6 (SMP w/8 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages plocate depends on: ii libc6 2.31-5 ii libgcc-s1 10.2.0-23 ii libstdc++6 10.2.0-23 ii liburing1 0.7-2 ii libzstd11.4.5+dfsg-4 plocate recommends no packages. plocate suggests no packages. -- Configuration Files: /etc/updatedb.conf changed: PRUNE_BIND_MOUNTS="yes" PRUNENAMES=".git .bzr .hg .svn" PRUNEPATHS="/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph" PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.glusterfs fuse.gvfsd-fuse fuse.mfs fuse.rozofs fuse.sshfs fusectl fusesmb hugetlbfs iso9660 lustre lustre_lite mfs mqueue ncpfs nfs nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs sysfs tmpfs tracefs udev udf usbfs" -- no debconf information
Bug#976268: same problem with package from debian repo
Now I reinstalled using the version from Debian repo (it's now in testing). Same problem.
Bug#976235: enlightenment: e switches off screen|monitor
> "Ross" == Ross Vandegrift writes: > [...] - it might be useful to run `xrandr` in > flwm and a bare X session to compare with E's output regarding > your displays. xrandr on flwm and on pure X diff -q 0: LVDS connected primary 1600x900+0+0 (normal left inverted right x axis y axis) 310mm x 174mm 1600x900 59.90*+ 39.93 1440x900 59.99 1280x854 59.95 1280x800 59.96 1280x720 59.97 1152x768 59.95 1024x768 59.95 800x600 59.96 848x480 59.94 720x480 59.94 640x480 59.94 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) DisplayPort-2 disconnected (normal left inverted right x axis y axis) VGA-0 disconnected (normal left inverted right x axis y axis) So all three cases use LVDS and know the precise measurements of my display, just e seems to need something additional which alas is not in the dependency list i suppose. Well, not to clutter up the 976...@bugs.debian.org, i'll try your suggestion upstream. I'll be back if there's some solution. Thx & brgds, e. -- // enno@gmx.net /\\\ Mag. Enno Deimel .\o \\ \ _ \Wisely and slow; they stumble that run fast. \\\ \_/ gpg-fp: eefe b049 6fe6 fc0b 0ec4 f39e af6a c178 eb98 909a
Bug#976267: same with debian package from testing
Now I reinstalled using the version from Debian repo (it's now in testing). Same problem.
Bug#976687: python3-escript: mixing incompatible libpython and libboost_python
Source: python3-escript Version: 5.5-5 Severity: serious Tags: bookworm sid Control: affects -1 python3-escript python3-escript-mpi $ objdump -p /usr/lib/python3-escript/esys/dudley/dudleycpp.so | grep python /usr/lib/python3-escript/esys/dudley/dudleycpp.so: file format elf64-x86-64 NEEDED libpython3.9.so.1.0 NEEDED libboost_python38.so.1.71.0 $ This is now no longer a problem for bullseye, but will again pop up during python3 transitions for bookworm.
Bug#976686: glom: mixing incompatible libpython and libboost_python
Source: glom Version: 1.30.4-6.1 Severity: serious Tags: bookworm sid Control: affects -1 glom libglom-1.30-0 $ objdump -p /usr/bin/glom | grep python NEEDED libpython3.9.so.1.0 NEEDED libboost_python38.so.1.71.0 $ This is now no longer a problem for bullseye, but will again pop up during python3 transitions for bookworm.
Bug#970631: Pitch bend of Calf Fluidsynth plugin does not work except on channel 1
The patch has been merged to upstream. So this bug can be closed if the package is updated by the upstream after 2020-11-7. https://github.com/calf-studio-gear/calf/commit/083b7497a8429fe9f1e12e1b53fae439c21414e4
Bug#976685: dash -x output seems broken
Hi, The bug is not specific to -x option, it's just a handy method to see what's going on. The same happens without -x, e.g. bash$ dash -c 'echo /// "///"' /// // The bug was discovered by strace test suite.
Bug#976620: xlrd: if defusedxml installed, AttributeError: 'ElementTree' object has no attribute 'getiterator'
Control: severity -1 serious Control: affects -1 pandas This breaks the default form of pandas.read_excel(). A workaround for this is to use pandas.read_excel(engine='openpyxl'), and pandas upstream have made this the default: https://github.com/pandas-dev/pandas/pull/35029/files I intend to make that default change in Debian pandas, but xlrd is still needed for reading old (.xls) files, and may be preferred for reading large numbers of files (it can be ~10x faster).
Bug#976685: dash -x output seems broken
Package: dash Version: 0.5.11+git20200708+dd9ef66-2 Severity: important Hi, Reporting this on behalf of the upstream strace developers. They've noticed this bug, and I can confirm. It looks like the new version of dash is giving incorrect output when called with -x. Older version in buster: $ dash -x -c 'true ///; true "///"' + true /// + true /// (and bash does the same) Using version 0.5.11+git20200708+dd9ef66-2 (in a sid chroot here): (sid)steve@tack:~$ dash -x -c 'true ///; true "///"' + true /// + true // -- System Information: Debian Release: 10.7 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dash depends on: ii debconf [debconf-2.0] 1.5.71 ii debianutils4.8.6.1 ii dpkg 1.19.7 ii libc6 2.28-10 dash recommends no packages. dash suggests no packages. -- debconf information excluded
Bug#976573: pandas: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.8 3.9" returned exit code 13
On 05/12/20 at 13:47 +0100, Lucas Nussbaum wrote: Tags: bullseye sid ftbfs Usertags: ftbfs-20201205 ftbfs-bullseye Does this imply that it was also tested and failed in bullseye? The log is marked unstable, and the test failures in it are #976620, which is probably unstable-only.
Bug#976679: commons-io: Fails to delete a symlink pointing to a non-existing file
Le 06/12/2020 à 22:39, Pierre Gruet a écrit : > This issue is well-documented on the Apache issue tracker [0] and I'm > proposing the enclosed patch by Bernd Rinn to get around it in version 2.8.0. The patch looks good. I'll try to get it applied upstream. Emmanuel Bourg
Bug#976683: xfsprogs: Import new upstream version
Source: xfsprogs Version: xfsprogs/5.6.0-1 Severity: important Hi, Please update the package to a new upstream version, preferrably the latest 5.9.0. As 5.7.0 removed libreadline support, this will imply building with libedit as filed in #695875. Thanks, Bastian
Bug#976682: node-jest: please provide real (not virtual) package node-natural-compare
Source: node-jest Version: 26.6.3+repack+~cs61.38.31-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 eslint will soon depend on node-natural-compare, which is currently a virtual package provided by jest. That means eslint and all its consumers, many of which do not need jest, will with the current setup grow a dependency of jest and its large set of dependencies. Please consider providing node-natural-compare as a real binary package, either from src:node-jest as now, but preferrably (to also reduce _build-dependency_ tree) provided by some other source package with much much lower dependency tree - ideally a package using same type of build-dependencies as itself (i.e. _not_ mocha or jest or babel or rollup or terser). Thanks for considering, - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/NVYsACgkQLHwxRsGg ASFC6A/9FTuzJjrSVIBEYxzqGUfJcaZUF2ppptYwy0xnTNEq29UGGfc1jezDd8jK 9Bvo6Aix1sDfqIh9/ehLkL3ZaLb7yHYbDNGHI+AaHX7eqg7IDqRor2tMoRSvpTyQ N6v3INGrr0pmjG7cu/Xe6t9TwNPYUtFkrItpTt7H9hxZewTmGG7pL5w7a9d5Fkf7 VxYOqyHAMibTbR1LddFy3hkenV43M7A3zdEfjBOmdVa/fXacxiafBQFF2iICzm7O MViDUMUjEKLhNEgLfpiIvraBC8eLJTvb5IsZu6Rs+BchEZF7GYmznXR3Tokyn/WS uCK1B+MuY7jYSqZB1C+T0KrviAhID2OmB8+teoY2n7jwIb/sc44bjrNjdLT4jzVp 3QWQnR3OkI523OdD8xSPBHit2llnY1n5BDhvETZa3Rey+13kYFPyt3B061aTKNyY RYZKpJgYLj+eUUlYkgmRtX1DgKAzfntySDvXAi1YNiZ3mpVWdRALGyiLTF0aFZVV lMVrNsdLtP2cy/m0Bm6FapwTkJmsnMOQ2YIRPakxeO16NXUUwqL1ujVr04NTi1U3 2/6+0h9/WCyB1sWswbCO7syo85nD/OaQ12q7wVcVBOhgmQzkblm9l1QniNiNRH4o qnNbfbI9Io4aDp8KWG1F9KK5FZzfngBuIxHxoqgXYt2Y8L7GOio= =Ia78 -END PGP SIGNATURE-
Bug#854580: enable giving killall an old fashioned process ID too!
B> Hi, B> Your bug report said you were looking for a kill program that kills the process group. Using a negative pid for things like kill will do this. killall is all about the name or commands, not the B> process id. (OK, but if killall could also just take PIDs, then one could enjoy e.g., --interactive, etc. fun features, over just plain kill(1).)
Bug#976681: bad-jar-name: false positive for version numbers with a tilde
Package: lintian Version: 2.104.0 Severity: normal Dear Lintian maintainers, Java policy requires [0] that the package libXXX-java installs a jar named XXX[-extraname]-fullversion.jar into /usr/share/java, where extraname is optional and fullversion is the version of the jar file. I suspect Lintian raises a false positive when there is a tilde in the version: I met this issue with - libsis-base-java version 18.09~pre1+git20180928.45fbd31, of which jar is named sis-base-18.09~pre1+git20180928.45fbd31.jar; - libpj-java version 0.0~20150107, of which jar is named pj-0.0~20150107.jar (I have overridden the warning); - libjsr305-java version 0.1~+svn49, of which jar is named jsr305-0.1~+svn49.jar . Thanks for considering and for all the work done on Lintian, Pierre Gruet [0] https://www.debian.org/doc/packaging-manuals/java-policy/ch02.html
Bug#976658: debcargo is broken (and the autopkgtest didn't catch it).
debcargo (and cargo) is out of date in Debian and needs to be updated. We had been blocked on the FTP binary-NEW policy but there is some progress in that area. Alternatively you could use collapse_features to begin to update it, but I personally do not approve of it and haven't been spending time on it. X peter green: > Package: debcargo > Version: 2.4.3-2+bw > Severity: grave > > After the recent binnmu of debcargo. debcargo update > (after deleting the cache) gives. > >> >> Updating crates.io index >> Something failed: failed to fetch >> `https://github.com/rust-lang/crates.io-index` >> >> Caused by: >> invalid version 0 on git_proxy_options; class=Invalid (3) > > This issue was not caught by the autopkgtest. > > In order to check this was indeed caused by the libgit2 update (and not by > one of the > other updates that have happened since the last debcargo build in unstable) I > did a > test build with libgit2-dev from testing but everything else from unstable. > That > test build worked fine. > > I suspect rust-git2/rust-libgit2-sys need to be updated to match the new > libgit2. > > I've got to go now, but I'll try look into this issue some more later tonight. > -- GPG: ed25519/56034877E1F87C35 https://github.com/infinity0/pubkeys.git
Bug#969631: can base-passwd provide the user _apt?
On Sun, Sep 06, 2020 at 09:48:26AM +0200, Helmut Grohne wrote: > Package: base-passwd > Version: 3.5.47 > Severity: wishlist > > Hi Colin, > > I was again looking into how essential could be trimmed further and I > stumbled into adduser. Technically, adduser is not transitively > essential. However, apt (which isn't essential) currently depends on > adduser. I consider apt essential for any practical purpose though, so > I'd argue that adduser is kinda defacto essential. > > So if we want to remove adduser from a minimal installation, we'd have > apt stop depending on it. Now apt uses it for the obvious thing: adding > an _apt user. Given that this user will be present on practically all > Debian systems, what would you think about adding _apt to base-passwd? +1 from my side. > > The adduser package has an installed size of 849KB. This is about 1% of > an essential chroot (depending on how far you trim it by other means). > > Doing so is not entirely trivial though. _apt is already present on > Debian systems and it owns at least /var/cache/apt/archives/partial. > Changing the uid to a static allocation may be impossible. On the other > hand, libapt always chowns it to _apt, so maybe changing the uid is > indeed harmless. I've Cced deity to get an answer here. I'm mostly just worried about users using file:/ or copy:/ methods and having given _apt access to them, they'd break. I think it'd be best if we don't change existing _apt users, but only dealt with new systems for now. I mean we could prompt users about changing the uid > > Then technically, we'd add _apt to base-passwd and make apt.postinst > skip the adduser call if _apt is present. apt can then "Depends: > base-passwd (>= ...) | adduser" and have a smooth transition. > > A possible risk of this change is that other packages will suddenly > become rc-buggy for missing a dependency on adduser as adduser is > presently defacto essential. They are RC-buggy already. There are real systems not using apt; e.g. people build application containers where they remove apt in the final step. > > Another benefit of this change (if a static uid is allocated) is that we > improve reproducible installations where currently uids may depend on > configuration order. +1 -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#976679: commons-io: Fails to delete a symlink pointing to a non-existing file
Source: commons-io
Version: 2.8.0
Severity: normal
Tags: patch
Hi,
Since version 2.8.0, commons-io fails at deleting a symlink when it points to
nothing. Such situation was met in some tests of libsis-base-java (temporarily
deactivated in order to face this issue), leading to bug #976490.
This issue is well-documented on the Apache issue tracker [0] and I'm proposing
the enclosed patch by Bernd Rinn to get around it in version 2.8.0.
Bye,
Pierre
[0] https://issues.apache.org/jira/browse/IO-692
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (90, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- org/apache/commons/io/file/PathUtils.java.orig 2020-01-22
15:10:16.0 +0100
+++ org/apache/commons/io/file/PathUtils.java 2020-10-28 21:32:24.874024999
+0100
@@ -358,7 +358,8 @@
}
final PathCounters pathCounts = Counters.longPathCounters();
final boolean exists = Files.exists(file, LinkOption.NOFOLLOW_LINKS);
-final long size = exists ? Files.size(file) : 0;
+final boolean existsFollowLink = Files.exists(file);
+final long size = existsFollowLink ? Files.size(file) : 0;
if (overrideReadOnly(options) && exists) {
setReadOnly(file, false, LinkOption.NOFOLLOW_LINKS);
}
Bug#976678: dstat: upgrade warnings when upgrading from python3.8 to python3.9
Package: dstat
Version: 0.7.4-6
Python 3.9 just migrated to testing yesterday. When I did a
dist-upgrade on my testing machine, I saw the following warnings that
originated from dstat:
Setting up libglib2.0-bin (2.66.3-2) ...
Setting up python3 (3.9.0-3) ...
running python rtupdate hooks for python3.9...
/usr/share/dstat/dstat_mysql_keys.py:41: SyntaxWarning: 'str' object is not
callable; perhaps you missed a comma?
if op.debug > 1: print('%s: exception' (self.filename, e))
/usr/share/dstat/dstat_squid.py:48: SyntaxWarning: 'str' object is not
callable; perhaps you missed a comma?
if op.debug > 1: print('%s: exception' (self.filename, e))
running python post-rtupdate hooks for python3.9...
Setting up libwbclient0:amd64 (2:4.13.2+dfsg-3) ...
It looks to me like you're missing a '%' in both of those print statements:
--- /usr/share/dstat/dstat_squid.py.orig2020-12-06 16:24:39.563332096
-0500
+++ /usr/share/dstat/dstat_squid.py 2020-12-06 16:25:02.959555941 -0500
@@ -45,7 +45,7 @@
if op.debug > 1: print('%s: lost pipe to squidclient, %s' %
(self.filename, e))
for name in self.vars: self.val[name] = -1
except Exception as e:
-if op.debug > 1: print('%s: exception' (self.filename, e))
+if op.debug > 1: print('%s: exception' % (self.filename, e))
for name in self.vars: self.val[name] = -1
# vim:ts=4:sw=4:et
--- /usr/share/dstat/dstat_mysql_keys.py.orig 2020-12-06 16:24:48.231415192
-0500
+++ /usr/share/dstat/dstat_mysql_keys.py2020-12-06 16:25:22.959746212
-0500
@@ -38,7 +38,7 @@
for name in self.vars: self.val[name] = -1
except Exception as e:
-if op.debug > 1: print('%s: exception' (self.filename, e))
+if op.debug > 1: print('%s: exception' % (self.filename, e))
for name in self.vars: self.val[name] = -1
# vim:ts=4:sw=4:et
Bug#976677: gdk-pixbuf-xlib: is deprecated
Source: gdk-pixbuf-xlib Version: 2.40.2-2 Severity: important Tags: confirmed upstream wontfix gdk-pixbuf-xlib has been deprecated by its upstream developer. The README says: No newly written code should ever use this library. If your existing code depends on gdk-pixbuf-xlib, then you're strongly encouraged to port away from it. This deprecation applies to and the gdk-pixbuf-xlib-2.0 pkg-config module, which means the libgdk-pixbuf-xlib-2.0-dev and libgdk-pixbuf-xlib-2.0-0 Debian packages. See https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib for more details. The Debian GNOME team plans to release gdk-pixbuf-xlib in Debian 11 'bullseye' (expected in mid 2021), but it will not necessarily be released in Debian 12 (expected in 2023). We also want to phase out the libgdk-pixbuf2.0-0 and libgdk-pixbuf2.0-dev transitional packages at some point. Again, we intend to release them in Debian 11, but hopefully not in Debian 12. There will probably be a mass-bug-filing for packages that depend on the transitional packages. To replace those transitional packages, packages that depend on the main gdk-pixbuf library (the gdk-pixbuf source package) should (build-)depend on libgdk-pixbuf-2.0-dev, libgdk-pixbuf-2.0-0 or gir1.2-gdkpixbuf-2.0, whichever is appropriate. Packages that depend on this deprecated Xlib integration should additionally (build-)depend on libgdk-pixbuf-xlib-2.0-dev or libgdk-pixbuf-xlib-2.0-0. smcv
Bug#976646: [Pkg-julia-devel] Bug#976646: julia: FTBFS on armhf
On 2020-12-07 05:36:58 +0900, Norbert Preining wrote: > Hi, > > thanks for the report, but that is really a porter/builder box problem: > > > | LLVM ERROR: out of memory > > Seems the machine couldn't deal with the required amount ( which is > considerable from my experience). > > I don't know what **we** can do here ... One could try the usual approaches of reducing the debug symbols to -g1 or optimization to -O1. And it's not usually the case the this is an actual out of memory issue, but a process that requires more than the mappable amount of memory. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#954270: [RFS] kmc: arm64 autopkgtest time out
Control: tag -1 + confirmed Control: tag -1 - unreproducible Hi Paul, Paul Gevers, on 2020-12-06 20:54:43 +0100: > It recently started to time out on amd64 too, but not always [1]. And > when we added armhf, that timed out too. The failures on amd64 that I > checked were all on ci-worker13, which is one of our hosts that runs > multiple debci-workers. That's common on our arm64 workers too. > [1] https://ci.debian.net/packages/k/kmc/testing/amd64/ Thanks for the pointers, I believe I found a reproducer! :) All failing CI runners all had in common a high NR_CPUS count, at least 32 cores. I don't have 32 cores at hand, but kmc provides an option -t to increase the parallelization. The following command, in the conditions of the autopkgtest, will hang on any machines: $ kmc -ci1 -m1 -k28 -t32 $ORIGDIR/debian/tests/sample_6.fastq.gz 1 . strace output looks like the program just deadlocks, I see no CPU consumption while the command is supposed to be running: strace: Process 3001579 attached with 23 threads [pid 3001633] futex(0x55b69bf9cb70, FUTEX_WAIT_PRIVATE, 0, NULL [pid 3001632] futex(0x55b69bf9cb70, FUTEX_WAIT_PRIVATE, 0, NULL [...] [pid 3001612] futex(0x55b69bf9cb70, FUTEX_WAIT_PRIVATE, 0, NULL [pid 3001579] futex(0x55b69bf9ce18, FUTEX_WAIT_PRIVATE, 0, NULL I suppose easy solution would be to cap the cores count of the program while working with upstream to find a proper fix. Will see what can be done about it. Have a good evening, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Bug#957468: Can this be closed?
Can BTS #957468 be closed? -- Brian T. Smith System Fabric Works Senior Principal Engineer bsm...@systemfabricworks.com GPG Key: 0xB3C2C7B73BA3CD7F
Bug#975617: ITA: libssh2
OpenPGP_0xFE82139440BD22B9.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#976676: RFS: python-absl/0.11.0-1 [ITP] -- Abseil Python Common Libraries
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-absl": * Package name: python-absl Version : 0.11.0-1 Upstream Author : Yilei Yang * URL : https://github.com/abseil/abseil-py * License : Apache-2 * Vcs : https://salsa.debian.org/python-team/packages/python-absl Section : python It builds those binary packages: python3-absl - Abseil Python Common Libraries To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-absl/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-absl/python-absl_0.11.0-1.dsc Changes for the initial release: python-absl (0.11.0-1) unstable; urgency=medium . * Initial release. (Closes: #975675) Regards, -- Romain Porte signature.asc Description: PGP signature
Bug#973712: Depends on argyll which is going away
Hi, On Fri, 6 Nov 2020 03:28:53 +0100 Guillem Jover wrote: > On Tue, 2020-11-03 at 19:32:03 +0100, Moritz Muehlenhoff wrote: > > argyll is filed for removal from the archive (#966416), but > > colord-sensor-argyll > > depends on it. > > The RC bugs filed against argyll have all been fixed now. And due to the FTBFS on s390x, the package is still around on s390x, so can be added again without a trip through NEW IIUC. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#923481: alpine: replies lose In-Reply-To and References headers
Package: alpine Version: 2.24+dfsg1-1 Followup-For: Bug #923481 X-Debbugs-Cc: t...@mirbsd.de This bug still persists. This caused loss of connection between a mailing list thread and a debbugs entry. This is becoming really annoying. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages alpine depends on: ii libc6 2.31-5 ii libcrypt1 1:4.4.17-1 ii libgssapi-krb5-2 1.18.3-4 ii libkrb5-3 1.18.3-4 ii libldap-2.4-2 2.4.56+dfsg-1 ii libssl1.1 1.1.1h-1 ii libtinfo6 6.2+20201114-1 ii mlock 8:2007f~dfsg-7+b1 Versions of packages alpine recommends: pn alpine-doc ii sensible-utils 0.0.12+nmu1 Versions of packages alpine suggests: ii aspell 0.60.8-1 ii postfix [mail-transport-agent] 3.5.6-1 -- no debconf information
Bug#976646: [Pkg-julia-devel] Bug#976646: julia: FTBFS on armhf
Hi, thanks for the report, but that is really a porter/builder box problem: > | LLVM ERROR: out of memory Seems the machine couldn't deal with the required amount ( which is considerable from my experience). I don't know what **we** can do here ... Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem
Am Sonntag, den 06.12.2020, 19:28 +0100 schrieb Michael Biebl: > Am 06.12.20 um 17:04 schrieb Josh Jones: > > It is the root filesystem which is failing to be remounted read- > > only - > > this is a simple setup with only one filesystem for the whole > > system. > > > > It seems to be happening right at the very very end of the shutdown > > sequence - I have attached a picture of the error; quality is poor > > because I had to capture it from video footage. Is there any way to > > even have anything saved to disk so late in the sequence? > > With the shutdown hook described in README.Debian and > https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 > (install the hook as /lib/systemd/system-shutdown/debug.sh without > the > /usr prefix) you can gather logs right until the end > > Copy the attached script to /lib/systemd/system-shutdown/, make it executable with chmod +x, then add systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M to the kernel command line and after the reboot, attach the file /shutdown-log.txt to this bug report. Michael debug.sh Description: application/shellscript signature.asc Description: This is a digitally signed message part
Bug#925775: mediastreamer2: ftbfs with GCC-9
Dear VOIP-team, On Wed, 27 Mar 2019 19:47:03 + Matthias Klose wrote: > The package fails to build in a test rebuild on at least amd64 with > gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. Do you intent to fix this in unstable soon too? The freeze is getting closer and we'd like to have this fixed in bullseye too. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#963424: sensible-utils: FTBFS: po4a::po: Invalid value for option 'porefs' ('noline,wrap' is not one of 'full', 'counter', 'noline', 'file' or 'never')
Hi Anibal, On Sun, 21 Jun 2020 22:34:58 +0200 Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. Do you intent to fix this in unstable soon too? The freeze is getting close and we'd like to have this fixed in bullseye. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#976056: nvidia-legacy-340xx-driver: Fails to build with kernel 5.9.11 (package linux-image-5.9.0-4-amd64)
@jim_p Is it possible for you to avoid putting all system information and Xorg logs in every message? It makes the thread very difficult to follow on the online bug tracker. I too rolled back to linux-image-5.9.0-3-amd64 which works, hope it won't be my very last kernel version.
Bug#925818: rocksdb: ftbfs with GCC-9
Dear Laszlo, On Wed, 27 Mar 2019 19:47:52 + Matthias Klose wrote: > The package fails to build in a test rebuild on at least amd64 with > gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. Do you intend to fix this soon in unstable too? The freeze of bullseye is near and we'd want to have this bug fixed. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#954270: [RFS] kmc: arm64 autopkgtest time out
Control: severity -1 serious Hi Étielle, On 06-12-2020 19:31, Étienne Mollier wrote: > I tried to trigger the kmc bug #954270 from an autopkgtest run > within a qemu-user arm64 machine (host amd64). Unfortunately, I > failed to reproduce any freeze; the run executes in a matter of > a minute or two. I don't see any changes that would visibly > affect the test succeptibility to freeze since the release of > the affected version of the package. It recently started to time out on amd64 too, but not always [1]. And when we added armhf, that timed out too. The failures on amd64 that I checked were all on ci-worker13, which is one of our hosts that runs multiple debci-workers. That's common on our arm64 workers too. > Is it possible that such freeze could be hardware dependent > somehow? (I'm thinking CPU extensions, or maybe parallelization > levels.) Of course, everything is possible. Paul [1] https://ci.debian.net/packages/k/kmc/testing/amd64/ OpenPGP_signature Description: OpenPGP digital signature
Bug#976674: RFS: menu-cache/1.1.0-1.1 [NMU] [RC] -- LXDE implementation of the freedesktop Menu's cache (libexec)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "menu-cache": * Package name: menu-cache Version : 1.1.0-1.1 Upstream Author : lxde-l...@lists.sourceforge.net * URL : http://www.lxde.org/ * License : LGPL-2.1+ * Vcs : https://git.lxde.org/gitweb/?p=debian/menu-cache.git Section : libs It builds those binary packages: libmenu-cache3 - LXDE implementation of the freedesktop Menu's cache libmenu-cache-dev - LXDE implementation of the freedesktop Menu's cache (devel) libmenu-cache-doc - LXDE implementation of the freedesktop Menu's cache (docs) libmenu-cache-bin - LXDE implementation of the freedesktop Menu's cache (libexec) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/menu-cache/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/menu-cache/menu-cache_1.1.0-1.1.dsc Changes since the last upload: menu-cache (1.1.0-1.1) unstable; urgency=medium . * Non-maintainer upload. * Take from Fedora patch for fix FTBFS with gcc-10. (Closes: #957533) Regards, -- Mateusz Łukasik
Bug#976095: linux-image-amd64: kernel crash refcount_t: underflow; use-after-free.
I just tested 5.9.6-1~bpo10+1 from buster-backports and it seems to work, thanks ! On Thu, Dec 3, 2020 at 11:33 PM Salvatore Bonaccorso wrote: > Hi Xavier, > > On Sun, Nov 29, 2020 at 06:32:36PM +0100, Xavier Chantry wrote: > > Package: linux-image-amd64 > > Version: 5.8.10-1~bpo10+1 > > Severity: important > > > > Version 5.8.10-1~bpo10+1 contains a critical bug that completely freezes > the > > system with a very basic LibreOffice usage. > > This is apparently fixed here : > > https://www.mail-archive.com/nouveau@lists.freedesktop.org/msg36460.html > > > > This patch appears in debian linux 5.9.9-1, so we are just waiting for a > > backport in buster-backports to confirm the fix. > > Can you fetch the package from testing to confirm it fixes the issue > you are seeing so we can adjust the bug metadata accordingly? > > Regards, > Salvatore >
Bug#976218: file breaks nagios-plugins-contrib autopkgtest: SSL_CERT UNKNOWN www.debian.org: Unable to fetch a valid certificate issuer certificate.
Control: tags 976218 fixed-upstream Paul Gevers wrote... > So, let's reassign appropriately. This was fixed¹ in upstream release 1.119.0, and I'll start preparing a NMU now. FWIW, upstream is already at version 1.124.0 while Debian unstable is at 1.98.0. Christoph ¹ https://github.com/matteocorti/check_ssl_cert/commit/99673c345ebf85d643abcc51022aec76af4a signature.asc Description: PGP signature
Bug#976673: dget: DEB822-style .sources files unsupported
Package: devscripts Version: 2.19.5+deb10u1 File: /usr/bin/dget dget isn't able to download any packages given a package name on my system: $ dget devscripts no repository found in /etc/apt/sources.list or sources.list.d at /usr/bin/dget line 378. It seems that the problem is that dget only supports one-line-style sources.list files, and not multi-line DEB822-style .sources files (the manpage sources.list(5) describes both formats).
Bug#976573: pandas: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.8 3.9" returned exit code 13
Hi, On 06/12/20 at 18:39 +, Rebecca N. Palmer wrote: > On 05/12/20 at 13:47 +0100, Lucas Nussbaum wrote: > > Tags: bullseye sid ftbfs > > Usertags: ftbfs-20201205 ftbfs-bullseye > > Does this imply that it was also tested and failed in bullseye? The log is > marked unstable, and the test failures in it are #976620, which is probably > unstable-only. I only tested on unstable, yes. (I tag bullseye+sid as a way to say "does not affect stable") Lucas
Bug#976672: acm: Improve package description
Package: acm
Version: 6.0+20200416-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Dear Maintainer,
We've been carrying a delta for a while to improve acm's package
description. Could you please consider merging it?
Thanks for considering the patch.
Logan
-- System Information:
Debian Release: bullseye/sid
APT prefers groovy-updates
APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 'groovy')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.128-microsoft-standard (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru acm-6.0+20200416/debian/control acm-6.0+20200416/debian/control
--- acm-6.0+20200416/debian/control 2020-11-17 06:52:56.0 -0500
+++ acm-6.0+20200416/debian/control 2020-12-06 14:13:50.0 -0500
@@ -9,16 +9,26 @@
Package: acm
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, tk
-Description: Multi-player classic aerial combat simulation
- A multiplayer aerial combat simulation. Players engage in air to air
+Description: Multi-player classic air combat simulator
+ A multi-player aerial combat simulation. Players engage in air to air
combat against one another using heat seeking missiles and cannons.
.
Main features include:
* Simulation with 6 degrees of freedom.
+ * Tricycle and bicycle landing gear simulation.
* Structural limit to the vertical positive/negative load.
- * Classic instruments, navigation and head-up display (HUD).
+ * Standard atmosphere.
+ * Weather: daylight/night, fog, wind.
+ * Classic instruments, including magnetic compass, turn and slip
+indicator, airspeed indicator, attitude and bank indicator,
+altitude indicator, vertical speed indicator.
+ * Navigation: HSI with RNAV calculator, ADF.
+ * Head-up display (HUD) and inertial reference system.
+ * Auto-pilots: hold altitude, hold climb rate, hold speed, follow VOR
+radial, follow ILS glide path, rudder/ailerons coordination.
* Several aircraft models implemented, both civil and military.
- * Two scenes provided, with many runways and radio stations.
+ * Two sceneries provided: Dallas area (Texas) and Italy area with
+hundreds of runways and radio stations.
.
acm runs under the X window system. This version of acm is
implemented as a distributed simulation. It communicates information
Bug#954270: [RFS] kmc: arm64 autopkgtest time out
Control: tag -1 + unreproducible Hi there, I tried to trigger the kmc bug #954270 from an autopkgtest run within a qemu-user arm64 machine (host amd64). Unfortunately, I failed to reproduce any freeze; the run executes in a matter of a minute or two. I don't see any changes that would visibly affect the test succeptibility to freeze since the release of the affected version of the package. Is it possible that such freeze could be hardware dependent somehow? (I'm thinking CPU extensions, or maybe parallelization levels.) For information, I made the autopkgtest run a wee bit more verbose and made a small refresh of the package while I was at it: https://salsa.debian.org/med-team/kmc I marked the package ready for upload to see if such issue could reoccur on CI infrastructure. Note that it would need sponsored upload. Kind Regards, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Bug#976671: grub: Funny characters appended to file names in `/boot/grub/i386-pc`
Package: grub-pc
Version: 2.04-10
Severity: important
Dear Debian folks,
This creates a bug report for the issue below, first reported to
linux-e...@vger.kernel.org.
Am 06.12.20 um 15:44 schrieb Colin Watson:
On Sat, Dec 05, 2020 at 08:34:34PM +0100, Paul Menzel wrote:
[Cc: +Colin]
Also CCing Dimitri, whose GRUB patch this may be related to. Dimitri,
see https://marc.info/?l=linux-ext4=160719695914303=2 for the full
message I'm replying to.
Am 04.12.20 um 19:05 schrieb Theodore Y. Ts'o:
On Fri, Dec 04, 2020 at 04:39:12PM +0100, Paul Menzel wrote:
Colin, the modules in `/boot/grub/i386-pc` look funny, and can’t be loaded
by GRUB anymore.
```
$ ls -lt /boot/grub/i386-pc/
insgesamt 2085
-rw-r--r-- 1 root root512 13. Aug 23:00 'boot.img-'$'\205\300''u'$'
\023\211''鍓]'$'\206\371\377\211\360\350''f'$'\376\377\377\205
\300''ur'$'\203\354\004''V'$'\377''t$'$'\030''j'$'\002''胒'
-rw-r--r-- 1 root root 30893 13. Aug 23:00 'core.img-'$'\205\300''u'$'
\023\211''鍓]'$'\206\371\377\211\360\350''f'$'\376\377\377\205
\300''ur'$'\203\354\004''V'$'\377''t$'$'\030''j'$'\002''胒'
[…]
```
[...]
When was the last time the directory was OK? Do you know when it may
have gotten corrupted?
The last reboot before. But I am really confused now though.
$ ls -ld /boot/grub/i386-pc
drwxr-xr-x 2 root root 28672 29. Nov 12:13 /boot/grub/i386-pc
But the module files in there are all from August 2020.
-rw-r--r-- 1 root root 2400 Aug 13 23:00
'part_gpt.mod-'$'\205\300''u'$'\023\211\351\215\223'']'$'\206\371\377\211\360\350''f'$'\376\377\377\205\300''ur'$'\203\354\004''V'$'\377''t$'$'\030''j'$'\002\350\203\222'
The characters in the file name look like some character encoding. Do you
know hat that is? UTF-8? The dumped output viewed in an editor shows a
“Asian” looking characters 胒.
It seems rather more likely to be junk from uninitialised memory.
2020-11-29 11:38:06 upgrade grub2-common:i386 2.04-9 2.04-10
[…]
2020-11-29 12:04:00 status installed linux-image-5.9.0-4-686-pae:i386
5.9.11-1
[…]
2020-11-29 12:13:24 configure grub-pc:i386 2.04-10
2020-11-29 12:13:24 status unpacked grub-pc:i386 2.04-10
2020-11-29 12:13:24 status half-configured grub-pc:i386 2.04-10
[Dialog waited for my confirmation: Some GRUB warning regarding block
devices, which I always “ignore”, that means tell GRUB to be upgraded]
You need to actually look into this and fix it properly rather than
ignoring it. It's probably related to this problem, since a successful
installation doesn't go down the RESTORE_BACKUP path which I think is
the suspicious one here.
2020-11-29 12:43:21 status installed grub-pc:i386 2.04-10
[…]
So, afterward I was able to reboot without any issues.
[...]
Do you want me to re-install grub to see if it’s a problem introduced in
Debian’s GRUB 2.04-10?
Now that I look at it more closely, some of the changes to
clean_grub_dir_real look suspicious:
+ char *srcf = grub_util_path_concat (2, di, de->d_name);
+
+ if (mode == CREATE_BACKUP)
+ {
+ char *dstf = grub_util_path_concat_ext (2, di, de->d_name, "-");
+ if (grub_util_rename (srcf, dstf) < 0)
+ grub_util_error (_("cannot backup `%s': %s"), srcf,
+grub_util_fd_strerror ());
+ free (dstf);
+ }
+ else if (mode == RESTORE_BACKUP)
+ {
+ char *dstf = grub_util_path_concat_ext (2, di, de->d_name);
+ dstf[strlen (dstf) - 1] = 0;
+ if (grub_util_rename (srcf, dstf) < 0)
+ grub_util_error (_("cannot restore `%s': %s"), dstf,
+grub_util_fd_strerror ());
+ free (dstf);
+ }
+ else
+ {
+ if (grub_util_unlink (srcf) < 0)
+ grub_util_error (_("cannot delete `%s': %s"), srcf,
+grub_util_fd_strerror ());
+ }
+ free (srcf);
grub_util_path_concat is a helper that joins its arguments with "/";
grub_util_path_concat_ext does likewise except the last argument is
appended as an extension without first appending "/". The first
argument to both of these functions is "n": grub_util_path_concat
expects n further argument, while grub_util_path_concat_ext expects n +
1 further arguments.
So, in the RESTORE_BACKUP case, shouldn't that be:
char *dstf = grub_util_path_concat (2, di, de->d_name);
... rather than grub_util_path_concat_ext? Otherwise it seems to me
that it's going to try to append an additional argument which doesn't
exist, and may well add random uninitialised stuff from memory. Running
grub-install under valgrind would probably show this up (I can't get it
to do it for me so far, but most likely I just haven't set up quite the
right initial conditions).
This looks more likely to be a userspace problem rather than filesystem
corruption. I think this should likely be
Bug#976670: libdvdread: README.css should mention the libdvd-pkg package
Source: libdvdread Version: 6.1.1-2 Severity: minor There's a package in contrib called libdvd-pkg which automates the process of downloading & installing libdvdcss. The README.css file included in the libdvdread package should mention it.
Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13 Inbox [Imap]/Sent
Control: forwarded -1 https://github.com/jeffdaily/parasail-python/issues/56 Forwarded the issue upstream, hopefully we will have a fix soonish with arm64 becoming more popular.
Bug#976652: mariadb-server-10.3: Could not increase number of max_open_files to more than 16384 (request: 32191)
Package: mariadb-server-10.3 Version: 1:10.3.27-0+deb10u1 Severity: normal When starting the mariadb service it warns: Dec 6 07:01:05 myhost mysqld[24031]: 2020-12-06 7:01:05 0 [Warning] Could not increase number of max_open_files to more than 16384 (request: 32191) This warning is because /lib/systemd/system/mariadb.service contains: LimitNOFILE=16384 Please increase this limit to 32191 as suggested by mariadb. -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mariadb-server-10.3 depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.71 ii galera-3 25.3.25-2 ii gawk 1:4.2.1+dfsg-1 ii iproute2 4.20.0-2 ii libc6 2.28-10 ii libdbi-perl 1.642-1+deb10u1 ii libgnutls30 3.6.7-4+deb10u5 ii libpam0g 1.3.1-5 ii libstdc++68.3.0-6 ii lsb-base 10.2019051400 ii lsof 4.91+dfsg-1 ii mariadb-client-10.3 1:10.3.27-0+deb10u1 ii mariadb-common1:10.3.27-0+deb10u1 ii mariadb-server-core-10.3 1:10.3.27-0+deb10u1 ii passwd1:4.5-1.1 ii perl 5.28.1-6+deb10u1 ii psmisc23.2-1 ii rsync 3.1.3-6 ii socat 1.7.3.2-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages mariadb-server-10.3 recommends: ii libhtml-template-perl 2.97-1 Versions of packages mariadb-server-10.3 suggests: ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-1 pn mariadb-test pn netcat-openbsd pn tinyca -- Configuration Files: /etc/logcheck/ignore.d.paranoid/mariadb-server-10_3 [Errno 13] Permission denied: '/etc/logcheck/ignore.d.paranoid/mariadb-server-10_3' /etc/logcheck/ignore.d.server/mariadb-server-10_3 [Errno 13] Permission denied: '/etc/logcheck/ignore.d.server/mariadb-server-10_3' /etc/logcheck/ignore.d.workstation/mariadb-server-10_3 [Errno 13] Permission denied: '/etc/logcheck/ignore.d.workstation/mariadb-server-10_3' /etc/logrotate.d/mysql-server changed [not included] -- debconf information excluded
Bug#976669: lintian: please warn about autopkgtests that test rebuilt source, not as-installed, where possible
Package: lintian
Severity: wishlist
X-Debbugs-Cc: debian-j...@lists.debian.org
Hi lintian people,
the request is, of course, not generally solvable. However, for
a few buildsystems and ways to “test”, this is possible, and
these should be warned about (probably at Error level even).
It all begun with…
> I find java packages with maven-debian-helper can be tested by:
>
>
> Test-Command: dh_auto_configure; dh_auto_test
The trouble here is that, with maven-debian-helper in Build-Depends
and used (if pom.xml exists, it’s used), this calls “mvn test”, and
Maven helpfully expands this to “mvn compile test” because the source
is not yet compiled. It’s probably much more involved to do as-installed
testing with Maven… but that’s for d-java@l.d.o to figure out.
But some people are using this, and this should be an Error.
Some other buildsystems also do this. I don’t know many, but
for example some Makefile-based ones also have a “test: build”
dependency. So maybe the mere presence of dh_auto_test in a
testcase should also be warned about, but with a much lower
severity than Error. Error should be used for these we positively
know about that rebuilds are caused and that the rebuilt code
is the code being tested.
Perhaps specialists for other buildsystems could also be asked
whether theirs do that, and errors tagged for those.
On Sun, 6 Dec 2020, Paul Wise wrote:
> On Sat, Dec 5, 2020 at 6:45 PM Thorsten Glaser wrote:
>
> > We probably should let maven-debian-helper’s dh module
> > abort any building (dh_auto_{build,test}) if run under
> > autopkgtests to enforce this.
>
> I'd suggest to start with a lintian warning about this and maybe when
> there are fewer packages using it, then change the dh module.
Good point. I’m doing so with this.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
*
Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.
Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.
*
Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Hello! On 12/6/20 7:38 PM, Nilesh Patra wrote: > I've no clue of where to even start debugging this. Any help/hints are > welcome and highly appreciated. My suggestion would be to report this issue upstream [1]. Since ARM is going to be more popular in the future with Apple switching their all their machines over from x86, I expect such issues to become more relevant. Adrian > [1] https://github.com/jeffdaily/parasail-python -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
Am Sonntag, den 06.12.2020, 16:04 +0100 schrieb Michael Biebl: > Control: severity -1 important > Control: tags -1 unreproducible > > I tested other Wayland clients To be specific: weston, sway and GNOME. I used gdm3 as display manager to start those Wayland sessions and did not run into any problems. Regards, Michael
Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Control: tags -1 help
Hi Debian Arm team,
I've no clue of where to even start debugging this. Any help/hints are welcome
and highly appreciated.
Thanks and regards
Nilesh
On Sat, 5 Dec 2020 13:51:16 +0100 Lucas Nussbaum wrote:
> Source: python-parasail
> Version: 1.2.1-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
>
> Relevant part (hopefully):
>> dpkg-buildpackage
>> -
>>
>> Command: dpkg-buildpackage -us -uc -sa -rfakeroot
>> dpkg-buildpackage: info: source package python-parasail
>> dpkg-buildpackage: info: source version 1.2.1-1
>> dpkg-buildpackage: info: source distribution unstable
>> dpkg-buildpackage: info: source changed by Nilesh Patra
>> dpkg-source --before-build .
>> dpkg-buildpackage: info: host architecture arm64
>> debian/rules clean
>> dh clean --with python3 --buildsystem=pybuild
>> dh_auto_clean -O--buildsystem=pybuild
>> I: pybuild base:232: python3.9 setup.py clean
>> running clean
>> removing '/<>/.pybuild/cpython3_3.9/build' (and everything
>> under it)
>> 'build/bdist.linux-arm64' does not exist -- can't clean it
>> 'build/scripts-3.9' does not exist -- can't clean it
>> dh_autoreconf_clean -O--buildsystem=pybuild
>> dh_clean -O--buildsystem=pybuild
>> dpkg-source -b .
>> dpkg-source: info: using source format '3.0 (quilt)'
>> dpkg-source: info: building python-parasail using existing
>> ./python-parasail_1.2.1.orig.tar.gz
>> dpkg-source: info: using patch list from debian/patches/series
>> dpkg-source: info: building python-parasail in
>> python-parasail_1.2.1-1.debian.tar.xz
>> dpkg-source: info: building python-parasail in python-parasail_1.2.1-1.dsc
>> debian/rules binary
>> dh binary --with python3 --buildsystem=pybuild
>> dh_update_autotools_config -O--buildsystem=pybuild
>> dh_autoreconf -O--buildsystem=pybuild
>> dh_auto_configure -O--buildsystem=pybuild
>> I: pybuild base:232: python3.9 setup.py config
>> running config
>> dh_auto_build -O--buildsystem=pybuild
>> I: pybuild base:232: /usr/bin/python3 setup.py build
>> running build
>> running build_py
>> creating /<>/.pybuild/cpython3_3.9/build/parasail
>> copying parasail/bindings_v2.py ->
>> /<>/.pybuild/cpython3_3.9/build/parasail
>> copying parasail/__init__.py ->
>> /<>/.pybuild/cpython3_3.9/build/parasail
>> copying parasail/bindings_v1.py ->
>> /<>/.pybuild/cpython3_3.9/build/parasail
>> dh_auto_test -O--buildsystem=pybuild
>> I: pybuild base:232: cd /<>/.pybuild/cpython3_3.9/build;
>> python3.9 -m pytest tests
>> = test session starts
>> ==
>> platform linux -- Python 3.9.1rc1, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
>> rootdir: /<>
>> collected 16 items
>> tests/test_basic.py ...Segmentation fault
>> E: pybuild pybuild:353: test: plugin distutils failed with: exit code=139:
>> cd /<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest tests
>> >> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
>> 3.9 returned exit code
signature.asc
Description: OpenPGP digital signature
Bug#976497: python-parasail: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13
Control: tags -1 help
Hi Debian Arm team,
I've no clue of where to even start debugging this. Any help/hints are welcome
and highly appreciated.
Thanks and regards
Nilesh
On Sat, 5 Dec 2020 13:51:16 +0100 Lucas Nussbaum wrote:
> Source: python-parasail
> Version: 1.2.1-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
>
> Relevant part (hopefully):
> > dpkg-buildpackage
> > -
> >
> > Command: dpkg-buildpackage -us -uc -sa -rfakeroot
> > dpkg-buildpackage: info: source package python-parasail
> > dpkg-buildpackage: info: source version 1.2.1-1
> > dpkg-buildpackage: info: source distribution unstable
> > dpkg-buildpackage: info: source changed by Nilesh Patra
> >
> > dpkg-source --before-build .
> > dpkg-buildpackage: info: host architecture arm64
> > debian/rules clean
> > dh clean --with python3 --buildsystem=pybuild
> > dh_auto_clean -O--buildsystem=pybuild
> > I: pybuild base:232: python3.9 setup.py clean
> > running clean
> > removing '/<>/.pybuild/cpython3_3.9/build' (and everything
> > under it)
> > 'build/bdist.linux-arm64' does not exist -- can't clean it
> > 'build/scripts-3.9' does not exist -- can't clean it
> > dh_autoreconf_clean -O--buildsystem=pybuild
> > dh_clean -O--buildsystem=pybuild
> > dpkg-source -b .
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building python-parasail using existing
> > ./python-parasail_1.2.1.orig.tar.gz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: info: building python-parasail in
> > python-parasail_1.2.1-1.debian.tar.xz
> > dpkg-source: info: building python-parasail in python-parasail_1.2.1-1.dsc
> > debian/rules binary
> > dh binary --with python3 --buildsystem=pybuild
> > dh_update_autotools_config -O--buildsystem=pybuild
> > dh_autoreconf -O--buildsystem=pybuild
> > dh_auto_configure -O--buildsystem=pybuild
> > I: pybuild base:232: python3.9 setup.py config
> > running config
> > dh_auto_build -O--buildsystem=pybuild
> > I: pybuild base:232: /usr/bin/python3 setup.py build
> > running build
> > running build_py
> > creating /<>/.pybuild/cpython3_3.9/build/parasail
> > copying parasail/bindings_v2.py ->
> > /<>/.pybuild/cpython3_3.9/build/parasail
> > copying parasail/__init__.py ->
> > /<>/.pybuild/cpython3_3.9/build/parasail
> > copying parasail/bindings_v1.py ->
> > /<>/.pybuild/cpython3_3.9/build/parasail
> > dh_auto_test -O--buildsystem=pybuild
> > I: pybuild base:232: cd /<>/.pybuild/cpython3_3.9/build;
> > python3.9 -m pytest tests
> > = test session starts
> > ==
> > platform linux -- Python 3.9.1rc1, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
> > rootdir: /<>
> > collected 16 items
> > tests/test_basic.py ...Segmentation fault
>> E: pybuild pybuild:353: test: plugin distutils failed with: exit code=139:
>> cd /<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest tests
>> >> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
>> 3.9 returned exit code 13
signature.asc
Description: OpenPGP digital signature
Bug#976659: Kernel panic while upgrading systemd
Control. tags -1 + moreinfo Am 06.12.20 um 17:00 schrieb Guillaume Brocker: Package: systemd Version: 246.6-4 Dear maintainer, I'm trying to upgrade systemd (along with libnss-systemd libpam-systemd libsystemd0 libudev1 systemd systemd-sysv systemd-timesyncd udev) from version 246-2 to version 246.6-4, but I'm encountering a kernel panic during systemd's package configuration. Please find as attchment the secreenshot with logs. Unfortunately, this screenshot is not too helpful. To be able to diagnose the problem, we at least need a full backtrace. For that install the dbgsym packages for systemd and a program which gathers the coredump. You can use systemd-coredump for that. After that, you can get the coredump with coredumpctl. Regards, Michael
Bug#972076: Bug#975233: tasksel --new-install fails
Control: reopen -1 Control: notfound -1 3.61 nicoo wrote: > Control: clone -1 -2 > Control: retitle -2 tasksel --new-install fails > Control: severity -2 normal > > Hi, > > On Thu, Nov 19, 2020 at 10:21:29AM +0100, Holger Wansing wrote: > > Swen Joachim wrote: > > > On 2020-11-17 23:00 +0100, nicoo wrote: > > > > Could you confirm that the version Holdger uploaded fixes the issue? > > > Sure it does. :-) > > > > > > > If it doesn't, please remove the “fixed in v3.60” tag I just added. > > > On the contrary, I am closing the bug hereby, no idea why Holger did not > > > do so with the upload. > > > > Because there is - strictly spoken - one aspect of the bug, which is not yet > > fixed. That is: > > > > Date: Thu, 15 Oct 2020 06:43:05 +0200 > > From: Markus Steinko > > To: 972...@bugs.debian.org > > Subject: Bug#972076: tasksel --new-install > > > > > > When rechecking for the warning I figured out that `tasksel > > --new-install` also gives an error. > > Oh, apologies for missing that part. > > > I'm not sure if this is because of > > already having all needed and available packages that option offers > > installed, or if it maybe is another bug. > > Sounds like another bug, but I'll try to reproduce with the new tasksel. > > > You can - of course - say, that is another issue, and thus #972076 can be > > closed, but then the other issue should get a separate bugreport. > > Agreed, cloning this report as I do not see a separate one in the BTS yet. The bug has been cloned, however the new one is also closed already. So reopening. Additionally, I tested with tasksel 3.61 from testing, if this bug is still reproducible, and found that it is not! Everything worked fine there: I called "tasksel --new-install", got the selection menu, chose to additionally install ssh-server, and that worked fine. So updating the list of not-affected versions. Let's see what happens with future versions ... (FTR: since the point of this bugreport may be overseen in the bug log: please find the description of the problem in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975233#24 ) Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem
Am 06.12.20 um 17:04 schrieb Josh Jones: It is the root filesystem which is failing to be remounted read-only - this is a simple setup with only one filesystem for the whole system. It seems to be happening right at the very very end of the shutdown sequence - I have attached a picture of the error; quality is poor because I had to capture it from video footage. Is there any way to even have anything saved to disk so late in the sequence? With the shutdown hook described in README.Debian and https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 (install the hook as /lib/systemd/system-shutdown/debug.sh without the /usr prefix) you can gather logs right until the end Thanks for your help and attention with this; I'm willing to try whatever you suggest to help work out what's going on - if that is even possible..! You might also have a look at https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/README.Debian "Debugging boot/shutdown problems" to gather logs after journald has been shut down.
Bug#962203: DeprecationWarning: isAlive() is deprecated, use is_alive() instead
Package: debdelta
Version: 0.65
Followup-For: Bug #962203
X-Debbugs-Cc: calumlikesapple...@gmail.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have created an attached a patch. It is also availible as merge request !2
in the salsa repository.
- -- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debdelta depends on:
ii binutils 2.35.1-3
ii bzip2 1.0.8-4
ii libbz2-1.01.0.8-4
ii libc6 2.31-4
ii python3 3.8.6-1
ii python3-requests 2.24.0+dfsg-1
ii zlib1g1:1.2.11.dfsg-2
Versions of packages debdelta recommends:
ii bsdiff 4.3-21+b1
ii gnupg-agent 2.2.20-1
ii gnupg2 2.2.20-1
ii gpg-agent [gnupg-agent] 2.2.20-1
ii python3-apt 2.1.6
ii python3-debian 0.1.38
ii xdelta 1.1.3-9.3
ii xdelta3 3.0.11-dfsg-1+b1
ii xz-utils [lzma] 5.2.4-1+b1
Versions of packages debdelta suggests:
ii debdelta-doc 0.65
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl/NHNgdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzK5rA//S3+ySeshMWhTEp38
KOrKKWvR/vGOb2MjPILXU6VJfAcw7tIf/IbzvGkj3QM08f1eF3RElP4UwC4NCpj6
oTEYgq88lE0YTqYrdRJopM70pmcDArzvFpysudonUHJ8k2sUwr/5R18S8BooiGDw
iOs7BaAv3vJNyKfeYSJlIdMLiq1u52z6xooSg92Rb6b/rBC3il5frkpUsy4L/Jid
AHEGDhTAtyvwof/zdyjwVnMQvxoS5lsm5hkc7RNFpndkvRONTWNNOa0raYucbQ3K
vitJ+7BuNZ3GF/yi86+L1krOGpv5E5lbdlmhtqUMd1RcYw1VZpEcJ+3D45dDOxSg
wbIFV+ud+ATXC7yVYMQhDv/S3GSb/sKx7OrLJZX/67BrQZqMM3eB4BXarJe1o9gV
56znmh+hzGoGkzaZJmKHRNdhYK97rWXYts/4pUAnpICDkhMBbQ/D4OgVgA18dRR6
h4CsU+ynf0Z6Xb0bW9tPmkbj0a91mOvqNRvO1E9kwnSolsAjqJQ7HmQp0GLnDQfy
nxdCMGTIQOIWepdF8bi2WiGaSwvK2f2Q1LyxqEMsBf68uH3+IcCxsPKCrZ55w+gy
7NxRvlLwYilTFN20aZSTtFt7ntDPzLy6J9BulukLNjgD1AoW00Y/mlG+Af/hxMhc
fNhgaK9EUfEhOQeqOyoorBwEjok=
=4QZH
-END PGP SIGNATURE-
>From 4821b3f1fdb9118ba3c80b8077af63b5006d6ddb Mon Sep 17 00:00:00 2001
From: Calum McConnell
Date: Sun, 6 Dec 2020 12:53:52 -0500
Subject: [PATCH] Fix isAlive -> is_alive
---
debdelta/debdelta | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/debdelta/debdelta b/debdelta/debdelta
index b4a79c1..b7f258c 100755
--- a/debdelta/debdelta
+++ b/debdelta/debdelta
@@ -5460,9 +5460,9 @@ def delta_upgrade_(args):
#do something useful in the meantime
debs_down_size=0
debs_down_time=0
- if patching_thread.isAlive() and no_delta and VERBOSE > 1 :
+ if patching_thread.is_alive() and no_delta and VERBOSE > 1 :
logger.info(' Downloading deltas done, downloading debs while waiting for
patching thread.')
- while patching_thread.isAlive() or ('a' in DEB_POLICY and no_delta):
+ while patching_thread.is_alive() or ('a' in DEB_POLICY and no_delta):
if no_delta:
uri, newdeb = no_delta.pop()
thread_returns['downloaduri']=os.path.basename(uri)
@@ -5481,12 +5481,12 @@ def delta_upgrade_(args):
if http_conns[i] != None :
http_conns[i].close()
- while patching_thread.isAlive():
+ while patching_thread.is_alive():
time.sleep(0.1)
#terminate progress report
thread_returns['STOP']=True
- while progress_thread != None and progress_thread.isAlive():
+ while progress_thread != None and progress_thread.is_alive():
time.sleep(0.1)
if DO_PROGRESS:
--
2.29.2
Bug#957420: lib3mf: diff for NMU version 1.8.1+ds-3.1
On Sun, 06 Dec 2020 18:26:44 +0100, Torsten Paul wrote: > On 06.12.20 02:37, gregor herrmann wrote: > > Joel Ray Holveck has prepared an NMU for lib3mf (versioned as > > 1.8.1+ds-3.1) and I've uploaded it to DELAYED/7. Please feel free to > > tell me if I should delay it longer. > Thanks, for the NMU, that's great. I appreciate the help as > I'm still stuck with trying to get an OpenSCAD release out. That's great to hear, because the lack of OpenSCAD in testing was the reason why I came across this bug :) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Peter Ratzenbeck: Lady Nothings Toye Puffe signature.asc Description: Digital Signature
Bug#855172: Unable to select no suite (ie unstable) when filing binNMU bug against release.debian.org
control: severity -1 minor On 14 Feb 2017 James Clarke wrote: Running reportbug release.debian.org with the GTK UI, when prompted to choose a suite, the first suite in the list is already selected, and there is no way to de-select it (at least as far as I can tell). This means I can't use reportbug to file binNMUs for unstable. You can unselect an item by holding down the Ctrl key when clicking. Since this is not too discoverable, we should include the default option in the menu here and have it pre-selected.
Bug#813771: reportbug: It can't unselect item in 'Do any of the following apply to this report' page.
control: severity -1 minor On 05 Feb 2016 Takahide Nojima wrote: In using gui of reportbug, The page of 'Do any of the following apply to this report' lacks functionarity that all item set to unselecting. If you would select a item mistakenly, all item can't set to unselecting. Yes, just clicking a selected item does not unselect it again. Until somebody knows how to implement that there is a workaround: You can unselect an item by holding down the Ctrl key when clicking.
Bug#976667: openjdk-16-jre-headless: too low prioriry for it to be used by default
Package: openjdk-16-jre-headless Version: 16~27-2 Severity: normal Dear Maintainer, the package works fine for my project however it have to low priority assigned to be used by default. please increase! mc36@noti:~$ sudo update-alternatives --config java There are 6 choices for the alternative java (providing /usr/bin/java). SelectionPathPriority Status * 0/usr/lib/jvm/java-15-openjdk-amd64/bin/java 1511 auto mode 1/usr/lib/jvm/java-11-openjdk-amd64/bin/java manual mode 2/usr/lib/jvm/java-13-openjdk-amd64/bin/java 1311 manual mode 3/usr/lib/jvm/java-14-openjdk-amd64/bin/java 1411 manual mode 4/usr/lib/jvm/java-15-openjdk-amd64/bin/java 1511 manual mode 5/usr/lib/jvm/java-16-openjdk-amd64/bin/java 1511 manual mode 6/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081 manual mode Press to keep the current choice[*], or type selection number: ^C mc36@noti:~$ *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages openjdk-16-jre-headless depends on: ii ca-certificates-java 20190909 ii java-common 0.72 ii libasound21.2.3.2-1+b1 ii libc6 2.31-5 ii libcups2 2.3.3op1-3 ii libfontconfig12.13.1-4.2 ii libfreetype6 2.10.2+dfsg-4 ii libgcc-s1 10.2.0-23 ii libharfbuzz0b 2.6.7-1 ii libjpeg62-turbo 1:2.0.5-1.1 ii liblcms2-22.9-4+b1 ii libnss3 2:3.59-1 ii libpcsclite1 1.9.0-1 ii libstdc++610.2.0-23 ii libx11-6 2:1.6.12-1 ii libxext6 2:1.3.3-1+b2 ii libxi62:1.7.10-1 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii util-linux2.36.1-2 ii zlib1g1:1.2.11.dfsg-2 openjdk-16-jre-headless recommends no packages. Versions of packages openjdk-16-jre-headless suggests: ii fonts-dejavu-extra 2.37-2 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei | fonts-wqy-zenhei ii libnss-mdns0.14.1-2 -- no debconf information
Bug#976648: linux-image-amd64: check if there is enough storage space before installing package and warn user if not
Package: linux-image-amd64 Version: 5.9.11-1 Severity: normal Dear Maintainer, * What led up to the situation? upgrade linux-image-amd64. * What exactly did you do (or not do) that was effective (or ineffective)? shortage of disk space on partition where modules are installed. * What was the outcome of this action? unsuccessful upgrade, kernel package remained in status "broken", couldn't install, couldn't deinstall older kernels because the broken package needed to be fixed first * What outcome did you expect instead? apt could estimate needed disk space; warn user, if there is not enough disk space available (broken down to partions) -- System Information: Debian Release: bullseye/sid Architecture: amd64 (x86_64) iu linux-image-5.9.0-4-amd64 5.9.11-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information -- signature.asc Description: PGP signature
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
On Tue, 24 Nov 2020, Cristian Ionescu-Idbohrn wrote: > > I interpret that this way: dns-mgr is confused; it concludes something > has changed, queues DNS updates, concludes nothing has changed and > does not commit anything (after first cleaning up resolv.conf). > > I both cases (wired, wireless), the primary dns is my router's lan ip > (served with dhcp). In the wireless case, I locally added a secondary > (external, public) dns ip. For the record: in my case, it appears modifying: --- a/NetworkManager/NetworkManager.conf +++ b/NetworkManager/NetworkManager.conf @@ -1,5 +1,6 @@ [main] plugins=ifupdown,keyfile +rc-manager=file [ifupdown] managed=false when no other dns-helper is installed, solves both problems (screw up both resolv.conf and interface switch wired/wireless between bots). Not really obvious even after reading `man 5 NetworkManager.conf'. -- Cristian
Bug#962203: DeprecationWarning: isAlive() is deprecated, use is_alive() instead
Package: debdelta Version: 0.65 Followup-For: Bug #962203 X-Debbugs-Cc: calumlikesapple...@gmail.com Control: severity -1 grave -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The function is removed in Python 3.9, which is now the debian default. Debdelta-upgrade will now simply crash. This is not good. Patching is as easy as a find/replace. Please fix this issue! - -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debdelta depends on: ii binutils 2.35.1-3 ii bzip2 1.0.8-4 ii libbz2-1.01.0.8-4 ii libc6 2.31-4 ii python3 3.8.6-1 ii python3-requests 2.24.0+dfsg-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages debdelta recommends: ii bsdiff 4.3-21+b1 ii gnupg-agent 2.2.20-1 ii gnupg2 2.2.20-1 ii gpg-agent [gnupg-agent] 2.2.20-1 ii python3-apt 2.1.6 ii python3-debian 0.1.38 ii xdelta 1.1.3-9.3 ii xdelta3 3.0.11-dfsg-1+b1 ii xz-utils [lzma] 5.2.4-1+b1 Versions of packages debdelta suggests: ii debdelta-doc 0.65 - -- no debconf information -BEGIN PGP SIGNATURE- iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl/NFbAdHGNhbHVtbGlr ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzLdMg//RU1jpB2htAenj5tx e7t1MBIdorjTWUFES2KSJLCFvfOSrLhXpf72xPAu0+kXSEs6VdcmaWZEqIEAjXje crGFezOx3zKPeV3Yzk3aKWOcftLrlmuDVV5Pgku0KwBtd0Qftgu6t+DemKhUs9Ym HSlbwlKCsAkikdbNhD+JJ/eIkzERdIUtE3KUM4YHa9LyQEipnE3kdnExrCjn9BZi 7rKQIv6GPpHH9AhwLnbkUuIdoNNeZRhBDcUB9BVJhnrrFhgkB5FF4/22L/DHV6xu z/ztSf+LiruUmUsR5nK7IH+xwQi8zqk/O1/tChYDWI4EXagMmMhN/rFzrlXmnlJI oeSxXhGnarKB2fjPqztS53Vd77pjXGWkqQWNQMO9AtmIbHNQ891vr8Hm0Zdd/cGV KB6uXtySybtHFAJsH2l6IZZgc3ouW+Vhqpn0n8/XcdtQBx7OQFpid/HbYup818fc 9pJOhGEFpq9mtTlje2TUtkKXasl6AbwSPg1+oqmPmmNVlwMT59MMMz2XJeQgLsH/ dUAOd0x3DfsEUq4Nlrcgnyeomk5Jc0mvhJ369CylXJnw9bI71bFiC32kzedz7v+C dET/HhOWus8IZcEZh4nJj3fhZO/kg2jcyx4wt5vKpzU8Fl6YtkPq3hAWkPgaPolr PseTA+roHeNtCwowHtdNrSCjmw8= =0hVv -END PGP SIGNATURE-
Bug#957420: lib3mf: diff for NMU version 1.8.1+ds-3.1
Hi! On 06.12.20 02:37, gregor herrmann wrote: > Joel Ray Holveck has prepared an NMU for lib3mf (versioned as > 1.8.1+ds-3.1) and I've uploaded it to DELAYED/7. Please feel free to > tell me if I should delay it longer. Thanks, for the NMU, that's great. I appreciate the help as I'm still stuck with trying to get an OpenSCAD release out. ciao, Torsten.
Bug#976590: How should I fix?
Hi, There's multiple ways how this could be fixed, probably one should be to disable the failing unit test if not running on amd64. I'll open an issue upstream for this, and see how it goes. In the mean while (ie: before I get an answer from upstream), I'll downgrade this bug to important. Cheers, Thomas Goirand (zigo)
Bug#871446: jemalloc: FTBFS on hurd-i386: aligned_alloc test hangs
Hello, Aaron M. Ucko, le ven. 11 août 2017 17:56:38 -0400, a ecrit: > only about a dozen source packages build-depend on > jemalloc. Just as additional updated information point: inkscape is now also using jemalloc, so that raises the number to a couple hundreds of reverse build dependencies. Samuel
