Bug#950816: mpv: unintended code execution vulnerability
Control: tags -1 + patch
Control: found -1 mpv/0.29.1-1
FYI, the patch below works for me.
Also, I think the version in stable is also affected. The code differs
slightly so the patch will need a little tweak.
Cheers.
--
>From 937749b545407aa68b1d15ea5e19a6c23d62da42 Mon Sep 17 00:00:00 2001
From: astian
Date: Mon, 11 Feb 2020 21:08:51 +
Subject: [PATCH] lua: fix unintended code execution vulnerability
Backport of upstream commit cce7062a8a6b6a3b3666aea3ff86db879cba67b6
("lua: fix highly security relevant arbitrary code execution") to
release 0.32.0.
Note: Before release 0.32.0, it used to be that mpv-related scripts
directories where added to Lua's module-loaders search path. This
behaviour was dropped in 0.32.0 (bc1c024ae032). Later, a similar but
stricter behaviour was introduced (see da38caff9c0b and b86bfc907f9c).
The original commit on which this patch is based depended on the new
behaviour. This backport retains the 0.32.0 behaviour; all it does is
filter out relative paths from "package.path" and "package.cpath" for
all Lua scripts.
---
player/lua.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/player/lua.c b/player/lua.c
index 6423861..172ab4e 100644
--- a/player/lua.c
+++ b/player/lua.c
@@ -273,6 +273,36 @@ static int load_scripts(lua_State *L)
return 0;
}
+static void fuck_lua(lua_State *L, const char *search_path)
+{
+void *tmp = talloc_new(NULL);
+
+lua_getglobal(L, "package"); // package
+lua_getfield(L, -1, search_path); // package search_path
+bstr path = bstr0(lua_tostring(L, -1));
+char *newpath = talloc_strdup(tmp, "");
+
+// Unbelievable but true: Lua loads .lua files AND dynamic libraries from
+// the working directory. This is highly security relevant.
+// Lua scripts are still supposed to load globally installed libraries, so
+// try to get by by filtering out any relative paths.
+while (path.len) {
+bstr item;
+bstr_split_tok(path, ";", , );
+if (bstr_startswith0(item, "/")) {
+newpath = talloc_asprintf_append(newpath, "%s%.*s",
+ newpath[0] ? ";" : "",
+ BSTR_P(item));
+}
+}
+
+lua_pushstring(L, newpath); // package search_path newpath
+lua_setfield(L, -3, search_path); // package search_path
+lua_pop(L, 2); // -
+
+talloc_free(tmp);
+}
+
static int run_lua(lua_State *L)
{
struct script_ctx *ctx = lua_touserdata(L, -1);
@@ -326,6 +356,10 @@ static int run_lua(lua_State *L)
assert(lua_gettop(L) == 0);
+fuck_lua(L, "path");
+fuck_lua(L, "cpath");
+assert(lua_gettop(L) == 0);
+
// run this under an error handler that can do backtraces
lua_pushcfunction(L, error_handler); // errf
lua_pushcfunction(L, load_scripts); // errf fn
--
2.25.0
Bug#951236: osmnx fails the remote autopkg test (access blocked)
Dear Matthias, thanks for your report. I have just send an email to the Nominatim system administrator to see what we can do. Best, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#951344: qemu-system-x86: booting Debian server on qemu + 5.5.x kernel crashes
Control: tag -1 + moreinfo unreproducible 14.02.2020 23:23, Antonio wrote: > Package: qemu-system-x86 > Version: 1:4.2-3 > Severity: normal > > Dear Maintainer, > I would like to report that using qemu to boot a Debian server crashes with > the > latest versions of the 5.5.x kernel. > I also reported this problem on Bugzilla at the following link: > https://bugzilla.kernel.org/show_bug.cgi?id=206405 First of all, on that picture there's no first line of the OOPs which is the most significant, unfortunately. You can capture it as text using serial console, eg: -append ".. console=ttyS0" -serial file:/some/where/file And for the most important, I can't reproduce it using Debian kernel in experimental (5.5.0-rc5-amd64 aka 5.5~rc5-1~exp1) - the only available 5.5 kernel on Debian so far. So you might want to provide some instructions on how to reproduce the issue. Also it might be helpful for you to figure out where it fails, what it tries to do at this time (eg loading modules or applies CPU firmware update). Thanks, /mjt
Bug#942989: dblatex: Python2 removal in sid/bullseye
On Wed, 23 Oct 2019 02:33:21 + mo...@debian.org wrote: > Source: dblatex > Version: 0.3.10-2 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal looks like upstream release a py3k compatible version, so i'm gonna try and package it; i've also pushed the previous packages to https://salsa.debian.org/debian/dblatex
Bug#951355: rspamd: Bayesian filters should not cause mails to be rejected
Package: rspamd
Version: 1.9.4-2~bpo10+1
Severity: important
Tags: upstream
Yesterday, I got a mail from the Listmaster Team because my server
rejected the following debian-user-french mail:
https://lists.debian.org/msgid-search/94de34b7-3d83-ba9d-49a4-254bcf3a4...@visionduweb.com
After a quick investigation, I understand that was because of bayesian
filters. If you think it's not possible with default configuration,
I can provide more information and you can stop reading here.
Else, I am horrified by such behaviour from rspamd. I consider that a mail
shall only be rejected if it is indubitably spam (e.g. SPF test failure).
But with Bayesian filters, it's impossible to be absolutely sure and the
only valid option is to accept it.
In fact, I don't expect much from this bug report. I am already quite unhappy
of rspamd for other reasons, mainly because it's too slow at learning ham/spam
(I configured dovecot to trigger that when I move mails from/to the Spam
folder). Configuring rspamd also looks horribly complicated and my only
settings are:
# head local.d/*
==> local.d/rbl.conf <==
enabled = false;
==> local.d/surbl.conf <==
enabled = false;
==> local.d/worker-normal.inc <==
enabled = false;
==> local.d/worker-proxy.inc <==
bind_socket = "localhost:11332";
upstream "local" {
default = yes;
self_scan = yes;
}
(no greylisting)
Whitelisting bendel.debian.org should be something doable easily
but I don't know how.
With this incident, I am now decided to try bogofilter.
I tagged upstream because I doubt that Debian ships with different settings
than upstream about this issue.
-- System Information:
Debian Release: 10.0
APT prefers proposed-updates
APT policy: (900, 'proposed-updates'), (900, 'stable'), (500,
'stable-debug'), (500, 'proposed-updates-debug')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages rspamd depends on:
ii adduser 3.118
ii ca-certificates 20190110
ii libc62.28-10
ii libevent-2.1-6 2.1.8-stable-4
ii libglib2.0-0 2.58.3-2+deb10u1
ii libicu63 63.1-6
ii libjs-bootstrap 3.4.1+dfsg-1
ii libjs-jquery 3.3.1~dfsg-3
ii libjs-requirejs 2.3.6-1
ii libluajit-5.1-2 2.1.0~beta3+dfsg-5.1
ii libmagic11:5.35-4
ii libpcre2-8-0 10.32-5
ii libsqlite3-0 3.27.2-3
ii libssl1.11.1.1c-1
ii libunwind8 1.2.1-9
ii lsb-base 10.2019051400
ii zlib1g 1:1.2.11.dfsg-1
rspamd recommends no packages.
rspamd suggests no packages.
-- no debconf information
Bug#951335: procps: top: window entry #1 corrupt, please delete '/home/tglase/.toprc'
Hi Thorsten, I am pretty sure it's the fieldscur validation having a bad day. I've emailed the author and will let you know what happens. - Craig On Sat, 15 Feb 2020 at 04:24, Thorsten Glaser wrote: > Package: procps > Version: 2:3.3.16-1 > Severity: important > > After an upgrade, my .toprc can no longer be read. > This might be related to the discussions we had > around #784740 where this happened again, and we, > in addition, found that those files are locale- > dependent, but it also happens in the C locale, > for which my /etc/skel/.toprc was written: > > tglase@tglase-nb:~ $ LC_ALL=C top > top: window entry #1 corrupt, please delete '/home/tglase/.toprc' > > On another system which still has 2:3.3.15-2 the > exact same file works, so this is a recent regression. > > -- System Information: > Debian Release: bullseye/sid > APT prefers buildd-unstable > APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores) > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/lksh > Init: sysvinit (via /sbin/init) > > Versions of packages procps depends on: > ii init-system-helpers 1.57 > ii libc62.29-10 > ii libncurses6 6.1+20191019-1 > ii libncursesw6 6.1+20191019-1 > ii libprocps8 2:3.3.16-1 > ii libtinfo66.1+20191019-1 > ii lsb-base 11.1.0 > > Versions of packages procps recommends: > ii psmisc 23.3-1 > > procps suggests no packages. > > -- no debconf information >
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
On Sat, 15 Feb 2020, Ryutaroh Matsumoto wrote: > This is LuaHBTeX, Version 1.11.2 (TeX Live 2020/dev) There is no luahbtex in Debian. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#951354: wget2: Please package new version (1.99.2)
Source: wget2 Version: 1.99.1-2.1 Severity: normal Dear wget2 maintainer, A new release of wget2 (wget2 1.99.1) is now available. Please consider packaging it in Debian. Thanks! -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#951353: syncthing: new upstream 1.3.4
Package: syncthing Version: 1.3.4Severity: Normal Please consider to upgrade to the current upstream version (1.3.4). RegardsJonatan
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
By luaotfload 3.12 and This is LuaHBTeX, Version 1.11.2 (TeX Live 2020/dev) the memory consumption is 2 GB, by texlive 15 February 2020. Ryutaroh
Bug#951352: xcffib: diff for NMU version 0.8.1-0.7
Package: xcffib Version: 0.8.1-0.6 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for xcffib (versioned as 0.8.1-0.7). The diff is attached to this message. Consider maintaining this package with the DPMT Regards. diff -Nru xcffib-0.8.1/debian/changelog xcffib-0.8.1/debian/changelog --- xcffib-0.8.1/debian/changelog 2019-12-21 20:57:12.0 -0500 +++ xcffib-0.8.1/debian/changelog 2020-02-14 21:31:52.0 -0500 @@ -1,3 +1,11 @@ +xcffib (0.8.1-0.7) unstable; urgency=medium + + * Non-maintainer upload. + * debian/control +- remove python-flake8 from b-d, no longer needed + + -- Sandro Tosi Fri, 14 Feb 2020 21:31:52 -0500 + xcffib (0.8.1-0.6) unstable; urgency=medium * Non-maintainer upload.
Bug#950589: lintian: collection/src-orig-index mishandles tarballs with whitespace in owner field
Hi Niko, On Mon, Feb 3, 2020 at 1:54 PM Niko Tyni wrote: > > It looks like this confuses the common prefix removal Thank you for the diagnosis. You were entirely correct. > Lintian reports false warnings for src:libcryptx-perl_0.067-1 With a development version of Lintian that includes this commit: https://salsa.debian.org/lintian/lintian/commit/bf0f7cb1539d08ebc6fe7caa5d09fcf7e2df3015 the output looks like that: $ frontend/lintian ../bugs/ownership/libcryptx-perl_0.067-1.dsc P: libcryptx-perl source: rules-requires-root-missing As Chris said, the fix required some non-trivial changes. Further breakage is possible. Please keep reporting bugs. Kind regards Felix Lechner
Bug#854490: retitle 854490 ITP: xva-img -- Citrix XenServer .xva disk extraction tool
Hi, a few days have passed, the package is ready and sent to the mentors, https://mentors.debian.net/package/xva-img. I wish to keep it. I changed the bug from RFP to ITP. Regards -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Bug#592124: Director
Bug#866613: cloud-init: Adding Apache v2 license to debian/copyright
On Fri, Jun 30, 2017 at 02:14:00PM +, Joonas Kylmälä wrote: > We need to also take care of asking permission from the authors of > Debian patches if they can be used under Apache v2 license. I don't think there's anything copyrightable in any of those contributions. Note that none of the debian-specific changes include any license information as it is. I'm going to make the change to debian/copyright to reflect upstream's license. noah
Bug#951350: RFP: offroad -- offline vector map display ported from OsmAnd
Package: wnpp Severity: wishlist * Package name: offroad Version : 0.5 Upstream Author : Christian Foltin, Reimar Döffinger * URL : https://sourceforge.net/projects/offroadosm/ * License : GPL Programming Lang: Java Description : offline vector map display ported from OsmAnd Features: * Offline Maps * Offline Navigation * GPX Tracks Management * Rendering Engine * OSM Vector Data * Elevation/Contour lines
Bug#951338: libkeyutils1: rkhunter warns that libkeyutils.so.1.9 may contain a possible rootkit
Hi Axel,
thank you for your effort in locating the cause of this!
On 14.02.20 20:21, Axel Beckert wrote:
> c459dfa4 (Francois Marier 2014-10-14 23:24:53 +1300 9958)
>\[pdflush\]:IRC bot
> eca1837f (Francois Marier 2017-07-01 20:33:17 -0700 9959)
>libkeyutils.so.1.9:Spam tool component
> eca1837f (Francois Marier 2017-07-01 20:33:17 -0700 9960)
>.IptabLex:malware component
>
> So it's solely the filename and it's in there since at least 2017.
> And the change which triggered this warning is this commit:
>
> commit 0f70f77491bb6976a2bf761224fec1a9cc6cfb87
> Author: David Howells
> Date: Wed May 29 23:37:15 2019 +0100
>
> Add support for KEYCTL_MOVE
>
> Signed-off-by: David Howells
>
> diff --git a/version.lds b/version.lds
> index 9317222..9e78ea2 100644
> --- a/version.lds
> +++ b/version.lds
> @@ -91,3 +91,9 @@ KEYUTILS_1.8 {
> keyctl_pkey_verify;
>
> } KEYUTILS_1.7;
> +
> +KEYUTILS_1.9 {
> + /* Management functions */
> + keyctl_move;
> +
> +} KEYUTILS_1.8;
>
> Doesn't look like a rootkit addition to me, just bumping the SONAME.
> (And the adding of KEYCTL_MOVE neither.) Lowering the severity to
> default ("normal")...
>
> IMHO this is a bug in rkhunter, but it could also be solved in
> keyutils by bumping the SONAME again, i.e. skipping this SONAME
> version explicitly. But feel free to reassign.
The SONAME wasn't changed. keyutils used versioned symbols, so that file
above actually generates a symbol keyctl_move@KEYUTILS_1.9 (you can see
it in libkeyutils1.symbols).
The only way I can see this changing properly is when a new symbol gets
added. I could maybe hack around this now, but I am not sure that doing
so would be the right solution, if the problem is rkhunter only matching
on a filename (not size, content, etc.). Because what would rkhunter do
when somewhat starts calling a malware file "grep" or something...
I'll have to think about this...
Bug#951348: RFP: scalene -- high-performance, high-precision CPU and memory profiler for Python
Package: wnpp Severity: wishlist * Package name: scalene Version : 0.7.5 Upstream Author : Emery Berger * URL : https://github.com/emeryberger/scalene * License : Apache Programming Lang: Python Description : high-performance, high-precision CPU and memory profiler for Python Scalene is a high-performance CPU and memory profiler for Python that does a few things that other Python profilers do not and cannot do. It runs orders of magnitude faster than other profilers while delivering far more detailed information * Scalene is fast. It uses sampling instead of instrumentation or relying on Python's tracing facilities. Its overhead is typically no more than 10-20% (and often less). * Scalene is precise. Unlike most other Python profilers, Scalene performs CPU profiling at the line level, pointing to the specific lines of code that are responsible for the execution time in your program. This level of detail can be much more useful than the function-level profiles returned by most profilers. * Scalene separates out time spent running in Python from time spent in native code (including libraries). Most Python programmers aren't going to optimize the performance of native code (which is usually either in the Python implementation or external libraries), so this helps developers focus their optimization efforts on the code they can actually improve. * Scalene profiles memory usage. In addition to tracking CPU usage, Scalene also points to the specific lines of code responsible for memory growth. It accomplishes this via an included specialized memory allocator.
Bug#525315: connect/disconnect loops with ifupdown and wpa_supplicant in roaming mode
Package: ifupdown
Version: 0.8.35+b1
Followup-For: Bug #525315
Hey,
I'm pretty sure this should be filed as a bug to wpasupplicant.
In my case (same phenomena on display as OP reported), increasing the
hysteresis timeout to 10 seconds was enough to stop the cycling reliably.
For the record that would be 10 seconds (instead of 4) in
wpa_hysteresis_check() in /etc/wpa_supplicant/functions.sh (a
pro-forma patch is attached).
The actual question here is: how do I debug this cycle properly?
--- a/wpa_supplicant/functions.sh
+++ b/wpa_supplicant/functions.sh
@@ -847,9 +847,10 @@ wpa_hysteresis_check () {
local TIME
local TIMESTAMP
local TIMEWAIT
+ local TIMEDELTA=10
TIME=$(date +%s)
- # current time minus 4 second event buffer
- TIMEWAIT=$(($TIME-4))
+ # current time minus TIMEDELTA second event buffer
+ TIMEWAIT=$((TIME-TIMEDELTA))
# get time of last event
TIMESTAMP=$(cat $WPA_CLI_TIMESTAMP)
# compare values, allowing new action to be processed
Bug#951347: cloud.debian.org: Cannot start vagrant LXC box 'debian/buster64
Package: cloud.debian.org
Severity: normal
Dear Maintainer,
I cannot start a vagrant LXC-box for 'debian/buster64', but succeed to
start the 'debian/stretch64' box. The error message leads me to believe
there is something wrong in the LXC config of the buster box.
Vagrant box: debian/buster64 (version 10.1.0)
I'm trying to start a vagrant LXC-box with this config:
-
Vagrant.configure("2") do |config|
config.vm.box = "debian/buster64"
end
-
Trying to start the vagrant box fails like this:
-
$ VAGRANT_LOG=DEBUG vagrant up --provider=lxc
[...]
There was an error executing ["sudo", "/usr/bin/env", "lxc-start", "-d",
"--name", "test-buster_default_1581713879231_84397"]
[...]
-
Manually trying to start the LXC container fails like this:
-
$ sudo lxc-start -F --name test-buster_default_1581713879231_84397
lxc-start: test-buster_default_1581713879231_84397: storage/dir.c: dir_mount:
198 No such file or directory - Failed to mount
"/var/lib/lxc/buster-base/rootfs" on "/usr/lib/lxc/rootfs"
lxc-start: test-buster_default_1581713879231_84397: conf.c: lxc_mount_rootfs:
1351 Failed to mount rootfs "/var/lib/lxc/buster-base/rootfs" onto
"/usr/lib/lxc/rootfs" with options "(null)"
lxc-start: test-buster_default_1581713879231_84397: conf.c:
lxc_setup_rootfs_prepare_root: 3447 Failed to setup rootfs for
lxc-start: test-buster_default_1581713879231_84397: conf.c: lxc_setup: 3550
Failed to setup rootfs
[...]
-
I don't have a folder "/var/lib/lxc/buster-base" that is mentioned in
the error message.
The corresponding LXC config option is not present for the stretch box,
but only for the buster box:
-
$ diff ~/.vagrant.d/boxes/debian-VAGRANTSLASH-stretch64/9.1.0/lxc/lxc-config
~/.vagrant.d/boxes/debian-VAGRANTSLASH-buster64/10.1.0/lxc/lxc-config
[...]
9a10,13
> lxc.net.0.type = empty
> lxc.apparmor.profile = generated
> lxc.apparmor.allow_nesting = 1
> lxc.rootfs.path = dir:/var/lib/lxc/buster-base/rootfs
16c20
< lxc.uts.name = stretch-base
---
> lxc.uts.name = buster-base
[...]
-
Is this 'lxc.rootfs.path' pointing to '/var/lib/lxc/buster-base' expected to be
in the config?
Kind regards
Reto
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.5.3-arch1-1 (SMP w/12 CPU cores; PREEMPT)
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
Bug#951346: ITP: paraglob -- library for matching strings against a large list of patterns (Zeek)
Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: paraglob Version : 0.4 Upstream Author : Corelight Inc. * URL or Web page : https://github.com/zeek/paraglob * License : BSD-3-clause, LGPL-3+ Description : library for matching strings against a large list of patterns (Zeek) This package is needed for pacakging Zeek 3.x (formerly known as Bro).
Bug#951345: RFS: git-revise/0.5.1-1 -- handy git tool for doing efficient in-memory commit rebases & fixups
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "git-revise" * Package name: git-revise Version : 0.5.1-1 Upstream Author : Nika Layzell * URL : https://mystor.github.io/git-revise.html * License : MIT * Vcs : https://salsa.debian.org/debian/git-revise Section : devel It builds those binary packages: git-revise - handy git tool for doing efficient in-memory commit rebases & fixups To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-revise Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-revise/git-revise_0.5.1-1.dsc Changes since the last upload: * New upstream version 0.5.1 Kind regards, Nicolas
Bug#916260: gparted mounts partition without protection
On Fri, Feb 14, 2020 at 02:52:59PM -0500, Phillip Susi wrote: > > You keep making this false claim, but that doesn't lend it more > > credence. POSIX permissions work the way they work, and if you think some > > combination of permissions are wrong, what are the rules to determine > > right and wrong and what is your source for this repeated statement? > > Simple... right doesn't allow access to the people you don't want to > have it. Wrong permissions do allow access to those you don't intend to > have it. Working around that by other means ( to deny access to the > entire filesystem ) does not change the fact that the permissions on the > file are not configured correctly to carry out your intent. No, it just means gparted has a security bug, because the permissions did work as the user intended before gparted changed them without the users knowledge, and they would have worked if gparted wasn't insecurely exposing the files. gparted *changed* the effective permissions of files by mounting the fs in an insecure location. The reason why your logic doesn't work is that you claim *every* debian root fs has the wrong permissions, because some directories might be world-writable (such as /tmp) which might not be what the user intended by not having the fs mounted in an insecure location (and thus allowing a DoS attack). It would also mean filesystems such as fat, without intrinsic permissions, would somehow have "wrong" permissions. I really don't understand why it is so difficult to simply accept that gparted has a security bug. It happens. It should be fixed. It's not the most dangerous security bug, after all... Fact is, gparted exposes files because it changes effective permissions. Whether you all these permissions right or wrong, green or blue, ethical or satanistic doesn't have any influence on this fact - all these classifications are your own personal opinions and don't have any merit in objectively analying this bug. > > Ah, maybe I see where you are copming from - gparted changes effective > > permissions, so they are wrong. > > No, I didn't say anything about gparted. Well, then you missed the topic - this bug report is about discussing a specific gparted security bug, if you want to discuss something else, you can try to engange me somewhere else or privately. > When gparted mounts it somewhere that isn't traverse proof, yes, that > does allow access where it was not previously, but that's really only > exposing the underlying bug that was always there: that the permissions > on the files are too loose. Well, I have asked you for the source of this claim, but you haven't given one - and I claim you just made it up, because I can't believe you have a source. If you could point out where, in the SuS, it says which permissions are wrong and which are right, then you might have something to discuss. But SuS only documents how permissions work, how they effectively apply, and according to the cold hard facts, gparted exposes files that weren't exposed before. It's that simple. Anyways, I am out of here, have a good one! -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#951344: qemu-system-x86: booting Debian server on qemu + 5.5.x kernel crashes
Package: qemu-system-x86 Version: 1:4.2-3 Severity: normal Dear Maintainer, I would like to report that using qemu to boot a Debian server crashes with the latest versions of the 5.5.x kernel. I also reported this problem on Bugzilla at the following link: https://bugzilla.kernel.org/show_bug.cgi?id=206405 Thank you, Antonio -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (700, 'unstable'), (500, 'stable-updates'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.3-custom (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ISO-8859-1) (ignored: LC_ALL set to it_IT), LANGUAGE=it (charmap=ISO-8859-1) (ignored: LC_ALL set to it_IT) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-20190125.36a4c85-4 ii libaio1 0.3.112-5 ii libasound21.2.1.2-2 ii libbrlapi0.7 6.0+dfsg-4+b1 ii libc6 2.29-10 ii libcacard01:2.6.1-1 ii libcapstone3 4.0.1+really+3.0.5-1+b1 ii libepoxy0 1.5.4-1 ii libfdt1 1.5.1-1 ii libgbm1 19.3.3-1 ii libgcc-s1 [libgcc1] 10-20200211-1 ii libgcc1 1:10-20200211-1 ii libglib2.0-0 2.62.4-2 ii libgnutls30 3.6.11.1-2 ii libibverbs1 28.0-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libncursesw6 6.1+20191019-1 ii libnettle73.5.1+really3.5.1-2 ii libnuma1 2.0.12-1+b1 ii libpixman-1-0 0.36.0-1 ii libpmem1 1.8-1 ii libpng16-16 1.6.37-2 ii librdmacm128.0-1 ii libsasl2-22.1.27+dfsg-2 ii libseccomp2 2.4.2-2 ii libslirp0 4.1.0-2 ii libspice-server1 0.14.2-4 ii libtinfo6 6.1+20191019-1 ii libusb-1.0-0 2:1.0.23-2 ii libusbredirparser10.8.0-1+b1 ii libvdeplug2 2.3.2+r586-2.2+b1 ii libvirglrenderer1 0.8.2-1 ii libxendevicemodel14.11.3+24-g14b62ab3e5-1 ii libxenevtchn1 4.11.3+24-g14b62ab3e5-1 ii libxenforeignmemory1 4.11.3+24-g14b62ab3e5-1 ii libxengnttab1 4.11.3+24-g14b62ab3e5-1 ii libxenmisc4.114.11.3+24-g14b62ab3e5-1 ii libxenstore3.04.11.3+24-g14b62ab3e5-1 ii libxentoolcore1 4.11.3+24-g14b62ab3e5-1 ii qemu-system-common1:4.2-3 ii qemu-system-data 1:4.2-3 ii seabios 1.13.0-1 ii zlib1g1:1.2.11.dfsg-1.2 Versions of packages qemu-system-x86 recommends: ii ovmf 0~20191122.bd85bf54-1 ii qemu-system-gui 1:4.2-3 ii qemu-utils 1:4.2-3 Versions of packages qemu-system-x86 suggests: ii qemu-block-extra1:4.2-3 ii qemu-system-data [sgabios] 1:4.2-3 ii samba 2:4.11.5+dfsg-1 pn vde2
Bug#951343: kid3-core: Missing man page /usr/share/man/man1/kid3-core.1
Package: kid3-core Version: 3.8.2-1 Severity: normal When trying to read the man page for kid3-cli (man kid3-cli) or kid3-qt (man kid3-qt) I get the following message from man: man: can't open /usr/share/man/man1/kid3-core.1: No such file or directory I verified that the file is missing. I tried reinstalling the packages kid3-core, kid3-cli, and kid3-qt, but that did not resolve the issue. dpkg-query -L shows that /usr/share/man/man1/kid3-core.1 is not included in kid3-core, kid3-cli, or kid3-qt. I am assuming from the name of the file that it should be included in the kid3-core package. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kid3-core depends on: ii libavcodec58 7:4.2.2-1 ii libavformat58 7:4.2.2-1 ii libavutil567:4.2.2-1 ii libc6 2.29-10 ii libchromaprint11.4.3-3 ii libflac++6v5 1.3.3-1 ii libflac8 1.3.3-1 ii libgcc11:9.2.1-25 ii libid3-3.8.3v5 3.8.3-16.2+b1 ii libogg01.3.2-1+b1 ii libqt5core5a 5.12.5+dfsg-8 ii libqt5dbus55.12.5+dfsg-8 ii libqt5gui5 5.12.5+dfsg-8 ii libqt5multimedia5 5.12.5-1+b1 ii libqt5network5 5.12.5+dfsg-8 ii libqt5qml5 5.12.5-5 ii libqt5quick5 5.12.5-5 ii libqt5widgets5 5.12.5+dfsg-8 ii libqt5xml5 5.12.5+dfsg-8 ii libstdc++6 9.2.1-25 ii libswresample3 7:4.2.2-1 ii libtag1v5 1.11.1+dfsg.1-0.3+b1 ii libvorbis0a1.3.6-2 ii libvorbisfile3 1.3.6-2 kid3-core recommends no packages. kid3-core suggests no packages. -- no debconf information
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > Maybe it helps when you realise thta chown can also modify a file... Only root can do that. In any case, I was ceeding the point that it is essentially the same thing. > You yourself mentioned some - in any case, does this lead somewhere? I was just curious if there were some that I didn't know about. >> In both cases the permissions on the file itself are wrong, > > You keep making this false claim, but that doesn't lend it more > credence. POSIX permissions work the way they work, and if you think some > combination of permissions are wrong, what are the rules to determine > right and wrong and what is your source for this repeated statement? Simple... right doesn't allow access to the people you don't want to have it. Wrong permissions do allow access to those you don't intend to have it. Working around that by other means ( to deny access to the entire filesystem ) does not change the fact that the permissions on the file are not configured correctly to carry out your intent. >> >> The permissions allow access that you do not wish it to. Ipso facto, >> the permissions are incorrect. > > Ah, maybe I see where you are copming from - gparted changes effective > permissions, so they are wrong. No, I didn't say anything about gparted. When gparted mounts it somewhere that isn't traverse proof, yes, that does allow access where it was not previously, but that's really only exposing the underlying bug that was always there: that the permissions on the files are too loose. If you are running an unpatched kernel that is vulnerable to a remote exploit and aren't connected to the network, then you don't have to worry about it, but if I plug in an Ethernet cable, it doesn't mean that the breach of security is my fault.
Bug#951342: jove: [INTL:fr] French debconf templates translation
Package: jove Severity: wishlist Tags: patch l10n Hi! Please find attached the french debconf templates translation, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Kind Regards jipege fr.po.gz Description: application/gzip
Bug#888670: gnome-system-tools: has been unmaintained upstream for a long time
Control: reopen -1 Control: severity -1 important Hello, The new repository[1] that was supposedly fixing this bug report doesn't even include the upstream sources (or their git history). It's a plain packaging repo with only the debian/ directory. I don't see how that's supposed to fulfil the need for you to become your own uptream. You most likely want to create a fork from the archived gnome repo[2]. Also please pick a (new) name for your fork as it's *not* THE gnome-system-tools (anymore), unless you actually talk to the gnome project to officially pick up as the gnome maintainer (but I suspect at this point there's absolutely no interest from the gnome project to have gnome-system-tools revived). (Once a proper upstream fork exists, packaging that under the new name and providing a transitional gnome-system-tools meta-package will give current users a seemless upgrade experience.) (Please also make sure to look into all the deprecated notices that is being spit out during build. Those will likely become an issue in the not too distant future. But first you might want to reconsider if you really have the resources for taking on the task of becoming your own upstream.) Regards, Andreas Henriksson [1]: https://github.com/LStranger/gnome-system-tools-debian [2]: https://gitlab.gnome.org/Archive/gnome-system-tools
Bug#950994: Discourage package in contrib to install the real program via another package manager
On Sun, Feb 09, 2020 at 11:47:18PM -0500, Olek Wojnar wrote: > 1) Perhaps surprisingly, I agree in principle that installing from an > external source should not be "encouraged" under normal circumstances. > > 2) However, this illustrates a use case that perhaps has not come up in > the past. As I explained in one of the bug reports against my packages, > the rationale for this was to provide a temporary alternate > functionality for end users while upstream goes through a period of > instability. > > 2a) Ideally, I would have preferred to remove the packages in > question from Debian and have a system that would have presented users > with options for alternate sources of that package. I may try to hack > something together for my packages because I agree with a comment on one > of those bugs that transitioning to an alternate package source should > not be done without explicit user action. > > 2b) In a general sense though, this seems like a mechanism that may > have value beyond these two packages. For example, would it be possible > for maintainers to list alternate sources of a package in a new field in > d/control? Then, if a package must be removed from Debian either > temporarily or permanently, users could be presented with alternate > options for that package. Or if certain users want the bleeding-edge > version they can easily get to it instead of pestering a maintainer to > package something that is not stable enough for Debian. > > 2c) The problem with saying a user could just install from > snap/flatpak/etc is that a user may not know what other options are out > there and may not know if they are authoritative (e.g. many but not all > packages are created by the upstream authors). What I am proposing > (well, more like thinking about at the moment, and looking for feedback) > is a system to create an equivalence between the official Debian package > and the same package in other systems. Does anyone else see value in > such a construct? > > > Another package manager in subject could be snap, flatpak, pip, nix, etc. > > > > [1] https://tracker.debian.org/pkg/cyphesis-cpp > > https://tracker.debian.org/pkg/ember > > [2] https://tracker.debian.org/pkg/snapd > > In summary, as snap/flatpak/etc increase in popularity I think it may be > a good idea to have a formalized method for Debian package maintainers > to designate authoritative equivalent sources for their packages, if > they wish to do so. May not answer you question directly. There's something called software center. Like discover[1] for KDE plasma, gnome-software[2] for GNOME. Users can install either debian package, or flatpak, or snap apps. [1] https://tracker.debian.org/pkg/plasma-discover [2] https://tracker.debian.org/pkg/gnome-software
Bug#947530: gnome-system-tools: build-depends on deprecated gnome-doc-utils
Control: reopen -1
On Sat, Feb 01, 2020 at 03:25:11PM +0200, Andriy Grytsenko wrote:
> Hello Andreas!
>
> Thank you very much for the patch. It appears you've done all the
> work and it worked like a charm. All porting guide steps are handled,
> I've rechecked that. Thank you very much.
Apparently you forgot to actually run the application, click the help
button and see what happens.
I've attached a patch which makes a few additional changes that avoids
completely breaking the help system.
To switch away from ghelp: URIs to help: URIs I've found out that it's
apparently needed to do a full docbook to mallard conversion. The URI
scheme is also different where ghelp: is followed by a full path to
an xml file while help: is followed by id, e.g.
help:users-admin or help:users-admin/chapter.
Regards,
Andreas Henriksson
PS. nitpick: The package also ships help for alot more applications than
it installs executables for.
diff -Nru gnome-system-tools-3.0.0/debian/changelog
gnome-system-tools-3.0.0/debian/changelog
--- gnome-system-tools-3.0.0/debian/changelog 2020-02-01 14:10:47.0
+0100
+++ gnome-system-tools-3.0.0/debian/changelog 2020-02-14 20:11:18.0
+0100
@@ -1,3 +1,13 @@
+gnome-system-tools (3.0.0-9.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix up debian/patches/70_gst-yelp.patch to not completely break help.
+- revert to using ghelp: URIs.
+- fix up help file available detection logic for new file location.
+ * Recommend yelp instead of xdg-utils (use gnome-help, not xdg-open).
+
+ -- Andreas Henriksson Fri, 14 Feb 2020 20:11:18 +0100
+
gnome-system-tools (3.0.0-9) unstable; urgency=medium
* Bump Standards-Version to 4.5.0.
diff -Nru gnome-system-tools-3.0.0/debian/control
gnome-system-tools-3.0.0/debian/control
--- gnome-system-tools-3.0.0/debian/control 2020-02-01 14:02:37.0
+0100
+++ gnome-system-tools-3.0.0/debian/control 2020-02-14 20:11:18.0
+0100
@@ -14,7 +14,6 @@
gettext,
libxml-parser-perl,
gnome-pkg-tools,
- yelp,
yelp-tools,
pkg-config
Standards-Version: 4.5.0
@@ -27,7 +26,7 @@
Depends: ${misc:Depends},
${shlibs:Depends},
policykit-1-gnome | mate-polkit
-Recommends: xdg-utils
+Recommends: yelp
Suggests: ntp
Replaces: ximian-setup-tools, gnome-network-admin
Conflicts: gnome-network-admin
diff -Nru gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch
gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch
--- gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch 2020-02-01
14:00:24.0 +0100
+++ gnome-system-tools-3.0.0/debian/patches/70_gst-yelp.patch 2020-02-14
20:11:18.0 +0100
@@ -43,7 +43,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = figures/network-tool.png
+HELP_ID = network-admin
-+HELP_FILES = legal.xml
++HELP_FILES = network-admin.xml legal.xml
+HELP_MEDIA = figures/network-tool.png
-DOC_LINGUAS = ca cs de el en_GB es fr oc pt_BR sl sv it zh_CN
@@ -63,7 +63,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = \
+HELP_ID = services-admin
-+HELP_FILES = legal.xml
++HELP_FILES = services-admin.xml legal.xml
+HELP_MEDIA = \
figures/services-tool.png
@@ -84,7 +84,7 @@
-DOC_FIGURES = figures/shares-tool.png
-DOC_LINGUAS = ca cs de el en_GB es fr gl it oc pt_BR sl sv zh_CN
+HELP_ID = shares-admin
-+HELP_FILES = legal.xml
++HELP_FILES = shares-admin.xml legal.xml
+HELP_MEDIA = figures/shares-tool.png
+HELP_LINGUAS = ca cs de el en_GB es fr gl it oc pt_BR sl sv zh_CN
@@ -101,7 +101,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = \
+HELP_ID = time-admin
-+HELP_FILES = legal.xml
++HELP_FILES = time-admin.xml legal.xml
+HELP_MEDIA = \
figures/time-map.png\
figures/time-servers.png\
@@ -124,7 +124,7 @@
-DOC_INCLUDES =
-DOC_FIGURES = figures/users-tool.png \
+HELP_ID = users-admin
-+HELP_FILES = legal.xml
++HELP_FILES = users-admin.xml legal.xml
+HELP_MEDIA = figures/users-tool.png \
figures/groups.png
@@ -792,15 +792,15 @@
- done
--- a/src/common/gst-tool.c
+++ b/src/common/gst-tool.c
-@@ -412,9 +412,9 @@
- }
-
- if (section) {
-- command = g_strconcat ("gnome-help ghelp://", uri, "?",
section, NULL);
-+ command = g_strconcat ("xdg-open help://", uri, "?", section,
NULL);
- } else {
-- command = g_strconcat ("gnome-help ghelp://", uri, NULL);
-+ command = g_strconcat ("xdg-open help://", uri, NULL);
- }
+@@ -400,9 +400,9 @@
+ }
+ uri = g_build_filename(DATADIR,
+- "/gnome/help/",
+- help_file,
++ "/help/",
+ lang,
++ help_file,
+ help_file_xml,
+
Bug#951338: libkeyutils1: rkhunter warns that libkeyutils.so.1.9 may contain a possible rootkit
Control: severity -1 normal
Hi,
Francesco Poli (wintermute) wrote:
> After upgrading
>
> [UPGRADE] libkeyutils1:amd64 1.6-6 -> 1.6.1-2
>
> I get the following warning with
>
> # rkhunter --sk -c
>
> in /var/log/rkhunter.log:
>
> Info: Starting test name 'running_procs'
> Checking running processes for suspicious files [ Warning ]
> Warning: The following processes are using suspicious files:
>Command: sshd
> UID: 0PID: 7331
> Pathname: /lib/x86_64-linux-gnu/libkeyutils.so.1.9
> Possible Rootkit: Spam tool component
[...]
> Does libkeyutils1/1.6.1-2 ship a rootkit?
Likely not. I looked through the whole diff between 1.6 and 1.6.1. At
least nothing suspicious like obfuscated code.
> Or is it a false positive from rkhunter?
Likely, because what triggers this is not the content of the file, but
the filename itself:
From "git blame files/rkhunter" in
https://salsa.debian.org/pkg-security-team/rkhunter:
c459dfa4 (Francois Marier 2014-10-14 23:24:53 +1300 9958)
\[pdflush\]:IRC bot
eca1837f (Francois Marier 2017-07-01 20:33:17 -0700 9959)
libkeyutils.so.1.9:Spam tool component
eca1837f (Francois Marier 2017-07-01 20:33:17 -0700 9960)
.IptabLex:malware component
So it's solely the filename and it's in there since at least 2017.
And the change which triggered this warning is this commit:
commit 0f70f77491bb6976a2bf761224fec1a9cc6cfb87
Author: David Howells
Date: Wed May 29 23:37:15 2019 +0100
Add support for KEYCTL_MOVE
Signed-off-by: David Howells
diff --git a/version.lds b/version.lds
index 9317222..9e78ea2 100644
--- a/version.lds
+++ b/version.lds
@@ -91,3 +91,9 @@ KEYUTILS_1.8 {
keyctl_pkey_verify;
} KEYUTILS_1.7;
+
+KEYUTILS_1.9 {
+ /* Management functions */
+ keyctl_move;
+
+} KEYUTILS_1.8;
Doesn't look like a rootkit addition to me, just bumping the SONAME.
(And the adding of KEYCTL_MOVE neither.) Lowering the severity to
default ("normal")...
IMHO this is a bug in rkhunter, but it could also be solved in
keyutils by bumping the SONAME again, i.e. skipping this SONAME
version explicitly. But feel free to reassign.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
Bug#947518: casparcg-server: FTBFS: xf86vmode library not found - required for GLFW
[Dimitri John Ledkov] > Anyway, I hacked up something that works, albeit looks ugly. Thank you very much. I hope upstream will accept the fix or some variant of it. :) -- Happy hacking Petter Reinholdtsen
Bug#950994: Discourage package in contrib to install the real program via another package manager
On Mon, Feb 10, 2020 at 05:48:42AM -0500, Sam Hartman wrote: > I'll note there's another case where this could be valuable. > If there is an installer in contrib, you can express dependencies on the > package being available in Debian. > Depending on how that installer works, you may not be able to express > dependencies on the installed version in Debian. > I agree with this argument when you using the word "installer". We have a lot of installers in contrib. Though a package manager is another kind of "installer", but the situation is different. Says I'm a user of pip. I install a python library using pip, and pin it at version A. Now a package in contrib try to use pip to install this library with version B. This becomes conflict. If another package declares dependencies with this package, the version management becomes mess. So technically this doesn't work, only causing problem for end users.
Bug#951340: forkstat: Provide means to filter, output column with UID
Package: forkstat Version: 0.02.11-1 Severity: wishlist Dear Maintainer, This is a really excellent program, but when running as root, it will show me a lot of activity, which I usually then need to filter with stdbuf and grep/awk, usually by name. It would be extremaly helpful to output a column with UID / EUID of the processes, so one can filter on it without looking this things manually in `/proc` (doing this using scripting in bash usually will lead to infinite recursion, it is solvable, just awkward and hacky). Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.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 forkstat depends on: ii libc6 2.29-10 forkstat recommends no packages. forkstat suggests no packages. -- no debconf information
Bug#951339: Debian changes to InspIRCd causes errors when loading the httpd module
Package: inspircd Version: 3.4.0-2 Hello, We have received reports that users of your package are experiencing errors caused by Debian patching the httpd module to not use the vendored version of the http_parser library. Having had a look at the patch (debian.use-http-parser-lib.patch) it seems like your patch is forgetting to link against the library so the module is compiling but failing at runtime. Ideally the fix for this should be to just remove this patch. We only test against the vendored version and there's no guarantee we won't make changes to the vendored libraries which make them incompatible with the mainline version. It's only a tiny library with no external dependencies so this isn't harmful at all. Regards, ~ Sadie
Bug#951338: libkeyutils1: rkhunter warns that libkeyutils.so.1.9 may contain a possible rootkit
Package: libkeyutils1 Version: 1.6.1-2 Severity: grave Tags: security Justification: user security hole Hello! After upgrading [UPGRADE] libkeyutils1:amd64 1.6-6 -> 1.6.1-2 I get the following warning with # rkhunter --sk -c in /var/log/rkhunter.log: Info: Starting test name 'running_procs' Checking running processes for suspicious files [ Warning ] Warning: The following processes are using suspicious files: Command: sshd UID: 0PID: 7331 Pathname: /lib/x86_64-linux-gnu/libkeyutils.so.1.9 Possible Rootkit: Spam tool component I tried to reinstall libkeyutils1/1.6.1-2, after checking the SHA256 checksum of the .deb file. The warning was issued again. On the other hand, after downgrading to libkeyutils1/1.6-6 and restarting ssh # service ssh restart the warning vanishes. Does libkeyutils1/1.6.1-2 ship a rootkit? Or is it a false positive from rkhunter? Please investigate. Thanks for your time! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkeyutils1 depends on: ii libc6 2.29-10 libkeyutils1 recommends no packages. libkeyutils1 suggests no packages. -- no debconf information
Bug#951139: Can someone please have a look (Was: Bug#951139: toil fails it's autopkg tests)
I've uploaded new packages of toil, cwltool, and python-schema-salad that should fix this
Bug#947518: casparcg-server: FTBFS: xf86vmode library not found - required for GLFW
On Fri, 27 Dec 2019 23:14:46 +0100 Andreas Beckmann wrote: > Package: casparcg-server > Version: 2.2.0+dfsg-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source > > Hi, > > casparcg-server FTBFS in a current sid pbuilder environment: > > CMake Error at CMakeModules/FindGLFW.cmake:150 (message): > xf86vmode library not found - required for GLFW > Call Stack (most recent call first): > CMakeModules/Bootstrap_Linux.cmake:44 (FIND_PACKAGE) > CMakeLists.txt:18 (INCLUDE) > What is odd however is that GLFW is not actually used or linked to the final binaries, only a subset of X libraries are. I've tried to clean it up a bit, but it seems to me that many cmake stanzas are quite bogus. And for example, instead of including a custom GLFW module, an upstream one could be used with find_package(glfw3 REQUIRED) for example. Anyway, I hacked up something that works, albeit looks ugly. Regards, Dimitri.
Bug#951337: lintian-brush: dh_clideps fails when debian/compat is removed
Control: retitle -1 lintian-brush: dh_clideps fails with compat bumped On Fri, Feb 14, 2020 at 06:23:53PM +0100, Andreas Henriksson wrote: > Package: lintian-brush > Version: 0.57 > Severity: wishlist > > Dear Maintainer, > > It seems running lintian-brush on a .NET package (like pdfmod) will > cause it to FTBFS. AFAICT this is caused by the switching of > debian/compat -> debhelper-compat (= ...) change, as the dh_clideps > helper has not been updated to support the new syntax. And with some more testing, even with debian/compat restored the same failure still happens. Apparently bumping compat to 12 (or even 10) will cause the same problem to happen. > > Please consider detecting .NET packages and skipping the > debhelper-compat change for now (until someone volunteers to > fix up dh_clideps). ... and the debhelper compat bump. BTW. If this turns out to be a pdfmod specific problem (and not a generic .Net packaging problem) feel free to just close this issue. Regards, Andreas Henriksson
Bug#951336: Update python3-lmdb to >= 0.92
Package: python3-lmdb Version: 0.86-1.2 python3-lmdb-0.86-1.2 is a 5 years old release and my project requires version >= 0.92 (https://gitlab.labs.nic.cz/knot/respdiff/blob/master/requirements.txt#L4). Please, update python3-lmdb in sid.
Bug#951335: procps: top: window entry #1 corrupt, please delete '/home/tglase/.toprc'
On Fri, 14 Feb 2020, Thorsten Glaser wrote: > After an upgrade, my .toprc can no longer be read. Oops, forgot the attachment. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander SteegRCfile for "top with windows" # shameless braggin' Id:a, Mode_altscr=0, Mode_irixps=1, Delay_time=3.000, Curwin=0 Def fieldscur=AEhIOQTrspvuWbcdfgjyzlKNMX winflags=65208, sortindx=10, maxtasks=0 summclr=6, msgsclr=6, headclr=7, taskclr=7 Job fieldscur=ABcefgjlrstuvyzMKNHIWOPQDX winflags=62776, sortindx=0, maxtasks=0 summclr=6, msgsclr=6, headclr=7, taskclr=6 Mem fieldscur=ANOPQRSTUVbcdefgjlmyzWHIKX winflags=62776, sortindx=13, maxtasks=0 summclr=5, msgsclr=5, headclr=4, taskclr=5 Usr fieldscur=ABDECGfhijlopqrstuvyzMKNWX winflags=62776, sortindx=4, maxtasks=0 summclr=3, msgsclr=3, headclr=2, taskclr=3
Bug#951337: lintian-brush: dh_clideps fails when debian/compat is removed
Package: lintian-brush Version: 0.57 Severity: wishlist Dear Maintainer, It seems running lintian-brush on a .NET package (like pdfmod) will cause it to FTBFS. AFAICT this is caused by the switching of debian/compat -> debhelper-compat (= ...) change, as the dh_clideps helper has not been updated to support the new syntax. Please consider detecting .NET packages and skipping the debhelper-compat change for now (until someone volunteers to fix up dh_clideps). Regards, Andreas Henriksson
Bug#951335: procps: top: window entry #1 corrupt, please delete '/home/tglase/.toprc'
Package: procps Version: 2:3.3.16-1 Severity: important After an upgrade, my .toprc can no longer be read. This might be related to the discussions we had around #784740 where this happened again, and we, in addition, found that those files are locale- dependent, but it also happens in the C locale, for which my /etc/skel/.toprc was written: tglase@tglase-nb:~ $ LC_ALL=C top top: window entry #1 corrupt, please delete '/home/tglase/.toprc' On another system which still has 2:3.3.15-2 the exact same file works, so this is a recent regression. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages procps depends on: ii init-system-helpers 1.57 ii libc62.29-10 ii libncurses6 6.1+20191019-1 ii libncursesw6 6.1+20191019-1 ii libprocps8 2:3.3.16-1 ii libtinfo66.1+20191019-1 ii lsb-base 11.1.0 Versions of packages procps recommends: ii psmisc 23.3-1 procps suggests no packages. -- no debconf information
Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader
control: tag -1 +pending Hello dkg, On Fri 31 Jan 2020 at 05:43PM -05, Daniel Kahn Gillmor wrote: > Thanks for the extensive review. I've revised imap-dl, taking it into > account, and have attached the revised version here. You can also find > it on my imap-dl-v2 branch on salsa. Very nice. Applied :) Thank you. > I've dug further into imaplib, and i've pushed the typeshed folks toward > annotating imaplib further based on those findings. We now expect the > response to the uids() call to be a list of items that alternates > between Tuple[bytes,bytes] and b')'. This is definitely more maintainable. >>> +fname = mdst.add(f[1].replace(b'\r\n', b'\n')) >> >> Could a message contain a mixture of UNIX and Windows line endings, such >> that this line corrupts the message? If not, please write a comment >> saying why it is always safe to perform this replacement. > > I know of no way to have this create an actual corruption, unless the > message itself doesn't actually have line endings at all (e.g. an 8-bit > attachment in a MIME message) but i don't have anything like that handy > and i've never seen it in practice. Okay, cool. >> Not a blocker, but it would be nice if the user could request that the >> expunge step be skipped. > > this is a pretty subtle distinction -- you want to set the Deleted flag > but not expunge? can you describe the use case? > >> Also, will imap-dl skip messages with the deleted flag? Do you think it >> should? > > I don't think it should -- the use case at the moment is just to fetch > all messages that exist in the inbox. Why should it treat any flag > differently? What I was thinking was that the user might want imap-dl to set the delete flag and not expunge, and then skip deleted messages on future runs. Then they'd expunge themselves from time-to-time. This way, if imap-dl makes any mistakes, there is a sort of backup. I was particularly thinking that someone might want to use this at first, until they could feel sure that imap-dl doesn't have any bugs with their particular IMAP server. -- Sean Whitton signature.asc Description: PGP signature
Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader
Hello, On Sat 08 Feb 2020 at 12:37PM -05, Daniel Kahn Gillmor wrote: > I don't understand what sort of rebase you are asking for -- the > imap-dl-v2 branch on https://salsa.debian.org/dkg/mailscripts.git is > (and been) based directly atop the imap-dl-squashed branch, so it's > accessible with piecewise commits, with explanatory comments. > > But i'll send a squashed v3 patch as well :) I looked at your branch but couldn't figure out how to get a diff of your v2 patch against your v3 patch, which I wanted to compare against my review comments. Otherwise, it would definitely have been useful to see the piecewise commits. I'd like to suggest using branch names which correspond to versions of the patch in the bug -- if I had seen imap-dl-v2 and imap-dl-v3 I would have known immediately what to do. -- Sean Whitton signature.asc Description: PGP signature
Bug#951334: does not support current lts versions
Package: haskell-stack Version: 1.7.1-3 Severity: normal The last version of LTS that this build of stack can handle seems to be 13.29. Trying to build any stack.yaml that uses a newer LTS results in parse failures. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) 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=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages haskell-stack depends on: ii ca-certificates 20190110 ii gcc 4:9.2.1-3.1 ii libatomic1 9.2.1-24 ii libc62.29-9 ii libffi6 3.2.1-9 ii libgmp-dev 2:6.1.2+dfsg-4 ii libgmp10 2:6.1.2+dfsg-4 ii libsqlite3-0 3.30.1+fossil191229-1 ii libyaml-0-2 0.2.2-1 ii make 4.2.1-1.2 ii xz-utils 5.2.4-1+b1 ii zlib1g 1:1.2.11.dfsg-1+b1 haskell-stack recommends no packages. haskell-stack suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#951333: telegram-purple: Logs error "Query Failed - 71: RPC_CALL_FAIL 400: CHANNEL_INVALID", lost posting functionality
Package: telegram-purple Version: 1.4.1-1+b1 Severity: important After several months of using telegram-purple (thanks for it!) via bitlbee, I started receiving the following message in thelog, with frequencies that go from every ten seconds to every ten minutes: 10:33:27 @root | purple - Error: Query Failed - 71: RPC_CALL_FAIL 400: CHANNEL_INVALID 10:38:52 @root | purple - Error: Query Failed - 71: RPC_CALL_FAIL 400: CHANNEL_INVALID 10:46:48 @root | purple - Error: Query Failed - 71: RPC_CALL_FAIL 400: CHANNEL_INVALID 10:50:53 @root | purple - Error: Query Failed - 71: RPC_CALL_FAIL 400: CHANNEL_INVALID I am not sure on the exact impact this has, bu I can at least say: - One particular channel I subscribe to (https://t.me/sysarmymx) no longer marks messages as read - I receive the messages, but cannot post to the group (my messages are silently dropped) - A couple of days ago, _all_ of my posting and personal messaging ability failed (could only read what was being posted) I have tried unsubscribing and subscribing again, to no avail. Thank you very much, -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages telegram-purple depends on: ii libc6 2.29-3 ii libgcrypt20 1.8.5-3 ii libglib2.0-0 2.62.2-3 ii libpng16-16 1.6.37-1 ii libpurple02.13.0-2.2+b1 ii libwebp6 0.6.1-2+b1 ii zlib1g1:1.2.11.dfsg-1+b1 telegram-purple recommends no packages. telegram-purple suggests no packages. -- no debconf information
Bug#951306: snek: unsatisfiable b-d on picolibc-arm-none-eabi
Ralf Treinen writes: > snek build-depends on picolibc-arm-none-eabi which does not exist (yet) > in sid. Yup. It's been stuck in the 'new' queue for several months now. -- -keith signature.asc Description: PGP signature
Bug#949751: debian-installer does not create efiboot record
пʼятниця, 7 лютого 2020 р. Steve McIntyre пише: > Hi again, > > Please accept my apologies for the very long delay in responding to > you. I've had a really busy time with 3 back-to-back conferences and > I'm just catching up on mail now. :-/ > [...] thanks for your reply, waiting for Colin :) -- WBR, Leonid Khorolets
Bug#945442: Re Bug#945442: Possible to backspace past beginning of string...
Control: -1 severity grave I'm increasing the severity of this bug, as it can cause unintended behavior of which the user is unaware, in a manner that is close enough to data loss that it should be considered grave. One example is when saving a bunch of tagged messages, and backspacing too far when attempting to change the destination folder, the messages will be saved to the default (save-hook) folder for the first tagged message. If the user is unaware of this bug, the user may not know what has happened or where the messages have gone. ...Marvin
Bug#950578: (no subject)
Just gonna add that the latest UEFI Firmware, released today at https://github.com/pftf/RPi4/releases, now contains all the elements needed (ACPI binding and UMAC initialization) for the above patch to work. Which means that, the only limiting factor for UEFI Debian 10.x netinst on a Raspberry Pi 4 is that the kernel is missing the patch above. Thanks, /Pete
Bug#916260: gparted mounts partition without protection
On Fri, Feb 14, 2020 at 10:11:13AM -0500, Phillip Susi wrote: > > doesn't matter how exactly I change a file, as long as I can change it > > when I shouldn't be, it is a security bug. > > True, you can delete the file and replace it, but then it is now owned > by you instead of the original owner. It's a fair argument that it > amounts mostly to the same thing. Maybe it helps when you realise thta chown can also modify a file... > > No, there are other possibilities, but that is one way, yes. > > Other possibilities like what? You yourself mentioned some - in any case, does this lead somewhere? > >> looser permissions, and that amounts to the same thing as just not > >> keeping it mounted most of the time. > > > > No, these are very different things. > > How so? If you can't see how not mounting a filesystem and having ti accessible by various means are very different, I am afraid I don't see how I can explain it to you. > In both cases the permissions on the file itself are wrong, You keep making this false claim, but that doesn't lend it more credence. POSIX permissions work the way they work, and if you think some combination of permissions are wrong, what are the rules to determine right and wrong and what is your source for this repeated statement? It seems to me your claim of "wrongess" is a value statement only - do you have any objective arguments, too? > > Your question is loaded, because it presumes that the correct permissions > > are somehow incorrect (a contradiction that any answer would have to > > accept, which makes it impossible to answer your question). That is > > The permissions allow access that you do not wish it to. Ipso facto, > the permissions are incorrect. Ah, maybe I see where you are copming from - gparted changes effective permissions, so they are wrong. Well, congratulations, that's exactly why this is a security bug in gparted - the user doesn't wish file access and configures the permissions accordingly, but gparted circumvents this user configuration, and this is unexpected, and incorrect behaviour. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#951330: keyboard connected to an USB hub does not work in X11 but on console
Am 14.02.2020 um 15:50 schrieb Marc Haber: > Package: systemd > Version: 244.2-1 > Severity: normal > > Hi, > > I have a rather complex setup on my desktop. > > - Keyboard A is an ancient IBM keyboard from the 1980ies > - Keyboard A is connected via an PS/2 to USB adaptor The only thing that rings a bell is https://github.com/systemd/systemd/issues/14822 You might try reverting that change as in https://github.com/systemd/systemd-stable/commit/c4280c342bbf4fa8da833103482362236c18f835 If that doesn't help, you'll probably need to run git bisect on the systemd-stable branch to find the faulty commit. https://github.com/systemd/systemd-stable/commits/v244-stable Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#950720: FTBFS: error: conflicting declaration ‘typedef long long unsigned int __u64’
Control: tags 950720 - patch + pending Am 05.02.2020 um 12:11 teilte Hilmar Preusse mit: > the package FTBFS on s390x & arm64. > > ./atoms/include/typedfs.h:73:14: note: previous declaration as ‘typedef long > int __s64’ >73 | typedef int __s64 __attribute__((mode(DI))); > | ^ > ./atoms/include/typedfs.h:77:16: error: conflicting declaration ‘typedef long > long unsigned int __u64’ >77 | #define __u64 __u64 > |^ > ./atoms/include/typedfs.h:74:23: note: previous declaration as ‘typedef long > unsigned int __u64’ >74 | typedef unsigned int __u64 __attribute__((mode(DI))); > | ^ > make[2]: *** [makefile:151: wp2latex.o] Error 1 > make[2]: Leaving directory '/<>/sources.cc' > The issue is solved in upstreams repository, but there is no easy patch I could apply. (Un)tagging. H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#916260: gparted mounts partition without protection
Marc Lehmann writes: > When you recreate a file with different contents you have modified it. > Anything else is weird word twisting, and not useful in this context - it > doesn't matter how exactly I change a file, as long as I can change it > when I shouldn't be, it is a security bug. True, you can delete the file and replace it, but then it is now owned by you instead of the original owner. It's a fair argument that it amounts mostly to the same thing. > No, there are other possibilities, but that is one way, yes. Other possibilities like what? >> looser permissions, and that amounts to the same thing as just not >> keeping it mounted most of the time. > > No, these are very different things. How so? In both cases the permissions on the file itself are wrong, and you are relying other mechanisms to stop access before it gets to checking the wrong permissions. > Your question is loaded, because it presumes that the correct permissions > are somehow incorrect (a contradiction that any answer would have to > accept, which makes it impossible to answer your question). That is > not The permissions allow access that you do not wish it to. Ipso facto, the permissions are incorrect.
Bug#951332: ITP: restfuldb -- Web frontend for SQL databases
Package: wnpp Owner: Andrius Merkys Severity: wishlist Control: block -1 by 951190 950611 * Package name : restfuldb Version : 0.13.1 Upstream Author : Saulius Gražulis * URL : https://projects.ibt.lt/repositories/projects/restfuldb * License : GPL-2 Programming Lang: Perl Description : Web frontend for SQL databases RestfulDB is a Web frontend for SQL databases. It provides both a Web GUI and a RESTful API for interaction with any MySQL/MariaDB or SQLite database. RestfulDB is developed with off-the-shelf usage in mind, but nevertheless it provides the means to override the default interpretations of underlying database's schema and data. Declaration of interests: I am one of the upstream developers of this project.
Bug#951331: merge HexChat AppArmor profile
Package: hexchat Severity: normal X-Debbugs-CC: whonix-de...@whonix.org Dear maintainer, could you please review and merge the following AppArmor profile? Called "XChat" but the package name was just not renamed to "HexChat". The profile is tested with HexChat. https://github.com/Whonix/apparmor-profile-xchat Direct links to relevant files: https://github.com/Whonix/apparmor-profile-xchat/blob/master/etc/apparmor.d/usr.bin.hexchat https://github.com/Whonix/apparmor-profile-xchat/blob/master/etc/apparmor.d/abstractions/xchat-based Cheers, Patrick
Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1
Package: user-mode-linux Version: 4.19-1um-1 Severity: serious Tags: patch Dear maintainer, The current user-mode-linux package in buster fails to build the latest linux kernel in buster due to the fix-port-helper-path.patch: Applying patch /build/user-mode-linux-4.19-1um/debian/patches/fix-port-helper-path.patch patching file arch/um/drivers/port_user.c Hunk #1 FAILED at 168. 1 out of 1 hunk FAILED -- rejects in file arch/um/drivers/port_user.c Patch /build/user-mode-linux-4.19-1um/debian/patches/fix-port-helper-path.patch can be reverse-applied make: *** [debian/rules:54: patch-stamp] Error 1 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 I: copying local configuration E: Failed autobuilding of package Removing it solves the issue: diff --git a/debian/patches/series b/debian/patches/series index 5f98481..29faa0f 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -3,4 +3,3 @@ 05_fix_static_build.patch 06-fix-linkage-on-386-arch.patch 07-remove-rpath.patch -fix-port-helper-path.patch BTW, I will prepare a git branch in my personal salsa namespace. But I am not sure against which branch should I propose a MR. Cheers, -- Santiago -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE=es_CO.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 user-mode-linux depends on: ii libc6 2.29-10 Versions of packages user-mode-linux recommends: ii uml-utilities 20070815.3-1 Versions of packages user-mode-linux suggests: ii rootstrap 0.3.25-1 ii rxvt-unicode [x-terminal-emulator]9.22-6+b2 pn slirp ii terminator [x-terminal-emulator] 1.91-4 ii user-mode-linux-doc 20060501-3 pn vde2 ii xfce4-terminal [x-terminal-emulator] 0.8.9.1-1 ii xterm [x-terminal-emulator] 353-1 -- no debconf information
Bug#779077: apache2-bin: crash with segmentation fault if gracefully reloaded twice too quickly
This bug did not go away by updating from Stretch to Buster. A quick fix seems to be changing 'reload' to 'restart' in the logrotate conf file /etc/logrotate.d/apache2. -- Harri
Bug#951328: jove: [INTL:nl] Dutch translation of debconf messages
Package: jove Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of jove 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#951305: r-cran-rockchalk: unsatisfiable build-dependency on r-cran-kutils
Hi Ralf, I would have bet I have uploaded r-cran-kutils together with r-cran-rockchalk to new - but it does not seem to be the case. @Thorsten: If you have time could you please have a look at the just uploaded r-cran-kutils? Thanks a lot Andreas. On Fri, Feb 14, 2020 at 08:57:41AM +0100, Ralf Treinen wrote: > Source: r-cran-rockchalk > Version: 1.8.144+dfsg-1 > Severity: serious > User: trei...@debian.org > Usertags: edos-uninstallable > > Hi, > > r-cran-rockchalk build-depends on r-cran-kutils which does not exist in > sid. > > -Ralf > > ___ > R-pkg-team mailing list > r-pkg-t...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team -- http://fam-tille.de
Bug#951327: thunar: Does not respect DISPLAY variable. Always opens on the primary X screen.
Package: thunar Version: 1.8.4-1 Severity: important Hi, I have four monitors as separate X screens. So on each screen I get a different value for the DISPLAY environment variable: DISPLAY=:0.0 DISPLAY=:0.1 DISPLAY=:0.2 DISPLAY=:0.3 But in Buster on Xfce desktop now Thunar window now always opens up on the primary :0.0 monitor. Like if it didn't realize the existence of several monitors. No matter how it's started: either from the desktop icons or from the applications menu. This was not the case with Stretch and earlier releases. Xfce is now quite awkward to use, as the file manager can be used on only one of the monitors. Regards, Harri -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.utf8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunar depends on: ii desktop-file-utils 0.23-4 ii exo-utils 0.12.4-1 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libexo-2-0 0.12.4-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libgudev-1.0-0 232-2 ii libice6 2:1.0.9-2 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libsm6 2:1.2.3-1 ii libthunarx-3-0 1.8.4-1 ii libxfce4ui-2-0 4.12.1-3 ii libxfce4util7 4.12.1-3 ii libxfconf-0-2 4.12.1-1 ii shared-mime-info1.10-1 ii thunar-data 1.8.4-1 Versions of packages thunar recommends: ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii gvfs 1.38.1-5 ii libcairo-gobject21.16.0-4 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libxfce4panel-2.0-4 4.12.2-1 pn policykit-1-gnome | polkit-1-auth-agent ii thunar-volman0.9.1-1 ii tumbler 0.2.3-1 ii udisks2 2.8.1-4 ii xdg-user-dirs0.17-2 Versions of packages thunar suggests: ii thunar-archive-plugin 0.4.0-2 ii thunar-media-tags-plugin 0.3.0-2 -- no debconf information
Bug#951310: Delaying transition
Hi, The SOVERSION revision in 3.1.5rc1 was an error; its not bumping the soversion until the 4.x releas, expected Q2 this year. I am postponing any changes on pmix until then as reverting (renaming libpmix3->libpmix2) for a minor bugfix release in the interim seems suboptimal. Regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#937870: Bug#947296: mercurial-keyring: Python2 removal in sid/bullseye
On Thu, 30 Jan 2020 12:08:33 +0300 Dmitry Shachnev wrote: > setuptools-scm has removed Python 2 support (see #938470), so python-keyring > build-dependencies are no longer satisfiable. It has since been reintroduced. > Thus I am going to remove Python 2 support from python-keyring, so I am > bumping severity of this bug. That support will be removed in 10 days from > now, on some day after 2020-02-09. > > I am also CCing the maintainers of packages which are listed as blockers of > this bug (mercurial and mercurial-extension-utils). Well, it would break this package, so you need to wait until Mercurial switches to Python 3. -- Cheers, Andrej
Bug#663763: nouveau: Another case of freezing
Package: xserver-xorg-video-nouveau Version: 1:1.0.16-1 Followup-For: Bug #663763 Dear Maintainer, when system starts using the GeForce card the X server freeze or crash. -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 20 -rw-r--r-- 1 root root 1350 Sep 10 2018 10-quirks.conf -rw-r--r-- 1 root root 267 Sep 10 2018 30-gpu.conf -rw-r--r-- 1 root root 584 Sep 10 2018 40-libinput.conf -rw-r--r-- 1 root root 113 Sep 10 2018 50-multitouch.conf -rw-r--r-- 1 root root 1608 Sep 10 2018 70-synaptics.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20200117 (Debian 9.2.1-24)) #1 SMP Debian 5.4.13-1 (2020-01-19) Xorg X server log files on system: -- -rw-r--r-- 1 root libvirtdbus 7250 Sep 10 2018 /var/log/Xorg.8.log -rw-r--r-- 1 root root 5827 Apr 2 2019 /var/log/Xorg.1.log -rw-r--r-- 1 root root35452 Feb 14 14:57 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 7.031] X.Org X Server 1.20.7 X Protocol Version 11, Revision 0 [ 7.031] Build Operating System: Linux 4.19.0-6-amd64 x86_64 Debian [ 7.031] Current Operating System: Linux lenovo 5.4.0-3-amd64 #1 SMP Debian 5.4.13-1 (2020-01-19) x86_64 [ 7.031] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-3-amd64 root=UUID=370651b9-1f6d-4559-9316-cbeea8815771 ro quiet acpi_osi=Linux [ 7.031] Build Date: 14 January 2020 10:13:49AM [ 7.031] xorg-server 2:1.20.7-2 (https://www.debian.org/support) [ 7.031] Current version of pixman: 0.36.0 [ 7.031]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 7.031] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 7.031] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb 14 11:15:02 2020 [ 7.032] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 7.032] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 7.033] (==) No Layout section. Using the first Screen section. [ 7.033] (==) No screen section available. Using defaults. [ 7.033] (**) |-->Screen "Default Screen Section" (0) [ 7.033] (**) | |-->Monitor "" [ 7.034] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 7.034] (**) | |-->Device "Intel Graphics" [ 7.034] (**) | |-->GPUDevice "GeForce MX130" [ 7.034] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 7.034] (==) Automatically adding devices [ 7.034] (==) Automatically enabling devices [ 7.034] (==) Automatically adding GPU devices [ 7.034] (==) Max clients allowed: 256, resource mask: 0x1f [ 7.035] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 7.035]Entry deleted from font path. [ 7.036] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 7.036] (==) ModulePath set to "/usr/lib/xorg/modules" [ 7.036] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 7.036] (II) Loader magic: 0x562024663e40 [ 7.036] (II) Module ABI versions: [ 7.036]X.Org ANSI C Emulation: 0.4 [ 7.036]X.Org Video Driver: 24.1 [ 7.036]X.Org XInput driver : 24.1 [ 7.036]X.Org Server Extension : 10.0 [ 7.036] (++) using VT number 7 [ 7.036] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 7.037] (II) xfree86: Adding drm device (/dev/dri/card0) [ 7.045] (II) xfree86: Adding drm device (/dev/dri/card1) [ 7.048] (--) PCI:*(0@0:2:0) 8086:5917:17aa:39cc rev 7, Mem @ 0xa200/16777216, 0xb000/268435456, I/O @ 0x4000/64, BIOS @ 0x/131072 [ 7.048] (--) PCI: (1@0:0:0) 10de:174d:17aa:39cc rev 162, Mem @ 0xa300/16777216, 0x9000/268435456, 0xa000/33554432, I/O @ 0x3000/128 [ 7.049] (II) LoadModule:
Bug#951326: ITP: libobject-lazy-perl -- create objects late from non-owned classes
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name : libobject-lazy-perl Version : 0.15 Upstream Author : Steffen Winkler * URL : https://metacpan.org/release/Object-Lazy * License : Artistic Programming Lang: Perl Description : create objects late from non-owned classes Object::Lazy implements lazy evaluation and can create lazy objects from every class. . Creates a dummy object including a subroutine which knows how to build the real object. . Later, if a method of the object is called, the real object will be built. . Inherited methods from UNIVERSAL.pm are implemented and so overwritten. This are isa, DOES, can and VERSION. Remark: This package is to be maintained with Debian Perl Group at https://salsa.debian.org/perl-team/modules/packages/libobject-lazy-perl
Bug#951325: rr: Changed path for librrpreload{,_32}.so causes problems
Package: rr
Version: 5.3.0-1
Severity: normal
Tags: patch
Dear Maintainer,
while trying to use 'rr' for debugging LibreOffice, it turned out that
this no longer works with rr version 5.3.0-1, while it did with the
previous version 5.2.0-5 and with a local build of rr.
As turned out, the cause seems to be that the libraries 'librrpreload.so' and
'librrpreload_32.so' are now located in /usr/lib/x86_64-linux-gnu/rr/
while rr expects them in /usr/lib/rr/ .
Building the package with the attached patch made things work again for
me, but there might be a better way to address the issue.
Details on the issue I saw with LibreOffice below, but I suppose that
other use cases needing those libraries may be affected as well.
Regards,
Michael
To reproduce (with package libreoffice 1:6.4.0-1 installed):
record a session (just close the LibreOffice window once it appears):
$ rr record /usr/lib/libreoffice/program/soffice.bin --writer
rr: Saving execution to trace directory
`/home/michi/.local/share/rr/soffice.bin-77'.
Replay:
$ rr replay -s 50505 -k
Launch gdb with
gdb '-l' '1' '-ex' 'set sysroot /' '-ex' 'target extended-remote
127.0.0.1:50505' /usr/lib/libreoffice/program/soffice.bin
Then attach from another terminal using the above command and keep an
eye on the output of the 'rr replay -s 50505 -k' command to see it fails as
follows:
[FATAL /build/rr-XWGEix/rr-5.3.0/src/Task.cc:2218:read_bytes_helper()
errno: EIO]
(task 671896 (rec:671731) at time 83127)
-> Assertion `false' failed to hold. Should have read 40 bytes from
0x7fac6e6e6000, but only read -1
Tail of trace dump:
{
real_time:28495.885633 global_time:83107, event:`SYSCALL: rt_sigaction'
(state:EXITING_SYSCALL) tid:671731, ticks:825
rax:0x0 rbx:0x7ffd2f9da450 rcx:0x rdx:0x7fac6e6e6dd0
rsi:0x0 rdi:0x40 rbp:0x7fac6e6e6ff0 rsp:0x7fac6e6e6d30 r8:0x7fac6e6e6f20 r9:0x0
r10:0x8 r11:0x246 r12:0x7fac6e6e6f20 r13:0x1 r14:0x7ffd2f9da6a0 r15:0x40
rip:0x7facb58940b2 eflags:0x246 cs:0x33 ss:0x2b ds:0x0 es:0x0 fs:0x0 gs:0x0
orig_rax:0xd fs_base:0x7facb018ad00 gs_base:0x0
{ tid:671731, addr:0x7fac6e6e6dd0, length:0x20 }
}
{
real_time:28495.885673 global_time:83108, event:`SYSCALL: rt_sigaction'
(state:ENTERING_SYSCALL) tid:671731, ticks:831
rax:0xffda rbx:0x7ffd2f9da450 rcx:0x rdx:0x0
rsi:0x7fac6e6e6d30 rdi:0x40 rbp:0x7fac6e6e6ff0 rsp:0x7fac6e6e6d30 r8:0x0 r9:0x0
r10:0x8 r11:0x246 r12:0x7fac6e6e6f20 r13:0x1 r14:0x7ffd2f9da6a0 r15:0x40
rip:0x7facb58940b2 eflags:0x246 cs:0x33 ss:0x2b ds:0x0 es:0x0 fs:0x0 gs:0x0
orig_rax:0xd fs_base:0x7facb018ad00 gs_base:0x0
}
{
real_time:28495.885703 global_time:83109, event:`SYSCALL: rt_sigaction'
(state:EXITING_SYSCALL) tid:671731, ticks:831
rax:0x0 rbx:0x7ffd2f9da450 rcx:0x rdx:0x0
rsi:0x7fac6e6e6d30 rdi:0x40 rbp:0x7fac6e6e6ff0 rsp:0x7fac6e6e6d30 r8:0x0 r9:0x0
r10:0x8 r11:0x246 r12:0x7fac6e6e6f20 r13:0x1 r14:0x7ffd2f9da6a0 r15:0x40
rip:0x7facb58940b2 eflags:0x246 cs:0x33 ss:0x2b ds:0x0 es:0x0 fs:0x0 gs:0x0
orig_rax:0xd fs_base:0x7facb018ad00 gs_base:0x0
{ tid:671731, addr:0x7fac6e6e6d30, length:0x20 }
}
{
real_time:28495.885743 global_time:83110, event:`SYSCALL: dup2'
(state:ENTERING_SYSCALL) tid:671731, ticks:844
rax:0xffda rbx:0x7ffd2f9da450 rcx:0x rdx:0x0
rsi:0x1 rdi:0xf rbp:0x7fac6e6e6ff0 rsp:0x7fac6e6e6e78 r8:0x0 r9:0x0 r10:0x8
r11:0x246 r12:0x7facb59dbb24 r13:0x0 r14:0x7ffd2f9da6a0 r15:0x559ff8d70400
rip:0x7facb5945f07 eflags:0x246 cs:0x33 ss:0x2b ds:0x0 es:0x0 fs:0x0 gs:0x0
orig_rax:0x21 fs_base:0x7facb018ad00 gs_base:0x0
}
{
real_time:28495.885772 global_time:83111, event:`SYSCALL: dup2'
(state:EXITING_SYSCALL) tid:671731, ticks:844
rax:0x1 rbx:0x7ffd2f9da450 rcx:0x rdx:0x0 rsi:0x1 rdi:0xf
rbp:0x7fac6e6e6ff0 rsp:0x7fac6e6e6e78 r8:0x0 r9:0x0 r10:0x8 r11:0x246
r12:0x7facb59dbb24 r13:0x0 r14:0x7ffd2f9da6a0 r15:0x559ff8d70400
rip:0x7facb5945f07 eflags:0x246 cs:0x33 ss:0x2b ds:0x0 es:0x0 fs:0x0 gs:0x0
orig_rax:0x21 fs_base:0x7facb018ad00 gs_base:0x0
}
{
real_time:28495.885869 global_time:83112, event:`SYSCALL: rt_sigprocmask'
(state:ENTERING_SYSCALL) tid:671731, ticks:848
rax:0xffda rbx:0x7ffd2f9da450 rcx:0x rdx:0x0
rsi:0x7ffd2f9da390 rdi:0x2 rbp:0x7fac6e6e6ff0 rsp:0x7fac6e6e6e78 r8:0x0 r9:0x0
r10:0x8 r11:0x246 r12:0x7facb59dbb24 r13:0x1 r14:0x7ffd2f9da6a0
r15:0x559ff8d70400 rip:0x7facb589420d eflags:0x246 cs:0x33 ss:0x2b ds:0x0
es:0x0 fs:0x0 gs:0x0 orig_rax:0xe fs_base:0x7facb018ad00 gs_base:0x0
}
{
real_time:28495.885899 global_time:83113, event:`SYSCALL: rt_sigprocmask'
(state:EXITING_SYSCALL) tid:671731, ticks:848
rax:0x0 rbx:0x7ffd2f9da450 rcx:0x rdx:0x0
rsi:0x7ffd2f9da390 rdi:0x2 rbp:0x7fac6e6e6ff0 rsp:0x7fac6e6e6e78 r8:0x0 r9:0x0
r10:0x8 r11:0x246
Bug#951323: emacs stop working when using xterm-mouse-mode in st
Package: emacs Version: 1:26.1+1-3.2+deb10u1 Severity: normal Dear Maintainer, * What led up to the situation? 1. using "emacs -nw" in stterm 2. xterm-mouse-mode 3. M-x customize-variable 4. Info-default-directory-list 5. click with mouse, first button, on "[INS]" (try add new entry) * What was the outcome of this action? emacs "freezes" no reaction to keys or mouse, have to kill it. emacs prints code in the echo area like: down-mouse-1 ESC [ < 0 ; 3 ; 1 5 m ESC ... * What outcome did you expect instead? adding new info default directory path. -- System Information: Distributor ID: Debian Architecture: x86_64 Versions of packages emacs depends on: ii emacs-gtk 1:26.1+1-3.2+deb10u1 ii stterm 0.8.2-1 signature.asc Description: PGP signature
Bug#951324: CTest does not detect NUMA correctly
Package: cmake Version: 3.15.4-1 Severity: minor Tags: upstream Hi, I've run ctest on a dual-socket machine, and the generated report contains NumberOfLogicalCPU="64" NumberOfPhysicalCPU="1" That is wrong. numastat shows two nodes, node 0 and node 8. Simon -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: ppc64el (ppc64le) Kernel: Linux 5.3.0-3-powerpc64le (SMP w/64 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages cmake depends on: ii cmake-data3.15.4-1 ii libarchive13 3.4.0-1+b1 ii libc6 2.29-10 ii libcurl4 7.67.0-2 ii libexpat1 2.2.9-1 ii libgcc1 1:9.2.1-25 ii libjsoncpp1 1.7.4-3.1 ii librhash0 1.3.9-1 ii libstdc++69.2.1-25 ii libuv11.34.2-1 ii procps2:3.3.15-2+b1 ii zlib1g1:1.2.11.dfsg-1.2 Versions of packages cmake recommends: ii gcc 4:9.2.1-3.1 ii make 4.2.1-1.2 Versions of packages cmake suggests: pn cmake-doc ii ninja-build 1.10.0-1 -- no debconf information
Bug#951143: Committed to SVN
Upstream have committed a fix for this to SVN, so it enchant-2 should be supported in the next upstream release. https://sourceforge.net/p/bluefish/tickets/16/
Bug#898159: openntpd: ifup is blocked for 15 sec by openntpd restart if ntpserver is not reachable
Dear Maintainer, This issue is still present in buster. It would be create if it could be fixed. In the meantime a workaround is to delete /etc/network/if-up.d/openntpd (which is quite dirty). Best regards, On Tue, 08 May 2018 10:29:46 +0200 Daniel Krambrock wrote: > Package: openntpd > Version: 1:6.0p1-2 > Severity: important > Tags: patch > > Dear Maintainer, > > on stretch openntpd restarts every time a new interface is added. On boot, > without the interface that provides network and many bridge interfaces, this > leeds to a timeout of networking.service and failed ntp.service. > > For example starting br_vlan1040: > > May 07 15:56:17 node16 kernel: br_vlan1040: port 1(vlan1040) entered blocking > state > May 07 15:56:17 node16 kernel: br_vlan1040: port 1(vlan1040) entered disabled > state > May 07 15:56:17 node16 kernel: device vlan1040 entered promiscuous mode > May 07 15:56:17 node16 kernel: br_vlan1040: port 1(vlan1040) entered blocking > state > May 07 15:56:17 node16 kernel: br_vlan1040: port 1(vlan1040) entered forwarding > state > May 07 15:56:17 node16 kernel: IPv6: ADDRCONF(NETDEV_UP): br_vlan1040: link is > not ready > May 07 15:56:17 node16 ntpd[1333]: ntp engine exiting > May 07 15:56:17 node16 systemd[1]: Stopping OpenNTPd Network Time Protocol... > May 07 15:56:17 node16 ntpd[1336]: Terminating > May 07 15:56:17 node16 systemd[1]: Stopped OpenNTPd Network Time Protocol. > May 07 15:56:17 node16 systemd[1]: Starting OpenNTPd Network Time Protocol... > May 07 15:56:18 node16 ntpd[1756]: configuration OK > May 07 15:56:18 node16 ntpd[2173]: ntpd: can't set priority: Permission denied > May 07 15:56:18 node16 ntpd[2266]: ntp engine ready > May 07 15:56:18 node16 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br_vlan1040: link > becomes ready > May 07 15:56:33 node16 ntpd[2173]: no reply received in time, skipping initial > time setting > May 07 15:56:33 node16 systemd[1]: Started OpenNTPd Network Time Protocol. > May 07 15:56:33 node16 systemd[1]: Reloading OpenBSD Secure Shell server. > May 07 15:56:33 node16 sshd[18649]: Received SIGHUP; restarting. > May 07 15:56:33 node16 systemd[1]: Reloaded OpenBSD Secure Shell server. > May 07 15:56:33 node16 sshd[18649]: Server listening on 0.0.0.0 port 22. > May 07 15:56:33 node16 sshd[18649]: Server listening on :: port 22. > > I found a fix here: > https://github.com/debops/debops/pull/325/commits/648434f7fc87b3e0764c9635a5c4b0ee2161925f > witch leeds to the patch: > > ~# diff -u openntpd_orig/etc/network/if-up.d/openntpd /etc/network/if- > up.d/openntpd > --- openntpd_orig/etc/network/if-up.d/openntpd 2016-11-11 22:47:56.0 > +0100 > +++ /etc/network/if-up.d/openntpd 2018-05-08 10:16:42.885001246 +0200 > @@ -7,4 +7,14 @@ > exit 0 > fi > > -invoke-rc.d openntpd force-reload || true > +if [ "$MODE" != start ]; then > + exit 0 > +fi -- **Fabrice MEYER* Software and System Engineer* EDF Store & Forecast 13 Avenue Albert Einstein 69100 Villeurbanne France *fabrice.me...@edf-sf.com* *www.edf-sf.com*
Bug#951322: ITP: terminews -- Manage RSS sources and display news feed in terminal
Package: wnpp Severity: wishlist Owner: Alois Micard * Package name: terminews Version : 1.2.0-1 Upstream Author : Alex Ntavelos * URL : https://github.com/antavelos/terminews * License : GPL-3.0 Programming Lang: Go Description : Manage RSS sources and display news feed in terminal terminews is a terminal based application (TUI) which makes use of the gocui (https://github.com/jroimartin/gocui) and gofeed (https://github.com/mmcdole/gofeed) libraries and allows you to manage RSS resources and display their news feed. Currently it is only compatible with Linux environments. - Aloïs Micard GPG: rsa4096/A5999EBDFC063F1F
Bug#951320: closed by Michael Biebl (Re: Bug#951320: systemd: network-online.target exits too early -> autofs with ldap fails)
* Henrik Schmidt [Fri Feb 14, 2020 at 01:49:26PM +0100]: > Debian Bug Tracking System schrieb am 14.02.20 um 13:45: > > This is an automatic notification regarding your Bug report > > which was filed against the systemd package: > > #951320: systemd: network-online.target exits too early -> autofs with ldap > > fails > > It has been closed by Michael Biebl . > > Their explanation is attached below along with your original report. > > If this explanation is unsatisfactory and you have not received a > > better one in a separate message then please contact Michael Biebl > > by > > replying to this email. > since this seems to be a debain bug where to I report it to get a better > answer than an immediate bug report closure? Michael closed the bug report while providing details and reasoning about it (which you seemed to have snipped in your reply, see "Their explanation is attached below" from above). See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951320#10 regards -mika- signature.asc Description: Digital signature
Bug#951321: liblog4cplus-dev: Library metadata file is missing
Package: liblog4cplus-dev Version: 1.1.2-3.2 Severity: important Tags: patch Dear Maintainer, While trying to link up a CMake project with this library, an error occured: ``` -- Checking for module 'log4cplus' -- No package 'log4cplus' found CMake Error at /usr/share/cmake-3.13/Modules/FindPkgConfig.cmake:452 (message): A required package was not found Call Stack (most recent call first): /usr/share/cmake-3.13/Modules/FindPkgConfig.cmake:622 (_pkg_check_modules_internal) src/CMakeLists.txt:9 (pkg_check_modules) ``` This is because the *log4cplus.pc* file is not packaged. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU:ru (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages liblog4cplus-dev depends on: ii liblog4cplus-1.1-9 1.1.2-3.2 liblog4cplus-dev recommends no packages. liblog4cplus-dev suggests no packages. -- no debconf information --- log4cplus-1.1.2/debian/liblog4cplus-dev.install 2016-08-08 14:02:11.0 +0300 +++ log4cplus-1.1.2-new/debian/liblog4cplus-dev.install 2020-02-14 14:36:16.973646620 +0200 @@ -2,3 +2,4 @@ usr/include/log4cplus/* usr/lib/*/liblog4cplus.a usr/lib/*/liblog4cplus.la +usr/lib/*/pkgconfig/*
Bug#951320: closed by Michael Biebl (Re: Bug#951320: systemd: network-online.target exits too early -> autofs with ldap fails)
Debian Bug Tracking System schrieb am 14.02.20 um 13:45: > This is an automatic notification regarding your Bug report > which was filed against the systemd package: > > #951320: systemd: network-online.target exits too early -> autofs with ldap > fails > > It has been closed by Michael Biebl . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Michael Biebl > by > replying to this email. > > Hi, since this seems to be a debain bug where to I report it to get a better answer than an immediate bug report closure? Best Henrik Schmidt
Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt
Hi Wolfgang, On Fr 14 Feb 2020 11:52:44 CET, Wolfgang Schweer wrote: On Thu, Feb 13, 2020 at 08:21:27PM +0100, Wolfgang Schweer wrote: On Wed, Feb 12, 2020 at 08:20:08PM +0100, Wolfgang Schweer wrote: > On Wed, Feb 12, 2020 at 07:09:21PM +, Mike Gabriel wrote: > > The simpleness of the fetch-ldap-cert version you propose is > > tempting. But this version will only work against TJENERs that have > > a Debian-Edu_rootCA.crt exported via www.intern. Considering... [Mike] > This assures that Debian-Edu_rootCA is available in the system-wide CA > bundle in /etc/ssl/certs/ca-certificates.crt. > This issue relates to #926388 (let Firefox trust > /etc/ssl/certs/ca-certificates.crt) ...let's me think, that this bug is only fixable for Debian Edu 10 and higher anyway. Some more thoughts: My proposed script could be added as fetch-rootca-cert because that's what it's all about. The fetch-ldap-cert script would be kept in bullseye (and retired in bullseye+1 aka bookworm). Yes. That sounds good. fetch-rootca- could then go into buster-pu, I guess. Yes. And it should ignore missing Debian-Edu_rootCA.crt on TJENER (i.e. a TJENER from Debian 10.0 or earlier). Also, the firefox-esr policies file (already in the master branch) should be shipped for buster-pu. Yes. The policies file makes shure that FF-ESR shows the green padlock also in case a user changes the password using gosa-desktop (which is the recommended way to do that). It is actually quite bad to be warned about a certificate issue and an insecure connection just in this case. Indeed. Reason for the gosa-desktop issue: On first call, a new FF profile is created on the fly. IMO the additional profile issue can't be solved with the p11-kit-trust.so method, which is now deprecated in favour of the pocicies one, see e.g.: https://wiki.mozilla.org/CA/AddRootToFirefox I've tested an appropiately updated d-e-config package both on a buster 10.3 main server and on a buster 10.3 roaming workstation (w/ your fixes present for that one). Works ok in both cases, green padlocks in all cases mentioned above. Great. Please go ahead and push and I will review from there on. 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 pgpkmOs0O7_Zw.pgp Description: Digitale PGP-Signatur
Bug#931173: Configuring static networking via NoCloud with Network Config Version 2 does not work
On 2/13/20 12:44 PM, Christian Tramnitz wrote: > Is there any progress in getting 19.3 into stable? I can see it was not > part of the Buster 10.3 release. > If this takes any longer I'd suggest to backport the initially mentioned > patch. > > > BR, > Christian We currently don't have any answer from the release team, so we can't tell, really. Opening a new big will not help. Cheers, Thomas Goirand (zigo)
Bug#951319: libapache2-mod-perl: reduce Build-Depends
Source: libapache2-mod-perl2 Version: 2.0.11-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability libapache2-mod-perl2 cannot be cross built, because a number of build dependencies are not cross-satisfiable. There are two major techniques to reduce dependencies that are easily applicable here: * Move from Build-Depends to Build-Depends-Indep. * Annotate with . Both techniques render the affected dependencies irrelevant to cross building. I've taken the time to figure out which dependencies can be reduced and verified that doing so results in bit-identical .deb files (if you fix the build path). As such I'm quite confident that these annotations are correct. Please consider applying the attached patch. After applying it, the size of the dependency problem for cross compilation should be significantly reduced. Helmut diff --minimal -Nru libapache2-mod-perl2-2.0.11/debian/changelog libapache2-mod-perl2-2.0.11/debian/changelog --- libapache2-mod-perl2-2.0.11/debian/changelog2019-10-13 18:06:30.0 +0200 +++ libapache2-mod-perl2-2.0.11/debian/changelog2020-02-14 06:17:04.0 +0100 @@ -1,3 +1,10 @@ +libapache2-mod-perl2 (2.0.11-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Reduce Build-Depends using and B-D-I. (Closes: #-1) + + -- Helmut Grohne Fri, 14 Feb 2020 06:17:04 +0100 + libapache2-mod-perl2 (2.0.11-1) unstable; urgency=medium [ gregor herrmann ] diff --minimal -Nru libapache2-mod-perl2-2.0.11/debian/control libapache2-mod-perl2-2.0.11/debian/control --- libapache2-mod-perl2-2.0.11/debian/control 2019-10-13 16:18:00.0 +0200 +++ libapache2-mod-perl2-2.0.11/debian/control 2020-02-14 06:17:04.0 +0100 @@ -10,19 +10,19 @@ Priority: optional Build-Depends: perl, apache2-dev, - apache2 (>= 2.4~), + apache2 (>= 2.4~) , debhelper (>= 10), - libbsd-resource-perl, - libcgi-pm-perl, - libdevel-symdump-perl, - libhtml-parser-perl, + libbsd-resource-perl , + libcgi-pm-perl , + libdevel-symdump-perl , + libhtml-parser-perl , libhtml-template-perl, libperl-dev, libreadonly-perl, - libwww-perl, - locales-all, - netbase, - rename + libwww-perl , + locales-all , + netbase , +Build-Depends-Indep: rename Build-Conflicts: apache2-mpm-event Standards-Version: 4.4.1 Vcs-Browser: https://salsa.debian.org/perl-team/modules/packages/libapache2-mod-perl2
Bug#951317: www.debian.org: make favicon the same an the all debian websites
Package: www.debian.org Severity: normal Dear Maintainer, at least packages.debian.org and snapshot.debian.org use old favicon. It should be the same on the all debian sites as on www.debian.org, bugs.debian.org, tracker.debian.org and other. See screenshot attached.
Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted
Am 14.02.20 um 12:05 schrieb Andreas Henriksson: > Hello, > > On Thu, Feb 13, 2020 at 02:21:00PM +0100, Michael Biebl wrote: >> Am 13.02.20 um 14:03 schrieb Trent W. Buck: > [...] >>> 78root@DESKTOP-P00TKMM:/# udevadm trigger >>> Failed to scan devices: No such file or directory >> >> You should only get this error message if /sys is not mounted. >> I assume your chroot has neither /sys nor /proc mounted. >> >> >> systemd-udevd.service has >> ConditionPathIsReadWrite=/sys >> >> You could try to convince upstream to add a similar check to "udevadm >> trigger" >> > > Just wanted to chime in here and say that another way at looking at this > is to say that calling udevadm (and expecting it to exit with success) > when udev is not running could possibly be considered the bug. > > (Or in other words, it feels wrong to me to expect udevadm to exit with > success when it's failing to do the job it was asked to do.) > > From a simple codesearch.debian.net search I can see there are atleast > some packages which tries to only conditionally run udevadm, eg. via > 'pidof udevd && udevadm ...' and similar in their maintainer scripts. The question is, whether such a check should be centralized or not. systemd-udev-trigger.service also has ConditionPathIsReadWrite=/sys We could update all maintainer scripts to wrap that udevadm call into a if [ -w /sys ]; then ... fi but it doesn't appear to me as the worst idea to move this check directly into udevadm and let "udevadm trigger" log a warning/notice and exit 0 if /sys is not writeable. Michael So signature.asc Description: OpenPGP digital signature
Bug#951316: snapshot.debian.org: favicon update
Package: snapshot.debian.org Severity: normal Dear Maintainer, please updade favicon for snapshot.debian.org. It should be the same as on www.debian.org, bugs.debian.org, tracker.debian.org and other. See screenshot attached.
Bug#951257: udevadm: please exit nonzero with "Running in chroot, ignoring request." when /proc is not mounted
Hello, On Thu, Feb 13, 2020 at 02:21:00PM +0100, Michael Biebl wrote: > Am 13.02.20 um 14:03 schrieb Trent W. Buck: [...] > > 78root@DESKTOP-P00TKMM:/# udevadm trigger > > Failed to scan devices: No such file or directory > > You should only get this error message if /sys is not mounted. > I assume your chroot has neither /sys nor /proc mounted. > > > systemd-udevd.service has > ConditionPathIsReadWrite=/sys > > You could try to convince upstream to add a similar check to "udevadm > trigger" > Just wanted to chime in here and say that another way at looking at this is to say that calling udevadm (and expecting it to exit with success) when udev is not running could possibly be considered the bug. (Or in other words, it feels wrong to me to expect udevadm to exit with success when it's failing to do the job it was asked to do.) From a simple codesearch.debian.net search I can see there are atleast some packages which tries to only conditionally run udevadm, eg. via 'pidof udevd && udevadm ...' and similar in their maintainer scripts. (Note: this particular check might not be considered perfect, just one example. This check will still fail if udevd is running in the host and you're working in a chroot. That might be considered your fault for not using a separate namespace though, ie. via systemd-nspawn.) Regards, Andreas Henriksson
Bug#951315: linux-image-amd64 vs linux-headers-amd64 Debian buster-backports version mismatch bpo.2 vs bpo.3
Package: linux-image-amd64 Severity: normal X-Debbugs-CC: whonix-de...@whonix.org Dear maintainer, package linux-image-amd64 seems to have an outdated dependency. https://packages.debian.org/buster-backports/linux-image-amd64 shows dep: linux-image-5.4.0-0.bpo.2-amd64 (= 5.4.8-1~bpo10+1) https://packages.debian.org/buster-backports/linux-headers-amd64 shows dep: linux-headers-5.4.0-0.bpo.3-amd64 (= 5.4.13-1~bpo10+1) bpo.2 vs bpo.3 I am under the assumption that dependency version of linux-image-amd64 should match dependency version of linux-headers-amd64. In comparsion to buster (non-backports) the version matches. Kindly let me know if that is an unreasonable assumption. Bumped into this issue by running: sudo apt-get -t buster-backports install linux-image-$(dpkg --print-architecture) linux-headers-$(dpkg --print-architecture) and then having DKMS report: /etc/kernel/postinst.d/dkms: Error! Your kernel headers for kernel 5.4.0-0.bpo.2-amd64 cannot be found. Please install the linux-headers-5.4.0-0.bpo.2-amd64 package, or use the --kernelsourcedir option to tell DKMS where it's located Which was unexpected. Cheers, Patrick
Bug#951314: bugs.debian.org: Laptop does not resume when undocked while suspended.
Package: bugs.debian.org Severity: normal Dear Maintainer, * What led up to the situation? Undocking my suspended Laptop and resumed it in the train. * What exactly did you do (or not do) that was effective (or ineffective)? Suspended the laptop the night before (via the sleep button). Opened the lid a day later after I unplugged it from the dock. * What was the outcome of this action? Screen was blank. Switching to other virtual consoles did not work. No reaction to alt+ctrl+del shortcut. Only reboot by pressing the power button for several seconds worked for me. * What outcome did you expect instead? Open the lid, see the lock screen, log in. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt
On Thu, Feb 13, 2020 at 08:21:27PM +0100, Wolfgang Schweer wrote: > On Wed, Feb 12, 2020 at 08:20:08PM +0100, Wolfgang Schweer wrote: > > On Wed, Feb 12, 2020 at 07:09:21PM +, Mike Gabriel wrote: > > > The simpleness of the fetch-ldap-cert version you propose is > > > tempting. But this version will only work against TJENERs that have > > > a Debian-Edu_rootCA.crt exported via www.intern. > > Considering... > > [Mike] > > > This assures that Debian-Edu_rootCA is available in the system-wide CA > > bundle in /etc/ssl/certs/ca-certificates.crt. > > > This issue relates to #926388 (let Firefox trust > > /etc/ssl/certs/ca-certificates.crt) > > ...let's me think, that this bug is only fixable for Debian Edu 10 and > higher anyway. Some more thoughts: My proposed script could be added as fetch-rootca-cert because that's what it's all about. The fetch-ldap-cert script would be kept in bullseye (and retired in bullseye+1 aka bookworm). fetch-rootca- could then go into buster-pu, I guess. Also, the firefox-esr policies file (already in the master branch) should be shipped for buster-pu. The policies file makes shure that FF-ESR shows the green padlock also in case a user changes the password using gosa-desktop (which is the recommended way to do that). It is actually quite bad to be warned about a certificate issue and an insecure connection just in this case. Reason for the gosa-desktop issue: On first call, a new FF profile is created on the fly. IMO the additional profile issue can't be solved with the p11-kit-trust.so method, which is now deprecated in favour of the pocicies one, see e.g.: https://wiki.mozilla.org/CA/AddRootToFirefox I've tested an appropiately updated d-e-config package both on a buster 10.3 main server and on a buster 10.3 roaming workstation (w/ your fixes present for that one). Works ok in both cases, green padlocks in all cases mentioned above. Wolfgang signature.asc Description: PGP signature
Bug#951313: openprinting-ppds: MemoryError
Package: openprinting-ppds
Version: 20181217-2
Severity: normal
Dear Maintainer,
openprinting-ppds requires too much memory, and doesn't handle this case
correctly:
% /usr/lib/cups/driver/openprinting-ppds cat
openprinting-ppds:0/ppd/openprinting/Samsung/PXL/Samsung_M262x_282x_Series_PXL.ppd
Traceback (most recent call last):
File "/usr/lib/cups/driver/openprinting-ppds", line 119, in
main()
File "/usr/lib/cups/driver/openprinting-ppds", line 95, in main
ppd = cat(args[1])
File "/usr/lib/cups/driver/openprinting-ppds", line 67, in cat
ppds['ARCHIVE'] =
BytesIO(decompress(base64.b64decode(ppds['ARCHIVE'].encode('ASCII'
File "/usr/lib/cups/driver/openprinting-ppds", line 17, in decompress
return process.communicate(value)[0]
File "/usr/lib/python3.7/subprocess.py", line 939, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/lib/python3.7/subprocess.py", line 1711, in _communicate
stdout = b''.join(stdout)
MemoryError
zsh: exit 1 /usr/lib/cups/driver/openprinting-ppds cat
% free
totalusedfree shared buff/cache available
Mem: 986Mi55Mi 698Mi 0.0Ki 233Mi 762Mi
Swap:0B 0B 0B
Bug#951312: networking: unsetting ipv6 brings many problems
Package: networking Severity: grave Justification: causes non-serious data loss Dear Maintainer, * What led up to the situation? lost of networking, caused by dhcp not renewing IP address * What exactly did you do (or not do) that was effective (or ineffective)? disabled ipv6 * What was the outcome of this action? dhcp 3442 non zero exit error * What outcome did you expect instead? well... Networking to work :-) Longer description: unsetting ipv6 (/etc/sysctl.conf -> net.ipv6.conf.all.disable_ipv6 = 0 net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.lo.disable_ipv6 = 0) generates dhcp 3442 non zero error. Disabling 3442 (dhclient.conf, removing request rfc3442-classless-static-routes) raises RTNETLINK answers: Permission denied -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#951253: FTBFS with Boost 1.71
Hi, Il 13/02/20 13:56, Bas Couwenberg ha scritto: >> Er, no actual reason. This setup works for me and nobody ever asked me >> to upload to experimental. I can do that anyway, if that's better for >> you. > > Yes, please. Done. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
Bug#951310: transition: pmix
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This is a mini-transition for pmix. The new pmix (pmix3) is in experimental; one further change is needed to add Breaks/Replaces before an unstable upload, (as libpmix2 and libpmix3 unfortunately conflict in one lib they both provide internally). There is one reverse dependency - openmpi - which needs changes to work with pmix3. This is done and ready to go in Git. Ben file: title = "pmix"; is_affected = ; is_good = ; is_bad = ; -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#951309: Please update tesseract-lang to the latest git packaging
Package: tesseract-lang Please update tesseract-lang to the latest git packaging: https://github.com/AlexanderP/tesseract-lang-debian
Bug#936806: koji: Python2 removal in sid/bullseye
On 2/14/20 2:30 AM, Holger Levsen wrote: > On Thu, Feb 13, 2020 at 08:14:11PM -0500, Sandro Tosi wrote: >> thanks! I'm gonna go ahead and file an RM bug for the following pkgs >> too: yum createrepo python-lzma yum-metadata-parser mock yum-utils >> dtc-xen deltarpm >> >> they are a closed set > > thank you for cleaning up after all of us, now that we reached containers. > (which used to be called virtualisation mainframes before... ;) > > I mean, rpm is definitly still useful to have on Debian, but yum and > friends??? I am the one that maintained yum for about a decade in Debian. Yum is (was?) useful because it does the same thing as debootstrap. Ie: with it, you can bootstrap a CentOS chroot from a Debian host, which may be useful for example if using Xen (or other virtualization systems). That was in fact my use case. Anyway, yum is kind of dead, as distros have been moving to dnf. I see therefore no reason to keep it. Cheers, Thomas Goirand (zigo)
Bug#949468: satpy: autopkgtest regression due to new pygac
control: forwarded -1 https://github.com/pytroll/satpy/pull/1045 control: tags -1 fixed-upstream Hello https://github.com/pytroll/satpy/pull/1045 Here you can find the discussion related and here a build log of a failure: https://launchpadlibrarian.net/464927743/buildlog_ubuntu-focal-amd64.satpy_0.19.1-2_BUILDING.txt.gz INFO:satpy.readers:Cannot use ['/<>/satpy/etc/readers/avhrr_l1b_hrpt.yaml'] DEBUG:satpy.readers:while constructing a Python object cannot find module 'satpy.readers.hrpt' (No module named 'pygac.gac_calibration') in "", line 93, column 22: file_reader: !!python/name:satpy.readers.hrpt ... ^ DEBUG:satpy.readers:Reading ['/<>/satpy/etc/readers/ami_l1b.yaml'] (note: Ubuntu default to python3.8, so this might be a reason for you not yet failing the build process) Looks like there is a new build error today, funny G. On Wed, 22 Jan 2020 08:41:33 +0100 Antonio Valentino wrote: > Dear Gianfranco, > > On Tue, 21 Jan 2020 18:03:01 +0100 Gianfranco Costamagna > wrote: > > control: severity -1 important > > > > On Tue, 21 Jan 2020 09:28:40 +0100 Gianfranco Costamagna > > wrote: > > > Source: satpy > > > Version: 0.19.1-1 > > > Severity: serious > > > > > > Hello, looks like pygac update regressed the testsuite. > > > I requested a new run in Debian, but in the meanwhile you can see a run > > > here: > > > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/satpy/20200120_195040_eac9b@/log.gz > > > > > > or here: > > > http://debomatic-amd64.debian.net/distribution#unstable/satpy/0.19.1-1/autopkgtest > > > > > > (and even inside the build process itself the error is thrown out, but > > > for some reasons the testsuite errors are somewhat ignored at least in > > > that part) > > > > > > > looks like the debian autopkgtest is green, and the "killed" is an > > ubuntu-only thing. > > > > However, my patch has been merged upstream, so the gac issue is fixed. > > > > G. > > > Sorry Gianfranco but the problem is not clear to me. > > Apart for the killed test run, satpy is failing in testing due to a > missing dependency (behave) which has been removed form testing. > > I don't see any issue related to pygac, am I missing something? > > Also can you please give me a pointer to the patch that has been merged > upstream? > > > kind regards > > -- > Antonio Valentino > >
Bug#951308: alot: needs versioned dependency on a higher python3-gpg version
Package: alot
Version: 0.9-1
Severity: normal
Hi,
with python3-gpg 1.12.0-4 I get the following error when opening alot:
Traceback (most recent call last):
File "/usr/share/alot/alot/crypto.py", line 261, in
_decrypt_verify_with_context
encrypted, verify=True)
File "/usr/lib/python3/dist-packages/gpg/core.py", line 432, in decrypt
raise errors.BadSignatures(verify_result, results=results)
gpg.errors.BadSignatures: C91B325B77F252FB: No public key
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/alot", line 11, in
load_entry_point('alot==0.9', 'console_scripts', 'alot')()
File "/usr/share/alot/alot/__main__.py", line 137, in main
UI(dbman, cmdstring)
File "/usr/share/alot/alot/ui.py", line 141, in __init__
self.mainloop.run()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 286, in run
self._run()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 384, in _run
self.event_loop.run()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1340, in run
reraise(*exc_info)
File "/usr/lib/python3/dist-packages/urwid/compat.py", line 58, in reraise
raise value
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1354, in
wrapper
rval = f(*args,**kargs)
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1313, in
_twisted_idle_callback
callback()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 572, in
entering_idle
self.draw_screen()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 586, in
draw_screen
canvas = self._topmost_widget.render(self.screen_size, focus=True)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/decoration.py", line 226, in render
canv = self._original_widget.render(size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/container.py", line 1086, in render
focus and self.focus_part == 'body')
File "/usr/share/alot/alot/buffers/buffer.py", line 19, in render
return self.body.render(size, focus)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 471, in render
(maxcol, maxrow), focus=focus)
File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 416, in
calculate_visible
next, pos = self._body.get_next( pos )
File "/usr/share/alot/alot/walker.py", line 46, in get_next
return self._get_at_pos(start_from + self.direction)
File "/usr/share/alot/alot/walker.py", line 72, in _get_at_pos
widget = self._get_next_item()
File "/usr/share/alot/alot/walker.py", line 85, in _get_next_item
next_widget = self.containerclass(next_obj, **self.kwargs)
File "/usr/share/alot/alot/widgets/search.py", line 26, in __init__
self.rebuild()
File "/usr/share/alot/alot/widgets/search.py", line 61, in rebuild
self.structure[partname])
File "/usr/share/alot/alot/widgets/search.py", line 145, in build_text_part
content = prepare_string(name, thread, maxw)
File "/usr/share/alot/alot/widgets/search.py", line 213, in prepare_string
s = content(thread)
File "/usr/share/alot/alot/widgets/search.py", line 188, in
prepare_content_string
lastcontent = ' '.join(m.get_body_text() for m in msgs)
File "/usr/share/alot/alot/widgets/search.py", line 188, in
lastcontent = ' '.join(m.get_body_text() for m in msgs)
File "/usr/share/alot/alot/db/message.py", line 266, in get_body_text
return extract_body(self.get_email())
File "/usr/share/alot/alot/db/message.py", line 105, in get_email
f.read(), self._session_keys)
File "/usr/share/alot/alot/db/utils.py", line 306, in
decrypted_message_from_bytes
session_keys)
File "/usr/share/alot/alot/db/utils.py", line 263, in
decrypted_message_from_message
_handle_encrypted(m, m, session_keys)
File "/usr/share/alot/alot/db/utils.py", line 176, in _handle_encrypted
sigs, d = crypto.decrypt_verify(payload, session_keys)
File "/usr/share/alot/alot/crypto.py", line 226, in decrypt_verify
return _decrypt_verify_with_context(ctx, encrypted)
File "/usr/share/alot/alot/crypto.py", line 266, in
_decrypt_verify_with_context
(plaintext, _, _) = ctx.decrypt(encrypted, verify=False)
File "/usr/lib/python3/dist-packages/gpg/core.py", line 431, in decrypt
for s in verify_result.signatures):
AttributeError: 'NoneType' object has no attribute 'signatures'
The problem is solved by upgrading python3-gpg to 1.13.1-6. Thus, alot
should gain a versioned dependency.
Thanks!
cheers, josch
Bug#951307: ITP: smartdns -- local DNS server to obtain the fastest IP for the best experience
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: smartdns * URL : https://github.com/pymumu/smartdns/releases * License : GPL-3+ Programming Lang: C Description : local DNS server to obtain the fastest IP for the best experience The package is already usable here: (I've not done the the code check and license check yet) https://salsa.debian.org/debian/smartdns I'll upload to to NEW after finishing the remaining checks and my local assessment.
Bug#949834: (no subject)
Cant' reproduce, I was using 68.4.1esr-1~deb10u1, today I upgraded to 68.5.0esr-1~deb10u1, everything works fine. System is Debian Buster 10 on AMD64.
Bug#951216: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest
> Can I suggest two things at this point? First, could you attach your
> generated test.pdf to this bug so that we are completely on the same
> page and using the exactly the same file? Secondly, perhaps you could
> systematically alter the settings of reprotest in order to identify
> which is the variation employed that is causing this to happen?
I've attached test.pdf as requested.
I've also tried to create a dummy package (attached) to reproduce the
problem. Unfortunately
reprotest .
fails with:
unshare: echec de unshare: �� �
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 843,
in run
return 0 if check_func(*check_args) else 1
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 369,
in check
local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 369,
in
local_dists += [proc.send(nv) for nv in zip(bnames[1:],
build_variations[1:])]
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 329,
in corun_builds
bctx.run_build(testbed, build, os.environ, artifact_pattern,
testbed_build_pre, no_clean_on_error)
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 220,
in run_build
kind='build')
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 64,
in check_exec2
adtlog.AutopkgtestError)
File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 70,
in bomb
raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "sh -ec run_build() {
mkdir -p /tmp/reprotest.pyacok/build-experiment-1-aux && \
SETARCH_ARCH=$(setarch --list | grep -vF "$(uname -m)" | shuf | head
-n1) && \
KERNEL_VERSION=$(uname -r) && \
if [ ${KERNEL_VERSION#2.6} = $KERNEL_VERSION ]; then
SETARCH_OPTS=--uname-2.6; fi && \
CPU_MAX=$(nproc) && \
CPU_MIN=$({ echo $CPU_MAX; echo 1; } | sort -n | head -n1) && \
CPU_NUM=$(if [ $CPU_MIN = $CPU_MAX ]; then echo
$CPU_MIN; echo >&2 "only 1 CPU is available; num_cpus is ineffective";
else shuf -i$((CPU_MIN + 1))-$CPU_MAX -n1; fi) && \
mv /tmp/reprotest.pyacok/build-experiment-1/
/tmp/reprotest.pyacok/build-experiment-1-before-disorderfs/ && \
mkdir -p /tmp/reprotest.pyacok/build-experiment-1/ && \
disorderfs -q --shuffle-dirents=yes
/tmp/reprotest.pyacok/build-experiment-1-before-disorderfs/
/tmp/reprotest.pyacok/build-experiment-1/ && \
umask 0002 && \
export
REPROTEST_BUILD_PATH=/tmp/reprotest.pyacok/build-experiment-1/ && \
export REPROTEST_UMASK=$(umask) && \
unshare -r --uts sh -ec '
hostname reprotest-capture-hostname
domainname "reprotest-capture-domainname"
"$@"' - \
faketime +294days+15hours+41minutes \
taskset -a -c $(echo $(shuf -i0-$((CPU_MAX - 1)) -n$CPU_NUM) | tr '
' ,) \
setarch $SETARCH_ARCH $SETARCH_OPTS \
sh -ec 'cd "$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH;
umask "$REPROTEST_UMASK"; unset REPROTEST_UMASK; dpkg-buildpackage
--no-sign -b'
}
cleanup() {
__c=0; \
export PATH="/tmp/reprotest.pyacok/bin:$PATH" || __c=$?; \
fusermount -u /tmp/reprotest.pyacok/build-experiment-1/ || __c=$?; \
rmdir /tmp/reprotest.pyacok/build-experiment-1/ || __c=$?; \
mv /tmp/reprotest.pyacok/build-experiment-1-before-disorderfs/
/tmp/reprotest.pyacok/build-experiment-1/ || __c=$?; \
rm -rf /tmp/reprotest.pyacok/build-experiment-1-aux || __c=$?; \
exit $__c
}
trap '( cleanup )' HUP INT QUIT ABRT TERM PIPE # FIXME doesn't quite
work reliably yet
if ( run_build ); then ( cleanup ); else
__x=$?; # save the exit code of run_build
if ( ! false ); then
if ( cleanup ); then :; else echo >&2 "cleanup failed with exit
code $?"; fi;
fi
exit $__x
fi" failed with status 1
test.pdf
Description: Adobe PDF document
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.0
Source: reprotest-pdfinfo
Binary: reprotest-pdfinfo
Architecture: all
Version: 1-1
Maintainer: Jeffrey Ratcliffe
Standards-Version: 4.5.0
Build-Depends: debhelper-compat (= 12)
Build-Depends-Indep: imagemagick, poppler-utils
Package-List:
reprotest-pdfinfo deb utils optional arch=all
Checksums-Sha1:
4f89e6a7ebc24a7ae440282c146459cf1dffc8ed 902 reprotest-pdfinfo_1-1.tar.gz
Checksums-Sha256:
d359d5e8f7f30fd540e7b475c47964604dda2a0d178187c14655da6183028316 902
reprotest-pdfinfo_1-1.tar.gz
Files:
ac3e1938ec1d9ffc701983e11d534aae 902 reprotest-pdfinfo_1-1.tar.gz
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEERjKT5K4zhxhG8wInsyHyAxEPyvMFAl5GWtkACgkQsyHyAxEP
yvMm5Q/+O+Pcq+M0VEDeqKFfBVlPmZwNHo1O46BCLBzEwlJM4VmXE0vAUWUXLBCn
YYL+dmCD3+DlHZ8+xqmHnvLGQYgEXU9pW61EwdJH09SC5EoiMjpXGjIJE8S+VQqM
8lyugLXY/ttCB3sOKPYgAoLPj19LN/WLjTTyDoG2QSa+Yl38U9CVohiwTxb8crnw
fXHTn2Pkju1kwwRgDaKhmEhCCKwAITsToba3i0iLTHobVK2HXbRp4FCxlg8jqAFJ
YTuZRHHFHEkJJ32zssryFA69RA5wlEWbXFUWfUJKwUPp9vhvu/Pm/KLYXZ1Ga6GP
Bug#693587: bind9: stop resolving
On Jan 16, Marco d'Itri wrote: > > Since we finally have 9.15 in experimental, could you please try this > > and give feedback? > Testing. Confirmed: 9.15 fixed this. -- ciao, Marco signature.asc Description: PGP signature
Bug#951306: snek: unsatisfiable b-d on picolibc-arm-none-eabi
Source: snek Version: 1.3-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, snek build-depends on picolibc-arm-none-eabi which does not exist (yet) in sid. -Ralf.
Bug#951305: r-cran-rockchalk: unsatisfiable build-dependency on r-cran-kutils
Source: r-cran-rockchalk Version: 1.8.144+dfsg-1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, r-cran-rockchalk build-depends on r-cran-kutils which does not exist in sid. -Ralf
