Bug#984788: (pre-approval) unblock: octave/6.2.0-1
Hi Paul ! Le lundi 08 mars 2021 à 22:17 +0100, Paul Gevers a écrit : > On 08-03-2021 13:19, Sébastien Villemot wrote: > > This is a pre-approval request for unblocking package octave, version > > 6.2.0-1 > > > > Currently, bullseye contains a hand-crafted mercurial snapshot of octave. > > Uploading a snapshot was made necessary because the previous official > > release > > (6.1.0) had serious bugs, which were fixed in the mercurial repository. > > > > Since then, a new official upstream bugfix release has been made (6.2.0). > > For > > various reasons, it would be better to ship an official release in bullseye, > > hence this request. > > > > The debdiff is attached. I have filtered out all unrelevant stuff (copyright > > header changes, regenerated files). > > What you showed looks OK. Under the assumption that the upload happens > in the next week or so, go ahead. Thanks, I have made the upload. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#933946: Request for review / upload for libtest-fitesque-rdf-perl
I have marked this package 'unstable' to signify that I believe it is ready to upload. Regards -- Ken Ibbotson E: k...@computer.org *"Reality is merely an illusion, albeit a very persistent one."* - Albert Einstein (1879-1955)
Bug#984853: elinks: compile with ECMAScript support
Package: elinks Version: 0.13.2-1+b1 Severity: wishlist Please compile the package with Javascript support -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 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 elinks depends on: ii elinks-data 0.13.2-1 ii libbz2-1.01.0.8-4 ii libc6 2.31-9 ii libev41:4.33-1 ii libexpat1 2.2.10-2 ii libfsplib00.14-5 ii libgcrypt20 1.8.7-3 ii libgnutls30 3.7.0-7 ii libgpm2 1.20.7-8 ii libgssapi-krb5-2 1.18.3-4 ii libidn11 1.33-3 ii liblua5.1-0 5.1.5-8.1+b3 ii liblzma5 5.2.5-1.0 ii libperl5.32 5.32.1-3 ii libtinfo6 6.2+20201114-2 ii libtre5 0.8.0-6+b1 elinks recommends no packages. Versions of packages elinks suggests: pn elinks-doc -- no debconf information
Bug#984851: O: qalculate-gtk -- Powerful and easy to use desktop calculator
Package: wnpp Severity: normal I haven't been able to work on qalculate-gtk for way too long, my apologies for that, I'm orphaning the package. It should probably be updated with libqalculate. Thanks, Vincent
Bug#984850: O: libqalculate -- Powerful and easy to use desktop calculator
Package: wnpp Severity: normal I haven't been able to work on libqalculate for way too long, my apologies for that, I'm orphaning the package. It should probably be updated with qalculate-gtk. Thanks, Vincent
Bug#984849: dpkg-divert: too sensitive to order of command-line args
Package: dpkg Version: 1.20.7.1 Severity: wishlist X-Debbugs-Cc: rvandegr...@debian.org dpkg-divert is too sensitive to the order of the command line parameters. Since I only use it rarely, I almost always run into: # dpkg-divert --add /wooo --divert /yeah --rename dpkg-divert: warning: please specify --no-rename explicitly, the default will change to --rename in 1.20.x dpkg-divert: error: --add needs a single argument Use --help for help about diverting files. The fix is to move --add last. But neither the error nor the manpage makes that clear. Ross -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (40, 'unstable'), (30, 'experimental'), (1, 'experimental-debug') 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 dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-9 ii liblzma5 5.2.5-1.0 ii libselinux1 3.1-3 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.2.0 pn debsig-verify -- no debconf information
Bug#979010: libqalculate20: crashes cantor due to symbol conflict with poppler
Hi, On Mon, Jan 4, 2021, at 1:53 PM, Norbert Preining wrote: > I would have been nice to get the latest qalculate into Debian, but so > close to initial freeze I don't feel really comfortable doing this. > Do you have any opinion on that? > There are not that many rdepends, actually only the gtk frontend and > cantor, as far as I see. Sorry for the late answer. Yes, it'd have been better to get the latest version of both libqalculate and qalculate-gtk. Unfortunately, I haven't been able to work on them for way too long, my apologies for that. I'll orphan the packages because it won't likely change soon. Yes, there are only a couple of rdepends, and migration wasn't too painful the few times I did it. Thanks, Vincent
Bug#984497: another fast-moving project
On Mon, Mar 08, 2021 at 07:59:37AM -0800, Dima Kogan wrote: > This particular project is fast-moving, so users of the package would at > best have a functional-yet-old version, and may think the software > sucks. *I* don't agree, and *I* think working with and using a distro is > still worth it. But this upstream made their preferences clear, and I > think we should respect them. so like https://tracker.debian.org/pkg/firefox unlike https://tracker.debian.org/pkg/firefox-esr Groeten Geert Stappers -- Silence is hard to parse
Bug#984848: extrepo: default config uses broken url
Package: extrepo Version: 0.8 Severity: normal Hello, I tried extrepo, but ran into an error: $ sudo extrepo enable google_chrome Could not download index YAML file: 403 Forbidden file type or location at /usr/share/perl5/Debian/ExtRepo/Data.pm line 27. ...propagated at /usr/bin/extrepo line 123. After some troubleshooting, I found that the salsa pages url seems to require https. s/http/https in config.yaml gets things working. Ross -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (40, 'unstable'), (30, 'experimental'), (1, 'experimental-debug') 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 extrepo depends on: ii gpgv 2.2.27-1 ii libcryptx-perl0.069-1+b1 ii libdpkg-perl 1.20.7.1 ii libwww-perl 6.52-1 ii libyaml-libyaml-perl 0.82+repack-1+b1 ii perl 5.32.1-2 extrepo recommends no packages. extrepo suggests no packages. -- Configuration Files: /etc/extrepo/config.yaml changed [not included] -- no debconf information
Bug#982682: ansible: some syntax errors appear in the installation
I can confirm I can reproduce this bug. Had the same error message while upgrading to ansible 2.10.7-1 on a sid machine. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#984847: ITP: ppmd -- PPMd compression/decompression library
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-pyt...@lists.debian.org Owner: Sandro Tosi * Package name: ppmd Version : 0.3.3 Upstream Author : miur...@linux.com * URL : https://github.com/miurahr/ppmd * License : LGPLv2+ Programming Lang: Python Description : PPMd compression/decompression library Binary package names: python3-ppmd PPM(Prediction by partial matching) is a compression algorithm which has several variations of implementations. PPMd is the implementation by Dmitry Shkarin. It is used in the RAR and by 7-Zip as one of several possible methods. . ppmd, aka. ppmd-cffi, is a python bindings with PPMd implementation by C language. The C codes are derived from p7zip, portable 7-zip implementation. ppmd-cffi support PPMd ver.H and PPMd ver.I. this is a new dependency of py7zr
Bug#983595: linux-image-5.10.0-3-amd64: [regression] Kernel panic on resume from sleep
Control: tags -1 + pending Hi, On Sat, Mar 06, 2021 at 08:18:52PM +0100, Zbynek Michl wrote: > So really it was a bug in the alx driver - there was a wrong call order on > resume. > > Jakub Kicinski has fixed it in the vanilla kernel: > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=a4dcfbc4ee2218abd567d81d795082d8d4afcdf6 > > More details are available in the kernel mailing list: > https://lore.kernel.org/netdev/CAJH0kmw00RHaKXqxRFi-7aSj2waYaMBYpp3v1fnC-=237be...@mail.gmail.com/T/#t > > This bug report can be closed now. Not directly, as the change is not yet in our upload. I cherry-picked the commit for the next upload as https://salsa.debian.org/kernel-team/linux/-/commit/3f06579cf51c653d71722c8bb742450798455089 . Regards, Salvatore
Bug#984846: netcfg: Default hostname hardcoded in netcfg-common
Package: netcfg Severity: normal Tags: d-i User: de...@kali.org Usertags: origin-kali Dear Maintainer, the default hostname "debian" is hardcoded in two places in the file netcfg-common.c: https://salsa.debian.org/installer-team/netcfg/-/blob/master/netcfg-common.c#L1043 https://salsa.debian.org/installer-team/netcfg/-/blob/master/netcfg-common.c#L1069 This was reported in the Kali Linux bugtracker [1]. For Kali, we set the default hostname to 'kali' in the file 'debian/netcfg-common.templates', key 'netcfg/get_hostname', so that the installer proposes it as the default hostname. It works well, however one of our user noticed that if they enter an invalid hostname, the default hostname is set back to 'debian' (since it's hardcoded in netcfg-common.c). It would be nice if instead it would default to the value that is set in 'netcfg/get_hostname'. However I'm nost sure how to achieve that, as I'm not familiar with the netcfg code at all, and it's not clear if we can still get this value at this moment in the code, or if it has been overwritten by the user's input. Cheers, Arnaud [1] https://bugs.kali.org/view.php?id=7070
Bug#984845: sofia-sip: reproducible builds: Embeds build path in binaries
Source: sofia-sip Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The build path is embedded through various uses of __FILE__ in the sofia-sip code. The attached patch fixes this by setting CFLAGS in debian/rules using dpkg-buildflags, which passes the -ffile-prefix-map argument in recent versions of dpkg. Alternately, upgrading to a recent debhelper compat level and dh would also probably fix this issue. Unfortunately, this patch does not resolve all reproducibility issues in sofia-sip, but the arch:any packages should be fixed by this change, leaving only sofia-sip-doc unreproducible. Applying the patch may also make the diffoscope output more reliable, as it frequently times out comparing builds from unstable: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/sofia-sip.html Thanks for maintaining sofia-sip! live well, vagrant From f4dbfb48ebf6e51af19102aa58bc27b3e59153be Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Tue, 9 Mar 2021 03:47:11 + Subject: [PATCH] debian/rules: Set CFLAGS with dpkg-buildflags. --- debian/rules | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/rules b/debian/rules index a3bf4ce..75a9cc2 100755 --- a/debian/rules +++ b/debian/rules @@ -8,6 +8,8 @@ NUM_CPUS = $(shell getconf _NPROCESSORS_ONLN 2>/dev/null) PARALLEL = $(subst parallel=,,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NJOBS= -j$(or $(PARALLEL),$(NUM_CPUS),1) +export CFLAGS=$(shell dpkg-buildflags --get CFLAGS) + DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) -- 2.20.1 signature.asc Description: PGP signature
Bug#946645: tmux is killed under gnome3 regardless of KillUserProcesses=no
I have similar observations to chrysn after starting and detaching a tmux session with KillUserProcesses=no (the default): 1. If I do the process in Gnome-3 using gnome-terminal and I log out, wait for a bit and log in (60 seconds is what I used), the detached tmux session is gone. 2. If I do the process in Gnome-3 using gnome-terminal and I log out, and log back in immediately, the tmux session usually survives. 3. If I Gnome-3 using gnome-terminal I run "loginctl enable-linger", do the process above and log out and in, tmux session always survives. 4. If started on a virtual console (crtl-alt-f3), and log out it survives regardless of how long I want before logging in again, and regardless of how many Gnome3 sessions are started and stopped on the same machine. I guess a workaround would be to globally set "loginctl enable-linger" for all logins but if there is such a setting I can't find it. (I thought KillUserProcess=no was that setting, apparently not, but I'm guessing that's because it isn't systemd doing this.) Alternatively if someone can tell me how get Wayland version of KDE to run ... OpenPGP_0xF5231C62E7843A8C.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Bug#980364: sudo: segfault when /var/lib/sudo/lectured not writable
Hi Marc, > Is it ok for you if I close this bug? Sure. > > Most likely unrelated, but one thing I did notice when checking the > > code is that sudo_mkdir_parents might UB if path is an empty string, > > since it first does "char *slash = path; strchr (slash + 1, '/');". > > > > Now I don't know if it's actually possible that it's called with an > > empty string, so it might not be an actual bug, but since I see it's > > coded very defensively overall, an empty string check here might not > > hurt. > > Would it be ok for you to file an issue in upstream's bugzilla? Or would > it be more comforable for you if I took this issue upstream? It is > generally more useful when the bug reporter has a direct communications > link to upstream in such cases. I'd prefer if you do it. I don't really have anything more to say about it, nor any kind of test case. (As I said, it may not even be a bug, just a matter of defensive programming.) Greetings, Frank
Bug#984844: bluez-firmware: 2.4 GHz WiFi is interfered by bluetooth on RPi4B
Package: bluez-firmware Version: 1.2-4 Severity: important Tags: upstream fixed-upstream sid bullseye X-Debbugs-Cc: debian-...@lists.debian.org Control: forwarded -1 https://github.com/RPi-Distro/firmware-nonfree/issues/8 Dear Maintainer, I have installed bluetooth 5.55-3 bluez 5.55-3 bluez-firmware 1.2-4 When I block bluetooth by /usr/sbin/rfkill, 2.4 GHz WiFi on Raspberry Pi 4 seems to work, at least ping packets can reach to machines on the same LAN. On the other hand, when I unblock bluetooth by /usr/sbin/rfkill, 2.4GHz WiFi does not work well. Connection by SSID is established, but no ping packet reach to machines on the same LAN. This seems fixed at https://github.com/RPi-Distro/firmware-nonfree/issues/8 Linux kernel is Debian linux-image-5.10.0-4-rt-arm64 5.10.19-1 Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-4-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#984756: beep: Trying to Increase Volume of PC-Speaker with "beep"
On Sun, 07 Mar 2021 17:26:23 -0800 Chime Hart wrote: > Package: beep > Version: 1.4.9-1+b1 > Severity: wishlist > > Dear Maintainer, I am the upstream maintainer of "beep", and I neither maintain any Debian packages nor am I a Debian user unless you count my Rasberry Pi's Raspbian. > Whether I use "beep" or "setterm" neither have a way > of increasing the volume of the PC-Speaker. > Supposedly xset has such an option, but that may not work in a > console only setup. The PC speaker hardware as such has no notion of sound volume. It just produces a rectangular pulse with a given frequency, or no pulse at all. Therefore I doubt very much that xset In traditional PCs, that signal went to a small dynamic speaker, and since circa the years 2000..2010 to a piezo buzzer which takes less space and is less expensive. If you have a traditional PC with a dynamic speaker, you probably cannot do much about the audio volume "beep" produces. If you have a traditional PC with a piezo buzzer, you can indirectly change the audio volume "beep" produces by changing the beep *frequency* to a frequency close to the resonant frequency of the piezo buzzer. My PC's buzzer is loudest around 2100Hz. However, non-traditional PCs (such as the IBM Thinkpads family where I have had models from the mid-1990s to the mid-2000s) do not have that separate speaker and route the audio signal from the PC speaker hardware to a mixer circuit where the PC speaker audio is mixed together with the PCM audio, CD player audio, and whatever else there is and the sum is finally routed to the laptop speakers to produce audible sound. On such systems, you can change the volume settings of that mixer circuit using alsamixer, and then save the mixer setting to have that setting loaded on the next system boot. See https://github.com/spkr-beep/beep/issues/13 for another Debian user's bug report, where the Debian 10 user on a ThinkPad T440p describes how they solved their audio problem in the comment https://github.com/spkr-beep/beep/issues/13#issuecomment-637058344 I do not know how well alsamixer works with a screenreader. > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-2-amd64 (SMP w/2 CPU threads) > Kernel taint flags: TAINT_CRAP, 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 > /usr/bin/dash I run in tcsh with a screen-reader > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages beep depends on: > ii libc6 2.31-9 > > beep recommends no packages. > > beep suggests no packages. > > -- no debconf information > Thanks so much in advance for considering an addition.
Bug#984842: RFS: fbcat/0.5.1-1 [ITA] -- framebuffer grabber
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "fbcat": * Package name: fbcat Version : 0.5.1-1 Upstream Author : Piotr Lewandowski , * URL : https://jwilk.net/software/fbcat * License : GPL-2 * Vcs : https://salsa.debian.org/debian/fbcat Section : graphics It builds those binary packages: fbcat - framebuffer grabber To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fbcat/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fbcat/fbcat_0.5.1-1.dsc Changes since the last upload: fbcat (0.5.1-1) unstable; urgency=medium . * New upstream version 0.5.1 * New Maintainer (Closes: #565156) * Update homepage URL * Update debhelper to 10 * Update rules to build with newer compat version * Update watch to use upstream github * Update copyright dates and homepage * Fix gbp old-style config -- Micheal Waltz https://keybase.io/ecliptik GPG Fingerprint: 5F70 F2AC BD58 F580 DF15 3D1F 4FA2 70F5 CD36 71F9 signature.asc Description: PGP signature
Bug#984841: global.h: fix a typo, "MST" instead of "MSG"
Source: nn Version: 6.7.3-14 Severity: normal Tags: patch Dear Maintainer, >From dc5b130e6ffd04f81ce7c6006895734ed4cb77af Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Tue, 9 Mar 2021 01:26:53 + >Subject: [PATCH] global.h: fix a typo, "MST" instead of "MSG" Signed-off-by: Bjarni Ingi Gislason --- global.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/global.h b/global.h index 6a65c63..35c0d0b 100644 --- a/global.h +++ b/global.h @@ -15,7 +15,7 @@ */ /* Array delayed_msg[] */ -#define NDELAYED_MST 100 +#define NDELAYED_MSG 100 /* * Various constants and types -- 2.30.1 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- debconf information excluded -- Bjarni I. Gislason
Bug#984840: Some files: define a macro NDELAYED_MSG and use it for the size of the array "delayed_msg[]!
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From d66640fce092fd7cded61a4243e3ba2fa07abfbe Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Tue, 9 Mar 2021 00:43:16 +
>Subject: [PATCH] Some files: define a macro NDELAYED_MSG and use it for the
> size of the array "delayed_msg[]!
global.h: define NDELAYED_MSG as the size of the array delayed_msg[].
aux.c: use NDELAYED_MSG for the size of the array "delayed_msg[],
and use it instead of the variable "ndelayed_msg".
group.c: likewise
menu.c: likewise
more.c: likewise
Signed-off-by: Bjarni Ingi Gislason
---
aux.c| 14 +++---
global.h | 7 +++
group.c | 4 ++--
menu.c | 2 +-
more.c | 1 -
5 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/aux.c b/aux.c
index 9326195..47f1561 100644
--- a/aux.c
+++ b/aux.c
@@ -25,8 +25,8 @@
extern char*temp_file;
extern int novice;
-const size_tndelayed_msg = 100; /* size of array "delayed_msg[]" */
-chardelayed_msg[ndelayed_msg];
+/* NDELAYED_MSG defined in "global.h" */
+chardelayed_msg[NDELAYED_MSG];
extern char*pager;
extern char*inews_program;
extern int inews_pipe_input;
@@ -177,10 +177,10 @@ no_params:
*ap++ = NULL;
if (execute(SHELL, args, 1)) {
- snprintf(delayed_msg, ndelayed_msg, sent_fmt, " not");
+ snprintf(delayed_msg, NDELAYED_MSG, sent_fmt, " not");
return 1;
}
-snprintf(delayed_msg, ndelayed_msg, sent_fmt, "");
+snprintf(delayed_msg, NDELAYED_MSG, sent_fmt, "");
return 0;
}
@@ -461,14 +461,14 @@ aux_sh(article_header * ah, char *script, char *prog,
char *action, char *record
nn_raw();
if (stat(temp_file, ) < 0 || statb.st_size == 0) {
- snprintf(delayed_msg, ndelayed_msg, sent_fmt, " not");
+ snprintf(delayed_msg, NDELAYED_MSG, sent_fmt, " not");
unlink(temp_file);
unlink(copy);
return (22);
}
if (empty_answer_check) {
if (cmp_file(temp_file, copy) != 1) {
- snprintf(delayed_msg, ndelayed_msg, sent_fmt, " not");
+ snprintf(delayed_msg, NDELAYED_MSG, sent_fmt, " not");
unlink(temp_file);
unlink(copy);
return (22);
@@ -722,7 +722,7 @@ aux.c:...: warning: the address of 'fname' will always
evaluate as 'true'
unlink(temp_file);
unlink(copy);
unlink(final);
-snprintf(delayed_msg, ndelayed_msg, sent_fmt, "");
+snprintf(delayed_msg, NDELAYED_MSG, sent_fmt, "");
return (0);
}
diff --git a/global.h b/global.h
index 9f75975..6a65c63 100644
--- a/global.h
+++ b/global.h
@@ -10,6 +10,13 @@
#include
+/*
+ * Constants for the size of arrays, that are used in more than on file
+ */
+
+/* Array delayed_msg[] */
+#define NDELAYED_MST 100
+
/*
* Various constants and types
*/
diff --git a/group.c b/group.c
index 44fd67f..aa533c4 100644
--- a/group.c
+++ b/group.c
@@ -53,7 +53,7 @@ extern int killed_articles;
extern int seq_cross_filtering;
extern char*default_save_file, *folder_save_file;
-extern const size_t ndelayed_msg;
+/* NDELAYED_MSG defined in "global.h"; size of array delayed_msg[] */
extern char delayed_msg[];
extern int32db_read_counter;
@@ -1164,7 +1164,7 @@ merge_and_read(flag_type access_mode, char *mask)
current_group = _group;
kb = (kb + 1023) >> 10;
-snprintf(delayed_msg, ndelayed_msg, "Read %ld articles in %ld seconds (%ld
kbyte/s)",
+snprintf(delayed_msg, NDELAYED_MSG, "Read %ld articles in %ld seconds (%ld
kbyte/s)",
(long) db_read_counter, (long) t2, t2 > 0 ? kb / t2 : kb);
menu(merged_header);
diff --git a/menu.c b/menu.c
index 90462c4..0e827e0 100644
--- a/menu.c
+++ b/menu.c
@@ -95,7 +95,7 @@ int auto_select_subject = 0; /* auto select
articles with
int auto_read_limit = 0; /* ignore auto_read_mode if less
* articles */
-extern const size_t NDELAYED_MSG;
+/* NDELAYED_MSG defined in global.h; size of array delayed_msg */
extern char delayed_msg[]; /* give to msg() after redraw */
int flush_typeahead = 0;
diff --git a/more.c b/more.c
index 843ead0..ab1bbc0 100644
--- a/more.c
+++ b/more.c
@@ -74,7 +74,6 @@ extern int mouse_state;
extern int alt_cmd_key, in_menu_mode, any_message;
extern long n_selected;
-extern const size_t ndelayed_msg; /* size of array "delayed_msg[]" */
extern char delayed_msg[];
static int rot13_must_init = 1;
--
2.30.1
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale:
Bug#984833: firefox: users locked out of continuing to use Flash plugin after EOL
Package: firefox Version: 85.0-1 Severity: normal Dear Maintainer, I hear that following the end of life of the Adobe Flash player at the end of 2020, Firefox, starting in version 85 released in January, now refuses to even load the Adobe Flash plugin at all, while explicitly and deliberately refraining from providing any configuration mechanism to control this behavior. This is problematic both in its consequences and as a behavior from a vendor. I find that Adobe was pretty responsible and diligent in their handling of the end of life of Flash. True, they did introduce a time bomb in their software, which is very much an offensive practice; but they announced their plans years in advance, coordinated with everyone, and more importantly, they provided and publicized several mechanisms to empower end users to work around this. For one, they provided an officially documented configuration mechanism to manage the end of life of the Flash player, both before and after the date it disabled itself. See their administration guide, chapter 4, "Administration": https://www.adobe.com/content/dam/acom/en/devnet/flashplayer/articles/flash_player_admin_guide/pdf/latest/flash_player_32_0_admin_guide.pdf#page=33 They also provided an official standalone Flash player application, which I hear, unlike the Flash plugin, was not affected by the time bomb: https://www.adobe.com/support/flashplayer/debug_downloads.html I haven't tried any standalone player, but using the documented configuration settings, I was able to restore Flash plugin functionality, after January 12, 2021 when it disabled itself, in several web browsers (including Firefox 84). Now keep in mind that this is coming from Adobe, a commercial company publishing closed-source, proprietary software. To be clear about this, starting on January 12, 2021, web browsers would still load the Flash plugin into the web page or tab, but the Flash plugin would display a big inactive icon instead of running the content. After setting the right configuration, the Flash plugin would run the content again as before. However, later in January, major web browser vendors rolled out new versions that disabled the Flash plugin at their own level, especially stating they provided no mechanism to reenable it. In Firefox 85, contrary to Firefox 84, the Flash plugin is not even listed anymore in about:plugins. It appears like there is some explicit rule to refuse to even load the Flash plugin. The Flash plugin doesn't load in pages or tabs where it is required, and the Flash configuration mentioned above to allow content to run in the plugin again can't change anything to that. Providing no mechanism to manage this runs counter to the direction, decision, and standards set by Adobe for the end of life of their own product. And it disenfranchises end users. Mozilla has no standing to enforce Adobe Flash player's end of life this way, especially not as a champion of not only free and open source software, but also of end users' empowerment and online freedoms and rights, as they reaffirm in their manifesto. This is hardly acceptable offensive behavior, especially in the form it takes. Not only does this endorse Adobe's time bomb, but with automatic Firefox updates to the newest version (e.g. on Windows), this is remote tampering to lock the end user out of a feature before they can even get a say in it - this is actually what happened to me before I could understand it, when investigating the issue after noticing it in another browser first. This is artificial feature lockout from a vendor - in free software. And Adobe Flash reached its final version so it's not like already existing support would require any future work to adapt to new Flash developments. I envision Debian as better than that. Thus I request the possibility in Debian to keep running the Adobe Flash plugin in Firefox, at the user's discretion. Perhaps with a configuration setting to make Firefox load the plugin again. Or if there could be a hack to apply on the local plugin installation, I'd be willing to hear about it. Either way, this wouldn't be the first time that Debian disagrees with Mozilla or restores support for a feature dropped by them in Firefox, and these are reasons I've appreciated your maintainership of the firefox packages for all these years. This is not just a political problem, this can be very real and practical. My Internet service provider offers an IPTV service as one main component of their plans, and one way to access it from home computers is through a web page hosted on their proprietary CPE router. Unfortunately, it requires Flash to play the video streams, as my ISP never converted it to HTML 5, even despite having years to do so and my CPE still being a supported product. This IPTV feature now doesn't work anymore; see https://dev.freebox.fr/bugs/task/22560 I've tried to hack around to the direct stream, but to no avail. This is a web page that mixes HTML and JavaScript
Bug#984546: cpl-plugin-hawki-calib: move downloader package to contrib
Hello, On Mon 08 Mar 2021 at 04:55PM -07, Sean Whitton wrote: > On Thu 04 Mar 2021 at 09:00PM +01, Andreas Beckmann wrote: > >> cpl-plugin-hawki-calib is a downloader package and needs to be moved to >> contrib. All other cpl-plugin-*-calib packages are already in contrib. > > I just reached this package during NEW processing. Could we get a > release team ACK on letting this into unstable at the current stage of > the freeze, please? ACKed by ivodd in #debian-release. -- Sean Whitton signature.asc Description: PGP signature
Bug#984839: nntp.c: Use strchr() instead of index(); add feature_test_macros
Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch
Dear Maintainer,
>From 4acca3d0ca72bb50c0fedbff1a59d49872789958 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason
>Date: Mon, 8 Mar 2021 23:06:25 +
>Subject: [PATCH] nntp.c: Use strchr() instead of index(); add
> feature_test_macros
Add a feature_test_macros for "fdopen(3)", "mkstemp(3)", and
"strchr(3)".
Add the header file for "strchr(3)".
Add a prototype for "get_group_line()".
Move the prototype for "server_port()" from the function
"find_server()" to the prototype section at top of the file.
Use "strchr()" instead of "index()", see "man 3 index".
Signed-off-by: Bjarni Ingi Gislason
---
nntp.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/nntp.c b/nntp.c
index 43093b8..54785e8 100644
--- a/nntp.c
+++ b/nntp.c
@@ -13,10 +13,23 @@
* any mistakes are mine :-) ++Kim
*/
+/* feature_test_macros(7) for "fdopen()" and "mkstemp()" */
+#ifndef _POSIX_C_SOURCE
+#define _POSIX_C_SOURCE 200809L
+#endif
+
+/* feature_test_macros(7) for strchr(3) */
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+
+
+
#include
#include
#include
#include
+#include
#include
#include
#include "config.h"
@@ -80,6 +93,7 @@ static int reconnect_server(int);
static int connect_server(void);
static void debug_msg(char *prefix, char *str);
static void find_server(void);
+intget_group_line(const char *, char *, size_t);
static int get_server_line(char *string, int size);
static int get_server(char *string, int size);
static int get_socket(void);
@@ -88,6 +102,7 @@ static int copy_text(register FILE * fp);
static struct cache *search_cache(article_number art, group_header * gh);
static struct cache *new_cache_slot(void);
static void clean_cache(void);
+void server_port(char *);
static void set_domain(void);
static void nntp_doauth(void);
@@ -210,7 +225,7 @@ find_server(void)
char *cp, *name;
charbuf[BUFSIZ];
FILE *fp;
-void server_port(char *);
+
/*
* This feature cannot normally be enabled, because the database and the
@@ -896,7 +911,7 @@ set_domain(void)
strncpy(domain, DOMAIN, MAXHOSTNAMELEN);
#else
strcpy(domain, host_name);
-cp = index(domain, '.');
+cp = strchr(domain, '.');
if (cp == NULL) {
strcat(domain, ".");
strncat(domain, DOMAIN, MAXHOSTNAMELEN - sizeof(host_name) - 1);
@@ -907,7 +922,7 @@ set_domain(void)
domain[0] = '\0';
-cp = index(host_name, '.');
+cp = strchr(host_name, '.');
if (cp == NULL) {
FILE *resolv;
@@ -1683,8 +1698,8 @@ valid_header(register char *h)
* just check for initial letter, colon, and space to make sure we
* discard only invalid headers
*/
-colon = index(h, ':');
-space = index(h, ' ');
+colon = strchr(h, ':');
+space = strchr(h, ' ');
if (isalpha(h[0]) && colon && space == colon + 1)
return (1);
--
2.30.1
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
-- debconf information excluded
--
Bjarni I. Gislason
Bug#984546: cpl-plugin-hawki-calib: move downloader package to contrib
Hello, On Thu 04 Mar 2021 at 09:00PM +01, Andreas Beckmann wrote: > cpl-plugin-hawki-calib is a downloader package and needs to be moved to > contrib. All other cpl-plugin-*-calib packages are already in contrib. I just reached this package during NEW processing. Could we get a release team ACK on letting this into unstable at the current stage of the freeze, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#984838: libboost1.74-dev: depends on libstdc++-dev provided by multiple packages
Package: libboost1.74-dev
Version: 1.74.0-8
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts
libstdc++-dev is not a good virtual package to depend upon, since it is
provided by multiple packages:
bullseye# apt-get install libstdc++-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package libstdc++-dev is a virtual package provided by:
libstdc++-9-dev 9.3.0-22
libstdc++-10-dev 10.2.1-6
You should explicitly select one to install.
E: Package 'libstdc++-dev' has no installation candidate
If apt has to choose, it may select the wrong one:
bullseye# apt-get install libboost1.74-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
libstdc++-9-dev
Suggested packages:
libboost1.74-doc libboost-atomic1.74-dev libboost-chrono1.74-dev
libboost-container1.74-dev libboost-context1.74-dev libboost-contract1.74-dev
libboost-coroutine1.74-dev libboost-date-time1.74-dev
libboost-exception1.74-dev libboost-fiber1.74-dev
libboost-filesystem1.74-dev libboost-graph1.74-dev
libboost-graph-parallel1.74-dev libboost-iostreams1.74-dev
libboost-locale1.74-dev libboost-log1.74-dev libboost-math1.74-dev
libboost-mpi1.74-dev libboost-mpi-python1.74-dev libboost-numpy1.74-dev
libboost-program-options1.74-dev libboost-python1.74-dev
libboost-random1.74-dev libboost-regex1.74-dev libboost-serialization1.74-dev
libboost-stacktrace1.74-dev libboost-system1.74-dev libboost-test1.74-dev
libboost-thread1.74-dev libboost-timer1.74-dev
libboost-type-erasure1.74-dev libboost-wave1.74-dev libboost1.74-tools-dev
libmpfrc++-dev libntl-dev libboost-nowide1.74-dev libstdc++-9-doc
The following NEW packages will be installed:
libboost1.74-dev libstdc++-9-dev
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/11.2 MB of archives.
After this operation, 159 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
But worse, on upgrades from buster to bullseye libstdc++-8-dev would
have to be removed and libstdc++-10-dev would have to be installed to
perform a clean upgrade, but I've found with piuparts a few upgrade
paths where apt prefers to keep libstdc++-8-dev installed since it
provides libstdc++-dev. That causes the upgrade to fail, since apt
cannot find a valid upgrade path at al in these cases.
The attached patch exchanges this dependency to
Upgrading to the packages with this patch applied fixes all the issues I
observed. I also tried a
Depends: libstdc++-10-dev | libstdc++-dev
but that leaves us with the failure I initially observed
Andreas
diff -Nru boost1.74-1.74.0/debian/changelog boost1.74-1.74.0/debian/changelog
--- boost1.74-1.74.0/debian/changelog 2021-01-23 20:00:18.0 +0100
+++ boost1.74-1.74.0/debian/changelog 2021-03-08 16:18:55.0 +0100
@@ -1,3 +1,13 @@
+boost1.74 (1.74.0-8.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * libboost1.74-dev: Smoothen upgrades from buster by depending on
+libstdc++-${gxx:major}-dev using the build-time version of g++ instead of
+the virtual libstdc++-dev provided by multiple packages.
+(Closes: #xx)
+
+ -- Andreas Beckmann Mon, 08 Mar 2021 16:18:55 +0100
+
boost1.74 (1.74.0-8) unstable; urgency=medium
* [85a2610] Fix compilation warnings. (Closes: #980497)
diff -Nru boost1.74-1.74.0/debian/control boost1.74-1.74.0/debian/control
--- boost1.74-1.74.0/debian/control 2021-01-23 19:37:38.0 +0100
+++ boost1.74-1.74.0/debian/control 2021-03-08 16:18:55.0 +0100
@@ -24,7 +24,7 @@
Architecture: any
Multi-Arch: same
Section: libdevel
-Depends: ${misc:Depends}, ${shlibs:Depends}, libstdc++-dev
+Depends: ${misc:Depends}, ${shlibs:Depends}, libstdc++-${gxx:major}-dev
Suggests: libboost1.74-doc,
libboost-atomic1.74-dev,
libboost-chrono1.74-dev,
diff -Nru boost1.74-1.74.0/debian/rules boost1.74-1.74.0/debian/rules
--- boost1.74-1.74.0/debian/rules 2020-12-25 23:26:58.0 +0100
+++ boost1.74-1.74.0/debian/rules 2021-03-08 16:18:55.0 +0100
@@ -343,6 +343,9 @@
sed -i -r 's/^(libboost_numpy([0-9]{2}) \S+ (\S+).*)$$/\1, \3-py\2/'
debian/libboost-numpy$(SOVERSION)/DEBIAN/shlibs
endif
+override_dh_gencontrol:
+ dh_gencontrol -- -V'gxx:major=$(shell dpkg-query -f '$${version}' -W
g++ | sed 's/.*://;s/\..*//')'
+
$(b2):
cd tools/build && bison -y -d -o src/engine/jamgram.cpp
src/engine/jamgram.y
./bootstrap.sh --with-icu=/usr --prefix=$(CURDIR)/debian/tmp/usr \
libkf5mailcommon-dev_4:20.08.3-1.log.gz
Description: application/gzip
Bug#984828: gitlab: code tree not rendered (circling circle instead)
Package: gitlab Version: 13.7.8+ds1-1~fto10+1 Severity: serious Hi Praveen, here comes the other issue I am facing. Occurred with 13.7.7 and also occurs with 13.7.8: When I open a Git repository on my GitLab instance, I see a circling circle where the code files/dirs should actually be. The JS console provides four error messages: 1. Uncaught TypeError: o.a.fn.tooltip is undefined (with a backtrace I omit here for now). 2. Source-Map-Fehler: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data Ressourcen-Adresse: https://gitlab.das-netzwerkteam.de/assets/webpack/runtime.2cbada1d.bundle.js Source-Map-Adresse: runtime.2cbada1d.bundle.js.map 3. Source-Map-Fehler: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data Ressourcen-Adresse: https://gitlab.das-netzwerkteam.de/assets/webpack/pages.projects.show.7aaabbab.chunk.js Source-Map-Adresse: pages.projects.show.7aaabbab.chunk.js.map 4. Source-Map-Fehler: Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data Ressourcen-Adresse: https://gitlab.das-netzwerkteam.de/assets/webpack/pages.projects.show.7aaabbab.chunk.js Source-Map-Adresse: pages.projects.show.7aaabbab.chunk.js.map Any clue where else to look for error or log messages that might help to track down this issue? I can push / pull to / from my GitLab server via the git command, only the rendering of code trees (and possibly other Javascript dependent functionalities) seem(s) to be broken. 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 pgpda4q5oHgIc.pgp Description: Digitale PGP-Signatur
Bug#984837: unblock: gsoap/2.8.104-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I have submitted an update for the gsoap package, back-porting several
fixes for CVEs from upstream. It fixes the RC bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983596
Due to the current soft freeze, the migration delay is 10 days, which
would mean 18 March. However the hard freeze starts March 12, after
which migration requires an explicit unblock. Hence this unblock
request.
Due to the RC bug, the package is marked for auto-removal, together
with many packages that depend on it:
Marked for autoremoval on 11 April: #983596 high
Version 2.8.104-2 of gsoap is marked for autoremoval from testing on
Sun 11 Apr 2021. It is affected by #983596. The removal of gsoap will
also cause the removal of (transitive) reverse dependencies: arc-gui-
clients, cgsi-gsoap, davix, gfal2, gridsite, lcas-lcmaps-gt4-interface,
lcmaps, lcmaps-plugins-basic, lcmaps-plugins-jobrep, lcmaps-plugins-
verify-proxy, lcmaps-plugins-voms, myproxy, nordugrid-arc, nordugrid-
arc-nagios-plugins, openstack-cluster-installer, srm-ifce, voms, voms-
mysql-plugin, xrootd. You should try to prevent the removal by fixing
these RC bugs.
I hope you will consider unblocking the update.
Debdiff attached.
Mattias
diff -Nru gsoap-2.8.104/debian/changelog gsoap-2.8.104/debian/changelog
--- gsoap-2.8.104/debian/changelog 2020-07-25 08:30:12.0 +0200
+++ gsoap-2.8.104/debian/changelog 2021-03-08 14:06:23.0 +0100
@@ -1,3 +1,12 @@
+gsoap (2.8.104-3) unstable; urgency=high
+
+ * Backporting upstream fixes (Closes: #983596)
+- Fixes CVE: CVE-2020-13574 CVE-2020-13575 CVE-2020-13577 CVE-2020-13578
+- Fixes CVE: CVE-2020-13576
+ * Urgency high due to fixing RC bug
+
+ -- Mattias Ellert Mon, 08 Mar 2021 14:06:23 +0100
+
gsoap (2.8.104-2) unstable; urgency=medium
* Re-upload source only
diff -Nru gsoap-2.8.104/debian/control gsoap-2.8.104/debian/control
--- gsoap-2.8.104/debian/control 2020-07-22 15:23:55.0 +0200
+++ gsoap-2.8.104/debian/control 2021-03-08 14:06:23.0 +0100
@@ -13,7 +13,7 @@
Build-Depends-Indep:
doxygen,
graphviz
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
Section: devel
Vcs-Browser: https://salsa.debian.org/ellert/gsoap
Vcs-Git: https://salsa.debian.org/ellert/gsoap.git
diff -Nru gsoap-2.8.104/debian/copyright gsoap-2.8.104/debian/copyright
--- gsoap-2.8.104/debian/copyright 2020-07-22 15:23:55.0 +0200
+++ gsoap-2.8.104/debian/copyright 2021-03-08 14:06:23.0 +0100
@@ -171,7 +171,7 @@
Files: debian/*
Copyright:
2003-2007, Thomas Wana
- 2011-2020, Mattias Ellert
+ 2011-2021, Mattias Ellert
License: GPL-2+
On Debian systems, the complete text of the GPL version 2 license can be
found in '/usr/share/common-licenses/GPL-2'.
diff -Nru gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch
--- gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch 1970-01-01 01:00:00.0 +0100
+++ gsoap-2.8.104/debian/patches/gsoap-plugins-hardening.patch 2021-03-08 11:28:34.0 +0100
@@ -0,0 +1,336 @@
+diff -ur gsoap2-code-r191/gsoap/plugin/httpda.c gsoap2-code-r192/gsoap/plugin/httpda.c
+--- gsoap2-code-r191/gsoap/plugin/httpda.c 2020-06-30 21:06:47.0 +0200
gsoap2-code-r192/gsoap/plugin/httpda.c 2020-11-19 19:29:25.0 +0100
+@@ -1460,7 +1460,7 @@
+ MUTEX_LOCK(http_da_session_lock);
+
+ for (session = http_da_session; session; session = session->next)
+-if (!strcmp(session->realm, realm) && !strcmp(session->nonce, nonce) && !strcmp(session->opaque, opaque))
++if (session->realm && session->nonce && session->opaque && !strcmp(session->realm, realm) && !strcmp(session->nonce, nonce) && !strcmp(session->opaque, opaque))
+ break;
+
+ if (session)
+diff -ur gsoap2-code-r191/gsoap/plugin/wsaapi.c gsoap2-code-r192/gsoap/plugin/wsaapi.c
+--- gsoap2-code-r191/gsoap/plugin/wsaapi.c 2020-06-30 21:06:47.0 +0200
gsoap2-code-r192/gsoap/plugin/wsaapi.c 2020-11-19 19:29:25.0 +0100
+@@ -1056,7 +1056,7 @@
+ oldheader->SOAP_WSA(FaultTo)->Address = oldheader->SOAP_WSA(ReplyTo)->Address;
+ }
+ /* use FaultTo */
+- if (oldheader && oldheader->SOAP_WSA(FaultTo) && !strcmp(oldheader->SOAP_WSA(FaultTo)->Address, soap_wsa_noneURI))
++ if (oldheader && oldheader->SOAP_WSA(FaultTo) && oldheader->SOAP_WSA(FaultTo)->Address && !strcmp(oldheader->SOAP_WSA(FaultTo)->Address, soap_wsa_noneURI))
+ return soap_send_empty_response(soap, SOAP_OK); /* HTTP ACCEPTED */
+ soap->header = NULL;
+ /* allocate a new header */
+diff -ur gsoap2-code-r191/gsoap/plugin/wsseapi.c gsoap2-code-r192/gsoap/plugin/wsseapi.c
+--- gsoap2-code-r191/gsoap/plugin/wsseapi.c 2020-10-16 23:01:09.0 +0200
gsoap2-code-r192/gsoap/plugin/wsseapi.c 2020-11-19 19:29:25.0 +0100
+@@ -2957,7 +2957,7 @@
+ else
+ {
+ /* check
Bug#983071: unblock: xz-utils/5.2.5-1.1
On 2021-03-08 18:54:22 [+0100], Paul Gevers wrote: > Hi, Hi, > Please upload to unstable. As said, we'll let it age a bit there. Thanks, uploaded. > Paul Sebastian
Bug#984826: tigervnc-standalone-server: Unable to init server: Could not connect: Connection refused
Am 8. März 2021 23:30:11 MEZ schrieb Matthias Klein : >Am Mon, 8 Mar 2021 22:44:37 +0100 >schrieb Joachim Falk : > >> Hi Matthias, >> >> I tried to replicate the problem, but could start the mate desktop >> just fine. I will attache my configuration. I used > >Hi Joachim, > >Thanks a lot for your help! > >> Can you try to start something simpler to determine where exactly the >> problem is? Use something like: tigervncserver --localhost no >> --xstartup /usr/bin/xterm This should get you a VNC session running a >> simple xterm. > >The call tigervncserver --localhost no --xstartup /usr/bin/xterm >started an xterm and the MATE desktop in the background. > >After that I tried some variants in the ~/xstartup file. I got the >original content from the internet, and didn't really understand it. > >The following variant works: >unset SESSION_MANAGER >unset DBUS_SESSION_BUS_ADDRESS >/usr/bin/mate-session > >That means instead of "exec /usr/bin/mate-session &" I now use >"/usr/bin/mate-session" in the last line. > >Do you have any idea why the original call doesn't work anymore, and >what is the difference between the calls? > >Many greetings, >Matthias In 1.11, autokill is enabled on default. If autokill is enabled, then the Xtigervnc server is killed when the xstartup script terminates. If you use "/usr/bin/mate-session &", then the xstartup script will immediately terminates because the mate desktop is started in the background, that is what the & does. Removing the & will start the mate desktop in the foreground, which means the xstartup script will only terminate after you have logged out of the desktop. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Bug#984826: tigervnc-standalone-server: Unable to init server: Could not connect: Connection refused
Am Mon, 8 Mar 2021 22:44:37 +0100 schrieb Joachim Falk : > Hi Matthias, > > I tried to replicate the problem, but could start the mate desktop > just fine. I will attache my configuration. I used Hi Joachim, Thanks a lot for your help! > Can you try to start something simpler to determine where exactly the > problem is? Use something like: tigervncserver --localhost no > --xstartup /usr/bin/xterm This should get you a VNC session running a > simple xterm. The call tigervncserver --localhost no --xstartup /usr/bin/xterm started an xterm and the MATE desktop in the background. After that I tried some variants in the ~/xstartup file. I got the original content from the internet, and didn't really understand it. The following variant works: unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS /usr/bin/mate-session That means instead of "exec /usr/bin/mate-session &" I now use "/usr/bin/mate-session" in the last line. Do you have any idea why the original call doesn't work anymore, and what is the difference between the calls? Many greetings, Matthias
Bug#983918: buster-pu: package libbsd/0.9.1-2
I somehow missed that libbsd produces a udeb when I was processing
stable-new, so CCing KiBi and -boot now.
Regards,
Adam
On Wed, 2021-03-03 at 12:05 +0100, Gianfranco Costamagna wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: buster
> Severity: normal
>
> CVE-2019-20367 (no DSA) has been fixed for stretch in 0.8.3-1+deb9u1
> and
> for bullseye, sid with version 0.10.0-1
> Buster has been left out from the patches, and since the patch is
> trivial, I propose to apply it for buster too
>
>
> diff -Nru libbsd-0.9.1/debian/changelog libbsd-0.9.1/debian/changelog
> --- libbsd-0.9.1/debian/changelog 2019-02-25 01:33:03.0
> +0100
> +++ libbsd-0.9.1/debian/changelog 2021-03-03 12:03:12.0
> +0100
> @@ -1,3 +1,12 @@
> +libbsd (0.9.1-2+deb10u1) buster; urgency=medium
> +
> + * Non-maintainer upload.
> + * CVE-2019-20367
> +A non-NUL terminated symbol name in the string table might
> +result in a out-of-bounds read.
> +
> + -- Gianfranco Costamagna Wed, 03 Mar
> 2021 12:03:12 +0100
> +
> libbsd (0.9.1-2) unstable; urgency=medium
>
>* Perform a proper and correct /usr-merge transition by moving the
> package
> diff -Nru libbsd-0.9.1/debian/patches/CVE-2019-20367.patch libbsd-
> 0.9.1/debian/patches/CVE-2019-20367.patch
> --- libbsd-0.9.1/debian/patches/CVE-2019-20367.patch 1970-01-01
> 01:00:00.0 +0100
> +++ libbsd-0.9.1/debian/patches/CVE-2019-20367.patch 2021-03-03
> 12:00:40.0 +0100
> @@ -0,0 +1,42 @@
> +From 9d917aad37778a9f4a96ba358415f077f3f36f3b Mon Sep 17 00:00:00
> 2001
> +From: Guillem Jover
> +Date: Wed, 7 Aug 2019 22:58:30 +0200
> +Subject: [PATCH] nlist: Fix out-of-bounds read on strtab
> +
> +When doing a string comparison for a symbol name from the string
> table,
> +we should make sure we do a bounded comparison, otherwise a non-NUL
> +terminated string might make the code read out-of-bounds.
> +
> +Warned-by: coverity
> +---
> + src/nlist.c | 6 --
> + 1 file changed, 4 insertions(+), 2 deletions(-)
> +
> +diff --git a/src/nlist.c b/src/nlist.c
> +index 8aa46a2..228c220 100644
> +--- a/src/nlist.c
> b/src/nlist.c
> +@@ -227,16 +227,18 @@ __fdnlist(int fd, struct nlist *list)
> + symsize -= cc;
> + for (s = sbuf; cc > 0 && nent > 0; ++s, cc -=
> sizeof(*s)) {
> + char *name;
> ++Elf_Word size;
> + struct nlist *p;
> +
> + name = strtab + s->st_name;
> + if (name[0] == '\0')
> + continue;
> ++size = symstrsize - s->st_name;
> +
> + for (p = list; !ISLAST(p); p++) {
> + if ((p->n_un.n_name[0] == '_' &&
> +-strcmp(name, p->n_un.n_name+1) ==
> 0)
> +-|| strcmp(name, p->n_un.n_name) ==
> 0) {
> ++ strncmp(name, p->n_un.n_name+1,
> size) == 0) ||
> ++strncmp(name, p->n_un.n_name, size)
> == 0) {
> + elf_sym_to_nlist(p, s, shdr,
> + ehdr.e_shnum);
> + if (--nent <= 0)
> +--
> +GitLab
> +
> diff -Nru libbsd-0.9.1/debian/patches/series libbsd-
> 0.9.1/debian/patches/series
> --- libbsd-0.9.1/debian/patches/series1970-01-01
> 01:00:00.0 +0100
> +++ libbsd-0.9.1/debian/patches/series2021-03-03
> 12:01:48.0 +0100
> @@ -0,0 +1 @@
> +CVE-2019-20367.patch
Bug#973248: [Pkg-puppet-devel] Bug#973248: Deprecation warning in Ruby 2.7: $SAFE will become a normal global variable in Ruby 3.0
Hi, On 21-03-08 20:46:54, Thomas Goirand wrote: > The patch is super small and looks clean. I also am very annoyed by > this problem and would like it to be fixed. I'm not sure I can be the > voice of all of the team, but I would say: please go ahead with NMU + > dealing with the release team. Can someone else approve? Apollon > maybe? ACK from my side as well, please go ahead. Thanks for caring and dealing this. Cheers, Georg
Bug#984501: unblock: libqb/2.0.3-1
Control: tags -1 confirmed On 2021-03-04 11:59:35 +0100, Ferenc Wágner wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package libqb > > Dear Release Team, > > Upstream made a new minor release of libqb yesterday. Since a new > upload wouldn't migrate before the hard freeze with the current 10 day > delay, I'm asking for an unblock in advance. > > 2.0.3 contains a single new feature extending the API and ABI in a > backwards-compatible way with a message-id parameter, which isn't the > main reason for this request. > > Included are two doxygen2man fixes, one of them already present in the > current 2.0.2-1 package as a Debian patch, and another fixing a groff > error in libqb's own manual pages. > > The really interesting stuff is a memory safety fix in the internal > strlcpy() implementation and a more thorough cleanup procedure, which > avoids filling up /dev/shm with stale files in certain error and > recovery conditions. > > Locking errors (insufficient locking) are also fixed in the timer code, > and the unit tests are extended appropriately. > > The last fix corrects another unit test but entails no change in > behaviour. > > It would be possible to cherry pick the fix commits into Debian patches > leaving out the final one adding the new API, but I'd prefer the > cleaner solution of uploading 2.0.3 at this stage. The changes look ok. Under the assumption that the upload happens soon, please go ahead. Cheers > > debdiff against the package in testing: > > diff -Nru libqb-2.0.2/ChangeLog libqb-2.0.3/ChangeLog > --- libqb-2.0.2/ChangeLog 2020-12-03 14:07:32.0 +0100 > +++ libqb-2.0.3/ChangeLog 2021-03-03 09:34:26.0 +0100 > @@ -1,3 +1,57 @@ > +2021-03-03 Christine Caulfield > + > + release: bump library version for 2.0.3 release > + > +2021-03-01 Aleksei Burlakov > + root > + > + syslog: Add a message-id parameter for messages (#433) > + The message-id parameter will enable systemd catalogs. > + To enable message-id's the libqb should be configured with the > + --enable-systemd-journal option. > + > +2021-02-08 Chrissie Caulfield > + > + tests: Fix up resources.test (#435) > + resources.test has not checked the right filenames for a while. > + Fix this, and also make sure we don't count (but remove) the dlock > + test files. > + > + timers: Add some locking (#436) > + Fix several locking issues reported by helgrind > + > +2021-01-25 Chrissie Caulfield > + > + ipcc: Have a few goes at tidying up after a dead server (#434) > + This is an attempt to make sure that /dev/shm is cleaned up when a > + server exits unexpectedly. Normally it's the server's responsibility > + to tidy up sockets, but if it crashes or is killed with SIGKILL then > + the client (us) makes a reasonable attempt to tidy up the server sockets > + we have connected. The extra delay here just gives the server chance to > + disappear fully. As a client we can get here pretty quickly but shutting > + down a large server may take a little longer even when SIGKILLed. > + The 1/100th of a second is an arbitrary delay (of course) but seems to > + catch most servers in 2 tries or less. > + > +2021-01-13 Chrissie Caulfield > + > + strlcpy: Check for maxlen underflow (#432) > + * strlcpy: Check for maxlen underflow > + https://github.com/ClusterLabs/libqb/issues/429 > + * Always terminate the string if maxlen is > 0 > + > +2021-01-07 Chrissie Caulfield > + > + doxygen2man: fix printing of lines starting with '.' (#431) > + if a line starts with a '.' (eg the '...' in qbarray.h) then > + nroff thinks it's looking for a macro called '..'. > + The easiest solution is to add a dummy format at the start of the line > + (just adding \ seems not to work). > + > +2021-01-04 wferi > + > + doxygen2man: ignore all-whitespace brief descriptions (#430) > + > 2020-12-03 Christine Caulfield > > lib: Update library version for 2.0.2 release > diff -Nru libqb-2.0.2/configure libqb-2.0.3/configure > --- libqb-2.0.2/configure 2020-12-03 14:07:14.0 +0100 > +++ libqb-2.0.3/configure 2021-03-03 09:34:07.0 +0100 > @@ -1,6 +1,6 @@ > #! /bin/sh > # Guess values for system-dependent variables and create Makefiles. > -# Generated by GNU Autoconf 2.69 for libqb 2.0.2. > +# Generated by GNU Autoconf 2.69 for libqb 2.0.3. > # > # Report bugs to . > # > @@ -590,8 +590,8 @@ > # Identity of this package. > PACKAGE_NAME='libqb' > PACKAGE_TARNAME='libqb' > -PACKAGE_VERSION='2.0.2' > -PACKAGE_STRING='libqb 2.0.2' > +PACKAGE_VERSION='2.0.3' > +PACKAGE_STRING='libqb 2.0.3' > PACKAGE_BUGREPORT='develop...@clusterlabs.org' > PACKAGE_URL='' > > @@ -1426,7 +1426,7 @@ ># Omit some internal or obsolete options to make the list less imposing. ># This
Bug#984836: logiops: Plase also ship TESTED.md
Package: logiops Version: 0.2.2-1 Severity: normal X-Debbugs-Cc: n...@iname.com Dear Maintainer, README.md mentions TESTED.md, but that is missing from the documentation. Please ship that as well. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages logiops depends on: ii libc6 2.31-9 ii libconfig++9v5 1.5-0.4 ii libevdev2 1.11.0+dfsg-1 ii libgcc-s1 10.2.1-6 ii libstdc++6 10.2.1-6 ii libudev1247.3-2 logiops recommends no packages. logiops suggests no packages.
Bug#984826: tigervnc-standalone-server: Unable to init server: Could not connect: Connection refused
Hi Matthias, I tried to replicate the problem, but could start the mate desktop just fine. I will attache my configuration. I used apt install mate-core and used the default configuration in /etc/tigervnc. Moreover, I have [bash joachim@xerstin:~]$ ls -la ~/.vnc/ drwxrwxr-x 2 joachim joachimg 4096 8. Mär 22:19 . drwxr-x--x 187 joachim joachimg 20480 8. Mär 22:29 .. -rw-rw-r-- 1 joachim joachimg 6098 8. Mär 22:28 alpha.jfalk.de:5901.log -rw-rw-r-- 1 joachim joachimg 6 8. Mär 22:19 alpha.jfalk.de:5901.pid -rw--- 1 joachim joachimg 8 8. Mär 22:12 passwd -rwxr-xr-x 1 joachim joachimg91 8. Mär 22:10 xstartup [bash joachim@xerstin:~]$ cat .vnc/xstartup #! /bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec /usr/bin/mate-session I used the following command to start. [bash joachim@alpha:~]$ tigervncserver --localhost no New Xtigervnc server 'alpha.jfalk.de:1 (joachim)' on port 5901 for display :1. Use xtigervncviewer -SecurityTypes VncAuth,TLSVnc -passwd /home/joachim/.vnc/passwd alpha.jfalk.de:1 to connect to the VNC server. I used tigervncserver --list to confirm that the server is running. [bash joachim@alpha:~]$ tigervncserver --list TigerVNC server sessions: X DISPLAY # RFB PORT # PROCESS ID SERVER :1 590129417 Xtigervnc Moreover, connecting to alpha.jfalk.de:1 with a VNC viewer gets me the mate desktop environment. Can you try to start something simpler to determine where exactly the problem is? Use something like: tigervncserver --localhost no --xstartup /usr/bin/xterm This should get you a VNC session running a simple xterm. Best, Joachim vnc-configs.tgz Description: application/compressed-tar OpenPGP_signature Description: OpenPGP digital signature
Bug#984835: /usr/sbin/pam-auth-update: allow comments in pam-config files
Package: libpam-runtime
Version: 1.3.1-5
Severity: wishlist
File: /usr/sbin/pam-auth-update
Tags: patch
Dear Maintainer,
we are shipping some custom pam-configs with our automation, for clarity
we want to include comments in these files. Currently this is not
supported and leeds to perl warning messages because of failed file
parsing. This is just an anoyance, the script is working correctly, even
with comments in files. I just want to get rid of the warning messages.
Output from pam-auth-update with comments im pam-config:
# pam-auth-update --package
Use of uninitialized value $fieldname in hash element at
/usr/sbin/pam-auth-update line 704, line 1.
Use of uninitialized value $fieldname in hash element at
/usr/sbin/pam-auth-update line 705, line 1.
I attached a patch, that enables comments with a "#" mark. If also
honors indented comments, so one could add descriptive comments in the
PAM configuration, without these comments being transfered to the
resulting PAM configuration.
The comment sign and support for indented comments is for you to decide.
-- System Information:
Debian Release: 10.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.14-arch1-1 (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_SOFTLOCKUP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libpam-runtime depends on:
ii debconf [debconf-2.0] 1.5.71
ii libpam-modules 1.3.1-5
libpam-runtime recommends no packages.
libpam-runtime suggests no packages.
-- debconf information:
libpam-runtime/title:
* libpam-runtime/no_profiles_chosen:
libpam-runtime/profiles: unix
libpam-runtime/conflicts:
libpam-runtime/override: false
--- /usr/sbin/pam-auth-update-orig 2021-03-08 21:02:52.039724305 +
+++ /usr/sbin/pam-auth-update 2021-03-08 20:58:22.831866075 +
@@ -685,6 +685,7 @@
my %profile;
open(PROFILE, $profile) || die "could not read profile $profile: $!";
while () {
+ next if (/^\s*#/);
if (/^(\S+):\s+(.*)\s*$/) {
$fieldname = $1;
# compatibility with the first implementation round;
Bug#984788: (pre-approval) unblock: octave/6.2.0-1
Control: tags -1 confirmed Hi Sébastien, On 08-03-2021 13:19, Sébastien Villemot wrote: > This is a pre-approval request for unblocking package octave, version 6.2.0-1 > > Currently, bullseye contains a hand-crafted mercurial snapshot of octave. > Uploading a snapshot was made necessary because the previous official release > (6.1.0) had serious bugs, which were fixed in the mercurial repository. > > Since then, a new official upstream bugfix release has been made (6.2.0). For > various reasons, it would be better to ship an official release in bullseye, > hence this request. > > The debdiff is attached. I have filtered out all unrelevant stuff (copyright > header changes, regenerated files). What you showed looks OK. Under the assumption that the upload happens in the next week or so, go ahead. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#982661: mame: Crash on startup
It still crashes, indeed. Best regards, Celelibi Le Sun, Mar 07, 2021 at 05:00:07PM +0100, Bernhard Übelacker a écrit : > Hello Celelibi, > does this happen with current version > in testing 0.228+dfsg.1-1, too? > > Kind regards, > Bernhard
Bug#984834: unblock firmware-nonfree 20210208-3 upload
Package: release.debian.org Thanks please unblock firmware-nonfree 20210208-3 it is the version that has the relevant firmware packages for the targeted version of linux in bullseye. It will need a small amount of fixes on top that are preprared in git and will be uploaded as soon it has migrated. thank you. -- maks signature.asc Description: PGP signature
Bug#983466: Is a mesa-bug
because wayland itself needs 2 fence registers for 2 momitors i
and X11 only 1.
A trace without using wayland shows the 15th register is used without
giving any problem:
Feb 24 20:10:59 debian systemd[1270]: Started GNOME Shell on X11.
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 0 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 1 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 2 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 3 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 4 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 5 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 6 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 7 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 8 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 9 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 10 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 11 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 12 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 13 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 14 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 15 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 1 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 2 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 3 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 4 0
Feb 24 20:11:29 debian gnome-shell[1505]: GK_intelClearWithBlit_fences 5 0
.
So this seems to be a mesa bug and an exact duplicate
of https://gitlab.freedesktop.org/mesa/mesa/-/issues/790 .
Only the kernel-driver-error has changed and is misleading now.
I add the mesa-2.3.4-patch I currently use, which solves the problem.
Testing for register-overflow is done after updating the batch, If
overflow occurs
the batch is restored to the situation before the last update, the
buffer is flushed
and the batch again is updated with the last update.
--- a/src/mesa/drivers/dri/i915/intel_blit.c2021-01-29 19:33:19.919872300
+0100
+++ b/src/mesa/drivers/dri/i915/intel_blit.c2021-02-27 11:52:41.779536510
+0100
@@ -93,9 +93,10 @@
GLuint CMD, BR13, pass = 0;
int dst_y2 = dst_y + h;
int dst_x2 = dst_x + w;
- drm_intel_bo *aper_array[3];
+ drm_intel_bo *aper_array[1];
bool dst_y_tiled = dst_tiling == I915_TILING_Y;
bool src_y_tiled = src_tiling == I915_TILING_Y;
+ int reloc_count;
BATCH_LOCALS;
if (dst_tiling != I915_TILING_NONE) {
@@ -109,22 +110,6 @@
if (dst_y_tiled || src_y_tiled)
return false;
- /* do space check before going any further */
- do {
- aper_array[0] = intel->batch.bo;
- aper_array[1] = dst_buffer;
- aper_array[2] = src_buffer;
-
- if (dri_bufmgr_check_aperture_space(aper_array, 3) != 0) {
- intel_batchbuffer_flush(intel);
- pass++;
- } else
- break;
- } while (pass < 2);
-
- if (pass >= 2)
- return false;
-
intel_batchbuffer_require_space(intel, 8 * 4);
DBG("%s src:buf(%p)/%d+%d %d,%d dst:buf(%p)/%d+%d %d,%d sz:%dx%d\n",
__func__,
@@ -177,15 +162,32 @@
assert(dst_x < dst_x2);
assert(dst_y < dst_y2);
- BEGIN_BATCH(8);
+ do {
+ reloc_count = drm_intel_gem_bo_get_reloc_count(intel->batch.bo);
+ BEGIN_BATCH(8);
+
+ OUT_BATCH(CMD | (8 - 2));
+ OUT_BATCH(BR13 | (uint16_t)dst_pitch);
+ OUT_BATCH((dst_y << 16) | dst_x);
+ OUT_BATCH((dst_y2 << 16) | dst_x2);
+ OUT_RELOC_FENCED(dst_buffer,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+ dst_offset);
+ /* do space check before going any further */
+ aper_array[0] = intel->batch.bo;
+ if (dri_bufmgr_check_aperture_space(aper_array, 1) != 0) {
+ drm_intel_gem_bo_clear_relocs(intel->batch.bo, reloc_count);
+ intel_batchbuffer_emit_reset(intel);
+ intel_batchbuffer_flush(intel);
+ pass++;
+ } else
+ break;
+ } while (pass < 2);
+
+ if (pass >= 2)
+ return false;
+
- OUT_BATCH(CMD | (8 - 2));
- OUT_BATCH(BR13 | (uint16_t)dst_pitch);
- OUT_BATCH((dst_y << 16) | dst_x);
- OUT_BATCH((dst_y2 << 16) | dst_x2);
- OUT_RELOC_FENCED(dst_buffer,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- dst_offset);
OUT_BATCH((src_y << 16) | src_x);
OUT_BATCH((uint16_t)src_pitch);
OUT_RELOC_FENCED(src_buffer,
@@ -335,6 +337,8 @@
GLuint clear_depth_value, clear_depth_mask;
GLint cx, cy, cw, ch;
GLbitfield fail_mask = 0;
+ int reloc_count;
+ bool flushed;
Bug#983775: libgrokj2k: Baseline violation on amd64/i386
Hi Adrian, Thanks very much for the bug report. I will make these changes. So, is it not possible to enable AVX2 acceleration for this package ? Regards, Aaron On Mon, Mar 1, 2021 at 12:21 PM Adrian Bunk wrote: > Source: libgrokj2k > Version: 7.6.6-1 > Severity: serious > Tags: patch > > > https://buildd.debian.org/status/fetch.php?pkg=libgrokj2k=amd64=7.6.6-1=1612309672=0 > > ... > cd /<>/obj-x86_64-linux-gnu/src/lib/jp2 && /usr/bin/c++ > -DSPDLOG_COMPILED_LIB -Dgrokj2k_EXPORTS > -I/<>/obj-x86_64-linux-gnu/src/lib/jp2 > -I/<>/src/bin/common -I/<>/src/bin/jp2 > -I/<>/src/include -I/<>/src/lib/jp2 > -I/<>/src/lib/jp2/plugin > -I/<>/src/lib/jp2/transform -I/<>/src/lib/jp2/t1 > -I/<>/src/lib/jp2/t1/t1_part1 > -I/<>/src/lib/jp2/t1/t1_ht > -I/<>/src/lib/jp2/t1/t1_ht/coding > -I/<>/src/lib/jp2/t1/t1_ht/common > -I/<>/src/lib/jp2/t1/t1_ht/others > -I/<>/src/lib/jp2/util > -I/<>/src/lib/jp2/codestream > -I/<>/src/lib/jp2/codestream/markers > -I/<>/src/lib/jp2/point_transform > -I/<>/src/lib/jp2/t2 -I/<>/src/lib/jp2/tile > -I/<>/src/lib/jp2/filters -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 > -fvisibility=hidden -mavx2 -mbmi2 -fPIC -Wall -Wextra -Wconversion > -Wsign-conversion -Wunused-parameter -std=c++2a -o > CMakeFiles/grokj2k.dir/util/GrkMappedFile.cpp.o -c > /<>/src/lib/jp2/util/GrkMappedFile.cpp > ... > > > "-mavx2 -mbmi2" is a violation of tha amd64 and i386 port baselines. > > Fix: > > --- debian/rules.old2021-03-01 17:09:49.253529618 + > +++ debian/rules2021-03-01 17:10:55.989543343 + > @@ -18,6 +18,7 @@ >-DBUILD_TESTING:BOOL=OFF \ >-DBUILD_DOC:BOOL=ON \ >-DBUILD_THIRDPARTY:BOOL=OFF \ > + -DAVX2_FOUND:BOOL=OFF \ >-DGRK_USE_LIBJPEG:BOOL=ON > > override_dh_auto_configure: >
Bug#984828: gitlab: code tree not rendered (circling circle instead)
On 2021, മാർച്ച് 9 12:56:44 AM IST, Mike Gabriel wrote: >Package: gitlab >Version: 13.7.8+ds1-1~fto10+1 >Severity: serious > >Hi Praveen, > >here comes the other issue I am facing. Occurred with 13.7.7 and also >occurs with 13.7.8: > >When I open a Git repository on my GitLab instance, I see a circling >circle where the code files/dirs should actually be. Can you share a screenshot ? >The JS console provides four error messages: > >1. >Uncaught TypeError: o.a.fn.tooltip is undefined (with a backtrace I >omit here for now). > >2. >Source-Map-Fehler: Error: JSON.parse: unexpected character at line 1 >column 1 of the JSON data >Ressourcen-Adresse: >https://gitlab.das-netzwerkteam.de/assets/webpack/runtime.2cbada1d.bundle.js >Source-Map-Adresse: runtime.2cbada1d.bundle.js.map > >3. >Source-Map-Fehler: Error: JSON.parse: unexpected character at line 1 >column 1 of the JSON data >Ressourcen-Adresse: >https://gitlab.das-netzwerkteam.de/assets/webpack/pages.projects.show.7aaabbab.chunk.js >Source-Map-Adresse: pages.projects.show.7aaabbab.chunk.js.map > >4. >Source-Map-Fehler: Error: JSON.parse: unexpected character at line 1 >column 1 of the JSON data >Ressourcen-Adresse: >https://gitlab.das-netzwerkteam.de/assets/webpack/pages.projects.show.7aaabbab.chunk.js >Source-Map-Adresse: pages.projects.show.7aaabbab.chunk.js.map > > >Any clue where else to look for error or log messages that might help >to track down this issue? You can try removing /usr/share/gitlab/public/assets (keep a backup in case you want to restore) and regenerating it. dpkg-reconfigure gitlab Or run gitlab-rake assets:precompile And run webpack as given in, https://wiki.debian.org/gitlab/webpack >I can push / pull to / from my GitLab server via the git command, only >the rendering of code trees (and possibly other Javascript dependent >functionalities) seem(s) to be broken. Removing /var/lib/gitlab/node_modules and /var/lib/gitlab/yarn.lock and regenerating it via yarnpkg install command could be another way. See /usr/lib/gitlab/scripts/rake-tasks.sh >Mike -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#984831: bugs.debian.org: should not emit semicolon as query param separator
Package: bugs.debian.org Severity: wishlist Hi, As reported on #debian-til, python can no longer parse bugs.d.o URLs correctly out of the box. The change was backported as a security update to 3.6+ so also affects buster. https://bugs.python.org/issue42967 > Changed in version 3.10: Added separator parameter with the default > value of &. Python versions earlier than Python 3.10 allowed using > both ; and & as query parameter separator. This has been changed to > allow only a single separator key, with & as the default separator. From what I can tell, the search form and msg= use semicolon and I actually can't find any with ampersand. I had a poke through salsa and believe this can be fixed with a `s/query_form/query_param/g`, but I don't know Perl. This feature was added in 2006 and has been completely untouched since then, so presumably it's missing upstream bugfixes. https://salsa.debian.org/debbugs-team/debbugs/-/commit/2c18114353029cfd5784df5c6def6c0b22de4ca7 -- Phil Morrell (emorrp1) -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#984832: has generally unnecessary dependency on python
Package: etckeeper Version: 1.18.16-1 Severity: normal I have systems that would not have python installed except etckeeper depends on it. The dependency is for brz if I understand correctly. However, etckeeper does not use brz by default, and its dependencies let the user choose their vcs without pulling in all the dependencies of all the others, except for in this case. Since the python module needs to be registered using python in order to be used, and the postinst does that, just removing the dep would be a problem. Maybe split the package and replace depends | brz | with etckeeper-brz? -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 etckeeper depends on: ii brz3.1.0-8 ii debconf [debconf-2.0] 1.5.74 ii git1:2.30.1-1 ii python33.9.1-1 Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-136 Versions of packages etckeeper suggests: ii sudo 1.9.5p2-2 -- debconf information excluded -- see shy jo signature.asc Description: PGP signature
Bug#922744: Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
Hi. Thanks for your reply. The links to bugs you included add much needed detail to this discussion. > "Matthias" == Matthias Klose writes: Matthias> as pre-processing. So we know since about three years Matthias> that dwz doesn't support compressed debug symbols. Your Matthias> language about "claims", "might", and so on is not Matthias> appropriate. No, we know that three years ago dwz didn't support compressed debug symbols. Since that information is three years out of date, you get my "might" and "claim" language. You're the binutils maintainer! If you happen to know that dwz still doesn't support compressed symbols then *say that* and all my language about "might" and "claim" will go away. I absolutely trust your knowledge about what our elf stack does. It's possible it's a language issue, but so far you've used rather vague language rather than making specific claims in an area where you are an expert. If you don't know, that's fine. But if no one who would like to see us move away from compressed debug symbols has chosen to check and see whether dwz still requires uncompressed symbols, well, I think that is significant. I think the primary burden of arguing for a change lies with those proposing that change. So, I do think that people proposing a change need to do things like find out what specific tools break. (Including pointers to bugs as you have done in the last mail also counts as providing that sort of justification. I'll admit that I don't see how the pointer to the rpm find-debuginfo script quite fits in, but I think I follow the valgrind issue.)
Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
On 2021-03-06 11:11, Jakub Wilk wrote: * Elana Hashman , 2021-02-17, 11:06: Would you be able to research some representative slice of popular packages that would be affected by the policy change (at least 10) and share the on-disk sizes with compression vs. without? Not exactly what you asked Niels for, but... A few months ago I recompressed whole buster/main/amd64 to see what the effect of ditching --compress-debug-sections would be. Raw data for this experiment is available here: https://github.com/jwilk/lets-shrink-dbgsym/releases/download/20200708/buster-main-amd64-20200708.tsv.xz The columns are: * file name * original .deb size * recompressed .deb size * original installed size * recompressed installed size Note that some of the .deb size savings might be caused by the fix for #868674 (for packages that haven't been rebuilt since the fix). Hi Jakub, This is very helpful. Using this file, I have calculated the following three aggregates: 1. % size between original and recompressed .deb 2. % size between original and recompressed install size 3. size difference in bytes between original and recompressed install size I then performed a quartile analysis on it. Recompressed size is X% of original .deb: Min 3.97% 25% 65.45% Median 74.73% 75% 82.64% Max 105.01% Installed size of recompressed is X% of original installed size: Min 100.06% 25% 230.72% Median 256.76% 75% 292.76% Max 4267.38% Size difference between recompressed and original installed size, is X bytes: Min 20480 (20KB) 25% 89088 (90KB) Median 404480 (404KB) 75% 2461184 (2.5MB) Max 5728869376 (5.72GB) So I think we can conclude the following: - In essentially all cases, recompressed deb has a size improvement over the original. - In all cases, the installed size of the debug symbols is larger, usually about 2-3x the original installed size. - In all but the largest cases, that size difference is negligable. However, the large cases have quite an extreme difference. Hence, I think the tail end of large packages will guide this decision, and Josh very helpfully provided an analysis of those already! Because of the extreme difference for the large packages, and because many of those packages are relatively popular, I think I am inclined to maintain the status quo, i.e. with --compress-debug-section enabled by default. I am open to being convinced otherwise :) Cheers, - e
Bug#922744: Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
On 3/8/21 6:27 PM, Sam Hartman wrote: >> "Matthias" == Matthias Klose writes: > > Matthias> Maybe you should be more specific about "those who can't > Matthias> use" uncompressed debug info in the first place. > > So, you've argued that the disk savings are not significant inside a > package, because packages are themselves compressed. > > What people are arguing is that they want to have debug info for large > programs like firefox or chromium installed, or really debug info for > large parts of their system. > They are in effect arguing that they care about the installed size not > the package size. > They have explicitly argued that having to uninstall and then later > reinstall disadvantages their debug cycle. > > This situation is particularly unfortunate because it sounds like we > have a conflict between two techniques for saving space. > > On one hand we have dwz which tries to optimize and reduce overall size > of debug symbols > > which is incompatible (apparently--no one has explicitly confirmed this) > compressed debug symbols. > > Presumably we can still run dwz within a single package by doing so > before debug symbols are compressed. > But presumably this gets in the way of people running dwz themselves or > something. > > I'll be blunt. > The people who say that they want debug symbols installed on their > system have made a simple, easy to understand argument. let my be blunt as well. The only reference I can find regarding the size on disk is #922744. Contrary to what you're saying "that they want to have debug info for large programs like firefox *or* chromium installed", they want to have debug symbols for firefox *and* chromium *and* more installed at the same time. #631985 speaks about a 10G space requirement for debugging KDE alone. The decision about the compressed debug symbols was made ten years ago. Maybe it's time to re-evaluate what expectations for a debug installation should be set. > The argument that compressed debug symbols break things is still porrly > stated. > We've had a claim that dwz might not work with compressed debug symbols > (and didn't used to). > We've had no one explain how that creates a problem in practice or even > confirm it's still the case. > It felt like pulling teeth to even get an answer that might be a tool we > care about. #87 asked for "postprocessing in dh_strip", however it was implemented in * dh_dwz: Add new experimental tool to run dwz(1) to deduplicate ELF debugging symbols. It should be generally be run before dh_strip (as dh_strip compresses the debug symbols and dwz expects uncompressed debug symbols). (Closes: #87) as pre-processing. So we know since about three years that dwz doesn't support compressed debug symbols. Your language about "claims", "might", and so on is not appropriate. Upstreams are currently looking at issues seen with valgrind about .gnu_debuglink section and .gnu_debugaltlink section in https://bugs.kde.org/show_bug.cgi?id=427969 https://bugs.kde.org/show_bug.cgi?id=396656 so apparently there are issues with another tool (valgrind), and how the debug information is created and split in debhelper. Also see https://github.com/rpm-software-management/rpm/blob/master/scripts/find-debuginfo.sh how dwz is run *after* separating the debug info, not touching the stripped binaries. Apparently the choice for compressed debug sections resulted later in an implementation for dh_dwz which is causing issues on it's own. Unrelated to that, but to not create conflicting dbg and dbgsym packages, there is #968710 and #981245, and it will be difficult to integrate within debhelper without introducing a new debhelper compat level. Also unrelated, there are #971724, #971680, and packages manually installing additional files in auto-generated dbgsym packages. Maybe any of these decisions to dh_strip were maybe mad to the best knowledge at the time, but the current situation is a mess. Sticking to compressed debug sections is just one issue ... Matthias
Bug#984830: Update pdfarranger to 1.7.0
Package: pdfarranger Please update pdfarranger to 1.7.0. https://github.com/pdfarranger/pdfarranger/releases 1.7.0 Allow to edit Keywords, Subjects and dates in document info (#237, #283) Ctrl+click now remove a single page from the selection (#197) Allow selection of odd or even pages (#197) Add option to crop white borders (#256) Allow export to individual files (#240) Enable autoscroll when rubberband selecting (#266) Display the current selection in the status bar (#262) Fix import of images with alpha channel (#226) Allow to scroll the view with up/down & page up/down keys (#269) Allow to zoom to full page (#51) Add option to select all pages from same file (#290) Fix visual issue in dialogs (#301) Improve responsiveness when scrolling zoom levels (#284) Change behavior when selecting with shift + click (#323) Select a continuous range when drag-selecting (#305) Add page scaling (#199) Allow to customize keyboard shortcut from the configuration file (#276) Add option to select all pages with the same page format (#314) Add 'new' button to open new document (#319) Support import of encrypted PDF file (#352) Allow to insert blank pages (#244) Split Page now support n x m split instead of just 1 x 2 (#306) Reduce memory usage (#355) Fix the shortcut created by the Windows MSI installer (#316) Problems with editing if not saving after each operation (#291) Fix slow paste-interleave-odd/even (#379)
Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change
Hi, for avoidance of doubt... Am 08.03.21 um 20:51 schrieb Rene Engelhard: >> type=AVC msg=audit(1615225628.771:1363): apparmor="DENIED" >> operation="mknod" profile="libreoffice-soffice" >> name="/home/vincas/Dokumentai/lu4638vdjw1.tmp" pid=4638 >> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000 >> ouid=1000FSUID="vincas" OUID="vincas" >> > Just because you enable the profile. "Set the profile to enforcing" (from complain) I mean. Regards, Rene
Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
Dear Julien, > Description : Free, functional, and secure implementation of the > BGP-4 protocol. > > the above short description has 3 useless words in it, I suggest you drop > them. > > If it wasn't free it wouldn't be in Debian; if it wasn't functional why > would anyone release or package it; same with "secure", plus it's a > rather meaningless descriptor that'll be wrong the day somebody finds a > bug (especially combined with "implemented in C"...). > Thank you for your feedback. I'll change the short description to "OpenBSD BGP-4 daemon" Kind regards, Job
Bug#983918: libbsd 0.9.1-2+deb10u1 flagged for acceptance
package release.debian.org tags 983918 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: libbsd Version: 0.9.1-2+deb10u1 Explanation: fix out-of-bounds read issue [CVE-2019-20367]
Bug#983113: ruby-mechanize 2.7.6-1+deb10u1 flagged for acceptance
package release.debian.org tags 983113 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: ruby-mechanize Version: 2.7.6-1+deb10u1 Explanation: fix command injection issue [CVE-2021-21289]
Bug#981686: linux-image-5.10.0-3-amd64: Streaming video over NFSv3 broken since upgrade to 5.10.12
Source: linux Source-Version: 5.10.19-1 Hi, On Sat, Mar 06, 2021 at 11:08:18AM +1100, Geoff wrote: > Package: linux-image-5.10.20-xanmod1 > Followup-For: Bug #981686 > X-Debbugs-Cc: unit...@bigpond.com > > NFSv3 issue is fixed upstream in 5.10.15 so this bug can be closed. Thanks for reporting back. Regards, Salvatore
Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
Package: wnpp Severity: wishlist Owner: Job Snijders X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: openbgpd Version : 6.8p1 Upstream Author : OpenBSD tech mailing list * URL : http://www.openbgpd.org/ * License : ISC Programming Lang: C Description : Free, functional, and secure implementation of the BGP-4 protocol. Openbgpd allows ordinary machines to be used as routers exchanging routes with other systems speaking the BGP-4 protocol. OpenBGPD, also known as OpenBSD Border Gateway Protocol Daemon, is a server software program that allows general purpose computers to be used as routers. It is a Unix system daemon that provides a free, open-source implementation of the Border Gateway Protocol version 4. Sponsor: John Goerzen
Bug#984829: batik: CVE-2020-11987
Source: batik Version: 1.12-4 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team The following vulnerability was published for batik. CVE-2020-11987[0]: | Apache Batik 1.13 is vulnerable to server-side request forgery, caused | by improper input validation by the NodePickerPanel. By using a | specially-crafted argument, an attacker could exploit this | vulnerability to cause the underlying server to make arbitrary GET | requests. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-11987 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11987 [1] https://github.com/apache/xmlgraphics-batik/commit/0ef5b661a1f2d1110877ea9e0287987098f6 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#984709: yubikey-luks: Stop exposing challenge in process list
On 08.03.21 20:26, Markus Frosch wrote: > Thanks for reporting, haven't been following upstream for a while since I > don't > use the package actively anymore. Admittedly, this particular information was somewhat buried. > Due to lack of time, I'll upload a minimal patch for now. Feel free to join in > maintaining. Sounds good. Best, Christian
Bug#984820: jags: Wrong homepage
On 8 March 2021 at 20:05, Davide Prina wrote: | Package: jags | Version: 4.3.0-3 | Severity: normal | | I have see that the project homepage do not respond anymore: | http://www-fis.iarc.fr/~martyn/software/jags/ Good catch. Martyn Plummer no longer works there but is now at Warwick. I'll update. Not worth a new release but marked in my sources. | I think that the homepage is now: | http://mcmc-jags.sourceforge.net/ | https://sourceforge.net/projects/mcmc-jags/ As you seen from these, they are stale-ish too. I took the first one even though it is http only which risks being outlawed eventually. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#973248: [Pkg-puppet-devel] Bug#973248: Deprecation warning in Ruby 2.7: $SAFE will become a normal global variable in Ruby 3.0
On 3/8/21 8:50 AM, intrigeri wrote: > Control: tag -1 + patch > Control: severity -1 important > > Hi, > > Miquel van Smoorenburg (2020-10-27): >> I get this warning on a puppet run: >> >> /usr/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:126: warning: >> $SAFE will become a normal global variable in Ruby 3.0 > > Confirmed here. > > I'm bumping the severity to "important" because with typical Puppet > deployments, this bug will yield tons of noise in whatever monitoring > system is used, which makes it pretty much unusable as-is. > >> So I tried another minimal approach. This fixes it for me, and it should >> also fix those other deprecation warnings from #955532, so that patch >> can be dropped if you want. > > The way #955532 was fixed (by backporting an upstream commit) seems > cleaner to me so personally, I'd rather see the big-hammer approach > proposed here used as little as possible. > > Below, I'll share the version of the patch that I'm now using. > It only tackles the problem this bug is about, > and I believe the code style is a bit more canonical Ruby > (guard clause instead of "if" + unspecified else). > > Dear maintainers, I would like this bug to be fixed in Bullseye, to > avoid having to maintain a local workaround on the Tails infra for the > next 2-5 years. If it may help, I could negotiate a freeze exception > with the release team, and if they agree, upload a NMU. > > What do you think? Hi, The patch is super small and looks clean. I also am very annoyed by this problem and would like it to be fixed. I'm not sure I can be the voice of all of the team, but I would say: please go ahead with NMU + dealing with the release team. Can someone else approve? Apollon maybe? Cheers, Thomas Goirand (zigo) > --- /a/puppet 2020-10-25 17:04:24.0 + > +++ /b/puppet 2021-03-08 07:39:16.294675668 + > @@ -1,5 +1,12 @@ > #!/usr/bin/ruby > > + > +def Warning.warn(w) > + return if w =~ /warning: \$SAFE will become a normal global variable/ > + > + super w > +end > + > begin >require 'puppet/util/command_line' >Puppet::Util::CommandLine.new.execute > > ___ > Pkg-puppet-devel mailing list > pkg-puppet-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-puppet-devel >
Bug#984810: courier-authlib: authtest can access user data information from normal users accoun
El lun, 8 de mar. de 2021 a la(s) 14:56, Markus Wanner (mar...@bluegap.ch) escribió: > not very different from a `cat /etc/passwd`). but we can use the tool to parse brute force attacks in combination with authpasswd tool that is also another case of! so an important update for oldstable, stable and future next release must be addressed as i xplain!
Bug#984709: yubikey-luks: Stop exposing challenge in process list
Hi Christian, On Sun, 2021-03-07 at 15:44 +0100, Christian Kastner wrote: > Looking at the upstream yubikey-luks repository, I noticed what seems to > be an important recent fix, namely for the password (used as the yubikey > challenge) being exposed in the process list: > > https://github.com/cornelinux/yubikey-luks/pull/63 > > This affects stable, too. > > The fix from the PR seems simple enough, it just changes four LOC. > > I looked at the (non-whitespace, non-documentation) diff between our > current version and HEAD, and it's not that big. Perhaps the RT would be > even be willing to ACK an update to HEAD. Thanks for reporting, haven't been following upstream for a while since I don't use the package actively anymore. Due to lack of time, I'll upload a minimal patch for now. Feel free to join in maintaining. Regards Markus
Bug#984810: [courier-users] any request using authtest are normal
thanks for clarifications Alessadro. but it seems easy if we look from the socket directory access, but .. > The socket file is srwxrwxrwx root root in both cases, but the parent > directory > on the locally built server is: > drwxr-x--- courier courier authdaemon > whilst on the Debian server it is: > drwxr-xr-x courier courier authdaemon anyone that have directory access wil can use authtest.. in debian is just a extra 755 but so any user that have access to courier group will get information.. still are a hole security so authtest must be acceded only by admins users.. or i mean only by root and courier users i changed and suggest the authtest and any other admin tool must be only accessed by root and courier user! > > > hth > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > courier-users mailing list > courier-us...@lists.sourceforge.net > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Bug#984827: jansi-native: Wrong homepage + possible new version
Source: jansi-native Version: 1.2.3-1 Severity: normal I have see that the project homepage do not respond anymore: http://jansi.fusesource.org/ I think that the homepage is now: https://fusesource.github.io/jansi/ I see that jansi-native is marked as deprecated and is now part of jansi (https://github.com/fusesource/jansi-native) I think that here there is a new jansi version: 2.1.0 that include jansi-native Ciao Davide Note: this is a simplified bug report that I use to report homepage problems found at https://repology.org/repository/debian_testing/problems
Bug#984826: tigervnc-standalone-server: Unable to init server: Could not connect: Connection refused
Package: tigervnc-standalone-server Version: 1.11.0+dfsg-1 Severity: important Dear Maintainer, since the update to version 1.11 the vncserver does not start anymore. Until prior to the update, the server worked with MATE. My ~/.xstartup file contains the following: unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec /usr/bin/mate-session & #lxterminal & /usr/bin/lxsession -s LXDE & Since the update "vncserver --localhost no" terminates with the following message: Xvnc TigerVNC 1.11.0 - built 2021-02-22 17:19 Copyright (C) 1999-2020 TigerVNC Team and many others (see README.rst) See https://www.tigervnc.org for information on TigerVNC. Underlying X server release 1201, The X.Org Foundation Mon Mar 8 20:00:18 2021 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 5901 vncext: created VNC server for screen 0 3NI3X0 New Xtigervnc server 'WS-MAK:1 (mak)' on port 5901 for display :1. 3NI3X0 Use xtigervncviewer -SecurityTypes VncAuth,TLSVnc -passwd /home/mak/.vnc/passwd WS-MAK:1 to connect to the VNC server. ComparingUpdateTracker: 0 pixels in / 0 pixels out ComparingUpdateTracker: (1:-nan ratio) Unable to init server: Could not connect: Connection refused ** (mate-session:11791): WARNING **: 20:00:18.826: Cannot open display: I also tried to use LXDE as a test. Also there the vncserver does not start anymore. Xvnc TigerVNC 1.11.0 - built 2021-02-22 17:19 Copyright (C) 1999-2020 TigerVNC Team and many others (see README.rst) See https://www.tigervnc.org for information on TigerVNC. Underlying X server release 1201, The X.Org Foundation Mon Mar 8 19:55:15 2021 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 5901 vncext: created VNC server for screen 0 3NI3X0 New Xtigervnc server 'WS-MAK:1 (mak)' on port 5901 for display :1. 3NI3X0 Use xtigervncviewer -SecurityTypes VncAuth,TLSVnc -passwd /home/mak/.vnc/passwd WS-MAK:1 to connect to the VNC server. ComparingUpdateTracker: 0 pixels in / 0 pixels out ComparingUpdateTracker: (1:-nan ratio) ** Message: 19:55:15.571: main.vala:101: Session is LXDE ** Message: 19:55:15.571: main.vala:102: DE is (null) ** Message: 19:55:15.571: main.vala:112: No desktop environnement set, fallback to LXDE (lxsession:10182): Gtk-WARNING **: 19:55:15.572: cannot open display: :1 Unable to init server: Could not connect: Connection refused (lxterminal:10181): Gtk-WARNING **: 19:55:15.638: cannot open display: :1 When I downgrade with the packages tigervnc-standalone-server_1.10.1+dfsg-9_amd64.deb and tigervnc-common_1.10.1+dfsg-9_amd64.deb the vncserver works again. Best regards, Matthias -- 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 not set Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tigervnc-standalone-server depends on: ii libaudit1 1:3.0-2 ii libbsd0 0.11.3-1 ii libc6 2.31-9 ii libfile-readbackwards-perl 1.05-2 ii libgcrypt20 1.8.7-3 ii libgl1 1.3.2-1 ii libgnutls30 3.7.0-7 ii libjpeg62-turbo 1:2.0.6-2 ii libpam0g1.4.0-4 ii libpixman-1-0 0.40.0-1 ii libselinux1 3.1-3 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-1 ii libunwind8 1.3.2-2 ii libxau6 1:1.0.9-1 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.4-1 ii perl5.32.1-3 ii tigervnc-common 1.11.0+dfsg-1 ii x11-xkb-utils 7.7+5 ii xauth 1:1.1-1 ii xkb-data2.29-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages tigervnc-standalone-server recommends: ii libgl1-mesa-dri20.3.4-1 ii x11-xserver-utils 7.7+8 ii xfonts-base1:1.0.5 Versions of packages tigervnc-standalone-server suggests: ii xfonts-100dpi1:1.0.4+nmu1.1 ii xfonts-75dpi 1:1.0.4+nmu1.1 ii xfonts-scalable 1:1.0.3-1.2 -- Configuration Files: /etc/tigervnc/vncserver.users changed [not included] -- no debconf information
Bug#984824: dh-python: pybuild needs to support toml (PEP517/PEP518) builds with no setup.py
Package: dh-python Version: 4.20201102+nmu1 Severity: important Increasingly upstream packages have been moving to the PEP518 build format, for which a pyproject.toml file is provided, and no setup.py pybuild fails to handle such packages. In some cases a trivial setup.py can be patched in, or an old one from before upstream updated to PEP518. But this does not work for all packages (fails badly with opendrop, for instance, where scons is invoked). pybuild needs to start supporting the PEP518 build method. Too late for bullseye, but I'd like to consider this a serious (FTBFS) bug post-bullseye. Drew -- 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-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-python depends on: ii python33.9.2-2 ii python3-distutils 3.9.2-1 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.20.7.1 ii libdpkg-perl 1.20.7.1 -- no debconf information
Bug#984825: packaging-tutorial: [INTL:nl] Dutch translation for the packaging-tutorial package's documentation
Package: packaging-tutorial Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch po file for the packaging-tutorial package. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as "po4a/po/nl.po" in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#984823: pam: [INTL:nl] Dutch translation of debconf messages
Package: pam Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of pam debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#984822: jalview: [INTL:nl] Dutch translation of debconf messages
Package: jalview Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the Dutch translation of jalview debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#984821: put-dns: [INTL:nl] Dutch translation of debconf messages
Package: put-dns Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the Dutch translation of put-dns debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#984820: jags: Wrong homepage
Package: jags Version: 4.3.0-3 Severity: normal I have see that the project homepage do not respond anymore: http://www-fis.iarc.fr/~martyn/software/jags/ I think that the homepage is now: http://mcmc-jags.sourceforge.net/ https://sourceforge.net/projects/mcmc-jags/ Ciao Davide Note: this is a simplified bug report that I use to report homepage problems found at https://repology.org/repository/debian_testing/problems
Bug#984819: jackson-annotations: Wrong homepage + new version
Source: jackson-annotations Version: 2.12.1-1 Severity: normal I have see that the project homepage do not respond anymore: http://wiki.fasterxml.com/JacksonHome I think that the homepage is now: source: https://github.com/FasterXML/jackson-annotations home?: https://github.com/FasterXML/jackson https://github.com/FasterXML/jackson-annotations/wiki I think that here there is a new version: 2.12.2 Ciao Davide Note: this is a simplified bug report that I use to report homepage problems found at https://repology.org/repository/debian_testing/problems
Bug#984810: courier-authlib: authtest can access user data information from normal users accoun
Control: tags -1 + confirmed
Control: severity -1 important
On 08.03.21 16:50, PICCORO McKAY Lenz wrote:
Currently as normal user, it can be accessed
to users database if we setup mysql, postgres
or sqlite, inclusively ldap setups.. i mean,
a limited account can query users mail data
to made some kind of attack
This information is reveal from DB:
serveruno:$ authtest test
Authentication succeeded.
Authenticated: test (uid 244, gid 244)
Home Directory: /home/users/intranetusers/test
Maildir: /home/users/intranetusers/test/Maildir
Quota: (none)
Encrypted Password: {MD5RAW}34ca4238a0b923820dcc509a6f75849b
Cleartext Password: 1
Options: (none)
While I generally agree that this is not optimal and should be better
guarded, it does not seem to reveal sensitive information (i.e. it is
not very different from a `cat /etc/passwd`).
Given authtest clearly is a test-tool only, I agree that its permissions
should be limited as requested.
ADDITIONAL NOTE: the package that own the program is authlib.. this
is completely wrong.. cos important setup is not retrieved by
reportbug like the authdaemon setup files modified.. the
/usr/sbin/authenumerate /usr/sbin/authpasswd and /usr/sbin/authtest
must belong to authdaemon (to make sense)
Thanks, that's a good hint as well.
Regards
Markus
Bug#984818: courier-authdaemon init script is not idempotent
Package: courier-authlib Version: 0.71.1-1 The (sysv) init script for courier-authdaemon exits with an error in case of an attempt to start an already started or stop an already stopped service. This clearly breaks the postrm script.
Bug#983198: torbrowser-launcher: launcher does not detect torbrowser as installed on non-EN user session
Hi Marcelo, I can reproduce the issue, and your patch works for me. Thanks for the effort! I hope that the maintainer of torbrowser-launcher can find the time to upload a new version. Cheers, Imre signature.asc Description: This is a digitally signed message part
Bug#982796: avahi 0.7-4+deb10u1 flagged for acceptance
package release.debian.org tags 982796 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: avahi Version: 0.7-4+deb10u1 Explanation: remove avahi-daemon-check-dns mechanism, no longer needed
Bug#984799: scilab-full-bin for armhf and i386
Package: scilab-full-bin Version: 6.1.0+dfsg1-7 Severity: wishlist In Debian 11 Bullseye (current testing) and Sid, scilab-full-bin is not available for armhf and i386, but in Debian 10 Buster is avaible. Perhaps this is due to the limited number of architectures supported by libjogl2-java: bug #926069 relate to #887140 But upstream, a downloadable package is available for i386, view https://www.scilab.org/download/6.1.0 This makes me think that it might be possible to package it for the missing architectures, even if it is by disabling some feature (libjogl2-java support?) when compiling. Thanks!
Bug#982737: gnome-autoar: CVE-2020-36241
Hi Sebastien, On Mon, Mar 08, 2021 at 01:28:51PM +0100, Sebastien Bacher wrote: > Hey there > > Le 06/03/2021 à 20:46, Salvatore Bonaccorso a écrit : > > Probably as well on your radar already, but there is as well a > > regression fix needed for it as per > > > > https://gitlab.gnome.org/GNOME/gnome-autoar/-/commit/cc4e8b7ccc973ac69d75a7423fbe1bcdc51e2cb3 > Thanks Salvatore for pointing that out. I've uploaded a backport of the > CVE patch + the regression fix to unstable now Thank you! Salvatore
Bug#983533: Fix for #983533, fix session startup of RDP session in vinagre's RDP plugin
Hi Simon, On Mo 08 Mär 2021 14:01:41 CET, Simon McVittie wrote: On Fri, 26 Feb 2021 at 09:44:34 +, Mike Gabriel wrote: 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. I suspect you might well now be Debian's foremost expert on Vinagre... ;-) I notice that Ubuntu hirsute has a somewhat larger diff, including the two patches that you applied, plus some more. It might be safer to go with the same patchset they have? Nope. I sense we should find a good mix of both patchsets. Shall I put that on my list? 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 pgpJquTOYfFuo.pgp Description: Digitale PGP-Signatur
Bug#984817: Hardcoded program names in arptables-legacy-save and arptables-legacy-restore scripts
Package: arptables Version: 0.0.4+snapshot20181021-4 Severity: important Dear Maintainer, /usr/sbin/arptables-legacy-save and /usr/sbin/arptables-legacy-restore have hard reference in scprits to my $tool = "/usr/sbin/arptables"; It makes them unusable for legacy as /usr/sbin/arptables is a symlink for alternatives. Both scripts should use /usr/sbin/arptables-legacy -- 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/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages arptables depends on: ii libc6 2.28-10 arptables recommends no packages. arptables suggests no packages. -- no debconf information
Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change
Control: reopen -1
I see this bug marked as Done but I just got denial today:
type=AVC msg=audit(1615225628.771:1363): apparmor="DENIED" operation="mknod" profile="libreoffice-soffice"
name="/home/vincas/Dokumentai/lu4638vdjw1.tmp" pid=4638 comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000FSUID="vincas" OUID="vincas"
Changing rule into this:
owner @{libo_user_dirs}/{,**/}lu?{,?,??}.tmp rwk, #Temporary file used
when saving
Did the trick (needed 9 symbol variant).
Bug#984816: busybox resume fails to resume with swap file after hibernation
Package: busybox-static Version: 1:1.30.1-6 Hi. I wasn't able to figure out all the details yet and likely won't get to that in the next few weeks. However, I tried getting hibernation to work on a machine with only a swap file. This failed miserably (machine appeared to hibernate properly, but on reboot, the script in the initrd (local-premount/resume, from initramfs-tools) did call /usr/bin/resume properly (I added some echo/sleep commands to see what happens), but that just terminated apparently, without any error message or similar. Reproduction (on ext4, btrfs needs more involved procedure for offset): 1) create a sufficiently large file /swap 2) mkswap /swap 3) Add swap to /etc/fstab 4) Figure out parameters for resume/resume_offset, /sys/power/resume_offset and /sys/power/resume resume=$(findmnt -no SOURCE -T /swap) findmnt -no MAJ:MIN -T /swap > /sys/power/resume resume_offset=$(debugfs -R 'bmap /swap 0' $resume 2>/dev/null) cat > /etc/initramfs-tools/conf.d/resume < /sys/power/resume_offset (Note the different capitalization for conf.d/resume - it is needed this way) Run 'update-initramfs -k all -u' Now you should be ready to hibernate (NOTE: Unless the bug is fixed or you configured initramfs-tools to _not_ use busybox, this will potentially lead to data loss, close all programs) echo shutdown > /sys/power/disk echo disk > /sys/power/state your system should now suspend to disk and power off. On power-on, the expected state would be that the machine resumes. The actual state is that the machine does a fresh boot (after running /usr/bin/resume $resume $resume_offset though). Cross-check: Modify /usr/share/initramfstools/hooks/klibc-utils by adding: rm "$DESTDIR/bin/resume" cp -pL /usr/lib/klibc/bin/resume "$DESTDIR/bin/resume" Re-run the steps from "resume=" above. The system properly resumes from hibernation. I know that the "resume" tool in busybox originates from the code in klibc-utils, but right now, the one in busybox doesn't work in this scenario while the one from klibc-utils does. Cheers, Sven
Bug#983071: unblock: xz-utils/5.2.5-1.1
Control: tags -1 confirmed Hi, On 04-03-2021 12:32, Paul Gevers wrote: > What I *think* we're going to do is accept the package in unstable, but > have it age a bit in unstable before unblocking (which is going to > happen automatically due to the hard freeze). Please upload to unstable. As said, we'll let it age a bit there. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#984802: [Pkg-fonts-devel] Bug#984802: conflicts: lcdf-typetools
Quoting Samuel Thibault (2021-03-08 18:00:31) > Jonas Smedegaard, le lun. 08 mars 2021 17:36:53 +0100, a ecrit: > > Quoting Samuel Thibault (2021-03-08 16:12:37) > > > Gürkan Myczko, le lun. 08 mars 2021 15:44:52 +0100, a ecrit: > > > > Package: otf-trace > > > > Version: 1.12.5+dfsg-7 > > > > Severity: serious > > > > Justification: Sounds like a serious violation of ?10.1 > > > > > > Well, yes. The base issue is that OTF stands both for OpenType > > > Font and Open Trace Format. Thus the marked "Conflicts". > > > > > > The question is who should "own" the otfinfo command name? > > > > Do you mean if the package already owning it is ok giving it up? > > No, I rather mean that in name spaces it's hard to define a notion of > "owning" a name. The two meanings of "OTF" have sprinkled > independently, one can try to look at history to check "who came > first", but that's rather meaningless. > > > > Packages names are not really a concern, I was fine with using > > > libopen-trace-format-dev along the existing libotf-dev. > > > > > > But command names are really a concern since that's what > > > documentations, tutorials, etc. found on internet will say: "run > > > otfinfo", and making Debian systems deviate from that will confuse > > > users, be it for one side or the other side. > > > > > > (and the probability that somebody works both on OpenType Font and > > > Open Trace Format on the same machine is quite low). > > > > I thought similarly about a clash between a JavaScript interpreter > > and a ham routing daemon, but turned out the rules are quite strict: > > See bug#681360 about node. > > And yet it has been so for 9 years without anybody complaining. Ohhh, now I get the point :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop
On 2021-03-08 17:19, Shengjing Zhu wrote: Hi, On Sun, Feb 28, 2021 at 11:12 PM YOSHINO Yoshihito wrote: Package: ibus-anthy Version: 1.5.11-2 Severity: important Tags: patch Dear Maintainer, On the GNOME desktop, manual set-up in GNOME Settings is required in order to make ibus-anthy to work. I have prepared an XDG Autostart .desktop file which should be installed to /etc/xdg/autostart/ibus-anthy-gnome-initial-setup.desktop and its corresponding script to be installed to /usr/share/ibus-anthy/ibus-anthy-gnome-initial-setup.sh to automatically set-up ibus-anthy immediately after each user's next login. Sorry for the tight schedule, but hopefully this should be included in the bullseye release (See also Bug#983653.) Thanks in advance, Back to this issue only(ibus doesn't have a working default). I find task-korean-gnome-desktop Recommends gnome-initial-setup, And above the Recommends, it has a comment that says: GNOME doesn't set the working Korean IM by default https://salsa.debian.org/installer-team/tasksel/-/blob/002c2a97/debian/control#L1547 So I think this is the workaround by Korean users. Which now GNOME defaults ibus, and ibus doesn't pick up the right defaults for all. Maybe we should find a universal solution? To me that sounds as a good idea, especially given how late we are in the cycle. I just run gnome-initial-setup, and even if it starts with a redundant question (about locale), the second question is about typing. So provided that the release-team approves the creation of a bunch of new task-*-gnome-desktop packages, I suppose that adding gnome-initial-setup as a dependency in those would be easier than adding the proposed auto setup script to several ibus-* packages. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj OpenPGP_signature Description: OpenPGP digital signature
Bug#982381: MainThread s3ql.umount.blocking_umount: Flushing cache...
Not sure if that's trio issue but after installing newer version from pip to get it running, umounting gets stuck at 2021-03-08 17:41:16.739 2857 DEBUG MainThread s3ql.umount.blocking_umount: Flushing cache... And only thing that helps is kill -9 of mount process and fixing it with fsck.
Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
> "Matthias" == Matthias Klose writes: Matthias> Maybe you should be more specific about "those who can't Matthias> use" uncompressed debug info in the first place. So, you've argued that the disk savings are not significant inside a package, because packages are themselves compressed. What people are arguing is that they want to have debug info for large programs like firefox or chromium installed, or really debug info for large parts of their system. They are in effect arguing that they care about the installed size not the package size. They have explicitly argued that having to uninstall and then later reinstall disadvantages their debug cycle. This situation is particularly unfortunate because it sounds like we have a conflict between two techniques for saving space. On one hand we have dwz which tries to optimize and reduce overall size of debug symbols which is incompatible (apparently--no one has explicitly confirmed this) compressed debug symbols. Presumably we can still run dwz within a single package by doing so before debug symbols are compressed. But presumably this gets in the way of people running dwz themselves or something. I'll be blunt. The people who say that they want debug symbols installed on their system have made a simple, easy to understand argument. The argument that compressed debug symbols break things is still porrly stated. We've had a claim that dwz might not work with compressed debug symbols (and didn't used to). We've had no one explain how that creates a problem in practice or even confirm it's still the case. It felt like pulling teeth to even get an answer that might be a tool we care about. Please be less vague! --Sam
Bug#984794: calamares: use eatmydata to speed up last installation step (60remove-live-packages)
Package: calamares Version: 3.2.36-1 Severity: wishlist Dear Maintainer, Upon installation of Debian 10.8.0 using live ISO with Calamares, the step of live packages removal from target file system may take up to 30 minutes on old HDD due to excessive fsync()'s caused by dpkg. With eatmydata package used, this step takes 3-5 minutes. Please consider using eatmydata for apt operations on calamares. -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages calamares depends on: pn kio pn kpackagetool5 ii libatasmart4 0.19-5 ii libblkid1 2.33.1-0.1 ii libboost-python1.67.0 1.67.0-13+deb10u1 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 pn libkf5auth5 pn libkf5codecs5 pn libkf5completion5 pn libkf5configcore5 pn libkf5configgui5 pn libkf5configwidgets5 pn libkf5coreaddons5 pn libkf5i18n5 pn libkf5jobwidgets5 pn libkf5kiocore5 pn libkf5kiowidgets5 pn libkf5package5 pn libkf5parts5 pn libkf5plasma5 pn libkf5service-bin pn libkf5service5 pn libkf5sonnetui5 pn libkf5textwidgets5 pn libkf5widgetsaddons5 pn libkf5xmlgui5 pn libkpmcore7 ii libparted2 3.2-25 ii libpwquality1 1.4.0-3 ii libpython3.7 3.7.3-2+deb10u2 pn libqt5concurrent5 ii libqt5core5a 5.11.3+dfsg1-1+deb10u4 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u4 ii libqt5gui5 5.11.3+dfsg1-1+deb10u4 ii libqt5network5 5.11.3+dfsg1-1+deb10u4 ii libqt5qml5 5.11.3-4 ii libqt5quick5 5.11.3-4 pn libqt5quickwidgets5 ii libqt5svg5 5.11.3-2 ii libqt5webkit5 5.212.0~alpha2-21 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u4 ii libqt5xml5 5.11.3+dfsg1-1+deb10u4 ii libstdc++6 8.3.0-6 pn libyaml-cpp0.6 ii os-prober 1.77 Versions of packages calamares recommends: ii btrfs-progs 4.20.1-2 pn squashfs-tools calamares suggests no packages. OpenPGP_signature Description: OpenPGP digital signature
Bug#984802: [Pkg-fonts-devel] Bug#984802: conflicts: lcdf-typetools
Jonas Smedegaard, le lun. 08 mars 2021 17:36:53 +0100, a ecrit: > Quoting Samuel Thibault (2021-03-08 16:12:37) > > Gürkan Myczko, le lun. 08 mars 2021 15:44:52 +0100, a ecrit: > > > Package: otf-trace > > > Version: 1.12.5+dfsg-7 > > > Severity: serious > > > Justification: Sounds like a serious violation of ?10.1 > > > > Well, yes. The base issue is that OTF stands both for OpenType Font > > and Open Trace Format. Thus the marked "Conflicts". > > > > The question is who should "own" the otfinfo command name? > > Do you mean if the package already owning it is ok giving it up? No, I rather mean that in name spaces it's hard to define a notion of "owning" a name. The two meanings of "OTF" have sprinkled independently, one can try to look at history to check "who came first", but that's rather meaningless. > > Packages names are not really a concern, I was fine with using > > libopen-trace-format-dev along the existing libotf-dev. > > > > But command names are really a concern since that's what > > documentations, tutorials, etc. found on internet will say: "run > > otfinfo", and making Debian systems deviate from that will confuse > > users, be it for one side or the other side. > > > > (and the probability that somebody works both on OpenType Font and > > Open Trace Format on the same machine is quite low). > > I thought similarly about a clash between a JavaScript interpreter and a > ham routing daemon, but turned out the rules are quite strict: See > bug#681360 about node. And yet it has been so for 9 years without anybody complaining. Samuel
Bug#984815: ITP: libbiosoup-dev -- C++ header-only support library for bioinformatics tools
Package: wnpp Severity: wishlist X-Debbugs-Cc: cru...@debian.org Subject: ITP: libbiosoup-dev -- C++ header-only support library for bioinformatics tools Package: wnpp Owner: Michael R. Crusoe Severity: wishlist * Package name: libbiosoup-dev Version : 0.10.0 Upstream Author : Robert Vaser * URL : https://github.com/rvaser/biosoup/ * License : MIT Programming Lang: C++ Description : C++ header-only support library for bioinformatics tools Biosoup is a c++ collection of header only data structures used for storage and logging in bioinformatics tools. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/libbiosoup-dev
Bug#984814: fbless: search is broken
Package: fbless Version: 0.2.3-4 Severity: normal After upgrade of fbless from 0.2.3-3 to 0.2.3-4 search is no longer working. anything always ends with Traceback (most recent call last): File "/usr/bin/fbless", line 23, in MainWindow().main_loop() File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 747, in main_loop self.search() File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 409, in search s = str(s, default_charset, errors='ignore') TypeError: decoding str is not supported Additionally, when non-ascii letters are used they are displayed as if utf-8-encoded text was treated as latin1-encoded text and then recoded to utf-8. I.e., /фыва becomes Search pattern: Ñ Ñ Ð²Ð° Looks like curses module works differently with text encodings in python3.
Bug#984792: eatmydata-udeb: finish-install.d/13eatmydata-udeb executes earlier than 60remove-live-packages on live ISO
Package: eatmydata-udeb Version: 105-7 Severity: normal Tags: d-i Dear Maintainer, /usr/lib/finish-install.d/60remove-live-packages file is executed after disablng eatmydata-udeb on live iso file, which slows down live packages removing process dramatically. Consider increasing execution order of eatmydata-udeb script. 61 or 62 would fix the issue. -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled OpenPGP_signature Description: OpenPGP digital signature
Bug#984792: eatmydata-udeb: finish-install.d/13eatmydata-udeb executes earlier than 60remove-live-packages on live ISO
On Mon, Mar 08, 2021 at 03:45:31PM +0300, ValdikSS wrote: > /usr/lib/finish-install.d/60remove-live-packages file is executed after > disablng eatmydata-udeb on live iso file, which slows down live packages > removing process dramatically. > Consider increasing execution order of eatmydata-udeb script. 61 or 62 would > fix the issue. I committed a change for this, but it won't be available before bookworm. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#984791: eatmydata-udeb: udeb included in Debian ISO, but eatmydata and libeatmydata1 are not
Package: eatmydata-udeb Version: 105-7 Severity: normal Tags: d-i Dear Maintainer, eatmydata-udeb is included in Debian ISO files but can't be used as eatmydata and libeatmydata1 are missing in ISO pool on any ISO I've tested (CD/DVD, regular/live). Without the library eatmydata-udeb does nothing. It also does not attempt to load the library over the internet. Please include eatmydata package into installation ISO files. I should mention that eatmydata-udeb by itself is not used by default and could be activated only with preseed file or kernel argument. -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled OpenPGP_signature Description: OpenPGP digital signature
Bug#984802: [Pkg-fonts-devel] Bug#984802: conflicts: lcdf-typetools
Quoting Samuel Thibault (2021-03-08 16:12:37) > Gürkan Myczko, le lun. 08 mars 2021 15:44:52 +0100, a ecrit: > > Package: otf-trace > > Version: 1.12.5+dfsg-7 > > Severity: serious > > Justification: Sounds like a serious violation of ?10.1 > > Well, yes. The base issue is that OTF stands both for OpenType Font > and Open Trace Format. Thus the marked "Conflicts". > > The question is who should "own" the otfinfo command name? Do you mean if the package already owning it is ok giving it up? > Packages names are not really a concern, I was fine with using > libopen-trace-format-dev along the existing libotf-dev. > > But command names are really a concern since that's what > documentations, tutorials, etc. found on internet will say: "run > otfinfo", and making Debian systems deviate from that will confuse > users, be it for one side or the other side. > > (and the probability that somebody works both on OpenType Font and > Open Trace Format on the same machine is quite low). I thought similarly about a clash between a JavaScript interpreter and a ham routing daemon, but turned out the rules are quite strict: See bug#681360 about node. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#984497: weasels and doves
Hi, On 2021-03-08 15:44, Albert van der Horst wrote: > I don't see the problem here. If there is a bug in an old version supplied > with Debian, the bug report lands with Debian. Not necessary. Many users cannot tell whether a bug is caused by upstream code or Debian packaging. Many users do not know about Debian BTS. Thus Debian-specific bugs land in upstream trackers, and some upstreams do not want to provide support outside what they consider "canonical" use of their software. > Then Debian can solve the bug report by renewing upstream. Sot that bug > report is not against the package, but against the packaging. True, but this might be slowed down by the update process in stable. > If it persists in the newest version, the bug can be passed to > upstream. Again - if the report ends up in Debian BTS. > Bug reports will not land at the developpers desk, or Debian has to take > measures that they don't, e.g. by replacing e-mail addresses. No reasonable > upstream developer will object to such an arrangement. Many users will not look into e-mail addresses. They will search online using the name of the software, and will arrive at the same developers' desk. This might be offset by renaming entire pieces of software, but renamed packages become hardly visible and all valuable online material related to the original name becomes hidden from users. Best, Andrius
Bug#968498: fbless cant open files
control: severity -1 important
control: tags -1 patch
On Sun, Aug 16, 2020 at 02:58:30PM +0300, Alexander Inyukhin wrote:
> Package: fbless
> Version: 0.2.3-4
> Severity: normal
>
> fbless failed to open files with exception
>
> Traceback (most recent call last):
> File "/usr/bin/fbless", line 23, in
> MainWindow().main_loop()
> File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 79, in
> __init__
> self.content = create_content(self.filename, curses.COLS)
> File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 1073, in
> create_content
> if data.startswith(' TypeError: startswith first arg must be bytes or a tuple of bytes, not str
This is because python3 patch is not complete. As a result, opening
of zip files (which seems to be the most common way fb2 files are
used) is broken. Fortunately the fix is trivial:
--- fbless-0.2.3.orig/fbless_lib/main.py
+++ fbless-0.2.3/fbless_lib/main.py
@@ -1070,7 +1070,7 @@ def create_content(filename, scr_cols):
zf = zipfile.ZipFile(filename)
for zip_filename in zf.namelist():
data = zf.read(zip_filename)
-if data.startswith('
Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop
Hi, On Sun, Feb 28, 2021 at 11:12 PM YOSHINO Yoshihito wrote: > > Package: ibus-anthy > Version: 1.5.11-2 > Severity: important > Tags: patch > > Dear Maintainer, > > On the GNOME desktop, manual set-up in GNOME Settings is required > in order to make ibus-anthy to work. > > I have prepared an XDG Autostart .desktop file which should be installed to > /etc/xdg/autostart/ibus-anthy-gnome-initial-setup.desktop > and its corresponding script to be installed to > /usr/share/ibus-anthy/ibus-anthy-gnome-initial-setup.sh > to automatically set-up ibus-anthy immediately after each user's next login. > > Sorry for the tight schedule, but hopefully this should be included in > the bullseye release > (See also Bug#983653.) > > Thanks in advance, Back to this issue only(ibus doesn't have a working default). I find task-korean-gnome-desktop Recommends gnome-initial-setup, And above the Recommends, it has a comment that says: > GNOME doesn't set the working Korean IM by default https://salsa.debian.org/installer-team/tasksel/-/blob/002c2a97/debian/control#L1547 So I think this is the workaround by Korean users. Which now GNOME defaults ibus, and ibus doesn't pick up the right defaults for all. Maybe we should find a universal solution? -- Shengjing Zhu
Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 05:13:35PM +0100, Job Snijders wrote: > Dear Julien, > > > > Description : Free, functional, and secure implementation of the > BGP-4 protocol. > > the above short description has 3 useless words in it, I suggest you drop > them. > > If it wasn't free it wouldn't be in Debian; if it wasn't functional why > would anyone release or package it; same with "secure", plus it's a > rather meaningless descriptor that'll be wrong the day somebody finds a > bug (especially combined with "implemented in C"...). > > > Thank you for your feedback. > > I'll change the short description to "OpenBSD BGP-4 daemon" > Sounds good, thanks! Cheers, Julien
Bug#983849: [Pkg-mailman-hackers] Bug#983849: Executable mailman-web does not exist
Hey Ÿnérant, Am 08.03.21 um 16:44 schrieb Ÿnérant: Mailman-web is providing an entrypoint for its management, called mailman-web: https://gitlab.com/mailman/mailman-web/-/blob/master/setup.cfg#L34 This is also appearing in its documentation: https://docs.mailman3.org/en/latest/config-web.html This is only a shortcut to the file /usr/share/mailman3-web/manage.py, but I think that this shortcut should appear in the Debian package. I see. It's a bit confusing: The `mailman3-web` Debian Package still uses the older mailman-suite[1] project as source, which is similar but not identical to the newer mailman-web[2] project that you mention. We have plans to migrate to mailman-web, but didn't find time to do it yet. Still I agree that a `/usr/bin/mailman-web` wrapper script would be useful. The next upload of `mailman-suite` (binary package `mailman3-web`) will ship one. Kind regards jonas OpenPGP_signature Description: OpenPGP digital signature
Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 04:51:14PM +0100, Job Snijders wrote: > Package: wnpp > Severity: wishlist > Owner: Job Snijders > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: openbgpd > Version : 6.8p1 > Upstream Author : OpenBSD tech mailing list > * URL : http://www.openbgpd.org/ > * License : ISC > Programming Lang: C > Description : Free, functional, and secure implementation of the BGP-4 > protocol. > Hi, the above short description has 3 useless words in it, I suggest you drop them. If it wasn't free it wouldn't be in Debian; if it wasn't functional why would anyone release or package it; same with "secure", plus it's a rather meaningless descriptor that'll be wrong the day somebody finds a bug (especially combined with "implemented in C"...). Cheers, Julien
