Bug#872635: blacklisting util-linux on ARM Ltd hosted buildds

[Michael Biebl]

On Mon, 21 Aug 2017 15:24:25 +0200 Julien Cristau 
wrote:
> On 08/21/2017 03:05 PM, Andreas Henriksson wrote:
> > On Mon, Aug 21, 2017 at 02:31:03PM +0200, Julien Cristau wrote:
> >> Is it reproducible on abel? 
> > 
> > Just because I knew someone would ask I ran the test 100.000 times in
> > a loop on the porter box last time it happened (arm64) and no it has
> > not been reproduced anywhere outside ARM Ltd as far as I'm aware.
> > 
> You don't seem to be answering my question.  abel is a porterbox, and
> it's on the exact same network as the buildds at ARM.

The problem is not reproducible in a sid_armel chroot on abel.
Is the (network) configuration of abel and the other armel buildds
identical?

-- 
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#877672: [systemd] System Stalled at Pam-nologon

[Michael Biebl]

Control: tags -1 moreinfo unreproducible

Am 04.10.2017 um 08:21 schrieb David Baron:
> Package: systemd
> Version: 234-3
> Severity: critical
> 
> --- Please enter the report below this line. ---
> This touches systemd because of concurrent boot threads but actual bug may be 
> elsewhere!
> 
> Sporadically get, instead of the usual bootup and kdm start, a console logon. 
> It is not possible to log on, getting the pam-nologon error, system booting.
> Actually had kdm start up in this state, though impossible to log on 
> (concurrent boot).

Please provide exact error messages. To get a more verbose boot you can
change the options in the grub boot loader and append
"systemd.log_level=debug".
If everything else fails, take a screenshot and attach the image.

Is this problem reproducible? Does it happen on every boot?


> MAY be related to:
> 1. CPU too hot. In this case, retries will simple abort early on. Can do 
> nothing but spray cool and wait.
> 2. Network unavailable. Had this happen as well. When finally succeeded to 
> normal boot, I had to restart network-services.
> 3. Zram. Error seems more frequent after this was activated.

And how would this be related to systemd?


> --- System information. ---
> Architecture: 
> Kernel:   Linux 4.11.0-1-amd64
> 
> Debian Release: buster/sid
>   500 yakkety ppa.launchpad.net 
>   500 unstableftp.us.debian.org 
>   500 testing ftp.us.debian.org 
>   500 sid linux.dropbox.com 
>   500 lucid   ppa.launchpad.net 
>   100 jessie-backports ftp.us.debian.org 
> 1 experimentalftp.us.debian.org 

What kind of frankendebian is that system, mixing all those different
distros/release...

> --- Package information. ---
> Depends  (Version) | Installed
> ==-+-
> libacl1  (>= 2.2.51-8) | 2.2.52-3+b1
> libapparmor1 (>= 2.9.0-3+exp2) | 2.11.0-11
> libaudit1 (>= 1:2.2.1) | 1:2.7.7-1+b2
> libblkid1  (>= 2.19.1) | 
> libc6(>= 2.17) | 
> libcap2(>= 1:2.10) | 
> libcryptsetup4(>= 2:1.4.3) | 
> libgcrypt20 (>= 1.7.0) | 
> libgpg-error0(>= 1.14) | 
> libidn11 (>= 1.13) | 
> libip4tc0  (>= 1.6.0+snapshot20161117) | 
> libkmod2   (>= 5~) | 
> liblz4-1 (>= 0.0~r130) | 
> liblzma5  (>= 5.1.1alpha+20120614) | 
> libmount1  (>= 2.26.2) | 
> libpam0g (>= 0.99.7.1) | 
> libseccomp2 (>= 2.3.1) | 
> libselinux1 (>= 2.1.9) | 
> libsystemd0  (= 234-3) | 
> util-linux (>= 2.27.1) | 
> mount(>= 2.26) | 
> adduser| 
> procps | 

Are those packages really not installed or why is the version
information missing?

-- 
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#873778: Fix for the mozjs52 build on armel

[Michael Biebl]

Am 01.10.2017 um 20:03 schrieb Simon McVittie:
> Control: clone -1 -2 Control: retitle -2 FTBFS on mips64el: various
> test failures
> 
> On Sat, 23 Sep 2017 at 12:29:08 +0200, Emilio Pozuelo Monfort wrote:
>> Let's track the mips64el failure in a different bug, as it's 
>> completely different from this.
> 
> Cloned away. I haven't investigated those failures at all.
> 
>> The remaining problem seems to be a big-endian issue (mips, s390x, 
>> hppa, powerpc, sparc64). ppc64 fails in a slightly different
>> manner, might just be it's failing earlier for a different reason
>> but would also suffer from this bug.

[..]

Fwiw, we had on #debian-gnome the other
day, where we also identified the icu data file as a culprit.
Unfortunately that alone doesn't fix the s390x build. Pulling the
patches from firefox-esr (especially the s390x atomics patch), get's us
down to 10 unexpected test-suite failures on s390x.
As you already found out though is, that generating the icu data file is
not easily possible, as the mozjs package seems to miss the
tools/scripts to do so.

Anyway, copying the full IRC log for completeness sake


> [00:09:22]  so, what's going to happen with mozjs? Any progress on 
> that front?
> [00:39:02]  get permission to ignore the build failures on mips & 
> s390x?
> [01:03:37]  has firefox/mozja or mhommey been notified about this?
> [01:15:40]  I haven't talked to mhomney about mozjs
> [01:16:31]  I believe ptomato (the gjs maintainer) knows about our 
> build issues on others arches
> [01:34:20]  jbicha: I see that the firefox-esr package as specific 
> rules for big/little endian
> [01:35:36]  
> https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/debian/rules?h=esr52/master#n142
>  ff
> [01:35:49]  pochu suspected an endian issue, right?
> [01:36:46]  
> https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/debian/rules?h=esr52/master#n285
> [01:38:02]  I wonder if we shouldn't simply use firefox-esr as basis 
> for building the mozjs library
> [01:38:28]  maybe we could convince mike to provide a bit of 
> debian/rules magic which would disable the non-mozjs parts
> [01:39:02]  and we simply reupload src:firefox-esr with a different 
> source name
> [01:40:11]  building libmozjs directly from src:firefox-esr is 
> probably not a good idea, given that stable get's new major updates of it
> [01:41:24]  somehow it would be awesome though to benefit from 
> mike's experience and knowledge with the firefox package
> [01:41:29]  Ubuntu 17.04's mozjs38 actually uses the final Firefox 38 
> ESR tarball because Mozilla has so far been pretty bad about making mozjs 
> releases
> [01:41:38]  mbiebl_: The architectures with the "Exception: Failed to 
> test XUL condition" error are the big endian architectures except 
> m68k/powerpcspe (build with nocheck).
> [01:42:01]  I stripped the tarball down because the full tarball is 
> very slow to work with
> [01:42:02]  mips64el looks unrelated.
> [01:42:35]  I believe mips64el is a minor issue we can easily work 
> around
> [01:45:38]  jbicha: I suppose that 17.04 does not directly build the 
> libmozjs binary packages from src:firefox-esr but uses a different src 
> package name?
> [01:46:35]  yes, it uses a slightly different version of 
> https://anonscm.debian.org/git/pkg-gnome/mozjs38.git which is just an older 
> version of our mozjs52 packaging
> [01:46:45]  Ubuntu does not offer firefox-esr
> [02:10:36]  the be icu from firefox-esr seems to be a bingo
> [02:10:52]  I'm now getting further with mozjs52 on s390x
> [02:12:58]  further as in the test-suite passes and you get a .deb 
> or the test-suite fails at a later point?
> [02:14:31]  the test suite starts (I have to double-check the 
> unexpected failures with a clean build)
> [02:22:33]  bunk: glandium also pointed me to 
> https://sources.debian.net/patches/firefox-esr/52.3.0esr-2/porting/Fix-crashes-in-AtomicOperations-none-on-s390x.patch/
> [02:24:06]  that patch alone didn't help on Ubuntu but maybe in 
> combination with other stuff…
> [02:26:10]  Ubuntu hasn't been able to build Firefox on s390x in like 
> a year
> [02:27:39]  glandium also suggests to disable jit on mips*
> [02:30:37]  he advises against using src:firefox-esr as a basis to 
> build the libmozjs libraries
> [02:31:05]  but we should have a look at the patches he ships in 
> firefox-esr which touch src/js
> [02:31:17]  js/src, I mean
> [02:58:58]  counting TEST-UNEXPECTED-FAIL:
> [02:59:04]  ppc64el: 2
> [02:59:08]  mips64el: 3
> [02:59:14]  s390x (icu): 104
> [02:59:19]  s390x (icu+atomic): 10
> [02:59:24]  s390x (icu+atomic+gcc-6): 10
> [03:07:18]  there's an unofficial 52.4 release we could grab too
> [10:31:31]  FTR, what I used for "the be icu" was cp 
> firefox-esr-52.4.0esr/config/external/icu/data/icudt58b.dat 
> ./mozjs52-52.3.1/config/external/icu/data/icudt58l.dat
> [10:34:48]  adding s390x to the list of architectures where test 
> results are ignored gives me a successful build with debs
> 

Bug#877322: git-buildpackage: FTBFS: openjade:E: cannot open "/usr/share/gtk-doc/data/gtk-doc.dsl" (No such file or directory)

[Michael Biebl]

Hi Guido

Am 30.09.2017 um 17:04 schrieb Guido Günther:
> On Sat, Sep 30, 2017 at 04:32:46PM +0200, Andreas Beckmann wrote:
>> openjade:E: cannot open "/usr/share/gtk-doc/data/gtk-doc.dsl" (No such file 
>> or directory)
> 
> The gtk-doc package dropped the stylesheet in 1.26. gtk-doc maintainers
> can this be added back please?

This was a deliberate change by upstream it seems. There is no more .dsl
file in the upstream tarball. See


https://git.gnome.org/browse/gtk-doc/commit/?id=d77af06
https://git.gnome.org/browse/gtk-doc/commit/?id=29022ad 

If you rely on that file, I would suggest to ship a copy in your package.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#862758: Switch from gir1.2-networkmanager-1.0 to gir1.2-nm-1.0

[Michael Biebl]

Am 28.09.2017 um 19:47 schrieb Michael Biebl:
> Please consider applying the patch I provided in my previous email.

See the attached diff.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/control b/debian/control
index 87f87160..0536519b 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends: debhelper (>= 10~)
  , dblatex
  , dh-python
  , docbook-utils
- , gir1.2-networkmanager-1.0
+ , gir1.2-nm-1.0
  , libjs-bootstrap
  , python3-all
  , python3-apt
@@ -48,7 +48,7 @@ Depends: ${python3:Depends}
  , augeas-tools
  , gettext
  , gir1.2-glib-2.0
- , gir1.2-networkmanager-1.0
+ , gir1.2-nm-1.0
  , javascript-common
  , ldapscripts
  , libjs-bootstrap


signature.asc
Description: OpenPGP digital signature

Bug#877085: [Pkg-utopia-maintainers] Bug#877085: network-manager installation crashes debian buster

[Michael Biebl]

Control: tags -1 + moreinfo

Am 28.09.2017 um 16:04 schrieb andy:
> Package: network-manager
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>   I installed network-manager and my system (dell r710 server) crashed 
> immediately, tried to reboot, 
>   failed and tried to reboot, this cycle went on indefinitely

What exactly does "crash" mean?
Did the NetworkManager binary crash or the kernel?
Do you still have (local/remote) access to the system?
Please provide a dmesg log and if possible the output of
journalctl -alb.

-- 
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#877068: gvfs: version 1.34 breaks xdg-mime query filetype

[Michael Biebl]

Am 28.09.2017 um 13:55 schrieb Emilio Pozuelo Monfort:
> On 28/09/17 13:38, Michael Biebl wrote:

>> Updating xdg-utils to the latest upstream version 1.1.2 would include
>> that fix. Unfortunately the Debian xdg-utils package seems to be
>> unmaintained atm.
> 
> Yes, but it's already ITA and will be maintained in pkg-freedesktop. An update
> is in progress.

That's good news. Thanks for the update!

-- 
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#877068: gvfs: version 1.34 breaks xdg-mime query filetype

[Michael Biebl]

Am 28.09.2017 um 13:27 schrieb Michael Biebl:

> There are two issues to fix here: we need to fix the bashism in gvfs and
> we should update xdg-utils to use gio directly.

This is already fixed upstream in xdg-utils by
https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=0d6eebb27c562e8644ccf616ebdbddf82d0d2dd8

Updating xdg-utils to the latest upstream version 1.1.2 would include
that fix. Unfortunately the Debian xdg-utils package seems to be
unmaintained atm.

-- 
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#877068: gvfs: version 1.34 breaks xdg-mime query filetype

[Michael Biebl]

Am 28.09.2017 um 13:27 schrieb Michael Biebl:
> if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then

> Unfortunately there is a bashism in the script above which breaks --help
> ("==" should be replaced by "=").
gvfs-info is apparently not the only tool affected by this:

$ grep "==" /usr/bin/gvfs-*
/usr/bin/gvfs-cat:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-copy:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-info:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-ls:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-mime:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-mkdir:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-monitor-dir:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-monitor-file:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-mount:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-move:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-open:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-rename:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-rm:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-save:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-set-attribute:if [ "$1" == "--help" ] || [ "$1" == "-h" ];
then
/usr/bin/gvfs-trash:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
/usr/bin/gvfs-tree:if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then

Those need to be fixed as well.

-- 
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#877068: gvfs: version 1.34 breaks xdg-mime query filetype

[Michael Biebl]

Am 28.09.2017 um 12:54 schrieb definetti:
> Package: gvfs
> Version: 1.30.4-1+b1
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> upon upgrading to gvfs 1.34.0-2, commands like xdg-mime query filetype, that
> depend on it, no longer work. This causes xdg-open to be unable to associate
> the right applications to each mimetype.
> Reverting to gvfs 1.30 solves the issue

gvfs-info has been deprecated:



#!/bin/sh

replacement="gio info"
help="gio help info"

>&2 echo "This tool has been deprecated, use '$replacement' instead."
>&2 echo "See '$help' for more info."
>&2 echo

if [ "$1" == "--help" ] || [ "$1" == "-h" ]; then
  exec $help "$@:2"
else
  exec $replacement "$@"
fi



xdg-mime calls it like this:

if gvfs-info --help 2>/dev/null 1>&2; then

Unfortunately there is a bashism in the script above which breaks --help
("==" should be replaced by "=").

There are two issues to fix here: we need to fix the bashism in gvfs and
we should update xdg-utils to use gio directly.

Can you confirm that replacing "==" with "=" in /usr/bin/gvfs-info fixes
xdg-mime?

-- 
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#876615: librsvg FTBFS with gtk-doc-tools 1.26: gtkdoc-scangobj: error: unrecognized arguments: --nogtkinit

[Michael Biebl]

Control: tags -1 patch fixed-upstream

Am 24.09.2017 um 01:43 schrieb Adrian Bunk:
> gtkdoc-scangobj: error: unrecognized arguments: --nogtkinit

Fixed upstream by
https://git.gnome.org/browse/librsvg/commit/?id=dfe34c8757debd07d4ef2f6f0381b2bcac1addc0
-- 
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#876342: [Pkg-utopia-maintainers] Bug#876342: Bug#876342: avahi-daemon: upgrade failed: failed to configure

[Michael Biebl]

Am 21.09.2017 um 20:05 schrieb Vincent Lefevre:
> On 2017-09-21 18:47:40 +0200, Michael Biebl wrote:
>> Can you provide steps how to reproduce the issue? I've upgraded avahi on
>> several systems and did not run into this particular problem.
> 
> I don't know whether this is reproducible, but this was just an
> upgrade with aptitude. 

Not sure what to do about this bug report then aside from closing it.
The given information at least is not sufficient to further debug this.



-- 
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#876342: [Pkg-utopia-maintainers] Bug#876342: avahi-daemon: upgrade failed: failed to configure

[Michael Biebl]

Control: tags -1 moreinfo unreproducible

Am 21.09.2017 um 10:28 schrieb Vincent Lefevre:
> Package: avahi-daemon
> Version: 0.7-3
> Severity: grave
> Justification: renders package unusable
> 
> The upgrade of avahi-daemon failed:
> 
> Setting up avahi-daemon (0.7-3) ...
> Installing new version of config file /etc/avahi/avahi-daemon.conf ...
> Job for avahi-daemon.service failed because the control process exited with 
> error code.
> See "systemctl  status avahi-daemon.service" and "journalctl  -xe" for 
> details.
> invoke-rc.d: initscript avahi-daemon, action "restart" failed.
> ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
>Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor 
> preset: enabled)
>Active: failed (Result: exit-code) since Thu 2017-09-21 10:21:56 CEST; 6ms 
> ago
>   Process: 740 ExecStart=/usr/sbin/avahi-daemon -s (code=exited, status=255)
>  Main PID: 740 (code=exited, status=255)
> 
> Sep 21 10:21:56 zira systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
> Sep 21 10:21:56 zira avahi-daemon[740]: Daemon already running on PID 740> 
> Sep 21 10:21:56 zira systemd[1]: avahi-daemon.service: Main process
exited, code=exited, status=255/n/a
> Sep 21 10:21:56 zira systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
> Sep 21 10:21:56 zira systemd[1]: avahi-daemon.service: Unit entered failed 
> state.
> Sep 21 10:21:56 zira systemd[1]: avahi-daemon.service: Failed with result 
> 'exit-code'.
> dpkg: error processing package avahi-daemon (--configure):
>  subprocess installed post-installation script returned error exit status 1
> 

Can you provide steps how to reproduce the issue? I've upgraded avahi on
several systems and did not run into this particular problem.




-- 
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#876070: [Pkg-utopia-maintainers] Bug#876070: libavahi-core7: Does not install

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 18.09.2017 um 09:02 schrieb Eric Valette:
> Package: libavahi-core7
> Version: 0.7-1
> Severity: grave
> Justification: renders package unusable
> 
> apt-get -f install
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following additional packages will be installed:
>   libavahi-core7
> The following packages will be upgraded:
>   libavahi-core7
> 1 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> 33 not fully installed or removed.
> Need to get 0 B/114 kB of archives.
> After this operation, 3072 B disk space will be freed.
> Do you want to continue? [Y/n] 
> (Reading database ... 147923 files and directories currently installed.)
> Preparing to unpack .../libavahi-core7_0.7-1_amd64.deb ...
> Unpacking libavahi-core7:amd64 (0.7-1) over (0.6.32-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libavahi-core7_0.7-1_amd64.deb (--unpack):
>  unable to install (supposed) new info file '/var/lib/dpkg/tmp.ci/shlibs': 
> Structure needs cleaning
> Errors were encountered while processing:
>  /var/cache/apt/archives/libavahi-core7_0.7-1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 

I can't reproduce the problem. Neither on my laptop nor in a chroot test
environment.

The shlibs file shipped by libavahi-core7_0.7-1 looks right to me
(attached), so I have no idea what's going on here.

Guillem, can you chime in here, please. What does this error message
mean and when and why can this happen.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
libavahi-core 7 libavahi-core7 (>= 0.6.26)


signature.asc
Description: OpenPGP digital signature

Bug#874693: Is this still an issue?

[Michael Biebl]

Am 17.09.2017 um 01:40 schrieb Dean Loros:
> I see that gjs 1.50  has been released. Is this bug still applicable?

Yes. Why do you think it should not be?


-- 
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#874693: breaks other packages

[Michael Biebl]

Package: gjs
Version: 1.49.92-1
Severity: serious

The version from experimental apparently breaks other packages like
gnome-weather:

[14:29:37]  (org.gnome.Weather.Application:3731): Gjs-CRITICAL **: JS 
ERROR: SyntaxError: redeclaration of let copyright @ 
resource:///org/gnome/Weather/Application/js/app/window.js:221
[14:29:37]  JS_EvaluateScript() failed

 
https://git.gnome.org/browse/gnome-weather/commit/src/app/window.js?id=39c65724bef050561fb605f29019bc60669710ec

That's pretty bad. The least we can do is to check all reverse dependencies
of gjs and add Breaks as needed.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gjs depends on:
ii  libc6 2.24-17
ii  libgcc1   1:7.2.0-4
ii  libgjs0e [libgjs0-libmozjs-24-0]  1.46.0-1+b2
ii  libglib2.0-0  2.53.6-1
ii  libstdc++67.2.0-4

gjs recommends no packages.

gjs suggests no packages.

-- no debconf information

Bug#873627: [Pkg-utopia-maintainers] Bug#873627: Not really fixed

[Michael Biebl]

Am 31.08.2017 um 16:17 schrieb Lisandro Damián Nicanor Pérez Meyer:
> reopen 873627
> severity 873627 serious
> thanks
> 
> I'm afraid this last upload does not fixes the issue. I don't know
> what's the real problem but I had to go back to testing's udisks2 to
> be able to use Plasma.

It does fix the problem in udisks2, but there was one in libblockdev as
well which is fixed in 2.12-2. Make sure to upgrade to that version.

If udisks2 still fails after that, please file a new bug report, with
proper version information and list of package dependencies.

Thanks.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#873716: closing 873716

[Michael Biebl]

close 873716 
thanks

Bug#870171: Attributing the problem to NM after all

[Michael Biebl]

Control: tags -1 + moreinfo

On Sun, 30 Jul 2017 20:22:07 +0200 "Eduard Bloch"
 wrote:
> clone 849875 -1
> reassign -1 network-manager
> retitle -1 WPA usage error: Invalid passphrase character
> thanks
> 
> On Sat, Jul 01, 2017 at 11:32:28PM +0200, Francesco Poli wrote:
> > Dear Debian wpasupplicant Maintainers,
> > I noticed that these 3 RC bugs (#849122, #849077, #849875) are marked
> > as found in wpa/2.6-2, which is now superseded by versions with epoch 2.
> > What seems to have happened (please correct me, if I am wrong) is that
> > the upstream version 2.4 was reintroduced into unstable (with epoch 2)
> > and then migrated to stretch (before the stretch release as stable).
> > 
> > Hence, I would say that those three bugs only affect experimental and
> > are not in stretch, buster or sid.
> > 
> > Could you please confirm that these 3 bugs should be marked as fixed in
> > wpa/2:2.4-1 and found in wpa/2:2.6-4 ?
> 
> Ok, now the problem from the original report has hit me too.
> 
> I could not figure out what is going on. I selected an AP which has been
> working fine for months, and suddenly NM switched me to another AP
> (which works partly since it is far away and reception quality is bad).
> 
> I tried removing wpasupplicant and network-manager. Purging config.
> Nothing helps. Checking the log, and WOW... (see attachment).
> So wpa_supplicant says "Line 0: Invalid passphrase character".
> Line 0 of what? This is most likely the input from NM which means: NM
> feeds wpa_supplicant with CRAP. But which crap? When NM asked me for
> passphrase, I am absolutely sure that I entered the correct one.

Does the password have any special characters?
Can you change the WPA passphrase to something else (say only letters)
and try again?
Please also provide a full debug log from NetworkManager (and
wpasupplicant) when the problem happens.
https://wiki.gnome.org/Projects/NetworkManager/Debugging

which versions of wpasupplicant and network-manager do you have installed?



signature.asc
Description: OpenPGP digital signature

Bug#872598: udev-udeb: no input in graphical installer

[Michael Biebl]

Am 23.08.2017 um 23:57 schrieb Cyril Brulebois:

> My NMU FTBFSes on mips64el:
>   
> https://buildd.debian.org/status/fetch.php?pkg=systemd=mips64el=234-2.1=1503523165=0
> 
> James Cowgill mentioned this gcc bug report:
>   https://bugs.debian.org/871514
> 
> so I think I might duplicate the rules file in src:debian-installer and
> work around the missing file by putting it into place manually, which is
> somewhat ugly but means we're no longer blocking on the systemd update.

I wouldn't mind if you forced the compiler to be GCC 6 in src:systemd
until this bug is fixed.

-- 
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#872598: udev-udeb: no input in graphical installer

[Michael Biebl]

Hi KiBi

Am 23.08.2017 um 10:08 schrieb Cyril Brulebois:
> Would you be OK with a minimal NMU to fix the missing file? This issue has
> been blocking the D-I Buster Alpha 1 release for weeks already (even if it
> hadn't been diagnosed and reported against udev-udeb until recently), and
> I'd be happy to get a release out the door ASAP, since I won't have much
> time in the following weeks.

Felipe has already looked into this issue a bit and discovered more
inconsistencies between the deb and udeb build for udev. This will
probably need some more time to review/investigate properly, so feel
free to go ahead with the NMU!

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#872598: udev-udeb: no input in graphical installer

[Michael Biebl]

Am 19.08.2017 um 14:38 schrieb Cyril Brulebois:

> A timely fix would be appreciated, the breakage(s) in the graphical
> installer prevented us from releasing debian-installer over the past few
> weeks, and it would be great not to wait too long before we're able to do
> so, esp. with linux 4.12.6-1 having reached testing lately.

I might have time for that mid next week.

-- 
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#872598: udev-udeb: no input in graphical installer

[Michael Biebl]

Am 19.08.2017 um 10:14 schrieb Raphael Hertzog:

> I wonder if it would be possible to have autopkgtest tests covering
> udev-udeb...

We'd be happy to ship such an autopkgtest. Help in that regard would be
much appreciated.

-- 
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#872598: udev-udeb: no input in graphical installer

[Michael Biebl]

Am 19.08.2017 um 10:19 schrieb Michael Biebl:
> Am 19.08.2017 um 04:59 schrieb Cyril Brulebois:
>>
>> I haven't looked into the changelog and actual changes (yet), but I'd be
>> happy to get some input (no pun intended) from systemd maintainers.
>>
> 
> Maybe this is related:
> https://github.com/systemd/systemd/commit/43af16c99c800afdfc4b6913ea7596aaddd0395d
> 
> I.e., could you apply this upstream patch, make sure the udev rule is in
> the udeb and try again?

Urgh, I missed that this patch is already part of v234, sorry for the
confusion.
So all that's missing seems to be the installation in the udev-udeb.


-- 
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#872598: udev-udeb: no input in graphical installer

[Michael Biebl]

Am 19.08.2017 um 04:59 schrieb Cyril Brulebois:
> 
> I haven't looked into the changelog and actual changes (yet), but I'd be
> happy to get some input (no pun intended) from systemd maintainers.
> 

Maybe this is related:
https://github.com/systemd/systemd/commit/43af16c99c800afdfc4b6913ea7596aaddd0395d

I.e., could you apply this upstream patch, make sure the udev rule is in
the udeb and try again?

If that doesn't help, we will need log files to debug this further.
A Xorg log from a working/non-working installer would be a start.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#870310: glib-mkenums: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: ordinal not in range(128)

[Michael Biebl]

Am 01.08.2017 um 00:34 schrieb Adrian Bunk:
> Control: tags -1 - moreinfo
> 
> On Tue, Aug 01, 2017 at 12:03:31AM +0200, Michael Biebl wrote:
>> Control: tags -1 + moreinfo
>>
>> Am 31.07.2017 um 23:04 schrieb Adrian Bunk:
>>>   File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
>>> return codecs.ascii_decode(input, self.errors)[0]
>>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: 
>>> ordinal not in range(128)
>>> Found cached translation database
>>> Merging translations into gthumb.desktop.
>>> Makefile:963: recipe for target 'org.gnome.gthumb.enums.xml' failed
>>> make[4]: *** [org.gnome.gthumb.enums.xml] Error 1
>>
>> Are you using a non-UTF-8 locale
> 
> Works with LANG=C.UTF-8 and FTBFS with LANG=C
> 
>> and are you processing data containing
>> unicode characters?
> 
> Yes, some files in gthumb are using the UTF-8 copyright symbol.

Not sure what glib-mkenums is supposed to do about this then.
It's the package/build environment not using a UTF-8 locale and Python 3
being picky about that. Making glib-mkenums forcefully set a specific
locale doesn't look like a solution to me.


-- 
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#870310: glib-mkenums: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: ordinal not in range(128)

[Michael Biebl]

Control: tags -1 + moreinfo

Am 31.07.2017 um 23:04 schrieb Adrian Bunk:
>   File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
> return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 108: 
> ordinal not in range(128)
> Found cached translation database
> Merging translations into gthumb.desktop.
> Makefile:963: recipe for target 'org.gnome.gthumb.enums.xml' failed
> make[4]: *** [org.gnome.gthumb.enums.xml] Error 1

Are you using a non-UTF-8 locale and are you processing data containing
unicode characters?

-- 
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#869922: [Pkg-utopia-maintainers] Bug#869922: policykit-1: members of group sudo become root with pkexec while ignoring /etc/sudoers

[Michael Biebl]

Control: severity -1 normal
Control: close -1
Am 27.07.2017 um 17:53 schrieb mviereck:
> Package: policykit-1
> Version: 0.105-18
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Dear Maintainer,
> 
> If an unprivileged user is member of group sudo, he can achieve unrestricted 
> root privileges with pkexec 
> and his user password (instead of root password). This happens regardless if 
> or if not package sudo is installed, 
> and regardless of existing or non-existing entries in /etc/sudoers.
> 
> Command sudo and group sudo were designed to allow single privileged commands 
> for unprivileged users.

This is not correct. The default sudo config ships

%sudo   ALL=(ALL:ALL) ALL

I.e., a user in group sudo can run every command with root privileges.

> Instead, pkexec allows full root access for members of group sudo.
> 
> I expect: 
>  - pkexec does not regard group sudo. (clean way, unlinking polkit from sudo)
> or
>  - pkexec regards entries in /etc/sudoers. (dirty way, pkexec should not be 
> mixed with sudo)
> 
> (Not regarding group sudo would also avoid prompting non-sudo-group users for 
> passwords of sudo-group users)

Granting root-like access via group sudo is intended and not a security
hole and the policykit policy is in line with the sudo policy here.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature

Bug#826471: intltool: Unescaped left brace in regex is deprecated at /usr/bin/intltool-update line 1070

[Michael Biebl]

Am 05.06.2016 um 20:12 schrieb Niko Tyni:
> Package: intltool
> Version: 0.50.2-3
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: perl-5.24-transition
> 
> Building the inkscape package triggers deprecation warnings with Perl
> 5.24 (currently in experimental), and probably with Perl 5.22 (current
> sid) too.
> 
>   Unescaped left brace in regex is deprecated, passed through in regex; 
> marked by <-- HERE in m/\${ <-- HERE ?PACKAGE_NAME}?/ at 
> /usr/bin/intltool-update line 1070,  line 1213.
> 

I can't find an upstream bug report for this issue, but there is
https://git.archlinux.org/svntogit/packages.git/tree/trunk/intltool-0.51.0-perl-5.26.patch?h=packages/intltool

upstream intltool looks pretty much dead unfortunately.
-- 
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#868695: [systemd] Have not had any LC_CTYPE on previous versions

[Michael Biebl]

Am 20.07.2017 um 09:14 schrieb David Baron:
> Package: systemd
> Version: 233-10
> 
> --- Please enter the report below this line. ---
> I have not seen this env variable in ages.
> Do I need to install something involving the getty systemd service to get it?
> 
> Since I have lived without it so far, question is if not using ssh xorg 
> login, 
> to I indeed need it?

This is a bug tracker, not a user support forum. There is a debian-user
mailing list and a debian forum which are more suitable for such type of
questions.


-- 
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#868695: systemd: leaves empty LC_CTYPE what breaks X11 ssh password prompt

[Michael Biebl]

Am 17.07.2017 um 20:54 schrieb Robert Luberda:
> Yes, LC_CTYPE and other LC_ variables are empty, because they are set
> like this in /lib/systemd/system/getty@.service.

Afaics, this was broken by
https://github.com/systemd/systemd/pull/6023

Robert, can you try reverting the commit
https://github.com/systemd/systemd/commit/db6aedab9292678918f15807a0d835be35511667

and report back.
I've created an upstream bug report in the mean time at
https://github.com/systemd/systemd/issues/6407

-- 
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#868695: systemd: leaves empty LC_CTYPE what breaks X11 ssh password prompt

[Michael Biebl]

Am 17.07.2017 um 20:54 schrieb Robert Luberda:
> Package: systemd
> Version: 234-1
> Severity: critical
> Justification: breaks unrelated software
> 
> I usually login on tty1 via getty and then switch to X via startx.
> After recent upgrade of systemd  I can no longer ssh to any 
> host in  X11, because gpg-agent (which is used instead of ssh-agent) 
> fails to prompt for password, and the following error is shown instead:
> 
>  sign_and_send_pubkey: signing failed: agent refused operation
>  Permission denied (publickey).
> 
> strace -f on gpg-agent process showed me this:
> 
> [pid  1794] <... read resumed> "OPTION lc-ctype=", 1002) = 16
> [pid  1792] write(12, "\n", 1 
> [pid  1794] read(6,  
> [pid  1792] <... write resumed> )   = 1
> [pid  1794] <... read resumed> "\n", 986) = 1
> [pid  1792] read(9,  
> [pid  1794] write(10, "ERR 536871188 IPC syntax error <"..., 81) = 81
> [pid  1792] <... read resumed> "ERR 536871188 IPC syntax error <"..., 1002) = 
> 81
> 
> 
> Yes, LC_CTYPE and other LC_ variables are empty, because they are set
> like this in /lib/systemd/system/getty@.service.
> Downgrading systemd to 233-10 solves the bug for me (even though
> getty@.service still contains the empty LC_ variables, but fortunatelly they 
> are not propagated to my terminals).

I'm not sure how the LC_*/LANG setting in getty@.service are relevant.
Can you please elaborate?

From what I understand, gpg-agent is started as a user service nowadays.

What does
systemctl --user show-environment
systemctl --user status gpg-agent.service
say?


-- 
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#868695: systemd: leaves empty LC_CTYPE what breaks X11 ssh password prompt

[Michael Biebl]

Am 17.07.2017 um 20:54 schrieb Robert Luberda:
> Package: systemd
> Version: 234-1
> Severity: critical
> Justification: breaks unrelated software
> 
> I usually login on tty1 via getty and then switch to X via startx.
> After recent upgrade of systemd  I can no longer ssh to any 
> host in  X11, because gpg-agent (which is used instead of ssh-agent) 
> fails to prompt for password, and the following error is shown instead:
> 

Can you share the exact configuration you are using so we can reproduce
the problem?

I just started a pristine sid VM, logged in on tty2, ran startx
/usr/bin/openbox, then ssh some.remote.server.
This prompted me for the password withouth problems.

-- 
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#868308: Acknowledgement (file conflict with libsane)

[Michael Biebl]

If the renaming from libsane to libsane1 was intentional, you need
proper versioned Breaks/Replaces against the old libsane package.
Be aware that this is technically a library transition, so before you
upload to unstable, get in touch with the release managers.

-- 
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#868307: Acknowledgement (library package ships libtools .la files)

[Michael Biebl]

See
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev

https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#library

https://wiki.debian.org/ReleaseGoals/LAFileRemoval
-- 
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#868309: FTBFS on various architectures due to missing symbols

[Michael Biebl]

Source: sane-backends
Version: 1.0.27-1~experimental1
Severity: serious

The version in experimental fails to build on various architectures:

@@ -7191,7 +7089,7 @@
  sanei_constrain_value@Base 1.0.24
  sanei_debug_dll@Base 1.0.25
  sanei_debug_msg@Base 1.0.24
- sanei_debug_sanei_ab306@Base 1.0.25
+#MISSING: 1.0.27# sanei_debug_sanei_ab306@Base 1.0.25
  sanei_debug_sanei_access@Base 1.0.25
  sanei_debug_sanei_config@Base 1.0.24
  sanei_debug_sanei_debug@Base 1.0.24
dh_makeshlibs: failing due to earlier errors
debian/rules:132: recipe for target 'override_dh_makeshlibs-arch' failed

See 
https://buildd.debian.org/status/package.php?p=sane-backends=experimental


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#868308: file conflict with libsane

[Michael Biebl]

Package: libsane1
Version: 1.0.27-1~experimental1
Severity: serious

The libsane package in experimental was renamed from libsane to
libsane1, yet it ships the same contents, e.g.
/usr/lib/x86_64-linux-gnu/libsane.so.1

This leads to a file conflicts between the two packages and failure to
install/upgrade the libsane1 package.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsane1 depends on:
ii  acl2.2.52-3+b1
ii  adduser3.115
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc6  2.24-12
ii  libgphoto2-6   2.5.13-3
ii  libgphoto2-port12  2.5.13-3
ii  libieee1284-3  0.2.11-13
ii  libjpeg62-turbo1:1.5.1-2
ii  libsane-common 1.0.26~git20151121-1
ii  libtiff5   4.0.8-3
ii  libusb-1.0-0   2:1.0.21-2
ii  makedev2.3.1-93
ii  udev   234-1

Versions of packages libsane1 recommends:
ii  libsane-extras  1.0.22.4
ii  sane-utils  1.0.26~git20151121-1

Versions of packages libsane1 suggests:
ii  avahi-daemon  0.6.32-2
pn  hplip 

Bug#868307: library package ships libtools .la files

[Michael Biebl]

Package: libsane1
Version: 1.0.27-1~experimental1
Severity: serious

The libsane1 package ships libtool .la files. Those should be dropped or
added to the -dev package (preferrably dropped).

The libtool .la files do not encode a soname version, so they will cause
a file conflict on soname bumps (libsane.la vs libsane.so.1)


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsane1 depends on:
ii  acl2.2.52-3+b1
ii  adduser3.115
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc6  2.24-12
ii  libgphoto2-6   2.5.13-3
ii  libgphoto2-port12  2.5.13-3
ii  libieee1284-3  0.2.11-13
ii  libjpeg62-turbo1:1.5.1-2
ii  libsane-common 1.0.26~git20151121-1
ii  libtiff5   4.0.8-3
ii  libusb-1.0-0   2:1.0.21-2
ii  makedev2.3.1-93
ii  udev   234-1

Versions of packages libsane1 recommends:
ii  libsane-extras  1.0.22.4
ii  sane-utils  1.0.26~git20151121-1

Versions of packages libsane1 suggests:
ii  avahi-daemon  0.6.32-2
pn  hplip 

Bug#866531: systemd: networking.service fails with virtual interfaces

[Michael Biebl]

Control: severity -1 important
Control: reassign -1 ifupdown

Am 29.06.2017 um 23:46 schrieb BERTRAND Joël:
> Package: systemd
> Version: 233-9
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
> 
> I have seen for a long time several issues with systemd. All of these issues 
> seem to come from target networking.service.
> 
> Indeed, systemctl status networking.service returns:
> networking.service - Raise network interfaces
> Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor
> preset: enabled)
> Active: failed (Result: exit-code) since Thu 2017-06-29 23:33:40 CEST; 16s ago
> ...
> juin 29 23:33:39 rayleigh ifup[16031]: RTNETLINK answers: File exists
> juin 29 23:33:39 rayleigh ifup[16031]: ifup: failed to bring up eth1:4
> juin 29 23:33:39 rayleigh ifup[16031]: RTNETLINK answers: File exists
> juin 29 23:33:39 rayleigh ifup[16031]: ifup: failed to bring up eth1:5
> juin 29 23:33:39 rayleigh ifup[16031]: RTNETLINK answers: File exists
> juin 29 23:33:39 rayleigh ifup[16031]: ifup: failed to bring up eth1:6
> juin 29 23:33:40 rayleigh systemd[1]: networking.service: Main process exited,
> code=exited, status=1/FAILURE
> juin 29 23:33:40 rayleigh systemd[1]: Failed to start Raise network 
> interfaces.
> juin 29 23:33:40 rayleigh systemd[1]: networking.service: Unit entered failed
> state.
> juin 29 23:33:40 rayleigh systemd[1]: networking.service: Failed with result
> 'exit-code'.
> 
> This target calls /sbin/ifup -a --read-environment that returns
> RTNETLINK answers: File exists
> ifup: failed to bring up eth1:1
> RTNETLINK answers: File exists
> ifup: failed to bring up eth1:2
> RTNETLINK answers: File exists
> ifup: failed to bring up eth1:3
> RTNETLINK answers: File exists
> ifup: failed to bring up eth1:4
> RTNETLINK answers: File exists
> ifup: failed to bring up eth1:5
> RTNETLINK answers: File exists
> ifup: failed to bring up eth1:6
> 
> Network interfaces I have configured are :
> - eth0 (LAN)
> - eth1 (WAN1) with six virtual interfaces eth1.[1-6]
> - eth2 (WAN2)
> - tap0
> - tap1
> 
> I cannot test as I cannot remove virtual interfaces but on all other servers
> without virtual interfaces, networking.service runs as expected.

networking.service is shipped by ifupdown, so reassign accordingly.


-- 
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#866376: [Pkg-utopia-maintainers] Bug#866376: network-manager: Network-Manager cause kernel panic

[Michael Biebl]

If the kernel panics, this sounds like a driver/kernel issue.
Which hardware and driver do you use?

Ben, does this sound familiar? Should this issue be reassigned to the
kernel?

Am 29.06.2017 um 11:33 schrieb Dario Maiocchi:
> Package: network-manager
> Version: 1.6.2-3
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>  Just booting and connecting with gnome on network wifi, cause kernel 
> panic,
>  impossible to get internet via wifi.(kernel panic attached)
>
>  I know that the wifi initially worked, then i moved and changed
>  wifi device router (not on laptop) and i have the kernel panic.
> 
>  I didn't tried it out with another device.  
>  For any additional info ping me
> 
>* What was the outcome of this action?
>  Disable wlan
>* What outcome did you expect instead?
>  Not kernel-panic
> 
> network-manager-gnome 1.4.4-1 amd64
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages network-manager depends on:
> ii  adduser3.115
> ii  dbus   1.10.18-1
> ii  init-system-helpers1.48
> ii  libaudit1  1:2.6.7-2
> ii  libbluetooth3  5.43-2
> ii  libc6  2.24-11+deb9u1
> ii  libglib2.0-0   2.50.3-2
> ii  libgnutls303.5.8-5+deb9u1
> ii  libgudev-1.0-0 230-3
> ii  libjansson42.9-1
> ii  libmm-glib01.6.4-1
> ii  libndp01.6-1+b1
> ii  libnewt0.520.52.19-1+b1
> ii  libnl-3-2003.2.27-2
> ii  libnm0 1.6.2-3
> ii  libpam-systemd 232-25
> ii  libpolkit-agent-1-00.105-18
> ii  libpolkit-gobject-1-0  0.105-18
> ii  libreadline7   7.0-3
> ii  libselinux12.6-3+b1
> ii  libsoup2.4-1   2.56.0-2
> ii  libsystemd0232-25
> ii  libteamdctl0   1.26-1+b1
> ii  libuuid1   2.29.2-1
> ii  lsb-base   9.20161125
> ii  policykit-10.105-18
> ii  udev   232-25
> ii  wpasupplicant  2:2.4-1
> 
> Versions of packages network-manager recommends:
> ii  crda 3.18-1
> ii  dnsmasq-base 2.76-5+b1
> ii  iptables 1.6.0+snapshot20161117-6
> ii  iputils-arping   3:20161105-1
> ii  isc-dhcp-client  4.3.5-3
> ii  modemmanager 1.6.4-1
> ii  ppp  2.4.7-1+4
> 
> Versions of packages network-manager suggests:
> pn  libteam-utils  
> 
> 
> kernel-panic:
> 
> Jun 29 11:00:03 atene kernel: INFO: rcu_sched self-detected stall on CPU
> Jun 29 11:00:03 atene kernel: 0-...: (5250 ticks this GP)
> idle=223/141/0 softirq=42741/42741 fqs=2317 
> Jun 29 11:00:03 atene kernel:  (t=5251 jiffies g=27933 c=27932
> q=10796)
> Jun 29 11:00:03 atene kernel: Task dump for CPU 0:
> Jun 29 11:00:03 atene kernel: NetworkManager  R  running task0
> 469  1 0x0008
> Jun 29 11:00:03 atene kernel:  a8b13340 a7ea3bbb
>  a8b13340
> Jun 29 11:00:03 atene kernel:  a7f7a4a6 8b01bec18fc0
> a8a4a6c0 
> Jun 29 11:00:03 atene kernel:  a8b13340 
> a7ededf4 0001
> Jun 29 11:00:03 atene kernel: Call Trace:
> Jun 29 11:00:03 atene kernel:   
> Jun 29 11:00:03 atene kernel:  [] ?
> sched_show_task+0xcb/0x130
> Jun 29 11:00:03 atene kernel:  [] ?
> rcu_dump_cpu_stacks+0x92/0xb2
> Jun 29 11:00:03 atene kernel:  [] ?
> rcu_check_callbacks+0x754/0x8a0
> Jun 29 11:00:03 atene kernel:  [] ?
> tick_sched_handle.isra.12+0x50/0x50
> Jun 29 11:00:03 atene kernel:  [] ?
> update_process_times+0x28/0x50
> Jun 29 11:00:03 atene kernel:  [] ?
> tick_sched_handle.isra.12+0x20/0x50
> Jun 29 11:00:03 atene kernel:  [] ?
> tick_sched_timer+0x38/0x70
> Jun 29 11:00:03 atene kernel:  [] ?
> __hrtimer_run_queues+0xdc/0x240
> Jun 29 11:00:03 atene kernel:  [] ?
> hrtimer_interrupt+0x9c/0x1a0
> Jun 29 11:00:03 atene kernel:  [] ?
> smp_apic_timer_interrupt+0x39/0x50
> Jun 29 11:00:03 atene kernel:  [] ?
> apic_timer_interrupt+0x82/0x90
> Jun 29 11:00:03 atene kernel:   
> Jun 29 11:00:03 atene kernel:  [] ?
> delay_tsc+0x21/0x50
> Jun 29 11:00:03 atene kernel:  [] ?
> rtl8723_fw_free_to_go+0xa3/0xf0 [rtl8723_common]
> Jun 29 11:00:03 atene kernel:  [] ?
> rtl8723_download_fw+0xb6/0x130 [rtl8723_common]
> Jun 29 11:00:03 atene kernel:  [] ?
> rtl8723be_hw_init+0xc60/0x1740 [rtl8723be]
> Jun 29 11:00:03 atene kernel:  [] ?
> rtl_pci_start+0x4c/0xb0 [rtl_pci]
> Jun 29 11:00:03 atene kernel:  [] ?
> rtl_op_start+0x4d/0x80 [rtlwifi]
> Jun 29 11:00:03 atene kernel:  [] ?

Bug#850291: gdm3: does not work without gnome-session

[Michael Biebl]

Am 28.06.2017 um 23:27 schrieb Michael Biebl:

> Afaics, we have 3 options:
> 
> 1/ Add a hard dependency on gnome-session to gdm3
> (this kind of makes the line
> Depends: gnome-session | x-session-manager | x-window-manager |
> x-terminal-emulator,
> pointless, so this should be dropped if this option is chosen)
> 
> 2/ Move /usr/share/gnome-session/sessions/gnome.session to gnome-session-bin
> 
> 3/ Revert upstream commit
> https://git.gnome.org/browse/gdm/commit/?id=f66cdfcb and possibly
> https://git.gnome.org/browse/gdm/commit/?id=9fb36b as well.

Fwiw, my preference would be 3 > 2 > 1


-- 
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#850291: gdm3: does not work without gnome-session

[Michael Biebl]

Am 28.06.2017 um 23:27 schrieb Michael Biebl:
> Am 28.06.2017 um 21:00 schrieb Michael Biebl:
>> Marking this as RC (missing dependency to function properly).
>> We should fix that in stretch via a point release.
> 
> After some more discussion on IRC, we concluded this is a result of the
> following upstream change:
> https://git.gnome.org/browse/gdm/commit/?id=f66cdfcb
> 
> gdm dropped it's own gdm-shell.session in preference of gnome.session.
> 
> This file is currently shipped by gnome-session.
> 
> Afaics, we have 3 options:
> 
> 1/ Add a hard dependency on gnome-session to gdm3
> (this kind of makes the line
> Depends: gnome-session | x-session-manager | x-window-manager |
> x-terminal-emulator,
> pointless, so this should be dropped if this option is chosen)

Also, since the gnome-session <> gnome-session-bin split was originally
done for gdm3, having a hard dep on gnome-session would make the split
pointless, so we should merge the packages again (this would obviously
not be something which should be done in stable)


-- 
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#850291: gdm3: does not work without gnome-session

[Michael Biebl]

Am 28.06.2017 um 21:00 schrieb Michael Biebl:
> Marking this as RC (missing dependency to function properly).
> We should fix that in stretch via a point release.

After some more discussion on IRC, we concluded this is a result of the
following upstream change:
https://git.gnome.org/browse/gdm/commit/?id=f66cdfcb

gdm dropped it's own gdm-shell.session in preference of gnome.session.

This file is currently shipped by gnome-session.

Afaics, we have 3 options:

1/ Add a hard dependency on gnome-session to gdm3
(this kind of makes the line
Depends: gnome-session | x-session-manager | x-window-manager |
x-terminal-emulator,
pointless, so this should be dropped if this option is chosen)

2/ Move /usr/share/gnome-session/sessions/gnome.session to gnome-session-bin

3/ Revert upstream commit
https://git.gnome.org/browse/gdm/commit/?id=f66cdfcb and possibly
https://git.gnome.org/browse/gdm/commit/?id=9fb36b as well.


-- 
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#865589: Ships a tmpfile in /usr and /etc, one overriding the other

[Michael Biebl]

Package: openvpn
Version: 2.4.3-1
Severity: serious

Hi,

I just noticed that the latest openvpn update now ships a tmpfile in /etc:
/etc/tmpfiles.d/openvpn.conf

This is odd, since the package also ships:
/usr/lib/tmpfiles.d/openvpn.conf

tmpfiles in /etc/tmpfiles.d are reserved to the local administrator and
override a tmpfile with the same name from /usr/lib/tmpfiles.d

Marking as RC, as something is clearly broken here, and
/usr/lib/tmpfiles.d/openvpn.conf being overriddden means that
/run/openvpn is no longer created.

Michael

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  iproute2   4.9.0-1
ii  libc6  2.24-12
ii  liblz4-1   0.0~r131-2+b1
ii  liblzo2-2  2.08-1.2+b2
ii  libpam0g   1.1.8-3.6
ii  libpkcs11-helper1  1.21-1
ii  libssl1.0.21.0.2l-2
ii  libsystemd0233-9
ii  lsb-base   9.20161125

Versions of packages openvpn recommends:
pn  easy-rsa  

Versions of packages openvpn suggests:
ii  openssl 1.1.0f-3
pn  resolvconf  

-- Configuration Files:
/etc/default/openvpn changed [not included]

-- debconf information excluded

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Michael Biebl]

Hi

Am 12.06.2017 um 20:33 schrieb Andreas Beckmann:
> Switching desktop-file-utils or/and shared-mime-info to -noawait
> triggers does not solve the problem.

So afaics there is nothing that can be done from the Debian GNOME team
side, right?

> I can confirm that the ca-certificates-java change triggered the bug
> (i.e. backing it out makes the problem go away, but this is not a solution).
> 
> I can also confirm that the changes I suggested in #863820 (adding
> adding Breaks: tzdata-java to gcc-6-base) would fix this upgrade path.
> It shakes the upgrade order quite well for this case ...
> (I can post the log if someone is interested.)
> According to piuparts, the upgrade paths of about 860 packages in
> jessie2stretch-rcmd would be affected by this change (because
> tzdata-java gets installed in jessie). These can be retested quickly.

I see that #863820 is still open and apparently also affects other
upgrade paths. Shouldn't this be bumped to RC?
What are we going to do about this? A failure to dist-upgrade our
default desktop environment is pretty bad.
Is there some known workaround which we could document in the release
notes at least?
From what I can see, wouldn't it be better to drop the the Breaks:
tzdata-java from openjdk-8-jdk-headless again?



-- 
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#761658: reliably disable DNS resolving

[Michael Biebl]

Hi

Am 14.06.2017 um 19:49 schrieb benaryorg:
> As this is about the default nameservers to be used when there is
> nothing else configured, how would I disable DNS resolution then?

First of all, systemd-resolved is not used and enabled by default.
If you actually do use systemd-resolved, disabling the
fallback DNS server(s) is trivial.

Either edit /etc/systemd/resolved.conf and set 
FallbackDNS=

or create a drop-in snippet like this:
mkdir /etc/systemd/resolved.conf.d/
echo -e "[Resolve]\nFallbackDNS=" > 
/etc/systemd/resolved.conf.d/no-fallback.conf

Then run systemctl restart systemd-resolved.service.

-- 
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#761658: urgency of a fix before stretch

[Michael Biebl]

Am 02.06.2017 um 16:46 schrieb Norbert Preining:
>> Your reasoning is flawed. The Google DNS servers are not set as default.
> 
> AC_ARG_WITH(dns-servers,
> AS_HELP_STRING([--with-dns-servers=DNSSERVERS],
> [Space-separated list of default DNS servers]),
> [DNS_SERVERS="$withval"],
> [DNS_SERVERS="8.8.8.8 8.8.4.4 2001:4860:4860:: 
> 2001:4860:4860::8844"])
> 
> and I don't see any usage of --with-dns-servers ?
> 
> Please explain?

You're the one who needs to explain a hostile NMU.
Do you actually know what this is about?


-- 
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#761658: urgency of a fix before stretch

[Michael Biebl]

Am 02.06.2017 um 16:32 schrieb Norbert Preining:
> Dear maintainers,
> 
> leaking information, whatsoever, is not acceptable in Debian, and against
> policy, at least lintian errors out on many occasions with
>   privacy-foobar*
> errors.
> 
> Setting the default servers to Google is not acceptable. 
> 
> Ignoring this fact with the explanation that one can *disable* it is
> not sufficient. Reason: *Every* leak can be disabled by unplugging the
> network cable. 
> 
> This is not a solution.
> 
> I am planning to upload an NMU fixing this issue to DELAY3 and hope that
> release managers allow this fix into stretch.

Your reasoning is flawed. The Google DNS servers are not set as default.
Neither is resolved enabled by default.

So I object to your hostile NMU.



-- 
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#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

[Michael Biebl]

On Wed, 31 May 2017 13:26:36 -0400 Daniel Kahn Gillmor 
wrote:

> I apologize for the oversight, and want to know if it'd be ok for me to
> upload 2.1.2-9.2 using the attached debdiff.  I've pushed a queue of
> these changes into the "unstable" branch at
> https://anonscm.debian.org/git/collab-maint/runit.git already if you'd
> prefer to review them there.

Seems like you want a Breaks/Replaces: runit-init in runit to ensure the
package is properly upgraded for users who have already runit-init
installed.

-- 
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#781535: unarchiving 781535, found 781535 in 3.22.3-2

[Michael Biebl]

On Fri, 02 Jun 2017 01:49:49 +0200 Andreas Beckmann  wrote:
> unarchive 781535
> found 781535 3.22.3-2
> thanks

Andreas, can you explain why you reopened this bug report?


-- 
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#863447: dh_install -X is ignored for --list/fail-missing

[Michael Biebl]

Am 31.05.2017 um 22:23 schrieb Iain Lane:
> On Sat, May 27, 2017 at 12:51:38AM +0200, Michael Biebl wrote:
>> I also note, that usr/share/doc/NetworkManager/examples/server.conf is
>> actually installed via debian/network-manager.examples, which contains:
>> debian/tmp/usr/share/doc/NetworkManager/examples/server.conf
>>
>> I assume dh_installexamples is simply not updated yet to support the new
>> dh_missing functionality?
> 
> This also happens with dh_install --list-missing currently[0]. I *guess*
> that this is because dh_install is run first, before all the other
> dh_installfoo commands. So dh_install itself has no way of knowing what
> is about to be installed by other commands. This to me seems unfixable
> without either changing the order (at a compat bump?) or removing
> --{list,fail}-missing and running dh_missing after all the dh_installfoo
> commands. AFAICS they will all need to call log_installed_files for this
> to work properly.

Right, I don't think this is fixable with the current dh_install and I
was actually thinking of the new dh_missing helper here which indeed
should run "last" i.e. after all other dh_installfoo helpers.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#744753: anacron: Anacron not triggered when system resumes under systemd

[Michael Biebl]

Hi Peter,

I've just uploaded anacron 2.3-24 to DELAYED/3 with the following changes:


> anacron (2.3-24) unstable; urgency=medium
> 
>   * Team upload.
>   * Reference anacron and anacrontab man page in anacron.service
>   * Use native systemd timer unit to trigger anacron periodically.
> When running under systemd, use a native timer unit which triggers
> anacron.service every hour. If the system was suspended for more then
> one hour, the timer will activate immediately on resume. The timer uses
> a randomized delay of up to 5 minutes. This helps with not overloading
> the system when coming out of suspend.
> Drop anacron-resume.service, as this service is no longer necessary.
>     (Closes: #744753)
> 
>  -- Michael Biebl <bi...@debian.org>  Mon, 29 May 2017 18:36:12 +0200


I've attached the debdiff as well.

Peter, let me know, if you are not happy with this upload, so we can
cancel it or if you are fine with uploading without DELAY. Once the
upload is made, I will push the changes to Git as well.

I haven't changed the SysV code path (yet), which still relies on hooks
to be triggered on resume as I wanted to keep the changes as minimal as
possible this late into the freeze.

We might eventually consolidate the two approaches and use the patch
from Laurent in [1], which drops all hooks and runs anacron every hour
for SysV as well. Something for buster, I'd say.

Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744753#78

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/debian/anacron.anacron-resume.service 
b/debian/anacron.anacron-resume.service
deleted file mode 100644
index 21b840a..000
--- a/debian/anacron.anacron-resume.service
+++ /dev/null
@@ -1,14 +0,0 @@
-[Unit]
-Description=Run anacron jobs at resume
-After=suspend.target
-After=hibernate.target
-After=hybrid-sleep.target
-
-[Service]
-ExecStart=/bin/systemctl --no-block --fail start anacron.service
-
-[Install]
-WantedBy=suspend.target
-WantedBy=hibernate.target
-WantedBy=hybrid-sleep.target
-
diff --git a/debian/anacron.preinst b/debian/anacron.preinst
new file mode 100644
index 000..603d3b4
--- /dev/null
+++ b/debian/anacron.preinst
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+if dpkg --compare-versions "$2" lt-nl 2.3-24; then
+   deb-systemd-helper purge anacron-resume.service >/dev/null
+   deb-systemd-helper unmask anacron-resume.service >/dev/null
+fi
+
+#DEBHELPER#
diff --git a/debian/anacron.service b/debian/anacron.service
index 77af569..46450c3 100644
--- a/debian/anacron.service
+++ b/debian/anacron.service
@@ -2,6 +2,7 @@
 Description=Run anacron jobs
 After=time-sync.target
 ConditionACPower=true
+Documentation=man:anacron man:anacrontab
 
 [Service]
 ExecStart=/usr/sbin/anacron -dsq
diff --git a/debian/anacron.timer b/debian/anacron.timer
new file mode 100644
index 000..8a04eb4
--- /dev/null
+++ b/debian/anacron.timer
@@ -0,0 +1,10 @@
+[Unit]
+Description=Trigger anacron every hour
+
+[Timer]
+OnCalendar=hourly
+RandomizedDelaySec=5m
+Persistent=true
+
+[Install]
+WantedBy=timers.target
diff --git a/debian/changelog b/debian/changelog
index 997e12e..f223e76 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+anacron (2.3-24) unstable; urgency=medium
+
+  * Team upload.
+  * Reference anacron and anacrontab man page in anacron.service
+  * Use native systemd timer unit to trigger anacron periodically.
+When running under systemd, use a native timer unit which triggers
+anacron.service every hour. If the system was suspended for more then
+one hour, the timer will activate immediately on resume. The timer uses
+a randomized delay of up to 5 minutes. This helps with not overloading
+the system when coming out of suspend.
+Drop anacron-resume.service, as this service is no longer necessary.
+(Closes: #744753)
+
+ -- Michael Biebl <bi...@debian.org>  Mon, 29 May 2017 18:36:12 +0200
+
 anacron (2.3-23) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/cron.d b/debian/cron.d
index 1691ffe..505b5c7 100644
--- a/debian/cron.d
+++ b/debian/cron.d
@@ -3,4 +3,4 @@
 SHELL=/bin/sh
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
-30 7* * *   root   test -x /etc/init.d/anacron && /usr/sbin/invoke-rc.d 
anacron start >/dev/null
+30 7* * *   root   [ -x /etc/init.d/anacron ] && if [ ! -d 
/run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi
diff --git a/debian/rules b/debian/rules
index 0f161df..5d44cc4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,14 +18,11 @@ override_dh_auto_install:
install -D -m 755 debian/apm.d debian/anacron/etc/apm/event.d/anacron
install -D -m 755 debian/pm-utils.power.d 
debian/anacron/usr/lib/pm-utils/power.d/anacron
install -D -m 755 debi

Bug#863387: Acknowledgement (dh produces incomplete binary packages)

[Michael Biebl]

Am 26.05.2017 um 05:48 schrieb Debian Bug Tracking System:
> As you can see from the 10.3 log, a lot of helpers are not run, like
> dh_installdirs, dh_bugfiles, dh_lintian, etc.

Comparing the output, I see the following helpers are not run with 10.3:

dh_installdirs
dh_installman
dh_bugfiles
dh_lintian



-- 
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#863387: dh produces incomplete binary packages

[Michael Biebl]

Package: debhelper
Version: 10.3
Severity: grave

Hi,

I just noticed that debhelper from experimental produces incomplete
binary packages.
I've attached log building init-system-helpers with 10.2.5 and 10.3

As you can see from the 10.3 log, a lot of helpers are not run, like
dh_installdirs, dh_bugfiles, dh_lintian, etc.

The result is an incomplete binary package (thus the RC severity).

Regards,
Michael


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.24
ii  dpkg-dev 1.18.24
ii  file 1:5.30-1
ii  libdpkg-perl 1.18.24
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-2
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information
Reading package lists...
dpkg-buildpackage: info: source package init-system-helpers
dpkg-buildpackage: info: source version 1.48
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Bernd Zeimetz 
 dpkg-source --before-build init-system-helpers-1.48
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 debian/rules build
dh build
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/init-system-helpers-1.48'
dh_auto_build
for file in $(ls script/deb-* script/dh_*); do \
pod2man --section=1p --utf8 $file $file.1p; \
done
ls: cannot access 'script/dh_*': No such file or directory
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_auto_test
   create-stamp debian/debhelper-build-stamp
 debian/rules binary
dh binary
   create-stamp debian/debhelper-build-stamp
   dh_testroot
   dh_prep
   dh_auto_install
   debian/rules override_dh_install
make[1]: Entering directory '/init-system-helpers-1.48'
dh_install
[ ! -d debian/init-system-helpers ] || sed -i 's/__VERSION__/1.48/' 
debian/init-system-helpers/usr/sbin/service
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_installdocs
   dh_installchangelogs
   debian/rules override_dh_perl
make[1]: Entering directory '/init-system-helpers-1.48'
dh_perl -d --package=init-system-helpers
dh_perl --no-package=init-system-helpers
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   debian/rules override_dh_gencontrol
make[1]: Entering directory '/init-system-helpers-1.48'
if dpkg-vendor --derives-from ubuntu; then \
dh_gencontrol -- -Valt:sysvinit=""; \
else \
dh_gencontrol -- -Valt:sysvinit="| sysvinit-core"; \
fi
dpkg-gencontrol: warning: Depends field of package init-system-helpers: unknown 
substitution variable ${perl:Depends}
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'init' in '../init_1.48_amd64.deb'.
dpkg-deb: building package 'init-system-helpers' in 
'../init-system-helpers_1.48_all.deb'.
 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../init-system-helpers_1.48_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build init-system-helpers-1.48
dpkg-buildpackage: info: binary-only upload (no source included)
NOTICE: 'init-system-helpers' packaging is maintained in the 'Git' version 
control system at:
https://anonscm.debian.org/git/collab-maint/init-system-helpers.git
Please use:
git clone https://anonscm.debian.org/git/collab-maint/init-system-helpers.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'init-system-helpers_1.48.dsc'
Skipping already downloaded file 'init-system-helpers_1.48.tar.xz'
Need to get 0 B of source archives.

drwxr-xr-x root/root 0 2017-05-02 10:20 ./
drwxr-xr-x root/root 0 2017-05-02 10:20 ./usr/
drwxr-xr-x root/root 0 2017-05-02 10:20 ./usr/bin/
-rwxr-xr-x root/root 20142 2017-05-02 10:20 ./usr/bin/deb-systemd-helper
-rwxr-xr-x root/root  4507 2017-05-02 10:20 ./usr/bin/deb-systemd-invoke
drwxr-xr-x root/root 0 2017-05-02 10:20 ./usr/sbin/
-rwxr-xr-x root/root 18110 2017-05-02 10:20 ./usr/sbin/invoke-rc.d
-rwxr-xr-x root/root 10061 2017-05-02 10:20 ./usr/sbin/service

Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot

[Michael Biebl]

Am 18.05.2017 um 10:32 schrieb Christoph Biedl:
> Michael Biebl wrote...
> 
>> To mark as mountpoint as network mount, there is the _netdev mount
>> option.
> 
> While I can confirm this provides a sane and safe shutdown for a mounted
> AoE-device, this works only if the device was initially mounted using
> that extra option. A later "mount -o remount,_netdev" exits zero but
> does not change /proc/mounts, hence resulting in havoc. If you could
> shed some light on this?
> 
>> See man systemd.mount. systemd tries to autodetect that for
>> various network file systems
>>
>> https://github.com/systemd/systemd/blob/master/src/fstab-generator/fstab-generator.c#L164
>>
>> https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c#L516
> 
> As a suggestion (probably too late for stretch), an extension of that
> check could inspect the device name as well, to detect AoE, NBD and even
> iSCSI devices - the latter probably needs some extra magic.

That sounds like a reasonable request if those mount points can be
detected reliably.
Would you mind filing an upstream bug report that at
https://github.com/systemd/systemd/issues

I personally have no experience with AoE

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

[Michael Biebl]

Control: tags -1 moreinfo unreproducible
Control: severity -1 normal

Am 14.05.2017 um 22:57 schrieb Brian Warner:
> Package: libvte-2.91-0
> Version: 0.46.1-1
> Severity: grave
> 
> There seems to be a bug in sid's libvte, such that dumping a large
> amount of text to stdout in a short period of time causes the terminal
> program to crash. "cat" of a file with 1MB of the letter "a" is
> sufficient to reproduce it.

I just created a test file the size of 1GB. gnome-terminal and
xfce4-terminal handled that without a hitch.
So, given that this problem seems to be not generally reproducible, I'm
downgrading the severity accordingly. (up-to-date debian sid, amd64)


If you can reliably reproduce the problem, it would be great if you can
file an upstream bug report at
https://bugzilla.gnome.org/enter_bug.cgi?product=vte

A backtrace would certainly be helpful for upstream to further diagnose
this.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#857573: Processed: Re: systemd: Raise network interfaces fails to stop cleanly on shutdown/reboot

[Michael Biebl]

Am 14.05.2017 um 11:36 schrieb Guus Sliepen:

> Another option is to explicitly add a dependency on the network for a
> given mount point in /etc/fstab, see the systemd.mount manpage.
> Basically, the following should work:
> 
> /dev/etherd/...  /mountpoint  ext4 x-systemd.requires=network-online.target  
> 0  2

To mark as mountpoint as network mount, there is the _netdev mount
option. See man systemd.mount. systemd tries to autodetect that for
various network file systems

https://github.com/systemd/systemd/blob/master/src/fstab-generator/fstab-generator.c#L164

https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c#L516



-- 
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#862509: not a drop-in replacement for pkg-config, doesn't properly handle --define-variable

[Michael Biebl]

Package: pkgconf
Version: 0.9.12-5
Severity: serious

Hi,

today I was puzzled by a package failing to build rather randomly

https://buildd.debian.org/status/package.php?p=network-manager-pptp=experimental

It turns out, some buildds installed pkgconf instead of pkg-config,
which resulted in the package failing to build.
The package in question uses
pkg-config --define-variable prefix='\${prefix}' --variable vpnservicedir libnm

With pkg-config this resolves to
${prefix}/lib/NetworkManager/VPN

With pkgconf this resolves to
\/lib/NetworkManager/VPN

As a result, files were installed at the wrong place, trying a
dh_install failure.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pkgconf depends on:
ii  libc6 2.24-10
ii  libdpkg-perl  1.18.23

pkgconf recommends no packages.

pkgconf suggests no packages.

-- no debconf information

Bug#862490: systemd 232-22 hangs with watchdog timeout, kills self with SIGABRT

[Michael Biebl]

Control: tags -1 + moreinfo

Am 13.05.2017 um 16:48 schrieb Mike Edwards:
> Package: systemd
> Version: 232-23
> Severity: critical
> Justification: causes serious data loss
> 
> * Note that this report applies to 232-22 - I just did an apt upgrade
> immediately before filing this bug report.
> 
> 
> This is the second time in as many days that this system has hung (console 
> unresponsive,
> unreachable on network, VMs it hosts with Xen dead).  Unfortunately, the 
> first time
> this occurred, logs weren't synced to disk at the time of the crash, so I had 
> nothing
> to go on.  This time around, I was able to have an external host capture log 
> entries,
> of which there are two:
> 
> May 13 04:04:05 balrog0 systemd[1]: systemd-logind.service: Watchdog timeout 
> (limit 3min)!
> May 13 04:04:05 balrog0 systemd[1]: systemd-logind.service: Killing process 
> 1270 (systemd-logind) with signal SIGABRT.

But this is systemd-logind, not systemd, which doesn't respond.
And apparently systemd is still active, otherwise it couldn't kill the
non-responsing systemd-logind process.

Where exactly does systemd crash? Where is the data loss?
Please provide more details.
If you can't access the system via network, it sounds more like a kernel
problem, maybe hardware or Xrelated.

If systemd/PID 1 crashes, it would only freeze itself, but the system
would still be running and accessible via the network.

So my guess is, that the problem you see is not related to systemd at all.



-- 
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#861683: Install xserver-xorg-legacy by default for stretch

[Michael Biebl]

Am 10.05.2017 um 07:32 schrieb Moritz Muehlenhoff:
> On Tue, May 02, 2017 at 07:39:37PM +0200, Michael Biebl wrote:
>> Same is true for users of startx. They need the suid wrapper provided by
>> xserver-xorg-legacy in such a case.

such a case == a non-KMS driver being in use.

> That's not true. I use the text mode console nearly all the time and only 
> start X as needed via startx, that works fine without the setuid wrapper.

What driver do you use?


-- 
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#712612: gcr: diff for NMU version 3.20.0-5.1

[Michael Biebl]

Am 06.05.2017 um 10:43 schrieb Christoph Biedl:
> Michael Biebl wrote...
> 
>> Am 06.05.2017 um 00:00 schrieb Christoph Biedl:
> 
>>> I've prepared an NMU for gcr (versioned as 3.20.0-5.1), upload to
>>> DELAYED/5 will follow in a few hours. Please feel free to tell me if I
>>> should delay it longer.
>>>
>>
>> Seems to be missing doc/
> 
> That's not obvious for me.

Well, Ansgar mentioned this:

> there are two files under a BSD license in build/valgrind/*. In
addition the
> documentation has its own license in docs/reference/COPYING.

He was referring to that file afaics:
https://git.gnome.org/browse/gcr/tree/docs/reference/COPYING



-- 
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#712612: gcr: diff for NMU version 3.20.0-5.1

[Michael Biebl]

Am 06.05.2017 um 00:00 schrieb Christoph Biedl:
> Control: tags 712612 + patch
> Control: tags 712612 + pending
> 
> Chris Lamb wrote...
> 
 there are two files under a BSD license in build/valgrind/*. In addition
 the ocumentation has its own license in docs/reference/COPYING.
> 
> Seems the license is rather bzip, at least it matches
> https://spdx.org/licenses/bzip2-1.0.5.html
> 
>>> Let's turn this into a bug report, so this issue is not forgotten.
>>
>> (June 2013). Raising to RC to ensure this gets fixed :)
> 
> So here we go:
> 
> Dear maintainer,
> 
> I've prepared an NMU for gcr (versioned as 3.20.0-5.1), upload to
> DELAYED/5 will follow in a few hours. Please feel free to tell me if I
> should delay it longer.
> 

Seems to be missing doc/


-- 
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#861683: Package: installation-reports GNOME is not Working

[Michael Biebl]

On Mon, 1 May 2017 00:28:59 -0500 Gerardo Flores 
wrote:
> Package:installation-reports
> Boot method:  (Virtual box)
> 
> Image version: 
> RC3
> Date: Abril 29 20717
> Machine: Virtual BOX DELL Presicion and Lenovo X230
> Processor: Xeon / icore 7
> Memory: En la virtual 2G / Virtual 2GB
> Partitions: Basicos en una sola partición LVM
> 
> Output of lspci -knn (o lspci -nn):  «lspci -nn»)>
> 
> Base System Installation Checklist:   si dicha fase funcionó, «E» si presentó algún fallo y déjela en blanco si
>  no intentó o no usó esta opción.>
> [O] = OK, [E] = Error (descríbalo a continuación), [ ] = didn't try it
> 
> Initial boot:   [E] <¿Funcionó el arranque inicial?>
> Detect network card:[O] <¿Se configuró el hardware de red?>
> Configure network:  [O] <¿Se configuró la red?>
> Detect CD:  [O] <¿Se detectó la unidad de CD?>
> Load installer modules: [O] <¿Se cargaron los módulos del instalador?>
> Detect hard drives: [O] <¿Se detectaron los discos duros?>
> Partition hard drives:  [O] <¿Se particionó el disco duro?>
> Install base system:[O] <¿Se instaló el sistema base?>
> Clock/timezone setup:   [O] <¿Se configuró bien la zona horaria?>
> User/password setup:[O] <¿Se configuró correctamente el usuario?>
> Install tasks:  [O] <¿Se instalaron bien las tareas?>
> Install boot loader:[O] <¿Se instaló el gestor de arranque?>
> Overall install:[E] <¿Reinició correctamente?>
> 
> Comments/Problems:
> 
> Hi, I am writing because you have tried to install Debian 9 for a month, on 
> two different computers with virtual box. And I can not put Gnome. In the 
> installation on a computer I get a red screen. So I just put the base system 
> without graphical environment and then try to install the gnome, the next 
> reboot will not boot. On any of the other desktops no problem is installed. 
> Then
>  I continued testing on different computers and different configurations
>  and continued with the problem I was not allowed to install gnome on 
> reboot after the computer does not boot. And in any desktop without problem 
> and also with only text I have problem only happens with gnome.
> Sorry for my english, in fact I'm using google translator. I hope it helps 
> them to have a shiny Debian, as always. And while happy with my Jessie it 
> works phenomenally :)

Most likely a duplicate of

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861683
seeing that you installed this system using Virtualbox



-- 
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#861683: Install xserver-xorg-legacy by default for stretch

[Michael Biebl]

Source: xorg
Version: 1:7.7+18
Severity: serious

With virtualbox-dkms gone for stretch, trying to install GNOME inside
Virtualbox will lead to gdm failing to start, as it tries to run Xorg as
unprivileged user. This requires a KMS compatible driver though.
Same is true for users of startx. They need the suid wrapper provided by
xserver-xorg-legacy in such a case.

Not having the Xorg.wrap suid wrapper is a worthwile goal, but I guess
we are not quite there yet, as there are still to many popular cases
where it's needed.

I would thus like to see xserver-xorg-legacy added as a Recommends to
one of the xorg packages.

This means it would be installed on upgrades and new installations but
users with a KMS compatible driver can uninstall it.




-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xserver-xorg depends on:
ii  x11-xkb-utils7.7+3+b1
ii  xkb-data 2.19-1
ii  xserver-xorg-core2:1.19.3-1
ii  xserver-xorg-input-all   1:7.7+18
ii  xserver-xorg-input-evdev [xorg-driver-input] 1:2.10.5-1
ii  xserver-xorg-input-libinput [xorg-driver-input]  0.23.0-2
ii  xserver-xorg-input-wacom [xorg-driver-input] 0.34.0-1
ii  xserver-xorg-video-all   1:7.7+18
ii  xserver-xorg-video-amdgpu [xorg-driver-video]1.2.0-1+b1
ii  xserver-xorg-video-ati [xorg-driver-video]   1:7.8.0-1+b1
ii  xserver-xorg-video-fbdev [xorg-driver-video] 1:0.4.4-1+b5
ii  xserver-xorg-video-nouveau [xorg-driver-video]   1:1.0.13-3
ii  xserver-xorg-video-radeon [xorg-driver-video]1:7.8.0-1+b1
ii  xserver-xorg-video-vesa [xorg-driver-video]  1:2.3.4-1+b2
ii  xserver-xorg-video-vmware [xorg-driver-video]1:13.2.1-1+b1

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  13.0.6-1+b2

-- no debconf information

Bug#857995: respawn loop due to insufficient permissions

[Michael Biebl]

Am 02.05.2017 um 13:43 schrieb Michael Biebl:

> After further investigation, this particular information is incorrect,
> it seems. It's not the main gdm3 process which dies. So the respawning
> is not done by systemd, but by the main gdm process:

Which seems to be a result of the session scope of Debian-gdm not being
stopped when the gdm service is stopped, so if you run systemctl stop
gdm.service, the session scope is still running, along with all its
processes:

> │ └─user-109.slice
> │   ├─user@109.service
> │   │ ├─at-spi-dbus-bus.service
> │   │ │ ├─5156 /usr/lib/at-spi2-core/at-spi-bus-launcher
> │   │ │ ├─5161 /usr/bin/dbus-daemon 
> --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
> --print-address 3
> │   │ │ └─5163 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
> │   │ ├─dbus.service
> │   │ │ ├─5133 /usr/bin/dbus-daemon --session --address=systemd: --nofork 
> --nopidfile --systemd-activation
> │   │ │ └─5174 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
> │   │ ├─xdg-permission-store.service
> │   │ │ └─5180 /usr/lib/flatpak/xdg-permission-store
> │   │ └─init.scope
> │   │   ├─5126 /lib/systemd/systemd --user
> │   │   └─5127 (sd-pam)
> │   └─session-c4.scope
> │ ├─5122 gdm-session-worker [pam/gdm-launch-environment]
> │ ├─5131 /usr/lib/gdm3/gdm-wayland-session gnome-session --autostart 
> /usr/share/gdm/greeter/autostart
> │ ├─5135 /usr/lib/gnome-session/gnome-session-binary --autostart 
> /usr/share/gdm/greeter/autostart
> │ ├─5143 /usr/bin/gnome-shell
> │ ├─5149 /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 
> -displayfd 6
> │ ├─5169 /usr/bin/pulseaudio --start --log-target=syslog
> │ ├─5172 /usr/lib/x86_64-linux-gnu/pulse/gconf-helper
> │ └─5189 /usr/lib/gnome-settings-daemon/gnome-settings-daemon

As a workaround, I added
ExecStopPost=/bin/loginctl kill-user Debian-gdm
to gdm.service. This seems enough to make
systemctl restart gdm.service
work


-- 
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#857995: respawn loop due to insufficient permissions

[Michael Biebl]

Am 17.03.2017 um 01:06 schrieb Michael Biebl:
> Am 17.03.2017 um 00:56 schrieb Michael Biebl:

>> To reproduce the problem:
>>
>> reboot, login, logout, switch to console, login as root, systemctl
>> restart gdm3.
>>
>> The result ist a constantly respawned gdm3.service which fails to start
>> properly due to insufficient permissions.
> 
> The constant respawns are done by systemd due to
> 
> Restart=always
> RestartSec=1s
> 
> in gdm.service

After further investigation, this particular information is incorrect,
it seems. It's not the main gdm3 process which dies. So the respawning
is not done by systemd, but by the main gdm process:

Running journalctl -b -1 -u gdm, I get

> Mai 02 13:29:52 pluto systemd[1]: Starting GNOME Display Manager...
> Mai 02 13:29:52 pluto systemd[1]: Started GNOME Display Manager.
> Mai 02 13:29:52 pluto gdm-launch-environment][755]: 
> pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm 
> by (uid=0)
> Mai 02 13:30:00 pluto gdm-password][1509]: pam_unix(gdm-password:session): 
> session opened for user michael by (uid=0)
> Mai 02 13:30:48 pluto systemd[1]: Stopping GNOME Display Manager...
> Mai 02 13:30:48 pluto gdm3[740]: GLib: g_hash_table_find: assertion 'version 
> == hash_table->version' failed
> Mai 02 13:30:48 pluto systemd[1]: Stopped GNOME Display Manager.
> Mai 02 13:30:48 pluto systemd[1]: Starting GNOME Display Manager...
> Mai 02 13:30:48 pluto systemd[1]: Started GNOME Display Manager.
> Mai 02 13:30:48 pluto gdm-launch-environment][2286]: 
> pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm 
> by (uid=0)
> Mai 02 13:30:48 pluto gdm3[2282]: GdmDisplay: display lasted 0.187789 seconds
> Mai 02 13:30:48 pluto gdm3[2282]: Child process -2290 was already dead.
> Mai 02 13:30:48 pluto gdm3[2282]: Child process 2286 was already dead.
> Mai 02 13:30:48 pluto gdm3[2282]: Unable to kill session worker process
> Mai 02 13:30:48 pluto gdm-launch-environment][2306]: 
> pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm 
> by (uid=0)
> Mai 02 13:30:48 pluto gdm3[2282]: Child process -2309 was already dead.
> Mai 02 13:30:48 pluto gdm3[2282]: Child process 2306 was already dead.
> Mai 02 13:30:48 pluto gdm3[2282]: Unable to kill session worker process
> Mai 02 13:30:48 pluto gdm-launch-environment][2314]: 
> pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm 
> by (uid=0)
> Mai 02 13:30:48 pluto gdm3[2282]: GdmDisplay: display lasted 0.128089 seconds
> Mai 02 13:30:48 pluto gdm3[2282]: Child process -2317 was already dead.
> Mai 02 13:30:48 pluto gdm3[2282]: Child process 2314 was already dead.
> Mai 02 13:30:48 pluto gdm3[2282]: Unable to kill session worker process

[and so on, until forcefully rebooting the system]

> Mai 02 13:30:50 pluto systemd[1]: Stopping GNOME Display Manager...
> Mai 02 13:30:51 pluto gdm3[2282]: GdmLocalDisplayFactory: Failed to issue 
> method call: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message 
> recipient disconnected from message bus without replying
> Mai 02 13:30:51 pluto gdm3[2282]: Child process -2518 was already dead.
> Mai 02 13:30:51 pluto gdm3[2282]: Child process 2515 was already dead.
> Mai 02 13:30:51 pluto systemd[1]: Stopped GNOME Display Manager.
> 

This means, we can't workaround this issue by dropping
Restart=always
from gdm.service


-- 
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#857995: respawn loop due to insufficient permissions

[Michael Biebl]

On Thu, 23 Mar 2017 07:10:05 -0400 Jeremy Bicha  wrote:
> By the way, the constant respawn is really annoying when I install
> stretch on VirtualBox.
> 
> I use the latest stretch testing netboot iso to install. Then I need
> to boot to a command line with Internet so I can install
> virtualbox-guest-x11 from sid (in order to be able to use a graphical
> desktop because Debian Security doesn't want VirtualBox in stretch).
> But first I have to wait 5 minutes for gdm to stop trying to load
> (effectively a Denial of Service) before I can use a virtual terminal.

Yeah, noticed this as well. Pretty sucky user experience.
Since virtualbox is no longer available in stretch, as an alternative,
you can use xserver-xorg-legacy.

Might be a good idea if d-i installed that automatically if it detects a
VBox environment.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#861204: deb-systemd-invoke: fails to handle units with escaped characters

[Michael Biebl]

Hi Bernd

Am 30.04.2017 um 05:53 schrieb Bernd Zeimetz:
> Hi Michael,
> 
> any news on that? I could upload an NMU if you thats okay for you.
> Or is there anything else I can help with?

The package is in collab-maint. If you can commit your changes there and
make the upload, this would be great. Whether you name it team upload or
NMU doesn't really matter to me, both would be fine as far as I'm concerned.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#861204: deb-systemd-invoke: fails to handle units with escaped characters

[Michael Biebl]

Am 26.04.2017 um 00:23 schrieb Bernd Zeimetz:
> Hi,
> 
>> Does this break existing services/packages in stretch? If so, which ones?
>> I'm trying to evaluate if this RC or can be fixed for buster.
> 
> yes. As mentioned, #856429 - run-vmblock\x2dfuse.mount from
> open-vm-tools-desktop.

Hm, but #856429 is severity minor. Something doesn't compute here.


-- 
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#861204: deb-systemd-invoke: fails to handle units with escaped characters

[Michael Biebl]

Hi

Am 25.04.2017 um 22:09 schrieb Bernd Zeimetz:
> Package: init-system-helpers
> Version: 1.47
> Severity: serious
> Tags: patch
> 
> Hi,
> 
> to fix #856429 I need to handle a unit with an escaped character
> correctly in the maintainer scripts generated by dh_systemd*.
> 
> Unfortunately deb-systemd-invoke does not quote the unit name
> properly in a systemctl call, so it fails to handle the unit.
> 
> A patch is attached, with it deb-systemd-invoke works as expected.
> I did not test my changes to t/001-deb-systemd-helper.t as I don't
> have the necessary perl module installed and didn't want to mess
> with CPAN. But I'd assume its correct.

Does this break existing services/packages in stretch? If so, which ones?
I'm trying to evaluate if this RC or can be fixed for buster.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#859262: Re: gnome-orca: Gets stuck if target app is busy

[Michael Biebl]

Am 19.04.2017 um 22:37 schrieb Niels Thykier:
> Control: retitle -1 gnome-orca: Gets stuck if target app is busy
> 
> Samuel Thibault:
>> Niels Thykier, on mer. 19 avril 2017 20:19:00 +, wrote:
>>> Time to hunt for some dbus experts who can tell us why a process might
>>> fail to respond to a ping.
>>
>> Well, the application could simply be busy doing other stuff, like
>> processing huge packages lists for synaptic.  And that's not a reason
>> for Orca to freeze, for me that's the most important bug to fix: Orca
>> shouldn't rely on applications behaving correctly.
>>
>> Samuel
>>
> 
> Ok, thanks for clarifying. :)
> 
> I have retitled the bug to reflect the situation.

Is this https://bugzilla.gnome.org/show_bug.cgi?id=756514 maybe?


-- 
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#781155: openbsd-inetd: openbsd-inetd.service should be the main service file

[Michael Biebl]

Am 11.04.2017 um 19:17 schrieb Michael Biebl:
> Renaming the .service file so the SysV init script and systemd service
> unit name align is a valid solution for this particular case. But then
> again, we have other packages where the names don't align.

That said, my recommendation is still that the names should align where
possible. I wouldn't rename a service unit which is provided by
upstream, but if the Debian package maintainer has control over the
names, then making them align seems sensible.

So my recommendation would be to clone this bug report and reassign it
to update-rc.d. I would keep this one (as wishlist) for the renaming part.

The update-rc.d bug should be severity normal or important.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#781155: openbsd-inetd: openbsd-inetd.service should be the main service file

[Michael Biebl]

Am 11.04.2017 um 18:01 schrieb Raphael Hertzog:
> On Tue, 11 Apr 2017, Marco d'Itri wrote:
>> On Apr 11, Niels Thykier  wrote:
>>
>>> Are there any updates on this bug?  If not, then we will be inclined to
>> I do not think that there is anything I can or should do in 
>> openbsd-inetd: the bug should either be closed or downgraded.
> 
> Why aren't you providing openbsd-inetd.service as the real file and
> inetd.service as a symlink ?

I agree that "update-rc.d openbsd-inetd disable" not working properly is
annoying, but it doesn't strike me as an RC bug which should cause the
removal of the package from testing.

Renaming the .service file so the SysV init script and systemd service
unit name align is a valid solution for this particular case. But then
again, we have other packages where the names don't align.

So it could be argued that this should be solved in a more general way.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

control: clone -1 -2
reassign: -2 ftp.debian.org
retitle: -2 RM: gnome-shell-extension-refreshwifi -- ROM; obsolete

Am 08.04.2017 um 18:25 schrieb Jonathan Carter:
> +1, package should be removed
> 
> Last when I checked that extension, stretch hat a slightly older version
> of Gnome that didn't autorefresh. Will update my blog entry to reflect that.

Since you agree, let's turn this into a proper RM request.

Dear ftp-masters, please remove gnome-shell-extension-refreshwifi from
the archive. It was added to workaround a bug in gnome-shell which has
been fixed in the mean time. Nowadays the package is superfluous and
only confuses people.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

Am 8. April 2017 18:25:06 MESZ schrieb Jonathan Carter :
>+1, package should be removed
>
  
Should I reassign this bug to ftp.debian.org so the package is removed 
completely?

Bug#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

Am 08.04.2017 um 17:10 schrieb Michael Biebl:
> Package: gnome-shell-extension-refreshwifi
> Version: 6.0-1
> Severity: serious
> 
> Hi,
> 
> this extensions was originally developed to work around a bug in
> gnome-shell:
> https://bugzilla.gnome.org/show_bug.cgi?id=767918
> 
> This has been fixed in the mean time in gnome-shell 3.22.2 and that fix
> is available in sid and stretch.

https://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-22=3fd65055f93e67fcc3dd595c61c453096908ec09

That's the commit, that went into the gnome-3-22 branch


-- 
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#859885: No longer necessary, should not be released with stretch

[Michael Biebl]

Package: gnome-shell-extension-refreshwifi
Version: 6.0-1
Severity: serious

Hi,

this extensions was originally developed to work around a bug in
gnome-shell:
https://bugzilla.gnome.org/show_bug.cgi?id=767918

This has been fixed in the mean time in gnome-shell 3.22.2 and that fix
is available in sid and stretch.

I therefor think this extension should not be shipped in stretch (or
even removed completely) as this is apparently confusing for users who
think they still need this. See e.g. the comments in 
https://plus.google.com/u/0/+ThorstenLeemhuis/posts/C4NwM8em9md

This was triggered by Jonathans blog post. Would be great if you can
update it accordingly and remove the reference to this particular
extension.

Regards,
Michael



-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

On Mon, 3 Apr 2017 14:37:27 +0200 Michael Biebl <bi...@debian.org> wrote:
> Am 03.04.2017 um 13:32 schrieb Michael Biebl:

> > In jessie, your opendnssec-signer SysV init script didn't use
> > init-d-script, which would explain the regression in stretch.
> 
> After rebooting the test VM using sysvinit, the system get's stuck
> during boot. This confirms that it's not an issue in invoke-rc.d (as
> /etc/init.d/rc start the init scripts directly without using
> invoke-rc.d) but makes this issue even more severe, as it renders the
> system unbootable.

Hm, wait a second. After looking at the SysV init script, it's rather
obvious what's broken:

https://anonscm.debian.org/git/pkg-dns/opendnssec.git/tree/debian/opendnssec-signer.init#n27

This while loop never finishes as you don't actually read from the file.
There's a missing
done < "$TMPFILES"

After you fix that, the service will no longer hang but you'll get those
error messages:

chown: invalid group: 'opendnssec:opendnssec - -'

Starting OpenDNSSEC Signer: opendnsec-signerstart-stop-daemon: warning:
this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
start-stop-daemon: warning: this system is not able to track process names
longer than 15 characters, please use --exec instead of --name.
OpenDNSSEC signer engine version 2.0.4
 failed!


I fear the SysV init scripts for opendnssec-{signer,enforcer} are in a
pretty much borked state atm.
The do_tmpfiles() routine is broken in several ways.

The start/stop routine using --name is broken as well, as you use
NAME=opendnssec-signer
but that isn't the actual name of the binary that is spawned.


-- 
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#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

Am 03.04.2017 um 13:32 schrieb Michael Biebl:
> 
> /usr/sbin/invoke-rc.d doesn't have 15 char limit, so reassigning back to
> opendnssec-signer. As mentioned earlier, this is most likely an issue in
> /lib/init/init-d-script which is used under sysvinit or the init script
> itself. My guess is on the former.
> 
> In jessie, your opendnssec-signer SysV init script didn't use
> init-d-script, which would explain the regression in stretch.

After rebooting the test VM using sysvinit, the system get's stuck
during boot. This confirms that it's not an issue in invoke-rc.d (as
/etc/init.d/rc start the init scripts directly without using
invoke-rc.d) but makes this issue even more severe, as it renders the
system unbootable.


-- 
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#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

Am 03.04.2017 um 12:43 schrieb Michael Biebl:
> Am 03.04.2017 um 11:59 schrieb Ondřej Surý:
>> Control: reassign -1 init-system-helpers
>> Control: affects -1 opendnssec-signer opendnssec-enforcer
>> Control: severity -1 serious
>>
>> Hi,
>>
>> I am quite certain this hasn't been broken prior to stretch as it was
>> working before, so I am bumping the severity to serious as I haven't
>> been able to find anything in the policy that would limit the length of
>> the init script names to 15 characters.
>>
>> If there's an error in the opendnssec, please reassign back.
> 
> It pretty certainly is an issue in start-stop-daemon which can be
> avoided by not using --name.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843419

But I probably need to retract that statement. It's most likely not an
issue in start-stop-daemon itself, as the binary name itself doesn't
exceed 15 chars.
It's most likely the combination of a script name exceeding 15 chars and
the use of init-d-script.


-- 
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#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

Am 03.04.2017 um 13:32 schrieb Michael Biebl:
> /usr/sbin/invoke-rc.d doesn't have 15 char limit, so reassigning back to
> opendnssec-signer. As mentioned earlier, this is most likely an issue in
> /lib/init/init-d-script which is used under sysvinit or the init script
> itself. My guess is on the former.
> 
> In jessie, your opendnssec-signer SysV init script didn't use
> init-d-script, which would explain the regression in stretch.

See the attached screenshot from the test VM. Notice how the script name
is shorted. I guess this is a result of

> if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
> set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
> fi


-- 
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#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

Control: reassign -1 opendnssec-signer
Control: found -1 1:2.0.4-2

Am 03.04.2017 um 11:59 schrieb Ondřej Surý:
> Control: reassign -1 init-system-helpers
> Control: affects -1 opendnssec-signer opendnssec-enforcer
> Control: severity -1 serious
> 
> Hi,
> 
> I am quite certain this hasn't been broken prior to stretch as it was
> working before, so I am bumping the severity to serious as I haven't
> been able to find anything in the policy that would limit the length of
> the init script names to 15 characters.
> 
> If there's an error in the opendnssec, please reassign back.

/usr/sbin/invoke-rc.d doesn't have 15 char limit, so reassigning back to
opendnssec-signer. As mentioned earlier, this is most likely an issue in
/lib/init/init-d-script which is used under sysvinit or the init script
itself. My guess is on the former.

In jessie, your opendnssec-signer SysV init script didn't use
init-d-script, which would explain the regression in stretch.


-- 
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#859419: non-functional after installation (service fails to start)

[Michael Biebl]

Package: opendnssec-enforcer
Version: 1:2.0.4-2
Severity: serious

After running apt-get install opendnssec-enforcer in a pristine Debian
stretch test VM, the service is in a non-functional state.

See attached screenshot





-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#859418: non-functional after installation (service fails to start)

[Michael Biebl]

Package: opendnssec-signer
Version: 1:2.0.4-2
Severity: serious

After running apt-get install opendnssec-signer, the service fails to
start. See attached screenshot from a test VM





-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

Am 03.04.2017 um 12:43 schrieb Michael Biebl:
> Am 03.04.2017 um 11:59 schrieb Ondřej Surý:
>> Control: reassign -1 init-system-helpers
>> Control: affects -1 opendnssec-signer opendnssec-enforcer
>> Control: severity -1 serious
>>
>> Hi,
>>
>> I am quite certain this hasn't been broken prior to stretch as it was
>> working before, so I am bumping the severity to serious as I haven't
>> been able to find anything in the policy that would limit the length of
>> the init script names to 15 characters.
>>
>> If there's an error in the opendnssec, please reassign back.
> 
> It pretty certainly is an issue in start-stop-daemon which can be
> avoided by not using --name.

See also this old bug report of mine
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519128


-- 
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#852059: [Pkg-dns-devel] Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

[Michael Biebl]

Am 03.04.2017 um 11:59 schrieb Ondřej Surý:
> Control: reassign -1 init-system-helpers
> Control: affects -1 opendnssec-signer opendnssec-enforcer
> Control: severity -1 serious
> 
> Hi,
> 
> I am quite certain this hasn't been broken prior to stretch as it was
> working before, so I am bumping the severity to serious as I haven't
> been able to find anything in the policy that would limit the length of
> the init script names to 15 characters.
> 
> If there's an error in the opendnssec, please reassign back.

It pretty certainly is an issue in start-stop-daemon which can be
avoided by not using --name.

This should either be assigned to sysvinit-utils (which provides
init-d-script), to dpkg (which provides start-stop-daemon) or back to
opendnssec to not use init-d-script and --name.

Read the man page of start-stop-daemon:


>-n, --name process-name
>   Check for processes with the name process-name. The 
> process-name is usually the process filename, but it could have been changed 
> by
>   the process itself. Note: on most systems this information is 
> retrieved from the process comm name from the kernel, which tends  to
>   have a relatively short length limit (assuming more than 15 
> characters is non-portable).

See also /lib/init/init-d-script

> do_start_cmd() {
>start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
>$START_ARGS \
>--startas $DAEMON --name $NAME --exec $DAEMON --test > /dev/null \
>|| return 1
>start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
>$START_ARGS \
>--startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS \
>|| return 2



Not a bug invoke-rc.d and thus init-system-helpers.

The original bug reporter was using sysvinit. I'm pretty sure it doesn't
happen under systemd, as you provide a native service file.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#858214: glib2.0: FTBFS (assertion failed: "BRT" == "-03")

[Michael Biebl]

Am 19.03.2017 um 21:56 schrieb Santiago Vila:
> Package: src:glib2.0
> Version: 2.50.3-1
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> but it failed:
> 
> 
> [...]
> 
> ERROR: gdatetime
> 
> 
> **
> GLib:ERROR:/<>/./glib/tests/gdatetime.c:652:test_GDateTime_new_full:
>  assertion failed ("BRT" == g_date_time_get_timezone_abbreviation (dt)): 
> ("BRT" == "-03")
> Aborted
> # random seed: R02S248136f0e155be50c617a3063014ea65
> 
> 
> 

Looks like
https://bugzilla.gnome.org/show_bug.cgi?id=779799


-- 
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#856024: Processed: Adding a conflict in systemd-sysv

[Michael Biebl]

Control: reassgin -1 molly-guard
Control: found -1 0.6.4

Am 18.03.2017 um 19:11 schrieb Francois Marier:
> Control: reassign -1 systemd-sysv
> 
>> This looks like a genuine bug in molly-guard,
> 
> Yes and that's tracked in bug #837928.
> 
> The present bug is specifically about the interaction between
> molly-guard and systemd-sysv.
> 
>> so this RC bug should be assigned to molly-guard.
>>
>> Adding a Breaks to systemd-sysv is backwards.
> 
> If the underlying bug was going to be fixed in time for stretch, then
> sure, that would be ideal. However, that's not going to happen in time.
> 
> The breaks/conflict seems like the best option to resolve this issue
> without removing molly-guard entirely from the release.

What exactly is "the issue"? How can it be reproduced? Why is it
specific to systemd-sysv and does not happen with sysvinit-core?
Why does this conflicts have to be in systemd-sysv (and not say
molly-guard)?

I'm reassigning this back to molly-guard. This needs to be properly
investigated by the molly-guard maintainers first and fixed there.
This is work you need to be doing, not offloading it to someone else.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#855951: Bug #855951: libsecret: diff for NMU version 0.18.5-3.1

[Michael Biebl]

Am 19.03.2017 um 17:48 schrieb Carsten Leonhardt:
> Michael Biebl <bi...@debian.org> writes:
> 
>> I don't remember seeing the test suite to get stuck completely (as it
>> apparently did on kfreebsd-* now).
> 
> It could well be a general problem of the kfreebsd buildds, as they
> regularly get completely stuck during the build of gcc-6 in the last
> weeks.
> 
> Should I go ahead and request the unblock?

Yes, please.

If you want, forwarding the patch to the upstream bug report at
https://bugzilla.gnome.org/show_bug.cgi?id=779041
would be great as well.

-- 
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#855951: Bug #855951: libsecret: diff for NMU version 0.18.5-3.1

[Michael Biebl]

Am 19.03.2017 um 17:22 schrieb Carsten Leonhardt:
> Hi,
> 
>> The changes in 0.18.5-3 were supposed to fix #837067, i.e. the test
>> suite failing to pass on a single CPU machine.
>>
>> Did you test that as well?
> 
> I did now, on a virtual single CPU kfreebsd-amd64 machine. 6 test runs,
> no failures.
> 
> Or is this too modern?
> 
> $ sysctl hw | head -n 3
> hw.machine: amd64
> hw.model: Intel Core i7 9xx (Nehalem Class Core i7)
> hw.ncpu: 1
> 
> 
> I've never looked at this package before the BSP this weekend, does it
> have a history of getting stuck during the tests, like the buildds of
> kfreebsd did just now?

I've seen collection/delete-sync fail once or twice in the past on
slower architectures.
Building on a single CPU machine was apparently sufficient to make this
particular test fail reliably.

I don't remember seeing the test suite to get stuck completely (as it
apparently did on kfreebsd-* now).

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#855951: Bug #855951: libsecret: diff for NMU version 0.18.5-3.1

[Michael Biebl]

Am 19.03.2017 um 12:59 schrieb Carsten Leonhardt:
> Michael Biebl <bi...@debian.org> writes:
> 
>> If you are sure it fixes the issue, feel free to upload without delay.
> 
> I've made a dozen test runs of the collection tests on arm64, all
> passed. After double checking the buildd logs, I noticed a different
> failing test on mipsel, I've made 5 complete test runs there without
> failure.

The changes in 0.18.5-3 were supposed to fix #837067, i.e. the test
suite failing to pass on a single CPU machine.

Did you test that as well?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#855951: Bug #855951: libsecret: diff for NMU version 0.18.5-3.1

[Michael Biebl]

Hi Charsten

Am 18.03.2017 um 19:57 schrieb Carsten Leonhardt:
> Control: tags -1 patch pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for libsecret (versioned as 0.18.5-3.1) and am
> about to upload it to DELAYED/5. Please feel free to tell me if I should
> delay it longer.
> 

If you are sure it fixes the issue, feel free to upload without delay.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#856024: Processed: Adding a conflict in systemd-sysv

[Michael Biebl]

Am 18.03.2017 um 19:11 schrieb Francois Marier:
> Control: reassign -1 systemd-sysv
> 
>> This looks like a genuine bug in molly-guard,
> 
> Yes and that's tracked in bug #837928.

And why is that bug not treated as RC then?

> The present bug is specifically about the interaction between
> molly-guard and systemd-sysv.

No, it's in the broken dpkg-divert handling of molly-guard. You can't
blame systemd-sysv here.

>> so this RC bug should be assigned to molly-guard.
>>
>> Adding a Breaks to systemd-sysv is backwards.
> 
> If the underlying bug was going to be fixed in time for stretch, then
> sure, that would be ideal. However, that's not going to happen in time.
> 
> The breaks/conflict seems like the best option to resolve this issue
> without removing molly-guard entirely from the release.
> 

Well, if molly-guard does not work with the default init system, it
doesn't seem like it's in a releasable state and it should indeed be
removed from stretch.
As such this RC bugs needs to be assigned to molly-guard and not
systemd. Or #837928 needs to be made RC, in which point this bug report
against systemd-sysv is pointless.

Adding a Conflicts to systemd might even be considered a policy violation.

Asking the release team for their input.

-- 
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#854078: network-manager: nm-online returns before network devices got an address

[Michael Biebl]

I've updated the packages at [1] to 1.6.2-3~test0 including the patches
from the th/device-wifi-wait-for-scan-bgo770938 branch.

Would be great if you can give those packages a try and report back.

Regards,
Michael

[1] deb [trusted=yes] https://people.debian.org/~biebl/nm ./
-- 
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#856024: Processed: Adding a conflict in systemd-sysv

[Michael Biebl]

Control: reassign -1 molly-guard
Control: found -1 0.6.4


This looks like a genuine bug in molly-guard, so this RC bug should be
assigned to molly-guard.

Adding a Breaks to systemd-sysv is backwards.


-- 
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#857995: respawn loop due to insufficient permissions

[Michael Biebl]

Am 17.03.2017 um 00:56 schrieb Michael Biebl:
> Package: gdm3
> Version: 3.22.1-2
> Severity: serious
> 
> 
> To reproduce the problem:
> 
> reboot, login, logout, switch to console, login as root, systemctl
> restart gdm3.
> 
> The result ist a constantly respawned gdm3.service which fails to start
> properly due to insufficient permissions.

The constant respawns are done by systemd due to

Restart=always
RestartSec=1s

in gdm.service


-- 
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#801990: gdm3: Keymap is forced to set US

[Michael Biebl]

Am 14.03.2017 um 10:05 schrieb Raphael Hertzog:
> Control: severity -1 serious
> Control: affects -1 gnome-shell
> 
> I also see this for any fresh stretch install where I select the French
> keyboard layout. On first start, the greeting screen (handled by
> gnome-shell AFAIK) uses a default US/qwerty layout and the layout selected
> at installation time is only available as an alternative that you must
> thus manually select to be able to login...
> 
> We really need to fix this before Stretch releases. Hence I'm bumping
> the severity to serious and I'll start to investigate a bit more. But any
> help is welcome because so far I haven't found anything in the upstream
> bug tracker.

Thanks for looking into this, Raphael.
My guess would be that this is either related to accountsservice or the
fact that we don't use gnome-initial-setup. I would start investigating
in that direction.


-- 
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#856036: screen sharing is not working and vino is segfaulting when started manually

[Michael Biebl]

Control: severity -1 normal
Control: tags -1 + moreinfo

On Fri, 24 Feb 2017 19:31:24 +0530 Pirate Praveen 
wrote:
> package: vino
> version: 3.22.0-1
> severity: grave
> justification: makes the package unuseable
> 
> I'm not able to share desktop using vino (5900 socket is not open) and
> when I manually start vino-server I get segmentation fault

I just tried to reproduce the problem with two VMs running both a
default GNOME stretch installation (using the X based session).

Worked without problems. So it doesn't seem to be general problem, thus
downgrading the severity.

Are you, as Andreas suggested, using the GNOME on Wayland session?

-- 
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#788769: marked as done (entangle: FTBFS without networking: relax-ng: failed to load external entity [..] mallard-1.0.rng)

[Michael Biebl]

On Sun, 26 Feb 2017 17:00:22 +0100 Florian Schlichting 
wrote:
> Control: tags -1 +patch
> 
> Hi Michael, Berlin BSP here.
> 
> Given that it's too late now to get a mallard-rng package into Stretch,
> I suggest to ship the mallard-1.0.rng file as part of the yelp-tools
> package for now (e.g. as /usr/share/yelp-tools/mallard/mallard-1.0.rng)
> and simply use that as relaxng schema in yelp-check:

[..]

> Do you want me to prepare an NMU or would you prefer to validate or
> improve upon the fix in some way?

Let's go with this approach for stretch and see if we can improve the
situation in buster.

Florian, can you send us a complete debdiff, which includes the
installation of the mallard-rng schema, changelog entry etc.

Thanks,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#788769: marked as done (entangle: FTBFS without networking: relax-ng: failed to load external entity [..] mallard-1.0.rng)

[Michael Biebl]

Hi Florian, hi release team

On Sun, 26 Feb 2017 17:00:22 +0100 Florian Schlichting 
wrote:
> Control: tags -1 +patch
> 
> Hi Michael, Berlin BSP here.
> 
> Given that it's too late now to get a mallard-rng package into Stretch,
> I suggest to ship the mallard-1.0.rng file as part of the yelp-tools
> package for now (e.g. as /usr/share/yelp-tools/mallard/mallard-1.0.rng)
> and simply use that as relaxng schema in yelp-check:

[..]

> Do you want me to prepare an NMU or would you prefer to validate or
> improve upon the fix in some way?

First of all, thanks a lot for working on this.
I've CCed the release team for their input.

The issue is, that "yelp-check validate" requires network access as it
needs the mallard-1.0.rng schema which is not packaged yet [0].

Now, according to [1], entangle is the only source package actually
running "yelp-check validate" during build [1]. If there is no network
access this doesn't lead to a failed build though, as "yelp-check
validate" always returns 0, even on error (which I consider to be a bug
[2], fwiw).

Shipping a copy of the mallard-rng schema in yelp-tools is a workaround
and I guess Florian agress that packaging the mallard-rng schema is what
should be done (and help with that would be grealy appreciated).

I'm undecided whether we should apply the workaround for stretch given
that we don't produce any build failures, that's why I'd like some input
from the release team on this:

Should we apply Florian's patch [3] or tag the bug as stretch-ignore?
Other suggestions?

Regards,
Michael



[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788769
[1] https://codesearch.debian.net/search?q=yelp-check+validate
[2] https://bugzilla.gnome.org/show_bug.cgi?id=779615
-- 
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