Bug#990468: genisoimage: Bad time stamps for post-2027 files
Package: genisoimage
Version: 9:1.1.11-3+b2
Description of bug: .iso files generated with genisoimage will have
incorrect timestamps for files created on or after January 1, 2028
Steps to reproduce:
tar xvJf geniso-Y2076-test.tar.xz
# Please ignore timestamp in future warnings
genisoimage -J -V "test" -o test.iso geniso-Y2076-test/
Expected results:
The timestamps in the file test.iso will be between 5:03 and 5:05 am
(local time) for years between 2021 and 2076.
Actual results:
Some timestamp will have a different time because the
time zone value is invalid.
How to fix:
Edit the file genisoimage.c so that the function iso9660_date() does
not generate bad timestamps starting on January 1, 2028.
Here is a fixed version of the file (also, I made sure to have
reasonable values for timestamps for files dated before January 1,
1900 or after December 31, 2155):
int
iso9660_date(char *result, time_t crtime)
{
struct tm *local;
struct tm *gmt;
int year, yday, hour, minute, second, zone;
local = localtime(&crtime);
result[0] = year = local->tm_year;
result[1] = local->tm_mon + 1;
result[2] = local->tm_mday;
yday = local->tm_yday;
result[3] = hour = local->tm_hour;
result[4] = minute = local->tm_min;
result[5] = second = local->tm_sec;
/* Sam Trenholme's notes: The following code has been updated to be
* Y2028 compliant. That is *not* a typo: Year twenty-*twenty*eight
* (**not 2038!**).
* In other words, result[6] (the time zone) had invalid values for
* files created on or after January 1, 2028.
*/
/* First of all, the 9660 spec only allows timestamps between
* January 1, 1900 and December 31, 2155. So, handle timestamps
* outside that spec by giving out timestamps at the end of the
* spec. It is unknown here in 2021 whether or not 2155 will
* have a leap second; I will assume programmers are smart enough
* to not have things crash if we have a leap second. */
if(year < 0) {
/* January 1, 1900 00:00:00 GMT */
result[0] = 0;
result[1] = 1;
result[2] = 1;
result[3] = 0;
result[4] = 0;
result[5] = 0;
result[6] = 0; /* Time zone */
return 0;
} else if(year > 255) {
/* December 31, 2155, 23:59:60 GMT */
result[0] = 255;
result[1] = 12;
result[2] = 31;
result[3] = 23;
result[4] = 59;
result[5] = 60;
result[6] = 0; /* Time zone */
return 0;
}
/* I have no idea why POSIX does not have tm_gmtoff. Since it
* doesn't, we have to calculate it ourselves. */
gmt = gmtime(&crtime); /* Zaps local, be careful */
zone = 0;
/* We will never be more than one day off between GMT and local
* time. That in mind, if the year is different, we are one day
* behind or ahead. Otherwise, if the day is different, it will
* always be a one day difference. */
if(gmt->tm_year < year) {
zone = 86400; /* 24 hours in seconds */
} else if(gmt->tm_year > year) {
zone = -86400;
} else if(gmt->tm_yday < yday) {
zone = 86400;
} else if(gmt->tm_yday > yday) {
zone = -86400;
}
/* Now that we account for different days, account for different
* hours, minutes, and seconds. */
zone += (hour - gmt->tm_hour) * 3600;
zone += (minute - gmt->tm_min) * 60;
zone += second - gmt->tm_sec;
result[6] = zone / 900; /* Every 15 minutes in 9660 spec */
return (0);
}
Additional notes:
File source code which uses 100% GPLv2 code and compiles and works in
Ubuntu 20.04 (probably also Debian) is at
https://github.com/samboy/9660img
Another comment:
I know there have been issues with the original upstream version of
the code possibly being linked to CDDL licensed code. Has anyone
attempted to contact Eric Youngdale and see if he’s willing to
dual-license the original mkisofs / cdrkit package to also have a CDDL
license so we can resolve the licensing dispute and have a version
directly derived from the version still maintained by the primary
mkisofs maintainer?
geniso-Y2076-test.tar.xz
Description: Binary data
Bug#989496: apt-listchanges: Error output if choosing to not continue after reading list of changes
Tia, Thank you for reporting this bug. I can confirm that this is an issue: apt-listchanges: Do you want to continue? [Y/n] n apt-listchanges: Aborting E: Sub-process /usr/bin/apt-listchanges --apt || test $? -lt 10 returned an error code (1) E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10 I believe I have found the issue and have a fix ready to go. I'll set the status to pending. -- Best regards, Brian
Bug#990363: caml-crush: FTBFS with OpenSSL 3.0
Thanks for the report.
I've been meaning to push an update to fix some other issues with Caml
Crush and recent Ocaml versions.
On Sun, Jun 27, 2021 at 11:45 AM Kurt Roeckx wrote:
> Package: caml-crush
> Version: 1.0.10-4
>
> Hi,
>
> Your package is failing to build against OpenSSL 3.0 beta 1. The
> log file show:
> configure:6589: checking for SSL_get_peer_certificate in -lssl
> configure:6614: gcc -o conftest -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -I/usr/lib/ocaml -Wdate-time -D_FORTIFY_SOURCE=2
> -I/usr/lib/ocaml -Wl,-z,relro conftest.c -lssl -lc >&5
> /usr/bin/ld: /tmp/cc4uEWWT.o: in function `main':
> ./build-SERVER/conftest.c:38: undefined reference to
> `SSL_get_peer_certificate'
> collect2: error: ld returned 1 exit status
> configure:6614: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "cam-crush"
> | #define PACKAGE_TARNAME "cam-crush"
> | #define PACKAGE_VERSION "1.0.10"
> | #define PACKAGE_STRING "cam-crush 1.0.10"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_TYPES_H 1
> | #define HAVE_SYS_STAT_H 1
> | #define HAVE_STDLIB_H 1
> | #define HAVE_STRING_H 1
> | #define HAVE_MEMORY_H 1
> | #define HAVE_STRINGS_H 1
> | #define HAVE_INTTYPES_H 1
> | #define HAVE_STDINT_H 1
> | #define HAVE_UNISTD_H 1
> | #define HAVE_CAML_MLVALUES_H 1
> | #define HAVE_CAML_CAMLIDLRUNTIME_H 1
> | #define HAVE_DLFCN_H 1
> | #define HAVE_PTHREAD_H 1
> | #define HAVE_RPC_RPC_H 1
> | #define HAVE_RPC_CLNT_H 1
> | #define HAVE_LIBC 1
> | #define HAVE_OPENSSL_SSL_H 1
> | /* end confdefs.h. */
> |
> | /* Override any GCC internal prototype to avoid an error.
> |Use char because int might match the return type of a GCC
> |builtin and then its argument prototype would still apply. */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char SSL_get_peer_certificate ();
> | int
> | main ()
> | {
> | return SSL_get_peer_certificate ();
> | ;
> | return 0;
> | }
> configure:6623: result: no
> configure:6628: error: Cannot find symbol in openssl library.
>
> The function has been renamed, and the old name deprecated in 3.0.
> The header file actually has a define from the old name to the new
> name:
> # ifndef OPENSSL_NO_DEPRECATED_3_0
> # define SSL_get_peer_certificate SSL_get1_peer_certificate
> # endif
>
> The easy fix is to actually include ssl.h when looking for
> symbol, so that you actually look for the renamed symbol.
>
>
> Kurt
>
Bug#843654: Use Debian pjproject and libsrtp
pjproject and libsrtp have been removed from Debian for a long time, so this bug is not valid anymore. There is libsrtp2 now, which can be used maybe. Debian's current version is 2.3.0 which is later than the bundled version.
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
Hi, On Tue, 22 Jun 2021 11:23:51 +0200 Sebastian Ramacher wrote: > 1.3.4-1 would have needed to rename the package to libopenscap25 and > start a library transition. The library package also contains a bunch of > binaries and other files that do not look like the should be part of a > library package. In any case, raising the severity to serious is the > current packaging of the library is broken. Can we have a chance to put splitted packages (openscap-scanner as tools binary as other distros do and openscap-common for /usr/share files) for bullseye release? If so, I'll try to do so. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#990469: libpod-coverage-perl: please use versioned Depends: libpod-parser-perl (>= 1.63)
Package: libpod-coverage-perl Version: 0.23-2 Severity: important User: debian...@lists.debian.org Usertags: piuparts Control: clone -1 -2 -3 -4 -5 -6 -7- -8 -9 -10 -11 -12 Control: reassign -2 libpod-spell-perl 1.20-2 Control: retitle -2 libpod-spell-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -3 dh-make-perl 0.116 Control: retitle -3 dh-make-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -4 libgetopt-euclid-perl 0.4.5-3 Control: retitle -4 libgetopt-euclid-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -5 libpod-xhtml-perl 1.61-3 Control: retitle -5 libpod-xhtml-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -6 libpod-constants-perl 0.19-2 Control: retitle -6 libpod-constants-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -7 libhttp-dav-perl 0.49-2 Control: retitle -7 libhttp-dav-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -8 libparse-errorstring-perl-perl 0.27-2 Control: retitle -8 libparse-errorstring-perl-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -9 libpod-abstract-perl 0.20-3 Control: retitle -9 libpod-abstract-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -10 libpod-latex-perl 0.61-3 Control: retitle -10 libpod-latex-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -11 libpod-plainer-perl 1.04-2 Control: retitle -11 libpod-plainer-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Control: reassign -12 libpod-sax-perl 0.14-7 Control: retitle -12 libpod-sax-perl: please use versioned Depends: libpod-parser-perl (>= 1.63) Hi, during a test with piuparts I noticed your package is not upgraded (i.e. the version from buster is kept) during an upgrade from 'buster' to 'bullseye' if perl-modules-5.24 from stretch is still installed. perl-modules-5.24 provided an unversioned virtual libpod-parser-perl and apt tries to use the installed package (instead of installing a new package) to satisfy the new dependency of your package, while perl-modules-5.24 needs to get removed due to Breaks in new perl. (The versioned virtual libpod-parser-perl (= 1.63) in perl/buster is probably not considered a candidate since perl with its high score was decided for being upgraded earlier.) Making the dependency versioned excludes the unversioned virtual package from being considered a candidate. I tested this with some of the affected packages, and assume that it will work the same way for the others as well. The corresponding apt bug is #988356, but of course this will not be fixed in apt/buster. An example for the bad problem resolution from apt: Starting 2 pkgProblemResolver with broken count: 1 Investigating (0) perl:amd64 < 5.28.1-6+deb10u1 -> 5.32.1-4 @ii umU Ib > Broken perl:amd64 Breaks on perl-modules-5.24:amd64 < 5.24.1-3+deb9u7 @ii mK > Considering perl-modules-5.24:amd64 -2 as a solution to perl:amd64 8 Added perl-modules-5.24:amd64 to the remove list Fixing perl:amd64 via remove of perl-modules-5.24:amd64 Investigating (0) libpod-coverage-perl:amd64 < 0.23-1 -> 0.23-2 @ii umU Ib > Broken libpod-coverage-perl:amd64 Depends on libpod-parser-perl:amd64 < none | 1.63-2 @un uH > Considering libpod-parser-perl:amd64 1 as a solution to libpod-coverage-perl:amd64 0 Holding Back libpod-coverage-perl:amd64 rather than change libpod-parser-perl:amd64 Investigating (0) libperl5.24:amd64 < 5.24.1-3+deb9u7 @ii gK Ib > Broken libperl5.24:amd64 Depends on perl-modules-5.24:amd64 < 5.24.1-3+deb9u7 @ii mR > (>= 5.24.1-3+deb9u7) Considering perl-modules-5.24:amd64 -2 as a solution to libperl5.24:amd64 -2 Removing libperl5.24:amd64 rather than change perl-modules-5.24:amd64 Try to Re-Instate (1) libpod-coverage-perl:amd64 Done Andreas
Bug#990455: unblock: rpm/4.16.1.2+dfsg1-2
Control: retitle -1 unblock: rpm/4.16.1.2+dfsg1-3
On Wed, Jun 30, 2021 at 02:15:43AM +0300, Peter Pentchev wrote:
> On Tue, Jun 29, 2021 at 09:02:43PM +0200, Sebastian Ramacher wrote:
> > Control: tags -1 moreinfo
> >
> > On 2021-06-29 20:15:33 +0300, Peter Pentchev wrote:
[snip]
> > > ++struct taglate_s {
> > > ++rpmTagVal stag;
> > > ++rpmTagVal xtag;
> > > ++rpm_count_t count;
> > > ++int quirk;
> > > ++} const xlateTags[] = {
[snip]
> >
> > Is this constant really supposed to be part of the public ABI? This
> > looks like it could use a static modifier.
>
> Hm, you are right. At least for the moment, it does not seem that
> anything else is using it, so it does not need to be exposed in
> the public library.
>
> I'll adapt the patch, drop the symbol from the library's symbols
> file (yes, I know, it would have been so much better if it had
> never actually hit the archive... true), and upload a new version.
>
> Thanks for making me stop and think about this!
Hi,
This should be fixed in 4.16.1.2+dfsg1-3 that I just uploaded to
unstable. FWIW, the upstream developers already accepted the patch:
https://github.com/rpm-software-management/rpm/pull/1737
(and I just realized that in the hurry to forward it upstream I plain
forgot to credit you for noticing it; sorry about that!)
Thanks again for spotting this!
unblock rpm/4.16.1.2+dfsg1-3
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#990470: unblock: neutron/17.1.1-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package neutron [ Reason ] The upstream release didn't include python3.9 in the possible python versions in the rootwrap configuration. [ Impact ] Neutron fails to kill the keepalived processes, resulting in a broken virtual router configuration whenever a router is deleted. [ Tests ] This isn't detected by the functional tests upstream (which uses Python 3.5 to Python 3.8), and the rootrwap tests aren't run in the unit tests. Though we successfully fixed the setup with the attached patch in production. [ Risks ] No risk, this is just enrichment of an already working config. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock neutron/17.1.1-6 diff -Nru neutron-17.1.1/debian/changelog neutron-17.1.1/debian/changelog --- neutron-17.1.1/debian/changelog 2021-05-17 20:47:34.0 +0200 +++ neutron-17.1.1/debian/changelog 2021-06-30 10:51:00.0 +0200 @@ -1,3 +1,9 @@ +neutron (2:17.1.1-6) unstable; urgency=medium + + * Add fix-rootwrap-does-not-include-python-3.9.patch. + + -- Thomas Goirand Wed, 30 Jun 2021 10:51:00 +0200 + neutron (2:17.1.1-5) unstable; urgency=high * CVE-2021-20267: Anti-spoofing bypass using Open vSwitch. Applied upstream diff -Nru neutron-17.1.1/debian/patches/fix-rootwrap-does-not-include-python-3.9.patch neutron-17.1.1/debian/patches/fix-rootwrap-does-not-include-python-3.9.patch --- neutron-17.1.1/debian/patches/fix-rootwrap-does-not-include-python-3.9.patch 1970-01-01 01:00:00.0 +0100 +++ neutron-17.1.1/debian/patches/fix-rootwrap-does-not-include-python-3.9.patch 2021-06-30 10:51:00.0 +0200 @@ -0,0 +1,16 @@ +Description: Fix rootwrap does not include python 3.9 +Author: Thomas Goirand +Bug-Debian: https://bugs.debian.org/985104 +Forwarded: no +Last-Update: 2021-06-30 + +--- neutron-17.1.1.orig/etc/neutron/rootwrap.d/l3.filters neutron-17.1.1/etc/neutron/rootwrap.d/l3.filters +@@ -70,6 +70,7 @@ kill_keepalived_monitor_py3: KillFilter, + kill_keepalived_monitor_py36: KillFilter, root, python3.6, -15, -9 + kill_keepalived_monitor_py37: KillFilter, root, python3.7, -15, -9 + kill_keepalived_monitor_py38: KillFilter, root, python3.8, -15, -9 ++kill_keepalived_monitor_py39: KillFilter, root, python3.9, -15, -9 + # For e.g. RHEL8 neutron-keepalived-state-change is run by "system python" + # which is /usr/libexec/platform-python3.6 so this should be in filters also. + # Path /usr/libexec isn't in PATH by default so it has to be given here as diff -Nru neutron-17.1.1/debian/patches/series neutron-17.1.1/debian/patches/series --- neutron-17.1.1/debian/patches/series2021-05-17 20:47:34.0 +0200 +++ neutron-17.1.1/debian/patches/series2021-06-30 10:51:00.0 +0200 @@ -1,2 +1,3 @@ Floating_IP_s_for_routed_networks.patch CVE-2021-20267_Restrict_IPv6_NA_and_DHCPv6_IP_and_MAC_source_addresses.patch +fix-rootwrap-does-not-include-python-3.9.patch
Bug#990471: [meta] support migration from diaspora-installer to diaspora
Package: diaspora Version: 0.7.15.0-2 Severity: important After installing diaspora-installer and migrating to diaspora package following https://wiki.debian.org/Diaspora#Experimental installation fails with Setting up diaspora (0.7.15.0-2) ... Your bundle only supports platforms [] but your local platform is x86_64-linux. Add the current platform to the lockfile with `bundle lock --add-platform x86_64-linux` and try again. dpkg: error processing package diaspora (--configure):
Bug#990483: python3-torchvision: HTTP Error: Service Unavailable, when downloading MNIST data with torchvision
Package: python3-torchvision
Version: 0.8.2-1
Severity: important
X-Debbugs-Cc: amribrahim1...@hotmail.com
Dear Maintainer,
I am getting an HTTPError: Service Unavailable when trying to download MNIST
dataset with torchvision.
Code to reproduce the bug:
from torchvision.datasets import MNIST
MNIST(".", download=True)
The issue is reported and fixed upstream:
https://github.com/pytorch/vision/issues/3549
By doing a little bit of research, these might be the fixing commits:
https://github.com/pytorch/vision/commit/9a08e47de1f8477faaea220dafa87d8fd376a151
https://github.com/pytorch/vision/commit/d5bc2b242038c1b2a3031d54e2961ebfdc0dc28e
https://github.com/pytorch/vision/commit/ad3bbef90707d6495803c59a3ef4910c91c5025e
https://github.com/pytorch/vision/commit/aa365993a297dfbcf82634a12747a0649c3356bd
https://github.com/pytorch/vision/commit/814c4f08bc9296a314ecb9e216648e0d059a3edc
Please backport the fix to Debian Bullseye 11.
Thanks,
Amr
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-7-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-torchvision depends on:
ii libc6 2.31-12
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii libtorch1.71.7.1-7
ii python33.9.2-3
ii python3-numpy 1:1.19.5-1
ii python3-pil8.1.2+dfsg-0.1
ii python3-torch 1.7.1-7
ii python3.9 3.9.2-1
python3-torchvision recommends no packages.
python3-torchvision suggests no packages.
-- no debconf information
Bug#990440: debianutils: manage /etc/shells declaratively using triggers
On Tue, Jun 29, 2021 at 08:01:49AM +0200, Helmut Grohne wrote: > Please refer to the mailing list discussion for details. I don't have time to do that right now, but I wonder if /etc/shells is really the only file that can/should be managed this way, or if this can be generalized further.
Bug#990447: fwupdmgr: Unable to install new updates
Hi, On Tue, Jun 29, 2021 at 02:04:47PM +0200, Salvatore Bonaccorso wrote: > Package: fwupd > Version: 1.5.7-4 > Severity: normal > X-Debbugs-Cc: car...@debian.org > > Hi > > I'm not entirely sure how to trackle this problem, since some time I'm > unable anymore to install updates available trough fwupdmgr. Secure > boot is enable, and in BIOS the 'boot order lock' *is* disabled. > > Though on every update, the firmware get's downloaded, the capsules > put in /boot/efi/EFI/debian/fw and reboot requested (and even choosing > the Linux Firmare Update manually) the firmware(s) are nut updated. > > The get-history command reflects that: > > cut-cut-cut-cut-cut-cut- > 20KGS05200 > │ > ├─LENSE30512GMSP34MEAT3TA: > │ │ Device ID: 04e17fcf7d3de91da49a163ffe4907855c3648be > │ │ Previous version: 1.4.0412 > │ │ Update State: Success > │ │ Last modified: 2020-10-01 23:11 > │ │ GUID: 124c38ac-0100-5a50-aac8-89602d99769f > │ │ Device Flags: • Internal device > │ │ • Updatable > │ │ • System requires external power source > │ │ • Supported on remote server > │ │ • Needs a reboot after installation > │ │ • Reported to remote server > │ │ • Device is usable for the duration of the update > │ │ > │ └─LENSE30512GMSP34MEAT3TA Device Update: > │ New version: 2.5.0412 > │ Remote ID:lvfs > │ Summary: Unionmemory LENSE30512GMSP34MEAT3TA NVMe SSD > Firmware for Lenovo PC > │ License: Proprietary > │ Size: 588.8 kB > │ Created: 2016-07-08 > │ Urgency: High > │ Vendor: Unionmemory > │ Description: > │ Do NOT turn off your computer or remove the AC adapter while update > is in progress. > │ > │ The computer shall be restarted after updating firmware completely. > The device may not properly function until you shut down or reboot PC > │ > │ Supported devices and firmware version : Unionmemory > LENSE30512GMSP34MEAT3TA-512G-2.5.0412 > │ > │ Supported Product Scope : Lenovo ThinkPad, ThinkCentre, ThinkStation, > IdeaCentre > │ > ├─Embedded Controller: > │ │ Device ID: 9698faabddf0d7b18925cfbbda95f8b0d0dacc53 > │ │ Previous version: 0.1.8 > │ │ Update State: Success > │ │ Last modified: 2020-11-17 16:05 > │ │ GUID: 3babca5f-b2bf-4f4b-a72e-2bdc84eb4019 > │ │ Device Flags: • Internal device > │ │ • Updatable > │ │ • System requires external power source > │ │ • Supported on remote server > │ │ • Needs a reboot after installation > │ │ • Reported to remote server > │ │ • Device is usable for the duration of the update > │ │ > │ └─ThinkPad X1 Carbon 6th Embedded Controller Update: > │ New version: 0.1.22 > │ Remote ID:lvfs > │ Summary: Lenovo ThinkPad X1 Carbon 6th Embedded Controller > Firmware > │ License: Proprietary > │ Size: 767.1 kB > │ Created: 2016-07-08 > │ Urgency: High > │ Vendor: Lenovo Ltd. > │ Description: > │ Lenovo ThinkPad X1 Carbon 6th Embedded Controller Firmware > │ > │ Fixed an issue where ThinkVision T24m-10 monitor might not connected > properly. > │ > ├─UEFI Device Firmware: > │ │ Device ID: 9e329270a7a68d289c82fe77d32d02208ddf0890 > │ │ Previous version: 0.73.4 > │ │ Update State: Success > │ │ Last modified: 2021-04-27 20:27 > │ │ GUID: cea87551-1701-43fb-afbc-6e8ce9728345 > │ │ Device Flags: • Internal device > │ │ • Updatable > │ │ • System requires external power source > │ │ • Supported on remote server > │ │ • Needs a reboot after installation > │ │ • Reported to remote server > │ │ • Device is usable for the duration of the update > │ │ > │ └─ThinkPad X1 Carbon 6th System Update: > │ New version: 0.73.20 > │ Remote ID:lvfs > │ Summary: Lenovo ThinkPad X1 Carbon 6th STM TPM Firmware > │ License: Proprietary > │ Size: 439.6 kB > │ Created: 2020-03-03 > │ Urgency: High > │ Vendor: Lenovo Ltd. > │ Description: > │ Lenovo ThinkPad X1 Carbon 6th STM TPM Firmware Version 73.20 > │ > │ • Do NOT turn off your computer or remove the AC adaptor while update > is in progress > │ > ├─Intel Management Engine: > │ │ Device ID:
Bug#990484: libreoffice-dictionaries: Character in debian/copyfile:3127,3220 breaks the paragraph unexpected
On Wed, Jun 30, 2021 at 01:42:20PM +0200, Zhi Han wrote: > After some debugging, I just found that it was failed at validation of the > copyright file, > by the Python deb822. More specific, the Character (which might be > Line Seperate) > in line 3127 and 3220 of file copyright is treated by the Python deb822 as > blank line, and > cause this failure. What an amusing thing, would be interesting to know how such char made its way in. I've commited the changes, but such minor bugs will only be fixed for the next stable release, which will be bookworm. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#990485: node-nodemailer: CVE-2021-23400
Source: node-nodemailer Version: 6.4.17-2 Severity: important Tags: security upstream Forwarded: https://github.com/nodemailer/nodemailer/issues/1289 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for node-nodemailer. CVE-2021-23400[0]: | The package nodemailer before 6.6.1 are vulnerable to HTTP Header | Injection if unsanitized user input that may contain newlines and | carriage returns is passed into an address object. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-23400 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23400 [1] https://github.com/nodemailer/nodemailer/issues/1289 [2] https://github.com/nodemailer/nodemailer/commit/7e02648cc8cd863f5085bad3cd09087bccf84b9f [3] https://snyk.io/vuln/SNYK-JS-NODEMAILER-1296415 Regards, Salvatore
Bug#984760: grub-pc: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
I have something to add to this. This morning I was writing up a document on how to convert an existing Debian amd64 AWS VM to arm64 without reinstalling, which is something I was interested in doing in the future to a fairly complex system install that I wasn't excited about trying to reinstall/migrate. Everything worked with the conversion, except for the grub stage, grub failed to start on the ARM instance and was stuck at the grub-rescue prompt. When typing "insmod normal", it shows the "symbol `grub_is_lockdown` not found" error. I managed to get it working by copying grub modules from an existing Debian ARM VM over to it, I did that because I noticed that the modules were of a newer version and a different size. I'm not sure if the "grub-install" step was needed, but after investigating I found that when I ran grub-install a standard Debian-provided ARM AWS community instance and rebooted, the instance fails to boot in the same way. This is my document if you were interested, I mention the error in it: https://ryan.thoryk.com/linux/arm_convert.html -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#989778: Regression in at least 5.10.y and mainline: Firewire audio interface fails to work properly (when booted under Xen)
Hi,
On Sun, Jun 27, 2021 at 04:17:03AM +1000, 小太 wrote:
> On Thu, 24 Jun 2021 at 04:50, Salvatore Bonaccorso
> wrote:
>
> > Hi Robin,
> >
> > On Mon, Jun 14, 2021 at 02:29:08PM +0100, Robin Murphy wrote:
> > > On 2021-06-13 07:29, Salvatore Bonaccorso wrote:
> > > > A user in Debian reported the above issue, which was reproducible with
> > > > 5.13-rc5 and 5.10.y as packaged in Debian and found that 85a5a6875ca9
> > > > ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") that
> > > > introduced the issue.
> > >
> > > Sounds like it's probably the same thing as being discussed over here:
> > >
> > >
> > https://lore.kernel.org/linux-iommu/2e899de2-4b69-c4b6-33a6-09fb8949d...@nxp.com/
> >
> > Thanks for the pointer, it seems that now it has been fixed upstream
> > with 5f89468e2f06 ("swiotlb: manipulate orig_addr when tlb_addr has
> > offset").
> >
>
> I've checked out upstream v5.13 b7050b242430f3170e0b57f5f55136e44cb8dc66
> (which includes the above commit) and confirmed that my issue is now
> resolved.
> Now to wait for it to reach Debian :)
The commit has been backported and queued for 5.10.y now as well, so
will reach Debian as well. I'm cherry-picking the commit as well in
the packaging repository.
Regards,
Salvatore
Bug#990486: mtools: mcopy -b crashes with "Internal error, size too big"
Package: mtools Version: 4.0.31-1 Severity: minor I have a script that uses mtools to create a FAT partition and it has stopped working with recent mtools versions: + dd if=/dev/zero of=img.tmp bs=512 count=100031 100031+0 records in 100031+0 records out 51215872 bytes (51 MB, 49 MiB) copied, 0,0473954 s, 1,1 GB/s + mformat -i img.tmp + mcopy -i img.tmp -sb /usr/share/common-licenses :: Internal error, size too big Streamcache allocation problem:: 4 This worked with 4.0.26-1 (currently in testing). It also works without the -b flag. The -b flag is described as an optimization, so a simple workaround for anyone affected is to stop using -b. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 5.10.0-7-amd64 (SMP w/32 CPU threads) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_DK.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mtools depends on: ii libc6 2.31-12 mtools recommends no packages. Versions of packages mtools suggests: pn floppyd -- Configuration Files: /etc/mtools.conf changed: drive a: file="/dev/fd0" exclusive drive b: file="/dev/disk/by-id/usb-MITSUMI0_MITSUMI0" exclusive drive m: file="/var/lib/dosemu/hdimage.first" partition=1 offset=128 drive n: file="/var/lib/dosemu/fdimage" -- no debconf information
Bug#990487: RFP: sourcetrail -- source code explorer
Package: wnpp Severity: wishlist * Package name: sourcetrail Version : 2021.1.30 Upstream Author : Coati Software * URL : https://github.com/CoatiSoftware/Sourcetrail * License : GPLv3 Programming Lang: C++ Description : source code explorer Help navigate and understand codebases. Shows relations between classes, attributes, types and so on. Supports C, C++, Java and Python. Runs locally.
Bug#990458: Attaching the files from buster vs bullseye
On Tue, 29 Jun 2021 23:54:30 +0530 Pirate Praveen
wrote:
> I can confirm libjs-autosize from buster works fine with diaspora.
>
> Buster version has this,
>
> (function (global, factory) {
> if (typeof define === "function" && define.amd) {
> define(['module', 'exports'], factory);
>
> But bullseye version is missing definition for module,
>
> (function (global, factory) {
> if (typeof define === "function" && define.amd) {
> define(["exports"], factory);
Akshay,
Any ideas about this? Basically it is a behavior change from babel 6 to
babel 7 and we'd like to restore the babel 6 behavior.
Bug#990458: Attaching the files from buster vs bullseye
On Tue, 29 Jun 2021 23:54:30 +0530 Pirate Praveen wrote: > I can confirm libjs-autosize from buster works fine with diaspora. So workaround is to install the buster version from snapshot.debian.org http://snapshot.debian.org/archive/debian/20190209T090056Z/pool/main/a/autosize.js/libjs-autosize_4.0.2~dfsg1-3_all.deb
Bug#980392: calendar: oldconfig /etc/calendar/default
Also, /etc/calendar is left over. I had basically the case of upgrading from buster to bullseye first: Unpacking bsdmainutils (12.1.7+nmu3) over (11.1.2+b1) ... dpkg: warning: unable to delete old directory '/etc/calendar': Directory not empty ..and afterwards purging ncal. But /etc/calendar remains as an empty dir.
Bug#990488: statsvn: Package in stable does not work
Package: statsvn Version: 0.7.0.dfsg-9 Severity: grave Justification: renders package unusable Dear Maintainer, When trying to use the statsvn utility, this fatal error message is encountered: SEVERE: Subversion binary is incorrect version. Found: 1.10.4, required: 1.3.0 This makes the utility broken on both stable and testing. It appears that FreeBSD has a patch for this, that disables the version check: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229325 -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages statsvn depends on: ii default-jre [java-runtime] 2:1.11-71 ii java-wrappers 0.3 ii libsvnkit-java 1.8.14-3 ii openjdk-11-jre [java-runtime] 11.0.11+9-1~deb10u1 ii statcvs1:0.7.0.dfsg-7 ii subversion 1.10.4-1+deb10u2 statsvn recommends no packages. statsvn suggests no packages. -- no debconf information
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Package: python3-expeyes Version: 4.8.7+repack-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + eyes17 Hi Georges, while investigating incomplete buster->bullseye upgrades, I came across the Conflicts: modemmanager in python3-expeyes. Why was that added? It is not mentioned in the changelog and the git commit introducing it doesn't explain it either. Should this have been a versioned Breaks instead? The modemmanager package still exists in bullseye, so what should be the desired buster->bullseye upgrade outcome for buster systems with both modemmanager and python3-expeyes installed (that happens e.g. when installing eyes17/buster with --install-recommends)? Andreas
Bug#990458: Attaching the files from buster vs bullseye
This is most likely due to babel-plugin-add-module-exports being broken. See https://github.com/59naga/babel-plugin-add-module-exports/issues/72 and https://github.com/59naga/babel-plugin-add-module-exports/issues/80 and https://github.com/59naga/babel-plugin-add-module-exports/issues/73 That 73 points to a new version that's put only on npm and not on github. I'm not exactly sure how it works with fakeupstream at https://salsa.debian.org/js-team/node-babel-plugin-add-module-exports/-/tree/master/ Either way, the version in salsa seems to be 0.2.1 which is definitely outdated (as per the github description of babel-plugin-add-module-exports Two ways I see are: Either, update this plugin in Debian to the fork that's pushed only to npm (or switch to https://github.com/lijunle/babel-plugin-add-module-exports/ I guess) OR Try removing this plugin altogether and changing the "export default autosize" statement in the last line of autosize.js to "module.exports = autosize" I'm NOT sure whether either of these will work.
Bug#990490: cryptsetup: leftover configuration
Package: cryptsetup Version: 2:2.3.5-1 Severity: normal Hi. During a test upgrade from buster to bullseye I've noted: Unpacking resolvconf (1.87) over (1.79) ... dpkg: warning: unable to delete old directory '/etc/init': Directory not empty The reason seems to be that there are leftover files from cryptsetup: /etc/init/cryptdisks.conf /etc/init/cryptdisks-udev.conf which were apparently dropped in 2cd1701a but never properly cleaned up for legacy installations. Could you please do so in a future upgrade? Unfortunately there is ne nice way to drop /etc/init itself now. guess you could try to check whether it's still registered with some package (dpkg -S /etc/init) and if not try to rmdir it. Cheers, Chris.
Bug#990491: unblock: darktable/3.4.1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please unblock package darktable [ Reason ] The new version fixes an unclosed comment in the Italian translation of user.css. If the user triggers the creation of this file (e.g. by adding a keyboard shortcut in the preferences), then the GUI is somewhat mangled. [ Impact ] Probably further confusion for Italian speaking users of darktable. There is a fairly simple workaround (fix the comment in user.css), if the user seeks help and/reports the problem. The fact that it only happens in Italian locales makes it trickier for users to figure out the problem. OTOH I guess from a utilitarian point of view it also affects less users. [ Tests ] I've run the new version under it_IT.utf8 and en_CA.utf8 locales. Both seem OK, and I can define keyboard shortcuts without trashing the GUI. [ Risks ] Darktable is a leaf package; the change is one line cherry-picked from upstream. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] (Anything else the release team should know.) unblock darktable/3.4.1-5 -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmDcjM0ACgkQA0U5G1Wq FSGAvw//YjMLahGNm+kbIBBHz4FKC5c8ZnKTNJPt9s8b5lvrM4EsYUEMMuxRkSUA ARZWKnDlB/IoLgjzcmOiOlCknDTP90W8P3oWDALMIjHzwJVqZBm54rDblKJKAzFI Egb+5WPMEgxHTLzEg7vA/gyeAiF/k2sliSAOxRJLGdYDAbJfFHmpUYGjqZvcf7S/ owZmz6tFUnjQmTdlnLycg34vzBrfM1e7G2xFONoHKNWq2WDRMjcHVKC7Gxx/ApdX QYjzC5t3eRqPiC4ZN+50EU+j+5i1qlwGPY1L2K9fOC3miOpFpnoBxSxpsgIQMf2x Utkt4DzufQ7M2Y3SVr2JAQ7ROce3NsAebN3ywm3P3Ld1kAmpFTndjj2vFBf5b7aP BgPiyR1f2/ID1UbxWsmahpZolc12oXEYqaaK9tVhCAy4sEon3XktSP9gcOhzoTav fSHjf/Cq0rrRgQIxaggpFbA9HWzL9RQGBzDi2b+PluwfBAHLhlgHu59QA8ExW8SK rLxHQwMLNkTcSiq8/ay1Z1Y1RPXjAJAy1ARRZ4CZnaNTRi3HgIrkq6dyfjaTyBFF NgEZtUjc3zwaurVRyV/WrIVyWzVzGlnC3W5X/XhKUghsFL7cJ61UCI+FfwIBF6tq f/x+Mw0iBtzqi4OEJbVRx2fkaHr6c/SgJkyriDuuvvmTwX+/o/c= =7OD0 -END PGP SIGNATURE- diff -Nru darktable-3.4.1/debian/changelog darktable-3.4.1/debian/changelog --- darktable-3.4.1/debian/changelog2021-06-05 12:41:39.0 -0300 +++ darktable-3.4.1/debian/changelog2021-06-30 09:37:35.0 -0300 @@ -1,3 +1,11 @@ +darktable (3.4.1-5) unstable; urgency=medium + + * Bug fix: "configuring shortcuts breaks filemanager gui at next start +filemanager issueVersion: 3.4.1-4", thanks to stef.binde (Closes: +#990405). Closed by cherry-picking upstream commit 154e945f. + + -- David Bremner Wed, 30 Jun 2021 09:37:35 -0300 + darktable (3.4.1-4) unstable; urgency=medium * Bug fix: "crashes with 'Floating point exception (core dumped)' after diff -Nru darktable-3.4.1/debian/patches/0003-it-fix-wrong-translation-breaking-the-CSS.patch darktable-3.4.1/debian/patches/0003-it-fix-wrong-translation-breaking-the-CSS.patch --- darktable-3.4.1/debian/patches/0003-it-fix-wrong-translation-breaking-the-CSS.patch 1969-12-31 20:00:00.0 -0400 +++ darktable-3.4.1/debian/patches/0003-it-fix-wrong-translation-breaking-the-CSS.patch 2021-06-30 09:37:35.0 -0300 @@ -0,0 +1,22 @@ +From: Pascal Obry +Date: Thu, 7 Jan 2021 09:49:25 +0100 +Subject: it: fix wrong translation breaking the CSS. + +(cherry picked from commit 154e945f4bef98de82eff728a6485b1c6c4d79c5) +--- + po/it.po | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/po/it.po b/po/it.po +index 3fb64aa..73be374 100644 +--- a/po/it.po b/po/it.po +@@ -7586,7 +7586,7 @@ msgid "" + "/* Enter CSS theme tweaks here */\n" + "\n" + msgstr "" +-"/* Inserisci le modifiche al CSS qui /*\n" ++"/* Inserisci le modifiche al CSS qui */\n" + "\n" + + #: ../src/gui/preferences.c:546 diff -Nru darktable-3.4.1/debian/patches/series darktable-3.4.1/debian/patches/series --- darktable-3.4.1/debian/patches/series 2021-06-05 12:41:39.0 -0300 +++ darktable-3.4.1/debian/patches/series 2021-06-30 09:37:35.0 -0300 @@ -1,2 +1,3 @@ 0001-add-explicit-dependency-on-generate_conf.patch 0002-Avoid-div-by-zero-in-dt_iop_clip_and_zoom_mosaic_hal.patch +0003-it-fix-wrong-translation-breaking-the-CSS.patch
Bug#990484: libreoffice-dictionaries: Character in debian/copyfile:3127,3220 breaks the paragraph unexpected
Source: libreoffice-dictionaries Version: 1:6.2.0-1 Severity: normal Dear Maintainer, When I install the package hunspell-en-gb and hypfen-en-gb in an ELBE(https://elbe-rfs.org/) environment, exception is raised with message "value must not have blank lines". After some debugging, I just found that it was failed at validation of the copyright file, by the Python deb822. More specific, the Character (which might be Line Seperate) in line 3127 and 3220 of file copyright is treated by the Python deb822 as blank line, and cause this failure. -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#990493: node-babel-plugin-add-module-exports broken with babel-preset-env 7
Package: node-babel-plugin-add-module-exports Version: 0.2.1-3 Severity: grave Justification: creates broken build output Control: forwarded -1 https://github.com/59naga/babel-plugin-add-module-exports/issues/73 Control: block 990458 by -1 Upstream has released a fix in major update. Since we are in freeze I'm not sure how to proceed here. This affects many packages. $ reverse-depends -b node-babel-plugin-add-module-exports Reverse-Build-Depends * autosize.js * node-babel-plugin-lodash * node-colormin * node-css-loader * node-deep-for-each * node-es6-promise * node-handlebars * node-i18next-http-backend
Bug#989697: taking this
Control: retitle -1 ITP: jpegqs -- JPEG artifacts removal tool Control: owner -1 ! Decrapifing JPEGs is an useful thing. I'm this taking this request. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Bug#990458: Attaching the files from buster vs bullseye
On Wed, Jun 30, 2021 at 8:27 pm, Akshay S Dinesh wrote: This is most likely due to babel-plugin-add-module-exports being broken. See https://github.com/59naga/babel-plugin-add-module-exports/issues/72 and https://github.com/59naga/babel-plugin-add-module-exports/issues/80 and https://github.com/59naga/babel-plugin-add-module-exports/issues/73 That 73 points to a new version that's put only on npm and not on github. I'm not exactly sure how it works with fakeupstream at https://salsa.debian.org/js-team/node-babel-plugin-add-module-exports/-/tree/master/ Either way, the version in salsa seems to be 0.2.1 which is definitely outdated (as per the github description of babel-plugin-add-module-exports Two ways I see are: Either, update this plugin in Debian to the fork that's pushed only to npm (or switch to https://github.com/lijunle/babel-plugin-add-module-exports/ I guess) I think we can take the last tagged version 1.0.0 and apply a patch to make it 1.0.2. OR Try removing this plugin altogether and changing the "export default autosize" statement in the last line of autosize.js to "module.exports = autosize" It looks like many packages build depend on this module and those are also likely broken. I opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990493 to track this. I'm NOT sure whether either of these will work. Thanks for the pointers, at least we know what is broken and what the fix is. We just have to figure out the best way to include it.
Bug#981815: Please explain
X-Debbugs-CC: serfyo...@yandex.ru
On Wed, Jun 30, 2021 at 05:27:45PM +0300, Сергей Фёдоров wrote:
> Sorry for the late response - I just went to the mail and did not
> expect a letter from you.
>
> I wanted to use sudo to delete the list of root owner files whose
> names are placed in the file.
Your first example is probably wrong because using '<' in sudoers
files is a syntax error, and the shell would interpret it anyway, so
sudo would never see it.
In your second and third examples the same rule applies. Also, your
executed command differs from that in sudoers ('-0t' vs. '-t'), so
sudo asks for a password.
Remember: sudo is not a shell, and it does no processing of shell meta
characters. To work with a defined sudoers entry, the beginning of
the command (after evaluation of meta characters by the shell) must
match /exactly/ what is specified in sudoers (absolute paths,
parameter order etc.). Additional parameters can be added, but what
is specified in sudoers must not be omitted nor rearranged.
I find the easiest way to inspect what the ultimately executed command
will look like after meta character evaluation is by processing the
output of strace, e.g. like so:
printf '/dev/null\n/dev/zero\n' > /tmp/files
strace -o '|grep execve' -e trace=execve \
-s 4096 -f sh -c "/usr/bin/xargs \
-a /tmp/files -n 1 -d '\n' /usr/bin/stat"
Notice that strace does some escaping of special characters like '\n'
in its output itself, so you have to be mindful of that.
Regards,
Dennis.
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Dear Andreas, I added in Cc: the authors of Expeyes hardware and software. Hello Jithin, Ajith! the context about the bug report with serious severity is below. I ignored that a statement like "Conflicts: modemmanager" would create problems with buster->bullseye upgrades. Currently, binary packages conflicting with modemmanager are: eyes17, python3-expeyes, firm-phoenix-ware. The first one, eyes17, will be the most used. This statement was added because boxes of the Expeyes family do not communicate correctly by their serial link when modemmanager is installed. I did not investigate further, to know the precise reason of the incompatibility. I got e-mails of some users of previous versions of expeyes packages, who could not activate their boxes, and my reply was to uninstall modemmanager or upgrade to the new version of eyes17 package. The number of Expeyes users is currently growing in Kerala (a southern state of India), and they rely on *eyes17* package, some with a Debian machine, most with an Ubuntu machine. This community is growing since Eyes17 box has become an officially encouraged scientific device, to be distributed to all high schools in the state, together with training. I cannot withdraw the confict statement without damaging this user community in the future. Hence the next question: How would it be possible to keep expeyes packages in the soon-to-come Debian/Stable distribution? The package modemmanager is recommended by widely used packages, like network-manager, while eyes17 is recommended by no package. I do not know how many users do really need modemmanager, or use modems. However I know better the profile of users who use eyes17: they are students and teachers, wo interact inside a high school. Then, the link with Internet is generally provided by some router or some wireless box, and no modem is used. @Jitin, @Ajith: can you give please an estimate of the user community for eyes17 now, and in a near future? Best regards, Georges. Andreas Beckmann a écrit : > Package: python3-expeyes > Version: 4.8.7+repack-4 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > Control: affects -1 + eyes17 > > Hi Georges, > > while investigating incomplete buster->bullseye upgrades, I came across > the Conflicts: modemmanager in python3-expeyes. Why was that added? > It is not mentioned in the changelog and the git commit introducing it > doesn't explain it either. > Should this have been a versioned Breaks instead? > > The modemmanager package still exists in bullseye, so what should be the > desired buster->bullseye upgrade outcome for buster systems with both > modemmanager and python3-expeyes installed (that happens e.g. when > installing eyes17/buster with --install-recommends)? > > > Andreas -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#990458: [Pkg-javascript-devel] Bug#990458: Attaching the files from buster vs bullseye
On Wed, Jun 30, 2021 at 9:30 pm, Pirate Praveen wrote: On Wed, Jun 30, 2021 at 8:27 pm, Akshay S Dinesh wrote: Either, update this plugin in Debian to the fork that's pushed only to npm (or switch to https://github.com/lijunle/babel-plugin-add-module-exports/ I guess) I think we can take the last tagged version 1.0.0 and apply a patch to make it 1.0.2. Looks like we are already using the dist tarballs and does not involve any build, we can just take the latest 1.0.4 from npmjs.com.
Bug#990494: texlive-latex-extra: missing dependency on texlive-science for invoice.sty
Package: texlive-latex-extra
Version: 2020.20210202-3
Severity: normal
Hi TeX Team,
texlive-latex-extra contains invoice.sty which depends on siunitx from
the texlive-science package but does not declare a dependency.
Without texlive-science installed:
$ latex -recorder examples.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=latex)
restricted \write18 enabled.
entering extended mode
(./examples.tex
LaTeX2e <2020-10-01> patch level 4
L3 programming layer <2021-01-09> xparse <2020-03-03>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)) (./invoice.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/calc.sty)
! LaTeX Error: File `siunitx.sty' not found.
##
A minimal example.tex:
\documentclass{article}
\usepackage{invoice}
\begin{document}
Foo
\end{document}
##
List of ls-R files
lrwxrwxrwx 1 root root 31 Feb 17 21:30 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
##
Config files
-rw-r--r-- 1 root root 475 Feb 13 08:36 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 17 21:30 /usr/share/texmf/web2c/fmtutil.cnf ->
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 17 21:30 /usr/share/texmf/web2c/updmap.cfg ->
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3106 Jun 30 17:50
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jul 31 2019 mktex.cnf
-rw-r--r-- 1 root root 475 Feb 13 08:36 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf
-- System Information:
Debian Release: 11.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/8 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 texlive-latex-extra depends on:
ii libcommons-logging-java1.2-2
ii libpdfbox-java 1:1.8.16-2
ii preview-latex-style12.2-1
ii python33.9.2-3
ii tex-common 6.16
ii texlive-base 2020.20210202-3
ii texlive-binaries 2020.20200327.54578-7
ii texlive-latex-recommended 2020.20210202-3
ii texlive-pictures 2020.20210202-3
Versions of packages texlive-latex-extra recommends:
ii texlive-fonts-recommended 2020.20210202-3
pn texlive-plain-generic
Versions of packages texlive-latex-extra suggests:
pn icc-profiles
ii libfile-which-perl 1.23-1
pn libspreadsheet-parseexcel-perl
ii python3-pygments2.7.1+dfsg-2.1
pn texlive-latex-extra-doc
Versions of packages tex-common depends on:
ii dpkg 1.20.9
ii ucf 3.0043
Versions of packages tex-common suggests:
ii debhelper 13.3.4
Versions of packages texlive-latex-extra is related to:
ii tex-common6.16
ii texlive-binaries 2020.20200327.54578-7
-- no debconf information
Bug#990458: [Pkg-javascript-devel] Bug#990458: Bug#990458: Attaching the files from buster vs bullseye
On Wed, Jun 30, 2021 at 9:38 pm, Pirate Praveen wrote: Looks like we are already using the dist tarballs and does not involve any build, we can just take the latest 1.0.4 from npmjs.com. Scratch that, the new versions use babel to build, so I think using https://github.com/lijunle/babel-plugin-add-module-exports/ is the best option, though the latest version tagged is 1.0.2 and latest npm release is 1.0.4 (basically completely messed up release workflow).
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Dear Georges, The modem-manager probes serial ports with random AT commands causing communication errors in a wide range of devices which use the serial port, most common ones being embedded development tools such as for the Arduino , PIC etc. This issue has been reported in many forums - https://mail.gnome.org/archives/networkmanager-list/2013-October/msg00038.html - https://askubuntu.com/questions/1231894/modemmanager-conflicts-with-arduino - https://github.com/ubuntu/ubuntu-make/issues/4 In case of ExpEYES, random communication errors, and subsequent data loss occurs during data acquisition tasks if Modem Manager is running in the background. Perhaps there is some way to place a lock on the active serial port to prevent MM from probing it. One suggestion that needs to be rigorously tested is to blacklist the serial device of ExpEYES(VendorID:ProductID) for Modem Manager so that it will ignore it. https://askubuntu.com/questions/1231894/modemmanager-conflicts-with-arduino The user community is currently in the range of a few thousands, and is expected to grow, so a solution must be quickly resolved after studying which serial devices Modem-Manager automatically likes to probe, and to keep ExpEYES ( ID 04d8:00df Microchip Technology, Inc.) out of that list. More about ExpEYES - https://expeyes.in/ - https://csparkresearch.in/expeyes17/ - https://csparkresearch.in/expeyes17/blog Regards, Jithin On Wed, Jun 30, 2021 at 9:36 PM Georges Khaznadar wrote: > Dear Andreas, > > I added in Cc: the authors of Expeyes hardware and software. > > Hello Jithin, Ajith! the context about the bug report with serious > severity is below. > > > > I ignored that a statement like "Conflicts: modemmanager" would create > problems with buster->bullseye upgrades. Currently, binary packages > conflicting with modemmanager are: eyes17, python3-expeyes, > firm-phoenix-ware. The first one, eyes17, will be the most used. > > This statement was added because boxes of the Expeyes family do not > communicate correctly by their serial link when modemmanager is > installed. I did not investigate further, to know the precise reason of > the incompatibility. > > I got e-mails of some users of previous versions of expeyes packages, > who could not activate their boxes, and my reply was to uninstall > modemmanager or upgrade to the new version of eyes17 package. > > The number of Expeyes users is currently growing in Kerala (a southern > state of India), and they rely on *eyes17* package, some with a Debian > machine, most with an Ubuntu machine. This community is growing since > Eyes17 box has become an officially encouraged scientific device, to be > distributed to all high schools in the state, together with training. > > I cannot withdraw the confict statement without damaging this user > community in the future. > > Hence the next question: > > > How would it be possible to keep expeyes packages in the soon-to-come > Debian/Stable distribution? > > The package modemmanager is recommended by widely used packages, like > network-manager, while eyes17 is recommended by no package. > > I do not know how many users do really need modemmanager, or use modems. > > However I know better the profile of users who use eyes17: they are > students and teachers, wo interact inside a high school. Then, the link > with Internet is generally provided by some router or some wireless box, > and no modem is used. > > @Jitin, @Ajith: > can you give please an estimate of the user community for eyes17 now, > and in a near future? > > Best regards, Georges. > > Andreas Beckmann a écrit : > > Package: python3-expeyes > > Version: 4.8.7+repack-4 > > Severity: serious > > User: debian...@lists.debian.org > > Usertags: piuparts > > Control: affects -1 + eyes17 > > > > Hi Georges, > > > > while investigating incomplete buster->bullseye upgrades, I came across > > the Conflicts: modemmanager in python3-expeyes. Why was that added? > > It is not mentioned in the changelog and the git commit introducing it > > doesn't explain it either. > > Should this have been a versioned Breaks instead? > > > > The modemmanager package still exists in bullseye, so what should be the > > desired buster->bullseye upgrade outcome for buster systems with both > > modemmanager and python3-expeyes installed (that happens e.g. when > > installing eyes17/buster with --install-recommends)? > > > > > > Andreas > > -- > Georges KHAZNADAR et Jocelyne FOURNIER > 22 rue des mouettes, 59240 Dunkerque France. > Téléphone +33 (0)3 28 29 17 70 > > -- jithin
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
On 30/06/2021 18.06, Georges Khaznadar wrote: I ignored that a statement like "Conflicts: modemmanager" would create problems with buster->bullseye upgrades. Currently, binary packages conflicting with modemmanager are: eyes17, python3-expeyes, firm-phoenix-ware. The first one, eyes17, will be the most used. So the current buster->bullseye upgrade outcome is not what you would desire: * eyes17 removed * modemmanager still installed * python3-expexes kept at the buster version This statement was added because boxes of the Expeyes family do not communicate correctly by their serial link when modemmanager is installed. I did not investigate further, to know the precise reason of the incompatibility. Is this incompatibility still the case with current modemmanager (1.14) in buster? The number of Expeyes users is currently growing in Kerala (a southern state of India), and they rely on *eyes17* package, some with a Debian machine, most with an Ubuntu machine. This community is growing since Eyes17 box has become an officially encouraged scientific device, to be distributed to all high schools in the state, together with training. That's a nice piece of hardware you have there ;-) However I know better the profile of users who use eyes17: they are students and teachers, wo interact inside a high school. Then, the link with Internet is generally provided by some router or some wireless box, and no modem is used. I haven't looked into modemmanager at all ... is it possible to "disable" it from the eyes17 side? Deactivating the service might be sufficient? Dropping a conffile somewhere to block it from using certain devices? Diverting the binary away? Andreas
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Dear Jithin,
thank you for your very fast response.
I attach the file eyes_udev.sh, which is called upon eyes17's
post-installation, as "eyes_udev.sh enable", thus creating or keeping
the file /lib/udev/rules.d/99-phoenix.rules, with this content:
---8<- /lib/udev/rules.d/99-phoenix.rules --
# udev rules for expEYES interface: AVR, FT232, MCP2200 and CH340
SUBSYSTEM=="usb",ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="21ff", MODE="666"
SUBSYSTEM=="tty",ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="666"
SUBSYSTEM=="tty",ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", MODE="666"
SUBSYSTEM=="tty",ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="666"
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="21ff", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ENV{ID_MM_DEVICE_IGNORE}="1"
# interest_eyes17
---8<-
Please can you check whether ATTRS{idVendor}=="03eb", ... "0403",
"04d8", ... "1a86" will be enough to blacklist our boxes' interfaces for
modemmanager, and eventually the interface of eyes17?
Then, please can you check that installing modemmanager will let Eyes17
boxes in peace, when such a rule is activated for udev?
Currently, my Eyes17 box is lended to a colleague who is trying the
complete list of experiments of the User Manual, while reviewing the
Spanish version, and might want to buy such boxes, for his technical
school. I can ask him to give it back, and he would do it shortly, but
he asked me two days ago whether I could lend the box some longer; I
did not know that I would get a bug report today :)
Best regards, Georges.
jithin bp a écrit :
> Dear Georges,
>
> The modem-manager probes serial ports with random AT commands causing
> communication errors in a wide range of devices which use the serial port,
> most common ones being embedded development tools such as for the Arduino ,
> PIC etc.
> This issue has been reported in many forums
> -
> https://mail.gnome.org/archives/networkmanager-list/2013-October/msg00038.html
> -
> https://askubuntu.com/questions/1231894/modemmanager-conflicts-with-arduino
> - https://github.com/ubuntu/ubuntu-make/issues/4
>
> In case of ExpEYES, random communication errors, and subsequent data loss
> occurs during data acquisition tasks if Modem Manager is running in the
> background. Perhaps there is some way to place a lock on the active serial
> port to prevent MM from probing it.
>
> One suggestion that needs to be rigorously tested is to blacklist the
> serial device of ExpEYES(VendorID:ProductID) for Modem Manager so that it
> will ignore it.
> https://askubuntu.com/questions/1231894/modemmanager-conflicts-with-arduino
>
> The user community is currently in the range of a few thousands, and is
> expected to grow, so a solution must be quickly resolved after studying
> which serial devices Modem-Manager automatically likes to probe, and to
> keep ExpEYES ( ID 04d8:00df Microchip Technology, Inc.) out of that list.
>
>
> More about ExpEYES
> - https://expeyes.in/
> - https://csparkresearch.in/expeyes17/
> - https://csparkresearch.in/expeyes17/blog
>
> Regards,
> Jithin
>
> On Wed, Jun 30, 2021 at 9:36 PM Georges Khaznadar
> wrote:
>
> > Dear Andreas,
> >
> > I added in Cc: the authors of Expeyes hardware and software.
> >
> > Hello Jithin, Ajith! the context about the bug report with serious
> > severity is below.
> >
> >
> >
> > I ignored that a statement like "Conflicts: modemmanager" would create
> > problems with buster->bullseye upgrades. Currently, binary packages
> > conflicting with modemmanager are: eyes17, python3-expeyes,
> > firm-phoenix-ware. The first one, eyes17, will be the most used.
> >
> > This statement was added because boxes of the Expeyes family do not
> > communicate correctly by their serial link when modemmanager is
> > installed. I did not investigate further, to know the precise reason of
> > the incompatibility.
> >
> > I got e-mails of some users of previous versions of expeyes packages,
> > who could not activate their boxes, and my reply was to uninstall
> > modemmanager or upgrade to the new version of eyes17 package.
> >
> > The number of Expeyes users is currently growing in Kerala (a southern
> > state of India), and they rely on *eyes17* package, some with a Debian
> > machine, most with an Ubuntu machine. This community is growing since
> > Eyes17 box has become an officially encouraged scientific device, to be
> > distributed to all high schools in the state, together with training.
> >
> > I cannot withdraw the confict statement without damaging this user
> > community in the future.
> >
> > Hence the next question:
> >
> >
> > How would it be possible to keep expeye
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Sorry, here is the forgotten attachment, on e-mail later as usual. eyes_udev.sh Description: Bourne shell script signature.asc Description: PGP signature
Bug#990458: [Pkg-javascript-devel] Bug#990458: Bug#990458: Bug#990458: Attaching the files from buster vs bullseye
On Wed, Jun 30, 2021 at 9:44 pm, Pirate Praveen wrote: On Wed, Jun 30, 2021 at 9:38 pm, Pirate Praveen wrote: Looks like we are already using the dist tarballs and does not involve any build, we can just take the latest 1.0.4 from npmjs.com. Scratch that, the new versions use babel to build, so I think using https://github.com/lijunle/babel-plugin-add-module-exports/ is the best option, though the latest version tagged is 1.0.2 and latest npm release is 1.0.4 (basically completely messed up release workflow). With babel-plugin-add-module-exports 1.0.4 from the above repo, $ diff -u autosize-current.js autosize.js --- autosize-current.js 2021-06-30 22:30:00.391798535 +0530 +++ autosize.js 2020-12-14 17:42:45.0 +0530 @@ -284,5 +284,5 @@ var _default = autosize; _exports["default"] = _default; - module.exports = exports["default"]; + module.exports = exports.default; }); \ No newline at end of file and this is working with diaspora. Thanks again for tracking down the issue.
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
On 30/06/2021 18.22, jithin bp wrote:
One suggestion that needs to be rigorously tested is to blacklist the
serial device of ExpEYES(VendorID:ProductID) for Modem Manager so that it
will ignore it.
https://askubuntu.com/questions/1231894/modemmanager-conflicts-with-arduino
That sounds very promising.
Corresponding ModemManager documentation is
https://www.freedesktop.org/software/ModemManager/api/latest/ref-overview-modem-filter.html
So maybe the solution is shipping in eyes17 (or a better fitting package?)
/lib/udev/rules.d/78-mm-blacklist-expeyes.rules with this content:
= 8< =
ACTION!="add|change|move", GOTO="mm_blacklist_expeyes_end"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", ENV{ID_MM_DEVICE_IGNORE}="1"
LABEL="mm_blacklist_expeyes_end"
= >8 =
(Repeat the middle line if you have multiple IDs)
Needs to be tested by someone having an expeyes board ;-)
As modemmanager already has several blacklists:
/lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules
/lib/udev/rules.d/77-mm-qdl-device-blacklist.rules
/lib/udev/rules.d/77-mm-usb-device-blacklist.rules
perhaps your device should rather be added there?
Some blacklists also set the ID_MM_TTY_BLACKLIST variable instead
of ID_MM_DEVICE_IGNORE
Andreas
Bug#990495: Stop using deprecated systemd-resolve tool
Package: python3-rally-openstack Version: 2.0.0-2 Severity: normal User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: resolvectl Hi, systemd-resolve has been replaced by the resolvectl tool in systemd v239 (i.e. is available since buster). This is from the systemd release notes: * The systemd-resolve tool has been renamed to resolvectl (it also remains available under the old name, for compatibility), and its interface is now verb-based, similar in style to the other ctl tools, such as systemctl or loginctl. systemd-resolve is nowadays merely a symlink pointing at resolvectl and we'd like to get rid of this compat symlink at some point. Your packages uses the old name like this: $ grep -E "systemd-resolve\b" -R rally_openstack/task/scenarios/vm/vmtasks.py:script = f"cloud-init status -w; systemd-resolve --status; "\ "systemd-resolve --status" can be replaced by "resolvectl status". It is planned, that the systemd-resolve compat symlink will be dropped in in bookworm. Regards, Michael
Bug#990495: Acknowledgement (Stop using deprecated systemd-resolve tool)
Control: tags -1 + patch
Patch should be as simple as this
diff --git a/rally_openstack/task/scenarios/vm/vmtasks.py b/rally_openstack/task/scenarios/vm/vmtasks.py
index dea2d44..139d032 100644
--- a/rally_openstack/task/scenarios/vm/vmtasks.py
+++ b/rally_openstack/task/scenarios/vm/vmtasks.py
@@ -599,7 +599,7 @@ class CheckDesignateDNSResolving(vm_utils.VMScenario):
key_name=self.context["user"]["keypair"]["name"],
**kwargs)
-script = f"cloud-init status -w; systemd-resolve --status; "\
+script = f"cloud-init status -w; resolvectl status; "\
f"dig $(hostname).{zone}"
command = {
OpenPGP_signature
Description: OpenPGP digital signature
Bug#990464: Kdump is unable to use NVME
tag 990464 + moreinfo thanks On Tue, Jun 29, 2021 at 06:25:48PM -0500, Kody Barks wrote: > Package: kdump-tools > Version: 1:1.6.5-1 > > When the kernel panics, it loads the kdump kernel correctly but this kernel > is unable to use NVME, making it unable to mount the root filesystem and > thus making the kdump kernel panic. > I am unable to generate a proper log of this error. The best I could do is > to take a picture of my screen when this happens. This is the attached > file. > I have tried using the boot parameter: "nvme_core.default_ps_max_latency_us=0" > but this made no changes in behavior. > I am using Debian 10 Buster with Linux 5.10.40 with libc6 2.28-10 > My motherboard is the ASUS PRIME x399-a . > The SSD I'm trying to use as the root filesystem is the Intel Corporation > Optane SSD 900P Series [8086:2700]. > It should be noted that outside of kdump, during normal operation, the > device works flawlessly. Only Kdump's kernel has an issue. hey Kody, It's likely that your crashkernel= parameter just doesn't provide enough memory for the crashkernel to initialize all of your devices. This is set in /etc/default/grub.d/kdump-tools.cfg. Try bumping that up to see if it fixes things. Note that after changing it you'll need to 1) sudo update-grub and 2) reboot before it will take effect for the next crash dump. It's unfortunately not possible to provide a static default crashkernel= that works for everyone, so tuning it is often required. -dann
Bug#990497: grub-efi-amd64: grub-install not run if /boot/efi/EFI/debian doesn't exist
Package: grub-efi-amd64 Version: 2.02+dfsg1-20+deb10u4 Severity: normal Hi, reporting a bug after an IRC debugging session today. On a amd64 EFI platform (Buster) I wanted to put the ESP partition on a RAID1 volume, so I recreated the whole thing (RAID1 creation and mkfs.vfat on the /dev/md1 device), ending with an empty vfat partition. I then proceeded to dpkg-reconfigure grub-efi-amd64 and chose to force installation to the removable path (EFI/boot/bootx64.efi) and not to update NVRAM variables. After that, grub-install was *not* ran and thus nothing appeared in /boot/efi/. Looking at the postinst script, I noticed: 693 grub-efi-ia32|grub-efi-amd64|grub-efi-ia64|grub-efi-arm|grub-efi-arm64) 694 bootloader_id="$(config_item GRUB_DISTRIBUTOR | tr A-Z a-z | \ 695 cut -d' ' -f1)" 696 case $bootloader_id in 697 kubuntu) bootloader_id=ubuntu ;; 698 esac 699 if [ "$bootloader_id" ] && [ -d "/boot/efi/EFI/$bootloader_id" ]; then 700 case grub-efi-amd64 in 701 grub-efi-ia32) target=i386-efi ;; 702 grub-efi-amd64) target=x86_64-efi ;; 703 grub-efi-ia64) target=ia64-efi ;; 704 grub-efi-arm) target=arm-efi ;; 705 grub-efi-arm64) target=arm64-efi ;; 706 esac 707 db_get grub2/force_efi_extra_removable 708 if [ "$RET" = true ]; then 709 FORCE_EXTRA_REMOVABLE="--force-extra-removable" 710 fi 711 NO_NVRAM="$(no_nvram_arg)" 712 run_grub_install --target="$target" "$FORCE_EXTRA_REMOVABLE" "$NO_NVRAM" 713 fi On Debian GRUB_DISTRIBUTOR is set to `debian` so if /boot/efi/EFI/debian doesn't exist, then grub-install won't be run at all. It looks like a bug to me, but maybe I missed something. Regards, -- Yves-Alexis
Bug#990498: CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16)
Source: kodi Version: 2:17.6+dfsg1-4 For some reason I cannot get any plugin to work in kodi today. I even tried the bpo version. My kodi.log is filled with: 2021-06-30 20:16:02.831 T:19196INFO : CPythonInvoker(0, /usr/share/kodi/addons/service.xbmc.versioncheck/resources/lib/runner.py): script successfully run 2021-06-30 20:16:02.841 T:19196INFO : Python interpreter stopped 2021-06-30 20:16:05.744 T:19163 ERROR : CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16) 2021-06-30 20:16:05.744 T:19163 ERROR : CCurlFile::Open failed with code 0 for https://mirrors.kodi.tv/addons/matrix/metadata.common.imdb.com/metadata.common.imdb.com-3.2.3.zip: 2021-06-30 20:16:05.744 T:19163 ERROR : Could not fetch addon location and hash from https://mirrors.kodi.tv/addons/matrix/metadata.common.imdb.com/metadata.common.imdb.com-3.2.3.zip 2021-06-30 20:16:05.744 T:19163 ERROR : CAddonInstallJob[metadata.common.imdb.com]: failed to resolve addon install source path 2021-06-30 20:16:06.143 T:19163 ERROR : CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16) 2021-06-30 20:16:06.143 T:19163 ERROR : CCurlFile::Open failed with code 0 for https://mirrors.kodi.tv/addons/matrix/metadata.common.themoviedb.org/metadata.common.themoviedb.org-3.2.14.zip: 2021-06-30 20:16:06.143 T:19163 ERROR : Could not fetch addon location and hash from https://mirrors.kodi.tv/addons/matrix/metadata.common.themoviedb.org/metadata.common.themoviedb.org-3.2.14.zip 2021-06-30 20:16:06.143 T:19163 ERROR : CAddonInstallJob[metadata.common.themoviedb.org]: failed to resolve addon install source path 2021-06-30 20:16:06.539 T:19163 ERROR : CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16) Looking upstream, all I can find are: https://github.com/xbmc/xbmc/issues/16616 which is not really helpful.
Bug#989236: crossgrader: crashes with "Could not mark python3-apt:amd64 for install, fixing manually."
Control: severity -1 serious On Mon, May 31, 2021 at 05:01:35PM +0200, Adam Borowski wrote: > On Mon, May 31, 2021 at 07:08:22AM -0700, Kevin Wu wrote: > > On Mon, May 31, 2021 at 4:26 AM Adam Borowski wrote: > > > But, is there _any_ case when crossgrader might possibly work? As it > > > needs > > > python-apt-common, it will always fail. That makes the package useless. > > > Should we bump #968458 to a RC severity? > > > > crossgrader won't be able to work if python3-apt cannot be > > crossgraded, so there's no case where it would work. Would #968458 > > merit critical for breaking unrelated software? As the other bug hasn't been fixed, crossgrader as it stands in Bullseye is useless. So either we convince David to reconsider or a workaround has to be found. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables ⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice. ⠈⠳⣄
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Control: retitle -1 python3-expeyes: superfluous Conflicts: modemmanager causes problems on buster->bullseye upgrades On 30/06/2021 18.55, Georges Khaznadar wrote: I attach the file eyes_udev.sh, which is called upon eyes17's post-installation, as "eyes_udev.sh enable", thus creating or keeping the file /lib/udev/rules.d/99-phoenix.rules, with this content: Great, the fix seems to be already included in the package. So maybe it's sufficient to just drop all the Conflicts on modemmanager to fix this bug ;-) In all the maintainer scripts, please use invoke-rc.d udev instead of service udev s.t. this gets properly filtered via policy-rc.d (an RC bug on its own, not filing it separately because we already have this one) Lintian says this: E: maintainer-script-calls-service N: N: The maintainer script apparently runs the service command. This N: command is reserved for local administrators and must never be used by N: a Debian package. N: N: Please replace with calls to update-rc.d(8) and invoke-rc.d(8). If N: your package installs this service, this can be automated using N: dh_installinit(1) or dh_installsystemd(1). N: N: Refer to Debian Policy Manual section 9.3.3 (Interfacing with init N: systems) for details. Andreas
Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1
reassign 990411 linux-image-5.10.0-7-amd64 - Thanks Michael, reassigning as proposed. Though I'm wondering (and not finding) whether there would be a more general package to assign this ticket to (such as linux-image-5.x or something). Any thoughts on this problem in the security or the kernel team? Thanks and greets to all of you! *t On Mon, 28 Jun 2021, Michael Biebl wrote: Am 28.06.21 um 14:52 schrieb Tomas Pospisek: Package: systemd Version: 247.3-5 Severity: wishlist Tags: security X-Debbugs-Cc: Debian Security Team Hi, TLDR: $ sudo sysctl kernel.unprivileged_bpf_disabled kernel.unprivileged_bpf_disabled = 0 please disable unprivileged BPF by default, it seems that it is not safe to be allowed by default in the general case. I'm not sure if systemd is the right place to report this security/wishlist ticket against. I've chosen systemd because it ships `/etc/sysctl.d/99-sysctl.conf` which seems to me to be the nearest fit to where `kernel.unprivileged_bpf_disabled` should be set. Please reassign if there's a better package to stick this report to. /etc/sysctl.d/99-sysctl.conf is just a symlink pointing at 99-sysctl.conf -> ../sysctl.conf $ dpkg -S /etc/sysctl.conf procps: /etc/sysctl.conf tbh, I'd prefer the security oder kernel team to make that judgement call.
Bug#990498: CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16)
Hi Matthieu! This might be relevant: https://github.com/xbmc/xbmc/pull/18582 And this definitely is: https://github.com/xbmc/xbmc/issues/19738 > I even tried the bpo version Were you able to reproduce an issue with 2:19.1+dfsg2-1~bpo10+1 ? Which version of curl do you have? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 30 червня 2021 р. 18:22:19 UTC, Mathieu Malaterre написав(-ла): >Source: kodi >Version: 2:17.6+dfsg1-4 > >For some reason I cannot get any plugin to work in kodi today. I even >tried the bpo version. > >My kodi.log is filled with: > >2021-06-30 20:16:02.831 T:19196INFO : CPythonInvoker(0, >/usr/share/kodi/addons/service.xbmc.versioncheck/resources/lib/runner.py): >script successfully run >2021-06-30 20:16:02.841 T:19196INFO : Python interpreter stopped >2021-06-30 20:16:05.744 T:19163 ERROR : >CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16) >2021-06-30 20:16:05.744 T:19163 ERROR : CCurlFile::Open >failed with code 0 for >https://mirrors.kodi.tv/addons/matrix/metadata.common.imdb.com/metadata.common.imdb.com-3.2.3.zip: > >2021-06-30 20:16:05.744 T:19163 ERROR : Could not fetch >addon location and hash from >https://mirrors.kodi.tv/addons/matrix/metadata.common.imdb.com/metadata.common.imdb.com-3.2.3.zip >2021-06-30 20:16:05.744 T:19163 ERROR : >CAddonInstallJob[metadata.common.imdb.com]: failed to resolve addon >install source path >2021-06-30 20:16:06.143 T:19163 ERROR : >CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16) >2021-06-30 20:16:06.143 T:19163 ERROR : CCurlFile::Open >failed with code 0 for >https://mirrors.kodi.tv/addons/matrix/metadata.common.themoviedb.org/metadata.common.themoviedb.org-3.2.14.zip: > >2021-06-30 20:16:06.143 T:19163 ERROR : Could not fetch >addon location and hash from >https://mirrors.kodi.tv/addons/matrix/metadata.common.themoviedb.org/metadata.common.themoviedb.org-3.2.14.zip >2021-06-30 20:16:06.143 T:19163 ERROR : >CAddonInstallJob[metadata.common.themoviedb.org]: failed to resolve >addon install source path >2021-06-30 20:16:06.539 T:19163 ERROR : >CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16) > >Looking upstream, all I can find are: > >https://github.com/xbmc/xbmc/issues/16616 > >which is not really helpful. >
Bug#990496: gcc-mingw-w64-x86-64-win32-runtime: libgcc_s_seh-1.dll built without NX and without ASLR
Hi Tim, On Wed, 30 Jun 2021 19:37:18 +0200, Tim Kosse wrote: > I have noticed that libgcc_s_seh-1.dll as distributed by this package > has not been built with support for the NX and ASLR security features > enabled, as can be see with objdump: > > ~$ x86_64-w64-mingw32-objdump -p > /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libgcc_s_seh-1.dll | grep > DllCharacteristics > DllCharacteristics > > It looks like the other .dlls in this package are also missing these > important flags. I have not checked whether this affects the > corresponding package with the 32bit DLLs. > > This is a regression from buster, where this file is built with support > for both features: > > ~$ x86_64-w64-mingw32-objdump -p > /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libgcc_s_seh-1.dll | grep > DllCharacteristics > DllCharacteristics 0160 Not quite: the DLLs were built with those flags set, but they weren’t built with support for the features — as a result, in many cases the protection features were unusable and even misleading. See https://www.kb.cert.org/vuls/id/307144/ and the links therein for details. > According to > https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32, > > 0160 decomposes into > IMAGE_DLLCHARACTERISTICS_NX_COMPAT, > IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE and > IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA > > These libraries should be built with both mitigations enabled. I agree, at least those options which make sense for DLLs, but it’s still not straightforward. Ideally, support for this should come from upstream (GCC and MinGW-w64), not just the Debian packages. Regards, Stephen pgpLgp09v8JH3.pgp Description: OpenPGP digital signature
Bug#990499: apparmor: Include local profile for sanitized_helper
Package: apparmor Version: 2.13.2-10 Severity: wishlist Dear Maintainer, The current setup for the profile sanitized_helper does not include a local profile for adjustments. I would like to propose #include in /etc/apparmor.d/abstraction/ubuntu-helpers Best wishes, Frank -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apparmor depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii lsb-base 10.2019051400 ii python33.7.3-1 apparmor recommends no packages. Versions of packages apparmor suggests: pn apparmor-profiles-extra pn apparmor-utils -- debconf information excluded
Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1
Control: reassign -1 src:linux Am 30.06.21 um 20:33 schrieb Tomas Pospisek: reassign 990411 linux-image-5.10.0-7-amd64 - Thanks Michael, reassigning as proposed. Though I'm wondering (and not finding) whether there would be a more general package to assign this ticket to (such as linux-image-5.x or something). The kernel team afair prefers this to be assigned to src:linux. OpenPGP_signature Description: OpenPGP digital signature
Bug#988963: libgc1c2: please drop obsolete Conflicts/Replaces on libgc1 in buster, it interferes with upgrades to bullseye
Hi libgc maintainers, On Thu, 27 May 2021 21:01:18 +0200 Paul Gevers wrote: > I'd expect our Stable Release Managers to be fine with an update like > this. I can even do it via an NMU if that's preferred. Please reassign > to the release-notes pseudo package if fixing this is unacceptable to > you, but please elaborate why in that case. Can you please comment? We missed the 10.10 point release already and 10.11 may happen after we release bullseye, but at least we could improve the upgrade for people upgrading after 10.11. Do you agree with me doing an NMU to fix this issue? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye
Hi Andreas, On Tue, 15 Jun 2021 14:50:39 +0200 Andreas Beckmann wrote: > This has not been discussed with the libgc maintainers (nor does there > exist a bug, yet). There is: https://bugs.debian.org/988963 with a solution (in buster). > I still think reusing 'libgc1' was a very bad decision (maybe the soname > should have been bumped if there were symbols gone?), and it has > uncovered a problem in apt handling swapping real/virtual > Package/Conflicts on the same name pair. I prefer to update libgc in buster and document this behavior in the release notes. As far as I'm aware, this is a "cosmetic" issue in that after the upgrade where packages are hold back, a second upgrade fixes the issue. If that view of the situation is incomplete, please enlighten us. If that view is correct, lets fix bug 988963. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990417: openjdk-11-jre-headless: running java in qemu s390 gives a SIGILL at C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8
I installed on an debian stable/unstable x86_64 the vm with: sudo virt-install --name debian-s390x --disk size=20 --memory=2000 -- arch=s390x --location http://ftp.debian.org/debian/dists/stretch/main/installer-s390x/ then I upgraded to stable (using stable for installation causes the new vm to freeze during install - another bug?) and installed the openjdk- 11-jre-headless. just execution the command /usr/lib/jvm/java-11-openjdk-s390x/bin/java crashes. This is how to reproduce the bug. This happens with debian stable/unstable on x86_64 as host and/or debian stable/unstable and ubuntu bionic/groovy as guest. Am Dienstag, dem 29.06.2021 um 10:01 +0200 schrieb Matthias Klose: > Control: reassign -1 src:qemu > > works for me on a native machine. You should also provide a test > case. > > > On 6/28/21 7:28 PM, Arne Plöse wrote: > > Package: openjdk-11-jre-headless > > Version: 11.0.11+9-1~deb10u1 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > > > I tried tu run java in an qemu emulated s390 debian VM. > > The bug accects also unstabel and te openjdk versions 15, 16 and > > 17, but not version 1.8 > > > > The outcome is a hs_err_pid632.log. > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGILL (0x4) at pc=0x03ff88c7e6f4, pid=587, tid=588 > > # > > # JRE version: (11.0.11+9) (build ) > > # Java VM: OpenJDK 64-Bit Server VM (11.0.11+9-post-Debian- > > 1deb10u1, mixed mode, sharing, tiered, compressed oops, g1 gc, > > linux-s390x) > > # Problematic frame: > > # C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 > > # > > # No core dump will be written. Core dumps have been disabled. To > > enable core dumping, try "ulimit -c unlimited" before starting Java > > again > > # > > # > > > > --- S U M M A R Y > > > > Command Line: > > > > Host: 2964, 2 cores, 1G, Debian GNU/Linux 10 (buster) > > Time: Mon Jun 28 19:13:29 2021 CEST elapsed time: 0.099756 seconds > > (0d 0h 0m 0s) > > > > --- T H R E A D --- > > > > Current thread is native thread > > > > Stack: [0x03ff8748,0x03ff8758], > > sp=0x03ff8757e940, free space=1018k > > Native frames: (J=compiled Java code, A=aot compiled Java code, > > j=interpreted, Vv=VM code, C=native code) > > C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 > > > > > > siginfo: si_signo: 4 (SIGILL), si_code: 5 (ILL_PRVOPC), si_addr: > > 0x03ff88c7e6f4 > > > > > > > > -- System Information: > > Debian Release: 10.10 > > APT prefers stable-updates > > APT policy: (500, 'stable-updates'), (500, 'stable') > > Architecture: s390x > > > > Kernel: Linux 4.19.0-17-s390x (SMP w/2 CPU cores) > > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C > > (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages openjdk-11-jre-headless depends on: > > ii ca-certificates-java 20190405 > > ii java-common 0.71 > > ii libasound2 1.1.8-1 > > ii libc6 2.28-10 > > ii libcups2 2.2.10-6+deb10u4 > > ii libfontconfig1 2.13.1-2 > > ii libfreetype6 2.9.1-3+deb10u2 > > ii libgcc1 1:8.3.0-6 > > ii libharfbuzz0b 2.3.1-1 > > ii libjpeg62-turbo 1:1.5.2-2+deb10u1 > > ii liblcms2-2 2.9-3 > > ii libnss3 2:3.42.1-1+deb10u3 > > ii libpcsclite1 1.8.24-1 > > ii libstdc++6 8.3.0-6 > > ii util-linux 2.33.1-0.1 > > ii zlib1g 1:1.2.11.dfsg-1 > > > > openjdk-11-jre-headless recommends no packages. > > > > Versions of packages openjdk-11-jre-headless suggests: > > pn fonts-dejavu-extra > > pn fonts-indic > > pn fonts-ipafont-gothic > > pn fonts-ipafont-mincho > > pn fonts-wqy-microhei | fonts-wqy-zenhei > > pn libnss-mdns > > > > -- no debconf information > > >
Bug#990492: libreoffice-draw: When I open LibreOffice Draw, I'm taken to the document recovery window.
Package: libreoffice-draw Version: 1:7.0.4-4 Severity: important Dear Maintainer, When I open LibreOffice Draw, I'm taken to the document recovery window, even though I'm opening the program for the first time. After that, LibreOffice's main window opens, not LibreOffice Draw's window. -- Package-specific info: -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-draw depends on: ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc62.31-12 ii libcdr-0.1-1 0.1.6-2 ii libdbus-1-3 1.12.20-2 ii libfreehand-0.1-10.1.2-3 ii libgcc-s110.2.1-6 ii libglib2.0-0 2.66.8-1 ii libmspub-0.1-1 0.1.4-3+b1 ii libmwaw-0.3-30.3.17-1 ii libodfgen-0.1-1 0.1.8-2 ii libpagemaker-0.0-0 0.0.4-1 ii libqxp-0.0-0 0.0.2-1+b1 ii libreoffice-common 1:7.0.4-4 ii libreoffice-core 1:7.0.4-4 ii librevenge-0.0-0 0.0.4-6+b1 ii libstaroffice-0.0-0 0.0.7-1 ii libstdc++6 10.2.1-6 ii libuno-cppu3 1:7.0.4-4 ii libuno-cppuhelpergcc3-3 1:7.0.4-4 ii libuno-sal3 1:7.0.4-4 ii libuno-salhelpergcc3-3 1:7.0.4-4 ii libvisio-0.1-1 0.1.7-1+b1 ii libwpg-0.3-3 0.3.3-1 ii libxml2 2.9.10+dfsg-6.7 ii libzmf-0.0-0 0.0.2-1+b3 ii ucf 3.0043 ii uno-libs-private 1:7.0.4-4 libreoffice-draw recommends no packages. libreoffice-draw suggests no packages. Versions of packages libreoffice-core depends on: ii fontconfig 2.13.1-4.2 ii fonts-opensymbol2:102.11+LibO7.0.4-4 ii libboost-locale1.74.0 1.74.0-9 ii libc6 2.31-12 ii libcairo2 1.16.0-5 ii libclucene-contribs1v5 2.3.3.4+dfsg-1+b1 ii libclucene-core1v5 2.3.3.4+dfsg-1+b1 ii libcmis-0.5-5v5 0.5.2-3 ii libcups22.3.3op2-3+deb11u1 ii libcurl3-gnutls 7.74.0-1.3 ii libdbus-1-3 1.12.20-2 ii libdconf1 0.38.0-2 ii libeot0 0.01-5+b1 ii libepoxy0 1.5.5-1 ii libexpat1 2.2.10-2 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.8-1 ii libgpgmepp6 1.14.0-1+b2 ii libgraphite2-3 1.3.14-1 ii libgstreamer-plugins-base1.0-0 1.18.4-2 ii libgstreamer1.0-0 1.18.4-2 ii libharfbuzz-icu02.7.4-1 ii libharfbuzz0b 2.7.4-1 ii libhunspell-1.7-0 1.7.0-3 ii libhyphen0 2.8.8-7 ii libice6 2:1.0.10-1 ii libicu6767.1-6 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-2 2.12~rc1-2 ii libldap-2.4-2 2.4.57+dfsg-3 ii libmythes-1.2-0 2:1.2.4-3+b1 ii libneon27-gnutls0.31.2-1 ii libnspr42:4.29-1 ii libnss3 2:3.67-1 ii libnumbertext-1.0-0 1.0.7-1 ii liborcus-0.16-0 0.16.1-3+b2 ii liborcus-parser-0.16-0 0.16.1-3+b2 ii libpng16-16 1.6.37-3 ii libpoppler102 20.09.0-3.1 ii libqrcodegencpp11.6.0-1 ii libraptor2-02.0.14-1.2 ii librdf0 1.0.17-1.1+b1 ii libreoffice-common 1:7.0.4-4 ii librevenge-0.0-00.0.4-6+b1 ii libsm6 2:1.2.3-1 ii libstdc++6 10.2.1-6 ii libuno-cppu31:7.0.4-4 ii libuno-cppuhelpergcc3-3 1:7.0.4-4 ii libuno-sal3 1:7.0.4-4 ii libuno-salhelpergcc3-3 1:7.0.4-4 ii libx11-62:1.7.1-1 ii libx11-xcb1 2:1.7.1-1 ii libxext62:1.3.3-1.1 ii libxinerama12:1.1.4-2 ii libxml2 2.9.10+dfsg-6.7 ii libxmlsec1 1.2.31-1 ii libxmlsec1-nss 1.2.31-1 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.34-4 ii uno-libs-private1:7.0.4-4 ii ure 1:7.0.4-4 ii zlib1g
Bug#990460: apt freezes - cannot be stopped (konsole)
Hi, On Tue, Jun 29, 2021 at 08:51:18PM +0200, Rene Regensbogen wrote: > Sometimes, after I used apt to install packages, I want to install some more > packages. > Every time then, there is simply no output. When I try to cancel it with ^C, > it doesn't > gets cancelled. The only way to quit is to close the subtab in konsole. ^C (interrupt) is not instantaneous like a SIGKILL. An application (like apt) is allowed to reach a safe point to exit, which in case of apt tends to be after the dpkg call currently executed. That might be quite a bit of time still until dpkg (and hence apt) actually finishes, but exiting earlier would mean that the machine might not be in a state which can boot, start the graphical user environment or whatever. In most cases that means that everything apt intended to do is actually done even if you press ^C "in the middle" of its run, but if not a warning message will be printed. Perhaps some day we might be able to add an indicator to the progress bar… Anyway, the short story is: Do not try to interrupt apt. You can btw start another apt call in another tab – apt will realize it is already running and even wait for the other process to be done before proceeding nowadays. You will have to show us the exact output apt produces for me to make better guesses what "hangs" (I am pretty sure apt is not), but some ideas anyhow: * Did you press CTRL+S (perhaps by accident)? Press CTRL+Q in that case; "flow control" is the term to look out for – you might want to disable it, its something which annoyed me way more often than I am willing to admit… (for zsh its "setopt noflowcontrol", no idea about bash. Konsole probably has an (advanced?) setting for it). * debconf: Was some other window opened, perhaps in the background or on another workspace asking questions? debconf usually asks on the console, but it can also ask in a more graphical way… You can also start a process monitor like 'htop' (F5 for tree) and see what is currently being run. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye
On 30/06/2021 21.38, Paul Gevers wrote: I prefer to update libgc in buster and document this behavior in the release notes. As far as I'm aware, this is a "cosmetic" issue in that after the upgrade where packages are hold back, a second upgrade fixes the issue. If that view of the situation is incomplete, please enlighten us. If that view is correct, lets fix bug 988963. I hadn't considered fixing this in buster where it is not broken. ;-) Will run some tests. This will probably fix this issue. I would probably not remove the Conflicts, but downgrade it to a Breaks: libgc1 (<< 1:8) In case there is no further buster point release before bullseye, the fix could be pushed to buster-updates s.t. it is available for the oldstable-upgrade before the dist-upgrade, at least on sane systems. Should be docuented in the release notes. Andreas
Bug#990462: Bug#990319: unblock: intel-microcode/3.20210608.2
Control: tags -1 moreinfo Hi Sebastian On 29-06-2021 22:41, Sebastian Ramacher wrote: >> Please note that the current plans are that a Debian 10 (buster) >> security update, intel-microcode/3.20210608.2~deb10u1, will be delivered >> to Debian stable in the next couple days through debian-security, in >> which case the version currently in Debian 11 "bullseye" would be >> *OLDER* than what would be available in buster-security and unstable. >> >> Also, please be warned that this update has the potential to cause >> regressions when compared to the previous version of the intel-microcode >> package. But do read the text below for the full rationale. > > The regression potential seems worth adding to the release notes. > Cloning and reassigning accordingly. I may be missing something, or your intentions, but if I understand correctly, users that upgrade to bullseye will already have had the regression and as such the release notes will not help them to prepare for the upgrade. Hence, if this needs further documenting, I think we should look for better places. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye
Hi, On 30-06-2021 21:53, Andreas Beckmann wrote: > On 30/06/2021 21.38, Paul Gevers wrote: > In case there is no further buster point release before bullseye, the > fix could be pushed to buster-updates s.t. it is available for the > oldstable-upgrade before the dist-upgrade, at least on sane systems. We'll have to discuss this with the SRM, hence I also wanted to know from you if you experienced worse cases than "just" needing two upgrades instead of one. I'm missing the point about oldstable though. > Should be docuented in the release notes. It's on the release notes radar for a while already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;exclude=tags%3Abuster;package=release-notes Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#987068: assert "preliminary cgroupv2 support" or fix outstanding bugs (eg: debootstrap+Docker)
Hi Nicholas, On 27-05-2021 09:33, Paul Gevers wrote: > Sorry for being silent on this issue for two weeks, but I lack the > background (and the time to investigate) to turn your messages into > release-notes text so I struggled how to reply. Can you maybe come up > with a proposal (bare text is fine, with markup even nicer)? We already > have two sections which mention cgroups v2: > > https://salsa.debian.org/ddp-team/release-notes/-/blob/96e1966eec0c3b163b8605a72e4f63379927d0ca/en/whats-new.dbk#L428 > > https://salsa.debian.org/ddp-team/release-notes/-/blob/96e1966eec0c3b163b8605a72e4f63379927d0ca/en/issues.dbk#L191 > > Please note that we try to not be very verbose, instead we prefer to > link to external sources as the release notes are meant for all bullseye > users, not only the ones that (need to) dive into cgroups. Any suggestion how to go from here? Do you have a (draft) proposal for some text? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990421: Bug#990379: unblock: rdiff-backup/2.0.5-2
Hi all,
On 28-06-2021 21:10, Paul Gevers wrote:
>> rdiff-backup is a sort of rsync-like backup tool. It happens that the
>> version that will be shipped in Bullseye (2.0.5) has a network protocol
>> that is incompatible with that of the version that was shipped in Buster
>> (1.2.8). The details are in https://bugs.debian.org/975270
>
> This sounds worth mentioning in the release notes. Cloned accordingly.
Samuels text was already pretty good. Attached a diff, ready to push.
Paul
From d59263cc5ca62988be7177f6bedd685eca8d42b6 Mon Sep 17 00:00:00 2001
From: Samuel Thibault
Date: Wed, 30 Jun 2021 22:17:20 +0200
Subject: [PATCH] issues.dbk: rdiff-backup in bullseye can't talk to
rdiff-backup in buster
---
en/issues.dbk | 24
1 file changed, 24 insertions(+)
diff --git a/en/issues.dbk b/en/issues.dbk
index e706ab69..7a2d3a91 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -422,6 +422,30 @@ data = ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
+
+rdiff-backup require lockstep upgrade of server and client
+
+ The network protocol of versions 1 and 2 of rdiff-backup are incompatible. This
+ means that you must be running the same version (either 1 or 2)
+ of rdiff-backup locally
+ and remotely. Since buster ships version 1.2.8 and bullseye
+ ships version 2.0.5, upgrading only the local system or only the
+ remote system from buster to bullseye will break rdiff-backup runs between the two.
+
+
+ For conveniency, version 2.0.5 of rdiff-backup is available in the
+ buster-backports distribution, see https://backports.debian.org/";>backports. This
+ enables users to first upgrade only the rdiff-backup package on their buster
+ systems, and then independently upgrade systems to bullseye at
+ their convenience.
+
+
+
Things to do post upgrade before rebooting
--
2.30.2
OpenPGP_signature
Description: OpenPGP digital signature
Bug#990498: CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16)
Package: kodi
Followup-For: Bug #990498
X-Debbugs-Cc: gh...@debian.org, elb...@debian.org
Hi Mathieu!
Can you please check if the following patch for curl 7.64.0-4+deb10u2 resolves
your issue?
It is a backport of two patches merged in 7.65.0 and 7.67.0, respectively (see
the commit msg
for details).
If that helps, I will reattach the bug to curl package since the patch is
long-time merged
upstream.
Vasyl
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-7-amd64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages kodi depends on:
pn kodi-bin
pn kodi-data
Versions of packages kodi recommends:
pn kodi-repository-kodi | kodi-repository
pn kodi-visualization-spectrum
kodi suggests no packages.
diff --git a/debian/patches/28-Fix-HTTP2-framing-layer-#990498.patch
b/debian/patches/28-Fix-HTTP2-framing-layer-#990498.patch
new file mode 100644
index 000..b6a917e
--- /dev/null
+++ b/debian/patches/28-Fix-HTTP2-framing-layer-#990498.patch
@@ -0,0 +1,34 @@
+Subject: Fix HTTP2 framing layer error (Closes: #990498)
+Author: Vasyl Gello
+Forwarded: not-needed
+
+This is squashed no-change backport of two commits:
+
+https://github.com/curl/curl/commit/3f5da4e59a556fc68272a9857a38dd75234d0c04
+openssl: mark connection for close on TLS close_notify
+
+https://github.com/curl/curl/commit/a56a47ac33a8344c0a3f3f74bd4a6b07576f7e0a
+openssl: close_notify on the FTP data connection doesn't mean closure
+
+mentioned in upstream issue:
+
+https://github.com/curl/curl/issues/3750
+
+---
+
+--- a/lib/vtls/openssl.c
b/lib/vtls/openssl.c
+@@ -3792,7 +3792,13 @@
+
+ switch(err) {
+ case SSL_ERROR_NONE: /* this is not an error */
++ break;
+ case SSL_ERROR_ZERO_RETURN: /* no more data */
++ /* close_notify alert */
++ if(num == FIRSTSOCKET)
++/* mark the connection for close if it is indeed the control
++ connection */
++connclose(conn, "TLS close_notify");
+ break;
+ case SSL_ERROR_WANT_READ:
+ case SSL_ERROR_WANT_WRITE:
diff --git a/debian/patches/series b/debian/patches/series
index 6330cd9..d0d1790 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -19,6 +19,7 @@
25_CVE-2020-8286.patch
26_CVE-2021-22876.patch
27_CVE-2021-22890.patch
+28-Fix-HTTP2-framing-layer-#990498.patch
# do not add patches below
90_gnutls.patch
Bug#989002: freshclam: apparmor denial: operation="capable" capability=2 capname="dac_read_search"
On 2021-05-23 08:32:23 [+0800], Paul Wise wrote: > Whenever freshclam gets restarted, either manually or automatically > during package upgrades, I get an apparmor denial in the logs. I > haven't seen any adverse effects from this denial. Reading the > capabilities(7) manual page where CAP_DAC_READ_SEARCH is mentioned, > there doesn't seem to be any reason for freshclam to need this > capability so I don't think the freshclam binary should be using this > capability. I note that the clamav codebase doesn't mention this > capability at all. I note that the apparmor profile mentions > dac_override and a comment next to that mentions a Launchpad bug that > explains this is for the AllowSupplementaryGroups option, which is > disabled by default. I wonder if whatever allows that to work has > switched from dac_override to dac_read_search, but I'm still not sure > why freshclam should also be using that capability. You still see it I guess? Based on your log you run systemd so that should be same thing I have here for testing. And I don't see it. But you have while freshclam is killed not on start up. There is this in my journal: |Oct 31 23:30:41 debsidamd64 audit[450]: AVC apparmor="DENIED" operation="capable" profile="/usr/bin/freshclam" pid=450 comm="freshclam" capability=1 capname="dac_override" which is from the time before dac_override got added. The Debian bug was #972974. I know that AllowSupplementaryGroups is marked as deprecated but this is the default now. That means initgroups() (the code that was hidden behind AllowSupplementaryGroups) is always executed. Sebastian
Bug#990498: CCurlFile::FillBuffer - Failed: Error in the HTTP2 framing layer(16)
CC'ing just in case reportbug fails to deliver the reply to bug reporter.
Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye
On 30/06/2021 21.58, Paul Gevers wrote: fix could be pushed to buster-updates s.t. it is available for the oldstable-upgrade before the dist-upgrade, at least on sane systems. We'll have to discuss this with the SRM, hence I also wanted to know from you if you experienced worse cases than "just" needing two upgrades instead of one. I'm missing the point about oldstable though. if stable == bullseye, oldstable == buster Andreas
Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1
Hi, Related: #928362. And on non src:linux #919226. It has to be noted that once set kernel.unprivileged_bpf_disabled=1 it cannot be cleared again. Regards, Salvatore
Bug#990500: unblock: lxml/4.6.3+dfsg-0.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package lxml [ Reason ] The source of lxml contained a file that's marked as unacceptable by ftp-master and as such a future upload of lxml would hit the auto-reject list. To avoid problems with security uploads, I prefer to fix the issue now. The file was a image shipped with the documentation, which wasn't even used. In the process of fixing this issue, I discovered that the documentation package was nearly empty and didn't contain any documentation. This is fixed by enabling the build of the documentation. [ Impact ] If not unblocked, security or plain pu uploads will have to take remove the file at that time. [ Tests ] The removed file is just an unlinked image. I have checked that the package now contains the documentation files. [ Risks ] Close to 0 risk as it's just removing an image and building documentation files. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock lxml/4.6.3+dfsg-0.1 diff -Nru lxml-4.6.3/debian/changelog lxml-4.6.3+dfsg/debian/changelog --- lxml-4.6.3/debian/changelog 2021-03-22 14:31:55.0 +0100 +++ lxml-4.6.3+dfsg/debian/changelog2021-06-26 19:40:37.0 +0200 @@ -1,3 +1,11 @@ +lxml (4.6.3+dfsg-0.1) unstable; urgency=medium + + * Non-maintainer upload + * Repack upstream to drop non-free and unused file (Closes: #988717) + * Build and ship documentation (Closes: #799334) + + -- Paul Gevers Sat, 26 Jun 2021 19:40:37 +0200 + lxml (4.6.3-1) unstable; urgency=high * New upstream version. diff -Nru lxml-4.6.3/debian/control lxml-4.6.3+dfsg/debian/control --- lxml-4.6.3/debian/control 2020-12-07 14:42:24.0 +0100 +++ lxml-4.6.3+dfsg/debian/control 2021-06-26 19:40:37.0 +0200 @@ -9,6 +9,7 @@ python3-setuptools (>= 0.6.29), python3-bs4, python3-html5lib, + python3-lxml , cython3, cython3-dbg, python3-sphinx-autoapi, X-Python-Version: all diff -Nru lxml-4.6.3/debian/rules lxml-4.6.3+dfsg/debian/rules --- lxml-4.6.3/debian/rules 2020-07-17 11:16:59.0 +0200 +++ lxml-4.6.3+dfsg/debian/rules2021-06-26 19:40:37.0 +0200 @@ -24,6 +24,9 @@ touch $@ build3-python%: prebuild python$* setup.py build +ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS))) + python$* doc/mkhtml.py doc/html . $(UPSTREAMVER) +endif touch $@ dbg-build3-python%: prebuild python$*-dbg setup.py build Binary files /tmp/nGluINxi3b/lxml-4.6.3/doc/html/flattr-badge-large.png and /tmp/DP0ayk9l1g/lxml-4.6.3+dfsg/doc/html/flattr-badge-large.png differ OpenPGP_signature Description: OpenPGP digital signature
Bug#990501: connman: Connman disrupted network during upgrade on system where it does not manage network
Package: connman Version: 1.36-2.2 Severity: normal X-Debbugs-Cc: je...@sney.ca Dear Maintainer, This system has two desktop environments installed: KDE Plasma, which is used primarily; and LXQT, for backup. Network connections are managed by NetworkManager whenever I am using Plasma, which I was when I discovered this bug. On upgrade to 1.36-2.2, connman triggered something to restart the network, the wifi connection dropped, and apt appeared to hang at: > Setting up connman (1.36-2.2) ... I noticed after a few minutes, used my acpi hotkey to re-enable wifi, and the upgrade proceeded, with: > Job for connman-wait-online.service failed because the control process exited > with error code. > See "systemctl status connman-wait-online.service" and "journalctl -xe" for > details. The associated systemctl status output was: > Jun 30 14:34:25 debaser systemd[1]: Starting Wait for network to be > configured by ConnMan... > Jun 30 14:36:26 debaser systemd[1]: connman-wait-online.service: Main process > exited, code=exited, status=110/n/a > Jun 30 14:36:26 debaser systemd[1]: connman-wait-online.service: Failed with > result 'exit-code'. > Jun 30 14:36:26 debaser systemd[1]: Failed to start Wait for network to be > configured by ConnMan. It appears that connman was waiting for some kind of network-up condition, which would never arrive because connman was not managing the network. It should be able to detect a system where something else (n-m, ifupdown, etc) is being used, and proceed with the upgrade without trying to mess with it. Please let me know if you need any more information. Jesse (sney) -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages connman depends on: ii dbus 1.12.20-2 ii iptables 1.8.7-1 ii libc6 2.31-12 ii libdbus-1-3 1.12.20-2 ii libglib2.0-0 2.66.8-1 ii libgnutls30 3.7.1-5 ii libreadline8 8.1-1 ii libxtables12 1.8.7-1 ii lsb-base 11.1.0 Versions of packages connman recommends: ii bluez 5.55-3.1 ii ofono 1.31-3 ii wpasupplicant 2:2.9.0-21 Versions of packages connman suggests: pn connman-vpn -- no debconf information
Bug#990447: fwupdmgr: Unable to install new updates
Salvatore Bonaccorso writes: > On Tue, Jun 29, 2021 at 02:04:47PM +0200, Salvatore Bonaccorso wrote: >> Package: fwupd >> Version: 1.5.7-4 [...] > Interesting datapoint: I experimented further, and disabled secure > boot. After that I was able to install those updates. > > Does that possibly ring some bell? I have no idea about fwupd, but if disabling secure boot works: I would check if the fwupd binaries in /boot/efi/EFI/debian are outdated for some reason. fwupd-amd64-signed switched to a new signing key with 1.5.7+3 and the old key should be revoked. Ansgar
Bug#990502: RFS: toxic/0.11.1-1 -- curses Tox based instant messenging client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "toxic": * Package name: toxic Version : 0.11.1-1 Upstream Author : JFreegman * URL : https://github.com/JFreegman/toxic * License : CC-BY-3.0, GPL-3+ * Vcs : [fill in URL of packaging vcs] Section : net It builds those binary packages: toxic - curses Tox based instant messenging client To access further information about this package, please visit the following URL: https://mentors.debian.net/package/toxic/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/toxic/toxic_0.11.1-1.dsc Changes since the last upload: toxic (0.11.1-1) experimental; urgency=medium . * New upstream version. Regards, -- Gürkan Myczko
Bug#990503: php-nrk-predis: Wrong install location
Package: php-nrk-predis Version: 1.0.0-1+b1 Followup-For: Bug #779418 X-Debbugs-Cc: gera...@malazdrewicz.com.ar Dear Maintainer, I had success with the attached patch to debian/rules, to get the desired outcome (files installed in /usr/share/php/Predis). -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/20 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#990504: fuse3: /etc/fuse.conf outdated permissions/owners
Package: fuse3 Version: 3.10.3-2 Severity: normal Hi. Apparently there used to be a fuse group in earlier versions of the package, and e.g. /etc/fuse.conf had: -rw-r- 1 root fuse 694 Apr 21 14:34 /etc/fuse.conf Now this group seems to have been dropped (and is btw: not cleaned up, which I think it should if it's not used anymore), but even after upgrade, /etc/fuse.conf remains :fuse owned. Also on fresh installations, the file has permissions: -rw-r--r-- Could you perhaps update owner/permissions in a future upgrade (of course only when there is no dpkg-statoverride set). Thanks, Chris.
Bug#990505: RFS: gifsicle/1.93-1 -- Tool for manipulating GIF images
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "gifsicle": * Package name: gifsicle Version : 1.93-1 Upstream Author : Eddie Kohler * URL : http://www.lcdf.org/gifsicle/ * License : GPL-2 or CLICK or special, GPL-2 or special * Vcs : https://salsa.debian.org/debian/gifsicle Section : graphics It builds those binary packages: gifsicle - Tool for manipulating GIF images To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gifsicle/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gifsicle/gifsicle_1.93-1.dsc Changes since the last upload: gifsicle (1.93-1) experimental; urgency=medium . * New upstream version. Regards, -- Gürkan Myczko
Bug#990506: RFS: labelme/4.5.9-1 -- Image Polygonal Annotation with Python
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "labelme": * Package name: labelme Version : 4.5.9-1 Upstream Author : Kentaro Wada * URL : https://github.com/wkentaro/labelme * License : GPL-3+ * Vcs : https://salsa.debian.org/myczko-guest/labelme Section : graphics It builds those binary packages: labelme-examples - Image Polygonal Annotation with Python, examples labelme - Image Polygonal Annotation with Python To access further information about this package, please visit the following URL: https://mentors.debian.net/package/labelme/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/labelme/labelme_4.5.9-1.dsc Changes since the last upload: labelme (4.5.9-1) experimental; urgency=medium . * New upstream version. Regards, -- Gürkan Myczko
Bug#990496: gcc-mingw-w64-x86-64-win32-runtime: libgcc_s_seh-1.dll built without NX and without ASLR
Package: gcc-mingw-w64-x86-64-win32-runtime Version: 10.2.1-6+24.2 Severity: important X-Debbugs-Cc: tim.ko...@filezilla-project.org Dear Maintainer, I have noticed that libgcc_s_seh-1.dll as distributed by this package has not been built with support for the NX and ASLR security features enabled, as can be see with objdump: ~$ x86_64-w64-mingw32-objdump -p /usr/lib/gcc/x86_64-w64-mingw32/10-win32/libgcc_s_seh-1.dll | grep DllCharacteristics DllCharacteristics It looks like the other .dlls in this package are also missing these important flags. I have not checked whether this affects the corresponding package with the 32bit DLLs. This is a regression from buster, where this file is built with support for both features: ~$ x86_64-w64-mingw32-objdump -p /usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libgcc_s_seh-1.dll | grep DllCharacteristics DllCharacteristics 0160 According to https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32, 0160 decomposes into IMAGE_DLLCHARACTERISTICS_NX_COMPAT, IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE and IMAGE_DLL_CHARACTERISTICS_HIGH_ENTROPY_VA These libraries should be built with both mitigations enabled. Regards, Tim Kosse -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/32 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages gcc-mingw-w64-x86-64-win32-runtime depends on: ii gcc-mingw-w64-base 10.2.1-6+24.2 gcc-mingw-w64-x86-64-win32-runtime recommends no packages. gcc-mingw-w64-x86-64-win32-runtime suggests no packages. -- no debconf information
Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Show new changelog entries from Debian package archives
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a package I made a fix for, "apt-listchanges": * Package name: apt-listchanges Version : 3.24.1 Upstream Author : Brian Thompson * URL : https://salsa.debian.org/briant/apt-listchanges * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/apt-listchanges Section : utils It builds those binary packages: apt-listchanges - package change history notification tool To access further information about this package, please visit the following URL: https://mentors.debian.net/package/apt-listchanges/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/apt-listchanges/apt-listchanges_3.24.1.dsc Changes since the last upload: * Fix error message being thrown when choosing not to proceed on confirmation (closes: #989496). * Update maintainer to myself (closes: #981890). Best regards, -- Brian Thompson
Bug#990421: Bug#990379: unblock: rdiff-backup/2.0.5-2
On Mi, 30 iun 21, 22:22:12, Paul Gevers wrote: > > Samuels text was already pretty good. Attached a diff, ready to push. > > Paul > > + > +rdiff-backup require lockstep upgrade of server and client > + > + The network protocol of versions 1 and 2 of + role="package">rdiff-backup are incompatible. This > + means that you must be running the same version (either 1 or 2) > + of rdiff-backup locally > + and remotely. Since buster ships version 1.2.8 and bullseye > + ships version 2.0.5, upgrading only the local system or only the > + remote system from buster to bullseye will break + role="package">rdiff-backup runs between the two. > + > + > + For conveniency, version 2.0.5 of + role="package">rdiff-backup is available in the > + buster-backports distribution, see + url="https://backports.debian.org/";>backports. This > + enables users to first upgrade only the + role="package">rdiff-backup package on their buster > + systems, and then independently upgrade systems to bullseye at > + their convenience. > + > + As far as I know typically we refer to backports as an 'archive', especially since it is an add-on for stable, so s/distribution/archive/, otherwise it looks good to me, for what it's worth. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#990421: Bug#990379: unblock: rdiff-backup/2.0.5-2
On Wed, Jun 30, 2021 at 10:22:12PM +0200, Paul Gevers wrote:
>Hi all,
>
>On 28-06-2021 21:10, Paul Gevers wrote:
>>> rdiff-backup is a sort of rsync-like backup tool. It happens that the
>>> version that will be shipped in Bullseye (2.0.5) has a network protocol
>>> that is incompatible with that of the version that was shipped in Buster
>>> (1.2.8). The details are in https://bugs.debian.org/975270
>>
>> This sounds worth mentioning in the release notes. Cloned accordingly.
>
>Samuels text was already pretty good. Attached a diff, ready to push.
May I suggest a small tweak - 'conveniency' isn't an English word
as far as I know
Instead of
+
+ For conveniency, version 2.0.5 of
+ Conveniently, version 2.0.5 of
+ Version 2.0.5 of
>Paul
>From d59263cc5ca62988be7177f6bedd685eca8d42b6 Mon Sep 17 00:00:00 2001
>From: Samuel Thibault
>Date: Wed, 30 Jun 2021 22:17:20 +0200
>Subject: [PATCH] issues.dbk: rdiff-backup in bullseye can't talk to
> rdiff-backup in buster
>
>---
> en/issues.dbk | 24
> 1 file changed, 24 insertions(+)
>
>diff --git a/en/issues.dbk b/en/issues.dbk
>index e706ab69..7a2d3a91 100644
>--- a/en/issues.dbk
>+++ b/en/issues.dbk
>@@ -422,6 +422,30 @@ data =
>${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
>
>
>
>+
>+rdiff-backup require lockstep upgrade of server and client
>+
>+ The network protocol of versions 1 and 2 of + role="package">rdiff-backup are incompatible. This
>+ means that you must be running the same version (either 1 or 2)
>+ of rdiff-backup locally
>+ and remotely. Since buster ships version 1.2.8 and bullseye
>+ ships version 2.0.5, upgrading only the local system or only the
>+ remote system from buster to bullseye will break + role="package">rdiff-backup runs between the two.
>+
>+
>+ For conveniency, version 2.0.5 of + role="package">rdiff-backup is available in the
>+ buster-backports distribution, see + url="https://backports.debian.org/";>backports. This
>+ enables users to first upgrade only the + role="package">rdiff-backup package on their buster
>+ systems, and then independently upgrade systems to bullseye at
>+ their convenience.
>+
>+
>+
>
> Things to do post upgrade before rebooting
>
>--
>2.30.2
>
--
Bug#990509: iperf3: [INTL:pt] Updated Portuguese translation - debconf messages
Package: iperf3 Version: 3.10.1-1 Tags: l10n, patch Severity: wishlist Updated Portuguese translation for iperf3's debconf messages Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro - iperf3_3.10.1-1.pt.po.gz Description: application/gzip
Bug#989002: freshclam: apparmor denial: operation="capable" capability=2 capname="dac_read_search"
On Wed, 2021-06-30 at 21:51 +0200, Sebastian Andrzej Siewior wrote: > You still see it I guess? I just tried it now. The first time I restarted freshclam it happened, but the second time and third times it did not happen but then the fourth time it did happen. Then I did a shell loop restarting 4 times with 0.5s sleep in between and it happened 3 out of 4 times. Then I did it 4 times again with 1s sleep in between and it happened 0 times. Then I did it with 4 times again with 0.1s sleep and it happened only once. Repeating the 0.5s restarts a bit later I got it 0 times. So I'm guessing it is caused by some kind of race condition. > Based on your log you run systemd Correct. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#989962: proceeding with bullseye checking using debian-bullseye-DI-rc1-amd64-DVD-1.iso and apt-mark hold shim-signed
To whom it may concern: I decided not to wait for updated version of shim-signed that runs on the very old Dell T1600 I'm proceeding with bullseye checkout using shim-signed package found on debian-bullseye-DI-rc1-amd64-DVD-1.iso This version of shim-signed works with me T1600 and its Xeon E3. Others can take advantage of this too. Procedure: install the abovementioned dvd without any ethernet connection to get working shim-signed apt-mark hold shim-signed (keeps old dvd-1 copy of shim-signed intact) connect the ethernet modify sources.list to refer to the debian online repository apt-get update Now I can check out the packages that really matter to me: gcc, g++, cython3, python3-numpy, libntl-dev, etc.
Bug#990510: nvme: AMD-Vi: Event logged IO_PAGE_FAULT
Package: src:linux Version: 5.10.46-1 Severity: minor X-Debbugs-Cc: ledu...@hotmail.com Hi, I found the following in my dmesg every time I boot, hopefully it's harmless, but I prefer to report it. [2.186470] nvme nvme0: missing or invalid SUBNQN field. [2.187498] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0xc000 flags=0x] [2.187557] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0xc080 flags=0x] thanks. -- Package-specific info: ** Version: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-1 (2021-06-24) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=607e48ef-8b29-4cd1-b798-0b1911f70d1b ro rootflags=discard drm_kms_helper.edid_firmware=HDMI-A-1:edid/edid.bin quiet ** Not tainted ** Kernel log: [4.906576] snd_hda_codec_conexant hdaudioC1D0: Mic=0x19 [4.909594] kvm: Nested Virtualization enabled [4.909637] SVM: kvm: Nested Paging enabled [4.909638] SVM: Virtual VMLOAD VMSAVE supported [4.909639] SVM: Virtual GIF supported [4.913191] MCE: In-kernel MCE decoding enabled. [4.938254] EDAC amd64: F17h_M10h detected (node 0). [4.938320] EDAC amd64: Node 0: DRAM ECC disabled. [4.942266] rtw_8822be :04:00.0: enabling device ( -> 0003) [4.945239] rtw_8822be :04:00.0: firmware: direct-loading firmware rtw88/rtw8822b_fw.bin [4.945251] rtw_8822be :04:00.0: Firmware version 27.2.0, H2C version 13 [4.959980] input: HD-Audio Generic Mic as /devices/pci:00/:00:08.1/:05:00.6/sound/card1/input14 [4.960038] input: HD-Audio Generic Headphone as /devices/pci:00/:00:08.1/:05:00.6/sound/card1/input15 [4.968997] rtw_8822be :04:00.0 wlp4s0: renamed from wlan0 [4.980488] XFS (sda1): Mounting V5 Filesystem [5.008276] EDAC amd64: F17h_M10h detected (node 0). [5.008340] EDAC amd64: Node 0: DRAM ECC disabled. [5.112728] EDAC amd64: F17h_M10h detected (node 0). [5.112783] EDAC amd64: Node 0: DRAM ECC disabled. [5.197084] EDAC amd64: F17h_M10h detected (node 0). [5.197164] EDAC amd64: Node 0: DRAM ECC disabled. [5.248934] EDAC amd64: F17h_M10h detected (node 0). [5.249010] EDAC amd64: Node 0: DRAM ECC disabled. [5.264425] XFS (sda1): Ending clean mount [5.276959] EDAC amd64: F17h_M10h detected (node 0). [5.277034] EDAC amd64: Node 0: DRAM ECC disabled. [5.332778] EDAC amd64: F17h_M10h detected (node 0). [5.332858] EDAC amd64: Node 0: DRAM ECC disabled. [5.417067] EDAC amd64: F17h_M10h detected (node 0). [5.417146] EDAC amd64: Node 0: DRAM ECC disabled. [5.450367] xfs filesystem being mounted at /home supports timestamps until 2038 (0x7fff) [5.484993] audit: type=1400 audit(1625101497.831:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=864 comm="apparmor_parser" [5.485000] audit: type=1400 audit(1625101497.835:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=856 comm="apparmor_parser" [5.485004] audit: type=1400 audit(1625101497.835:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=863 comm="apparmor_parser" [5.485104] audit: type=1400 audit(1625101497.835:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=857 comm="apparmor_parser" [5.485107] audit: type=1400 audit(1625101497.835:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=857 comm="apparmor_parser" [5.485236] audit: type=1400 audit(1625101497.835:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=858 comm="apparmor_parser" [5.485240] audit: type=1400 audit(1625101497.835:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=858 comm="apparmor_parser" [5.485243] audit: type=1400 audit(1625101497.835:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=858 comm="apparmor_parser" [5.485845] audit: type=1400 audit(1625101497.835:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=861 comm="apparmor_parser" [5.485954] audit: type=1400 audit(1625101497.835:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirtd" pid=862 comm="apparmor_parser" [5.663654] zram: Added device: zram0 [5.675628] zram0: detected capacity change from 0 to 8589934592 [5.711813] Adding 8388604k swap on /dev/zram0. Priority:100 extents:1 across:8388604k SSFS [5.866689] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [5.867112] mc: Linux media interface: v0.10 [5.883289] videodev: Linux video capt
Bug#868273: open-vm-tools: clean up legacy conffiles
Hey. Anything new on this? These things should be really cleaned up, as also mandated by the policy: https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3 "Obsolete configuration files without local changes should be removed by the package during upgrade." In the meantime some more non-cleaned-up-but-dropped conffiles have been added to the ones mentioned above: /etc/vmware-tools/vm-support /etc/vmware-tools/guestproxy-ssl.conf Please properly clean them up using dpkg-maintscript-helper(1). (AFAIU, the version that needs to be specified for that is NOT the version where the conffile was dropped, but rather "the latest version of the package whose upgrade should trigger the operation" Quoting the manpage: For example, for a conffile removed in version 2.0-1 of a package, prior-version should be set to 2.0-1~. This will cause the conffile to be removed even if the user rebuilt the previous version 1.0-1 as 1.0-1local1. Or a package switching a path from a symlink (shipped in version 1.0-1) to a directory (shipped in version 2.0-1), but only performing the actual switch in the maintainer scripts in version 3.0-1, should set prior-version to 3.0-1~. Thanks, Chris.
Bug#990511: unblock: kodi/2:19.1+dfsg2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: mat...@debian.org
Please unblock package kodi
[ Reason ]
Targeted bug fix for #989814
[ Impact ]
Turkish users get Kodi unusable without it
[ Tests ]
See related Debian bug and https://github.com/xbmc/xbmc/issues/19883
[ Risks ]
Change is trivial and approved by upstream
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock kodi/2:19.1+dfsg2-2
diff -Nru kodi-19.1+dfsg2/debian/changelog kodi-19.1+dfsg2/debian/changelog
--- kodi-19.1+dfsg2/debian/changelog2021-06-07 14:42:08.0 +
+++ kodi-19.1+dfsg2/debian/changelog2021-06-24 20:44:30.0 +
@@ -1,3 +1,9 @@
+kodi (2:19.1+dfsg2-2) unstable; urgency=medium
+
+ * Add runtime locale test and fallback (Closes: #989814)
+
+ -- Vasyl Gello Thu, 24 Jun 2021 20:44:30 +
+
kodi (2:19.1+dfsg2-1) unstable; urgency=medium
* New upstream version 19.1+dfsg2
diff -Nru kodi-19.1+dfsg2/debian/patches/kodi/0022-Workaround-989814.patch
kodi-19.1+dfsg2/debian/patches/kodi/0022-Workaround-989814.patch
--- kodi-19.1+dfsg2/debian/patches/kodi/0022-Workaround-989814.patch
1970-01-01 00:00:00.0 +
+++ kodi-19.1+dfsg2/debian/patches/kodi/0022-Workaround-989814.patch
2021-06-24 20:44:30.0 +
@@ -0,0 +1,67 @@
+From 8b8e97dbec5c6268d1b81eb7799cfc945ca9520e Mon Sep 17 00:00:00 2001
+From: Vasyl Gello
+Date: Fri, 25 Jun 2021 01:37:02 +
+Subject: [PATCH 1/2] Check if applied locale correctly lowers chars and
+ fallback
+
+.. to default region if it does not.
+
+Fixes #19883.
+
+Signed-off-by: Vasyl Gello
+---
+ xbmc/LangInfo.cpp | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/xbmc/LangInfo.cpp b/xbmc/LangInfo.cpp
+index 24f0419cfe..ace72e1ffe 100644
+--- a/xbmc/LangInfo.cpp
b/xbmc/LangInfo.cpp
+@@ -981,6 +981,16 @@ void CLangInfo::SetCurrentRegion(const std::string&
strName)
+
+ m_currentRegion->SetGlobalLocale();
+
++ // Check if locale is not affected by #19883
++ int test19883 = std::tolower('i') - std::tolower('I');
++ if (test19883 != 0)
++ {
++CLog::Log(LOGWARNING, "region '{}' is affected by #19883 - falling back
to default region '{}'",
++ m_currentRegion->m_strName, m_defaultRegion.m_strName);
++m_currentRegion = &m_defaultRegion;
++m_currentRegion->SetGlobalLocale();
++ }
++
+ const std::shared_ptr settings =
CServiceBroker::GetSettingsComponent()->GetSettings();
+ if (settings->GetString(CSettings::SETTING_LOCALE_SHORTDATEFORMAT) ==
SETTING_REGIONAL_DEFAULT)
+ SetShortDateFormat(m_currentRegion->m_strDateFormatShort);
+--
+2.32.0.rc0
+
+
+From 114ee13138389c96a759d6e5b73717093dd4030d Mon Sep 17 00:00:00 2001
+From: Vasyl Gello
+Date: Sun, 27 Jun 2021 19:31:39 +
+Subject: [PATCH 2/2] kodi.sh.in: Unset LC_{ALL,CTYPE}, LANG
+
+Signed-off-by: Vasyl Gello
+---
+ tools/Linux/kodi.sh.in | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/tools/Linux/kodi.sh.in b/tools/Linux/kodi.sh.in
+index 108c0b007b..29d17d2c0f 100644
+--- a/tools/Linux/kodi.sh.in
b/tools/Linux/kodi.sh.in
+@@ -171,6 +171,9 @@ if command_exists gdb; then
+ fi
+ fi
+
++# Unset CTYPE, LANG and ALL - see issue #19883
++unset LC_CTYPE LC_ALL LANG
++
+ LOOP=1
+ while [ $(( $LOOP )) = "1" ]
+ do
+--
+2.32.0.rc0
+
diff -Nru kodi-19.1+dfsg2/debian/patches/series
kodi-19.1+dfsg2/debian/patches/series
--- kodi-19.1+dfsg2/debian/patches/series 2021-06-07 14:42:08.0
+
+++ kodi-19.1+dfsg2/debian/patches/series 2021-06-24 20:44:30.0
+
@@ -19,6 +19,7 @@
kodi/0019-Disable-GetCPUFrequency-test.patch
kodi/0020-Fix-C++-example-includes.patch
kodi/0021-Detect-and-honor-big-endian-arch.patch
+kodi/0022-Workaround-989814.patch
libdvdnav/0001-xbmc-dvdnav-allow-get-set-vm-state.patch
libdvdnav/0002-xbmc-dvdnav-expose-dvdnav_get_vm-dvdnav_get_button_i.patch
libdvdnav/0003-xbmc-dvdnav-detection-of-dvd-name.patch
Bug#990512: unblock: mirtop/0.4.23-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org
Please unblock package mirtop
our GSoC Student Shruti Sridhar has written an autopkgtest for
this package which uncovers a real bug. This is fixed in the
really late upload.
[ Reason ]
The upload fixes a circular import in the code which was fixed
in a patch. The according autopkgtest is included in the change
as well.
[ Impact ]
The program would not work without the patch.
[ Tests ]
The autopkgtest is part of the changes of this upload.
[ Risks ]
There are no real risks since the package is a leaf package.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock mirtop/0.4.23-2
diff -Nru mirtop-0.4.23/debian/changelog mirtop-0.4.23/debian/changelog
--- mirtop-0.4.23/debian/changelog 2019-12-05 11:43:49.0 +0100
+++ mirtop-0.4.23/debian/changelog 2021-06-30 20:18:19.0 +0200
@@ -1,3 +1,15 @@
+mirtop (0.4.23-2) unstable; urgency=medium
+
+ * Team Upload.
+
+ [ Shruti Sridhar ]
+ * Add autopkgtests
+
+ [ Nilesh Patra ]
+ * d/p/fix-circular-import.patch: Fix circular import
+
+ -- Nilesh Patra Wed, 30 Jun 2021 18:18:19 +
+
mirtop (0.4.23-1) unstable; urgency=medium
* New upstream version
diff -Nru mirtop-0.4.23/debian/patches/fix-circular-import.patch
mirtop-0.4.23/debian/patches/fix-circular-import.patch
--- mirtop-0.4.23/debian/patches/fix-circular-import.patch 1970-01-01
01:00:00.0 +0100
+++ mirtop-0.4.23/debian/patches/fix-circular-import.patch 2021-06-30
20:18:19.0 +0200
@@ -0,0 +1,29 @@
+Description: import module in needed functions to fix circular import
+Author: Nilesh Patra
+Last-Update: 2021-06-30
+--- a/mirtop/bam/bam.py
b/mirtop/bam/bam.py
+@@ -15,7 +15,6 @@
+ from mirtop.mirna.realign import isomir, hits, reverse_complement
+ from mirtop.mirna.mapper import get_primary_transcript, guess_database
+ from mirtop.bam import filter
+-from mirtop.gff import body
+ from mirtop.mirna.annotate import annotate
+ from mirtop.libs import sql
+
+@@ -72,6 +71,7 @@
+ def low_memory_bam(bam_fn, sample, out_handle, args):
+ if args.genomic:
+ raise ValueError("low-memory option is not compatible with genomic
coordinates.")
++from mirtop.gff import body
+ precursors = args.precursors
+ bam_fn = _sam_to_bam(bam_fn)
+ bam_fn = _bam_sort(bam_fn)
+@@ -100,6 +100,7 @@
+ def low_memory_genomic_bam(bam_fn, sample, out_handle, args):
+ logger.info("Reading BAM file in low memory mode.")
+ logger.warning("This is under development and variants can be unexact.")
++from mirtop.gff import body
+ precursors = args.precursors
+ bam_fn = _sam_to_bam(bam_fn)
+ bam_fn = _bam_sort(bam_fn)
diff -Nru mirtop-0.4.23/debian/patches/series
mirtop-0.4.23/debian/patches/series
--- mirtop-0.4.23/debian/patches/series 2019-12-05 11:42:13.0 +0100
+++ mirtop-0.4.23/debian/patches/series 2021-06-30 20:18:19.0 +0200
@@ -1 +1,2 @@
spelling
+fix-circular-import.patch
diff -Nru mirtop-0.4.23/debian/tests/control mirtop-0.4.23/debian/tests/control
--- mirtop-0.4.23/debian/tests/control 1970-01-01 01:00:00.0 +0100
+++ mirtop-0.4.23/debian/tests/control 2021-06-30 20:18:19.0 +0200
@@ -0,0 +1,3 @@
+Tests: run-unit-test
+Depends: @, python3-nose, samtools, bedtools, seqan-apps
+Restrictions: allow-stderr
diff -Nru mirtop-0.4.23/debian/tests/run-unit-test
mirtop-0.4.23/debian/tests/run-unit-test
--- mirtop-0.4.23/debian/tests/run-unit-test1970-01-01 01:00:00.0
+0100
+++ mirtop-0.4.23/debian/tests/run-unit-test2021-06-30 20:18:19.0
+0200
@@ -0,0 +1,20 @@
+#!/bin/bash
+set -e
+
+CUR_DIR=`pwd`
+if [ "$AUTOPKGTEST_TMP" = "" ] ; then
+ AUTOPKGTEST_TMP=`mktemp -d /tmp/${pkg}-test.XX`
+ trap "rm -rf $AUTOPKGTEST_TMP" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cp -a ${CUR_DIR}/test/ $AUTOPKGTEST_TMP
+cp -a ${CUR_DIR}/data/ $AUTOPKGTEST_TMP
+
+cd $AUTOPKGTEST_TMP
+
+for py in $(py3versions -s 2> /dev/null)
+do
+echo "Testing with $py in $(pwd):"
+nosetests3 -v
+
+done
Bug#990513: texlive-extra-utils: make4ht unusable because make4ht-logging.lua is missing
Package: texlive-extra-utils Version: 2018.20190227-2 Severity: grave Dear Maintainer, Because of make4ht prerequisits texlive-extra-utils should depend on texlive-luatex which should contain make4ht-logging.lua but this is not the case, at least in buster and bullseye. Cf. https://github.com/michal-h21/make4ht/issues/47 for the upstream discussion. Regards JSB -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-extra-utils depends on: ii libunicode-linebreak-perl 0.0.20190101-1 ii python 2.7.16-1 ii tex-common 6.11 ii texlive-base 2018.20190227-2 ii texlive-binaries 2018.20181218.49446-1 ii texlive-latex-base 2018.20190227-2 Versions of packages texlive-extra-utils recommends: ii ghostscript9.27~dfsg-2+deb10u4 ii libfile-homedir-perl 1.004-1 ii liblog-log4perl-perl 1.49-1 ii libyaml-tiny-perl 1.73-1 ii ruby 1:2.5.1 ii texlive-latex-recommended 2018.20190227-2 Versions of packages texlive-extra-utils suggests: pn chktex pn dvidvi pn dvipng pn fragmaster pn lacheck pn latexdiff ii latexmk 1:4.61-0.1 pn purifyeps pn xindy Versions of packages tex-common depends on: ii dpkg 1.19.7 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 12.1.1 Versions of packages texlive-extra-utils is related to: ii tex-common6.11 ii texlive-binaries 2018.20181218.49446-1 -- no debconf information -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Bug#981815: Please explain
On Wed, Jun 30, 2021 at 06:04:57PM +0200, Dennis Filder wrote: > I find the easiest way to inspect what the ultimately executed command > will look like after meta character evaluation is by processing the > output of strace, e.g. like so: > > printf '/dev/null\n/dev/zero\n' > /tmp/files > strace -o '|grep execve' -e trace=execve \ > -s 4096 -f sh -c "/usr/bin/xargs \ > -a /tmp/files -n 1 -d '\n' /usr/bin/stat" I cringe at the necessity of using strace to obtain vital debugging information. Would it be worth to make an upstream withlist request for debugging output of this string so that stracing sudo unnecessary? It is quite hard to strace an suid binary. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#990250: guile-2.2 FTBFS on musl: dh_missing complains about charset.alias
Control: clone -1 -2 Control: reassign -2 src:guile-3.0 On Wed, Jun 23, 2021 at 11:23:58PM +0200, Helmut Grohne wrote: > Source: guile-2.2 > Version: 2.2.7+1-6 > Tags: ftbfs patch upstream > User: helm...@debian.org > Usertags: rebootstrap > > guile-2.2 fails to build from source on musl-linux-any, because the > build generates a charset.alias that is never installed and thus > dh_missing complains: > > | dh_missing: warning: usr/lib//charset.alias exists in debian/tmp > but is not installed to anywhere > | dh_missing: error: missing files, aborting > > It turns out, that this file actually contains only comments for musl, > so it can be skipped like it is skipped for glibc. Please consider > applying the attached patch. guile-3.0 suffers from the same issue and the same patch applies. Helmut
Bug#990440: debianutils: manage /etc/shells declaratively using triggers
Hi Clint, On Wed, Jun 30, 2021 at 12:22:45PM +, Clint Adams wrote: > On Tue, Jun 29, 2021 at 08:01:49AM +0200, Helmut Grohne wrote: > > Please refer to the mailing list discussion for details. > > I don't have time to do that right now, but I wonder if /etc/shells is > really the only file that can/should be managed this way, or if this > can be generalized further. There is no need to read the whole discussion. My bug submission contains the most important parts. If you have any other questions, just ask and I'll answer them on the bug. What other files do you have in mind that could managed similarly? Do I understand correctly that you agree with the approach taken in this patch? Helmut
Bug#990515: release.debian.org: buster->bullseye upgrade issue: sshfs is not upgraded due to fuse/fuse3
Package: release.debian.org
Severity: normal
let's start a discussion here and once we found a package to upgrade,
turn this into an unblock request.
sshfs is sometimes kept at the buster version because of some dependency
mess of fuse/fuse3.
This usually shows up in large metapackages like freedombox or kde-full
with --install-recommends enabled. Probably because there are additional
dependency paths on fuse.
* sshfs/buster depends on fuse
* sshfs/bullseye depends on fuse3
* fuse still exists in bullseye as a real package
* fuse3/bullseye has Conflicts/Replaces: fuse and a
versioned Provides: fuse (= ${source:Version})
Upgrading would require kicking out fuse and installing fuse3 but apt
does not do that, as so often.
This isn't solved by a followup distupgrade either.
I haven't found a solution adding more Breaks: fuse to various packages
to solve this cleanly. Naturally I would have suggested to add a
transitional fuse binary package to src:fuse3 which just
Depends: fuse3 (= ${binary:Version}) and adjust the Breaks/Replaces in
fuse3 to fuse (<< 3). src:fuse then should drop its fuse package (or
rename it to fuse2 while adding a '2' to all filenames).
I'm also not convinced that fuse3 is a real replacement for fuse: it has
symlinks foo -> foo3 for all binaries and manpages. But the initramfs
hook only does 'copy_exec /sbin/mount.fuse3 /sbin', it does not care
about /sbin/mount.fuse
Andreas
Bug#940707: [Pkg-clamav-devel] Bug#940707: clamdscan: "LibClamAV Error: pdf_find_and_extract_objs: Timeout" since update to 0.101.4+dfsg-0+deb10u1
On 2019-09-19 12:04:41 [+0200], Dominik wrote: > with the update to 0.101.4+dfsg-0+deb10u1 clamd frequently reports: > LibClamAV Error: pdf_find_and_extract_objs: Timeout reached in the PDF parser > while extracting objects. > > This has not occured before the update - thus it is surprising. > > It is not clear, where to configure longer timeouts for scanning pdf. > > The error should be more explicit about this. > > Probably, the default timeout should also be increased. Is this still there? This comes from the pdf-part of the code because scanning a given .PDF file takes longer than the limit. The limit is by default MaxScanTime 12 is time in ms, here 120 seconds or two minutes. So it took longer than that and then it aborted, most likely a DoS prevention where an infinite loop would occupy the daemon forever. The surprising part is that according to your clamd.conf you have > Config file: clamd.conf > --- > MaxScanTime disabled which means no limit, take all the time you need. Sebastian
Bug#990513: texlive-extra-utils: make4ht unusable because make4ht-logging.lua is missing
Control: tags -1 + buster Am 01.07.2021 um 07:42 teilte Janusz S. Bień mit: Hi Janusz, Because of make4ht prerequisits texlive-extra-utils should depend on texlive-luatex which should contain make4ht-logging.lua but this is not the case, at least in buster and bullseye. Cf. https://github.com/michal-h21/make4ht/issues/47 for the upstream discussion. AFAICT the requested file is in texlive-extra-utils itself: hille@sid:~ $ apt-file search make4ht-logging.lua texlive-extra-utils: /usr/share/texlive/texmf-dist/scripts/make4ht/make4ht-logging.lua This is for Debian unstable / testing. So in my eyes the issue is for buster. I tag it buster for now, but I have doubt that we'll make attempts to fix it. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
