Bug#1083128: nebula: Please update to the newest version

[Tollef Fog Heen]

Package: nebula
Version: 1.6.1+dfsg-3+b4
Severity: wishlist
X-Debbugs-Cc: Tollef Fog Heen 

The version of Nebula in Debian is about two years out of date, could we
please have the newest version packaged?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1064867: xsettingsd: Please ship .service file

[Tollef Fog Heen]

Package: xsettingsd
Version: 1.0.2-1
Severity: wishlist

xsettingsd upstream ships with a .service file which makes this start
automatically when installed.  Could this please be shipped with
xsettingsd?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1062968: initramfs-tools-core: Use zstdmt instead of zstd by default

[Tollef Fog Heen]

Package: initramfs-tools-core
Version: 0.142
Severity: wishlist

It would be nice if initramfs-tools-core used zstdmt (multi-threaded)
instead of plain zstd when creating the initramfs.  On my system, that
saves about 15% of the time spent building the initramfs.

The following change seems sufficient:

--- /usr/sbin/mkinitramfs~  2022-07-12 23:51:34.0 +0200
+++ /usr/sbin/mkinitramfs   2024-02-04 09:09:07.614462279 +0100
@@ -227,7 +227,7 @@
fi
;;
 lz4)   compress="lz4 ${compresslevel} -l" ;;
-zstd)  compress="zstd -q ${compresslevel}"
+zstd)  compress="zstdmt -q ${compresslevel}"
# If we're not doing a reproducible build, enable multithreading
test -z "${SOURCE_DATE_EPOCH}" && compress="$compress -T0"
;;

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1053298: emacs: Buggy handling of transparency changes / blur/unblur

[Tollef Fog Heen]

]] Sean Whitton 

> Hello Tollef,
> 
> Please M-x report-emacs-bug to send this upstream.

Done.

One additional detail is I only see this with the nvidia X11 driver, not
with Intel.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1053298: emacs: Buggy handling of transparency changes / blur/unblur

[Tollef Fog Heen]

Package: emacs
Version: 1:29.1+1-5
Severity: normal
X-Debbugs-Cc: none, Tollef Fog Heen 

In my setup, I make non-focused windows semi-transparent (using Xmonad
and its compose support).  This used to work perfectly, but with the
recent-ish update of emacs from 28.2 to 29.1, this broke.  (Basically,
what's described on
https://hackage.haskell.org/package/xmonad-contrib-0.16/docs/XMonad-Hooks-FadeInactive.html)

I've bisected this down to:

commit b299f173490f5c51476ad3c8436b19bb091c1b00
Author: Po Lu 
Date:   Tue May 10 09:32:59 2022 +0800

Update alpha frame parameter when the window manager changes it

* src/xfns.c (x_set_alpha): New function.  Set
`alpha_identical_p' flag.
(x_frame_parm_handlers): Use it to handle `alpha' instead.

* src/xterm.c (x_set_frame_alpha): Make tests against current
alpha safer.
(handle_one_xevent): Set frame alpha when alpha property
changes.
* src/xterm.h (struct x_output): New flag `alpha_identical_p'.

 src/xfns.c  | 59 ++-
 src/xterm.c | 48 ++--
 src/xterm.h |  4 
 3 files changed, 108 insertions(+), 3 deletions(-)

which seems like a plausible change for causing such a bug.

Note that the transparency of the window corrects itself if there's a
message in the minibuffer, so it seems like emacs isn't always picking
up the change in transparency which happens as it is being focused. 

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Tollef Fog Heen]

]] Gunnar Hjalmarsson 

> On 2023-08-28 13:42, Tollef Fog Heen wrote:
> > ]] Gunnar Hjalmarsson
> > 
> >> What's the output of this command:
> >>
> >> gsettings get org.gnome.desktop.input-sources xkb-options
> > $ gsettings get org.gnome.desktop.input-sources xkb-options
> > ['compose:caps', 'compose:caps', 'grp:alts_toggle', 'lv3:ralt_switch']
> 
> Then run this command:
> 
> gsettings set org.gnome.desktop.input-sources xkb-options "['compose:caps']"

That made the problem go away, but it doesn't really answer how it ended
up there in the first place, though.  I suspect this is something that's
carried from older versions somewhere, but replicating that will be
somewhere between hard and impossible.

Thanks for helping debug this.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Tollef Fog Heen]

]] Gunnar Hjalmarsson 

> What's the output of this command:
> 
> gsettings get org.gnome.desktop.input-sources xkb-options

$ gsettings get org.gnome.desktop.input-sources xkb-options
['compose:caps', 'compose:caps', 'grp:alts_toggle', 'lv3:ralt_switch']

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Tollef Fog Heen]

]] Gunnar Hjalmarsson 

> But you must have set that group(alts_toggle) option somewhere, and on
> a Debian system the /etc/default/keyboard file is a suspect.

$ cat /etc/default/keyboard
# Check /usr/share/doc/keyboard-configuration/README.Debian for
# documentation on what to do after having modified this file.

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL="pc105"
XKBLAYOUT="no"
XKBVARIANT=""
XKBOPTIONS="compose:caps"

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap.  Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
BACKSPACE="guess"

> Otherwise it may depend on which desktop environment you use. You
> never told us that, did you?

gnome-flashback on X11 (with xmonad, but I doubt that makes a
difference).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Tollef Fog Heen]

]] Gunnar Hjalmarsson 

> I can't help asking why you set the "group(alts_toggle)" option at
> all. You don't seem to use any other keyboard layout but Norwegian
> anyway. So even before you have answered, my advice would be to just
> drop that option wherever you set it and move on. ;)

I'm not setting it intentionally, but I suspect somewhere in the xkb
stack.  If I choose just Norwegian as my layout in gnome control center,
I get:

$ setxkbmap -print
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+no+us:2+inet(evdev)+level3(ralt_switch)+compose(caps)+group(alts_toggle):1+group(alts_toggle):2"
   };
xkb_geometry  { include "pc(pc105)" };
};

Which looks pretty bizarre to me, and I have no idea what «us» does
there.

> In any case the issue is not severity "serious", especially not in a
> Debian distro context.

I'd argue that making people unable to write «@» is a release critical
bug in the package.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Tollef Fog Heen]

Package: xkb-data
Version: 2.38-2
Severity: serious
Justification: makes a subset of systems effectively unusable
X-Debbugs-Cc: none, Tollef Fog Heen 

With commit 0fb34101788d84e9a1d98b3730cc7b9295e0f19b in
xkeyboard-config, `group(alts_toggle)` changed behaviour in a way such
that the right alt no longer generates altgr.  This is very problematic
with keyboard layouts such as Norwegian where that is required to type @
(altgr-2) or $ (altgr-4).

setxkmap no -print on my system outputs:

xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+no+inet(evdev)+level3(ralt_switch)+compose(caps)+group(alts_toggle)"
};
xkb_geometry  { include "pc(pc105)" };
};

which includes the problematic toggle.  I don't know if the right fix is
to revert the relevant commit (reintroducing the problem in
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/316)
or something else, but the current way it works is not great.

Happy to help debug this further, let me know what I can provide.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1032819: rancid: Fails to detect output from RouterOS devices

[Tollef Fog Heen]

Package: rancid
Severity: normal
Version: 3.13-1
X-Debbugs-Cc: Tollef Fog Heen 

I have a couple of routeros devices where rancid fails to work correctly
on them, since even though it logs in with +ct200w, routeros seems to
send a bunch of escapes.  The last couple of lines of the .raw file
reads like:

^M^M^M^[[B[admin@vormioox] > q^M[admin@vormioox] > q^[[Ku^M[admin@vormioox] 
> qu^[[Ki^M[admin@vormioox] > qui^[[Kt^M[admin@vormioox] > quit^[[K^M
^Minterrupted
^[7^[[;54r^[8Connection to vormioox.err.no closed.^M^M

rancid then outputs:
vormioox.err.no.raw: missed cmd(s): all commands
vormioox.err.no.raw: End of run not found
vormioox.err.no.raw: clean_run is false
vormioox.err.no.raw: found_end is false

Something like this seems to fix it for me, and ought not to break it
for anyone else.  (Diff might be slightly off; I had to hand-hack it,
but I can provide a clean one if necessary.)

# diff -u routeros.pm~ routeros.pm
--- routeros.pm~2023-03-11 09:08:12.729340483 +0100
+++ routeros.pm 2023-03-12 05:24:30.074961827 +0100
 TOP: while (<$INPUT>) {
tr/\015//d;
-   if (/[>#]\s*quit$/) {
+   if (/[>#]\s*quit(?:\x{1b}\[K)?/m) {
$clean_run=1;
last;
}
@@ -98,7 +99,7 @@
$clean_run = 0;
last;
}
-   while (/\s*($cmds_regexp)\s*$/) {
+   while (/\s*($cmds_regexp)\s*(?:\x{1b}\[K)?$/) {
$cmd = $1;
if (!defined($prompt)) {
$prompt = "\] > ";  # crude but effective
@@ -167,7 +171,7 @@
 while (<$INPUT>) {
tr/\015//d;
last if (/$prompt/);
-   next if (/^(\s*|\s*$cmd\s*)$/);
+   next if (/^(\s*|\s*$cmd\s*)(?:\x{1b}\[K)?$/);
return(1) if (/(bad command name )/);
s/^\s+//g;

@@ -187,7 +191,7 @@
 while (<$INPUT>) {
tr/\015//d;
last if (/$prompt/);
-   next if (/^(\s*|\s*$cmd\s*)$/);
+   next if (/^(\s*|\s*$cmd\s*)(?:\x{1b}\[K)?$/);
return(1) if (/(bad command name )/);
s/^\s+//g;

@@ -204,8 +208,9 @@

 while (<$INPUT>) {
tr/\015//d;
if (/$prompt/) { $found_end=1; $clean_run=1; return 0};
-   next if(/^(\s*|\s*$cmd\s*)$/);
+   next if(/^(\s*|\s*$cmd\s*)(?:\x{1b}\[K)?$/);
next if(/^#/);
return(1) if /(bad command name )/;
s/^\s+//g;

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Tollef Fog Heen]

]] Sunil Mohan Adapa 

> During today's FreedomBox meet, we have discussed that systemd'd
> PrivateTmp= is a better solution than libpam-tmpdir for FreedomBox at 
> least as systemd makes a cleaner mount isolation between processes
> instead of managing directories and permissions.
> 
> For this reason, we believe that we can stop using libpam-tmpdir if
> most of the daemons on the system use PrivateTmp=yes. For a while now, 
> FreedomBox has been forcefully adding systemd security features to
> daemons that don't enable them. Without upstream blessing, we can only 
> do this for smaller applications than something like MariaDB/MySQL due
> the testing effort needed.

They solve completely different problems, though.  One handles PAM
sessions, the other handles services.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Tollef Fog Heen]

]] Robie Basak 

> On Thu, Nov 10, 2022 at 05:37:53PM +0100, Tollef Fog Heen wrote:
> > I think it's more wide than that: If you change UID, you need to
> > sanitise the environment.  Your HOME is likely to be wrong.  PATH might
> > very well be pointing at directories which are not appropriate for the
> > user you're changing the UID to, etc.
> 
> I don't think that this is necessarily obviously the case in general.
> For example, I often use "sudo -s" and *don't* want HOME reset. It
> depends on the purpose of taking different privileges as to what is
> appropriate to reset.

I don't think we're disagreeing here.

> > I'm not sure this is libpam-tmpdir specific, but rather a bit more
> > general: what are the expectations that maintainer scripts can have
> > about the environment they're running in, and how do we make those
> > expectations hold?  This should probably then be documented in policy.
> 
> Agreed, but also, we need a specific answer for TMPDIR. We pass things
> into maintainer scripts because we want to change their behaviour (eg.
> DEBIAN_FRONTEND). So which specific variables are required to be reset
> by maintainer scripts and under what circumstances?

In the specific case of changing users, I'd say any that might influence
the behaviour of what you're executing, whether it's PATH, TMP, TMPDIR,
XDG_DATA_DIRS, PERL5LIB or something else.  I can see arguments both for
and against dpkg ensuring that maintainer scripts run with a sanitised
environment.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Tollef Fog Heen]

]] Robie Basak 

> But are you in essence saying that libpam-tmpdir requires that *every
> maintainer script* that runs things as non-root, or starts processes
> that do that, unset TMPDIR first?

I think it's more wide than that: If you change UID, you need to
sanitise the environment.  Your HOME is likely to be wrong.  PATH might
very well be pointing at directories which are not appropriate for the
user you're changing the UID to, etc.

> I think the answer to this should probably be established by the
> libpam-tmpdir maintainer and documented first, for fear of someone else
> later coming along and saying that the maintainer script incorrectly
> ignores TMPDIR because we started ignoring it to resolve this bug. So I
> copied debian-devel@ for comment.

I'm not sure this is libpam-tmpdir specific, but rather a bit more
general: what are the expectations that maintainer scripts can have
about the environment they're running in, and how do we make those
expectations hold?  This should probably then be documented in policy.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1012076: varnish: Remove me as uploader

[Tollef Fog Heen]

Package: varnish
Severity: normal
X-Debbugs-Cc: Tollef Fog Heen 

Hi,

I haven't been active in maintaining Varnish for quite a few years,
could you please remove me from uploaders?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1007715: RM: yubikey-server-c -- RoM; abandoned

[Tollef Fog Heen]

package: ftp.debian.org

Hi,

I no longer use this software, and I do not believe anyone else does at
this point either, so please remove yubikey-server-c from the archive.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1003955: Acknowledgement (systemd: systemd-networkd: wireguard AllowedIPs is inserted into routing table)

[Tollef Fog Heen]

]] Michael Biebl 

> sorry for the inconvenience

No worries.

> Am 18.01.22 um 17:03 schrieb Tollef Fog Heen:
> > It seems like this is
> > https://github.com/systemd/systemd/issues/21964.
> > 
> 
> I'm working on an update as we speak. 250.3-1 should hit the archive
> later today.

Thanks a lot for the quick reaction on this and that you're maintaining
systemd.  Much appreciated!

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1003955: Acknowledgement (systemd: systemd-networkd: wireguard AllowedIPs is inserted into routing table)

[Tollef Fog Heen]

It seems like this is https://github.com/systemd/systemd/issues/21964.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1003955: systemd: systemd-networkd: wireguard AllowedIPs is inserted into routing table

[Tollef Fog Heen]

Package: systemd
Version: 250.2-3
Severity: critical
Justification: completely breaks network connectivity in certain setups
X-Debbugs-Cc: none, Tollef Fog Heen 

(Feel free to downgrade, but this completely broke network on my testing
system, which weren't it my laptop and sat in front of me, it'd be
really hard to debug.)

It seems like systemd-networkd between 249.7-1 and 250.2-3 started
adding IPs specified in AllowedIPs in WireGuardPeer stanzas in netdev
units to the routing table.

The documentation in systemd.netdev states:

   Note that this only affects routing inside the network interface 
itself, i.e. the
   packets that pass through the tunnel itself. To cause packets to be 
sent via the
   tunnel in the first place, an appropriate route needs to be added as 
well — either in
   the "[Routes]" section on the ".network" matching the wireguard 
interface, or
   externally to systemd-networkd.

This is the historic behaviour, and this behaviour can be had by using
RouteTable=off in the WireGuardPeer section.

The reason it broke is I have a multi-peer wireguard setup where I
direct traffic to the different peers a machine can talk to using BGP
and bird, and therefore has AllowedIPs=0.0.0.0/0 for the netdevs. After
the upgrade, systemd-networkd proceeded to make my default route point
at the tunnels (which are not suitable as default routes) in addition to
my regular default route, causing most of the traffic to end up on the
floor.

It might be possible to detect this in a postinst, but it's probably
brittle, so I'd consider changing the default RouteTable setting to off.

-- System Information:
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-6
ii  libaudit11:3.0.6-1+b1
ii  libblkid12.37.2-6
ii  libc62.33-2
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.27-1
ii  libcryptsetup12  2:2.4.3-1
ii  libfdisk12.37.2-6
ii  libgcrypt20  1.9.4-5
ii  libgnutls30  3.7.2-5
ii  libgpg-error01.43-1
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-6
ii  libpam0g 1.4.0-11
ii  libseccomp2  2.5.3-2
ii  libselinux1  3.3-1+b1
ii  libsystemd0  250.2-3
ii  libzstd1 1.4.8+dfsg-3
ii  mount2.37.2-6
ii  util-linux   2.37.2-6

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.12.20-3
ii  ntp [time-daemon]   1:4.2.8p15+dfsg-1

Versions of packages systemd suggests:
ii  libfido2-11.9.0-1
ii  libtss2-esys-3.0.2-0  3.1.0-3
ii  libtss2-mu0   3.1.0-3
ii  libtss2-rc0   3.1.0-3
ii  policykit-1   0.105-31
ii  systemd-container 250.2-3

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   250.2-3
ii  libpam-systemd   250.2-3
ii  udev 250.2-3

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1001046: todoman: crashes on startup

[Tollef Fog Heen]

]] Tollef Fog Heen 

> I have no idea what's wrong here, except «it used to work» (as in,
> yesterday, but that update included, amongst many others, an update from
> python3-click 7.1.2-1 to 8.0.2-1, so based on the backtrace, maybe
> relevant?)

fwiw, duwngrading to 7.1.2-1 makes todoman not break again, so looks
like both a bug in todoman for not supporting python3-click, and a
missing Breaks (or API bump) in python3-click.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1001046: todoman: crashes on startup

[Tollef Fog Heen]

Package: todoman
Version: 3.9.0-1
Severity: serious
X-Debbugs-Cc: none, Tollef Fog Heen 

I have no idea what's wrong here, except «it used to work» (as in,
yesterday, but that update included, amongst many others, an update from
python3-click 7.1.2-1 to 8.0.2-1, so based on the backtrace, maybe
relevant?)

$ todoman
Traceback (most recent call last):
  File "/usr/bin/todoman", line 33, in 
sys.exit(load_entry_point('todoman==3.9.0', 'console_scripts', 'todoman')())
  File "/usr/lib/python3/dist-packages/click/core.py", line 1126, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1051, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1635, in invoke
super().invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1393, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 752, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 26, in 
new_func
return f(get_current_context(), *args, **kwargs)
 File "/usr/lib/python3/dist-packages/todoman/cli.py", line 39, in wrapper
return f(*a, **kw)
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 312, in cli
invoke_command(
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 322, in 
invoke_command
click_ctx.invoke(cli.commands[command], args)
  File "/usr/lib/python3/dist-packages/click/core.py", line 752, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 84, in 
new_func
return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 752, in invoke
return __callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 39, in wrapper
return f(*a, **kw)
  File "/usr/lib/python3/dist-packages/todoman/cli.py", line 635, in list
hide_list = (len([_ for _ in ctx.db.lists()]) == 1) or 
(len(kwargs["lists"]) == 1)
TypeError: object of type 'NoneType' has no len()

-- System Information:
Versions of packages todoman depends on:
ii  libjs-sphinxdoc4.2.0-5
ii  python33.9.7-1
ii  python3-atomicwrites   1.4.0-2
ii  python3-click  8.0.2-1
ii  python3-click-log  0.2.1-2
ii  python3-configobj  5.0.6-5
ii  python3-dateutil   2.8.1-6
ii  python3-humanize   3.12.0-1
ii  python3-icalendar  4.0.3-4
ii  python3-parsedatetime  2.6-2
ii  python3-tabulate   0.8.7-0.1
ii  python3-urwid  2.1.2-2+b1
ii  python3-xdg0.27-2

todoman recommends no packages.

Versions of packages todoman suggests:
ii  vdirsyncer  0.16.8-2

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1000732: python3-click-threading: broken monkeypatching

[Tollef Fog Heen]

]] Tollef Fog Heen 

> Versions of packages python3-click-threading depends on:
> ii  python33.9.7-1
> ii  python3-click  8.0.2-1

The problem goes away if I downgrade to python3-click 7.1.2-1, so maybe
there's a missing Breaks there too.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1000732: python3-click-threading: broken monkeypatching

[Tollef Fog Heen]

Package: python3-click-threading
Version: 0.4.4-2
Severity: serious
X-Debbugs-Cc: none, Tollef Fog Heen 

It seems like the monkeypatching in
/usr/lib/python3/dist-packages/click_threading/monkey.py is broken, at
least for me. I'm using python3-click-threading by way of vdirsyncer:

$ vdirsyncer -vdebug sync
debug: Using 1 maximal workers.
) -> None
lambda ) -> None: clear._real_click_fn() -> None)
error: Unknown error occurred: unmatched ')' (, line 1)
error: Use `-vdebug` to see the full traceback.
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
30, in inner
debug: f(*a, **kw)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
145, in sync
debug: with wq.join():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/utils.py", line 
364, in join
debug: with ui_worker.patch_click():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/__init__.py", 
line 144, in patch_click
debug: with patch_ui_functions(wrapper):
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/monkey.py", line 
50, in patch_ui_functions
debug: stub_f = eval('lambda {s}: {n}._real_click_fn({a})'

Adding a few prints shows that it's trying do do an eval of the string:

lambda ) -> None: clear._real_click_fn() -> None)

This, unsurprisingly, does not work.  I'm not sure what component has
changed in a way that breaks python3-click-threading, but the patching
seems pretty brittle.

-- System Information:

Versions of packages python3-click-threading depends on:
ii  python33.9.7-1
ii  python3-click  8.0.2-1

python3-click-threading recommends no packages.

python3-click-threading suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#988082: shim-signed: Fails to install on non-UEFI systems

[Tollef Fog Heen]

Package: shim-signed
Version: 1.34~1+deb10u1+15.4-2~deb10u1
Severity: serious
X-Debbugs-Cc: none, Tollef Fog Heen 

Looks like postinst is poking into /sys/firmware/efi, which doesn't
exist on a non-UEFI system.

Preparing to unpack .../shim-signed_1.34~1+deb10u1+15.4-2~deb10u1_amd64.deb ...
Unpacking shim-signed:amd64 (1.34~1+deb10u1+15.4-2~deb10u1) over 
(1.33+15+1533136590.3beb971-7) ...
Preparing to unpack 
.../shim-signed-common_1.34~1+deb10u1+15.4-2~deb10u1_all.deb ...
Unpacking shim-signed-common (1.34~1+deb10u1+15.4-2~deb10u1) over 
(1.33+15+1533136590.3beb971-7) ...
Preparing to unpack .../shim-unsigned_15.4-3~deb10u1_amd64.deb ...
Unpacking shim-unsigned (15.4-3~deb10u1) over (15.4-2~deb10u1) ...
Setter opp shim-signed:amd64 (1.34~1+deb10u1+15.4-2~deb10u1) ...
cat: /sys/firmware/efi/fw_platform_size: No such file or directory
dpkg: error processing package shim-signed:amd64 (--configure):
 installed shim-signed:amd64 package post-installation script subprocess 
returned error exit status 1
Setter opp shim-signed-common (1.34~1+deb10u1+15.4-2~deb10u1) ...
No DKMS packages installed: not changing Secure Boot validation state.
Setter opp shim-unsigned (15.4-3~deb10u1) ...
Det oppsto feil ved behandling av:
 shim-signed:amd64
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

(It's a fair question to ask «why are you installing it here?», in this
particular case, it's a bug, but one could very well be doing this as a
part of migrating from legacy to UEFI boot.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#922666: confirmed bug report

[Tollef Fog Heen]

]] Salvatore Bonaccorso 

> Can you confirm if this issue is still present with a recent kernel?

I haven't seen it for quite some time on my Buster machine, so from my
point of view, it can be closed.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#971515: Status as of last tech-ctte meeting

[Tollef Fog Heen]

]] Philip Hands 

> Tollef Fog Heen  writes:
> 
> > ]] Shengjing Zhu 
> >
> >> Firefox is special, since for Debian desktop users, they need a browser. Is
> >> kubernetes same here?
> >
> > FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
> > nomad, docker swarm) in stable has been keeping back development of the
>   ^^
> 
> Do you really mean stable here?  I had gained the impression that there
> was no prospect of Kubernetes getting into stable, regardless of the
> details of how it ends up being packaged.  Have I misunderstood?

I do mean stable.  I was making a narrow comment about how special or
not Kubernetes is, I don't know if the goal is for it to reach stable or
not.

(My comment above was also slightly imprecise, I've since learned that
Docker Swarm is in Debian, in the docker.io package, thanks to Shengjing
Zhu who pointed it out in private email.)

-- 
Tollef Fog Heen

Bug#971515: Status as of last tech-ctte meeting

[Tollef Fog Heen]

]] Shengjing Zhu 

> Firefox is special, since for Debian desktop users, they need a browser. Is
> kubernetes same here?

FWIW, the lack of Kubernetes or a similar orchestration platform (mesos,
nomad, docker swarm) in stable has been keeping back development of the
next generation way of handling Debian services, since that will need a
reasonable container orchestation platform to build on.  The lack of a
platform is not the only reason for the delay, but it surely hasn't
helped either.

-- 
Tollef Fog Heen, speaking for himself, but as a DSA member

Bug#973951: ipp-usb: Fails to restart

[Tollef Fog Heen]

Package: ipp-usb
Version: 0.9.14-1
Severity: important
X-Debbugs-Cc: none, Tollef Fog Heen 

ipp-usb fails to restart for me, at least when restarted by needrestart:

: tfheen@xoog ~ > systemctl status ipp-usb.service
● ipp-usb.service - Daemon for IPP over USB printer support
 Loaded: loaded (/lib/systemd/system/ipp-usb.service; static)
 Active: activating (start) since Sun 2020-11-08 10:03:33 CET; 41min ago
   Docs: man:ipp-usb(8)
   Main PID: 57922 (ipp-usb)
  Tasks: 11 (limit: 38371)
 Memory: 15.3M
 CGroup: /system.slice/ipp-usb.service
 └─57922 /sbin/ipp-usb udev

as you can see, it's been «starting» for 40+ minutes. This is pretty
annoying, since it makes my apt runs just hang whenever ipp-usb is
restarted.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Versions of packages ipp-usb depends on:
ii  avahi-daemon  0.8-3
ii  libavahi-client3  0.8-3
ii  libavahi-common3  0.8-3
ii  libc6 2.31-4
ii  libusb-1.0-0  2:1.0.23-2

ipp-usb recommends no packages.

ipp-usb suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#681177: run-parts: /etc/cron.daily/mlocate exited with return code 137

[Tollef Fog Heen]

]] The Wanderer 

> I'm not at all sure whether the underlying cause is still the same, but
> I'm getting a very similar-looking failure - albeit with different BUG
> details - after a reboot a few nights ago into a new kernel.

My understanding is that when you get one of those, it indicates a
kernel problem, isn't that so?  If so, it should probably just be
reassigned to linux.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#958286: pavucontrol: Missing escaping of & in device names

[Tollef Fog Heen]

]] Felipe Sateler 

> On Sat, Apr 25, 2020 at 2:34 AM Tollef Fog Heen  wrote:
> 
> ]] Felipe Sateler
>
> > So, I could not reproduce the issue by setting bluez.alias either. 
> >
> > Does the console error happen on applicatin startup? Or when switching 
> to a given tab?
>
> It shows up when the device connects, so either at startup or when I
> turn on the headphones.
>
> I think maybe the problem is related to the «Configuration» tab, since
> the headset is listed there with just «Card Name» as the name.  It's
> shown correctly on both the Playback and Output Devices tabs.
> 
> Ah, so it is the "card" that is the problem, not the sink. That explains why 
> I couldn't reproduce.

Apparently!  It didn't say anything about where it came from, it'd be
really useful if you could ask GTK/GLib to include a backtrace (using
backtrace(3)) when throwing warnings and errors to better trace those.

> I see now that this is already fixed in upstream git. I'll upload the fix 
> shortly. 

That's great, thanks!

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#958286: pavucontrol: Missing escaping of & in device names

[Tollef Fog Heen]

]] Felipe Sateler 

> So, I could not reproduce the issue by setting bluez.alias either. 
> 
> Does the console error happen on applicatin startup? Or when switching to a 
> given tab?

It shows up when the device connects, so either at startup or when I
turn on the headphones.

I think maybe the problem is related to the «Configuration» tab, since
the headset is listed there with just «Card Name» as the name.  It's
shown correctly on both the Playback and Output Devices tabs.

--- pavucontrol-4.0.orig/src/mainwindow.cc
+++ pavucontrol-4.0/src/mainwindow.cc
@@ -368,7 +368,7 @@ void MainWindow::updateCard(const pa_car
 
 description = pa_proplist_gets(info.proplist, PA_PROP_DEVICE_DESCRIPTION);
 w->name = description ? description : info.name;
-w->nameLabel->set_markup(w->name.c_str());
+w->nameLabel->set_text(w->name.c_str());
 
 icon = pa_proplist_gets(info.proplist, PA_PROP_DEVICE_ICON_NAME);
 set_icon_name_fallback(w->iconImage, icon ? icon : "audio-card", 
Gtk::ICON_SIZE_SMALL_TOOLBAR);

seems to fix it for me.  (You could also use g_markup_printf_escaped, I
guess).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#958286: pavucontrol: Missing escaping of & in device names

[Tollef Fog Heen]

]] Felipe Sateler 

> Could you share the output of `pactl list sinks`? It appears the problem is 
> not really in the device description.

Sink #11
State: IDLE
Name: bluez_sink.EC_66_D1_XX_XX_XX.headset_head_unit
Description: Bowers & Wilkins PX
Driver: module-bluez5-device.c
Sample Specification: s16le 1ch 8000Hz
Channel Map: mono
Owner Module: 31
Mute: no
Volume: mono: 37987 /  58%
balance 0.00
Base Volume: 65536 / 100%
Monitor Source: bluez_sink.EC_66_D1_XX_XX_XX.headset_head_unit.monitor
Latency: 24995 usec, configured 28000 usec
Flags: HARDWARE HW_VOLUME_CTRL LATENCY
Properties:
bluetooth.protocol = "headset_head_unit"
device.intended_roles = "phone"
device.description = "Bowers & Wilkins PX"
device.string = "EC:66:D1:XX:XX:XX"
device.api = "bluez"
device.class = "sound"
device.bus = "bluetooth"
device.form_factor = "headphone"
bluez.path = "/org/bluez/hci0/dev_EC_66_D1_XX_XX_XX"
bluez.class = "0x240418"
bluez.alias = "Bowers & Wilkins PX"
device.icon_name = "audio-headphones-bluetooth"
Ports:
headphone-output: Hovudtelefonar (priority: 0, available)
Active Port: headphone-output
    Formats:
pcm

(replaced the last three parts of the bluetooth address with XX, I doubt
that's the problem.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#958286: pavucontrol: Missing escaping of & in device names

[Tollef Fog Heen]

Package: pavucontrol
Version: 4.0-1
Severity: minor

I have a bluetooth headset from Bowers & Wilkins.  It seems like
pavucontrol fails to escape the «&» in the name before feeding it to
GTK, leading to console errors like:

(pavucontrol:416883): Gtk-WARNING **: 20:28:02.902: Failed to set text
'Bowers & Wilkins PX' from markup due to error parsing markup: Error on
line 1: Entity did not end with a semicolon; most likely you used an
ampersand character without intending to start an entity — escape
ampersand as &

Versions of packages pavucontrol depends on:
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libc62.30-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgcc-s1 [libgcc1]  10-20200411-1
ii  libgcc1  1:10-20200411-1
ii  libglib2.0-0 2.64.1-1
ii  libglibmm-2.4-1v52.64.2-1
ii  libgtk-3-0   3.24.18-1
ii  libgtkmm-3.0-1v5 3.24.2-1
ii  libpulse-mainloop-glib0  13.0-5
ii  libpulse013.0-5
ii  libsigc++-2.0-0v52.10.2-1
ii  libstdc++6   10-20200411-1

Versions of packages pavucontrol recommends:
ii  pulseaudio  13.0-5

pavucontrol suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#901238: Acknowledgement (wnorwegian: Both word list files should be in UTF-8, not in ISO-8859 anymore)

[Tollef Fog Heen]

]] Petter Reinholdtsen 

> [Tollef Fog Heen]
> > That's configuration that's up to the admin which of the two different
> > forms of Norwegian should be used as the Norwegian dictionary on the
> > system.
> 
> While I agree with this, it seem to me like a classic use case for the
> alternatives system, and no need for a dictionary-common specific system.
> Why is dictionaries-common used here instead of updated-alternatives?

I don't know the exact reason ssm used for choosing debconf over
update-alternatives back in 1999 (but it was a conscious choice, he
started out with u-a)

Alternatives doesn't provide any debconf integration with all the
features that include such as preseeding and explaining what the choice
is about.  If it grew those abilities, I think switching to that would
be interesting.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#950426: O: yubikey-server-c -- Yubikey validation server

[Tollef Fog Heen]

Package: wnpp
Severity: normal

Description-en: Yubikey validation server
 Yubikeys are USB tokens that act like keyboards and generate one-time
 passwords.  The tokens are produced and sold by Yubico
 .
 This is a server that checks the validity of those OTP tokens.  There
 are servers written in Java and PHP, while this one is written in C
 .
 It implements the server side of the API as described on
 http://www.yubico.com/developers/api/ and can be used with any client
 that implements the same API.


I no longer use this, and I increasingly think it's a bad idea to write
security-sensitive software in C, so I'm going to ask for its removal
unless it's adopted by somebody fairly quickly.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#948823: xmonad: Does not work with GNOME 3.34

[Tollef Fog Heen]

Package: xmonad
Version: 0.15-1
Severity: important

it seems like the set of required components for gnome have changed in
3.34, putting the following in
/usr/share/gnome-session/sessions/gnome-flashback-xmonad.session works
for me:

RequiredComponents=gnome-flashback;gnome-panel;xmonad;org.gnome.SettingsDaemon.A11ySettings;org.gnome.SettingsDaemon.Color;org.gnome.SettingsDaemon.Datetime;org.gnome.SettingsDaemon.Housekeeping;org.gnome.SettingsDaemon.Keyboard;org.gnome.SettingsDaemon.MediaKeys;org.gnome.SettingsDaemon.Power;org.gnome.SettingsDaemon.PrintNotifications;org.gnome.SettingsDaemon.Rfkill;org.gnome.SettingsDaemon.ScreensaverProxy;org.gnome.SettingsDaemon.Sharing;org.gnome.SettingsDaemon.Smartcard;org.gnome.SettingsDaemon.Sound;org.gnome.SettingsDaemon.Wacom;org.gnome.SettingsDaemon.XSettings;

In addition, 3.34 seems to use systemd for user sessions, and you need
to ship a
/usr/lib/systemd/user/gnome-session-x11@gnome-flashback-xmonad.target
with the following contents:

[Unit]
Description=GNOME Flashback Session
OnFailure=gnome-session-failed.target
OnFailureJobMode=replace
DefaultDependencies=no
RefuseManualStart=no

Conflicts=shutdown.target gnome-session-shutdown.target
PartOf=graphical-session.target

# Pull in all X11-specific services the session might depend on
Requires=gnome-session-x11-services.target

BindsTo=gnome-session@.target
After=gnome-session@.target

BindsTo=gnome-flashback.target
After=gnome-flashback.target

BindsTo=gnome-session.target
After=gnome-session.target

without this, it will try to start gnome-shell and everything crashes
and burns pretty quickly.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Tollef Fog Heen]

]] Stephen Kitt 

> I noticed that the pkg-config hook is very careful to only
> touch /usr/bin/*-pkg-config links it owns. Would it be acceptable to continue
> shipping MinGW-w64 pkg-config instances there? Not using crosswrapper, of
> course, but a MinGW-w64-hosted implementation.

Without binding future pkg-config maintainers too much: I think this is
fine for you to do.  It might change in the future, at which point
we'll talk and figure the way forward, but I don't think that should be
particularly problematic.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Tollef Fog Heen]

]] Stephen Kitt 

Hi,

> On Mon, 17 Jun 2019 22:20:11 +0200, Stefan Weil  wrote:
> > I am not sure whether reassigning the bug to mingw-w64-tools is the best
> > way to get a quick (intermediate) solution. If it helps, I have no
> > objection, although I thought that patching the pkg-config package would
> > be easier to fix that special issue.
> 
> Oh well, I suppose mingw-w64-tools *is* the right place to deal with this, if
> pkg-config is only intended to handle Debian architectures. If you do
> reassign the bug, please upgrade it to serious and I’ll try to get a fix
> ready in time for Buster.

The crosswrapper in pkg-config does require that the architecture is
known to dpkg, yes.  The /usr/bin/*-pkg-config namespace is managed by
the pkg-config dpkg hook, so other tools should coordinate with
pkg-config if they want to work within that area.  (I'm not even sure
what the pkg-config directory for i686-w64-mingw32 and
x86_64-w64-mingw32 should be.)

As a workaround, I'd set PKG_CONFIG_LIBDIR in a shell script wrapper and
execute that rather than going through the crosswrapper.

It's far too late to change behaviour in the crosswrapper for buster,
but I'm happy to discuss solutions for bullseye.  Helmut should
absolutely be part of those discussions as he's probably the biggest
user of the crosswrapper.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#930871: arbtt: unsupported tags leads to error

[Tollef Fog Heen]

]] Joachim Breitner 

Hi!

> I was young and naive when I designed the file format, and sometimes
> when arbtt-stats is killed at the wrong moment, invalid (partial) data
> is written. You can recover most using the arbtt-recover tool.

Thanks, that helped a lot.  It would be useful if this was referenced in
the error output, could you consider adding that, since it won't recover
by itself?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#930871: arbtt: unsupported tags leads to error

[Tollef Fog Heen]

Package: arbtt
Version: 0.10.1-1
Severity: important

arbtt seems to have written data which it is unable to read back for me:

$ arbtt-stats -t 
Processing data 
[===>.]  
11%arbtt-stats: Unsupported TimeLogEntry version tag 0
CallStack (from HasCallStack):
  error, called at src/Data.hs:90:15 in main:Data

I'm unable to get it to output anything from the stream, it always stops
at what seems to be the same place.

Versions of packages arbtt depends on:
ii  libatomic18.3.0-6
ii  libc6 2.28-10
ii  libffi6   3.2.1-9
ii  libgmp10  2:6.1.2+dfsg-4
ii  libpcre3  2:8.39-12
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxrandr22:1.5.1-1
ii  libxss1   1:1.2.3-1


-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#930573: Workaround

[Tollef Fog Heen]

A better workaround is probably:

(define-advice open-gnutls-stream (:after (&rest args) workaround-for-930573)
  (sleep-for 0 250))

This adds 250msec to opening of gnutls connections, which is a lot less
noisy than increasing the verbosity level

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#930573: emacs: gnus/nnimap/gnutls race condition

[Tollef Fog Heen]

Package: emacs
Version: 1:26.1+1-3.2
Severity: normal

After I upgraded my mail server (dovecot) to buster, gnus completely
refuses to connect, with a blank error message:

Opening connection to mail.err.no via tls...
Unable to open server nnimap+err due to: Process *nnimap* not running
nnimap (err) open error: ‘’.  Continue? (y or n) n
Couldn’t open server on err
Warning: Unable to open server nnimap+err due to: Process *nnimap* not running

After a bit of debugging, this seems to be some sort of race
condition. If I slow down network-stream-open-tls slightly by adding a
few message calls in the middle, or a (setq gnutls-log-level 1), gnus
starts up just fine.  To me, it might look like it's not properly
waiting for the server to actually write the initial greeting and that now ends 
up
in a different packet than what it used to end up in the initial packet.

This is completely reproducible for me, across machines, happy to
provide more information if that's useful.

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

Versions of packages emacs depends on:
ii  emacs-gtk  1:26.1+1-3.2

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#929495: libpam-tmpdir: too strict permissions on /tmp/user may lead to errors in other programs

[Tollef Fog Heen]

]] Andrey Bondarenko 

Hi,

> By default both / and /tmp are world readable. Many programs was not
> tested with unreadable $TMP parent. Some of them may have bugs that may
> be triggered by pam_tmpfs installation. Find and fix all such bugs will
> be very time consuming task. Also pam_tmpdir may be installed by package
> dependencies, so user may not even notice change that caused the bug.

Given that this is the first time I've heard of such a bug in another
package (since I wrote pam-tmpdir back in 2001), I don't think they are
particularly common.

> Changing permissions of /tmp/user in pam_tmpdir package, to 755 will not
> reduce security mutch, but will stop triggering bugs in other packages
> by default.

While this is true, I disagree about the tradeoff.

> > If you precreate the directory before pam_tmpdir is invoked, the
> > permissions aren't changed.
> 
> Pre-creating /tmp/user by local admin is a possible workaround. Local
> admin may create rc.d script or systemd unit that creates /tmp/user with
> desired permissions, but would not providing such a script by the
> package itself be a better solution?

echo "d /tmp/user 0755 root root -" > /etc/tmpfiles.d/pam-tmpfiles.conf

I guess I could ship that in the default configuration, but with 0711
permissions, that'll make it pretty easy to find and change for
interested users.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#929495: libpam-tmpdir: too strict permissions on /tmp/user may lead to errors in other programs

[Tollef Fog Heen]

]] Andrey Bondarenko 

> pam_tmpdir creates /tmp/user with strict permissions (drwx--x--x root:root)
> Some programs report unwanted permission denied errors while walking from 
> temporary file in $TMP to /. For example error appears in gwenview.

That sounds like a bug in gwenview; why would it try to walk the tree?

> Is there are good reason for removing world readable permissions from 
> /tmp/user
> by default? If defaults cannot be changed, is it possible to make it 
> configurable
> option so local administrator can decide what permissions use for /tmp/user?

If you precreate the directory before pam_tmpdir is invoked, the
permissions aren't changed.  Note that  o+r is fine, but o+w is not and
will lead to PAM failures, so you probably want to make pam_tmpdir as
optional while playing around.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#927079: libpam-script: Filters environment variables

[Tollef Fog Heen]

Package: libpam-script
Severity: normal

It seems like libpam-script filters the set of environment variables
that are set, and there is no way to either turn this off or add extra
environment variables that are passed through.

I'm interested in inspecting the SSH_AUTH_INFO_0 environment variable
set by newer versions of OpenSSH, but as this is not on the list of
variables that are passed through, I can't.

This greatly reduces the usefulness of libpam-script for me, so if this
could either be optional or the list of variables could be added to,
that'd be great.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#923818: mosquitto: provide systemd unit

[Tollef Fog Heen]

Source: mosquitto
Severity: wishlist

It would be useful if mosquitto provided a systemd unit, I suggest
something like:

[Unit]
Description=mosquitto MQTT v3.1 message broker

[Service]
ExecStart=/usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Restart=on-failure

[Install]
WantedBy=multi-user.target

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#922666: linux-image-4.19.0-2-amd64: Trackpad and trackpoint stop working after suspend

[Tollef Fog Heen]

rsions of packages linux-image-4.19.0-2-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod25-2
ii  linux-base  4.5

Versions of packages linux-image-4.19.0-2-amd64 recommends:
ii  apparmor 2.13.2-7
ii  firmware-linux-free  3.4
ii  irqbalance   1.5.0-3

Versions of packages linux-image-4.19.0-2-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20171011.af7e95c3+dfsg1-6
ii  grub-efi-amd64  2.02+dfsg1-10
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-2-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20190114-1
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic       
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#920553: pkg-config: Undefined subroutine &main::warning called at /usr/share/pkg-config-dpkghook line 34.

[Tollef Fog Heen]

]] Axel Beckert 

Hi, thanks for reporting this.

> pkg-config fails to upgrade on two machines (1x amd64 with i386 as
> foreign architecture, 1x pure i386) as follows for me:

Both of those probably have a non-valid dpkg architecture enabled, such
as «x86».  What does dpkg --print-foreign-architectures on them output?

[...]

> It does though not happen on all of my sid machines, including other
> amd64 machines. Maybe a missing dependency on some Perl module or so?

It was a missing import; I've fixed this now, but if it's something else
than what I think it is, then it'd be good to get the other bug fixed
too, so it'd be good to get an answer to my question above.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#916772: pkg-config: missing Depends: dpkg-dev

[Tollef Fog Heen]

severity 916772 normal
thanks

]] Helmut Grohne 

> # i686-linux-gnu-pkg-config --libs libssl

This is a supported, but non-standard configuration, so I'm downgrading
this from serious.

> If adding dpkg-dev to Depends is not desired, the cross-wrapper could be
> extended to give a useful error message in case $multiarch is empty:
> 
> --- /usr/share/pkg-config-crosswrapper
> +++ /usr/share/pkg-config-crosswrapper
> @@ -11,6 +11,10 @@
>triplet="${basename%-pkg-config}"
># Normalized multiarch path if any, e.g. i386-linux-gnu for i386
>multiarch="`dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 
> 2>/dev/null`"
> +  if test "$?" != 0; then
> +echo "Please apt install dpkg-dev to use this program." 1>&2
> +exit 1
> +  fi
># Native multiarch path
>native_multiarch="$(cat /usr/lib/pkg-config.multiarch)"

This looks reasonable.

> dpkg-dev should be added to Recommends in that case.

Suggests seems more appropriate here.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Tollef Fog Heen]

]] Stéphane Glondu 

Hi,

> Le 20/01/2019 à 23:14, Ian Jackson a écrit :
> > In #919622 and the associated debian-devel thread,
> >  "Conflict over /usr/bin/dune"
> >   https://lists.debian.org/debian-devel/2019/01/msg00227.html
> > the file conflict over /usr/bin/dune was discussed.
> > 
> > The rough consensus of the debian-devel thread was that /usr/bin/dune
> > ought definitely not to be taken by the ocaml build system, and that
> > the best claim on it was the C++ library which already provides a
> > number of /usr/bin/dune?* binaries.
> 
> I do not agree there was such concensus.

FWIW, I don't think there was any particularly clear consensus, and I
also don't think that an absence of a veto from the whitedune
maintainers makes it ok to go ahead and NMU whitedune with a renamed
binary.

[...]

> > Additionally the binary package name `dune' for the ocaml tool is bad,
> > too.
> 
> Actually, I am not fond of the `dune' name either, but I think it's not
> my job to judge and rename it. And I would feel ridiculous asking
> upstream for a change (I am already ashamed of this situation).

It's not unusual for packages in Debian to be renamed and have their
binaries renamed to avoid naming conflicts and it is part of the work of
being a maintainer to ensure a package fits well into the Debian
ecosystem.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#915407: libpam-systemd: please add a virtual package "logind" to allow alternatives

[Tollef Fog Heen]

]] Felipe Sateler 

Two minor typos.

> The proposed virtual packages are:
> 
> logind: a org.freedesktop.login1 D-Bus API implementation

«an org…»

> default-logind: should be provided by the distributions default logind 
> provider (currently pam-systemd)

distribution's.

Otherwise, this looks like a good idea to me.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Call for vote on disallowing the use dpkg's vendor series in the archive

[Tollef Fog Heen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

]] Tollef Fog Heen 

> A: Approve resolution, disallowing the use of dpkg's vendor series
> F: Further Discussion

I vote A > F.

- -- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAlvgl3MACgkQtlpIccoZ
1xfADw/+LklAe9eq0NT3FBRba+x07C5dG3tuSqqoE6Sz4uipWg5iVhwfsIQ9/QCp
J8+0IbxlsifeH/gyeJg9SFTwb8f/PXhtRRX5s12Pq7wYE+ESMtQcxhVNy9DOchil
nT2NxIMO+T8+Z/FxeXaaVYaFNfgoV41RhFoQOmz+koZnoE01TSA/bR+iHZ1BE5OR
IS8xFGYwn4/TI8yIaiQLOxXXqK+6ZBkgyownf3VHbzFMjoVmMPAULs5IEOREUMQe
lq5GC/a33KUnHgw/Msoy2/wIIqSBh7hs8oS6w+BjyhdzHwbgrjs/OTPCXeDncoUn
lwnhUkw3mUNDMqt62YETAoffrYg38X9QuaF3tqlbFzgaKUBOAUXg/qYH+xJ2un6j
Quh9qvZnrNM3c82cy1SHSoqWPBUMOYjsTgoyP6ttjLfvuJcd2/hNej2MZD4bt+cr
OcY1SdiieLebqy5CLPE8xL7W5II+91wQnfl0nvbWeWxtjiO2xyp6BfkJhWiJ3Ftn
iDGKaPAK+duJlMBQlzj1WSapW2wUNmQBhDK4VXwrGznoe3LlSz8+MB3V9M3wrBrj
uXq0hukjhEXQvKa0cSObA9+neYmZItb6w9oB9VDviAepBwHx5J5ew5qfonazANPn
Pmj0yHYr48H1wqqwCZ38gqiOkbv9g1LQvbpTUER/t8XJWMkQpdc=
=bxbK
-END PGP SIGNATURE-

Bug#904302: Call for vote on disallowing the use dpkg's vendor series in the archive

[Tollef Fog Heen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


I call for votes on the following resolution with regards to #904302.
The voting period lasts for one week or until the outcome is no longer
in doubt (§6.3.1).

 RESOLUTION 

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  Since Debian source packages are usually
treated as a pure transport format (like tar), this property can cause
confusion and frustration for users.  Examples could be if only the
series file for one vendor is updated, or a source package is unpacked
on one system and then transferred to a system with a different vendor
for debugging.

The Committee recognises that there is a need for packages to behave
differently when built on different distributions, but this should be
done by using differing source packages, or as part of the build
process using current and future practices such as patches with
conditional behaviour or patching of files during the build rather than
at source unpacking time.

Since this feature is used by several packages today, we need a
reasonable transition period.  They will be considered buggy from when
this resolution is accepted, but it will not be considered severe enough
to warrant immediate removal from Debian.  After Buster is released, the
presence of a vendor-specific patch series will be a violation of a MUST
directive in Debian policy.

The Committee therefore resolves that:

1. Any use of dpkg's vendor-specific patch series feature is a bug for
   packages in the Debian archive (including contrib and non-free).

   This should be implemented in Debian Policy by declaring that a
   package SHOULD NOT contain a non-default series file.

2. After Buster is released, use of the vendor-specific patch series
   feature is forbidden in the Debian archive.

   This should be implemented in Debian Policy by declaring that a
   package MUST NOT contain a non-default series file.

 END OF RESOLUTION 

A: Approve resolution, disallowing the use of dpkg's vendor series
F: Further Discussion

- -- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEooQRpZYZMXEzGALAtlpIccoZ1xcFAlvgj4UACgkQtlpIccoZ
1xcsxA//bVUE8oe/0wLDsp8FaMZCPL6SNCA9E8QAxKV+MyccsRqdX6Agvfmk9VvF
7gA9DoKTutWxXcrzAULoyDLFUxbvsvaKSQXS5S/Y4XOh3bl2or1TcYd7PLLWo8Ch
MAmnvvppXi9FHeH1ooMe8ta6rFrx0r0f6ts7u7Enh8YHynTsVllhZ5S0ZaUz8knD
0MQZDo4qe2DYT4ZjxVphl3z7JJ0ah+vYmXjNSRKBVn/XURIUtVAb036tn7fGlkSF
DpMJlS84L1ZxOOhkRijWTItSruCzwDgK3l/mjnM3dgYtVwMMwXFipDAxSxNhjv8B
Db3xN9t2lxUIzg5liBeUDI4WruKBtlAhDc0dhZCjBUgTNF23RYEeKWdax82xo7zR
CfpRDPx6+FOaGr/7vHtAAga/FRHdEXpCf7pYv3XsdgD9LvgBLhJ2UO8jKsaYFapB
tCh2QdTMl6fDRvrYQ4mRqqR2sGxfkA6bOAHaemrydg3dBufmZ4hHqxqW7zU5I2zu
qETvO7DY7JbhFlRmF4rHLjuiptSkJpqB8BaO1XcL4H2G1tqU+xJK6WvHMOkIwplk
KVwjkfe4NL6WYTGkcca6Waa3XmX8oBalDQ6SQVbeEe97CavcJENDF0Tk7xEI9KJ5
kJfdXX7TEFKlBTCHKdBbUDws2bhafDRweRtDXZBMG7TLEUEYV4o=
=yGbl
-END PGP SIGNATURE-

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

Last draft, incorporating the suggestions from Ian and Didier.

=== DRAFT Resolution ===

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  Since Debian source packages are usually
treated as a pure transport format (like tar), this property can cause
confusion and frustration for users.  Examples could be if only the
series file for one vendor is updated, or a source package is unpacked
on one system and then transferred to a system with a different vendor
for debugging.

The Committee recognises that there is a need for packages to behave
differently when built on different distributions, but this should be
done by using differing source packages, or as part of the build
process using current and future practices such as patches with
conditional behaviour or patching of files during the build rather than
at source unpacking time.

Since this feature is used by several packages today, we need a
reasonable transition period.  They will be considered buggy from when
this resolution is accepted, but it will not be considered severe enough
to warrant immediate removal from Debian.  After Buster is released, the
presence of a vendor-specific patch series will be a violation of a MUST
directive in Debian policy.

The Committee therefore resolves that:

1. Any use of dpkg's vendor-specific patch series feature is a bug for
   packages in the Debian archive (including contrib and non-free).

   This should be implemented in Debian Policy by declaring that a
   package SHOULD NOT contain a non-default series file.

2. After Buster is released, use of the vendor-specific patch series
   feature is forbidden in the Debian archive.

   This should be implemented in Debian Policy by declaring that a
   package MUST NOT contain a non-default series file.

=== End DRAFT Resolution ===

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Tollef Fog Heen 

> ]] Tollef Fog Heen 
>
> That turned out to be in the rather more distant future than I
> intended.  Apologies about that.

… and again.

Diff from previous one:

- Included separate source packages as an alternative to build time
  patching.
- Fixed typo.

I have not included the language about release criticalness of bugs,
due to OdyX' comment about that being the domain of the release team,
not policy.

I hope to call for a vote on this by the end of the week.

Second draft:

=== DRAFT Resolution ===

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  Since Debian source packages are usually
treated as a pure transport format (like tar), this property can cause
confusion and frustration for users.  Examples could be if only the
series file for one vendor is updated, or a source package is unpacked
on one system and then transferred to a system with a different vendor
for debugging.

The Committee recognises that there is a need for packages to behave
differently when built on different distributions, but this should be
done by using different source packages, or as part of the build
process, using current and future practices such as patches with
conditional behaviour, patching of files during the build, rather than
at source unpacking time.

Since this feature is used by several packages today, we need a
reasonable transition period.  They will be considered buggy from when
this resolution is accepted, but it will not be considered severe enough
to warrant immediate removal from Debian.  After Buster is released, the
presence of a vender-specific patch series will be a violation of a MUST
directive in Debian policy.

The Committee therefore resolves that:

1. Any use of dpkg's vendor-specific patch series feature is a bug for
   packages in the Debian archive (including contrib and non-free).

   This should be implemented in Debian Policy by declaring that a
   package SHOULD NOT contain a non-default series file.

2. After Buster is released, use of the vendor-specific patch series
   feature is forbidden in the Debian archive.

   This should be implemented in Debian Policy by declaring that a
   package MUST NOT contain a non-default series file.

=== End DRAFT Resolution ===

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904459: Uploading soon?

[Tollef Fog Heen]

]] Daniel Baumann 

> On 10/12/2018 09:56 AM, Tollef Fog Heen wrote:
> > any chance you could find time to get this uploaded soon? It'd be great
> > to have netdata back in testing (and in buster when it gets released).
> 
> yep, working on it.. will take a couple of days though. having netdata
> in buster is important to me too.

Thank you! :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904459: Uploading soon?

[Tollef Fog Heen]

Hi,

any chance you could find time to get this uploaded soon? It'd be great
to have netdata back in testing (and in buster when it gets released).

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Philip Hands 

> On reflection this seems like we're straying into micro-management.
> Should we really be determining the detail of how this is done in
> policy?

Given the entire decision has been delegated to us, I think we should,
yes.  If we'd just been asked to decide on a matter of technical policy,
that would have been slightly different.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#909435: git-annex: Fails in obscure way with version in stable

[Tollef Fog Heen]

Package: git-annex
Version: 6.20180913-1
Severity: important

I have an ssh remote where the other end is running Debian stable (so
6.20170101-1+deb9u2).  If I do a `git annex copy . --to foo`, it fails
with the rather obscure error:

copy directory/some.file (fd:18: hClose: resource vanished (Broken pipe)) failed

The problem goes away by upgrading the remote end to the version in
backports.

Can git-annex either be fixed so it works across those versions, or at
least give a clear error message that the two ends are speaking
incompatible protocol versions?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#909434: git-annex: inappropriate recommends: youtube-dl

[Tollef Fog Heen]

Package: git-annex
Version: 6.20180913-1
Severity: normal

youtube-dl pulls in a bunch of extra dependencies, and I doubt it
fulfills the

> The Recommends field should list packages that would be found together
> with this one in all but unusual installations.

definition from policy.  Can it be demoted to Suggests, please?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904558: What should happen when maintscripts fail to restart a service

[Tollef Fog Heen]

]] Ian Jackson 

> Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts 
> fail to restart  a service"):

[...]

> > This means that failure to start a daemon should generally not cause the
> > postinst to fail.
> 
> ... I disagree with that.  I think that in the usual case, if the
> daemon is broken, and the package's purpose is to provide that daemon
> service, then the package probably isn't providing its API.

I don't think dpkg relationships are a good fit for expressing those
kinds of statements.  They are not about in-memory and process state
management, they're about what's on disk.

[...]

> Also:
> 
> > The API provided by a package being in the configured state is not
> > whether the relevant daemon is running or not; that is runtime and can
> > and will change many times while the package is in the configured state,
> > so dpkg dependencies are not useful for expressing "this service must be
> > running".
> 
> I disagree with this.
> 
> dpkg dependencies are not just about what sets of packages can be
> coinstalled.  They also imply sequencing of package setup.  And since
> starting daemons is part of package setup, dpkg dependencies imply a
> sequencing of daemon startup.

If you include the word «attempted» there, I might agree.  policy-rc.d
for instance enters the picture here.  Blacklisting in the init system
does as well, probably others too.  The landscape is pretty crowded with
actors.

> That is actually necessary in the case where the startup of daemon B
> can only successfully completed if daemon A is up,

That's the job of the init system's dependency resolution mechanisms,
not dpkg's.  dpkg does not have information about what is running and so
can't do this.  Ordering is also separate from dependencies, at least
for some init systems.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904558: What should happen when maintscripts fail to restart a service

[Tollef Fog Heen]

]] Wouter Verhelst 

> On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:

[...]

> > The API provided by a package being in the configured state is not
> > whether the relevant daemon is running or not; that is runtime and can
> > and will change many times while the package is in the configured state,
> > so dpkg dependencies are not useful for expressing «this service must be
> > running».
> 
> No. But it *is* a useful way to express "this service must be able to
> run".

That's not what «configured» means, though.  «apt install foo ; rm
/etc/foo.conf» and the package will be in a «running, but can't restart»
state, but also configured in dpkg terms.

> Additionally, if something fails to restart, then that is a serious
> problem that I, as a system administrator, would like to know about.
> Failure to configure a package signals that there is a serious problem
> that I need to fix, so that informs me.

I think monitoring should be implemented using monitoring tools, so if
you actually care if a service is up, you should monitor it rather than
relying on postinsts failing or succeeding.

Alternatively, you could just add «systemctl is-system-running» to a
post-dpkg-invoke hook, it'll tell you if there are daemons that have
failed.

[...]

> There are really only two[1] reasons why a daemon could fail to restart:
> 
> - The maintainer made a mistake in the default configuration, and the
>   user didn't make any changes so the old conffiles are being replaced
>   by the new ones, or the package is being newly installed; now the
>   daemon encounters a syntax error. This is a bug, plain and simple, and
>   catching bugs earlier rather than later is a good idea, which will
>   happen if the daemon restart failure causes a postinst failure.
> - The maintainer made no mistake, but the upgrading user made some local
>   changes, so the conffile system ensures that the syntactic differences
>   in the configuration are not incorporated and the daemon fails to
>   restart. As a system administrator, I would want to know when
>   something like that happens sooner rather than later, so that I can
>   fix it (also sooner rather than later). Failing to finish postinst
>   correctly ensures that that does happen.

In addition to this: Any number of runtime problems.  The disk might be
full.  The service might try to look up a user whose name is in LDAP and
the network is down and thus the user lookup fails.  Some hardware the
service needs is not plugged in or doesn't work correctly.  Data files
are corrupted.  Out of memory.  I'm sure you can come up with more. :-)

This then also ties into what the semantics of «daemon is started»
should be: is it that the service has started, or that it is working?
What should happen if you, on a host with no network connectivity (or
just heavily firewalled), do «apt install ntp»?  Should it wait until
the clock is synced (effectively forever in this case?  Should the
postinst fail until you've fixed the firewall?)?

> [1] There is also the possibility of "the package ships with incomplete
> configuration on purpose, because there are no sane defaults to use
> and installing the package requires manual steps from the maintainer
> before it can be made to work", but (a) our best practices recommend
> against doing that if at all possible, and (b) in that case starting
> the daemon shouldn't even be attempted from postinst, and so failure
> to start can't be a consideration in the exit state of postinst.

You might still want to restart it on upgrade to ensure you don't run
outdated binaries.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904558: What should happen when maintscripts fail to restart a service

[Tollef Fog Heen]

]] Ian Jackson 

Hi,

> There may be good reasons not to treat daemon startup failure as a
> postinst failure, but the argument above is not one of them.

I think this is the core question.  I largely agree with Ian here that
having postinsts fail is not that big a deal if they can't make forward
progress, but also we're being asked to advice on what happens when a
maintainer script fails to restart a service.  I disagree with him on
whether failure to start/restart a service should be considered a
configuration failure.

The API provided by a package being in the configured state is not
whether the relevant daemon is running or not; that is runtime and can
and will change many times while the package is in the configured state,
so dpkg dependencies are not useful for expressing «this service must be
running».  (There's also the case where the service is running on a
separate host, which is often the case for services such as databases
and where the use of Depends is inappropriate.)

I think the general rule should be that the success/failure of the
postinst script should signal whether the package considers itself ready
to provide whatever API it exists to provide (disregarding the case of
Essential packages here, since those are special).

This means that failure to start a daemon should generally not cause the
postinst to fail.  At the same time, I think there are exceptions to
this rule that should be left to maintainer judgement: sshd comes to
mind as a service where if it can't restart, you want the system to make
it very clear that something is wrong that you might want to fix sooner
rather than later (since failure to do so can lead to you not being able
to access it after a reboot).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Philip Hands 

> Tollef Fog Heen  writes:
> 
> >This should be implemented in Debian Policy by declaring that a a
>^^^
> You've this doubled 'a' on two occasions in this text.

I'll fix that, thanks for spotting it.

> Presumaly we would not want to see new packages adopting the use of
> vendor-specific patch series prior to Buster.
> 
> Do we need to make the "SHOULD NOT" conditional on the package already
> having a vendor-specific patch series at the time of this resolution?

I think that just adds needless complexity and assumes that maintainers
will want to add bugs to their package.  I really hope that's not the
case, so I don't think it's worthwhile to add extra language for it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Tollef Fog Heen 

> ]] Sean Whitton 
> 
> > The concrete question that I am asking the committee to decide, in my
> > capacity as a Policy delegate, is whether or not vendor-specific patch
> > series should be permitted in the Debian archive.
> 
> It's now been five days since I mailed the various package
> maintainers. I intend to write up a resolution and then call for a vote
> in the not-too-distant future, so if there is anything we have not
> covered in the discussion so far, please chime in sooner rather than
> later

That turned out to be in the rather more distant future than I
intended.  Apologies about that.

A first draft is below, feedback on wording and content appreciated.

=== DRAFT Resolution ===

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  Since Debian source packages are usually
treated as a pure transport format (like tar), this property can cause
confusion and frustration for users.  Examples could be if only the
series file for one vendor is updated, or a source package is unpacked
on one system and then transferred to a system with a different vendor
for debugging.

The Committee recognises that there is a need for packages to behave
differently when built on different distributions, but this should be
done as part of the build process, using current and future practices
such as patches with conditional behaviour, patching of files during the
build, rather than at source unpacking time.

Since this feature is used by several packages today, we need a
reasonable transition period.  They will be considered buggy from when
this resolution is accepted, but it will not be considered severe enough
to warrant immediate removal from Debian.  After Buster is released, use
of a vender-specific patch series will be a violation of a MUST
directive in Debian policy.

The Committee therefore resolves that:

1. Any use of dpkg's vendor-specific patch series feature is a bug for
   packages in the Debian archive (including contrib and non-free).

   This should be implemented in Debian Policy by declaring that a a
   package SHOULD NOT contain a non-default series file.

2. After Buster is released, use of the vendor-specific patch series
   feature is forbidden in the Debian archive.

   This should be implemented in Debian Policy by declaring that a a
   package MUST NOT contain a non-default series file.

=== End DRAFT Resolution ===

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#908368: isync: Does not work with GSSAPI authentication

[Tollef Fog Heen]

]] Oswald Buddenhagen 

> ok, that seems convincing. i bumped it to 4KiB (just to be safe) on
> the 1.3 branch.

Much appreciated, thank you! :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#908368: isync: Does not work with GSSAPI authentication

[Tollef Fog Heen]

]] Oswald Buddenhagen 

Hi,

> please increase the buffer to whatever size works and then send me the
> output of an -l session with the -D option, so i can see where i made
> the wrong assumption.

Thanks for the quick response, I suspect the interesting bit of the log
is:

S: [ 3] Callback leave list_store
S: [ 3] Leave list_store
S: [ 2] Callback leave connect_store
S: [ 2] Leave connect_store
Connection is now encrypted
M: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
AUTH=GSSAPI AUTH=PLAIN] Dovecot ready.
Logging in...
Authenticating with SASL mechanism GSSAPI...
M: >>> 1 AUTHENTICATE GSSAPI YIIE[around 1700 characters elided]

I've bumped size of buf in send_imap_cmd and imap_vprintf to 2048 bytes;
no other changes seems to be needed.

(I'd rather not provide the complete log as it includes folder names,
host names and so on.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#908368: isync: Does not work with GSSAPI authentication

[Tollef Fog Heen]

Package: isync
Version: 1.3.0-1
Severity: important

When I run mbsync against my Kerberos-enabled Dovecot installation, it
fails with a «buffer too small» error:

$ mbsync mail
C: 0/1  B: 0/0  M: +0/0 *0/0 #0/0  S: +0/0 *0/0 #0/0Fatal: buffer too small. 
Please report a bug.
zsh: abort  mbsync mail

This is very reproducible for me, the components are dovecot with gssapi
enabled, samba4 as the Kerberos server and mbsync with
libsasl2-modules-gssapi-mit installed.  An easy workaround is to
increase the size of the IMAP command buffer, I can provide a patch for
that if you'd like.

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

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

Versions of packages isync depends on:
ii  libc6   2.27-5
ii  libdb5.35.3.28+dfsg1-0.1
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3.1
ii  libssl1.1   1.1.0h-4
ii  zlib1g  1:1.2.11.dfsg-1

isync recommends no packages.

Versions of packages isync suggests:
pn  mutt  

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#908162: grub-efi-amd64-signed: cryptdisk support missing

[Tollef Fog Heen]

Package: grub-efi-amd64-signed
Version: 1+2.02+dfsg1+6
Severity: critical
Justification: makes the system completely unbootable

When grub-efi-amd64-signed is installed and /boot is on an encrypted
file system and GRUB_ENABLE_CRYPTODISK=y is present in
/etc/default/grub, the system fails to boot, since cryptodisk appears to
be missing from the installed image.

Removing grub-efi-amd64-signed works around the problem, since it then
seems to use a locally built image?  I suspect just adding cryptodisk to
GRUB_MODULES in grub's debian/build-efi-images would be sufficient to
make this work correctly.

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

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

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Tollef Fog Heen]

]] Adrian Bunk 

> Hi,
> 
> looking at something where I worked on the upstream implementation ages ago:
> https://sources.debian.org/src/liferea/1.12.4-1/debian/patches/ubuntu-example-feeds.patch/
> 
> It is a common problem that users should be able to get started quickly 
> after installing a program.
> 
> When liferea is started by a user for the first time, the default feedlist
> in the locale of the user gets installed as feedlist for the user.
> 
> It is clear why a derivative, especially a brand-aware one like Ubuntu,
> wants to change this feedlist.
> 
> And it is also clear why this change cannot be applied in Debian.
> 
> One obvious solution if vendor-specific series files get outlawed in 
> Debian would be to switch from ubuntu.series to manual patching in
> debian/rules based on dpkg-vendor(1).

Or it would mean that Ubuntu would carry a XubuntuY version and do
manual (or automatic, based on whatever tooling they have available)
merges from Debian, marking it clearly as a different work.

[...]

> The whole underlying notion that there would be one source tree that 
> gets built is also flawed. This is not true in all cases, and can
> never be.

We are not talking about what's built. We're talking about what's
unpacked.  It's well understood that what's unpacked is not always
what's built; build processes can (and do) all kinds of transformations
and is understood to be executable code.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904558: What should happen when maintscripts fail to restart a service

[Tollef Fog Heen]

]] Sean Whitton 

> The general question about which I am seeking advice: does the
> T.C. think that Debian can be consistent on service (re)starts in
> maintscripts, or is the best we can do to leave it up to package
> maintainer discretion?

I think we can give advice on what the default should be and that people
should not stray from that unless they have particular reasons.  That
advice might be more appropriate for the developers reference than
policy, though.

Due to the variety and complexity of daemons in the archive, I would be
reluctant to require complete consistency, there are likely various edge
cases we have not thought about.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Sean Whitton 

> The concrete question that I am asking the committee to decide, in my
> capacity as a Policy delegate, is whether or not vendor-specific patch
> series should be permitted in the Debian archive.

It's now been five days since I mailed the various package
maintainers. I intend to write up a resolution and then call for a vote
in the not-too-distant future, so if there is anything we have not
covered in the discussion so far, please chime in sooner rather than
later

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Notification about TC discussion on possible deprecation of dpkg vendor specific patch series

[Tollef Fog Heen]

Hi,

The Debian Technical Committee has been asked to rule on whether to
disallow the use of dpkg's vendor-specific patch support in the Debian
archive.  As you either maintain or are interested in a package that
uses this support, you might want to be aware of this discussion and
possibly participate.  The bug number is 904302.

Best regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Gunnar Wolf 

> ...Although if we make a policy change in this, it will require
> cooperation of the dpkg developers if we don't want to go into 6.1.4
> (which we don't).

No, it won't, it's a policy change on what's allowed in the archive, not
what features dpkg is allowed to implement.

I imagine the language we'd want to use is along the lines of «Packages
must not use dpkg's vendor-specific patch series functionality».

> I am explicitly cc:ing Guillem here. Guillem, please take a look at
> this bug and give us your PoV!

Thanks!

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904882: fortunes-off: Rename to fortunes-offensive

[Tollef Fog Heen]

Package: fortunes-off
Severity: normal

Since fortunes-off predates the policy on offensive package names[1] and
the Diversity Statement, it has a name that's not in line with what
we chose as the suffix for offensive packages.

Could you rename fortunes-off to fortunes-offensive (and add a
transitional package to ensure people get smooth upgrades)?

[1] 
https://www.debian.org/doc/debian-policy/ch-binary.html#packages-with-potentially-offensive-content

Thanks,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Stuart Prescott 

> Essentially, this is a request that the TC overrule both Debian
> maintainers *and* derivative maintainers in what they have agreed as a
> workflow that obviously works for them. Today, Debian decides to not
> allow debian/patches/vendor.series, then tomorrow, a derivative
> patches dpkg-source and Debian is asked to decide whether
> debian/patches/vendor-dammit-i-want-these-patches-applied.series is
> allowed in the source package.

I can see where you are coming from, but I disagree with your
conclusions.

Hypothetically, if a downstream distribution implemented support
vendor.series without there being any support in Debian for it, I don't
think we would disallow vendor.series in Debian.  (I think it would be a
bad idea for a downstream to patch such functionality into dpkg, but
there are many bad ideas that should not be forbidden.)

> (Footnote: Sean has referred this under §6.1.3, requesting a decision but 
> since this is overriding a (set of) maintainer(s) that includes those using 
> vendor.series and the dpkg maintainers, I assume §6.1.4 applies.)

I believe his request might also be considered under §6.1.1, since we're
being asked about a policy change.  (After talking to Sean in person, he
said he intended it under §6.1.3, not §6.1.1, though.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Sean Whitton 

> The concrete question that I am asking the committee to decide, in my
> capacity as a Policy delegate, is whether or not vendor-specific patch
> series should be permitted in the Debian archive.
> 
> There is a broader question of whether source packages should be allowed
> to unpack differently on different systems through other means, such as
> patch systems implemented in debian/rules (this could be done using
> dpkg-vendor(1)).  But given that 3.0 (quilt) is now dominant, you might
> leave this broader question aside.

I agree with Ian, Steve, and Colin that it is rather surprising for
source packages to unpack differently on a different OS.  Source
packages are (at least to most people) a transport format; not entirely
unlike tar, and those do in general not have the property that the
unpacking OS matters.  My understanding is also that vendor series are
mostly used by Ubuntu and the experience that Colin and Steve have is
that they are mostly used for the wrong reasons, and cause at least as
many problems as they solve.

I think we should disallow vendor-specific patch series in Debian, and
ask the dpkg developers to kindly deprecate the functionality given the
mentioned concerns.

As for the wider question about patch systems operating through
debian/rules, I'm a lot more comfortable allowing that since you then
run code to get to the patches-applied source code.  (I think it's a bad
idea with patches-unapplied packages, but there are use cases for it,
and not all bad ideas should be outlawed.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#901923: buildd.debian.org: Wrong links to git repositories on front page

[Tollef Fog Heen]

Package: buildd.debian.org
Severity: normal

At the bottom of https://buildd.debian.org/, there are links marked with
gitweb that points to Alioth.  Those should be updated to where the
source actually lives.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#901238: Acknowledgement (wnorwegian: Both word list files should be in UTF-8, not in ISO-8859 anymore)

[Tollef Fog Heen]

]] Pander 

> But these symbolic links are dubious:
> 
> /usr/share/dict/norsk -> /etc/dictionaries-common/norsk
> /etc/dictionaries-common/norsk -> /usr/share/dict/bokmaal

I'm not sure what you think is dubious about this.

> And the following symbolic link should be used instead:
> 
> /usr/share/dict/norsk -> /usr/share/dict/nynorsk

That's configuration that's up to the admin which of the two different
forms of Norwegian should be used as the Norwegian dictionary on the
system.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#760022: libpam-tmpdir fails to work properly with systemd and suspend

[Tollef Fog Heen]

Hi,

First of all, apologies for never following up on this.

]] John Gruenenfelder 

[...]

> Given the complexity of systemd, I'm not sure where the conflict arises.
> Considering how frequently systemd seems to create and tear down sessions,
> that seems a likely area for problems.  I think the only PAM module that
> touches tmp-anything is libpam-tmpdir, so my best guess is that at some point,
> pre-suspend, systemd removes the user session triggering libpam-tmpdir to
> remove the user tmpdir and anything in it.  When the system resumes, systemd
> creates a new session and libpam-tmpdir creates a new per-user tmpdir, but it
> is, of course, now empty.

libpam-tmpdir never cleans up the temporary directory, though, so I'm
not sure how this would happen.  If anything it sounds like a systemd
bug.  Are you still experiencing this, or did it get resolved in the
meantime?

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#899223: sparkleshare: fails to start without any error message

[Tollef Fog Heen]

Package: sparkleshare
Version: 2.0.1-1
Severity: grave

After the recent update, sparkleshare fails to start without any kind of
useful error message on multiple machines.

First, it hits a mono bug that's triggered by the new libncurses, which
can either be worked around with «TERM=xterm sparkleshare start» or
patched by
https://github.com/mono/mono/commit/2c1f45f3791f274855e0f5fd2fb0af71c9a756f7
(thanks to Jo Shields for that link).

It then runs like:
$ TERM=dumb sparkleshare start
06.47.09 Environment | SparkleShare 2.0.1
06.47.09 Environment | Git LFS 
06.47.09 Environment | Git 2.17.0
06.47.09 Environment | GNOME (Unix 4.16.0.1)
06.47.09 Cmd |  | gvfs-set-attribute "/home/tfheen/SparkleShare" 
metadata::custom-icon-name org.sparkleshare.SparkleShare

and then just exits.  strace does not really shed any light on what's
going on.

I'm happy to help out with debugging this issue if you can't reproduce
it.

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

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

Versions of packages sparkleshare depends on:
ii  git 1:2.17.0-1
ii  gnome-icon-theme3.12.0-3
ii  gvfs1.36.1-1
ii  libappindicator3-0.1-cil12.10.0+git20151221-5
ii  libgdk3.0-cil   2.99.3-2+b1
ii  libgio3.0-cil   2.99.3-2+b1
ii  libglib3.0-cil  2.99.3-2+b1
ii  libgtk3.0-cil   2.99.3-2+b1
ii  libjs-jquery3.2.1-1
ii  libmono-corlib4.5-cil   4.6.2.7+dfsg-1
ii  libmono-posix4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system4.0-cil   4.6.2.7+dfsg-1
ii  libnotify3.0-cil3.0.3-3
ii  libpango3.0-cil 2.99.3-2+b1
ii  libwebkit2-sharp-4.0-cil2.10.9+git20160917-1.1
ii  mono-runtime4.6.2.7+dfsg-1

Versions of packages sparkleshare recommends:
ii  python   2.7.15~rc1-1
ii  python-nautilus  1.1-6

sparkleshare suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#899222: mono-runtime: breaks with new ncurses terminfo files

[Tollef Fog Heen]

Package: mono-runtime
Version: 4.6.2.7+dfsg-1
Severity: important

ncurses 6 introduced a new file format, which causes mono to become
pretty unhappy when trying to parse those files.  A current example is
sparkleshare:

$ mono /usr/lib/x86_64-linux-gnu/sparkleshare/SparkleShare.exe
exception inside UnhandledException handler: The type initializer for 
'System.Console' threw an exception.

[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type 
initializer for 'System.Console' threw an exception. ---> 
System.TypeInitializationException: The type initializer for 
'System.ConsoleDriver' threw an exception. ---> System.Exception: Magic number 
is wrong: 542
  at System.TermInfoReader.ReadHeader (System.Byte[] buffer, System.Int32& 
position) [0x0002b] in <8f2c484307284b51944a1a13a14c0266>:0 
  at System.TermInfoReader..ctor (System.String term, System.String filename) 
[0x00065] in <8f2c484307284b51944a1a13a14c0266>:0 
  at System.TermInfoDriver..ctor (System.String term) [0x00058] in 
<8f2c484307284b51944a1a13a14c0266>:0 
  at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x0] 
in <8f2c484307284b51944a1a13a14c0266>:0 
  at System.ConsoleDriver..cctor () [0x00062] in 
<8f2c484307284b51944a1a13a14c0266>:0 
   --- End of inner exception stack trace ---
  at System.Console.SetupStreams (System.Text.Encoding inputEncoding, 
System.Text.Encoding outputEncoding) [0xa] in 
<8f2c484307284b51944a1a13a14c0266>:0 
  at System.Console..cctor () [0x000a8] in <8f2c484307284b51944a1a13a14c0266>:0 
   --- End of inner exception stack trace ---
  at Sparkles.Logger.LogInfo (System.String type, System.String message, 
System.Exception exception) [0x0009d] in <1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Logger.LogInfo (System.String type, System.String message) 
[0x1] in <1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Command.Start () [0x00097] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Command.StartAndReadStandardOutput () [0x1] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at (wrapper remoting-invoke-with-check) 
Sparkles.Command:StartAndReadStandardOutput ()
  at Sparkles.InstallationInfo.get_OperatingSystem () [0x00049] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at Sparkles.Logger.WriteCrashReport (System.Exception e) [0x8] in 
<1cfdbdb30dbc4aa3a274a50c6e3e3879>:0 
  at SparkleShare.SparkleShare.OnUnhandledException (System.Object sender, 
System.UnhandledExceptionEventArgs exception_args) [0xd] in 
<6d9908bd36a64477b98c6146bd1b2e76>:0 

https://github.com/mono/mono/commit/2c1f45f3791f274855e0f5fd2fb0af71c9a756f7
is an upstream commit that I've been told fixes this.

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

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

Versions of packages mono-runtime depends on:
ii  libc6  2.27-3
ii  mono-runtime-sgen  4.6.2.7+dfsg-1

mono-runtime recommends no packages.

mono-runtime suggests no packages.

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#894850: cinnamon: Network applet can't activate new networks

[Tollef Fog Heen]

]] Fabio Fantoni 

> Thanks for you report, this is caused by my mistake in latest network
> patch fix, sorry.
> To solves it in /usr/share/cinnamon/applets/netw...@cinnamon.org/applet.js
> change:
> let perms = client.get_permission_result
> (NM.Client.Permission.SETTINGS_MODIFY_SYSTEM);
> with:
> let perms = client.get_permission_result
> (NM.ClientPermission.SETTINGS_MODIFY_SYSTEM);

Thanks, this solves it, and I can connect to passworded wifi just fine
after that change.

(If you'd like me to NMU with this, I'd be happy to.  Please let me
know.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#894850: cinnamon: Network applet can't activate new networks

[Tollef Fog Heen]

2:1.6.5-1
ii  libxfixes3   1:5.0.3-1
ii  libxml2  2.9.4+dfsg1-6.1
ii  mesa-utils   8.4.0-1
ii  muffin   3.6.0-1
ii  nemo 3.6.5-1
ii  network-manager-gnome1.8.10-2
ii  policykit-1-gnome0.105-6
ii  python   2.7.14-4
ii  python-dbus  1.2.6-1
ii  python-gi-cairo  3.28.1-1
ii  python-lxml  4.2.0-1
ii  python-pam   0.4.2-13.2
ii  python-pexpect   4.2.1-1
ii  python-pil   4.3.0-2
ii  python-pyinotify 0.9.6-1
ii  python3  3.6.4-1
ii  python3-dbus 1.2.6-1
ii  python3-gi   3.28.1-1
ii  xapps-common 1.0.4-2

Versions of packages cinnamon recommends:
ii  blueman   2.0.5-1+b1
ii  cinnamon-l10n 3.6.4-1
ii  gir1.2-gnomebluetooth-1.0 3.28.0-2
ii  gksu  2.0.2-9+b1
ii  gnome-terminal [x-terminal-emulator]  3.28.0-1
ii  metacity-common   1:3.28.0-1

Versions of packages cinnamon suggests:
pn  cinnamon-doc   
pn  python-opencv  

-- no debconf information

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#894551: ITP: fascism -- Exhaustive exploration of Fascist theory and practice

[Tollef Fog Heen]

]] Enrico Zini 

> >  - do you use it?
> 
> I do all I can to avoid it.

Does it come with unit tests?  They might be useful to figure out what
it would take to break it properly this time around.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#893200: TC Chair election

[Tollef Fog Heen]

]] Didier 'OdyX' Raboud 

> ===BEGIN===
> 
> The chair of the Debian Technical Committee will be:
> 
> A : Didier Raboud 
> B : Tollef Fog Heen 
> C : Phil Hands 
> D : Margarita Manterola 
> E : David Bremner 
> F : Niko Tyni 
> G : Gunnar Wolf 
> H : Simon McVittie 
> ===END===

I vote:

C = D = E > A = B = F = G > H

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#864184: Raising severity

[Tollef Fog Heen]

severity 864184 serious
thanks

This basically makes noping completely useless, so I'm raising this to
RC.

I'm happy to upload an NMU if you're busy.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#804784: This would also fix #864184

[Tollef Fog Heen]

Switching to non-root with setcap seems to have made this work as
non-root for me, so I think this should just be done.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#890540: ITP: libtest-postgresql-perl -- sets up and destroys temporary PostgreSQL instances for testing

[Tollef Fog Heen]

]] Don Armstrong 

> Test::PostgreSQL automatically setups a PostgreSQL instance in a temporary
> directory, and destroys it when the perl script exits.

Are you already aware of pg_virtualenv?  It sounds like those are
overlapping a bit.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering

[Tollef Fog Heen]

]] Didier 'OdyX' Raboud 

> === Resolution ===
> 
> In 2014, it was resolved in #746578 that the libpam-systemd binary package 
> alternative dependency on systemd-shim and systemd-sysv shall be set in that 
> order, in order to avoid unwanted init system changes accross upgrades. 
> Debian 
> Stretch has since been released.
> 
> The Committee therefore resolves that:
> 
> 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.
> 
> This means Debian's normal policies and practices take over and the
> libpam-systemd package's dependencies are set free from specific ordering 
> constraints.  The migration should be managed according to Debian's usual 
> backwards-compatibility arrangements.
> 
> === End Resolution ===
> 
> R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
> F: Further Discussion

I vote R > F.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#886526: ITP: rt4-extension-commandbymail -- Change metadata of ticket via email (Request Tracker)

[Tollef Fog Heen]

]] Andrew Ruthven 

> The intial packaging work has been carried but by myself for my employer.
> Ongoing maintenance will be by the Debian Request Tracker Group (of which
> I'm a member).

This is already packaged as librt-extension-commandbymail-perl, but feel
free to have the team take it over.  (I'm the maintainer.)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#884173: Solved-for-me

[Tollef Fog Heen]

Good catch Toote,

it went away when I manually removed the Signal extension it all works a
lot better (just mv-ed out of ~/.config/chromium/Default/Extensions).
If you use it, does it help for you as well?  Should extensions be able
to crash the browser? (Not sure if they can include native code.)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#877966: This is happening again

[Tollef Fog Heen]

]] Julien Cristau 

> On 12/12/2017 03:39 PM, Tollef Fog Heen wrote:
> > DSA, thoughts on this?  Sounds reasonable?
> > 
> I think the issue is also made worse by mirror-bytemark being
> consistently much slower than the other backends, and how ftpsync
> behaves in a pathological way when mirrors have very different speeds.

Agreed, we should fix this on both the mirror-health side and how we
push.

> When doing a staged push, we start stage1 for all downstreams.  Each of
> those, when it's done, waits for up to $PUSHDELAY, by default 10
> minutes, for its siblings to signal they're also done with stage1.  If
> all goes well, everyone waits for everyone else to be done with stage1,
> then within 5 seconds of each other they run stage2.

Why do we do this?  To avoid having inconsistent mirrors?  Can we solve
this by having names that incorporate _health instead and just have
mirrors take whatever time they need?  This will cause some traffic to
slosh around as mirrors go healthy and unhealthy, but hopefully not more
than what we can handle?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#884173: Backtrace

[Tollef Fog Heen]

This happens for me too:

$ /usr/bin/chromium -g
# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/tfheen/bin:/usr/local/bin:/home/tfheen/.local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin
#GTK_PATH=
#  CHROMIUM_FLAGS=--enable-remote-extensions 
--show-component-extension-options --ignore-gpu-blacklist 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.be3nwP
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...Reading symbols from 
/usr/lib/debug/.build-id/ca/13b14d742fddeb5910cd30a74e53d1af48ad1b.debug...(no 
debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/lib/chromium/chromium --enable-remote-extensions 
--show-component-extension-options --ignore-gpu-blacklist 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdd739700 (LWP 14296)]
[New Thread 0x7fffdcf38700 (LWP 14301)]
[New Thread 0x7fffdb558700 (LWP 14302)]
[New Thread 0x7fffdad57700 (LWP 14303)]
[New Thread 0x7fffd9d55700 (LWP 14304)]
[New Thread 0x7fffda556700 (LWP 14305)]
[New Thread 0x7fffd9d4d700 (LWP 14306)]
[New Thread 0x7fffd954c700 (LWP 14307)]
[New Thread 0x7fffd7107700 (LWP 14308)]
[New Thread 0x7fffd6906700 (LWP 14309)]
[New Thread 0x7fffd6105700 (LWP 14310)]
[New Thread 0x7fffd5904700 (LWP 14311)]
[New Thread 0x7fffd5103700 (LWP 14312)]
[New Thread 0x7fffd4902700 (LWP 14313)]
[New Thread 0x7fffd4101700 (LWP 14314)]
[New Thread 0x7fffd3900700 (LWP 14315)]
[New Thread 0x7fffd30ff700 (LWP 14316)]
[New Thread 0x7fffd28fe700 (LWP 14317)]
[New Thread 0x7fffd20fd700 (LWP 14318)]
[New Thread 0x7fffd18fc700 (LWP 14319)]
[New Thread 0x7fffd10fb700 (LWP 14320)]
[New Thread 0x7fffd08fa700 (LWP 14321)]
[New Thread 0x7fffd00f9700 (LWP 14322)]
[New Thread 0x7fffcf8f8700 (LWP 14323)]
[New Thread 0x7fffcf0f7700 (LWP 14324)]
[New Thread 0x7fffce8f6700 (LWP 14325)]
[New Thread 0x7fffce0f5700 (LWP 14326)]
[New Thread 0x7fffcd8f4700 (LWP 14327)]
[New Thread 0x7fffcce6d700 (LWP 14328)]
[New Thread 0x7fffbbe42700 (LWP 14355)]
[14252:14324:1213/195506.734934:ERROR:io_thread.cc(743)] Cannot use V8 Proxy 
resolver in single process mode.
[New Thread 0x7fffbb641700 (LWP 14356)]
[New Thread 0x7fffb9e3e700 (LWP 14358)]
[New Thread 0x7fffba63f700 (LWP 14359)]
[New Thread 0x7fffbae40700 (LWP 14357)]
[14252:14324:1213/195506.827087:ERROR:io_thread.cc(743)] Cannot use V8 Proxy 
resolver in single process mode.
[New Thread 0x7fffb5a67700 (LWP 14362)]
[New Thread 0x7fffb5266700 (LWP 14363)]
[New Thread 0x7fffb4a65700 (LWP 14365)]
[New Thread 0x7fffb4264700 (LWP 14366)]
[New Thread 0x7fffb3a63700 (LWP 14367)]
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[New Thread 0x7fffb28db700 (LWP 14368)]
[Thread 0x7fffb28db700 (LWP 14368) exited]
[New Thread 0x7fffb193d700 (LWP 14370)]
[New Thread 0x7fffb113c700 (LWP 14371)]
[New Thread 0x7fffb093b700 (LWP 14372)]
[New Thread 0x7fffb013a700 (LWP 14373)]
[14252:14355:1213/195506.960725:ERROR:connection.cc(1964)] Web sqlite error 1, 
errno 0: no such column: instant_url, sql: SELECT id, short_name, keyword, 
favicon_url, url, safe_for_autoreplace, originating_url, date_created, 
usage_count, input_encodings, suggest_url, prepopulate_id, created_by_policy, 
instant_url, last_modified, sync_guid, alternate_urls, 
search_terms_replacement_key, image_url, search_url_post_params, 
suggest_url_post_params, instant_url_post_params, image_url_post_params, 
new_tab_url, last_visited FROM keywords ORDER BY id ASC
[New Thread 0x7fffaf939700 (LWP 14374)]
[New Thread 0x7fffaf057700 (LWP 14375)]
[New Thread 0x7fffae856700 (LWP 14376)]
[New Thread 0x7fffade43700 (LWP 14377)]
[New Thread 0x7fffad43f700 (LWP 14387)]
[New Thread 0x7fffabdd7700 (LWP 14404)]
[Thread 0x7fffabdd7700 (LWP 14404) exited]
[New Thread 0x7fffabdd7700 (LWP 14405)]
[New Thread 0x7fffaaf4a700 (LWP 14406)]
[New Thread 0x7fffa9fc5700 (LWP 14407)]
[New Thread 0x7fffa79ec700 (LWP 14408)]
[New Thread 0x7fffa716b700 (LWP 14409)]

Thre

Bug#877966: This is happening again

[Tollef Fog Heen]

]] Santiago Vila 

> While building a lot of packages today, I found that this is happening again:
> 
> 503  Quorum weight not reached [IP: 151.101.112.204 80]

Hi,

yeah, we saw an outage on the 9th, need to investigate why it hit us.  I
suspect it was due to (all dates the the 9th, all times are UTC):

21:08:21 mirror push on mirror-conova is done
21:08:22 mirror-skroutz declares itself unhealthy due to being out of date
21:08:58 mirror-accumu declares itself unhealthy due to being out of date
21:09:10 mirror-bytemark declares itself unhealthy due to being out of date
21:09:56 mirror-conova declares itself unhealthy due to scheduled shutdown
21:16:44 mirror push on mirror-skroutz is done
21:17:22 mirror-skroutz declares itself healthy
21:17:37 mirror push on mirror-accumu is done
21:17:58 mirror-accumu declares itself healthy
21:19:32 mirror-skroutz hits a bug in mirror-health and declares itself
 unhealthy due to connect timeouts to mirror-conova
21:20:07 mirror-accumu hits a bug in mirror-health and declares itself
 unhealthy due to connect timeouts to mirror-conova
21:26:10 mirror-accumu comes back and is healthy
21:26:11 mirror-skroutz comes back and is healthy
21:26:53 mirror-conova comes back and is healthy

Dec 10:
03:45:34 mirror-bytemark push is done
03:45:47 mirror-bytemark comes back and is healthy

So what happened was essentially that we did a reboot *just* after a
push had finished, leading to a mirror declaring itself unhealthy.

I've fixed the bug that caused the second outage from ~2120 until ~2126
now, so we should not run into that one again at least.

I wonder if the right fix is to ignore timestamps from any unhealthy
hosts, and to reset latest_ts on each iteration through check_uptodate.
If we initialise latest_ts to 0, that will mean we do consider ourselves
healthy in the case of nobody else being healthy.  If somebody else is
newer than us and healthy, we consider ourselves unhealthy.

DSA, thoughts on this?  Sounds reasonable?

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#877024: Modemmanager probing of unknown Devices

[Tollef Fog Heen]

]] Ian Jackson 

> Sam Hartman writes ("Bug#877024: Modemmanager probing of unknown Devices"):
> > Hi.  In #877024, the TC was asked to rule on whether modemmanager should
> > continue to probe USB devices that might not be modems.
> > 
> > There's been significant involvement from upstream leading to a new
> > optional behavior that is less aggressive about probing unknown devices.
> > 
> > Would it help the maintainer for the TC to rule on this issue?
> > 
> > Do you have any input into the TC process you would like to give?
> 
> Thanks for asking these questions, Sam.
> 
> FAOD, currently, it seems that the Debian maintainers don't have time
> to address this issue in Debian.  That is fine of course.  No-one is
> obliged to do work, even if their name is in the Maintainer or
> Uploaders field.

Given there's no indication they were made aware of your bug filing that
I could find, I don't think that's a conclusion we can make.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Tollef Fog Heen]

]] Didier 'OdyX' Raboud 

> There are _plenty_ of changes that one needs to care about in a stable 
> upgrade: things like mandatory postfixing of Apache configuration files, 
> removal 
> of specific Python3 versions, removal of upstart, etc. Having to change a 
> shebang isn't a big deal given the amount of things one has to check accross 
> a 
> stable release upgrade.

You might quite reasonably write scripts in node and either store them
in a shared directory across multiple Debian versions or have ~/bin in
version control shared across multiple Debian installations (and
corresponding versions).

#! lines are a bit special in this regard.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#860568: iptraf-ng: cron spam due to duplicated logrotate rules

[Tollef Fog Heen]

]] Charles Plessy 

> Le Tue, Apr 18, 2017 at 08:31:58PM +0200, Tollef Fog Heen a écrit :
> > Package: iptraf-ng
> > Version: 1:1.1.4-6
> > Severity: normal
> > 
> > As of a few days ago, I started getting mails from logrotate complaining
> > about duplicate log rotation rules for iptraf and iptraf-ng:
> > 
> >   /etc/cron.daily/logrotate:
> >   error: iptraf-ng:2 duplicate log entry for /var/log/iptraf/rvnamed.log
> 
> Hi all,
> 
> isn't it because the transitional package iptraf contains
> /etc/logrotate.d/iptraf, and shouldn't this file be removed from the
> package ?

It should probably be cleaned up in the transitional package, no matter
whether it still ships there or not.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Tollef Fog Heen]

]] Tollef Fog Heen 

> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

with 7 votes for R and none for F, the result is no longer in doubt and
the CTTE decision from 2012-07-12 in bug #614907 is repealed.

I'll mail d-d-a about this now.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Tollef Fog Heen]

]] Tollef Fog Heen 

> I call for votes on the following resolution with regards to #862051.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
> 
> === Resolution ===
> 
> The Technical Committee recognises that circumstances change in ways
> that make previous resolutions no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in stable, testing
> or unstable so the requirement for nodejs to not provide /usr/bin/node
> no longer applies.
> 
> The Committee therefore resolves that:
> 
> 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
> 
> This means Debian's normal policies and practices take over and the
> nodejs package is free to provide /usr/bin/node.  The migration should
> be managed according to Debian's usual backwards-compatibility
> arrangements.
> 
> === End Resolution ===
> 
> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote R > F.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are