Bug#928181: aptitude-robot: aptitude-robot-session removes aptitude's "forbid-version" flags
Package: aptitude-robot Version: 1.5.1-1 Severity: normal If I flag the new (e.g. uninstablable) version of an upgradable package as "forbid-version" (e.g. with Shift-F inside the aptitude TUI) and then run aptitude-robot-session, these flags are reproducibly no more set. They should be kept like e.g. hold flags are kept and honoured. Workaround: Use /etc/apt/preferences or /etc/apt/preferences.d/ for this, e.g. like this: # cat /etc/apt/preferences.d/dont-upgrade-to-version-without-plugin Explanation: 1.6.2-3.1+deb9u1 only removes the browser plugins which we still need for old IMMs Package: icedtea-netx* Pin: version 1.6.2-3.1+deb9u1 Pin-Priority: -1 # -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages aptitude-robot depends on: ii aptitude 0.8.7-1 ii libmoo-perl2.002005-1 ii librun-parts-perl 0.09-2 ii lsb-base 9.20161125 ii perl 5.24.1-3+deb9u5 ii psmisc 22.21-2.1+b2 Versions of packages aptitude-robot recommends: ii perl-doc 5.24.1-3+deb9u5 Versions of packages aptitude-robot suggests: ii apt-listbugs 0.1.22 ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 ii needrestart 2.11-3+deb9u1 pn needrestart-session ii xymon-client [hobbit-client] 4.3.28-2 -- Configuration Files: /etc/default/aptitude-robot changed: RUN_DAILY=yes MAX_RANDOM_DELAY_SECONDS=900 RUN_ON_BOOT=yes LOG_SESSION=/var/log/aptitude-robot-session.log LOGFILE=/var/log/aptitude-robot.log MAX_LOGFILES_SIZE_BLOCKS=100 SESSION_REPORT_COMMAND=/usr/share/aptitude-robot/xymon-report SUPPRESS_CRON_MAILS=no POST_SESSION_HOOK= -- no debconf information
Bug#928180: unblock: fortunes-zh/2.95
Control: retitle -1 unblock: fortune-zh/2.95 The source package should be called "fortune-zh" instead of "fortunes-zh". Sorry for the typo. -- Thanks, Boyuan Yang Boyuan Yang 于2019年4月29日周一 上午10:14写道： > > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-CC: fortunes...@packages.debian.org > > Please unblock fortunes-zh 2.95. The new upload fixes > https://bugs.debian.org/928138 , which is a typo in the fortune cookie > file that caused grammar error and misbehavior of the program. It's > literally a one-line fix. > > The full debdiff is pasted here. Note that I removed a trailing space > in quotes.d/bingxin.cookie . > > -- > Regards, > Boyuan Yang > > diff -Nru fortune-zh-2.94/debian/changelog fortune-zh-2.95/debian/changelog > --- fortune-zh-2.94/debian/changelog2019-01-03 08:08:01.0 -0500 > +++ fortune-zh-2.95/debian/changelog2019-04-28 16:02:39.0 -0400 > @@ -1,3 +1,11 @@ > +fortune-zh (2.95) unstable; urgency=medium > + > + * Team upload. > + * quotes.d/bingxin.cookie: Remove a trailing space that triggered > +fortune cookie grammar error. (Closes: #928138) > + > + -- Boyuan Yang Sun, 28 Apr 2019 16:02:39 -0400 > + > fortune-zh (2.94) unstable; urgency=medium > >* Misc updates for the Debian Reference cookie generator: > diff -Nru fortune-zh-2.94/quotes.d/bingxin.cookie > fortune-zh-2.95/quotes.d/bingxin.cookie > --- fortune-zh-2.94/quotes.d/bingxin.cookie2018-02-07 > 00:03:33.0 -0500 > +++ fortune-zh-2.95/quotes.d/bingxin.cookie2019-04-28 > 15:48:22.0 -0400 > @@ -10,4 +10,4 @@ > 假如生命是乏味的，我怕有来生。 > 假如生命是有趣的，今生已是满足的了！ >-- 冰心《往事（一）》 > -% > +%
Bug#928044: libwebkit2gtk-4.0-37: version 2.24.1-1 does not play some streams
On Fri, Apr 26, 2019 at 08:08:52PM +0200, Richard Lucassen wrote: > After an upgrade from 2.22.7 to 2.24.1-1, libwebkit2gtk refuses > to play some radio streams. Downgrade to 2.22.7 resolves the > problem. Seen on 4 different machines. The browser I use is > "surf". The audio system is ALSA. I haven't had the time to test this yet, but we suspect that this is a regression between 2.24.0 and 2.24.1 caused by this patch: https://trac.webkit.org/changeset/243197/webkit Can you try 2.24.0 and see if it works? https://snapshot.debian.org/package/webkit2gtk/2.24.0-1/ Thanks! Berto
Bug#928180: unblock: fortunes-zh/2.95
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: fortunes...@packages.debian.org Please unblock fortunes-zh 2.95. The new upload fixes https://bugs.debian.org/928138 , which is a typo in the fortune cookie file that caused grammar error and misbehavior of the program. It's literally a one-line fix. The full debdiff is pasted here. Note that I removed a trailing space in quotes.d/bingxin.cookie . -- Regards, Boyuan Yang diff -Nru fortune-zh-2.94/debian/changelog fortune-zh-2.95/debian/changelog --- fortune-zh-2.94/debian/changelog2019-01-03 08:08:01.0 -0500 +++ fortune-zh-2.95/debian/changelog2019-04-28 16:02:39.0 -0400 @@ -1,3 +1,11 @@ +fortune-zh (2.95) unstable; urgency=medium + + * Team upload. + * quotes.d/bingxin.cookie: Remove a trailing space that triggered +fortune cookie grammar error. (Closes: #928138) + + -- Boyuan Yang Sun, 28 Apr 2019 16:02:39 -0400 + fortune-zh (2.94) unstable; urgency=medium * Misc updates for the Debian Reference cookie generator: diff -Nru fortune-zh-2.94/quotes.d/bingxin.cookie fortune-zh-2.95/quotes.d/bingxin.cookie --- fortune-zh-2.94/quotes.d/bingxin.cookie2018-02-07 00:03:33.0 -0500 +++ fortune-zh-2.95/quotes.d/bingxin.cookie2019-04-28 15:48:22.0 -0400 @@ -10,4 +10,4 @@ 假如生命是乏味的，我怕有来生。 假如生命是有趣的，今生已是满足的了！ -- 冰心《往事（一）》 -% +%
Bug#928125: Revert commit 310ca162d77
On Mon, Apr 29, 2019 at 02:05:42PM +0200, Salvatore Bonaccorso wrote: > Hi Jan, hi Greg, > > On Wed, Mar 20, 2019 at 01:58:06PM +0100, Jan Kara wrote: > > Hello, > > > > commit 310ca162d77 "block/loop: Use global lock for ioctl() operation." has > > been pushed to multiple stable trees. This patch is a part of larger series > > that overhauls the locking inside loopback device upstream and for 4.4, > > 4.9, and 4.14 stable trees only this patch from the series is applied. Our > > testing now has shown [1] that the patch alone makes present deadlocks > > inside loopback driver more likely (the openqa test in our infrastructure > > didn't hit the deadlock before whereas with the new kernel it hits it > > reliably every time). So I would suggest we revert 310ca162d77 from 4.4, > > 4.9, and 4.14 kernels. > > A user in Debian reported [1], providing the following testcase which showed > up > after the recent update to 4.9.168-1 in Debian stretch (based on upstream > v4.9.168) as follows: > > dd if=/dev/zero of=/tmp/ff1.raw bs=1G seek=8 count=0 > sync > sleep 1 > parted /tmp/ff1.raw mklabel msdos > parted -s /tmp/ff1.raw mkpart primary linux-swap 1 100 > parted -s -- /tmp/ff1.raw mkpart primary ext2 101 -1 > parted -s -- /tmp/ff1.raw set 2 boot on > sleep 5 > losetup -Pf /tmp/ff1.raw --show > > I have verified that the same happens with v4.9.171 where the mentioned commit > was not reverted, and bisecting of the testcase showed it was introduced with > 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 (v4.9.152~9) (which is the backport > of > 310ca162d77 for 4.9). > > Reverting 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 on top of v4.9.171 worked > and fixed the respective issue. > > Can this commit in meanwhile be reverted or is there further ongoing work in > integrating the followup fixes as mentioned in > https://lore.kernel.org/stable/20190321104110.gf29...@quack2.suse.cz/ . Sorry for the delay here. No, I didn't find any time for the followup stuff here, and Jan is right, this should just be dropped. I've now reverted it from 3.18.y, 4.4.y, 4.9.y, and 4.14.y. thanks, greg k-h
Bug#928179: Installation creates /etc/apt/sources.liste
Package: waagent Version: 2.2.34-3~deb9u1 Severity: normal In the azure stretch image, there is a stray /etc/apt/sources.liste file. Initial investigation by waldi found a bad "sed -ie" call in waagent. Christoph
Bug#928158: ITP: g15daemon -- provides multiple virtual screens for the LCD on the Logitech G11 and G15 keyboards.
Hi, On Mon, 29 Apr 2019 04:36:01 +0300 Alexander Ponyatykh wrote: > Package: wnpp > Severity: wishlist > Owner: Alexander Ponyatykh > > * Package name: g15daemon > Version : 1.9.5.3 > Upstream Authors: Mike Lampard , Sven Ludwig, James > Green, Philip Lawatsch > * URL : https://sourceforge.net/p/g15daemon/code/HEAD/tree/trunk/ > * License : GPL v2 or later > Programming Lang: C > Description : G15daemon provides multiple virtual screens for the LCD > on the Logitech G11 and G15 keyboards. > > I would like to reintroduce this package. It was deleted at the request of > the previous maintainer because of the abandoned upstream. While it is true > that it is no longer being developed, this is not a problem, because it is > completed, works as intended almost flawlessly, and most bugs have been > already fixed by the community. > > G15daemon is the only way to use LCD of Logitech keyboards, there are no > alternatives. > > Here is my Ubuntu PPA with the latest version of the package, cleaned up and > converted to the 3.0 format: > https://launchpad.net/~lazyranma/+archive/ubuntu/g15daemon > > I will need a sponsor to review and upload new packages. I’d like to sponsor your packages. Are you a Git user? Giacomo hasn’t used Git for his packaging work, but I have imported the history to the following repositories at Salsa: - https://salsa.debian.org/debian/libg15 - https://salsa.debian.org/debian/g15daemon If you haven’t yet got an account at Salsa, please create one, and submit merge requests against those repos so that I can review your changes. -- Cheers, Andrej signature.asc Description: OpenPGP digital signature
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
On Mon, Apr 29, 2019 at 01:22:18PM +, Holger Levsen wrote: > On Mon, Apr 29, 2019 at 01:10:39PM +, Holger Levsen wrote: > > On Mon, Apr 29, 2019 at 03:08:49PM +0200, Santiago Vila wrote: > > > We can tell people to upgrade to the latest point release before > > > upgrading. > > > Every software vendor, not just so-called linux distros, recommend > > > such kind of things. > > thats not how Debian works since 20 years... > > as in: we can fix this properly (=not requiring people to read release > notes or doing special steps), and we should do that (=make it just > work). > > how: thats the open question I had in my initial reply to this bug > report to Andreas. So, what kind of package relationship will fix this, and in which package? (Depends/Conflicts/Breaks). > > > As I said in the other bug, the root problem for this is to make the > > > error to be fatal. So, the time-bomb in stable is exploding now. Let > > > deactivate the bomb once and forever before it explodes again when > > > upgrading from buster to bullseye. > > you are again mixing bugs. > > as in: once we fix #928172 for the buster upgrade, we can apply the same > fix for the bullseye update, so #927450 doesnt become an "exploding time > bomb". This is where we seem to disagree. If I add a Breaks or a Conflicts in base-files, I would do it only for this time and only because we can't fix the package debian-security-support retroactively in stable (well, we could, but as you say, and I agree, we can't be sure that the user will upgrade to the latest point release before upgrading). However, I consider adding a Breaks to be a hack (or slighly hackish if you prefer). As far as the error in debian-security-support is fatal (i.e. the other bug you would like to ignore), we will have to repeat this Conflicts/Breaks thing again. That's not very appealing. So the "we can apply the same fix for the bullseye update" is what I dislike, because the fix will surely be hacky. I would not have to track debian-security-support releases every time I make the final base-files upload for a stable release. > if we now could please focus on #928172 and ignore #927450 for now, > that would be great. (and "ignoring #927450" also means not mixing them > up.) Let's focus on #928172 if you like. I try not to mix them up, but I believe they are strongly related in the sense that the reason #928172 is serious now is that the package in stable still has #927450. Thanks.
Bug#926708: unblock: otrs2/6.0.17-1
Am 09.04.2019 um 18:51 schrieb Ivo De Decker: > Hi, > > On 4/9/19 2:59 PM, Patrick Matthäi wrote: >> Am 09.04.2019 um 14:46 schrieb Ivo De Decker: > >>> Being in non-free doesn't give you an exception to the freeze. >> Sorry you are right, I totaly forget it.. >> It was an exception for fglrx in the past-past, but because it was also >> closed source, so no fixes could be adapted. >> >> I will prepare a diff along with other security fixes (I think there >> will be one in the next time) if they are out > > OK. Do you have an idea about the timeframe of this future release? > > I will prepare an upload for tomorrow and ask for a pre approval. Should I open a new bug then or use this? -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
Bug#928178: thunderbird fails to start sayng that is already running
Package: thunderbird Version: 1:60.6.1-1~deb9u1 Severity: grave Tags: d-i Justification: renders package unusable Dear Maintainer, after recently updates thunderbird fails to start with the message: "Thunderbird is already running, but is not responding. To open a new window, you must first close the existing Thunderbird process, or restart your system." In /var/log/syslog I can find: Apr 29 12:06:40 psala-lx2 kernel: [ 5131.606429] audit: type=1400 audit(1556532400.993:264): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5131.707820] audit: type=1400 audit(1556532401.093:265): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5131.808901] audit: type=1400 audit(1556532401.197:266): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5131.909833] audit: type=1400 audit(1556532401.297:267): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5132.010927] audit: type=1400 audit(1556532401.397:268): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5132.111760] audit: type=1400 audit(1556532401.497:269): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5132.212797] audit: type=1400 audit(1556532401.601:270): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5132.313764] audit: type=1400 audit(1556532401.701:271): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5132.414863] audit: type=1400 audit(1556532401.801:272): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:41 psala-lx2 kernel: [ 5132.515785] audit: type=1400 audit(1556532401.901:273): apparmor="DENIED" operation="file_lock" profile="thunderbird" name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" pid=4393 comm="thunderbird" requested_mask="k" denied_mask="k" fsuid=21046 ouid=21046 Apr 29 12:06:46 psala-lx2 kernel: [ 5136.710721] kauditd_printk_skb: 40 callbacks suppressed Apr 29 12:06:46 psala-lx2 kernel: [ 5136.710726] audit: type=1400 audit(1556532406.097:314): apparmor="DENIED" operation="open" profile="thunderbird" name="/etc/ld.so.conf" pid=4393 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=21046 ouid=0 If I disable apparmor for thunderbird (aa-disable /etc/apparmor.d/usr.bin.thunderbird) the problem seems to be solved. I don't know which update cause this problem any way these are the packages I have last updated: Commandline: packagekit role='update-packages' Install: firebird3.0-server-core:amd64 (3.0.1.32609.ds4-14, automatic), linux- headers-4.19.0-0.bpo.4-amd64:amd64 (4.19.28-2~bpo9+1, automatic), libtommath1:amd64 (1.0-4, automatic), linux-image-4.19.0-0.bpo.4-amd64:amd64 (4.19.28-2~bpo9+1, automatic), libfbclient2:amd64 (3.0.1.32609.ds4-14, automatic), libreoffice-sdbc-firebird:amd64 (1:6.1.5-3~bpo9+1, automatic), libreoffice-style-elementary:amd64 (1:6.1.5-3~bpo9+1, automatic), libreoffice- help-common:amd64 (1:6.1.5-3~bpo9+1, automatic), linux- headers-4.19.0-0.bpo.4-common:amd64 (4.19.28-2~bpo9+1, automatic), libreoffice- style-colibre:amd64 (1:6.1.5-3~bpo9+1, automatic), libboost-locale1.62.0:amd64 (1.62.0+dfsg-4, automatic), libib-util:amd64 (3.0.1.32609.ds4-14, automatic), linux-kbuild-4.19:amd64 (4.19.28-2~bpo9+1, automatic), firebird3.0-common- doc:amd64 (3.0.1.32609.ds4-14, automatic), firebird
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
On Mon, Apr 29, 2019 at 01:10:39PM +, Holger Levsen wrote: > On Mon, Apr 29, 2019 at 03:08:49PM +0200, Santiago Vila wrote: > > We can tell people to upgrade to the latest point release before upgrading. > > Every software vendor, not just so-called linux distros, recommend > > such kind of things. > thats not how Debian works since 20 years... as in: we can fix this properly (=not requiring people to read release notes or doing special steps), and we should do that (=make it just work). how: thats the open question I had in my initial reply to this bug report to Andreas. > > As I said in the other bug, the root problem for this is to make the > > error to be fatal. So, the time-bomb in stable is exploding now. Let > > deactivate the bomb once and forever before it explodes again when > > upgrading from buster to bullseye. > you are again mixing bugs. as in: once we fix #928172 for the buster upgrade, we can apply the same fix for the bullseye update, so #927450 doesnt become an "exploding time bomb". if we now could please focus on #928172 and ignore #927450 for now, that would be great. (and "ignoring #927450" also means not mixing them up.) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#928177: etckeeper: Ubuntu patches to port to python3/breezy, use UTF8 and newer debhelper
Package: etckeeper
Version: 1.18.10-1
Severity: normal
Dear Maintainer,
Breezy is the python3 port of bazaar-ng, and I've added a plugin for
that. Otherwise cmdline utility is compatible with bzr invocation.
We also observed an ordering bug due to inconsistent locale usage,
thus switched to unicode C locale by default.
Also deprecated debhelper is in use, and I upgraded to debhelper 11.
Please consider applying/including all or some of these patches.
Regards,
Dimitri.
From b5919d7919dda614c3c3c76ba126f45e205494bd Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov
Date: Mon, 29 Apr 2019 14:11:09 +0100
Subject: [PATCH 1/3] Add breezy python3 plugin
---
Makefile | 3 +++
debian/changelog | 6 ++
debian/control| 6 +++---
etckeeper-brz/__init__.py | 34 ++
4 files changed, 46 insertions(+), 3 deletions(-)
create mode 100644 etckeeper-brz/__init__.py
diff --git a/Makefile b/Makefile
index bac3fd5..c0cb23d 100644
--- a/Makefile
+++ b/Makefile
@@ -16,11 +16,13 @@ INSTALL=install
INSTALL_EXE=${INSTALL}
INSTALL_DATA=${INSTALL} -m 0644
PYTHON=python
+PYTHON3=python3
FAKEROOT := $(shell command -v fakeroot 2> /dev/null)
TESTDIR := $(shell mktemp -u -d)
build: etckeeper.spec etckeeper.version
-$(PYTHON) ./etckeeper-bzr/__init__.py build || echo "** bzr support
not built"
+ -$(PYTHON3) ./etckeeper-brz/__init__.py build || echo "** bzr support
not built"
-$(PYTHON) ./etckeeper-dnf/etckeeper.py build || echo "** DNF support
not built"
install: etckeeper.version
@@ -66,6 +68,7 @@ ifeq ($(HIGHLEVEL_PACKAGE_MANAGER),zypper)
$(INSTALL) zypper-etckeeper.py
$(DESTDIR)$(prefix)/lib/zypp/plugins/commit/zypper-etckeeper.py
endif
-$(PYTHON) ./etckeeper-bzr/__init__.py install --root=$(DESTDIR)
${PYTHON_INSTALL_OPTS} || echo "** bzr support not installed"
+ -$(PYTHON3) ./etckeeper-brz/__init__.py install --root=$(DESTDIR)
${PYTHON_INSTALL_OPTS} || echo "** brz support not installed"
echo "** installation successful"
clean: etckeeper.spec etckeeper.version
diff --git a/debian/changelog b/debian/changelog
index aca3d97..9457eb2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+etckeeper (1.18.11) UNRELEASED; urgency=medium
+
+ * Add breezy python3 plugin
+
+ -- Dimitri John Ledkov Mon, 29 Apr 2019 14:04:46 +0100
+
etckeeper (1.18.10) unstable; urgency=medium
* Avoid post-install failing when ps is from busybox or another
diff --git a/debian/control b/debian/control
index 7e3b8dc..f948a26 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
Source: etckeeper
Section: admin
Priority: optional
-Build-Depends: debhelper (>= 7), dpkg-dev (>= 1.9.0), bzr (>= 1.5~), python,
dh-python, bats, fakeroot
+Build-Depends: debhelper (>= 7), dpkg-dev (>= 1.9.0), brz, python2, python3,
dh-python, bats, fakeroot
Maintainer: Antoine Beaupré
Standards-Version: 3.9.8
XS-Python-Version: all
@@ -11,11 +11,11 @@ Homepage: http://etckeeper.branchable.com/
Package: etckeeper
Architecture: all
Section: admin
-Depends: git (>= 1:1.7) | mercurial | bzr (>= 1.5~) | darcs, ${misc:Depends}
+Depends: git (>= 1:1.7) | mercurial | brz | bzr (>= 1.5~) | darcs,
${python3:Depends}, ${misc:Depends}
Recommends: cron-daemon
Suggests: sudo (>= 1.7.4p4)
Conflicts: bzr (<< 1.5~)
-Description: store /etc in git, mercurial, bzr or darcs
+Description: store /etc in git, mercurial, brz, bzr or darcs
The etckeeper program is a tool to let /etc be stored in a git, mercurial,
bzr or darcs repository. It hooks into APT to automatically commit changes
made to /etc during package upgrades. It tracks file metadata that version
diff --git a/etckeeper-brz/__init__.py b/etckeeper-brz/__init__.py
new file mode 100644
index 000..5f04ba6
--- /dev/null
+++ b/etckeeper-brz/__init__.py
@@ -0,0 +1,34 @@
+#
+# Breezy plugin that runs etckeeper pre-commit when necessary
+
+"""Runs etckeeper pre-commit when necessary."""
+
+from breezy.errors import BzrError
+import os
+
+def etckeeper_startcommit_hook(tree):
+abspath = getattr(tree, "abspath", None)
+if abspath is None or not os.path.exists(abspath(".etckeeper")):
+# Only run the commit hook when this is an etckeeper branch
+return
+import subprocess
+ret = subprocess.call(["etckeeper", "pre-commit", abspath(".")])
+if ret != 0:
+raise BzrError("etckeeper pre-commit failed")
+
+try:
+from breezy.hooks import install_lazy_named_hook
+except ImportError:
+from breezy.mutabletree import MutableTree
+MutableTree.hooks.install_named_hook('start_commit',
+etckeeper_startcommit_hook, 'etckeeper')
+else:
+install_lazy_named_hook(
+"breezy.mutabletree", "MutableTree.hooks",
+'start_commit', etckeeper_startcommit_hook, 'etckeeper')
+
+if __name__ == "__main__":
+from distutils.core import setup
+setup(name="brz-etckeeper",
+ packages=[
Bug#921599: [debian-mysql] Bug#921599: mariadb-10.3: always connects to localhost ignoring host entry in option file
Apparently the comment in your Github PR was wrong then in https://github.com/MariaDB/mariadb-connector-c/pull/101#issuecomment-466809308 I asked also you where the commit is in the MR at https://salsa.debian.org/mariadb-team/mariadb-10.3/merge_requests/15 Could you please research and verify here what version the commit is shipped in? Or maybe research if it broke something and was reverted before release? Thanks for your help! - Otto
Bug#921599: [debian-mysql] Bug#921599: mariadb-10.3: always connects to localhost ignoring host entry in option file
Hi Otto, On Thu, Apr 18, 2019 at 10:25:00PM +0300, Otto Kekäläinen wrote: > This is pending since > https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/5046bb4fc2a8ff47a1cf139eba468286a29fcf13 > > Should be fixed when 10.3.14-1 is uploaded. unfortunately, this is not the case. The changes from my merge request (same as https://github.com/MariaDB/mariadb-connector-c/pull/101) are not included in the mariadb-10.3 1:10.3.14-1 source, and testing shows that a hostname set through my.cnf is ignored. Florian
Bug#928176: vlc: BOBOOvlc cannot play cd audio without net connection and crash
Package: src:vlc Version: 3.0.6-0+deb9u1 Severity: normal Dear Maintainer, * What led up to the situation? remove wire cable from ethernet play cd audio with vlc * What exactly did you do (or not do) that was effective (or ineffective)? with net connection, vlc can play cd audio and display title from cddb protocol * What was the outcome of this action? fix network connection * What outcome did you expect instead? to be able to play cd audio without internet connection -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 'unstable'), (55, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vlc depends on: ii dpkg 1.18.25 ii vlc-bin 3.0.6-0+deb9u1 ii vlc-l10n 3.0.6-0+deb9u1 ii vlc-plugin-base 3.0.6-0+deb9u1 ii vlc-plugin-qt3.0.6-0+deb9u1 ii vlc-plugin-video-output 3.0.6-0+deb9u1 Versions of packages vlc recommends: ii vlc-plugin-notify 3.0.6-0+deb9u1 ii vlc-plugin-samba 3.0.6-0+deb9u1 ii vlc-plugin-skins2 3.0.6-0+deb9u1 ii vlc-plugin-video-splitter 3.0.6-0+deb9u1 ii vlc-plugin-visualization 3.0.6-0+deb9u1 vlc suggests no packages. Versions of packages libvlc-bin depends on: ii libc62.24-11+deb9u4 ii libvlc5 3.0.6-0+deb9u1 Versions of packages libvlc5 depends on: ii dpkg 1.18.25 ii libc62.24-11+deb9u4 ii libvlccore9 3.0.6-0+deb9u1 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.6-0+deb9u1 Versions of packages vlc-bin depends on: ii libc6 2.24-11+deb9u4 ii libvlc-bin 3.0.6-0+deb9u1 ii libvlc5 3.0.6-0+deb9u1 Versions of packages vlc-plugin-base depends on: ii dpkg 1.18.25 ii liba52-0.7.4 0.7.4-19 ii libarchive13 3.2.2-2+deb9u1 ii libasound2 1.1.3-5 ii libass5 1:0.13.4-2 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libavc1394-0 0.5.4-4+b1 ii libavcodec57 7:3.2.12-1~deb9u1 ii libavformat577:3.2.12-1~deb9u1 ii libavutil55 7:3.2.12-1~deb9u1 ii libbasicusageenvironment12016.11.28-1+deb9u2 ii libbluray1 1:0.9.3-3 ii libc62.24-11+deb9u4 ii libcairo21.14.8-1 ii libcddb2 1.3.2-5 ii libchromaprint1 1.4.2-1 ii libcrystalhd31:0.0~git20110715.fdd2f19-12 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdc1394-22 2.2.5-1 ii libdca0 0.0.5-10 ii libdvbpsi10 1.3.0-5 ii libdvdnav4 5.0.3-3 ii libdvdread4 5.0.3-2 ii libebml4v5 1.3.4-1 ii libfaad2 2.8.0~cvs20161113-1+deb9u1 ii libflac8 1.3.2-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libfribidi0 0.19.7-1+b1 ii libgcc1 1:6.3.0-18+deb9u1 ii libgcrypt20 1.7.6-2+deb9u3 ii libglib2.0-0 2.50.3-2 ii libgnutls30 3.5.8-5+deb9u4 ii libgpg-error01.26-2 ii libgroupsock82016.11.28-1+deb9u2 ii libharfbuzz0b1.4.2-1 ii libjpeg62-turbo 1:1.5.1-2 ii libkate1 0.4.1-7+b1 ii liblirc-client0 0.9.4c-9 ii liblivemedia57 2016.11.28-1+deb9u2 ii liblua5.2-0 5.2.4-1.1+b2 ii libmad0 0.15.1b-8+deb9u1 ii libmatroska6v5 1.4.5-2 ii libmicrodns0 0.0.3-3 ii libmpcdec6 2:0.1~r495-1+b1 ii libmpeg2-4 0.5.1-7+b2 ii libmpg123-0 1.23.8-1+b1 ii libmtp9 1.1.13-1 ii libncursesw5 6.0+20161126-1+deb9u2 ii libnfs8 1.11.0-2 ii libogg0 1.3.2-1 ii libopenmpt-modplug1 0.2.7386~beta20.3-3+deb9u3 ii libopus0 1.2~alpha2-1 ii libpng16-16 1.6.28-1+deb9u1 ii libpostproc54
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
On Mon, Apr 29, 2019 at 03:08:49PM +0200, Santiago Vila wrote: > We can tell people to upgrade to the latest point release before upgrading. > Every software vendor, not just so-called linux distros, recommend > such kind of things. thats not how Debian works since 20 years... > As I said in the other bug, the root problem for this is to make the > error to be fatal. So, the time-bomb in stable is exploding now. Let > deactivate the bomb once and forever before it explodes again when > upgrading from buster to bullseye. you are again mixing bugs. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#848890: New MP in Salsa to re-consider these changes.
Hi, I have created a new MP in Salsa to re-consider these changes. I have updated and cleared a lot, but also skipped the mass enabling for now to focus on the rest of the changes first. Please see: https://salsa.debian.org/debian/strongswan/merge_requests/5
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
On Mon, Apr 29, 2019 at 12:34:18PM +, Holger Levsen wrote: > And even if we fixed stable in a point release we still need to > support upgrades from previours stretch point releases. We can tell people to upgrade to the latest point release before upgrading. Every software vendor, not just so-called linux distros, recommend such kind of things. As I said in the other bug, the root problem for this is to make the error to be fatal. So, the time-bomb in stable is exploding now. Let deactivate the bomb once and forever before it explodes again when upgrading from buster to bullseye. Thanks.
Bug#925911: RFS: lopsub-1.0.2 [ITP]
On Mon, Apr 22, 17:30, Andre Noll wrote > > But in general, the package already seems to be in a releasable state. > > Could you please change "UNRELEASED" to "unstable" so it can be uploaded? > > Done. Please have a final look. If everything is fine, I can merge > the various topic branches to master (so that master becomes what is > pu now), and tag the result as v1.0.3. Ping Andre -- Max Planck Institute for Developmental Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/ signature.asc Description: PGP signature
Bug#926992: unblock: sia/1.3.0-1.1
Control: reopen -1 Control: retitle -1 unblock: sia/1.3.0-1.1~deb10u1 [t-p-u] On 2019-04-29 07:42, Niels Thykier wrote: > Ok, can you prepare a t-p-u upload to fix this directly in testing then? What is the correct (or preferred) distribution for t-p-u uploads ? "buster" or "testing-proposed-updates" ? Attached patch uses the latter. Andreas diff -Nru sia-1.3.0/debian/changelog sia-1.3.0/debian/changelog --- sia-1.3.0/debian/changelog 2017-11-01 00:54:54.0 +0100 +++ sia-1.3.0/debian/changelog 2019-04-29 14:21:56.0 +0200 @@ -1,3 +1,17 @@ +sia (1.3.0-1.1~deb10u1) testing-proposed-updates; urgency=medium + + * Non-maintainer upload. + * Rebuild for buster. + + -- Andreas Beckmann Mon, 29 Apr 2019 14:21:56 +0200 + +sia (1.3.0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add 'missingok' to logrotate config. (Closes: #910439) + + -- Andreas Beckmann Sat, 13 Apr 2019 09:42:04 +0200 + sia (1.3.0-1) unstable; urgency=medium [ Bjorn Dolk ] diff -Nru sia-1.3.0/debian/sia.logrotate sia-1.3.0/debian/sia.logrotate --- sia-1.3.0/debian/sia.logrotate 2017-11-01 00:54:54.0 +0100 +++ sia-1.3.0/debian/sia.logrotate 2019-04-13 09:32:11.0 +0200 @@ -3,4 +3,5 @@ copytruncate rotate 14 compress +missingok }
Bug#928118: libzfs2linux: coredump in zfs send -n -v -I A B
Cause and solution are described in some detail here: https://www.reddit.com/r/zfs/comments/bicu1g/zfs_send_issues_a_zfs_ioctl_which_fails_with/em1rj9r/?utm_source=share&utm_medium=web2x -- the cause was a config error, and the solution was to correct the config error. But, when an ioctl() call fails with EINVAL, this should not cause a coredump in the zfs tools. IMO that's still a bug.
Bug#928175: postfix: [Regression/Stretch] No more delivers mails to mailboxes > ca. 500 MB via procmail since upgrade from 3.1.9-0+deb9u2 to 3.1.12-0+deb9u1
Package: postfix
Version: 3.1.12-0+deb9u1
Severity: grave
Affects: procmail
Justfication: causes data loss (after a few days), breaks (more or less)
unrelated packages (procmail)
Dear Debian Postfix Maintainers,
* What led up to the situation?
Since a few minutes after upgrading Postfix on Stretch from
3.1.9-0+deb9u2 to 3.1.12-0+deb9u1, procmail (!) on my server has been
unable to deliver mails to mailboxes bigger than some threshold:
procmail: Error while writing to "/home/abe/mbox"
procmail: Truncated file to former size
procmail: Error while writing to "/var/mail/abe"
procmail: Truncated file to former size
procmail itself has last been updated with the dist-upgrade of that box
from Jessie to Stretch.
This threshold seems somewhere between 472 MB and 609 MB (see below), so
I suspect it to be 500 MB or 512 MB, as the examples of mailboxes to
which or to which not procmail could deliver mail are clearly separated
by their size:
Postfix via procmail has delivered mails into these mailboxes since the
upgrade:
$ tail -42720 procmail-log.2019-04 | egrep "Folder: [^*]" | awk '{print $2}' |
sort -u | xargs ls -lhSr --
-rw--- 1 abe users 4.4M Apr 29 04:49 -spam.4
-rw--- 1 abe users 7.9M Apr 29 10:15 -spam.3
-rw--- 1 abe users 11M Apr 29 13:09 -spam.2
-rw--- 1 abe users 16M Apr 29 12:10 -spam.20
-rw--- 1 abe users 48M Apr 28 16:43 -pkg-xen-devel
-rw--- 1 abe users 74M Apr 29 07:30 -debian-www
-rw--- 1 abe users 77M Apr 29 06:31 -debian-apt
-rw--- 1 abe users 110M Apr 28 20:24 -zsh
-rw--- 1 abe users 115M Apr 29 13:58 -spam.5
-rw--- 1 abe users 128M Apr 29 09:42 -debian-lintian
-rw--- 1 abe users 138M Apr 29 12:13 -debian-sparc
-rw--- 1 abe users 183M Apr 29 08:18 -debian-qa
-rw--- 1 abe users 438M Apr 28 19:43 -spam.15
-rw--- 1 abe users 472M Apr 29 09:17 -news
Postfix via procmail wasn't able to deliver mails into these mailboxes
since the upgrade:
$ tail -42720 procmail-log.2019-04 | fgrep "Error while writing to" | sort -u |
awk -F'"' '{print $2}' | xargs ls -lhSr --
lrwxrwxrwx 1 abe users 13 Jun 25 2018 /home/abe/mbox -> /var/mail/abe
-rw--- 1 abe users 606M Apr 29 13:25 -debian-arm
-rw--- 1 abe users 612M Apr 29 13:24 -debian-boot
-rw--- 1 abe users 737M Apr 29 13:25 -debian-release
-rw--- 1 abe users 838M Apr 29 08:00 -spam.10
-rw--- 1 abe users 952M Apr 29 13:52 -debian
-rw--w 1 abe mail 1.4G Apr 29 13:53 /var/mail/abe
-rw--- 1 abe users 5.9G Apr 29 13:33 -logcheck
This is IMHO sufficiently enough statistically relevant data to show
that the imposed limit is somewhere around 500 MB.
The more recent timestamps of the files procmail couldn't deliver mail
to are explained by it stating that it tried to append something (which
failed) and trunkated the file to its original size — which doesn't
reset the timestamp.
Mutt on the same system can easily write to mailboxes at the size of up
to at least 1.8 GB, so it's not a system-wide issue.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Upgrading postfix on Stretch from 3.1.9-0+deb9u2 to 3.1.12-0+deb9u1 via
aptitude-robot (similar to unattended-upgrades, just with more
flexibility).
* What was the outcome of this action?
Since then my procmail log shows error messages like these for any
mailbox bigger than approx. 500 MB:
>From MAILER-DAEMON Mon Apr 29 13:33:45 2019
Subject: Delayed Mail (still being retried)
Folder: **Requeued** 2898
procmail: Extraneous locallockfile ignored
procmail: Error while writing to "/home/abe/mbox"
procmail: Truncated file to former size
procmail: Error while writing to "/var/mail/abe"
procmail: Truncated file to former size
>From MAILER-DAEMON Mon Apr 29 13:38:45 2019
Subject: Delayed Mail (still being retried)
Folder: **Requeued** 2900
procmail: Extraneous locallockfile ignored
procmail: Error while writing to "/home/abe/mbox"
procmail: Truncated file to former size
procmail: Error while writing to "/var/mail/abe"
procmail: Truncated file to former size
* What outcome did you expect instead?
- Same limits as before.
- Honor the mailbox_size_limit set in /etc/postfix/main.cf as before.
(According to
https://www.mhonarc.org/archive/html/procmail/2003-01/msg00224.html
postfix's mailbox_size_limit affects delivery via procmail.)
- Don't have any previously not existent effect on procmail.
JFTR:
~ → fgrep mailbox_size_limit /etc/postfix/main.cf
mailbox_size_limit = 0
Downgrading Postfix to 3.1.9-0+deb9u2 again (without touching the
procmail package or any configuration setting besides setting VERBOSE=1
in .procmailrc for debugging) fixed the issue for me. Now mails are
delivered again to mailbox up to at least 6.0 GB.
Unfortunately I haven't found anything which seemed relevant in the
3.1.12-0+deb9u1 debian/changelog entry, upstream changelog (HISTORY)
entires
Bug#745800: should be fixed in 2.8.0
Hello, according to amavisd changelog, this bug should be fixed in 2.8.0 https://www.ijs.si/software/amavisd/release-notes.txt amavisd-new-2.8.0 release notes - removed an old compatibility measure: default value of @banned_admin_maps was changed from: @banned_admin_maps = (\$banned_admin, \%virus_admin, \$virus_admin); to a more consistent: @banned_admin_maps = (\$banned_admin); The previous default value of @banned_admin_maps tried to maintain compatibility with versions before the setting was separated from its companion @virus_admin_maps. Now this compatibility is no longer considered necessary and contributes to some confusion, so it was dropped. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Despite the cost of living, have you noticed how popular it remains?
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
On Mon, Apr 29, 2019 at 02:27:14PM +0200, Santiago Vila wrote: > This is because debian-security-support in testing is still incompatible > with base-files in sid, as reported here: yes, sure... > Paradoxically, the version in unstable is supposed to fix this. it does, #927450 is fixed (and since then has been (*) reopened in anticipation of the same issue for the next release), but this doesnt fix the problem that the hook from d-s-s < 2019.04.25 is still used when upgrading from testing now (as it doesnt have 2019.04.25) or from stable as well. if d-s-s is upgraded before base-files, the upgrade now works nicely. if however basefiles is upgrades before d-s-s, it doesn't. That's the bug Andreas has reported as #928172. (*) sadly. a new bug would have been much better. > So I wonder if we could fix this problem without making any upload at > all, for example, by allowing debian-security-support to propagate to > testing *before* I ask for base-files to be allowed in testing. > > Holger, what do you think? as I tried to explain above, this wont fix the issue of upgrading from stable. And even if we fixed stable in a point release we still need to support upgrades from previours stretch point releases. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#928173: .
I did a cross check with Apache 2.4.39 on my FreeBSD box, it is working as expected.
Bug#922097: inkscape stops with message complaining about an internal illegal instruction on start
Hello André Isidoro Fernandes Esteves, do you still see this crash? If yes, could you please provide the output of following search: grep -Rn arbow_type /usr If you create another user, is the problem also visible there? Kind regards, Bernhard
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
On Mon, Apr 29, 2019 at 01:24:26PM +0200, Andreas Beckmann wrote: > >From the attached log (scroll to the bottom...): > > Unpacking base-files (10.2) over (10.1) ... > Setting up base-files (10.2) ... > Installing new version of config file /etc/debian_version ... > Installing new version of config file /etc/issue ... > Installing new version of config file /etc/issue.net ... > dpkg: error: error executing hook 'if [ -x > /usr/share/debian-security-support/check-support-status.hook ] ; then > /usr/share/debian-security-support/check-support-status.hook ; fi', exit code > 256 > E: Sub-process /usr/bin/dpkg returned an error code (2) This is because debian-security-support in testing is still incompatible with base-files in sid, as reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927450 Paradoxically, the version in unstable is supposed to fix this. So I wonder if we could fix this problem without making any upload at all, for example, by allowing debian-security-support to propagate to testing *before* I ask for base-files to be allowed in testing. Holger, what do you think? Thanks.
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
Hmm, not sure that allowing debian-security-support in testing is a good idea. What would happen with upgrades from stable to testing in such case? I think it would also fail for the same reason. Maybe we should really make the error not to be fatal in version 2019.02.02~deb9u2 in stretch? Thanks.
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
Hi Andreas, thanks for filing this bug report! On Mon, Apr 29, 2019 at 01:24:26PM +0200, Andreas Beckmann wrote: > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. > It installed fine in 'testing', then the upgrade to 'sid' fails. [...] > dpkg: error: error executing hook 'if [ -x > /usr/share/debian-security-support/check-support-status.hook ] ; then > /usr/share/debian-security-support/check-support-status.hook ; fi', exit code > 256 > E: Sub-process /usr/bin/dpkg returned an error code (2) this happens when base-files is upgraded before debian-security-support. So I'm wondering if this needs d-s-s to conflict on base-files < 10 or a pre-depends or what? -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
Basically what happens is that the patch 'ostree-stub.patch' produces an empty file 'ostree_src.go' and the compiler doesn't accept an empty Go file. My affirmation WRT the path can be confirmed by reading the patch itself [2] or just applying it. [2] https://salsa.debian.org/go-team/packages/golang-github-containers-image/blob/master/debian/patches/ostree-stub.patch#L1104 The error reported by the compiler is (see full buildlog below): can't load package: package github.com/containers/image/ostree: obj-x86_64-linux-gnu/src/github.com/containers/image/ostree/ostree_src.go:1:1: expected 'package', found 'EOF' On Mon, 2019-04-29 at 07:29 -0400, Reinhard Tartler wrote: > I'm having a hard time understanding what issue you are facing with and what > you mean fix "fix manually". How are you building the package? Are you using > git-buildpackage, sbuild or pbuilder? I'd > strongly recommend to do so, because if you were, I cannot see how you > possibly could run into such issues. I'm using none of them, I'm building "the hard way": in a container (from Docker base image debian:sid-slim) with a script that runs the individual steps and builds with 'dpkg-buildpackage'. It should be possible to build these packages this way, right? It usually works. I prefer not to use too much magic (although using containers involves per-se some magic) to better understand what's going on. What I meant with "fix manually" is executing "rm ostree/ostree_src.go" right after patching and before building. I don't know if the 'magic' of any of the mentioned tools is just silently fixing the issue for you and that's why you are not facing it... > In any case, a full buildlog, similar to what I attached, could be helpful. > If English is a language barrier, try explaining in German. I don't think that it's a language barrier. But possibly an expertise barrier: my expertise on building Debian packages (specially for Go) is not as extensive as yours :-) --- dpkg-buildpackage: info: source package golang-github-containers-image dpkg-buildpackage: info: source version 1.5-1 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by Reinhard Tartler dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . debian/rules clean dh clean --buildsystem=golang --with=golang dh_auto_clean -O--buildsystem=golang dh_autoreconf_clean -O--buildsystem=golang dh_clean -O--buildsystem=golang debian/rules build dh build --buildsystem=golang --with=golang dh_update_autotools_config -O--buildsystem=golang dh_autoreconf -O--buildsystem=golang dh_auto_configure -O--buildsystem=golang debian/rules override_dh_auto_build make[1]: Entering directory '/debian-packages/golang-github-containers-image' dh_auto_build -O--buildsystem=golang -- -tags "containers_image_ostree_stub" can't load package: package github.com/containers/image/ostree: obj-x86_64-linux-gnu/src/github.com/containers/image/ostree/ostree_src.go:1:1: expected 'package', found 'EOF' cd obj-x86_64-linux-gnu && go install -gcflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -asmflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -v -p 4 -tags containers_image_ostree_stub github.com/containers/image github.com/containers/image/copy github.com/containers/image/directory github.com/containers/image/directory/explicitfilepath github.com/containers/image/docker github.com/containers/image/docker/archive github.com/containers/image/docker/daemon github.com/containers/image/docker/policyconfiguration github.com/containers/image/docker/reference github.com/containers/image/docker/tarfile github.com/containers/image/image github.com/containers/image/internal/testing/explicitfilepath-tmpdir github.com/containers/image/internal/testing/mocks github.com/containers/image/internal/tmpdir github.com/containers/image/manifest github.com/containers/image/oci github.com/containers/image/oci/archive github.com/containers/image/oci/internal github.com/containers/image/oci/layout github.com/containers/image/pkg/blobinfocache github.com/containers/image/pkg/compression github.com/containers/image/pkg/docker/config github.com/containers/image/pkg/strslice github.com/containers/image/pkg/sysregistries github.com/containers/image/pkg/sysregistriesv2 github.com/containers/image/pkg/tlsclientconfig github.com/containers/image/signature github.com/containers/image/storage github.com/containers/image/tarball github.com/containers/image/transports github.com/containers/image/transports/alltransports github.com/containers/image/types github.com/containers/image/version github.com/containers/image errors internal/race internal/cpu runtime/internal/sys runtime/internal/atomic sync/atomic unicode unicode/utf8 internal/testlog internal/bytealg math math/bits encoding unicode/utf16
Bug#928125: Revert commit 310ca162d77
Hi Jan, hi Greg, On Wed, Mar 20, 2019 at 01:58:06PM +0100, Jan Kara wrote: > Hello, > > commit 310ca162d77 "block/loop: Use global lock for ioctl() operation." has > been pushed to multiple stable trees. This patch is a part of larger series > that overhauls the locking inside loopback device upstream and for 4.4, > 4.9, and 4.14 stable trees only this patch from the series is applied. Our > testing now has shown [1] that the patch alone makes present deadlocks > inside loopback driver more likely (the openqa test in our infrastructure > didn't hit the deadlock before whereas with the new kernel it hits it > reliably every time). So I would suggest we revert 310ca162d77 from 4.4, > 4.9, and 4.14 kernels. A user in Debian reported [1], providing the following testcase which showed up after the recent update to 4.9.168-1 in Debian stretch (based on upstream v4.9.168) as follows: dd if=/dev/zero of=/tmp/ff1.raw bs=1G seek=8 count=0 sync sleep 1 parted /tmp/ff1.raw mklabel msdos parted -s /tmp/ff1.raw mkpart primary linux-swap 1 100 parted -s -- /tmp/ff1.raw mkpart primary ext2 101 -1 parted -s -- /tmp/ff1.raw set 2 boot on sleep 5 losetup -Pf /tmp/ff1.raw --show I have verified that the same happens with v4.9.171 where the mentioned commit was not reverted, and bisecting of the testcase showed it was introduced with 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 (v4.9.152~9) (which is the backport of 310ca162d77 for 4.9). Reverting 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 on top of v4.9.171 worked and fixed the respective issue. Can this commit in meanwhile be reverted or is there further ongoing work in integrating the followup fixes as mentioned in https://lore.kernel.org/stable/20190321104110.gf29...@quack2.suse.cz/ . Regards, Salvatore [1] https://bugs.debian.org/928125
Bug#928174: haskell-raaz: FTBFS: hlibrary.setup: Encountered missing dependencies: base >=4.6 && <4.11
Source: haskell-raaz Version: 0.2.0-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + libghc-raaz-dev libghc-raaz-doc Hi, haskell-raaz FTBFS in unstable https://buildd.debian.org/status/package.php?p=haskell-raaz&suite=unstable Running debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/raaz-0.2.0/ --datasubdir=raaz --htmldir=/usr/share/doc/libghc-raaz-doc/html/ --enable-library-profiling --enable-tests Using Parsec parser Configuring raaz-0.2.0... CallStack (from HasCallStack): die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:958:20 in Cabal-2.2.0.1:Distribution.Simple.Configure configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:462:12 in Cabal-2.2.0.1:Distribution.Simple.Configure configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:596:20 in Cabal-2.2.0.1:Distribution.Simple confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.2.0.1:Distribution.Simple.UserHooks configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:178:19 in Cabal-2.2.0.1:Distribution.Simple defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:115:27 in Cabal-2.2.0.1:Distribution.Simple defaultMain, called at Setup.lhs:3:10 in main:Main hlibrary.setup: Encountered missing dependencies: base >=4.6 && <4.11 Andreas
Bug#928171: closed by Michael Biebl (Re: Bug#928171: rsyslog.service does not create PID file reguired by logrotate script)
Am 29.04.19 um 13:24 schrieb IB Development Team: > invoke-rc.d rsyslog rotate > > (used in /etc/logrotate.d/rsyslog and /usr/lib/rsyslog/rsyslog-rotate) invoke-rc.d rsyslog rotate is *not* used in /etc/logrotate.d/rsyslog It is used in /usr/lib/rsyslog/rsyslog-rotate as a fallback when systemd is *not* used, i.e. sysvinit is active. The sysv init script still creates a pid file. See /etc/init.d/rsyslog. > throws error in buster if no rsyslogd pid exists. > > Please verify and fix if confirmed. > I can't verify this error, no. -- 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#928125: losetup causes Dead systemd-udevd processes, blocks forever
Control: tags -1 + confirmed upstream Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=202985 Hi, Some further updates. On Sun, Apr 28, 2019 at 10:58:21PM +0200, Salvatore Bonaccorso wrote: > Hi Michael, Brad, > > On Sun, Apr 28, 2019 at 08:50:38PM +0200, Michael Biebl wrote: > > Control: reassign -1 linux-image-4.9.0-9-amd64 > > Control: severity -1 important > > > > Am 28.04.19 um 20:32 schrieb Brad Barnett: > > > > > > Ack, should have thought of that. > > > > > > Just tested. OK kernel: > > > > > > 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux > > > > > > Borked kernel: > > > > > > 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64 > > > > > > Hmm. Just noticed GNU/Linux tag is missing too.. > > > > > > Thanks for checking, Reassigning to the linux package and bumping > > severity a bit. Seems like something that should be fixed in stable. > > And looks already present in 4.9.161-1 which was an intermediate > upload to stretch-proposed-updates before 4.9.168-1. As well > reproducible with the current WIP for 4.9.171-1 as per [1]. Can confirm as well the issue with upstream 4.9.171 directly. Bisecting showed that it's introduced by 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 (v4.9.152~9) and it relates to this thread: https://lore.kernel.org/stable/20190320125806.gd9...@quack2.suse.cz/ https://bugzilla.kernel.org/show_bug.cgi?id=202985 Regards, Salvatore
Bug#867377: approx: Cleanup cronjob prints all deleted files
Package: approx Version: 5.10-1 Followup-For: Bug #867377 Still present in buster. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-4-armmp (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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) Versions of packages approx depends on: ii adduser 3.118 ii bzip21.0.6-9 ii curl 7.64.0-2 ii libc62.28-8 ii libpcre3 2:8.39-12 ii rsyslog [system-log-daemon] 8.1901.0-1 ii xz-utils 5.2.4-1 approx recommends no packages. Versions of packages approx suggests: pn libconfig-model-approx-perl -- Configuration Files: /etc/approx/approx.conf changed [not included] -- no debconf information
Bug#928171: closed by Michael Biebl (Re: Bug#928171: rsyslog.service does not create PID file reguired by logrotate script)
invoke-rc.d rsyslog rotate (used in /etc/logrotate.d/rsyslog and /usr/lib/rsyslog/rsyslog-rotate) throws error in buster if no rsyslogd pid exists. Please verify and fix if confirmed. -- Regards, Pawel Boguslawski IB Development Team https://dev.ib.pl/ Dnia 2019-04-29, pon o godzinie 11:18 +, Debian Bug Tracking System pisze: > This is an automatic notification regarding your Bug report > which was filed against the rsyslog package: > > #928171: rsyslog.service does not create PID file reguired by logrotate script > > 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. > >
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
I'm having a hard time understanding what issue you are facing with and what you mean fix "fix manually". How are you building the package? Are you using git-buildpackage, sbuild or pbuilder? I'd strongly recommend to do so, because if you were, I cannot see how you possibly could run into such issues. In any case, a full buildlog, similar to what I attached, could be helpful. If English is a language barrier, try explaining in German. Best, Reinhard On April 29, 2019 7:21:09 AM EDT, "Cirujano Cuesta, Silvano" wrote: >Commit c17b0346 is changing the patching of the 'ostree' directory in a >way that generates an invalid Go package. > >Instead of removing 'ostree/ostree_src.go', it's replacing it with an >empty file that breaks 'go build'. > >If I manually fix it, it builds successfully. > >Cheers, > Silvano > >[1] >https://salsa.debian.org/go-team/packages/golang-github-containers-image/commit/c17b0346163f88028e5675600865ac2eb95e051d -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#928173: apache2: SSLCipherSuite is ignored
Package: apache2 Version: 2.4.25-3+deb9u7 Severity: normal Dear Maintainer, I have set SSLCipherSuite "-ALL ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384" in mods-enabled/ssl.conf SSLProtocol is not defined anywhere. SSLCipherSuite is only defined here. According to Qualsys SSL labs test, non-defined ciphers are being used, e.g. ECDHE-RSA-AES128-GCM-SHA256 Expectation: only defined three ciphers are being used. -- Package-specific info: -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages apache2 depends on: ii apache2-bin 2.4.25-3+deb9u7 ii apache2-data 2.4.25-3+deb9u7 ii apache2-utils2.4.25-3+deb9u7 ii dpkg 1.18.25 ii init-system-helpers 1.48 ii lsb-base 9.20161125 ii mime-support 3.60 ii perl 5.24.1-3+deb9u5 ii procps 2:3.3.12-3+deb9u1 Versions of packages apache2 recommends: ii ssl-cert 1.0.39 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii w3m [www-browser]0.5.3-34+deb9u1 Versions of packages apache2-bin depends on: ii libapr1 1.5.2-5 ii libaprutil1 1.5.4-3 ii libaprutil1-dbd-sqlite3 1.5.4-3 ii libaprutil1-ldap 1.5.4-3 ii libc62.24-11+deb9u4 ii libldap-2.4-22.4.44+dfsg-5+deb9u2 ii liblua5.2-0 5.2.4-1.1+b2 ii libnghttp2-141.18.1-1 ii libpcre3 2:8.39-3 ii libssl1.0.2 1.0.2r-1~deb9u1 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii perl 5.24.1-3+deb9u5 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages apache2-bin suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii w3m [www-browser]0.5.3-34+deb9u1 Versions of packages apache2 is related to: ii apache2 2.4.25-3+deb9u7 ii apache2-bin 2.4.25-3+deb9u7 -- Configuration Files: /etc/apache2/conf-available/localized-error-pages.conf changed [not included] /etc/apache2/conf-available/security.conf changed [not included] /etc/apache2/mods-available/deflate.conf changed [not included] /etc/apache2/mods-available/ssl.conf changed [not included] /etc/apache2/ports.conf changed [not included] /etc/apache2/sites-available/000-default.conf changed [not included] /etc/apache2/sites-available/default-ssl.conf changed [not included] /etc/logrotate.d/apache2 changed [not included] -- no debconf information
Bug#928171: closed by Michael Biebl (Re: Bug#928171: rsyslog.service does not create PID file reguired by logrotate script)
Ok /usr/lib/rsyslog/rsyslog-rotate uses systemctl not invoke-rc.d - sorry. -- Regards, Pawel Boguslawski IB Development Team https://dev.ib.pl/ Dnia 2019-04-29, pon o godzinie 13:24 +0200, IB Development Team pisze: > invoke-rc.d rsyslog rotate > > (used in /etc/logrotate.d/rsyslog and /usr/lib/rsyslog/rsyslog-rotate) > throws error in buster if no rsyslogd pid exists. > > Please verify and fix if confirmed. >
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
Package: debian-security-support Version: 2019.04.25 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails. >From the attached log (scroll to the bottom...): Unpacking base-files (10.2) over (10.1) ... Setting up base-files (10.2) ... Installing new version of config file /etc/debian_version ... Installing new version of config file /etc/issue ... Installing new version of config file /etc/issue.net ... dpkg: error: error executing hook 'if [ -x /usr/share/debian-security-support/check-support-status.hook ] ; then /usr/share/debian-security-support/check-support-status.hook ; fi', exit code 256 E: Sub-process /usr/bin/dpkg returned an error code (2) cheers, Andreas debian-security-support_2019.04.25.log.gz Description: application/gzip
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
Commit c17b0346 is changing the patching of the 'ostree' directory in a way that generates an invalid Go package. Instead of removing 'ostree/ostree_src.go', it's replacing it with an empty file that breaks 'go build'. If I manually fix it, it builds successfully. Cheers, Silvano [1] https://salsa.debian.org/go-team/packages/golang-github-containers-image/commit/c17b0346163f88028e5675600865ac2eb95e051d
Bug#928160: [pkg-apparmor] Bug#928160: apparmor-utils: aa-genprof fails with "ERROR: Include file /etc/apparmor.d/local/usr.lib.dovecot.lmtp not found"
Hello,
Am Montag, 29. April 2019, 04:39:05 CEST schrieb hoxp18:
> On Buster, "aa-genprof SOMEPROG" fails with the error message.
>
> root# aa-enabled
> Yes
> root# aa-genprof {firefox,firefox-esr,gedit,file,vim} # did each
> actually
>
> ERROR: Include file /etc/apparmor.d/local/usr.lib.dovecot.lmtp not
> found
>
> The file does not seem to exist in any package.
>
> user$ apt-file search /etc/apparmor.d/local/usr.lib.dovecot.lmtp
>
> nor in /etc
>
> root# find /etc -name usr.lib.dovecot.lmtp -print
>
> I installed apparmor-profiles and apparmor-profiles-extra, too.
/etc/apparmor.d/local/usr.lib.dovecot.lmtp typically gets included by
/etc/apparmor.d/usr.lib.dovecot.lmtp - if you don't have that profile,
please
grep -r usr.lib.dovecot.lmtp /etc/apparmor.d/
I don't know the Debian packaging ("wrong" distribution ;-) but my guess
is that you copied the dovecot profile(s) from /usr/share/apparmor/ to
/etc/apparmor.d/, or got them proposed by aa-genprof, but nobody/nothing
created the local/ includes for them.
As a workaround, you can simply
touch /etc/apparmor.d/local/usr.lib.dovecot.lmtp
(it's an include file where you can add rules specific for your system,
or let it empty if you don't need additional rules)
If you copied more dovecot profiles to /etc/apparmor.d/, you'll probably
need to create local/ include files for each of them. The error messages
will tell you what's missing ;-)
Regards,
Christian Boltz
--
with people like you for sure we would have been still living in a cave
looking for fruits in forests... Fruits are very tasty, why the hell
should we spend time hunting and cooking...
[Alin M Elena in opensuse-factory]
signature.asc
Description: This is a digitally signed message part.
Bug#928066: videogen FTCBFS: force the build architecture compiler
Hi Helmut! > videogen fails to cross build from source, because debian/rules forces > the build architecture compiler upon make. The attached patch defers the > compiler choice to dh_auto_build and makes videogen cross buildable. > Please consider applying it. Thanks for the patch! I'll prepare a new version. Gr, Bas.
Bug#927666: RFS: golang-github-mgutz-str
On Sun, 21 Apr 2019, Jongmin Kim wrote: https://salsa.debian.org/go-team/packages/golang-github-mgutz-str The package was tested on both gbp and sbuild. It's also lintian-clean. Please consider to review and upload it. ... and uploaded. Thorsten
Bug#913344: The "Headphone virtual spatialization effect" setting not working in VLC 3.X when the "Force detection of Dolby Surround" setting is enabled
Seems, no longer present in VLC 3.0.6+ in Unstable - see my comments in https://trac.videolan.org/vlc/ticket/21439 for details.
Bug#928171: rsyslog.service does not create PID file reguired by logrotate script
Package: rsyslog Version: 8.1901.0-1 Logrotate does not notify rsyslog to close its files on rotation because lack of PID file; consider changing -ExecStart=/usr/sbin/rsyslogd -n -iNONE +ExecStart=/usr/sbin/rsyslogd -n -i /run/rsyslogd.pid in /usr/lib/systemd/system/rsyslog.service like in https://github.com/rsyslog/rsyslog-pkg-ubuntu/issues/79 Regards, Pawel IB Development Team https://dev.ib.pl/
Bug#807653: nedit and numeric keypad
Hello, here a few findings from me: 1) NEdit's text window is different from Motifs text widget. IIRC it was derived from it some long time ago. This is the reason, why it behaves different. 2) I do recall in the early 2000s NEdit had some strange behaviours with CAPS-Lock and Numlock etc, so called "modifiers". Ctrl-S did not save when one of the modifiers was on but inserted an control code like . In some later version of NEdit this was fixed. Maybe using some "tricks", which may still be in the code and interfere with a recent Motif. 3) There is a "magic" workaround: I have a "old" machine with NEdit 1:5.6~cvs20081118-8.3 + OpenMotif 2.2.3(*) (Debian 7.1) and a "new" machine with Nedit 1:5.6a-5 + Motif 2.3.4 (Debian 9.8). Recipe: Startup new machine and login via ssh to the old machine and invoke NEdit. Numeric keys work as expected just like working locally on the old machine. Now invoke NEdit on the new machine and the numeric keypad works for the rest of the day! (Until restart of X11 actually). It "works" the other way around, also: Startup old machine and login via ssh to the new machine and invoke NEdit. Numeric keypad is not working but also doesn't work with the local version of NEdit on the old machine. Until restart of X11. For me this is strange, not being familiar with X11-client-server topology. Maybe for someone else it provides a useful hint. (*) You have to self-compile NEdit with OpenMotif 2.2.3-4 to replace LessTif. Markus
Bug#927262: dracut: reboot delayed 2 minutes for stop job running for user manager for UID 0 after new kernel installation
> On Wed, 17 Apr 2019 14:57:31 -0400, Felix Miata > said: > I have more Buster installations not yet using latest kernel. If you could point > to how to capture better information before I do another apt upgrade it could be > very helpful. please prove the output of dpkg -l |grep initramfs -- regards Thomas
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
On Fri, 2019-04-26 at 21:50 -0400, Reinhard Tartler wrote: > Are you sure that you applied the patches from 'debian/patches'? Ups, no. That's probably the issue. I'll let you know if it works or not, once I've tested it. Silvano
Bug#925555: linux-image-4.19.0-4-amd64 causes X regression
I can confirm I've seen the same symptoms on my system. I was unable to get a working X session (although the cursor would appear on one of my two displays). Manual startx would also fail. HW: 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06) Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor DRAM Controller Flags: bus master, fast devsel, latency 0 Capabilities: Kernel driver in use: hsw_uncore 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 26 Memory at f780 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller Flags: bus master, fast devsel, latency 0, IRQ 32 Memory at f7e14000 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) (prog-if 30 [XHCI]) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family USB xHCI Flags: bus master, medium devsel, latency 0, IRQ 24 Memory at f7e0 (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family MEI Controller Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at f7e1e000 (64-bit, non-prefetchable) [size=16] Capabilities: Kernel driver in use: mei_me Kernel modules: mei_me 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family USB EHCI Flags: bus master, medium devsel, latency 0, IRQ 20 Memory at f7e1c000 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset High Definition Audio Controller Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at f7e1 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Capabilities: Kernel driver in use: pcieport 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 18 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: f7d0-f7df Prefetchable memory behind bridge: f000-f00f Capabilities: Kernel driver in use: pcieport 00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 (rev d4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f7c0-f7cf Capabilities: Kernel driver in use: pcieport 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04) (prog-if 20 [EHCI]) S
Bug#928143: unblock: glibc/2.28-9
* Aurelien Jarno: > - Fix for memusagestat's Makefile related code, which has no impact on > the generated code. Sorry, I screwed that one up and had to revert it upstream for the 2.28 branch. I don't think the bug introduced by this commit matters for Debian at present, but it will cause problems if libpthread ever changes internal ABI in buster because with the memusagestat Makefile change, the installed libpthread is used instead of the newly built in-tree libpthread. Previously, the wrong headers were used, and while equally invalid, this created no practical problems. Thanks, Florian
Bug#928170: chrony: Apparmor profile contains wrong path for samba sntp
Package: chrony
Severity: important
Hello, after a few messages on the samba list we discovered a wrong path in the
apparmor profiles of chrony.
File : /etc/apparmor.d/usr.sbin.chrony
Wrong:
# samba4 ntp signing socket
/{,var/}run/samba/ntp_signd/socket rw,
Correct:
# To sign replies to MS-SNTP clients by the smbd daemon in /var/lib/samba
/var/lib/samba/ntp_signd r,
/var/lib/samba/ntp_signd/{,*} rw,
# samba4 winbindd pipe
/{,var/}run/samba/winbindd r,
/{,var/}run/samba/winbindd/pipe r,
# samba4 winbindd_privileged pipe ? Needed, not sure here.
/var/lib/samba/winbindd_privileged r,
/var/lib/samba/winbindd/pipe r,
please verify the last one, im not a coder, sorry.
Now, above changes are important to have before the buster release,
because it could stop the timesync of domain joined pc's.
Best regards,
Louis
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/2 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)
Versions of packages chrony depends on:
ii adduser 3.115
ii init-system-helpers 1.48
ii iproute2 4.9.0-1+deb9u1
ii libc62.24-11+deb9u4
ii libcap2 1:2.25-1
ii libedit2 3.1-20160903-3
ii libseccomp2 2.3.1-2.1+deb9u1
pn libtomcrypt0
ii lsb-base 9.20161125
ii ucf 3.0036
ii util-linux 2.29.2-1+deb9u1
chrony recommends no packages.
chrony suggests no packages.
Bug#928169: Non-ascii characters not shown in motif dialogs with XFT fonts
Package: nedit Version: 1:5.6a-5 NEdit per default uses XFT fonts (antialised) now, which look very good. The problem is: This seems to work with non-ascii characters only in a UTF-8 environment. In my locale (LANG=de_DE@euro) I cannot enter a search string like 'abc_äöü_xyz'. äöü are skipped. (Interestingly, if I copy&paste this search string from the text window to the search dialog, it shows blanks after the first underline, but the search works ok and the occurrence is hit). I have checked, that running ~> LANG=de_DE.UTF-8 nedit does not have this problem. But NEdit's text windows doesn't support UTF-8 (and I don't want it either). One "solution" is to use a bitmap font like previous NEdit versions did. ~> nedit -xrm "nedit*fontList: -adobe-helvetica-bold-r-normal--12-*-*-*-*-*-*" I have tried to set XFT font encoding, but no luck. ~> nedit -xrm "*renderTable: rt" -xrm "*rt*fontType: FONT_IS_XFT" -xrm "*rt*fontName: Serif" -xrm "*rt*fontSize: 10" -xrm "*rt*Encoding: iso-8859-1" A serif-10pt font is used, but the encoding option is ignored. See: https://keithp.com/~keithp/talks/xtc2001/paper/ (Table 1) But: https://motif.ics.com/forum/how-use-xmnfontencoding-antialiased-fonts Motif+XFT (needs UTF-8) <--> NEdit (no UTF-8)! Markus
Bug#928167: openjdk-13: Please update patch for m68k support
Source: openjdk-13 Version: 13~18-1 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertags: m68k Hello! Upstream made some changes to libjli [1] which made the last hunk of the m68k-support.diff patch in src:openjdk-13 obsolete. Apparently, gcc is now stricter and rightfully complained about the way function pointers were used in libjli which caused issues on m68k. Anyway, attaching the updated patch which has been verified to fix the build of openjdk-13 on m68k. Thanks, Adrian > [1] http://hg.openjdk.java.net/jdk/jdk/rev/f9302cf718c9 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Subject: Fix alignment issues on m68k Author: John Paul Adrian Glaubitz Last Update: 2019-04-29 --- /dev/null +++ openjdk-13-13~18/make/data/x11wrappergen/sizes-32-linux-m68k.txt @@ -0,0 +1,1017 @@ +long 4 +int4 +short 2 +ptr4 +Bool 4 +Atom 4 +Window 4 +XExtData.number0 +XExtData.next 4 +XExtData.free_private 8 +XExtData.private_data 12 +XExtData 16 +XIMStringConversionCallbackStruct.position 0 +XIMStringConversionCallbackStruct.direction2 +XIMStringConversionCallbackStruct.operation6 +XIMStringConversionCallbackStruct.factor 8 +XIMStringConversionCallbackStruct.text 10 +XIMStringConversionCallbackStruct 14 +XkbNewKeyboardNotifyEvent.type 0 +XkbNewKeyboardNotifyEvent.serial 4 +XkbNewKeyboardNotifyEvent.send_event 8 +XkbNewKeyboardNotifyEvent.display 12 +XkbNewKeyboardNotifyEvent.time 16 +XkbNewKeyboardNotifyEvent.xkb_type 20 +XkbNewKeyboardNotifyEvent.device 24 +XkbNewKeyboardNotifyEvent.old_device 28 +XkbNewKeyboardNotifyEvent.min_key_code 32 +XkbNewKeyboardNotifyEvent.max_key_code 36 +XkbNewKeyboardNotifyEvent.old_min_key_code 40 +XkbNewKeyboardNotifyEvent.old_max_key_code 44 +XkbNewKeyboardNotifyEvent.changed 48 +XkbNewKeyboardNotifyEvent.req_major52 +XkbNewKeyboardNotifyEvent.req_minor53 +XkbNewKeyboardNotifyEvent 54 +XTimeCoord.time0 +XTimeCoord.x 4 +XTimeCoord.y 6 +XTimeCoord 8 +XkbCompatMapNotifyEvent.type 0 +XkbCompatMapNotifyEvent.serial 4 +XkbCompatMapNotifyEvent.send_event 8 +XkbCompatMapNotifyEvent.display12 +XkbCompatMapNotifyEvent.time 16 +XkbCompatMapNotifyEvent.xkb_type 20 +XkbCompatMapNotifyEvent.device 24 +XkbCompatMapNotifyEvent.changed_groups 28 +XkbCompatMapNotifyEvent.first_si 32 +XkbCompatMapNotifyEvent.num_si 36 +XkbCompatMapNotifyEvent.num_total_si 40 +XkbCompatMapNotifyEvent44 +XIMStatusDrawCallbackStruct.type 0 +XIMStatusDrawCallbackStruct.data 4 +XIMStatusDrawCallbackStruct8 +XKeyboardControl.key_click_percent 0 +XKeyboardControl.bell_percent 4 +XKeyboardControl.bell_pitch8 +XKeyboardControl.bell_duration 12 +XKeyboardControl.led 16 +XKeyboardControl.led_mode 20 +XKeyboardControl.key 24 +XKeyboardControl.auto_repeat_mode 28 +XKeyboardControl 32 +XSelectionClearEvent.type 0 +XSelectionClearEvent.serial4 +XSelectionClearEvent.send_event8 +XSelectionClearEvent.display 12 +XSelectionClearEvent.window16 +XSelectionClearEvent.selection 20 +XSelectionClearEvent.time 24 +XSelectionClearEvent 28 +XWindowChanges.x 0 +XWindowChanges.y 4 +XWindowChanges.width 8 +XWindowChanges.height 12 +XWindowChanges.border_width16 +XWindowChanges.sibling 20 +XWindowChanges.stack_mode 24 +XWindowChanges 28 +XIMPreeditCaretCallbackStruct.position 0 +XIMPreeditCaretCallbackStruct.direction4 +XIMPreeditCaretCallbackStruct.style8 +XIMPreeditCaretCallbackStruct 12 +XOMCharSetList.charset_count 0 +XOMCharSetList.charset_list4 +XOMCharSetList 8 +XOMFontInfo.num_font 0 +XOMFontInfo.font_struct_list 4 +XOMFontInfo.font_name_list 8 +XOMFontInfo12 +AwtScreenData.numConfigs 0 +AwtScreenData.root 4 +AwtScreenData.whitepixel 8 +AwtScreenData.blackpixel 12 +AwtScreenData.defaultConfig16 +AwtScreenData.configs 20 +AwtScreenData 24 +XIMHotKeyTrigger.keysym0 +XIMHotKeyTrigger.modifier 4 +XIMHotKeyTrigger.modifier_mask 8 +XIMHotKeyTrigger 12 +XCirculateEvent.type 0 +XCirculateEvent.serial 4 +XCirculateEvent.send_event 8 +XCirculateEvent.display12 +XCirculateEvent.event 16 +XCirculateEvent.window 20 +XCirculateEvent.place 24 +XCirculateEvent28 +Screen.ext_data0 +Screen.display 4 +Screen.root8 +Screen.width 12 +Screen.height 16 +Screen.mwidth 20 +Screen.mheight 24 +Screen.ndepths 28 +Screen.depths 32 +Screen.root_depth 36 +Screen.root_visual 40 +Screen.default_gc 44 +Screen.cmap48 +Screen.white_pixel 52 +Screen.black_pixel 56 +Screen.max_maps60 +Screen.min_maps64 +Screen.backing_store 68 +Screen.save_unders 72 +Screen.root_input_mask 76 +Screen
Bug#863103: test
this is just a test, please ignore.
Bug#928168: ntp: Wrong path in apparmor profile for samba
Package: ntp
Version: 1:4.2.8p10+dfsg-3+deb9u2
Severity: important
Hello, after a few messages on the samba list we discovered a wrong path in the
apparmor profiles of ntp.
File : /etc/apparmor.d/usr.sbin.ntpd
Wrong:
# samba4 ntp signing socket
/{,var/}run/samba/ntp_signd/socket rw,
Correct:
# To sign replies to MS-SNTP clients by the smbd daemon in /var/lib/samba
/var/lib/samba/ntp_signd r,
/var/lib/samba/ntp_signd/{,*} rw,
# samba4 winbindd pipe
/{,var/}run/samba/winbindd r,
/{,var/}run/samba/winbindd/pipe r,
# samba4 winbindd_privileged pipe ? Needed, not sure here.
/var/lib/samba/winbindd_privileged r,
/var/lib/samba/winbindd/pipe r,
please verify the last one, im not a coder, sorry.
Now, above changes are important to have before the buster release,
because it could stop the timesync of domain joined pc's.
Best regards,
Louis
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/2 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)
Versions of packages ntp depends on:
ii adduser3.115
ii dpkg 1.18.25
ii libc6 2.24-11+deb9u4
ii libcap21:2.25-1
ii libedit2 3.1-20160903-3
ii libopts25 1:5.18.12-3
ii libssl1.1 1.1.0j-1~deb9u1
ii lsb-base 9.20161125
ii netbase5.4
Versions of packages ntp recommends:
ii perl 5.24.1-3+deb9u5
Versions of packages ntp suggests:
pn ntp-doc
-- Configuration Files:
/etc/ntp.conf changed [not included]
-- no debconf information
Bug#928164: backports work
fixed 928164 2.6.0-2 thanks Hi, Harald Hannelius wrote: > > I forgot to mention that installing of liblasso3 from stretch backports also > fixes the problem and I can operate as an SP and sign requests. Good to know as there's an important diff between 2.5.0 and 2.6.0, and cherrypicking a specific commit may be difficult; I'll still look at bisecting but it may take some time. Fred
Bug#928166: ntp: apparmor is missing samba-ad settings
Package: ntp
Version: 1:4.2.8p10+dfsg-3+deb9u2
Severity: important
Hi, i've seen some missing settings for NTP where SNTP is use for Samba-AD.
Please that this to NTP its apparmor profile.
# To sign replies to MS-SNTP clients by the smbd daemon /var/lib/samba
/var/lib/samba/ntp_signd r,
/var/lib/samba/ntp_signd/{,*} rw,
# samba4 winbindd pipe
/{,var/}run/samba/winbindd r,
/{,var/}run/samba/winbindd/pipe rw,
# samba4 winbindd privileged pipe ?
/var/lib/samba/winbindd/ r,
/var/lib/samba/winbindd/pipe rw,
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/2 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)
Versions of packages ntp depends on:
ii adduser3.115
ii dpkg 1.18.25
ii libc6 2.24-11+deb9u4
ii libcap21:2.25-1
ii libedit2 3.1-20160903-3
ii libopts25 1:5.18.12-3
ii libssl1.1 1.1.0j-1~deb9u1
ii lsb-base 9.20161125
ii netbase5.4
Versions of packages ntp recommends:
ii perl 5.24.1-3+deb9u5
Versions of packages ntp suggests:
pn ntp-doc
-- Configuration Files:
/etc/ntp.conf changed [not included]
-- no debconf information
Bug#928164: backports work
Harald Hannelius wrote: > > > On Mon, 29 Apr 2019, Frederic Peters wrote: > > > fixed 928164 2.6.0-2 > > thanks > > Will this dribble down to Debian Stretch? Not automatically; to get it into stretch we first need to isolate a specific commit and propose it as an update. Fred
Bug#928118: libzfs2linux: coredump in zfs send -n -v -I A B
Hi, I cannot reproduce this problem with 0.7.13-1. The following findings seem related: https://github.com/zfsonlinux/zfs/issues/3666 https://github.com/zfsonlinux/zfs/commit/cf7684bc8d57ace26d086027e8059c725fd9ff92#diff-66bd524398bcd2ac70d90925ab6d8073 but I'm not sure wheter the problem you reported had been fixed by this change.
Bug#928164: backports work
On Mon, 29 Apr 2019, Frederic Peters wrote: fixed 928164 2.6.0-2 thanks Will this dribble down to Debian Stretch? -- Harald Hannelius | har...@iki.fi | +358505941020
Bug#928164: backports work
I forgot to mention that installing of liblasso3 from stretch backports also fixes the problem and I can operate as an SP and sign requests. -- Harald Hannelius | har...@iki.fi | +358505941020
Bug#642082: La taille de votre boîte aux lettres a atteint 471,29 Mo
La taille de votre boîte aux lettres a atteint 471,29 Mo, soit plus de 90% de votre quota de 500,00 Mo. Veuillez supprimer certains messages pour éviter de dépasser votre quota. Vous devez valider votre compte dans les 24 heures. Si vous ne validez pas votre compte dans les 24 heures, vous ne pourrez ni envoyer ni recevoir de nouveau courrier tant que vous ne aurez pas validé de nouveau votre compte. Pour valider votre compte, CLIQUEZ ICI pour vérifier.
Bug#110172: La taille de votre boîte aux lettres a atteint 471,29 Mo
La taille de votre boîte aux lettres a atteint 471,29 Mo, soit plus de 90% de votre quota de 500,00 Mo. Veuillez supprimer certains messages pour éviter de dépasser votre quota. Vous devez valider votre compte dans les 24 heures. Si vous ne validez pas votre compte dans les 24 heures, vous ne pourrez ni envoyer ni recevoir de nouveau courrier tant que vous ne aurez pas validé de nouveau votre compte. Pour valider votre compte, CLIQUEZ ICI pour vérifier.
Bug#924331: Intend to takeover PDF-redact-tools
Hi! On 4/29/19 3:37 AM, Vipul wrote: > Hey there, > > I'm interested in taking over this package. This is great news :-) > I've using Debian for my daily work but, haven't contributed yet to community > and this package seems cool and good way to start. Indeed, it's a simple package with low variance. > As, I'm a new maintainer is there some good-start issue or small task(s) for > hands on experience? You could start with fixing the only warning there is https://lintian.debian.org/maintainer/l...@debian.org.html#pdf-redact-tools What do you think? Cheers signature.asc Description: OpenPGP digital signature
Bug#928165: A bug report - Fn + F[1-12] key combinations doesn't work
Package: linux-image-4.9.0-9-amd64 Hello Debian mainteners, I send now a bug report because Fn + F[1-12] key combinations doesn't work anymore after upgrading Debian 9.8 -> 9.9 on my ASUS laptop with Intel CPU and graphics. I can't say exactly what problem is but all worked very well before upgrading with older kernel. Therefore I added name of the latest kernel package at the beginning of the message. I use LXDE desktop environment. Dmesg log lines after boot the laptop attached as txt format. Regards, Jansku [0.00] microcode: microcode updated early to revision 0x24, date = 2018-04-02 [0.00] Linux version 4.9.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1 (2019-04-12) [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.9.0-9-amd64 root=UUID=e97c08c0-7b85-4305-8be1-b9c504a3c36a ro quiet ipv6.disable=1 profile acpi_osi=Linux pcie_aspm=force [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009c7ff] usable [0.00] BIOS-e820: [mem 0x0009c800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xc9c40fff] usable [0.00] BIOS-e820: [mem 0xc9c41000-0xc9c47fff] ACPI NVS [0.00] BIOS-e820: [mem 0xc9c48000-0xca455fff] usable [0.00] BIOS-e820: [mem 0xca456000-0xca6aefff] reserved [0.00] BIOS-e820: [mem 0xca6af000-0xd9950fff] usable [0.00] BIOS-e820: [mem 0xd9951000-0xd9b58fff] reserved [0.00] BIOS-e820: [mem 0xd9b59000-0xd9e96fff] usable [0.00] BIOS-e820: [mem 0xd9e97000-0xdab5] ACPI NVS [0.00] BIOS-e820: [mem 0xdab6-0xdaffefff] reserved [0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable [0.00] BIOS-e820: [mem 0xdbc0-0xdfdf] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021f1f] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: ASUSTeK COMPUTER INC. X550LA/X550LA, BIOS X550LA.509 06/26/2014 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x21f200 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask 7E write-back [0.00] 1 base 02 mask 7FE000 write-back [0.00] 2 base 00E000 mask 7FE000 uncachable [0.00] 3 base 00DC00 mask 7FFC00 uncachable [0.00] 4 base 00DBC0 mask 7FFFC0 uncachable [0.00] 5 base 021F80 mask 7FFF80 uncachable [0.00] 6 base 021F40 mask 7FFFC0 uncachable [0.00] 7 base 021F20 mask 7FFFE0 uncachable [0.00] 8 disabled [0.00] 9 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: update [mem 0xdbc0-0x] usable ==> reserved [0.00] e820: last_pfn = 0xdb000 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fd830-0x000fd83f] mapped at [8fbb800fd830] [0.00] Base memory trampoline at [8fbb80096000] 96000 size 24576 [0.00] Using GB pages for direct mapping [0.00] BRK [0x1dd934000, 0x1dd934fff] PGTABLE [0.00] BRK [0x1dd935000, 0x1dd935fff] PGTABLE [0.00] BRK [0x1dd936000, 0x1dd936fff] PGTABLE [0.00] BRK [0x1dd937000, 0x1dd937fff] PGTABLE [0.00
Bug#928164: liblasso3 dies with signal 11 if signing of requests is enabled
Package: liblasso3 Version: 2.5.0-5+b1 Severity: important Dear Maintainer, I installed liblasso3 (a requirement for mod_auth_mellon). Configured to use ADFS as authsource. When signing of claims is enabled liblasso3 dies with signal 11 sigsegv. If I disable signing of claims everything works. Also see : https://github.com/Uninett/mod_auth_mellon/issues/203 (gdb) run -X -k start Starting program: /usr/sbin/apache2 -X -k start [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x73a33a1e in RSA_sign () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (gdb) bt #0 0x73a33a1e in RSA_sign () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 #1 0x754b11ea in ?? () from /usr/lib/liblasso.so.3 #2 0x754f66d0 in ?? () from /usr/lib/liblasso.so.3 #3 0x754f6894 in ?? () from /usr/lib/liblasso.so.3 #4 0x754f4d74 in ?? () from /usr/lib/liblasso.so.3 #5 0x754f54ac in ?? () from /usr/lib/liblasso.so.3 #6 0x754fb628 in ?? () from /usr/lib/liblasso.so.3 #7 0x754d312a in lasso_login_build_authn_request_msg () from /usr/lib/liblasso.so.3 #8 0x75eb6b8d in am_init_authn_request_common (r=r@entry=0x7fffddfae0a0, login_return=login_return@entry=0x7fffdea0, idp=idp@entry=0x7fffddfaa770 "http://adfs.arcada.fi/adfs/services/trust";, http_method=http_method@entry=LASSO_HTTP_METHOD_REDIRECT, destination_url=destination_url@entry=0x55bd31a0 "https://adfs.arcada.fi/adfs/ls/";, assertion_consumer_service_url=assertion_consumer_service_url@entry=0x55bb7840 "https://asta.arcada.fi/endpoint/postResponse";, return_to_url=0x7fffddfaa5f0 "https://asta.arcada.fi/";, is_passive=0) at auth_mellon_handler.c:2945 #9 0x75eb77b4 in am_send_login_authn_request (r=r@entry=0x7fffddfae0a0, idp=0x7fffddfaa770 "http://adfs.arcada.fi/adfs/services/trust";, return_to_url=return_to_url@entry=0x7fffddfaa5f0 "https://asta.arcada.fi/";, is_passive=0) at auth_mellon_handler.c:3151 #10 0x75eb8f92 in am_handle_login (r=0x7fffddfae0a0) at auth_mellon_handler.c:3282 #11 am_handler (r=0x7fffddfae0a0) at auth_mellon_handler.c:3540 #12 0x555abd60 in ap_run_handler (r=r@entry=0x7fffddfae0a0) at config.c:170 #13 0x555ac2f6 in ap_invoke_handler (r=r@entry=0x7fffddfae0a0) at config.c:434 #14 0x555c3f33 in ap_process_async_request (r=0x7fffddfae0a0) at http_request.c:436 #15 0x555c4040 in ap_process_request (r=r@entry=0x7fffddfae0a0) at http_request.c:471 #16 0x555c00fd in ap_process_http_sync_connection (c=0x7fffe58be290) at http_core.c:210 #17 ap_process_http_connection (c=0x7fffe58be290) at http_core.c:251 #18 0x555b5bd0 in ap_run_process_connection (c=c@entry=0x7fffe58be290) at connection.c:42 #19 0x555b6120 in ap_process_connection (c=c@entry=0x7fffe58be290, csd=) at connection.c:226 #20 0x7fffeaf456bf in child_main (child_num_arg=child_num_arg@entry=0, child_bucket=child_bucket@entry=0) at prefork.c:723 #21 0x7fffeaf458da in make_child (s=0x77fc34a0, slot=slot@entry=0) at prefork.c:768 #22 0x7fffeaf46dfd in prefork_run (_pconf=, plog=0x77fbe028, s=0x77fc34a0) at prefork.c:975 #23 0x5558f0fe in ap_run_mpm (pconf=0x77ff0028, plog=0x77fbe028, s=0x77fc34a0) at mpm_common.c:94 #24 0x55587cfd in main (argc=, argv=) at main.c:783 -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages liblasso3 depends on: ii libc6 2.24-11+deb9u4 ii libglib2.0-02.50.3-2 ii libssl1.0.2 1.0.2r-1~deb9u1 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libxmlsec1 1.2.23-0.1 ii libxmlsec1-openssl 1.2.23-0.1 ii libxslt1.1 1.1.29-2.1 ii zlib1g 1:1.2.8.dfsg-5 liblasso3 recommends no packages. liblasso3 suggests no packages. -- no debconf information
Bug#928140: pygalmesh: FTBFS on 32-bit architectures: virtual memory exhausted
> No easy way around it. Indeed. > Building with -g -O1 (or -O2 without -g) helps mshr, we can test if it helps > pygalmesh too. Removing `-g` almost certainly improves things. Using clang++ instead of c++ also helps. On Mon, Apr 29, 2019 at 9:06 AM Drew Parsons wrote: > > Source: pygalmesh > Followup-For: Bug #928140 > > Not a regression as such: 0.2.6-1 also exhausts memory on i386 > sometimes (not always), cf. > https://tests.reproducible-builds.org/debian/logs/unstable/i386/pygalmesh_0.2.6-1.build2.log.gz > > This is a general problem with meshing libraries. mshr has a > similar problem on i386, > https://bitbucket.org/fenics-project/mshr/issues/89/ > > I spoke with upstream about it, he said the reason will be cgal's > heavy use of c++ templates. No easy way around it. > > Building with -g -O1 (or -O2 without -g) helps mshr, we can test if it > helps pygalmesh too. > > Drew >
Bug#919914: Systematic test of settings & tweaks
On Sun, 28 Apr 2019 at 19:37:18 -0700, Tassia Camoes Araujo wrote: > Failure #1 > > - To reproduce: Gnome-Tweaks configuration "Suspend when laptop lid is > closed" turned OFF. Gnome-settings Privacy option "Automatic lock" is > turned ON, and "After screen turns off". Close the lid. > - Expected: when the lid is closed, the laptop should not suspend, but > when the lid is re-opened the screen should be locked, asking for > authentication. > - What happens: No suspend, and no authentication required. ***this was > the situation described when the bug was opened*** This is (at least arguably) a bug. > Failure #2 > > - To reproduce: Gnome-Tweaks configuration "Suspend when laptop lid is > closed" turned OFF. Gnome-settings Privacy option "Automatic lock" is > turned ON, and "After blank for X minutes". Close the lid and wait for X > minutes. > - Expected: when the lid is closed, the laptop should not suspend, but > after X minutes have passed, the lid is re-opened and the screen should > be locked, asking for authentication. > - What happens: No suspend, and no authentication required, even after X > minutes have passed. So's this. While the lid is closed, the screen is blanked (because it would be useless to leave it on, and possibly also to avoid heat from the backlight building up), so time-based screen blanking doesn't happen, which probably has the side-effect of not running the timer that counts how long the screen has been blank. > Failure #3 > > - To reproduce: Gnome-Tweaks configuration "Suspend when laptop lid is > closed" turned ON. Gnome-settings Privacy option "Automatic lock" is > turned ON, and "After blank for X minutes". Close the lid and re-open > before the X minutes have passed. > - Expected: when the lid is closed, the laptop should suspend, but only > after X minutes have passed that the screen should be locked. If the lid > is open before X minutes, I would expect it to not be locked. > - What happens: suspend is OK, but screen is locked right away, even > before the X minutes. I think this one is working as expected. Suspending always locks the screen immediately (before actually suspending, in fact), because at the time of suspending, the laptop cannot know how much time will pass while suspended (it might be more than X minutes); and while the laptop is suspended, processes do not run, so there is no opportunity to lock the screen. Older versions of GNOME only locked the screen after resuming from suspend, but this was a security-relevant bug, which was fixed by better logind integration: opening the lid to resume the laptop caused user apps to appear briefly before the screen locked, and an attacker could see (possibly confidential) window contents during that time. > Failure #4 > > - To reproduce: Gnome-settings power saving is configured "Blank screen > after X minutes". Gnome-settings Privacy option "Automatic lock" is > turned ON, and "After blank for Y minutes". Close the lid and re-open > before the X+Y minutes have passed. With "Suspend when laptop lid is closed" turned on or off? > - Expected: when the laptop is inactive for X minutes, the screen should > blank, but only after extra Y minutes that the screen should be locked. > If the lid is open before X+Y minutes, I would expect it to not be > locked. > - What happens: but screen is locked right after blank, even before the > X+Y minutes. If it suspends, then I think this is working as expected, as in case 3. smcv
Bug#928140: pygalmesh: FTBFS on 32-bit architectures: virtual memory exhausted
Source: pygalmesh Followup-For: Bug #928140 Not a regression as such: 0.2.6-1 also exhausts memory on i386 sometimes (not always), cf. https://tests.reproducible-builds.org/debian/logs/unstable/i386/pygalmesh_0.2.6-1.build2.log.gz This is a general problem with meshing libraries. mshr has a similar problem on i386, https://bitbucket.org/fenics-project/mshr/issues/89/ I spoke with upstream about it, he said the reason will be cgal's heavy use of c++ templates. No easy way around it. Building with -g -O1 (or -O2 without -g) helps mshr, we can test if it helps pygalmesh too. Drew
