Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup
On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote: > The attached patch is an attempt to grow the buffer size > if the header changes on a new page. > This is just tested for the given crash, nothing more, therefore > there might be side effects on replacing this buffer? It doesn't look unreasonable to me, although the related shuffling of pointers between rgbRaster, kRaster and m_pPrinterBuffer makes my head hurt a bit (this code could really do with a dollop of modern c++ memory management idiom). Do you think there is a need to preserve the current contents (e.g. something approximating realloc rather than delete+new)? Or maybe it is fine to simply unconditionally allocate a new buffer each time round the loop? It could almost be a local variable like *Raster at that point... But I think if you are looking for a minimal fix your patch seems pretty sensible to me (speaking as a competent enough C/C++ programmer but not someone familiar with this codebase before today). Ian.
Bug#983365: Info received (Bug#983365: linphone-desktop: chat messages)
Okay, I do see a difference in behaviour now in sqlitebrowser: with my soci-enabled liblinphone packages installed I see entries being added to table ~/.local/share/linphone/linphone.db:chat_message_content and other tables. The timestamps in chat_message_participant also line up perfectly with the time of installation. I even downgraded again to the current bullseye packages for comparison, and with them installed nothing was added to the database when sending messages. So compiling that in certainly had some effect. And it could actually mean that a new upload of linphone-desktop can be avoided (at least for now). I don't see the message history reappearing in the app though, but that could be because my SIP gateway doesn't relay the messages correctly. I think linphone might only show in its history messages whose reception was acknowledged by the other side. Until then they might be stored in the DB to be delivered once the other side becomes reachable again. What puzzles me a bit is that the submitter saw messages in the DB. But maybe those were from when he (presumably) used the appimage version. I'll try to get asterisk to work and see if I can find out more with that.
Bug#980305: RFA: libcddb2
On 17/01/21 23:35 pm, Eugene V. Lyubimkin wrote: > > The libcddb package needs a new maintainer. I no longer have time nor > interest to maintain it properly. > > I had adopted it many years as a dependency of a package I no longer > maintain. It was very low-maintenance until recently; there are now two > outstanding bug reports which require attention [1]. > > If you maintain one of Debian packages that depend on libcddb (Cc:d), > you might be interested in adopting it. > Hi Eugene, I'm not maintaining a dependent package but I'd like to help Debian more. I took a look at the two open bugs and I think they can be fixed quite easily with the patches I attached. Let me know if you're happy for me to adopt it. -- Thanks, Nick
Bug#928176: vlc: BOBOOvlc cannot play cd audio without net connection and crash
On 01/17/21 22:54 pm, Sebastian Ramacher wrote: >> >> In https://trac.videolan.org/vlc/ticket/25252, upstream answer : >> >> > That CDDB bug was fixed 9 years ago in VLC contribs. Complain to Debian. >> >> Can you have a look on debian side ? > > Reassigning to libcddb2. > I believe this is the patch in VLC's vendored copy they are referring to: https://code.videolan.org/videolan/vlc/-/commit/29d3ded7194271 It disables the use of alarm() to set a timeout for gethostbyname() which isn't safe if called from a program with multiple threads. > >> >> I made test with fedora 33 live + install proccess >> (https://www.videolan.org/vlc/download-fedora.html). >> vlc is functional. >> Fedora seems to use a different patch which just disables _FORTIFY_SOURCE in that file to avoid the longjmp() crash: https://src.fedoraproject.org/rpms/libcddb/blob/rawhide/f/libcddb-1.3.2-rhbz770611.patch Although I think it still has a problem where SIGALRM can be delivered to any thread in the program, so it's better to avoid using alarm() entirely as the VLC patch does. gethostbyname will time out by itself anyway. I've rebuilt the package with the patch below and tested locally without any problems. diff --git a/lib/cddb_net.c b/lib/cddb_net.c index 7adf37b..aac3967 100644 --- a/lib/cddb_net.c +++ b/lib/cddb_net.c @@ -228,6 +228,10 @@ int sock_vfprintf(cddb_conn_t *c, const char *format, va_list ap) /* Time-out enabled work-alikes */ +/* Do not use SIGALRM in Debian as it is not safe if used in a program + with multiple threads. */ +#undef HAVE_ALARM + #ifdef HAVE_ALARM /* time-out jump buffer */ static jmp_buf timeout_expired; -- Thanks, Nick
Bug#952689: libcddb2: freedb service is closing down
On 02/27/20 23:19 pm, Andreas Ronnquist wrote: > > According to a notice on https://freedb.org, that service is closing > down. I assume that libcddb is using that server, and only that - > please inform me if I am mistaken. > The patch below changes the default server to gnudb.org. I've tested locally with the cddb_query tool and it works fine: diff --git a/include/cddb/cddb_ni.h b/include/cddb/cddb_ni.h index d32fdc1..4156bdb 100644 --- a/include/cddb/cddb_ni.h +++ b/include/cddb/cddb_ni.h @@ -78,8 +78,8 @@ #define DEFAULT_USER"anonymous" #define DEFAULT_HOST"localhost" -#define DEFAULT_SERVER "freedb.org" -#define DEFAULT_PORT888 +#define DEFAULT_SERVER "gnudb.gnudb.org" +#define DEFAULT_PORT8880 #define DEFAULT_TIMEOUT 10 #define DEFAULT_PATH_QUERY "/~cddb/cddb.cgi" #define DEFAULT_PATH_SUBMIT "/~cddb/submit.cgi" -- Thanks, Nick
Bug#785495: Bug is back on 3.38.2.1-1
Hi all, With Buster (gdm3 3.30.2-3 ) using DisallowTCP=false add the "-listen tcp" in command line and I can connect remotely. With gdm3 3.38.2.1-1, using DisallowTCP=false remove the "-nolisten tcp" but do not add "-listen tcp" so I can not connect remotely. Thanks
Bug#565156: ITA: fbcat -- framebuffer grabber
Control: retitle -1 ITA: fbcat -- framebuffer grabber Control: owner -1 Micheal Waltz -- Micheal Waltz https://keybase.io/ecliptik GPG Fingerprint: 5F70 F2AC BD58 F580 DF15 3D1F 4FA2 70F5 CD36 71F9 signature.asc Description: PGP signature
Bug#981754:
I made a merge request for 7.7 here: https://salsa.debian.org/debian/dkopp/-/merge_requests/3 Please take a look :)
Bug#983486: zipl: allow other packages to provide config snippets
On Thu, 25 Feb 2021, 07:51 Christian Borntraeger, wrote: > > > On 24.02.21 23:40, dann frazier wrote: > > Source: s390-tools > > Version: 2.15.1-2 > > > > I'm one of the maintainers of kdump-tools, which has a need to manipulate > > the kernel command line parameters in boot loader configurations. > > Currently zipl provides no way to do this without modifying > > /etc/zipl.conf directly. It would be helpful if there was e.g. an > > /etc/zipl.conf.d/ interface for dropping in additional configuration. > > > > As an example, GRUB provides an /etc/default/grub.d/ directory, which > > allows us to drop in a file like this: > > > > $ cat /etc/default/grub.d/kdump-tools.cfg > > GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT > crashkernel=384M-:128M" > > > > One idea of how to implement this would be to do something similar to > > GRUB and ship a tool (say, update-zlib) that generates a static > > /etc/zlib.conf as directed by a set of shell variables (say > > /etc/default/zlib). It could then process a directory of snippets (say > > /etc/default/zlib.d/*) allowing other packages to tweak/override the > > configuration defined by those variables. > > > > I realize that while that this design would have an upgrade problem > > for existing users, but perhaps we could provide an opt-in-only > > migration path. > > > > Newer zipls also provide a way to specify BLS entries > https://systemd.io/BOOT_LOADER_SPECIFICATION/ > would that help you? > grub.d snippets are typically used to extend kernel cmdline arguments for all entries. Is there variable substitution available? As far as I understand it BLS is purely declarative and there is no ability to say "and append this value to all entries", "and append that value to all entries". >From locations that have drop-ins from packaged software and/or user. Also in Debian / Ubuntu we only generate two static entries in zipl.conf for the current and last kernel. BSL might be useful for us to list all installed / bootable kernels. But not sure how to reconcile that with arguments in zipl.conf. If something like a zipl.conf.d is still considered valueable, maybe > open an issue for the > upstream project https://github.com/ibm-s390-linux/s390-tools/issues >
Bug#983587: https://wiki.debian.org/KDE#Making_GNOME.2FGTK_applications_look_natural: file not foundE (GTK)" needs review
On Fri, Feb 26, 2021 at 7:36 PM Scorpion2185 wrote: > I think that the wiki needs a review: If you know what the fix is, please register an account and add the fix to the page. If you don't know what the fix is, please discuss the issue on the Debian support channels and the people there will help you find the solution or find the appropriate team to ask about the issue. https://www.debian.org/support -- bye, pabs https://wiki.debian.org/PaulWise
Bug#983601: aux.c: changes in the file
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From 4bbc72a38a25a19afdce68bdb7e4f3d394afbf16 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Sat, 27 Feb 2021 00:59:50 +
>Subject: [PATCH] aux.c: changes in the file
Use named constants instead of a number for the declaration of number
of array elements.
Use "snprintf()" instead of "sprintf()".
Add information to some output.
Fix a warning:
aux.c:359:16: warning: comparison with string literal results in unspecified
behavior [-Waddress]
359 | if (action != "send") {
|^~
Fix a warning by turning the line into a comment:
aux.c:472:7: warning: the address of 'lookfor' will always evaluate as 'true'
[-Waddress]
472 | if (lookfor); /* grep for lookfor */
| ^~~
Fix a warning by turning the line into a comment:
aux.c:557:7: warning: the address of 'fname' will always evaluate as 'true'
[-Waddress]
557 | if (fname)
Maybe the test should be to test, if "fname" is not empty?
Signed-off-by: Bjarni Ingi Gislason
---
aux.c | 58 --
1 file changed, 36 insertions(+), 22 deletions(-)
diff --git a/aux.c b/aux.c
index 7802288..5ce9271 100644
--- a/aux.c
+++ b/aux.c
@@ -26,6 +26,8 @@ extern char*temp_file;
extern int novice;
extern char delayed_msg[];
+/* number for array delayed_msg[] in"master.c" and "menu.c" */
+extern const size_tndelayed_msg;
extern char*pager;
extern char*inews_program;
extern int inews_pipe_input;
@@ -102,8 +104,9 @@ aux_sh(article_header * ah, char *script, char *prog, char
*action, char *record
* find the .param file, can't always look in $HOME/.nn
*/
if (!getenv("NNDIR")) {
- charebuf[FILENAME + 8];
- sprintf(ebuf, "NNDIR=%s", nn_directory);
+#define NEBUF FILENAME + 8;
+ charebuf[NEBUF];
+ snprintf(ebuf, NEBUF, "NNDIR=%s", nn_directory);
putenv(ebuf);
}
if (strcmp(prog, "cancel") == 0) {
@@ -175,10 +178,10 @@ no_params:
*ap++ = NULL;
if (execute(SHELL, args, 1)) {
- sprintf(delayed_msg, sent_fmt, " not");
+ snprintf(delayed_msg, ndelayed_msg, sent_fmt, " not");
return 1;
}
-sprintf(delayed_msg, sent_fmt, "");
+snprintf(delayed_msg, ndelayed_msg, sent_fmt, "");
return 0;
}
@@ -192,7 +195,7 @@ tempsuffix(char *name, char *suffix)
{
static char concat_name[FILENAME];
-sprintf(concat_name, "%s%s", name, suffix);
+snprintf(concat_name, FILENAME, "%s%s", name, suffix);
return concat_name;
}
@@ -293,8 +296,10 @@ aux_sh(article_header * ah, char *script, char *prog, char
*action, char *record
charroute[512], *poster = NULL;
int goodsigntype = 0;
int loop = 1, prmpt = 0;
-charcc[256], pr[80], pr1[80], fname[FILENAME], buf[80];
-charbuf2[10];
+#define NBUF 80
+#define NBUF2 10
+charcc[256], pr[80], pr1[80], fname[FILENAME], buf[NBUF];
+charbuf2[NBUF2];
charlookfor[16], send[8], sent[8], sendpr[8], message[8];
int x, act = response_dflt_answer[0];
struct stat statb;
@@ -334,7 +339,7 @@ aux_sh(article_header * ah, char *script, char *prog, char
*action, char *record
fprintf(temp, "\n");
fprintf(temp, "cancel %s in newsgroup %s\n", action, record);
fprintf(temp, "\n");
- fprintf(temp, "This article was cancelled from within %s\n",
version_id);
+ fprintf(temp, "This article was cancelled from within nn %s\n",
version_id);
fprintf(temp, "\n");
fclose(temp);
x = (nntp_post(temp_file));
@@ -356,7 +361,7 @@ aux_sh(article_header * ah, char *script, char *prog, char
*action, char *record
strcpy(message, "letter");
}
-if (action != "send") {
+if (strcmp(action, "send") != 0) {
strcpy(copy, tempsuffix(temp_file, "C"));
copy_file(temp_file, copy, 0);
}
@@ -447,7 +452,7 @@ aux_sh(article_header * ah, char *script, char *prog, char
*action, char *record
strncpy(buf, editor_program, 50);
if (use_ed_line) {
- sprintf(buf2, " +%d", ed_line);
+ snprintf(buf2, NBUF2, " +%d", ed_line);
strcat(buf, buf2);
}
strcat(buf, " ");
@@ -457,19 +462,22 @@ aux_sh(article_header * ah, char *script, char *prog,
char *action, char *record
nn_raw();
if (stat(temp_file, &statb) < 0 || statb.st_size == 0) {
- sprintf(delayed_msg, sent_fmt, " not");
+ snprintf(delayed_msg, ndelayed_msg, sent_fmt, " not");
unlink(temp_file);
unlink(copy);
return (22);
}
if (empty_answer_che
Bug#940621: libmeanwhile1: Login verification down or unavailable on 1.0.2-9+b1
Control: found -1 1.0.2-9+b1 Control: fixed -1 1.0.2-9 Hi, 在 2021-02-26星期五的 10:47 +0100，Adrien CLERC写道： > On Fri, 26 Feb 2021 09:23:03 +0100 Adrien CLERC > wrote: > > > > Boyuan Yang, can you reintroduce -fno-tree-vrp in CFLAGS please? I > can't > > > connect to Sametime right now. > > I did a lot of tests, and it seems that only "export > DEB_CFLAGS_MAINT_APPEND=-O0" fix this issue. > > Applying manual optimizations from O1 or O2 didn't trigger the issue, > but unfortunately, some flags don't exist (see > https://gcc.gnu.org/wiki/FAQ#optimization-options) > > And applying "-O0 -O1" trigger the issue. If you have more thing in > mind, please tell me, I am able to test it. But I'll stick to -O0 for > my > local installation Since the hard freeze is approaching, I will go with the conservative way and upload meanwhile/1.1.1-2 with the following line: export DEB_CFLAGS_MAINT_APPEND=-O0 -fno-tree-vrp Please test whether the built package fixes the bug once you have access to meanwhile/1.1.1-2 in Debian Sid. Let me know if it needs further fix. -- Thanks, Boyuan Yang
Bug#983525: [Debian-on-mobile-maintainers] Bug#983525: Bug#983525: Bug#983525: Update to 1.1 in experimental
Hi, Le 26/02/2021 à 14:25, Guido Günther a écrit : Hi, On Fri, Feb 26, 2021 at 12:57:25PM +0100, Sebastien Bacher wrote: Le 26/02/2021 à 12:36, Guido Günther a écrit : Uploaded. Given the libhandy lives under GNOME/ upstream for some time i wonder if we shouldn't move it over in Debian too? Cheers, +1 from me, let me know if you want me to push the vcs to pkg-gnome? Fine with me. Let's give Arnaud a chance to object. I think both of us aren't members of the `gnome-team` salsa group so if we should continue to help we'd need to be added (I'll request membership via web-ui once the package moved). Sure, I fully approve moving this package to the `gnome-team` group, I'll request access once it's done so I can continue helping with its maintenance. Cheers, Arnaud Cheers, -- Guido ___ Debian-on-mobile-maintainers mailing list debian-on-mobile-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers ___ Debian-on-mobile-maintainers mailing list debian-on-mobile-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
Bug#983471: rspamd should depend libjs-jquery
On Wed, Feb 24, 2021 at 07:09:20PM (+0100), Jean Charles Delépine wrote: > Versions of packages rspamd depends on: > ii adduser 3.118 > ii ca-certificates 20200601 > ii fonts-glyphicons-halflings 1.009~3.4.1+dfsg-1 > ii init-system-helpers 1.60 > ii libc6 2.31-9 > ii libgcc-s1 10.2.1-6 > ii libglib2.0-02.66.4-1 > ii libhyperscan5 5.4.0-2 > ii libicu6767.1-5 > ii libjs-bootstrap44.5.2+dfsg1-4 > ii libjs-jquery3.5.1+dfsg+~3.5.5-7 > ii libjs-requirejs 2.3.6+ds-1 > ii libluajit-5.1-2 2.1.0~beta3+dfsg-5.3 > ii libpcre2-8-010.36-2 > ii libsodium23 1.0.18-1 > ii libsqlite3-03.34.0-1 > ii libssl1.1 1.1.1i-1 > ii libstdc++6 10.2.1-6 > ii libunwind8 1.3.2-2 > ii lsb-base11.1.0 > ii perl5.30.3-4 > ii zlib1g 1:1.2.11.dfsg-2 Hello Jean Charles, Thank you for this bug report ! Could you please post the full installation log ? As mentioned by your reportbug log, libjs-jquery package is already a dependency of rspamd. - https://packages.debian.org/unstable/rspamd Debian CI seems ok and piupart too - https://ci.debian.net/packages/r/rspamd/testing/amd64/ - https://piuparts.debian.org/sid/source/r/rspamd.html I can't reproduce your issue for the moment, your installation log will help. Thanks in advance ! Sebastien
Bug#983435: Regarding the backup/restore function
On Fri, 26 Feb 2021 15:21:59 + Dimitri John Ledkov wrote: >are grub.mo from grub-common somehow excluded on the system? I have no idea, I don't have localepurge installed on that machine. I belive those missing grub.mo's are actually not in debian's grub-common, or rather, not in the entire debian archive. At least, packages.debian.org/search doesn't show e.g. /fa/LC_MESSAGES/grub.mo anywhere anysuite, so no one in debian world should have that file...? Being just a router, the machine have very minimum packages installed (besides gcc to compile kernel), so there may be some missing executables used by grub-install. For reference, the list of installed packages (distilled from /var/lib/dpkg/status of the disk image) is pasted below. >For me to avoid doing it on_exit() >would mean to rewrite all the places where grub_install tries to exit >to try to do cleanups & restores. Would doing it in grub-install >without on_exit inspire more confidence, or guarding to only do >anything in the main_pid of grub-install? Should the log of actions be >maintained and then rolled back only if they can be? I'm not familiar to codes, take with a grain of salt: Given the structure of upstream code, entirely avoiding on_exit() would result to more intrusive patch. As for log-and-rewind strategy (with or without on_exit)... I thought that first, but then isn't it better to stop creating new installs in-place from the very first? Instead create new in temporary, and finally swap old with new. As the modules directory should once have been created by grub-install itself, I thought we're allowed to move it around, and then we don't have to track all of individual old files...? But for now, guarding by main_pid, patching up every fork()'s, and proper logging for --verbose would be nice to have, I guess. Of course, BIG RED BOLD BANNER and couple of beeps should be put whenever detected misfire :-) Thanks in advance, list of installed packages on my problematic router: adduser apt aptitude aptitude-common attr base-files base-passwd bash bc binutils binutils-common binutils-x86-64-linux-gnu bison bsdmainutils bsdutils build-essential bzip2 conntrack console-setup-linux console-setup-mini coreutils cpio cpp cpp-8 dash debconf debian-archive-keyring debianutils dhcpcd5 diffutils dmsetup dns-root-data dnsmasq dnsmasq-base dosfstools dpkg dpkg-dev e2fsprogs ethtool fakeroot false-sendmail false-strongswan-starter false-unbound-anchor fcron fdisk findutils flex g++ g++-8 gcc gcc-8 gcc-8-base gettext-base gpgv grep groff-base grub-common grub-efi-amd64 grub-efi-amd64-bin grub2-common gzip hostname ifupdown init init-system-helpers initscripts insserv iproute2 iputils-tracepath kbd keyboard-configuration kmod ldnsutils libacl1 libapt-pkg5.0 libasan5 libatomic1 libattr1 libaudit-common libaudit1 libbinutils libbison-dev libblkid1 libboost-iostreams1.67.0 libboost-system1.67.0 libbsd0 libbz2-1.0 libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libc6-i386 libcap-dev libcap-ng0 libcap2 libcap2-bin libcc1-0 libcom-err2 libcurl4 libcwidget3v5 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libdpkg-perl libefiboot1 libefivar1 libelf1 libevent-2.1-6 libexpat1 libext2fs2 libfakeroot libfdisk1 libffi6 libfreetype6 libfuse2 libgcc-8-dev libgcc1 libgcrypt20 libgdbm3 libglib2.0-0 libgmp10 libgomp1 libgpg-error0 libhogweed4 libidn11 libip4tc0 libip6tc0 libisl19 libitm1 libivykis0 libjansson4 libjson-c3 libkmod2 libldns2 liblocale-gettext-perl liblsan0 liblz4-1 liblzma5 libmnl0 libmount1 libmpc3 libmpdec2 libmpfr6 libmpx2 libncurses-dev libncurses6 libncursesw6 libnet1 libnetfilter-acct1 libnetfilter-conntrack3 libnetfilter-log1 libnettle6 libnewt0.52 libnfnetlink0 libnftables1 libnftnl11 libpam-modules libpam-modules-bin libpam-runtime libpam0g libpcap0.8 libpcre3 libperl5.24 libpipeline1 libpng16-16 libpopt0 libprocps7 libprotobuf-c1 libpython3.7 libpython3.7-minimal libpython3.7-stdlib libquadmath0 libreadline7 libselinux1 libsemanage-common libsemanage1 libsepol1 libsigc++-2.0-0v5 libsigsegv2 libslang2 libsmartcols1 libsqlite3-0 libss2 libssl-dev libssl1.1 libstdc++-8-dev libstdc++6 libstrongswan libstrongswan-standard-plugins libsystemd0 libtinfo6 libtsan0 libubsan1 libudev1 libustr-1.0-1 libutempter0 libuuid1 libwrap0 libxapian30 libxtables12 linux-image-4.19.171 linux-libc-dev linux-source-4.19 locales login lsb-base lv m4 make makedev man-db mawk mime-support mount ncurses-base ncurses-bin netbase nftables ngetty openssl passwd patch perl perl-base perl-modules-5.24 pkg-config procps readline-common rng-tools5 screen sed sensible-utils startpar strongswan-charon strongswan-libcharon strongswan-swanctl syslog-ng-core syslog-ng-mod-getent syslog-ng-mod-journal sysv-rc sysvinit-core sysvinit-utils tar tzdata ucf ulogd2 ulogd2-pcap unbound util-linux watchdog whiptail xz-utils zlib1g zlib1g-dev (note: false-* is dummies to shut up dpkg, but I'm fairly sure they're not related to grub, never.)
Bug#983600: libopenmpi-dev: Can not install with multi-arch
Package: libopenmpi-dev Version: 4.1.0-7 Severity: important Dear Maintainer, libopenmpi-dev is marked 'Multi-Arch: same' but cannot be installed. It seems that gfortran-10:ARCH is included in Depends. ``` $ LANG=C sudo apt-get install libopenmpi-dev:arm64 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libopenmpi-dev:arm64 : Depends: gfortran-10:arm64 but it is not going to be installed or gfortran-mod-15:arm64 Recommends: libcoarrays-openmpi-dev:arm64 but it is not going to be installed E: Unable to correct problems, you have held broken packages. ``` Could you check it? Best regards, Nobuhiro -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#983587: GNOME apps with dark theme on KDE plasma
Now I can also use GNOME apps with the dark theme on KDE plasma.
Bug#983598: lintian: package-installs-apt-sources emitted for packages whose names end in -archive-keyring
Felix Lechner writes: > On Fri, Feb 26, 2021 at 2:36 PM Ferenc Wágner wrote: > >> only the first suffix is exempted > > Which package triggers the false positive, please? Thank you! Hi Felix, The one I created tonight based on the instructions at https://wiki.debian.org/DebianRepository/UseThirdParty, called elastic-archive-keyring. It indeed ships a file under /etc/apt/sources.list.d. (And another under /etc/apt/preferences.d, which Lintian also complains about, but that tag hasn't got contradicting documentation.) -- Regards, Feri
Bug#983589: w3m: Cannot verify certificates any more
On 2021-02-27 at 08:22, Tatsuya Kinoshita wrote: > -2 implicitly adds OpenSSL default paths that helps you, but > I think this is a bug and fixed in -3. However, this is a long-standing feature. I'll reconsider for the next upload. Thanks, -- Tatsuya Kinoshita pgpoM3ie625SY.pgp Description: PGP signature
Bug#983587: https://wiki.debian.org/KDE#Making_GNOME.2FGTK_applications_look_natural: file not foundE (GTK)" needs review
Package: wiki.debian.org Severity: normal Tags: patch Dear Maintainer, I think that the wiki needs a review: "[...] you may try editing the ~/.config/gtk-3.0/gtk.css file Comment out the "@import 'colors.css';" line by adding a # character before it, so that the line looks like: # @import 'colors.css';" I added KDE plasma on my computer with GNOME, debian 10. I don't have that file (gtk.css). On GNOME I am using (adwaita) dark theme, I changed the value of this line in ~/.config/gtk-3.0/settings.in that before was 0: gtk-application-prefer-dark-theme=1 I also changed it in ~/.config/gtk-4.0. I think that the solution is to simply set the adwaita dark theme in KDE "System Settings/GNOME Application Style (GTK)". That probably corrects the ~/.config/gtk-3.0/settings.ini file. Gparted was working bad on GNOME. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 [Settings] gtk-application-prefer-dark-theme=0
Bug#983586: linux-image-5.10.0-3-amd64: Please configure kernel with CONFIG_AMD_MEM_ENCRYPT=y
Hi, Le 2021-02-26 20:26, bs.net a écrit : > Package: src:linux > Version: 5.10.13-1 > > Dear Maintainer, > > please consider to set the Linux kernel option "CONFIG_AMD_MEM_ENCRYPT=y". > > Without that option it is not possible to enable the memory encryption for AMD > Secure Memory Encryption (SME). I sent a merge request [1] to enable this feature, but it was deemed a bit late for Bullseye. > Thank you very much. > > With kind regards Cheers, Vincent [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/322 signature.asc Description: PGP signature
Bug#983589: w3m: Cannot verify certificates any more
On 2021-02-26 at 23:54 +0100, Samuel Thibault wrote: > ssl_ca_file > ssl_ca_path /etc/ssl/certs, ~/.ssl/certs Ah, multiple paths in ssl_ca_path is not supported. The value is directly passed to OpenSSL's SSL_CTX_load_verify_locations. So, your configuration means the single nonexistence directory "/etc/ssl/certs, ~/.ssl/certs" is used. -2 implicitly adds OpenSSL default paths that helps you, but I think this is a bug and fixed in -3. Probably, you should set the following. ``` ssl_ca_file /etc/ssl/certs/ca-certificates.crt ssl_ca_path ~/.ssl/certs ``` Thanks, -- Tatsuya Kinoshita pgppQSAUyauh8.pgp Description: PGP signature
Bug#983589: w3m: Cannot verify certificates any more
Tatsuya Kinoshita, le sam. 27 févr. 2021 07:36:20 +0900, a ecrit: > On 2021-02-26 at 21:25 +0100, Samuel Thibault wrote: > > Since version 0.5.3+git20210102-3 of w3m (downgrading to -2 fixes it), > > all https website give me > > > > unable to get local issuer certificate: accept? (y/n) > > Hmm, could you please tell me your configuration of ssl_ca_path > and ssl_ca_file in <~/.w3m/config> and ? I have ssl_ca_file ssl_ca_path /etc/ssl/certs, ~/.ssl/certs Samuel
Bug#983585: RFS: prometheus-cpp/0.12.1-1 [ITP] -- Prometheus Client Library for Modern C++
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "prometheus-cpp": * Package name: prometheus-cpp Version : 0.12.1-1 Upstream Author : https://github.com/jupp0r/prometheus-cpp/issues * URL : https://github.com/jupp0r/prometheus-cpp * License : Expat, 0BSD, Apache-2.0 * Vcs : https://salsa.debian.org/debian/prometheus-cpp Section : libs It builds those binary packages: libprometheus-cpp-push0.12 - Prometheus Client Library for Modern C++ (push gateway support) libprometheus-cpp-pull0.12 - Prometheus Client Library for Modern C++ (pull support) libprometheus-cpp-core0.12 - Prometheus Client Library for Modern C++ (core metrics) prometheus-cpp-dev - Prometheus Client Library for Modern C++ (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/prometheus-cpp/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/prometheus-cpp/prometheus-cpp_0.12.1-1.dsc Changes for the initial release: prometheus-cpp (0.12.1-1) unstable; urgency=medium . * Initial release (Closes: #917817) Regards, -- Gregor Jasny
Bug#983599: New upstream version v579
Package: less Version: 551-2 Severity: wishlist Hi, it seems the currently latest upstream version is v579: https://github.com/gwsw/less/releases/tag/v579 It would be great if you could update less accordingly. My motivation for this change is https://github.com/systemd/systemd/commit/ebef02dd8f35f8b6ee58060b71b7f321a5027760 Regards, Michael -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND 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 less depends on: ii libc6 2.31-9 ii libtinfo6 6.2+20201114-2 less recommends no packages. less suggests no packages. -- no debconf information
Bug#983598: lintian: package-installs-apt-sources emitted for packages whose names end in -archive-keyring
Hi Ferenc, On Fri, Feb 26, 2021 at 2:36 PM Ferenc Wágner wrote: > > only the first suffix is exempted Which package triggers the false positive, please? Thank you! Kind regards Felix Lechner
Bug#983589: w3m: Cannot verify certificates any more
On 2021-02-26 at 21:25 +0100, Samuel Thibault wrote: > Since version 0.5.3+git20210102-3 of w3m (downgrading to -2 fixes it), > all https website give me > > unable to get local issuer certificate: accept? (y/n) Hmm, could you please tell me your configuration of ssl_ca_path and ssl_ca_file in <~/.w3m/config> and ? The intentional change in -3 means that OpenSSL default paths will not be loaded if you set ssl_ca_path or ssl_ca_file. All the following should work in -3. w3m -dump -o ssl_ca_path= -o ssl_ca_file=/etc/ssl/certs/ca-certificates.crt https://www.debian.org w3m -dump -o ssl_ca_path=/etc/ssl/certs -o ssl_ca_file= https://www.debian.org w3m -dump -o ssl_ca_path= -o ssl_ca_file= https://www.debian.org Thanks, -- Tatsuya Kinoshita pgpDAjuApmgHT.pgp Description: PGP signature
Bug#983598: lintian: package-installs-apt-sources emitted for packages whose names end in -archive-keyring
Package: lintian Version: 2.15.0 Severity: normal Dear Maintainer, The tag info for package-installs-apt-sources states that "packages whose names end in -apt-source or -archive-keyring are permitted to install such files. However, only the first suffix is exempted by the code. I don't know whether the documentation or the implementation is right; please fix the one which isn't. -- Thanks, Feri.
Bug#982591: grub-pc can't be updated non-interactively on debian/buster64
On 26/02/21 at 20:07 +0100, Lucas Nussbaum wrote:
> On 14/02/21 at 08:48 +0100, Evgeni Golov wrote:
> > On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
> > > IMO we cannot know which device name is used by the users virtualisation
> > > environment.
> > > So, what is the be setting without knowing the device name?
> > >
> > > Or is /dev/sda used in most enviroments?
> >
> > For VirtualBox sda is a pretty safe bet, for libvirt it'd be either sda
> > or vda (and I think we could set both in debconf, as that's a
> > multiselect). AWS has another one, vxda I think? But this explicit bug
> > is about vagrant (so virtualbox and libvirt) only anyways.
> >
> > The only thing to consider with this approach: it should only be done
> > when preparing images, not installing "real" systems. So in the
> > cloud.d.o context that's safe, but probably not as a generic default in
> > FAI and other tools.
>
> Maybe a better approach (but still hackish) would be to set it at first
> boot, in a way similar to
> https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/files/etc/systemd/system/generate-sshd-host-keys.service/VAGRANT
>
> Running Something like:
> echo grub-pc grub-pc/install_devices multiselect $(awk '{ if ($2 == "/") {
> sub(/1$/, "", $1) ; print $1 } }' /proc/mounts) | debconf-set-selections
Tentative patch:
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/b82d522f65b507767f909b2b9471c5a9ade75e05
Lucas
Bug#982356: (no subject)
On 26/02/21 at 22:17 +0100, Lucas Nussbaum wrote: > On 25/02/21 at 19:06 +0100, Emmanuel Kasper wrote: > > I think this bug is due to the switch to fai for testing/bullseye. > > IIRC with fai, we run a dhcp client for each interface, which would > > cause the double IP adresses you see (one set up by DHCP, one set up by > > Vagrant directly over ssh when booting the VM) > > Right. But the solution is not obvious. > > If we want to do DHCP only on the first interface, we need to hardcode > this in the image. But how can we know the name of the interface? > Apparently it's enp0s3 with virtualbox, and something different with > libvirt (because my test fails). > > We could go back to traditional names and do DHCP on eth0... Tentative patch that doesn't work completely because of the above issue: https://salsa.debian.org/cloud-team/debian-vagrant-images/-/commit/735f0a2ba3ad1124fa0c86b159a31e94489807c6 Lucas
Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Package: libqt5quick5 Version: 5.15.2+dfsg-4 Architecture: amd64 Severity: normal Tags: sid bullseye a11y upstream patch confirmed Control: affects -1 + linphone-desktop The segfault happens * both with and without a preexisting configuration, * only if Orca is running in the same session. Without Orca the segfault does not happen. Reproducer: . Start Orca . Start linphone . If already configured: click "Assistant" (skip otherwise) . Click "Use a SIP account" . Enter as Username: a . Enter as SIP Domain: b . Enter as Password: c . Click on "Use". The program segfaults with a stacktrace like the attached with the top-most 5 frames pasted below: -- #0 0x in () #1 0x774d7ba7 in QQuickItemLayer::~QQuickItemLayer() (this=0x581100e0, __in_chrg=) at items/qquickitem.cpp:8338 (/lib/x86_64-linux-gnu/libQt5Quick.so.5) #2 0x774d7be9 in QQuickItemLayer::~QQuickItemLayer() (this=0x581100e0, __in_chrg=) at items/qquickitem.cpp:8340 #3 0x7764b21b in QAccessibleQuickItem::role() const (this=0x5811e0d0) at accessible/qaccessiblequickitem.cpp:215 #4 0x7fffeb1f18ca in () at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 ... -- A web search for "segfault" "QQuickItemLayer::~QQuickItemLayer" produces an qt.io forum thread[1] where someone segfaulted with an almost identical stacktrace with a virtual keyboard. Thus I mark this bug as confirmed. If you decide to use the attached patch, please put the bugnumber in the Bug-Debian: field for me. Regards, Dennis. 1: https://forum.qt.io/topic/105120/qt-application-crash-with-onboard-virtual-keyboard-with-non-root-users qtdecl-segfault.patch.gz Description: patch libqt5quick5-stacktrace.txt.gz Description: stacktrace
Bug#982591: grub-pc can't be updated non-interactively on debian/buster64
On 26/02/21 at 22:30 +0100, Thomas Goirand wrote: > This could well be in another bug report, if someone hasn't opened it yet. There's #982182, but it's a bit different from what you are saying here. Lucas
Bug#965984: CVE-2020-5238
Am Tue, Jul 21, 2020 at 09:30:01PM +0200 schrieb Moritz Muehlenhoff: > Source: cmark-gfm > Severity: important > Tags: security > > This was assigned CVE-2020-5238 > https://github.com/github/cmark-gfm/security/advisories/GHSA-7gc6-9qr5-hc85 > https://github.com/github/cmark-gfm/commit/85d895289c5ab67f988ca659493a64abb5fec7b4 Hi Keith, can you please fix this in time for the freeze? Cheers, Moritz
Bug#982591: grub-pc can't be updated non-interactively on debian/buster64
On 2/26/21 8:07 PM, Lucas Nussbaum wrote:
> On 14/02/21 at 08:48 +0100, Evgeni Golov wrote:
>> On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
>>> IMO we cannot know which device name is used by the users virtualisation
>>> environment.
>>> So, what is the be setting without knowing the device name?
>>>
>>> Or is /dev/sda used in most enviroments?
>>
>> For VirtualBox sda is a pretty safe bet, for libvirt it'd be either sda
>> or vda (and I think we could set both in debconf, as that's a
>> multiselect). AWS has another one, vxda I think? But this explicit bug
>> is about vagrant (so virtualbox and libvirt) only anyways.
>>
>> The only thing to consider with this approach: it should only be done
>> when preparing images, not installing "real" systems. So in the
>> cloud.d.o context that's safe, but probably not as a generic default in
>> FAI and other tools.
>
> Maybe a better approach (but still hackish) would be to set it at first
> boot, in a way similar to
> https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/files/etc/systemd/system/generate-sshd-host-keys.service/VAGRANT
>
> Running Something like:
> echo grub-pc grub-pc/install_devices multiselect $(awk '{ if ($2 == "/") {
> sub(/1$/, "", $1) ; print $1 } }' /proc/mounts) | debconf-set-selections
>
> Lucas
>
Hi,
I'm not a big fan of such boot-time hack.
Anyways, there's a big problem with the current way grub is attempting
to solve things. Using /dev/ as the device where grub should
install itself is wrong in the first place. These days, the kernel is
discovering block devices in an asynchronous way, and the order of the
block device can be different at each boot of a computer.
I have such type of hardware in production, and I really don't know how
to tell grub that no, I can't tell that grub should be installed in
/dev/sda and /dev/sdb, because these same small SSD I use for the system
can be /dev/sdc and /dev/sde if I reboot...
So grub should adopt a new strategy. Like for example, accepting device
UUIDs or block device serial numbers as identifiers.
This could well be in another bug report, if someone hasn't opened it yet.
Cheers,
Thomas Goirand (zigo)
Bug#983596: CVE-2020-13574 CVE-2020-13575 CVE-2020-13576 CVE-2020-13577 CVE-2020-13578
Package: gsoap Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team CVE-2020-13574 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1185 CVE-2020-13575 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1186 CVE-2020-13576 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1187 CVE-2020-13577 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1188 CVE-2020-13578 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1189 Cheers, Moritz
Bug#983069: lintian: please check that upstream signature is made with a modern hash (warn or error on MD5, SHA1, or RIPEMD160)
On Fri 2021-02-26 04:48:50 -0800, Felix Lechner wrote:
> That's a great idea! As a first step, I would like to show a
> classification tag with the hash algorithm. (It could be used for
> statistics.) Can 'gpgv' output such signature characteristics?
sure, we have several different tools (like pgpdump or "sq packet dump",
or python3-pgpy) that could provide this check.
If you're already using gpgv, you might just try verifying the signature
with "gpgv --weak-digest SHA1 --weak-digest RIPEMD160 …" -- that should
fail if the signature is weak, and produce some semi-readable warnings
for the user as well.
If you want to learn a lot more about the signature, you've got a lot of
options, but they're all pretty hairy.
gpgv produces data about the signature on its status FD:
$ gpg --dearmor < debian/upstream/signing-key.asc >
debian/upstream/signing-key.pgp
$ gpgv --status-fd 3 3>sig.status --keyring debian/upstream/signing-key.pgp
../xml2rfc_3.5.0.orig.tar.gz.asc ../xml2rfc_3.5.0.orig.tar.gz
gpgv: Signature made Wed 18 Nov 2020 05:20:56 AM EST
gpgv:using RSA key 4E9B574B8FBB171A
gpgv: Good signature from "Henrik Levkowetz "
$ awk < sig.status '/^\[GNUPG:\] VALIDSIG/ { print $10 }'
2
$
Yes, that "2" means "SHA1" (see
https://tools.ietf.org/html/rfc4880#section-9.4) (the "print $10" comes
from searching for VALIDSIG in /usr/share/doc/gnupg/DETAILS.gz)
So, that is rather opaque. Other techniques include sq, pgpdump, hot
(from hopenpgp-tools), and "gpg --list-packets"
$ sq packet dump ../xml2rfc_3.5.0.orig.tar.gz.asc
Signature Packet, old CTB, 540 bytes
Version: 4
Type: Binary
Pk algo: RSA (Encrypt or Sign)
Hash algo: SHA1
Hashed area:
Signature creation time: 2020-11-18 10:20:56 UTC
Unhashed area:
Issuer: 4E9B 574B 8FBB 171A
Digest prefix: D29F
Level: 0 (signature over data)
$ pgpdump ../xml2rfc_3.5.0.orig.tar.gz.asc
Old: Signature Packet(tag 2)(540 bytes)
Ver 4 - new
Sig type - Signature of a binary document(0x00).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Wed Nov 18 05:20:56 EST 2020
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x4E9B574B8FBB171A
Hash left 2 bytes - d2 9f
RSA m^d mod n(4094 bits) - ...
-> PKCS-1
$ gpg --list-packets < ../xml2rfc_3.5.0.orig.tar.gz.asc
# off=0 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 4E9B574B8FBB171A
version 4, created 1605694856, md5len 0, sigclass 0x00
digest algo 2, begin of digest d2 9f
hashed subpkt 2 len 4 (sig created 2020-11-18)
subpkt 16 len 8 (issuer key ID 4E9B574B8FBB171A)
data: [4094 bits]
$ hot dearmor < ../xml2rfc_3.5.0.orig.tar.gz.asc | hot dump
--output-format YAML
hot (hopenpgp-tools) 0.23.6
Copyright (C) 2012-2021 Clint Adams
hot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions.
hot (hopenpgp-tools) 0.23.6
Copyright (C) 2012-2021 Clint Adams
hot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions.
signature:
- tag: BinarySig
- tag: RSA
- tag: SHA1
- - _sspCriticality: false
_sspPayload:
sigCreationTime:
unThirtyTwoBitTimeStamp: 1605694856
- - _sspCriticality: false
_sspPayload:
issuer:
eoki: 4E9B574B8FBB171A
- 53919
- - unMPI: […]
$
Warning: GnuPG upstream has explicitly said for years that *no one*
should try to programmatically parse the output of --list-packets.
> The warning you asked for would then take place on top of that—perhaps
> with different severities depending how dated the algorithm is.
The most detailed set of categories i can imagine wanting want are (in
order of severity, worse ones first):
a) no signature is available / signature does not validate from
debian/upstream/signing-key.asc
b) only available signature depends on MD5
c) only available signature depends on SHA1 or RIPEMD160
d) valid signature with any other OpenPGP digest
If we want to collapse to fewer categories, my main priority is that (d)
stands apart from any of (a), (b), or (c).
In no case should lintian suggest that a signature that depends on a
weak digest (b) or (c) is *worse* than having no signature at all (a)
If you want to look at other cryptographic checks like this, maybe you
want to warn based on the contents of the OpenPGP certificates in
debian/upstream/signing-key.pgp.
Things that would be worth warning or errors on on:
- No signing-capable keys (primary key or subkeys)
- Weak primary key
Bug#983595: linux-image-5.10.0-3-amd64: [regression] Kernel panic on resume from sleep
Package: src:linux Version: 5.10.13-1 Severity: important Tags: upstream X-Debbugs-Cc: zbynek.mi...@gmail.com Dear Maintainer, I'm facing a kernel panic issue on resume from sleep in the recent Linux kernels (including 5.10.13-1). Here's what I can see on the serial console output: Resume phase: BUG: kernel NULL pointer dereference, address: 0198 [ 3046.188967] serial 00:05: activated [ 3047.527610] usb usb6: root hub lost power or was reset [ 3047.534619] #PF: supervisor read access in kernel mode [ 3047.538729] sd 0:0:0:0: [sda] Starting disk [ 3047.543458] #PF: error_code(0x) - not-present page [ 3047.543459] PGD 0 P4D 0 [ 3047.543462] Oops: [#1] SMP PTI [ 3047.543464] CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G OE 5.10.0-3-amd64 #1 Debian 5.10.13-1 [ 3047.543465] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77-D3H, BIOS F15 11/14/2013 [ 3047.543469] RIP: 0010:alx_start_xmit+0x34/0x650 [alx] [ 3047.543472] Code: 41 56 41 55 41 54 55 53 48 83 ec 20 0f b7 57 7c 8b 8e b0 0b 00 00 39 ca 72 06 89 d0 31 d2 f7 f1 89 d2 48 8b 84 df [ 3047.548638] sd 1:0:0:0: [sdb] Starting disk [ 3047.552800] RSP: 0018:b09240083d28 EFLAGS: 00010297 [ 3047.552801] RAX: RBX: a04d80ae7800 RCX: 0004 [ 3047.552801] RDX: RSI: a04d80afa000 RDI: a04e92e92a00 [ 3047.552803] RBP: 0042 R08: 0100 R09: a04ea3146700 [ 3047.638122] R10: 0014 R11: R12: a04e92e92100 [ 3047.644348] [ cut here ] [ 3047.645256] R13: 0001 R14: a04e92e92a00 R15: a04e92e92a00 [ 3047.645258] FS: () GS:a0508f60() knlGS: [ 3047.649878] i915 :00:02.0: vblank wait timed out on crtc 0 [ 3047.657043] CS: 0010 DS: ES: CR0: 80050033 [ 3047.657044] CR2: 0198 CR3: 4460a001 CR4: 001706f0 [ 3047.657044] Call Trace: [ 3047.657062] ? dev_queue_xmit_nit+0x268/0x2a0 [ 3047.665203] WARNING: CPU: 3 PID: 3019 at drivers/gpu/drm/drm_vblank.c:1253 drm_wait_one_vblank+0x1f0/0x210 [drm] [ 3047.670988] ? skb_checksum_help+0xa6/0x120 [ 3047.670990] dev_hard_start_xmit+0xc7/0x1e0 [ 3047.671006] sch_direct_xmit+0x10f/0x310 [ 3047.676769] Modules linked in: [ 3047.683910] __qdisc_run+0x149/0x550 [ 3047.683925] ? __switch_to_asm+0x42/0x70 [ 3047.686380] vboxnetadp(OE) [ 3047.690765] net_tx_action+0x10d/0x230 [ 3047.690767] __do_softirq+0xc5/0x275 [ 3047.700947] vboxnetflt(OE) [ 3047.705145] run_ksoftirqd+0x26/0x40 [ 3047.705160] smpboot_thread_fn+0xc5/0x160 [ 3047.709346] cpufreq_userspace [ 3047.713289] ? smpboot_register_percpu_thread+0xf0/0xf0 [ 3047.713291] kthread+0x11b/0x140 [ 3047.716369] cpufreq_powersave [ 3047.719955] ? __kthread_bind_mask+0x60/0x60 [ 3047.723870] cpufreq_ondemand [ 3047.726679] ret_from_fork+0x22/0x30 [ 3047.726680] Modules linked in: [ 3047.730441] vboxdrv(OE) [ 3047.734028] vboxnetadp(OE) vboxnetflt(OE) [ 3047.736835] cpufreq_conservative [ 3047.740425] cpufreq_userspace cpufreq_powersave cpufreq_ondemand vboxdrv(OE) [ 3047.75] intel_rapl_msr [ 3047.747512] cpufreq_conservative intel_rapl_msr [ 3047.752732] intel_rapl_common [ 3047.755972] intel_rapl_common nft_counter [ 3047.759023] nft_counter [ 3047.763303] x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi [ 3047.766293] x86_pkg_temp_thermal [ 3047.769874] kvm_intel xt_tcpudp snd_hda_codec_via xt_multiport snd_hda_codec_generic ledtrig_audio kvm [ 3047.772960] intel_powerclamp [ 3047.775505] xt_state [ 3047.779609] snd_hda_codec_hdmi [ 3047.782932] xt_conntrack irqbypass nf_conntrack snd_hda_intel [ 3047.790102] kvm_intel [ 3047.792910] nf_defrag_ipv6 nf_defrag_ipv4 snd_intel_dspcfg soundwire_intel [ 3047.797554] xt_tcpudp [ 3047.800622] soundwire_generic_allocation nft_compat ghash_clmulni_intel nf_tables [ 3047.804730] snd_hda_codec_via [ 3047.807277] snd_soc_core [ 3047.813727] xt_multiport [ 3047.817063] nfnetlink aesni_intel snd_compress libaes [ 3047.826467] snd_hda_codec_generic [ 3047.829465] soundwire_cadence crypto_simd snd_hda_codec cryptd [ 3047.831752] ledtrig_audio kvm [ 3047.834898] glue_helper snd_hda_core snd_hwdep rapl [ 3047.840784] xt_state [ 3047.843141] i915 [ 3047.850117] xt_conntrack [ 3047.852500] soundwire_bus intel_cstate snd_pcm intel_uncore [ 3047.860074] irqbypass [ 3047.863133] snd_timer evdev drm_kms_helper pcspkr [ 3047.865771] nf_conntrack [ 3047.868403] serio_raw mei_me at24 iTCO_wdt [ 3047.873551] snd_hda_intel [ 3047.876958] snd intel_pmc_bxt cec iTCO_vendor_support [ 3047.880827] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 3047.882585] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 3047.882613] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3047.882912] nf_defrag_ipv6 [ 3047.885979] soundcore watchdog i2c_algo_bit mei [ 3047.890954] nf_defr
Bug#982356: (no subject)
On 25/02/21 at 19:06 +0100, Emmanuel Kasper wrote: > I think this bug is due to the switch to fai for testing/bullseye. > IIRC with fai, we run a dhcp client for each interface, which would > cause the double IP adresses you see (one set up by DHCP, one set up by > Vagrant directly over ssh when booting the VM) Right. But the solution is not obvious. If we want to do DHCP only on the first interface, we need to hardcode this in the image. But how can we know the name of the interface? Apparently it's enp0s3 with virtualbox, and something different with libvirt (because my test fails). We could go back to traditional names and do DHCP on eth0... Lucas
Bug#983594: [INTL:pt] Updated portuguese translation for debconf messages
Package: pam Version: 1.4.0 Severity: wishlist Tags: l10n patch Updated Portuguese translation for pam's debconf messages. Translator: Pedro Ribeiro Feel free to use it. For translation updates please contact 'Last Translator' or the Portuguese Translation Team . # translation of pam debconf to Portuguese # Copyright (C) 2007 Américo Monteiro # This file is distributed under the same license as the pam package. # # Américo Monteiro , 2007, 2009. # Pedro Ribeiro , 2011, 2021. # msgid "" msgstr "" "Project-Id-Version: pam 1.4.0-6\n" "Report-Msgid-Bugs-To: p...@packages.debian.org\n" "POT-Creation-Date: 2021-02-26 10:32-0500\n" "PO-Revision-Date: 2021-02-26 20:46+\n" "Last-Translator: Pedro Ribeiro \n" "Language-Team: Portuguese \n" "Language: pt\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Lokalize 1.0\n" #. Type: string #. Description #: ../libpam0g.templates:1001 msgid "Services to restart for PAM library upgrade:" msgstr "Serviços a reiniciar para a actualização da biblioteca PAM:" #. Type: string #. Description #: ../libpam0g.templates:1001 msgid "" "Most services that use PAM need to be restarted to use modules built for " "this new version of libpam. Please review the following space-separated " "list of services to be restarted now, and correct it if needed." msgstr "" "A maioria dos serviços que usam PAM necessitam ser reiniciados para usarem " "os módulos construídos para esta nova versão do libpam. Por favor, reveja a " "seguinte lista de serviços, separados por espaços, a serem reiniciados agora " "e corrija-a se for necessário." #. Type: error #. Description #: ../libpam0g.templates:2001 msgid "Display manager must be restarted manually" msgstr "O gestor de sessão gráfica deverá ser reiniciado manualmente" #. Type: error #. Description #: ../libpam0g.templates:2001 msgid "" "The wdm and xdm display managers require a restart for the new version of " "libpam, but there are X login sessions active on your system that would be " "terminated by this restart. You will therefore need to restart these " "services by hand before further X logins will be possible." msgstr "" "Os gestores de sessão gráfica wdm e xdm necessitam de reiniciar para a nova " "versão de libpam, mas existem sessões de login X activas no seu sistema que " "seriam terminadas por esta operação. Deverá reiniciar estes serviços " "manualmente para permitir novos logins X." #. Type: error #. Description #: ../libpam0g.templates:3001 msgid "Failure restarting some services for PAM upgrade" msgstr "Falha ao reiniciar alguns serviços para a actualização PAM" #. Type: error #. Description #: ../libpam0g.templates:3001 msgid "" "The following services could not be restarted for the PAM library upgrade:" msgstr "" "Os seguintes serviços não puderam ser reiniciados para a actualização da " "biblioteca PAM:" #. Type: error #. Description #: ../libpam0g.templates:3001 msgid "" "You will need to start these manually by running '/etc/init.d/ " "start'." msgstr "" "Você precisa iniciar manualmente estes serviços fazendo '/etc/init.d/" " start'." #. Type: boolean #. Description #: ../libpam0g.templates:4001 msgid "Restart services during package upgrades without asking?" msgstr "Reiniciar os serviços durante actualizações do pacote sem perguntar?" #. Type: boolean #. Description #: ../libpam0g.templates:4001 msgid "" "There are services installed on your system which need to be restarted when " "certain libraries, such as libpam, libc, and libssl, are upgraded. Since " "these restarts may cause interruptions of service for the system, you will " "normally be prompted on each upgrade for the list of services you wish to " "restart. You can choose this option to avoid being prompted; instead, all " "necessary restarts will be done for you automatically so you can avoid being " "asked questions on each library upgrade." msgstr "" "Há serviços instalados no seu sistema que necessitam de ser reiniciados " "quando certas bibliotecas, tais como libpam, libc e libssl, são " "actualizadas. Uma vez que estes reinícios podem causar interrupções de " "serviço do sistema, será normalmente questionado em cada actualização sobre " "a lista de serviços que deseja reiniciar. Pode escolher esta opção para " "evitar as questões; neste caso, todos os reinicios serão efectuados " "automaticamente e não será questionado em cada actualização das bibliotecas." #. Type: title #. Description #: ../libpam-runtime.templates:1001 msgid "PAM configuration" msgstr "Configuração PAM" #. Type: multiselect #. Description #: ../libpam-runtime.templates:2001 msgid "PAM profiles to enable:" msgstr "Perfis PAM para activar:" #. Type: multiselect #. Description #: ../libpam-runtime.templates:2001 msgid "" "Pluggable Authentication Modules (PAM) determine how authentication, " "authorization, and password changing are handled on the system, as well as " "allowing configuration of additional a
Bug#983593: connman: Missing "conflict" dependency information?
Package: connman Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** I do apologize if this is routed poorly, but I figure I have to start somewhere. * What led up to the situation? I've had an unstable/sid server system working well for decades - its configuration has overall been pretty stable. On 2021-02-23, the unattended-upgrades system installed connman (among others) on my system. connman was never on my system before. I do not know how/why unattended-upgrades decided to install the package, and I don't even know who/where to file that bug. (Suggestions welcome... but not your problem) But it did expose a problem with the connman package: It doesn't appear to conflict with other interface configuration systems. Having multiple things changing the network configuration was deeply confusing and hard to debug. My system would not boot, and there were many network configuration errors. The package appears to behave quite poorly with ifupdown: * Classic /etc/network/interfaces.d/ network configurations were being configured twice: * Ifupdown was told to give an interface a static IPv4 address (as * expected) * wide-dhcpv6-client was able to initially configure IPv6 for the address, but then couldn't upon fixing the static ipv4 address. * For whatever reason connman was trying a DHCP, not getting it, and re-assigned the interface to the 169.254 automatic private ip addresses. * Because of the dual-configuration "race", the system was rendered unbootable and unusable, as the two configuration systems appeared to be "fighting" each other. * I couldn't even login locally as root * often, the system never even reached a login prompt * It wasn't easy to diagnose the source of why the system wasn't booting, but I eventually found it. * What exactly did you do (or not do) that was effective (or ineffective)? * I removed connman, clearing the conflict, so there was only one thing trying to configure my network interfaces. * What was the outcome of this action? * After removing connman, the system started behaving normally/correctly. * What outcome did you expect instead? * Ideally, unattended upgrades should not have installed connman. I don't have the slightest idea who to ask about that situation, though. If you could point me in the right direction, I'd be grateful. * I imagine a "conflict" in the connman package for other incompatible interface configuration systems would be good in general. Having multiple interface configuration systems modifying the same interfaces seems like a guaranteed race condition. *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 connman depends on: ii dbus 1.12.20-2 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-9 ii libdbus-1-3 1.12.20-2 ii libglib2.0-0 2.66.7-1 ii libgnutls30 3.7.0-7 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 pn ofono ii wpasupplicant 2:2.9.0-20 Versions of packages connman suggests: pn connman-vpn
Bug#983592: netbase: add port for network time security key exchange
Package: netbase Version: 6.2 The port for network time security key exchange should be added to /etc/services. This is port 4460 as specified in RFC8915 and is used by debian packages ntpsec and chrony. Also the wording at the beginning of /etc/services, lines 4 and 5, implies that TCP is always used and UDP is optional. Replacing "even if the protocol doesn't support UDP operations" with "even if only one of the protocols is used" will better convey the message. Thanks. Jeff
Bug#983591: iproute2: running 'ip -6 -r route' results in printing an unitialized buffer for the hostname on 'dev' routes
Package: iproute2
Version: 5.10.0-4
Severity: normal
Tags: ipv6
Dear Maintainer,
* What led up to the situation?
Using ip -6 -r route shows (on 10.8) either an information leak:
$ ip -6 -r r
+U dev lo proto kernel metric 256 pref medium
or (on testing) empty output:
$ ip -6 -r r
dev lo proto kernel metric 256 pref medium
for the resolved hostname.
* What outcome did you expect instead?
Printing of the resolved name, e.g. 'localhost' for dev lo.
Reading the source and a bit of printf debugging i can see it's
in lib/utils.c, format_host_r:
1113z20n
1113const char *format_host_r(int af, int len, const void *addr,
1114char *buf, int buflen)
1115{
1116#ifdef RESOLVE_HOSTNAMES
1117if (resolve_hosts) {
1118const char *n;
1119
1120puts("XXX: here");
1121len = len <= 0 ? af_byte_len(af) : len;
1122
1123if (len > 0 &&
1124(n = resolve_address(addr, len, af)) !=
NULL)
1125{
1126printf("n is '%s'\n", n);
1127strncpy(buf, n, buflen);
1128return n;
1129}
1130}
1131#endif
results in:
./ip/ip -6 -r r
XXX: here
n is 'localhost'
localhost dev lo proto kernel metric 256 pref medium
Something better then this awful hack should be implemented i guess.
Kind regards,
Axel Scheepers
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages iproute2 depends on:
ii debconf [debconf-2.0] 1.5.74
ii libbpf01:0.3-2
ii libbsd00.11.3-1
ii libc6 2.31-9
ii libcap21:2.44-1
ii libcap2-bin1:2.44-1
ii libdb5.3 5.3.28+dfsg1-0.8
ii libelf10.183-1
ii libmnl01.0.4-3
ii libselinux13.1-3
ii libxtables12 1.8.7-1
Versions of packages iproute2 recommends:
pn libatm1
Versions of packages iproute2 suggests:
pn iproute2-doc
-- debconf information:
iproute2/setcaps: false
Bug#983590: freecad: autopkgtest regression
Source: freecad Version: 0.19+dfsg1-1 Severity: serious https://ci.debian.net/data/autopkgtest/testing/amd64/f/freecad/10706923/log.gz ... ** run FEM TestObjectOpen tests load old document objects #0 /lib/x86_64-linux-gnu/libc.so.6(+0x3bd60) [0x7fa5d2e14d60] #1 0x7fa5c321a0c2 in Fem::Constraint::getDirection(App::PropertyLinkSub const&) from /usr/lib/freecad-python3/lib/Fem.so+0x42 #2 0x7fa5c3223973 in Fem::ConstraintFluidBoundary::onChanged(App::Property const*) from /usr/lib/freecad-python3/lib/Fem.so+0x223 #3 0x7fa5d3c0c965 in App::Property::hasSetValue() from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x75 #4 0x7fa5d3c3eca8 in App::PropertyLinkSub::Restore(Base::XMLReader&) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x688 #5 0x7fa5d3c0f45e in App::PropertyContainer::Restore(Base::XMLReader&) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0xeee #6 0x7fa5d3ad9718 in App::Document::readObjects(Base::XMLReader&) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x718 #7 0x7fa5d3ae698e in App::Document::Restore(Base::XMLReader&) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x21e #8 0x7fa5d3ae8563 in App::Document::restore(char const*, bool, std::set, std::allocator >, std::less, std::allocator > >, std::allocator, std::allocator > > > const&) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x383 #9 0x7fa5d3c9482b in App::Application::openDocumentPrivate(char const*, char const*, char const*, bool, bool, std::set, std::allocator >, std::less, std::allocator > >, std::allocator, std::allocator > > > const&) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x6fb #10 0x7fa5d3c9537e in App::Application::openDocuments(std::vector, std::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > const*, std::vector, std::allocator >, std::allocator, std::allocator > > > const*, std::vector, std::allocator >, std::allocator, std::allocator > > >*, bool) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x65e #11 0x7fa5d3c964ef in App::Application::openDocument(char const*, bool) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0x11f #12 0x7fa5d3ca94c3 in App::Application::sOpenDocument(_object*, _object*, _object*) from /usr/lib/freecad-python3/lib/libFreeCADApp.so+0xe3 #13 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x10cc93) [0x7fa5d3291c93] #14 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_MakeTpCall+0x90) [0x7fa5d324ba50] #15 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x8632) [0x7fa5d31fd2f2] #16 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x6f033) [0x7fa5d31f4033] #17 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0xc9728) [0x7fa5d324e728] #18 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x6456) [0x7fa5d31fb116] #19 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x6f033) [0x7fa5d31f4033] #20 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x77f7) [0x7fa5d31fc4b7] #21 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x1a4ddc) [0x7fa5d3329ddc] #22 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyFunction_Vectorcall+0x9d) [0x7fa5d3246c7d] #23 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0xc96a4) [0x7fa5d324e6a4] #24 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x4a59) [0x7fa5d31f9719] #25 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x1a4ddc) [0x7fa5d3329ddc] #26 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyFunction_Vectorcall+0x9d) [0x7fa5d3246c7d] #27 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_FastCallDictTstate+0x53) [0x7fa5d324df23] #28 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_Call_Prepend+0xe0) [0x7fa5d324e140] #29 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x12f609) [0x7fa5d32b4609] #30 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_MakeTpCall+0x90) [0x7fa5d324ba50] #31 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x7248) [0x7fa5d31fbf08] #32 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x1a4ddc) [0x7fa5d3329ddc] #33 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyFunction_Vectorcall+0x9d) [0x7fa5d3246c7d] #34 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0xc96a4) [0x7fa5d324e6a4] #35 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x4a59) [0x7fa5d31f9719] #36 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x1a4ddc) [0x7fa5d3329ddc] #37 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyFunction_Vectorcall+0x9d) [0x7fa5d3246c7d] #38 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_FastCallDictTstate+0x53) [0x7fa5d324df23] #39 /lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_Call_Prepend+0xe0) [0x7fa5d324e140] #40 /lib/x86_64-linux-gnu/
Bug#983589: w3m: Cannot verify certificates any more
Package: w3m Version: 0.5.3+git20210102-3 Severity: important Hello, Since version 0.5.3+git20210102-3 of w3m (downgrading to -2 fixes it), all https website give me unable to get local issuer certificate: accept? (y/n) and choosing y gives Accept unsecure SSL session: unverified: unable to get local issuer certificate while choosing n quits. This makes w3m vulnerable to spoofing. I almost thought about making this a grave severity, since I believe we definitely don't want to keep this bug in Bullseye. Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.11.0 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages w3m depends on: ii libc6 2.31-9 ii libgc1 1:8.0.4-3 ii libgpm21.20.7-8 ii libssl1.1 1.1.1j-1 ii libtinfo6 6.2+20201114-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages w3m recommends: ii ca-certificates 20210119 Versions of packages w3m suggests: pn cmigemo ii curl7.74.0-1.1 ii dict1.13.0+dfsg-1 pn dict-wn pn dictd pn libsixel-bin ii man-db 2.9.4-1 ii mime-support3.66 ii mpv 0.32.0-2+b1 ii sensible-utils 0.0.14 pn w3m-el ii w3m-img 0.5.3+git20210102-2 ii wget1.21-1+b1 ii xdg-utils 1.1.3-4 ii xsel1.2.0+git9bfc13d.20180109-3 -- no debconf information -- Samuel Actually, typing random strings in the Finder does the equivalent of filename completion. (Discussion in comp.os.linux.misc on the intuitiveness of commands: file completion vs. the Mac Finder.)
Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?
Hello again,
The latest Microchip Packs at
http://packs.download.atmel.com/ have the relevant files for
now: perhaps they updated them in stages?
I have taken some time to read more of the docs (
https://gcc.gnu.org/wiki/avr-gcc#Using_avr-gcc ) and it seems that there is
a cleaner way of using the pack files than copying them piecewise into the
/usr/... directories.
For GCC support for the new 0-series and 1-series parts I do this in my
source code directory:
-
$ mkdir gcc
$ mkdir gcc/device-specs
$ mkdir gcc/avrxmega3
$ mkdir gcc/avrxmega3/short-calls
$ cp ../microchip-packs/tmp/gcc/dev/attiny?*{0,1}[2467]/avrxmega3/*.{o,a}
gcc/avrxmega3/
$ cp
../microchip-packs/tmp/gcc/dev/attiny?*{0,1}[2467]/avrxmega3/short-calls/*.{o,a}
gcc/avrxmega3/short-calls/
$ cp ../microchip-packs/tmp/gcc/dev/attiny?*{0,1}[2467]/device-specs/*
gcc/device-specs/
-
Then I add "-B gcc/" to the gcc command line (in CFLAGS in my Makefile) so
that it can find the new spec files.
...and for avr-libc support I do this:
-
$ mkdir -p gcc/include/avr/
$ cp ../microchip-packs/tmp/include/avr/iotn?*{0,1}[2467].h
gcc/include/avr/
-
Note /usr/lib/avr/include/avr/io.h does not need to be modified as the
system one has a clause that can construct the include file name if there
is no dedicated mapping.
However, this depends on support from the spec file. For example, the stock
spec file for atmega328pb is different from the one in the latest Microchip
pack file and does not specify __AVR_DEV_LIB_NAME__. Unpacking the new spec
file as described above then allows the stock avr/io.h to automatically
include the correct part-specific file. (However, even tho' the compiler
has a spec file for the atmega328pb, avr-libc support is missing, so you
still have to get that and the crt and lib files from the Microchip pack
anyway.)
This seems like a clean way for users to provide the Microchip pack files
to the compiler without messing around with the package manager maintained
directories so I'm posting here in case anyone else runs into this problem
and finds it useful.
Best wishes,
@ndy
--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
Bug#981488: Please add a symbols file for libmarisa0
After a fourth upload to experimental, it built on all the official
archs and some of the unofficial ones. (As an extra bonus I made it
build also on x32.)
However, to fix the symbols file properly I need build logs including
the dh_makeshlibs output from *all* archs. Still waiting for
kfreebsd-{amd64,i386} (fail due to perl) and alpha. I have fixed it on
the Ubuntu side, and since a symbols file is not a requirement in
Debian, my conclusion is to keep waiting for now instead of uploading a
half-finished fix to unstable.
--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj
OpenPGP_signature
Description: OpenPGP digital signature
Bug#766716: New upstream release
Hi Mark, Thanks for the report, I adopt cuyo package and now is up-to-date with upstream. Thanks Cheers. Emmanuel
Bug#981003: Kernel paniced with null pointer dereference on Panasonic CF-SV9 notebook machine
Hi, On Fri, Feb 26, 2021 at 11:01:50PM +0900, Kubo Hiroshi wrote: > Hi Salvatore, > > > Would it be possible for you to test the two patches submitted as > > https://lore.kernel.org/linux-acpi/20210208120104.204761-1-marcin.slus...@gmail.com/ > > and > > https://lore.kernel.org/linux-acpi/20210208120104.204761-2-marcin.slus...@gmail.com/ > > ? > > Yes, the first patch worked fine for my notebook machine. > > I applied the fistpatch to the linux-image-5.10.13-1 source, built a > linux-image-5.10.0-3-amd64-unsigned package, > installed the package to my machine using dpkg, and the machine > booted without kernel panic. > > It seems that the second patch is just for comment fix, right? I did > not applied the second patch. Yes correct. Thanks for confirming the fix. I just have applied it so that it can be inclueded in the next upload. Regards, Salvatore
Bug#982591: grub-pc can't be updated non-interactively on debian/buster64
On 14/02/21 at 08:48 +0100, Evgeni Golov wrote:
> On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
> > IMO we cannot know which device name is used by the users virtualisation
> > environment.
> > So, what is the be setting without knowing the device name?
> >
> > Or is /dev/sda used in most enviroments?
>
> For VirtualBox sda is a pretty safe bet, for libvirt it'd be either sda
> or vda (and I think we could set both in debconf, as that's a
> multiselect). AWS has another one, vxda I think? But this explicit bug
> is about vagrant (so virtualbox and libvirt) only anyways.
>
> The only thing to consider with this approach: it should only be done
> when preparing images, not installing "real" systems. So in the
> cloud.d.o context that's safe, but probably not as a generic default in
> FAI and other tools.
Maybe a better approach (but still hackish) would be to set it at first
boot, in a way similar to
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/blob/master/config_space/files/etc/systemd/system/generate-sshd-host-keys.service/VAGRANT
Running Something like:
echo grub-pc grub-pc/install_devices multiselect $(awk '{ if ($2 == "/") {
sub(/1$/, "", $1) ; print $1 } }' /proc/mounts) | debconf-set-selections
Lucas
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Hi Matthias, On 26-02-2021 07:40, Matthias Klose wrote: > I'm planning to upload the upload as done to experimental, plus the final (no > changes) 3.9.2 release. Granted, refreshing the patches is not not > necessary, > but that's what is now tested in experimental. Ack. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983588: xmlgraphics-commons: reproducible builds: Set timezone to UTC when SOURCE_DATE_EPOCH is set
Package: xmlgraphics-commons
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Several packages use fop (which uses xmlgraphics-commons) to generate
PDF files in Debian packages, but the resulting PDF files have embedding
timestamps. This was partially fixed in fop:
https://bugs.debian.org/978499
Unfortunately, in some cases the timezone information is still embedded
due to how xmlgraphics-commons embeds the date and timezone:
For example, in xorg-docs:
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/xorg-docs.html
/usr/share/doc/xorg-docs/License.pdf.gz
dc:date>2020-12-20T04:18:36-12:00
vs.
dc:date>2020-12-21T06:18:36+14:00
The attached patch fixes this by adding setting the timezone to UTC when
the SOURCE_DATE_EPOCH environment variable is defined. This patch is
just a rough draft; would appreciate improvements to it from someone who
knows their way around java better!
This seems to fix the embedded timestamp/timezone issues in several of
the packages listed in:
https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_pdf_generated_by_apache_fop_issue.html
Thanks for maintaining xmlgraphics-commons!
live well,
vagrant
From 2146f4a44fbee1e3aef12e56ae3d904e793090cd Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Fri, 26 Feb 2021 19:10:10 +
Subject: [PATCH] XMPSchemaAdapter.java: Use UTC timezone when
SOURCE_DATE_EPOCH is set.
SOURCE_DATE_EPOCH specifies the timestamp, but needs to be rendered in
UTC timezone to ensure reproducible builds.
https://reproducible-builds.org/docs/source-date-epoch/
This is a follow-up to https://bugs.debian.org/978499 in apache fop,
as there is no way for fop itself to pass the timezone information for
some values.
---
.../java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java| 5 +
1 file changed, 5 insertions(+)
diff --git a/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java b/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java
index 9a41eba..19811a8 100644
--- a/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java
+++ b/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java
@@ -157,6 +157,11 @@ public class XMPSchemaAdapter {
* @return the formatted date
*/
public static String formatISO8601Date(Date dt) {
+// https://reproducible-builds.org/docs/source-date-epoch/
+String source_date_epoch = System.getenv("SOURCE_DATE_EPOCH");
+if (source_date_epoch != null) {
+return formatISO8601Date(dt, TimeZone.getTimeZone("Etc/UTC"));
+}
return formatISO8601Date(dt, TimeZone.getDefault());
}
--
2.20.1
signature.asc
Description: PGP signature
Bug#983586: linux-image-5.10.0-3-amd64: Please configure kernel with CONFIG_AMD_MEM_ENCRYPT=y
Package: src:linux Version: 5.10.13-1 Dear Maintainer, please consider to set the Linux kernel option "CONFIG_AMD_MEM_ENCRYPT=y". Without that option it is not possible to enable the memory encryption for AMD Secure Memory Encryption (SME). Thank you very much. With kind regards
Bug#983554: inkscape: Measurement path effect scale inaccurate after changing display units in document properties
The linked issue is similar. From what I found from my search, this issue is related to: https://gitlab.com/inkscape/inkscape/-/issues/1746 and the issue you linked above. Both of which can also be replicated with a new installation of inkscape from the debian repos. On Fri, Feb 26, 2021 at 8:12 AM Mattia Rizzolo wrote: > > Control: tag -1 upstream > > Hi Will, > > On Thu, Feb 25, 2021 at 10:54:34PM -0800, will wrote: > > Changing the Display Units to anything other than the default mm throws off > > the > > measurement path effect. > > > > With the default display unit (mm), the measurements are displayed > > correctly. > > The file with display unit changed to inches shows an incorrect measurement. > > Other units are also affected, for example: cm is off by a factor of x10. > > Could I ask you to please read this other bugs report and check whether > that matches what you are reporting? > https://gitlab.com/inkscape/inkscape/-/issues/1675 > > Thank you in advance! > > -- > 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 `-
Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup
Dear Maintainer,
with the original PPD and input files from Ian I could
reproduce the issue and with the help of rr-debugger
this is what I assume what happens:
- The buffer m_pPrinterBuffer is allocated here with
the current sizes inside cups_header. [1]
- The first page got processed and for the second page
a new cups_header record gets copied. [2]
Unfortunately now the header contains higher sizes,
but the buffer is not grown accordingly.
- Now to this buffer is written by a read function, and beyond
where the management information of malloc got overwritten for
some other random memory. [3]
- The defect in the management information of malloc is detected
and the process is aborted. [4]
The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side effects on replacing this buffer?
Kind regards,
Bernhard
[1]
500 m_pPrinterBuffer = new BYTE[cups_header->cupsWidth * 4 + 32];
(rr) bt
#0 HPCupsFilter::startPage (this=0x556369c551c0 ,
cups_header=0x7ffe94b8e030) at prnt/hpcups/HPCupsFilter.cpp:500
#1 0x556369bf4793 in HPCupsFilter::processRasterData
(this=this@entry=0x556369c551c0 , cups_raster=,
cups_raster@entry=0x55636ac39d00) at prnt/hpcups/HPCupsFilter.cpp:668
#2 0x556369bf4de9 in HPCupsFilter::StartPrintJob (this=0x556369c551c0
, argc=, argv=0x7ffe94b8ecf8) at
prnt/hpcups/HPCupsFilter.cpp:597
...
(rr) when
Current event: 898
[2]
#0 0x7f504dcaa190 in memcpy (__len=1796, __src=0x564615c8cd1c,
__dest=0x7ffc2a13f080) at
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#1 cupsRasterReadHeader2 (r=0x564615c8cd00, h=h@entry=0x7ffc2a13f080) at
raster-stubs.c:209
#2 0x5646141d356d in HPCupsFilter::processRasterData
(this=this@entry=0x5646142341c0 , cups_raster=,
cups_raster@entry=0x564615c8cd00) at prnt/hpcups/HPCupsFilter.cpp:661
#3 0x5646141d3de9 in HPCupsFilter::StartPrintJob (this=0x5646142341c0
, argc=, argv=0x7ffc2a13fd48) at
prnt/hpcups/HPCupsFilter.cpp:597
#4 0x7f504d83fd0a in __libc_start_main (main=0x5646141d0e10 , argc=6,
argv=0x7ffc2a13fd48, init=, fini=, rtld_fini=, stack_end=0x7ffc2a13fd38) at ../csu/libc-start.c:308
#5 0x5646141d0efa in _start ()
(rr) when
Current event: 1230
[3]
...
#9 0x7f504dcaa00d in read (__nbytes=19220, __buf=0x564615cb1ca0,
__fd=0) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#10 cups_read_fd (ctx=, buf=0x564615cb1ca0 '\377' ..., bytes=19220) at raster-stubs.c:323
#11 0x7f504dca9340 in cups_raster_io (bytes=19220, buf=0x564615cb1ca0 '\377'
..., r=0x564615c8cd00) at raster-stream.c:1372
#12 _cupsRasterReadPixels (r=0x564615c8cd00, p=0x564615cb1ca0 '\377' ..., len=19220) at raster-stream.c:782
#13 0x7f504dcaa1e5 in cupsRasterReadPixels (r=, p=, len=) at raster-stubs.c:228
#14 0x5646141d36e8 in HPCupsFilter::processRasterData
(this=this@entry=0x5646142341c0 , cups_raster=,
cups_raster@entry=0x564615c8cd00) at prnt/hpcups/HPCupsFilter.cpp:758
#15 0x5646141d3de9 in HPCupsFilter::StartPrintJob (this=0x5646142341c0
, argc=, argv=0x7ffc2a13fd48) at
prnt/hpcups/HPCupsFilter.cpp:597
...
[4]
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7f504d83e537 in __GI_abort () at abort.c:79
#2 0x7f504d897768 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f504d9a5e31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3 0x7f504d89ea5a in malloc_printerr (str=str@entry=0x7f504d9a8258 "free():
invalid next size (normal)") at malloc.c:5347
#4 0x7f504d89ff2c in _int_free (av=0x7f504d9d7b80 ,
p=0x564615cb1c90, have_lock=) at malloc.c:4322
#5 0x5646141d15c6 in HPCupsFilter::cleanup (this=this@entry=0x5646142341c0
) at prnt/hpcups/HPCupsFilter.cpp:227
#6 0x5646141d3e1b in HPCupsFilter::closeFilter (this=0x5646142341c0
) at prnt/hpcups/HPCupsFilter.cpp:221
#7 HPCupsFilter::StartPrintJob (this=0x5646142341c0 , argc=, argv=0x7ffc2a13fd48) at prnt/hpcups/HPCupsFilter.cpp:617
...
Description: Grow m_pPrinterBuffer if needed on each page
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/974828
Bug-Ubuntu: https://launchpad.net/bugs/1904318
Last-Update: 2021-02-26
Index: hplip-3.20.11+dfsg0/prnt/hpcups/HPCupsFilter.cpp
===
--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/HPCupsFilter.cpp
+++ hplip-3.20.11+dfsg0/prnt/hpcups/HPCupsFilter.cpp
@@ -199,7 +199,7 @@ void HPCupsFilter::WriteKBMPRaster (FILE
fwrite (black_raster, 1, adj_k_width, fp);
}
-HPCupsFilter::HPCupsFilter() : m_pPrinterBuffer(NULL)
+HPCupsFilter::HPCupsFilter() : m_pPrinterBuffer(NULL), m_PrinterBufferSize(0)
{
setbuf (stderr, NULL);
@@ -226,6 +226,7 @@ void HPCupsFilter::cleanup()
if (m_pPrinterBuff
Bug#983584: paraview: reproducible builds: Embeds running kernel in header files and binaries
Source: paraview
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The running kernel version is embedded in various files and binaries:
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/diffoscope-results/paraview.html
/usr/include/paraview-5.9/catalyst/conduit_config.h
#define·CONDUIT_SYSTEM_TYPE·"Linux-4.19.0-14-686-pae"
vs.
#define·CONDUIT_SYSTEM_TYPE·"Linux-4.19.0-14-amd64"
That attached two patches fix this by using CMAKE_SYSTEM_NAME instead of
CMAKE_SYSTEM. It builds fine, though someone familiar with the code
should verify that it actually works correctly before applying the
patches.
This appears to be fixed in vtk7 in https://bugs.debian.org/977530, but
since paraview uses an embedded code copy, needs to be fixed here too.
Thanks for maintaining paraview!
live well,
vagrant
From 8fb482790cdbfc5dd8bc76b2c8b75de2c0614326 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Fri, 26 Feb 2021 08:19:28 +
Subject: [PATCH 1/4] conduit_config.h.in: Do not embed the kernel version of
the build machine.
Use CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM to avoid embedding the
kernel version of the build machine.
https://tests.reproducible-builds.org/debian/issues/unstable/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
.../catalyst/thirdparty/conduit/conduit/conduit_config.h.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ThirdParty/catalyst/vtkcatalyst/catalyst/thirdparty/conduit/conduit/conduit_config.h.in b/ThirdParty/catalyst/vtkcatalyst/catalyst/thirdparty/conduit/conduit/conduit_config.h.in
index 95fb51cd..8697730f 100644
--- a/ThirdParty/catalyst/vtkcatalyst/catalyst/thirdparty/conduit/conduit/conduit_config.h.in
+++ b/ThirdParty/catalyst/vtkcatalyst/catalyst/thirdparty/conduit/conduit/conduit_config.h.in
@@ -71,7 +71,7 @@
#cmakedefine CONDUIT_GIT_SHA1 "${CONDUIT_GIT_SHA1}"
-#define CONDUIT_SYSTEM_TYPE "@CMAKE_SYSTEM@"
+#define CONDUIT_SYSTEM_TYPE "@CMAKE_SYSTEM_NAME@"
#define CONDUIT_CPP_COMPILER "@CMAKE_CXX_COMPILER@"
--
2.20.1
From ddef60f591e554379f084476ea9ba70369b4555b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Fri, 26 Feb 2021 08:22:03 +
Subject: [PATCH 2/4] XdmfConfig.h.in: Do not embed the kernel version of the
build machine.
Use CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM to avoid embedding the
kernel version of the build machine.
https://tests.reproducible-builds.org/debian/issues/unstable/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
VTK/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfConfig.h.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/VTK/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfConfig.h.in b/VTK/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfConfig.h.in
index bb49d09c..26ba625c 100644
--- a/VTK/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfConfig.h.in
+++ b/VTK/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfConfig.h.in
@@ -32,7 +32,7 @@
#define XDMF_BYTE_ORDER_LITTLE
#endif
-#define XDMF_SYSTEM ${CMAKE_SYSTEM}
+#define XDMF_SYSTEM ${CMAKE_SYSTEM_NAME}
#cmakedefine XDMF_VOID_VALID
#ifndef XDMF_VOID_VALID
--
2.20.1
signature.asc
Description: PGP signature
Bug#983583: FTBFS on mips64el and mipsel
Source: golang-github-sylabs-sif Version: 1.0.9-2 Severity: serious X-Debbugs-Cc: z...@debian.org Tried 3 times on buildd and failed at same test. === RUN TestAddDelObject unexpected fault address 0xffc8a0c000 fatal error: fault [signal SIGSEGV: segmentation violation code=0x2 addr=0xffc8a0c000 pc=0x12007ebe4] goroutine 22 [running]: runtime.throw(0x1201b74ed, 0x5) /usr/lib/go-1.15/src/runtime/panic.go:1116 +0x6c fp=0xce3430 sp=0xce3408 pc=0x120040afc runtime.sigpanic() Since it has been built on mipsx before, the failure will cause it impossible to fix issue later on these arch. It should either be removed from these arch or get fixed.
Bug#907440: libvirt-daemon: libvirtd spams host logs with `cant open .../memory.memsw.usage_in_bytes'
I can confirm this is the case, and that this bug has lingered without a reply for two years and a half already :-( The log flooding happens only when virt-manager is open (because it keeps polling several files for displaying the guests' status). The messages also appear when querying for specific information using virsh: # dommemstat --domain sirf error: Failed to get memory statistics for domain sirf error: Unable to read from '/sys/fs/cgroup/memory/machine/lxc-29895-sirf.libvirt-lxc/memory.memsw.usage_in_bytes': No such file or directory Curiously, when querying for full domain information, the data y scorrectly returned: virsh # dominfo --domain lafa Id: 38611 Name: lafa UUID: 0d4041d2-327b-42f0-8433-6aeb05beb36b OS Type:exe State: running CPU(s): 1 CPU time: 2374.6s Max memory: 2097152 KiB Used memory:1740144 KiB Persistent: yes Autostart: enable Managed save: no Security model: apparmor Security DOI: 0
Bug#983582: RFS: yadifa/2.4.2-1 -- Internet Domain Name Server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "yadifa": * Package name: yadifa Version : 2.4.2-1 Upstream Author : yadifa-us...@mailinglists.yadifa.eu * URL : https://www.yadifa.eu * License : BSD-3-clause, EURid-BSD-like, other-BSD * Vcs : https://salsa.debian.org/dns-team/yadifa Section : net It builds those binary packages: libyadifa-dev - development libraries and header files for YADIFA yadifa - Internet Domain Name Server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/yadifa/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.4.2-1.dsc Changes since the last upload: yadifa (2.4.2-1) unstable; urgency=medium . * New upstream version 2.4.2 (Closes: #971605) * Paths and keyword changes to primary and secondary * Includes yakeyrolld - a utility to generate ZSK and KSK keys * Enable systemd-resolved-avoidance (not binding to 127.0.0.53 by default) * Add missing paths and capabilties to systemd service file Regards, Markus
Bug#983365: linphone-desktop: chat messages
Hi, > Have you reached out to the SOCI maintainer in private already? I don't > see a bug report on this. If we can get a targeted fix uploaded for this > within the next days (next step of the freeze is on March 10th, with a > migration time of 10 days right now) I will attempt to push through a > new src:linphone upload. Do you know whether we need a new > src:linphone-desktop upload as well? I'm the SOCI maintainer. Dennis did email me and explain the situation, and I don't see an issue making the change. I'll prepare the upload today. If someone would please file a bug against SOCI regarding this, I would appreciate it. Best regards, Bill -- GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84
Bug#983465: openjdk-17-jre
Everything works now, thank you very much (herzlichen Dank) kind regards MB
Bug#890343: linux: make fq_codel default for default_qdisc
Hi, Le 2021-01-21 00:43, Ben Hutchings a écrit : > On Wed, 2021-01-20 at 14:46 -0800, Noah Meyerhans wrote: > > On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > > > We could do that. However, in the past (earlier in this bug, > > > > even) it's > > > > been pointed out that other packages should not be responsible > > > > for > > > > setting kernel policies, so changes like this should be the > > > > responsibility of the kernel packages. That seems like a > > > > sensible > > > > position to take. > > > > > > If this is the position of the kernel team, then fine. But some > > > packages *do* > > > tweak kernel parameters using the sysctl interface mechanism. So > > > does the kernel > > > team provides documention about what is acceptable? > > > > I think the distinction is that the other packages that tweak sysctl > > values don't claim to be doing so on behalf of the kernel team. If > > the > > kernel team is responsible for the values being set, then the > > settings > > should come from a package that the kernel team owns, not some other > > package. > > Right, maybe in linux-base? Although that might annoy derivatives that > want different defaults. > > procps is the wrong place, not just because it's out of our hands, but > because systemd applies sysctl configuration now and procps is > optional. Is there a definitive answer from the kernel team about how this should be implemented? In the meantime, Noah sent [1]. > Ben. Cheers, Vincent [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/309/diffs signature.asc Description: PGP signature
Bug#983581: lirc: Please fix dependencies
Package: lirc Version: 0.10.1-6.2~deb10u1 Severity: normal Dear maintainers, the referenced package gir1.2-vte does not exist because its correct name is gir1.2-vte-2.91. Moreover, gir1.2-glib-2.0 and gir1.2-gtk-3.0 are also used in the lirc setup tool. So at the moment you need to manually install these packages. It would be good if you could update the corresponding 'Recommends' dependencies. Thank you in advance! Best regards, Thomas Uhle -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 4.19.0-14-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lirc depends on: ii libasound2 1.1.8-1 ii libc62.28-10 ii libftdi1-2 1.4-1+b2 ii libgcc1 1:8.3.0-6 ii liblirc-client0 0.10.1-6.2~deb10u1 ii liblirc0 0.10.1-6.2~deb10u1 ii libportaudio219.6.0-1 ii libstdc++6 8.3.0-6 ii libsystemd0 241-7~deb10u6 ii libusb-0.1-4 2:0.1.12-32 ii libusb-1.0-0 2:1.0.22-2 ii lsb-base 10.2019051400 ii python3 3.7.3-1 Versions of packages lirc recommends: pn gir1.2-vte ii python3-gi3.30.4-1 ii python3-yaml 3.13-2 ii systemd 241-7~deb10u6 Versions of packages lirc suggests: ii ir-keytable 1.16.6-2 pn lirc-compat-remotes pn lirc-doc pn lirc-drv-irman ii lirc-x 0.10.1-6.2~deb10u1 pn setserial
Bug#983580: jalview: Questions/Corrections for Debconf template
Package: jalview Version: 2.11.1.3+dfsg2-3 Severity: minor While translating your Debconf message into German, we ran into the following sentence: "Jalview can automatically query the public (or any other configured) JABAWS " "services on start-up. Otherwise, they will need to initiate discovery with a " "menu option." The second sentence: a) Is ist they → users? b) Is "initiate the discovery" the same as the query you talk about in the first sentence? Also I had a hard time with some content. The package despription is rather brief, the upstream homepage is close to non-existant. Do you have some short text giving background about the terms you use, e.g. "accessions"? Finally, your template might benefit from a review on debian-l10n-english. If you update your template, please contact me with the updated de.po as well, so I can update the translation as well. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Versions of packages jalview depends on: ii default-jre2:1.11-72 pn groovy pn javahelp2 pn libapache-mime4j-java pn libaxis-java pn libbiojava4.0-java pn libcommons-discovery-java pn libhtsjdk-java ii libhttpclient-java 4.5.13-1 ii libhttpcore-java 4.4.14-1 pn libhttpmime-java pn libintervalstorej-java pn libjaba-client-java pn libjaxrs-api-java pn libjaxws-java pn libjersey1-client-java pn libjersey1-core-java pn libjetty9-java pn libjfreesvg-java pn libjmol-java pn libjson-simple-java pn libjsoup-java pn libjswingreader-java pn liblog4j1.2-java ii libmiglayout-java 5.1-3 ii libslf4j-java 1.7.30-1 pn libvamsas-client-java pn varna jalview recommends no packages. Versions of packages jalview suggests: pn clustalw pn kalign pn t-coffee -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#983579: jalview: [INTL:de] initial German debconf translation
Package: jalview Version: 2.11.1.3+dfsg2-3 Severity: wishlist Tags: patch l10n Please find the initial German debconf translation for jalview attached. Please place this file in debian/po/ as de.po for your next upload. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Greetings Helge # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the jalview package. # Helge Kreutzmann , 2021. # msgid "" msgstr "" "Project-Id-Version: jalview 2.11.1.3+dfsg2-3\n" "Report-Msgid-Bugs-To: jalv...@packages.debian.org\n" "POT-Creation-Date: 2021-02-22 17:20+0100\n" "PO-Revision-Date: 2021-02-26 18:16+0100\n" "Last-Translator: Helge Kreutzmann \n" "Language-Team: German \n" "Language: de\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Allow downloading identifiers automatically from www.jalview.org?" msgstr "" "Automatisches Herunterladen der Kennzeichner von www.jalview.org erlauben?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Jalview can automatically download a list of identifiers.org URL templates " "for viewing accessions from various biological databases." msgstr "" "Jalview kann automatisch eine Liste von identifiers.org-URL-Vorlagen zur " "Betrachtung von Akzessionen aus verschiedenen biologischen Datenbanken." #. Type: boolean #. Description #: ../templates:1001 msgid "" "This is a convenience for users but can be deactivated as it causes an " "automatic ping to www.jalview.org/services/identifiers, which records usage " "statistics." msgstr "" "Dies dient der Bequemlichkeit der Benutzer, kann aber deaktiviert werden, da " "es zu einem automtischen Ping an www.jalview.org/services/identifiers führt, " "wo Benutzungsstatistiken aufgezeichnet werden." #. Type: boolean #. Description #: ../templates:1001 msgid "" "Users can only override this preference from their own configuration file." msgstr "" "Benutzer können diese Voreinstellung nur über ihre eigene Konfigurationsdatei " "außer Kraft setzen." #. Type: boolean #. Description #: ../templates:2001 msgid "Allow automatic display of news from the Jalview website?" msgstr "Automatische Anzeige der Neuigkeiten von der Jalview-Website erlauben?" #. Type: boolean #. Description #: ../templates:2001 msgid "" "Users will be automatically shown updates from https://www.jalview.org/"; "feeds/desktop/rss in a popup window." msgstr "" "Benutzern werden automatisch Aktualisierungen von https://www.jalview.org/"; "feeds/desktop/rss in einem aufklappenden Fenster angezeigt." #. Type: boolean #. Description #: ../templates:2001 msgid "" "The news feed is informative to users but its retrieval pings www.jalview." "org, which records usage statistics." msgstr "" "Der Neuigkeiten-Feed ist für Benutzer informativ, aber beim Abruf wird www." "jalview.org kontaktiert, wo Benutzungsstatistiken aufgezeichnet werden." #. Type: boolean #. Description #: ../templates:2001 msgid "" "If this is disabled, users may still manually open the news reader. Users " "can also override this preference in the Preferences window or from their " "own configuration file." msgstr "" "Wird dies deaktivert, können Benutzer weiterhin manuell den " "Nachrichtenanzeiger öffnen. Benutzer können diese Einstellung im " "»Preferences«-Fenster oder in ihrer Konfigurationsdatei außer Kraft setzen." #. Type: boolean #. Description #: ../templates:3001 msgid "Allow prompts from Jalview's website about a user questionnaire?" msgstr "Anfragen von Jalviews Website über einen Benutzerfragebogen erlauben?" #. Type: boolean #. Description #: ../templates:3001 msgid "" "User questionnaires are posted from time to time on www.jalview.org, and " "Jalview can automatically query the site to look for them on startup, in " "order to prompt users to complete them." msgstr "" "Von Zeit zu Zeit werden Benutzerfragebögen auf www.jalview.org " "veröffentlicht und Jalview kann den Webauftritt beim Starten automatisch " "danach abfragen, um den Benutzer aufzufordern, diesen auszufüllen." #. Type: boolean #. Description #: ../templates:3001 msgid "" "Logs for the questionnaire service are used to record usage statistics, and " "anonymised cookies are stored in the user's preferences to track whether " "they have completed the latest questionnaire." msgstr "" "Protokolle für den Befragungsdienst werden zur Aufzeichnung von " "Benutzerstatistiken verwandt und anonymisierte Cookies werden in den " "Einstellungen des Benutzers gespeichert, um nachzuverfolgen, ob sie den " "neusten Fragebogen ausgefüllt haben." #. Type: boolean #. Description #: ../templates:3001 msgid "" "Users can enable or disable this query from their own configuration file,
Bug#983542: gnome-session-flashback: Wastebaske/t icon - label is linewrapped
Hi Andrej and Philip! On Fri, Feb 26, 2021 at 04:59:54PM +0100, Andrej Shadura wrote: > > In en_GB you could probably also use "Rubbish" as the alternative word, > > but that does not work in the US AFAIK. Then again this is just for the > > en_GB translation, so that's probably fine. > > > > Most "en_GB" speakers would probably say "Bin" as the nearest > > translation from US-ian "Trash", especially since both can be used as > > both a noun and a verb, but I think that "Bin" is probably too short for > > the label, and would look strange -- might be worth a try though. > > What about Wastebin/Waste bin? I’m probably not very representative as > I’m not a native en_GB (or even just "en") speaker, but I don’t think > I’ve heard anyone saying waste basket, but I’ve definitely heard bin or > waste bin quite a lot. Thank you both for your suggestions. I have just filed a bug upstream about this [1], but after doing that I discovered an old closed issue about the same thing, and the response was not very positive [2]. [1]: https://gitlab.gnome.org/Teams/Translation/en_GB/-/issues/9 [2]: https://gitlab.gnome.org/Teams/Translation/en_GB/-/issues/3#note_582937 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#983578: stterm: defaul variable for TERM didn't appear to work by default
Package: stterm Version: 0.8.2-1 Severity: important Dear Maintainer, With st, i ran $ htop Error opening terminal: st-256color. $ but after I added [ $TERM = st-256color ] && export TERM=xterm-256color to my bashrc, htop worked perhaps a change the default TERM value in config.def.h would be good? thanks -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stterm depends on: ii libc6 2.28-10 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3+deb10u2 ii libx11-62:1.6.7-1+deb10u1 ii libxft2 2.3.2-2 ii ncurses-term6.1+20181013-2+deb10u2 stterm recommends no packages. stterm suggests no packages. -- no debconf information
Bug#898177: [related feature respect /etc/mailname] Re: please add MAILFROM to cron
Dear Tomas, El jue., 25 feb. 2021 12:52, Tomas Pospisek escribió: > Javier, > > seeing that you do not seem to have been working on cron for a few years > would it be OK with you if I posted something along these lines to > debian-devel: I can send a message along the lines of your proposal below to d-d. Will schedule it to do it soon. Best regards Javier
Bug#983567: Subject: systemd-nspawn: can not run any command related changing the timestamp of files in the i386 bullseye chroot
Control: tags -1 + moreinfo Hello Binh Am 26.02.21 um 12:13 schrieb binh1.tran...@toshiba.co.jp: I enter to the bullseye chroot with i386 architecture by systemd-nspawn command, and i can't run any command related changing the timestamp of files as below: debian-buster:~$ mkdir chroot-bullseye-i386 debian-buster:~$ sudo debootstrap --arch=i386 bullseye chroot-bullseye-i386 http://deb.debian.org/debian/ debian-buster:~$ sudo systemd-nspawn -q --resolv-conf=off --timezone=off -D chroot-bullseye-i386 root@chroot-bullseye-i386:~# touch /usr/bin/bootctl touch: setting times of '/usr/bin/bootctl': Operation not permitted root@chroot-bullseye-i386:~# date Thu Jan 1 00:00:01 UTC 1970 Is this bug of systemd-container package? Can you describe your host system? Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#983577: FTBFS: src/github.com/future-architect/vuls/oval/util.go:239:43: not enough arguments in call to driver.GetByPackName
Package: vuls Version: 0.6.1-2 Severity: serious X-Debbugs-Cc: z...@debian.org Recently goval-dictionary was upgraded 0.2.0-4, causes this package FTBFS. https://buildd.debian.org/status/fetch.php?pkg=vuls&arch=amd64&ver=0.6.1-2%2Bb2&stamp=1614218113&raw=0 # github.com/future-architect/vuls/oval src/github.com/future-architect/vuls/oval/util.go:239:43: not enough arguments in call to driver.GetByPackName have (string, string) want (string, string, string, string)
Bug#983365: linphone-desktop: chat messages
On Fri, Feb 26, 2021 at 10:23:04AM +0100, Bernhard Schmidt wrote: > Have you confirmed already that the whole soci/linphone dance really > fixes this issue? No. I installed my liblinphone* packages with soci support and I don't see a difference in behaviour yet. I must state though that I haven't been able to get chat to work at all yet, so it might mean nothing. I may have to set up an asterisk server. > Do you know whether we need a new src:linphone-desktop upload as > well? After installing the liblinphone* packages libsoc_core showed up in the output of "ldd /usr/bin/linphone" and it started without crashing. I don't know if any subtle template magic could cause problems. I keep stumbling into segfaults both in Qt and liblinphone and I can never tell if they are due to something I changed or just lingering bugs. I'll keep looking into this throughout the weekend and will post any new findings. Regards, Dennis.
Bug#983576: CVE-2020-8020 CVE-2020-8021 CVE-2020-8031
Source: open-build-service Severity: important Tags: security X-Debbugs-Cc: Debian Security Team CVE-2020-8020: https://bugzilla.suse.com/show_bug.cgi?id=1171439 https://github.com/openSUSE/open-build-service/commit/7cc32c8e2ff7290698e101d9a80a9dc29a5500fb CVE-2020-8021: https://bugzilla.suse.com/show_bug.cgi?id=1171649 https://github.com/openSUSE/open-build-service/commit/7323c904f86ba9e04065c23422d06c03647589fb CVE-2020-8031: https://bugzilla.suse.com/show_bug.cgi?id=1178880 Cheers, Moritz
Bug#983575: CVE-2020-29443
Package: qemu Severity: important Tags: security X-Debbugs-Cc: Debian Security Team CVE-2020-29443: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04255.html https://www.openwall.com/lists/oss-security/2021/01/18/2 Patches: https://git.qemu.org/?p=qemu.git;a=commit;h=813212288970c39b1800f63e83ac6e96588095c6 https://git.qemu.org/?p=qemu.git;a=commit;h=b8d7f1bc59276fec85e4d09f1567613a3e14d31e Cheers, Moritz
Bug#983574: dpdk_config_options in DEB_BUILD_OPTIONS fails
Package: dpdk Version: unstable The support for specifying dpdk_config_options in DEB_BUILD_OPTIONS fails when building the unstable branch in a bullseye schroot. It appears that commas are being replaced with dashes. DEB_BUILD_OPTIONS="dpdk_config_options=-Duse_hpet=true,-Dmax_ethports=128,-Dmax_numa_nodes=8,-Ddisable_drivers=net/softnic" gbp buildpackage -uc -us dh_auto_configure -- -Duse_hpet=true-Dmax_ethports=128-Dmax_numa_nodes=8-Ddisable_drivers=net/softnic \ --includedir=include/dpdk \ --default-library=shared \ -Dper_library_versions=false \ -Dinclude_subdir_arch=../x86_64-linux-gnu/dpdk \ -Dmachine="default" install -d obj-x86_64-linux-gnu cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Duse_hpet=true-Dmax_ethports=128-Dmax_numa_nodes=8-Ddisable_drivers=net/softnic --includedir=include/dpdk --default-library=shared -Dper_library_versions=false -Dinclude_subdir_arch=../x86_64-linux-gnu/dpdk -Dmachine=default The Meson build system Version: 0.56.2 Source dir: /home/brownn/dpdk Build dir: /home/brownn/dpdk/obj-x86_64-linux-gnu Build type: native build Program cat found: YES (/bin/cat) ../meson.build:4:0: ERROR: Value true-Dmax_ethports=128-Dmax_numa_nodes=8-Ddisable_drivers=net/softnic is not boolean (true or false). A full log can be found at /home/brownn/dpdk/obj-x86_64-linux-gnu/meson-logs/meson-log.txt cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt ==> meson-logs/meson-log.txt <== Build started at 2021-02-26T15:25:29.485465 Main binary: /usr/bin/python3 Build Options: -Duse_hpet=true-Dmax_ethports=128-Dmax_numa_nodes=8-Ddisable_drivers=net/softnic -Dper_library_versions=false -Dinclude_subdir_arch=../x86_64-linux-gnu/dpdk -Dmachine=default -Dprefix=/usr -Dincludedir=include/dpdk -Dlibdir=lib/x86_64-linux-gnu -Dlocalstatedir=/var -Dsysconfdir=/etc -Dbuildtype=plain -Ddefault_library=shared -Dwrap_mode=nodownload Python system: Linux The Meson build system Version: 0.56.2 Source dir: /home/brownn/dpdk Build dir: /home/brownn/dpdk/obj-x86_64-linux-gnu Build type: native build Program cat found: YES (/bin/cat) Running command: /bin/cat /home/brownn/dpdk/VERSION --- stdout --- 20.11.0 --- stderr --- ../meson.build:4:0: ERROR: Value true-Dmax_ethports=128-Dmax_numa_nodes=8-Ddisable_drivers=net/softnic is not boolean (true or false). dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Duse_hpet=true-Dmax_ethports=128-Dmax_numa_nodes=8-Ddisable_drivers=net/softnic --includedir=include/dpdk --default-library=shared -Dper_library_versions=false -Dinclude_subdir_arch=../x86_64-linux-gnu/dpdk -Dmachine=default returned exit code 1 make[1]: *** [debian/rules:83: override_dh_auto_configure] Error 25
Bug#983554: inkscape: Measurement path effect scale inaccurate after changing display units in document properties
Control: tag -1 upstream Hi Will, On Thu, Feb 25, 2021 at 10:54:34PM -0800, will wrote: > Changing the Display Units to anything other than the default mm throws off > the > measurement path effect. > > With the default display unit (mm), the measurements are displayed correctly. > The file with display unit changed to inches shows an incorrect measurement. > Other units are also affected, for example: cm is off by a factor of x10. Could I ask you to please read this other bugs report and check whether that matches what you are reporting? https://gitlab.com/inkscape/inkscape/-/issues/1675 Thank you in advance! -- 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#887649: cdebconf-gtk-terminal: Please don't depend on unmaintained vte
On Thu, 03 Sep 2020 at 11:46:56 +0200, Cyril Brulebois wrote: > Simon McVittie (2020-09-03): > > One way to resolve [needing a libstdc++ udeb] > > might be to build the vte2.91 udeb with > > -static-libstdc++, which makes it about 200K larger than it would > > otherwise have been, but avoids needing a 1.5M shared libstdc++. vte > > exports a C ABI, and only uses C++ internally. > > This looks like a nice plan, thanks for the heads-up! This happened a while ago. However, since we're already in soft freeze, a GTK 3 port of the graphical installer interface is clearly not something to start on right now - so I think this has to slip to Debian 12. Release team: I think #887649 is going to need to be bullseye-ignore. smcv
Bug#983469: RFS: glmark2/2021.02-1 [RFP] -- OpenGL (ES) 2.0 benchmark suite
On Fri, Feb 26, 2021 at 03:35:19PM +0100, Adam Borowski wrote: > On Wed, Feb 24, 2021 at 07:55:11PM +0200, Marius Vlad wrote: > > * Package name: glmark2 > >Version : 2021.02-1 > > > It builds those binary packages: > > > > glmark2-data - OpenGL (ES) 2.0 benchmark suite -- data files > > glmark2-drm - OpenGL 2.0 benchmark suite > > glmark2-es2-drm - OpenGL 2.0 benchmark suite > > glmark2-wayland - OpenGL 2.0 benchmark suite > > glmark2-es2-wayland - OpenGL 2.0 benchmark suite > > glmark2-x11 - OpenGL 2.0 benchmark suite > > glmark2-es2-x11 - OpenGL 2.0 benchmark suite > > > > glmark2 (2021.02-1) unstable; urgency=low > > . > >* Initial release. (Closes: #695849) > > Includes 2 patches from upstream to fix two issues, one related to > > wayland > > and one about creating two EGLDisplays which might cause issues on some > > platforms. > > Hi! > I'm afraid the least fun part of packaging -- copyright -- needs a lot of > work. For example: Hi, thanks for taking a look. > > NTP license: > 1994-1996, Thomas G. Lane. > 1988 by Jef Poskanzer. > 2015, D. R. Commander. > ./src/libjpeg-turbo/rdcolmap.c > ./src/libjpeg-turbo/rdppm.c > ./src/libjpeg-turbo/wrgif.c > > Apache: > ./android/build.sh > > ISC: > ./src/include/getopt.h > > Khronos: > ./src/glad/include/EGL/eglplatform.h > ./src/glad/include/KHR/khrplatform.h > > -- and so on, I did not analyze the licenses in depth. > > > In a brief review of non-copyright stuff, I did not notice any problems. Does that mean that I need to run some kind of license (debmake) tool that scans everything in src/ and then 'adapt' debian/changelog to match that? I'm looking over the man page of debmake and it seems it is capable of mostly generate everything. > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] > ⣾⠁⢠⠒⠀⣿⡁ # beware of races > ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn > ⠈⠳⣄ ` signature.asc Description: PGP signature
Bug#983542: gnome-session-flashback: Wastebaske/t icon - label is linewrapped
Hi Phil and Dmitry, On Fri, 26 Feb 2021 15:02:33 +0100 Philip Hands wrote: > Dmitry Shachnev writes: > >> If rewording is deemed the right way to fix this, I would suggest > >> "Recycling" as a reasonable alternative: It's shorter, so ought to fit; > >> also > >> it matches the icon, which includes the circular-arrow recycling symbol. > > I am not a native speaker of en_GB. Do you think "Recycling" can be used in > > all places where "Wastebasket" is used currently, and where "Trash" is used > > in > > en_US? E.g. "Trashed On" → "Recycled On", > In en_GB you could probably also use "Rubbish" as the alternative word, > but that does not work in the US AFAIK. Then again this is just for the > en_GB translation, so that's probably fine. > > Most "en_GB" speakers would probably say "Bin" as the nearest > translation from US-ian "Trash", especially since both can be used as > both a noun and a verb, but I think that "Bin" is probably too short for > the label, and would look strange -- might be worth a try though. What about Wastebin/Waste bin? I’m probably not very representative as I’m not a native en_GB (or even just "en") speaker, but I don’t think I’ve heard anyone saying waste basket, but I’ve definitely heard bin or waste bin quite a lot. -- Cheers, Andrej
Bug#983365: linphone-desktop: chat messages
Am 26.02.21 um 15:19 schrieb Bill Blough: Hi Bill, > Hi, > >> Have you reached out to the SOCI maintainer in private already? I don't >> see a bug report on this. If we can get a targeted fix uploaded for this >> within the next days (next step of the freeze is on March 10th, with a >> migration time of 10 days right now) I will attempt to push through a >> new src:linphone upload. Do you know whether we need a new >> src:linphone-desktop upload as well? > > I'm the SOCI maintainer. Dennis did email me and explain the > situation, and I don't see an issue making the change. > > I'll prepare the upload today. If someone would please file a bug > against SOCI regarding this, I would appreciate it. Thanks, I've opened Bug#983572 for this. Bernhard
Bug#780280: dak: generate rejection mail for mails with expired signature
Hey folks, this issue still seems to exist, I just discovered that an upload I did three months ago was never processed because I forgot to push my extended key to Debian, which is a bit of a bummer. Gr. Matthijs signature.asc Description: PGP signature
Bug#940821: NFS Caching broken in 4.19.37
On 26/02/2021 15:03, Timo Rothenpieler wrote: I think I can reproduce this, or something that at least looks very similar to this, on 5.10. Namely on 5.10.17 (On both Client and Server). I think this is a different issue - see below. We are running slurm, and since a while now (coincides with updating from 5.4 to 5.10, but a whole bunch of other stuff was updated at the same time, so it took me a while to correlate this) the logs it writes have been truncated, but only while they're being observed on the client, using tail -f or something like that. Looks like this then: On Server: store01 /srv/export/home/users/timo/TestRun # ls -l slurm-41101.out -rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out store01 /srv/export/home/users/timo/TestRun # wc -l slurm-41101.out 61 slurm-41101.out On Client: timo@login01 ~/TestRun $ ls -l slurm-41101.out -rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out timo@login01 ~/TestRun $ wc -l slurm-41101.out 24 slurm-41101.out See https://gist.github.com/BtbN/b9eb4fc08ccc53bb20087bce0bf9f826 for the respective file-contents. If I run the same test job, wait until its done, and then look at its slurm.out file, it matches between NFS Client and Server. If I tail -f the slurm.out on an NFS client, the file stops getting updated on the client, but keeps getting more logs written to it on the NFS server. The slurm.out file is being written to by another NFS client, which is running on one of the compute nodes of the system. It's being reads from a login node. These are two different clients, then what you see is possible on NFS with client side caching. If you have multiple clients reading/writing to the same files you usually need to tune the caching options and/or use locking. I suspect that if you leave it for a while (until the cache expires) it will sort itself out. In my test-case it is just one client, it missed a file deletion and nothing short of an unmount and remount fixes that. I have waited for 30 mins+. It does not seem to refresh or expire. I also see the opposite behavior - the bug shows up on 4.x up to at least 5.4. I do not see it on 5.10. Brgds, Timo On 21.02.2021 16:53, Anton Ivanov wrote: Client side. This seems to be an entirely client side issue. A variety of kernels on the clients starting from 4.9 and up to 5.10 using 4.19 servers. I have observed it on a 4.9 client versus 4.9 server earlier. 4.9 fails, 4.19 fails, 5.2 fails, 5.4 fails, 5.10 works. At present the server is at 4.19.67 in all tests. Linux jain 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux I can set-up a couple of alternative servers during the week, but so far everything is pointing towards a client fs cache issue, not a server one. Brgds, -- Anton R. Ivanov Cambridgegreys Limited. Registered in England. Company Number 10273661 https://www.cambridgegreys.com/
Bug#983573: Build with ENABLE_DB_STORAGE
Package: src:linphone Version: 4.4.21-1 Severity: important As discussed in RC Bug#983365 we probably need to build src:linphone with ENABLE_DB_STORAGE for persistent storage in linphone-desktop. This in turn needs C++11 support in src:soci which is tracked by Bug#983572.
Bug#983531: buster-pu: package python2.7/2.7.16-2+deb10u2
On Fri, Feb 26, 2021 at 07:49:38AM +0100, Matthias Klose wrote: > On 2/25/21 7:41 PM, Moritz Muehlenhoff wrote: > > + * CVE-2021-3177 > > are all the ctypes tests passing with this patch? See #983516. I'll have a look at Marc' updated patch and revise if needed. Cheers, Moritz
Bug#983572: Please build with -DSOCI_CXX11=YES
Package: src:soci Version: 4.0.1-3 Severity: important Dear maintainer, as discussed by mail, please build soci with C++11 support (-DSOCI_CXX11=YES). This will allow us to build src:linphone with DB storage which in turn will hopefully be the fix for RC Bug#983365 on linphone-desktop. Thanks in advance! Bernhard
Bug#983435: Regarding the backup/restore function
On Fri, 26 Feb 2021 10:21:47 +0900 bugsgrid+...@gmail.com wrote: > Regarding the backup/restore function > in the commit bb3205709aa9f83e1c8cb91e7f6f9f110d41b34e, > for me it seems bringing in more critical dangers than the safety it provides. > > The logic is too error prone, it relies on on_exit() absolutely never > duped by any fork()'s, > meaning it's requiring absolutely every fork() in the entire code to be > patched. > And there is no safeguard against misfiring of restore_backup_on_exit(). > It itself is "just irrevocably removing them as the first action," > even if there is nothing to be restored. > Oh well. > > I bet it's better to set onhold on grub for now... > > Reading the logs above I am not sure what is causing the misfire. I see that it fails to install any translations, are grub.mo from grub-common somehow excluded on the system? (i.e. with a dpkg filter) Is that the cause for the bug, or a red herring, I will try to test that. I would want to make it safer if I could. Indeed, duped by any fork() is painful. Intention is for the top level tool to decide if it is aborting or not, and unfortunately it doesn't do any sort of cleanup and just exits() whenever it is. For me to avoid doing it on_exit() would mean to rewrite all the places where grub_install tries to exit to try to do cleanups & restores. Would doing it in grub-install without on_exit inspire more confidence, or guarding to only do anything in the main_pid of grub-install? Should the log of actions be maintained and then rolled back only if they can be? Regards, Dimitri.
Bug#940821: NFS Caching broken in 4.19.37
I think I can reproduce this, or something that at least looks very similar to this, on 5.10. Namely on 5.10.17 (On both Client and Server). We are running slurm, and since a while now (coincides with updating from 5.4 to 5.10, but a whole bunch of other stuff was updated at the same time, so it took me a while to correlate this) the logs it writes have been truncated, but only while they're being observed on the client, using tail -f or something like that. Looks like this then: On Server: store01 /srv/export/home/users/timo/TestRun # ls -l slurm-41101.out -rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out store01 /srv/export/home/users/timo/TestRun # wc -l slurm-41101.out 61 slurm-41101.out On Client: timo@login01 ~/TestRun $ ls -l slurm-41101.out -rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out timo@login01 ~/TestRun $ wc -l slurm-41101.out 24 slurm-41101.out See https://gist.github.com/BtbN/b9eb4fc08ccc53bb20087bce0bf9f826 for the respective file-contents. If I run the same test job, wait until its done, and then look at its slurm.out file, it matches between NFS Client and Server. If I tail -f the slurm.out on an NFS client, the file stops getting updated on the client, but keeps getting more logs written to it on the NFS server. The slurm.out file is being written to by another NFS client, which is running on one of the compute nodes of the system. It's being reads from a login node. Timo On 21.02.2021 16:53, Anton Ivanov wrote: Client side. This seems to be an entirely client side issue. A variety of kernels on the clients starting from 4.9 and up to 5.10 using 4.19 servers. I have observed it on a 4.9 client versus 4.9 server earlier. 4.9 fails, 4.19 fails, 5.2 fails, 5.4 fails, 5.10 works. At present the server is at 4.19.67 in all tests. Linux jain 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux I can set-up a couple of alternative servers during the week, but so far everything is pointing towards a client fs cache issue, not a server one. Brgds, smime.p7s Description: S/MIME Cryptographic Signature
Bug#969597: libzstd: Please correct version in symbol file
Control: severity -1 important On Wed, 27 Jan 2021 20:14:22 +0100, Stephen Kitt wrote: > On Mon, 25 Jan 2021 23:20:37 +0100, Sebastian Andrzej Siewior > wrote: > > On 2021-01-25 22:59:08 [+0100], Stephen Kitt wrote: > > > That was no doubt the intention, however in practice the symbol > > > visibility wasn’t as expected: looking at the .so build in version > > > 1.3.8, common/pool.c includes common/zstd_internal.h which defines > > > ZSTD_STATIC_LINKING_ONLY before including zstd.h, and as a result the > > > symbols are visible. > > > > > > (It’s unfortunate that the build hides the exact commands used, so > > > they’re not visible in the build logs, but that’s another issue. Easy > > > enough to fix in a local build to see exactly what’s going on...) > > > > > > So the cat is out of the bag, and the symbols are present and visible > > > in the .so. The symbols file is generated and only reflects the > > > reality of what is present in the file (apart from the version numbers > > > which are added manually). > > > > I opened the bug because I couldn't use these symbols in Buster's zstd > > but had to use bpo instead. rsync is meanwhile available in bpo and > > pulls-in the libzstd from bpo which is good. > > > > I have no idea what should be done here to close this properly. > > I think the best fix at this point will be to bump the versions in the > symbols file to match the intention, and then binNMU all the packages with a > dependency on (>= 1.3.8) so that they get fixed to (>= 1.4.0) if > appropriate. I’ve been working on improving this, but ultimately I think a symbols file isn’t currently appropriate for libzstd in Debian (see https://github.com/facebook/zstd/pull/2501 for the discussion with upstream). I’m going to file an unblock request to discuss this with the release team; my plan now is to NMU the package, dropping the symbols file and adjusting the shlibs file, and then requesting rebuilds of all packages with insufficient dependencies. Regards, Stephen pgptGg9bD7Hed.pgp Description: OpenPGP digital signature
Bug#983469: RFS: glmark2/2021.02-1 [RFP] -- OpenGL (ES) 2.0 benchmark suite
On Wed, Feb 24, 2021 at 07:55:11PM +0200, Marius Vlad wrote: > * Package name: glmark2 >Version : 2021.02-1 > It builds those binary packages: > > glmark2-data - OpenGL (ES) 2.0 benchmark suite -- data files > glmark2-drm - OpenGL 2.0 benchmark suite > glmark2-es2-drm - OpenGL 2.0 benchmark suite > glmark2-wayland - OpenGL 2.0 benchmark suite > glmark2-es2-wayland - OpenGL 2.0 benchmark suite > glmark2-x11 - OpenGL 2.0 benchmark suite > glmark2-es2-x11 - OpenGL 2.0 benchmark suite > > glmark2 (2021.02-1) unstable; urgency=low > . >* Initial release. (Closes: #695849) > Includes 2 patches from upstream to fix two issues, one related to wayland > and one about creating two EGLDisplays which might cause issues on some > platforms. Hi! I'm afraid the least fun part of packaging -- copyright -- needs a lot of work. For example: NTP license: 1994-1996, Thomas G. Lane. 1988 by Jef Poskanzer. 2015, D. R. Commander. ./src/libjpeg-turbo/rdcolmap.c ./src/libjpeg-turbo/rdppm.c ./src/libjpeg-turbo/wrgif.c Apache: ./android/build.sh ISC: ./src/include/getopt.h Khronos: ./src/glad/include/EGL/eglplatform.h ./src/glad/include/KHR/khrplatform.h -- and so on, I did not analyze the licenses in depth. In a brief review of non-copyright stuff, I did not notice any problems. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#983542: gnome-session-flashback: Wastebaske/t icon - label is linewrapped
Dmitry Shachnev writes: > Hi Philip! > > On Thu, Feb 25, 2021 at 10:47:41PM +0100, Philip Hands wrote: >> Dear Maintainer, >> >> [This may well be reported against the wrong package, because >> it's not immediately clear to me what would cause this, >> so please reasign this bug as as you see fit.] >> >> As you can see here: >> >> https://openqa.debian.net/tests/11042#step/_graphical_wait_login/9 >> >> the Wastebasket's icon has it's label line-wrapped, such that it looks >> something >> like this: >> >> | | >> | | >> +--+ >> Wastebaske >> t > > This seems to come from the en_GB translation of nautilus: > > https://sources.debian.org/src/nautilus/3.38.2-1/po/en_GB.po/#L4253 > >> If rewording is deemed the right way to fix this, I would suggest >> "Recycling" as a reasonable alternative: It's shorter, so ought to fit; also >> it matches the icon, which includes the circular-arrow recycling symbol. > > I am not a native speaker of en_GB. Do you think "Recycling" can be used in > all places where "Wastebasket" is used currently, and where "Trash" is used in > en_US? E.g. "Trashed On" → "Recycled On", If "Trashed On" refers to the date something was moved to the trash folder, then I think "Recycled On" pretty-much works. Except perhaps that the metaphor doesn't quite match, because I'd assume that "Recycled On" would be the date that it was rendered down into it's ones and zeros and those were made available for use by other files (e.g. final actual deletion). It probably depends on the context, since if one is still looking at the file, and being told when it was moved, then clearly it's not yet been finally "recycled". On the other hand "Trashed" in normal speech seems likely to mean the moment that something was rendered unusable, rather than the moment you dropped it in the bin. "I trashed my car" tends to mean that it stopped being a thing one could drive at that exact moment. > "Date when file was moved to the Trash" → "Date when file was moved to > the Recycling" (or was recycled?), etc. That does work I think. "Moved to recycling" seems to be distinct from "recycled", whereas I'd think that "Trashed" could mean either of those. > If you think these translations are fine, I will file a bug upstream against > Nautilus suggesting to change them. In en_GB you could probably also use "Rubbish" as the alternative word, but that does not work in the US AFAIK. Then again this is just for the en_GB translation, so that's probably fine. Most "en_GB" speakers would probably say "Bin" as the nearest translation from US-ian "Trash", especially since both can be used as both a noun and a verb, but I think that "Bin" is probably too short for the label, and would look strange -- might be worth a try though. BTW I note that LXDE has dealt with the problem slightly differently: https://openqa.debian.net/tests/11056#step/_graphical_wait_login/12 which shows us something that looks like: | | | | +--+ Wastebas... which is a bit neater to look at, but seems likely to be a problem for non-native readers, and may even be an accessibility problem (but I'd hope that screen readers and the like get to deal with the full word rather than mangling it in the same way). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#981003: Kernel paniced with null pointer dereference on Panasonic CF-SV9 notebook machine
Hi Salvatore, > Would it be possible for you to test the two patches submitted as > https://lore.kernel.org/linux-acpi/20210208120104.204761-1-marcin.slus...@gmail.com/ > and > https://lore.kernel.org/linux-acpi/20210208120104.204761-2-marcin.slus...@gmail.com/ > ? Yes, the first patch worked fine for my notebook machine. I applied the fistpatch to the linux-image-5.10.13-1 source, built a linux-image-5.10.0-3-amd64-unsigned package, installed the package to my machine using dpkg, and the machine booted without kernel panic. It seems that the second patch is just for comment fix, right? I did not applied the second patch. Best regards, -- Hiroshi Kubo
Bug#916691: cuyo -- Not fit for next release
Hi, Currenlty I adopt the package, and is up-to-date with upstream. Thanks for this report. Cheers, Emmanuel
Bug#940621: libmeanwhile1: Login verification down or unavailable on 1.0.2-9+b1
On Fri, 26 Feb 2021 09:23:03 +0100 Adrien CLERC wrote: > > Boyuan Yang, can you reintroduce -fno-tree-vrp in CFLAGS please? I can't > connect to Sametime right now. I did a lot of tests, and it seems that only "export DEB_CFLAGS_MAINT_APPEND=-O0" fix this issue. Applying manual optimizations from O1 or O2 didn't trigger the issue, but unfortunately, some flags don't exist (see https://gcc.gnu.org/wiki/FAQ#optimization-options) And applying "-O0 -O1" trigger the issue. If you have more thing in mind, please tell me, I am able to test it. But I'll stick to -O0 for my local installation
Bug#983533: Fix for #983533, fix session startup of RDP session in vinagre's RDP plugin
Control: tags -1 patch
I have done more tests with vinagre. I have attached a .debdiff that
fixes Vinagre's connection initialization and gives me a working RDP
session.
Upstream authors of FreeRDP mentioned that Vinagre's way of using the
FreeRDP API is rather old and it should be reworked by Vinagre
upstream maintainers.
However, session startup now works, but maybe more flaws are ahead.
See attached .debdiff for the proposed fix (and ignore the patch that
was attached to my earlier post).
Mike
--
DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
diff -Nru vinagre-3.22.0/debian/changelog vinagre-3.22.0/debian/changelog
--- vinagre-3.22.0/debian/changelog 2021-01-01 01:09:52.0 +0100
+++ vinagre-3.22.0/debian/changelog 2021-02-25 19:48:08.0 +0100
@@ -1,3 +1,11 @@
+vinagre (3.22.0-8.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches:
++ Add 0003-fix-hangs-with-recent-FreeRDP-version.patch. (Closes: -1).
+
+ -- Mike Gabriel Thu, 25 Feb 2021 19:48:08 +0100
+
vinagre (3.22.0-8) unstable; urgency=medium
* Team upload.
diff -Nru
vinagre-3.22.0/debian/patches/0003-fix-hangs-with-recent-FreeRDP-version.patch
vinagre-3.22.0/debian/patches/0003-fix-hangs-with-recent-FreeRDP-version.patch
---
vinagre-3.22.0/debian/patches/0003-fix-hangs-with-recent-FreeRDP-version.patch
1970-01-01 01:00:00.0 +0100
+++
vinagre-3.22.0/debian/patches/0003-fix-hangs-with-recent-FreeRDP-version.patch
2021-02-25 19:48:08.0 +0100
@@ -0,0 +1,78 @@
+From 404a56a11469ef24a1df632847465030d81db091 Mon Sep 17 00:00:00 2001
+From: Ondrej Holy
+Date: Fri, 15 May 2020 15:43:37 +0200
+Subject: [PATCH] plugins/rdp: Fix hangs with recent FreeRDP versions
+
+Connection to all my testing servers fails with "SERVER BUG: The support
+for this feature was not announced! Use /relax-order-checks to ignore"
+currently. This happens always with current FreeRDP versions after
+https://github.com/FreeRDP/FreeRDP/pull/4926 has been merged. This can be
+fixed by the usage of /relax-order-checks option, however, this option
+should be used only if necessary needed and it should not be needed in
+most of the cases. This currenlty happens always as it interfere with our
+custom OrderSupports settings. Let's use the default OrderSupports
+settings to fix this issue, which is possible thanks to
+https://github.com/FreeRDP/FreeRDP/pull/5057.
+
+See: https://gitlab.gnome.org/GNOME/gtk-frdp/-/issues/27
+---
+ configure.ac | 2 +-
+ plugins/rdp/vinagre-rdp-tab.c | 27 ---
+ 2 files changed, 1 insertion(+), 28 deletions(-)
+
+--- a/configure.ac
b/configure.ac
+@@ -58,7 +58,7 @@
+ AM_CONDITIONAL([VINAGRE_ENABLE_SSH], [test "x$have_ssh" = "xyes"])
+
+ # Whether to enable support for RDP.
+-RDP_DEPS="freerdp2 x11"
++RDP_DEPS="freerdp2 >= 2.0.0 x11"
+ AC_ARG_ENABLE([rdp],
+ [AS_HELP_STRING([--disable-rdp],
+ [Disable Remote Desktop Protocol (RDP) support])])
+--- a/plugins/rdp/vinagre-rdp-tab.c
b/plugins/rdp/vinagre-rdp-tab.c
+@@ -524,32 +524,7 @@ frdp_pre_connect (freerdp *instance)
+ {
+ rdpSettings *settings = instance->settings;
+
+-#if HAVE_FREERDP_1_1
+- settings->OrderSupport[NEG_DSTBLT_INDEX] = TRUE;
+- settings->OrderSupport[NEG_PATBLT_INDEX] = TRUE;
+- settings->OrderSupport[NEG_SCRBLT_INDEX] = TRUE;
+- settings->OrderSupport[NEG_OPAQUE_RECT_INDEX] = TRUE;
+- settings->OrderSupport[NEG_DRAWNINEGRID_INDEX] = FALSE;
+- settings->OrderSupport[NEG_MULTIDSTBLT_INDEX] = FALSE;
+- settings->OrderSupport[NEG_MULTIPATBLT_INDEX] = FALSE;
+- settings->OrderSupport[NEG_MULTISCRBLT_INDEX] = FALSE;
+- settings->OrderSupport[NEG_MULTIOPAQUERECT_INDEX] = TRUE;
+- settings->OrderSupport[NEG_MULTI_DRAWNINEGRID_INDEX] = FALSE;
+- settings->OrderSupport[NEG_LINETO_INDEX] = TRUE;
+- settings->OrderSupport[NEG_POLYLINE_INDEX] = TRUE;
+- settings->OrderSupport[NEG_MEMBLT_INDEX] = TRUE;
+- settings->OrderSupport[NEG_MEM3BLT_INDEX] = FALSE;
+- settings->OrderSupport[NEG_MEMBLT_V2_INDEX] = TRUE;
+- settings->OrderSupport[NEG_MEM3BLT_V2_INDEX] = FALSE;
+- settings->OrderSupport[NEG_SAVEBITMAP_INDEX] = FALSE;
+- settings->OrderSupport[NEG_GLYPH_INDEX_INDEX] = TRUE;
+- settings->OrderSupport[NEG_FAST_INDEX_INDEX] = TRUE;
+- settings->OrderSupport[NEG_FAST_GLYPH_INDEX] = FALSE;
+- settings->OrderSupport[NEG_POLYGON_SC_INDEX] = FALSE;
+- settings->OrderSupport[NEG_POLYGON_CB_INDEX] = FALSE;
+- settings->OrderSupport[NEG_ELLIPSE_SC_INDEX] = FALSE;
+- settings->OrderSupport[NEG_ELLIPSE_CB_INDEX] = FALSE;
+-#else
++#if !HAVE_FREERDP_1_1
+ settings->order_support[NEG_DSTBLT_INDEX] = true;
+ settings->order_support[NEG_PATBLT_INDEX] = true;
+
Bug#983571: packaging-tutorial: [INTL:pt] Update on Portuguese translation of MANPAGE
Package: packaging-tutorial Version: 0.27 Tags: l10n, patch- Severity: wishlist Updated Portuguese translation for packaging-tutorial's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro packaging-tutorial_0.27.pt.po.gz Description: application/gzip
Bug#983525: [Debian-on-mobile-maintainers] Bug#983525: Bug#983525: Update to 1.1 in experimental
Hi, On Fri, Feb 26, 2021 at 12:57:25PM +0100, Sebastien Bacher wrote: > Le 26/02/2021 à 12:36, Guido Günther a écrit : > > Uploaded. Given the libhandy lives under GNOME/ upstream for some time i > > wonder if we shouldn't move it over in Debian too? > > Cheers, > > +1 from me, let me know if you want me to push the vcs to pkg-gnome? Fine with me. Let's give Arnaud a chance to object. I think both of us aren't members of the `gnome-team` salsa group so if we should continue to help we'd need to be added (I'll request membership via web-ui once the package moved). Cheers, -- Guido > > ___ > Debian-on-mobile-maintainers mailing list > debian-on-mobile-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
Bug#975954: amavisd-milter: please make the build reproducible
> Hi Harald, Hi Chris, > > Just to say that I did not see your email until now; I see > the bug submitter > does not automatically receive emails sent directly to the bug email > address ??? Oh ok I thought that the submitter gets the mail too my fault. > you should either CC them directly or use the 975954-submitter@ > alias too. I now added the 975954-submitter@ alias hope that works? > > > 1. I guess the patch is for Debian only so forwarding it to upstream is > > not necessary, correct? > > Correct, yes. Thanks for clarification. > > > 2. How urgent/important is it to have this patch in the next Debian > > stable release? I'm asking this because I' not a DD so I need a sponsor > > to do the actual upload to Debian and I don't want to put extra stress > > on somebody. > > It is/was not terribly important to get this in the next stable > release. Hope that helps, and thanks for your reply. Yes thanks will do the next upload when bullseye is released and things calm down again. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- Kind regards Harald Jenny
Bug#983526: buster-pu: package python-django/1:1.11.29-1+deb10u1
Chris Lamb wrote: > Please find an updated patch attached, which also adopts your > suggested version number: The patch I *just* sent contained a binary portion which (judging by the large number of bounces I just received!) will not have reached many of the intended recipients. Therefore, please see: https://bugs.debian.org/983526#15 … for the original version of the message and the attachment. For easy reference, however, the changelog entry is: Source: python-django Version: 1:1.11.29-1~deb10u2 Distribution: buster Urgency: medium Maintainer: Chris Lamb Timestamp: 1614334069 Date: Fri, 26 Feb 2021 10:07:49 + Closes: 969367 981562 983090 Changes: python-django (1:1.11.29-1~deb10u2) buster; urgency=medium . * CVE-2020-24583: Fix incorrect permissions on intermediate-level directories on Python 3.7+. FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files and to intermediate-level collected static directories when using the collectstatic management command. You should review and manually fix permissions on existing intermediate-level directories. (Closes: #969367) . * CVE-2020-24584: Correct permission escalation vulnerability in intermediate-level directories of the file system cache. On Python 3.7 and above, the intermediate-level directories of the file system cache had the system's standard umask rather than 0o077 (no group or others permissions). (Closes: #969367) . * CVE-2021-3281: Fix a potential directory-traversal exploit via archive.extract(). The django.utils.archive.extract() function, used by startapp --template and startproject --template, allowed directory traversal via an archive with absolute paths or relative paths with dot segments. (Closes: #981562) . * CVE-2021-23336: Prevent a web cache poisoning attack via "parameter cloaking". Django contains a copy of urllib.parse.parse_qsl() which was added to backport some security fixes. A further security fix has been issued recently such that parse_qsl() no longer allows using ";" as a query parameter separator by default. (Closes: #983090) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#983526: buster-pu: package python-django/1:1.11.29-1+deb10u1
retitle 983526 buster-pu: package python-django/1:1.11.29-1~deb10u2 thanks Hi Salvatore, > There are as well yet open other issues (which similarly do not > warrant a DSA), CVE-2021-3281, CVE-2020-24583 and CVE-2020-24584. > Can you add fixes for those as well? Of course, that was silly of me not to check. Please find an updated patch attached, which also adopts your suggested version number: python-django (1:1.11.29-1~deb10u2) buster; urgency=medium . * CVE-2020-24583: Fix incorrect permissions on intermediate-level directories on Python 3.7+. FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files and to intermediate-level collected static directories when using the collectstatic management command. You should review and manually fix permissions on existing intermediate-level directories. (Closes: #969367) . * CVE-2020-24584: Correct permission escalation vulnerability in intermediate-level directories of the file system cache. On Python 3.7 and above, the intermediate-level directories of the file system cache had the system's standard umask rather than 0o077 (no group or others permissions). (Closes: #969367) . * CVE-2021-3281: Fix a potential directory-traversal exploit via archive.extract(). The django.utils.archive.extract() function, used by startapp --template and startproject --template, allowed directory traversal via an archive with absolute paths or relative paths with dot segments. (Closes: #981562) . * CVE-2021-23336: Prevent a web cache poisoning attack via "parameter cloaking". Django contains a copy of urllib.parse.parse_qsl() which was added to backport some security fixes. A further security fix has been issued recently such that parse_qsl() no longer allows using ";" as a query parameter separator by default. (Closes: #983090) The tests all pass for me. Do note that this adds python-pytest as a test-time dependency (a backport of sorts of Python 3.x's "pathlib" module). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-diff --git a/debian/changelog b/debian/changelog index 00bbc0532..12cc85c31 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,32 @@ +python-django (1:1.11.29-1~deb10u2) buster; urgency=medium + + * CVE-2020-24583: Fix incorrect permissions on intermediate-level directories +on Python 3.7+. FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to +intermediate-level directories created in the process of uploading files +and to intermediate-level collected static directories when using the +collectstatic management command. You should review and manually fix +permissions on existing intermediate-level directories. (Closes: #969367) + + * CVE-2020-24584: Correct permission escalation vulnerability in +intermediate-level directories of the file system cache. On Python 3.7 and +above, the intermediate-level directories of the file system cache had the +system's standard umask rather than 0o077 (no group or others permissions). +(Closes: #969367) + + * CVE-2021-3281: Fix a potential directory-traversal exploit via +archive.extract(). The django.utils.archive.extract() function, used by +startapp --template and startproject --template, allowed directory +traversal via an archive with absolute paths or relative paths with dot +segments. (Closes: #981562) + + * CVE-2021-23336: Prevent a web cache poisoning attack via "parameter +cloaking". Django contains a copy of urllib.parse.parse_qsl() which was +added to backport some security fixes. A further security fix has been +issued recently such that parse_qsl() no longer allows using ";" as a query +parameter separator by default. (Closes: #983090) + + -- Chris Lamb Fri, 26 Feb 2021 10:07:49 + + python-django (1:1.11.29-1~deb10u1) buster-security; urgency=high * New upstream security release (postponed from March 2020): diff --git a/debian/control b/debian/control index f1a8bd6b7..51a16f7e3 100644 --- a/debian/control +++ b/debian/control @@ -22,6 +22,7 @@ Build-Depends: python-jinja2 , python-mock , python-numpy , + python-pathlib , python-pil , python-psycopg2-doc , python-setuptools, diff --git a/debian/patches/0010-CVE-2021-23336.patch b/debian/patches/0010-CVE-2021-23336.patch new file mode 100644 index 0..192ac7251 --- /dev/null +++ b/debian/patches/0010-CVE-2021-23336.patch @@ -0,0 +1,147 @@ +From: Chris Lamb +Date: Thu, 25 Feb 2021 16:27:58 + +Subject: CVE-2021-23336 + +--- + django/utils/http.py| 2 +- + tests/handlers/test_exception.py| 2 +- + tests/requests/test_data_upload_settings.py | 8 ++--- + tests/utils_tests/test_http.py | 55 +
Bug#940621: libmeanwhile1: Login verification down or unavailable on 1.0.2-9+b1
> > on libmeanwhile1 1.0.2-9+b1 I can't connect to Sametime with the error > "Login verification down or unavailable". > > It works on libmeanwhile1 1.0.2-9. > > This seems to be the same problem reported on #764494. Indeed, the patched applied in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815045#10 (see https://salsa.debian.org/debian/meanwhile/-/commit/6fb8a53b9423cb3980684dc886991f9d1dc03584) was dropped in the conversion when upgrading to 1.1.1 (see https://salsa.debian.org/debian/meanwhile/-/commit/05a5760e1031e20a9b830b5c7f3d5ced9cddb0b0) Boyuan Yang, can you reintroduce -fno-tree-vrp in CFLAGS please? I can't connect to Sametime right now. Have a nice day! Adrien
Bug#983069: lintian: please check that upstream signature is made with a modern hash (warn or error on MD5, SHA1, or RIPEMD160)
Hi dkg, On Thu, Feb 18, 2021 at 2:57 PM Daniel Kahn Gillmor wrote: > > uses a weak cryptographic digest algorithm. That's a great idea! As a first step, I would like to show a classification tag with the hash algorithm. (It could be used for statistics.) Can 'gpgv' output such signature characteristics? The warning you asked for would then take place on top of that—perhaps with different severities depending how dated the algorithm is. Thanks! Kind regards, Felix Lechner
Bug#983558: ITP: cdemu -- optical drive and disc emulation, including CD/DVD-ROMs
Package: wnpp Severity: wishlist Owner: Matteo Bini * Package name: cdemu Version : 3.2.4 Upstream Author : Rok Mandeljc * URL : https://cdemu.sourceforge.io/ * License : GPL Programming Lang: C Description : optical drive and disc emulation, including CD/DVD-ROMs First of all I want to apologise. I'm the author of the following wnpp ITP bug reports: - vhba-dkms [1] - libmirage11 [2] - cdemu-daemon [3] - cdemu-client [4] - gcdemu [5] - image-analyzer [6] They are a bit messy, but they were my first ones. After reading Debian docs regarding ITP reports I decided to do this the proper way. I should have read more docs in the first place, I'm sorry. CDEmu is a software suite made primarily by Rok Mandeljc. It allows CD/DVD emulation in a similar fashion to Alcohol 120%, CloneCD or DAEMON Tools on Windows, which means it can emulate several DRM strategies used by old games. In addition to that it is also able to read and write most optical drive and disc formats such as B6T, CCD, CDI, CUE, ISO, MDS, NRG and TOC. The software suite consists of: - a kernel module implementing a virtual drive-controller - libMirage, a software library for interpreting optical disc images - a daemon which emulates the functionality of an optical drive and disc - command line and GTK clients for controlling the emulator - a GTK application that displays tree structure of libMirage disc images On the project website you can already find tarballs that produce DEB packages compatible with both Debian 9 and 10. The resulting packages are: - vhba-dkms - libmirage11 - gir1.2-mirage-3.2 - cdemu-daemon - cdemu-client - gcdemu - image-analyzer For the sake of ease I would add a couple of meta packages as well: - cdemu or cdemu-suite with the full suite - cdemu-cli with only the command line client, without image-analyzer I use this software to play old games on CD/DVD with disc-based DRM methods and since Debian packages Wine, which does a great job playing those titles, I think it would be a neat inclusion into the repository. Moreover this software can be used for many other purposes. It is also stable. Lastly there already are two old RFP bugs [7] that ask for the software inclusion. I am willing to mantain these packages, I am willing to compile DEB packages and to provide support. I've received Mr. Mandeljc's blessing to add CDEmu into Debian repository. Please, let's make this happen! It would be a huge honour to help this wonderful OS grow, albeit in such a humble way. Greetings. -- Matteo Bini [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983402 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983444 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983451 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983452 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983453 [6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983454 [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237925 [7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705409
