Bug#889002: Simple reboot reminder

[martin f krafft]

Package: linux-base
Version: 4.5
Severity: wishlist

We use the following line from cron to remind us to reboot
a machine, if the initrd for the currently running kernel has been
updated:

  test /proc -nt /boot/initrd.img-$(uname -r) || echo reboot required

Would you be open to the idea to provide such functionality from
linux-base?

I'd be happy to extend it to make it work for systems without
initrd, as well as in the case of kernel version upgrades
(configurable), but I'd want to gauge first if this is the right
place for such a script.

If you don't think linux-base is the place for this, please
reassign.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#889002: Simple reboot reminder

[martin f krafft]

Package: linux-base
Version: 4.5
Severity: wishlist

We use the following line from cron to remind us to reboot
a machine, if the initrd for the currently running kernel has been
updated:

  test /proc -nt /boot/initrd.img-$(uname -r) || echo reboot required

Would you be open to the idea to provide such functionality from
linux-base?

I'd be happy to extend it to make it work for systems without
initrd, as well as in the case of kernel version upgrades
(configurable), but I'd want to gauge first if this is the right
place for such a script.

If you don't think linux-base is the place for this, please
reassign.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#887384: Ability to provide password per-instance

[martin f krafft]

Package: wget
Version: 1.19.2-2
Severity: wishlist
Tags: upstream

As far as I can tell, Wget only provides the following methods to
provide a HTTP password:

  1. as part of the URL
  2. with --http-password / --password
  3. using ~/.netrc
  4. using --use-askpass
  5. using --ask-password

The problem is that 1 & 2 expose the password in the process table,
while ~/.netrc is a centralised resource that may not be editable by
a script. 4 & 5 are interactive, and while I could provide an ad-hoc
askpass script, this is a gross hack.

It'd be awesome if Wget could provide one or more of the following
methods to provide the password:

  1. read it from $WGET_PASSWORD
  2. read it from a specific file
  3. read it from a netrc-style file that is not ~/.netrc
  4. let --use-askpass specify parameters to the script/binary to invoke

Ftr, my current hack involves creating an executable temporary file
with content like this:

  #!/bin/sh
  echo username:password

and then invoking wget like so:

  wget -c --use-askpass=tempfile …

and that works, but it's a hack that I think could be rendered
obsolete by Wget functionality. Lftp and cURL both provide ways to
either read from the environment, or to override the netrc filename.
Lftp furthermore can be scripted itself, which solves the problem
in its own way.

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

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

Versions of packages wget depends on:
ii  libc62.26-3
ii  libgnutls30  3.5.16-1
ii  libidn2-02.0.4-1.1
ii  libnettle6   3.4-1
ii  libpcre3 2:8.39-8
ii  libpsl5  0.19.1-4
ii  libuuid1 2.30.2-0.1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages wget recommends:
ii  ca-certificates  20170717

wget suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#887166: When invoked on local file, returns control to caller before file is read

[martin f krafft]

Package: firefox
Version: 57.0.4-1
Severity: normal

Most of the time when asking mutt to open an attachment in a new tab
in a running Firefox instance (using view-mailcap), the browser
reports an error:

  Firefox can’t find the file at /home/madduck/.tmp/mutt.html

It works some times, but that's the exception.

The reason seems to be that /usr/bin/firefox exits before the
running browser had a chance to read the file. When execution is
returned to the caller (mutt in this case), mutt then cleans up the
temporary file. By the time, the running Firefox instance wants to
read the file, it's gone. It's a classic race condition where mutt
seems to win most of the time.

It seems that the new /usr/bin/firefox process notifies the running
instance, but then doesn't receive or wait for confirmation that the
request has been processed (i.e. the file has been read).

I've searched the Web and Bugzilla, but could not find a report or
solution for this. I seem to recall this has happened before, but it
hasn't been a problem for many years.

I'm reporting to Debian rather than Bugzilla because it's possible
that Debian's packaging is responsible for this. If not, please
upstream the report, or tell me to.

Thanks,

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

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

Versions of packages firefox depends on:
ii  debianutils   4.8.4
ii  fontconfig2.12.6-0.1
ii  libatk1.0-0   2.26.1-2
ii  libc6 2.26-3
ii  libcairo-gobject2 1.15.8-3
ii  libcairo2 1.15.8-3
ii  libdbus-1-3   1.12.2-1
ii  libdbus-glib-1-2  0.108-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.12.6-0.1
ii  libfreetype6  2.8.1-1
ii  libgcc1   1:7.2.0-19
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libglib2.0-0  2.54.3-1
ii  libgtk-3-03.22.26-2
ii  libgtk2.0-0   2.24.31-5
ii  libhunspell-1.6-0 1.6.2-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.16-1+b1
ii  libnss3   2:3.34.1-1
ii  libpango-1.0-01.40.14-1
ii  libsqlite3-0  3.21.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++67.2.0-19
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3
ii  zlib1g1:1.2.8.dfsg-5

firefox recommends no packages.

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-6
ii  libgssapi-krb5-2   1.15.2-2
pn  mozplugger 

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#535128: unify v4 ip route output

[martin f krafft]

also sprach Luca Boccassi <bl...@debian.org> [2017-12-29 22:04 +0100]:
> Feel free to ask for this upstream at net...@vger.kernel.org but
> I strongly suspect such a change would be considered backward
> incompatible, since it would probably break all the nasty screen-
> scraping systems out there, so it's not likely to happen.

Oh joy. Any tool should always check for a tty on stdout and if none
is found, it should randomly reformat the output unless
--machine-readable is given. You know, easier said than done… ;)

Thanks for following up, I guess I'll rest my case.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"this week dragged past me so slowly;
 the days fell on their knees..."
-- david bowie


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#882990: Arbitrary meta-data date chosen

[martin f krafft]

also sprach Jeff <jf...@posteo.net> [2017-11-28 22:15 +0100]:
> > Today, it suggested 2017-12-07. Something really just isn't working
> > right. Please either leave the field empty, or fill it in with
> > TODAY().
> 
> I've just tested this, and for me it is still working as advertised -
> ~/.config/gscan2pdfrc has a "date offset" field, which is used to
> calculate the date.
> 
> Can you check this?

I did. If I remove the date offset (== 0), then today's date is
used as default.

If I change the date to e.g. 10 days ago and save a file, then "date
offset" becomes -10. If I now wait 2 days before using gscan2pdf
again to save a file, it'll apply -10 and default to the date 8 days
ago today.

I'm failing to see the logic behind all of this.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
no. no musicals. i loathe musicals. i never did have a plan for
doing one. my cousin made me sit through some fucking musical twice.
i just hate them. they bore me stiff. i think they’re just horrible.
even _hair_. and they're always lousy music.
   -— john lennon, _the lost interviews_ by ray connolly


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#882992: Clear out meta-data fields between saves

[martin f krafft]

Package: gscan2pdf
Version: 1.8.10-1
Severity: minor

It seems as if fields like the document metadata title are being
kept between saves. I don't think that makes any sense and I think
instead the metadata form should be cleared each time the save
dialog is opened, with possible exception of defaulting to today's
date (#882990), which ought to then be selected such that it can be
changed without effort, or just accepted by hitting enter.

Thank you!

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.4+dfsg-16
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1
ii  libfilesys-df-perl 0.92-6+b3
ii  libgoo-canvas-perl 0.06-2+b4
ii  libgtk2-ex-simple-list-perl0.50-2
ii  libgtk2-imageview-perl 0.05-2+b4
ii  libhtml-parser-perl3.72-3+b2
ii  libimage-magick-perl   8:6.9.7.4+dfsg-16
ii  libimage-sane-perl 0.14-1+b1
ii  liblist-moreutils-perl 0.416-1+b3
ii  liblocale-gettext-perl 1.07-3+b3
ii  liblog-log4perl-perl   1.49-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b6
ii  libpdf-api2-perl   2.033-1
ii  libproc-processtable-perl  0.53-2+b2
ii  libreadonly-perl   2.050-1
ii  librsvg2-common2.40.18-2
ii  libset-intspan-perl1.19-1
ii  libtiff-tools  4.0.8-6
ii  libtry-tiny-perl   0.28-1
ii  sane-utils 1.0.26~git20151121-1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin  3.5.27.1-8
ii  gocr   0.49-2+b1
pn  libgtk2-ex-podviewer-perl  
ii  sane   1.0.14-12
ii  tesseract-ocr  3.04.01-6
ii  unpaper6.1-2+b1
ii  xdg-utils  1.1.2-1

gscan2pdf suggests no packages.

-- no debconf information

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#882990: Arbitrary meta-data date chosen

[martin f krafft]

Package: gscan2pdf
Version: 1.8.10-1
Severity: normal

Seems like a reprise of #842239 — yesterday, I noticed that instead
of 2017-11-27, the file-save dialog box defaulted to 2017-11-26 as
the save date to be stored in metadata. Close enough, I thought (but
still…)

Today, it suggested 2017-12-07. Something really just isn't working
right. Please either leave the field empty, or fill it in with
TODAY().

Thank you!

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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.4+dfsg-16
ii  libconfig-general-perl 2.63-1
ii  libdate-calc-perl  6.4-1
ii  libfilesys-df-perl 0.92-6+b3
ii  libgoo-canvas-perl 0.06-2+b4
ii  libgtk2-ex-simple-list-perl0.50-2
ii  libgtk2-imageview-perl 0.05-2+b4
ii  libhtml-parser-perl3.72-3+b2
ii  libimage-magick-perl   8:6.9.7.4+dfsg-16
ii  libimage-sane-perl 0.14-1+b1
ii  liblist-moreutils-perl 0.416-1+b3
ii  liblocale-gettext-perl 1.07-3+b3
ii  liblog-log4perl-perl   1.49-1
ii  libossp-uuid-perl [libdata-uuid-perl]  1.6.2-1.5+b6
ii  libpdf-api2-perl   2.033-1
ii  libproc-processtable-perl  0.53-2+b2
ii  libreadonly-perl   2.050-1
ii  librsvg2-common2.40.18-2
ii  libset-intspan-perl1.19-1
ii  libtiff-tools  4.0.8-6
ii  libtry-tiny-perl   0.28-1
ii  sane-utils 1.0.26~git20151121-1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin  3.5.27.1-8
ii  gocr   0.49-2+b1
pn  libgtk2-ex-podviewer-perl  
ii  sane   1.0.14-12
ii  tesseract-ocr  3.04.01-6
ii  unpaper6.1-2+b1
ii  xdg-utils  1.1.2-1

gscan2pdf suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#855887: Any news

[martin f krafft]

also sprach Jelmer Vernooij <jel...@jelmer.uk> [2017-11-21 23:17 +0100]:
> > > Forgot the link:
> > > https://mentors.debian.net/debian/pool/main/t/todoman/todoman_3.2.4-1.dsc
> > 
> > I just updated a new version which fixes a typo.
> 
> You should be receiving an email soon saying the package is in the NEW
> queue.

You guys are awesome. Thanks a lot.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#855887: Any news

[martin f krafft]

also sprach Jelmer Vernooij <jel...@jelmer.uk> [2017-11-21 23:17 +0100]:
> > > Forgot the link:
> > > https://mentors.debian.net/debian/pool/main/t/todoman/todoman_3.2.4-1.dsc
> > 
> > I just updated a new version which fixes a typo.
> 
> You should be receiving an email soon saying the package is in the NEW
> queue.

You guys are awesome. Thanks a lot.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#881866: yes(1): Possibility to specify delay between lines

[martin f krafft]

Package: coreutils
Version: 8.28-1
Severity: wishlist
File: /usr/bin/yes
Tags: upstream

Long shot, but it never hurts to try:

I've found myself wanting /usr/bin/yes to accept -d , e.g.

  yes -d5 .

which would output '.' every 5 seconds.

Obviously, I can just use a shell loop and sleep(1) instead, but
that same argument applies to yes(1) as a whole. Nevertheless, it's
a beautiful little utility that I think could benefit from this
backwards-compatible enhancement.

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-17
ii  libselinux1  2.7-2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Debian banners

[martin f krafft]

also sprach Ian Jackson <ijack...@chiark.greenend.org.uk> [2017-11-15 13:17 
+0100]:
> So, you could ship it to me.  Perhaps Debian wants to pay for the
> shipping out of Debian funds.

Thanks Ian,

at the moment I'm talking to someone in Cuba who'd have good use of
them if we can figure out how to get them over. On the other hand,
I think it'd be a better use of Debian funds just to print them
there.

If nothing else, then I'll take the banners to 34c3, where Holger
has agreed to take them over.

Thanks a lot for your offer though.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"i love deadlines. i like the whooshing
 sound they make as they fly by."
  -- douglas adams


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Debian shirts give-away

[martin f krafft]

Sent too quickly… there are also DebConf shirts from the following
years: 2005, 2006, 2007, 2008 (+orga), 2009 (+orga), 2011, 2014
(+orga), 2015 (+orga), 2016. All Men's L. Same principle as with the
other shirts. Sorry for the spam, if you perceive this as such.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"this sentence contradicts itself -- no actually it doesn't."
   -- douglas hofstadter


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Debian banners

[martin f krafft]

Hey,

I still have some heavy-duty banners we've used at conferences, as
well as a banner stand in my basement that I need to get rid of.
If you want them or you have an idea what to do with them, please
let me know. Else, come the end of November, I'll be forced to throw
them out.

Cheers,

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
minchinhampton (n.): the expression on a man's face when he has just
zipped up his trousers without due care and attention.
   -- douglas adams, the meaning of liff


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#879705: remotehost/transporttunnel "fix" breaks remotehost/preauthtunnel

[martin f krafft]

Package: offlineimap
Version: 7.1.3+dfsg1-1
Severity: important

According to the changelog, the latest version introduced some
"fixes" relating to remotehost and transporttunnel.

Unfortunately, it broke setups with preauthtunnel, it seems:

  ERROR: No remote host for repository 'madduck.net' specified.

If I add a dummy

  remotehost = notrequired

then it works again. Seems like it should be an easy fix, but it
meant I saw no new mail for a day, which makes this bug a bit more
severe. Or well, actually, it was a great day. Don't fix it. ;)

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

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

Versions of packages offlineimap depends on:
ii  python   2.7.14-1
ii  python-imaplib2  2.57-1
ii  python-six   1.11.0-1

Versions of packages offlineimap recommends:
pn  python-socks  

Versions of packages offlineimap suggests:
pn  python-kerberos  

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Debian-branded USB-powered fans

[martin f krafft]

also sprach Ondřej Surý <ond...@sury.org> [2017-10-22 11:05 +0200]:
> I don't know who's planning to have a FOSDEM booth, but maybe they could be
> shipped to Brussels in advance to the event.

Not a bad idea. Wouter, are you still involved?

These officially belong to DebConf15 still, but they aren't in the
balance sheet and thus officially written off. I'll leave it up to
the DebConf people and/or DPL to decide how much they're worth in
terms of sellings vs. giving away.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"anyone who is capable of getting themselves made president
 should on no account be allowed to do the job"
-- douglas adams


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Debian-branded USB-powered fans

[martin f krafft]

Hello,

We have precisely 198 USB-powered fans left over:

  
http://www.werbeartikel-planimed.de/USB-Ventilator-AERO-FRESH-Werbeartikel-1.html

These have a tiny Debian logo engraved close to the (soft) blades.

They're currently in our basement and can't stay there. I'm
therefore asking for someone to take them into custody, e.g. for
sale at conferences etc..

If by the end of November, nobody's stepped up, I'll be forced to
throw them out or might put them on Ebay.

So if you want them, let me know. There are two boxes, one with 69
and the other with 129. It's probably not worth to send these to
anywhere outside Europe.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"when a woman marries again it is because she detested her first husband.
 when a man marries again it is because he adored his first wife.
 women try their luck; men risk theirs."
  -- oscar wilde


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#812547: mediathek: please try to download subtitles

[martin f krafft]

also sprach Rogério Brito <rbr...@gmail.com> [2017-10-19 22:26 +0200]:
> > A lot of videos on the ARD/ZDF Mediathek feature subtitles, and
> > it'd be fantastic if there were a way to download them into the
> > mp4 container as well. Unfortunately, I have not found out the
> > URL scheme for those, or spotted them in the XML or Manifest
> > files.
> 
> Is this still relevant? Do you have any way of reproducing this?

It's still relevant, but I have no further information. I don't know
how those subtitles work. Any current video, e.g.
https://www.zdf.de/serien/die-bergretter/zu-kurz-gekommen-100.html
has the ability to toggle subtitles.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"if i am occasionally a little overdressed, i make up for it by being
 always immensely over-educated."
  -- oscar wilde


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#878749: Read user ID from Git

[martin f krafft]

Package: cil
Version: 0.07.00-11
Severity: wishlist
Tags: upstream

At least when using Git, cil can and should obtain the identifying
user information from Git:

  git config --get user.name
  git config --get user.email

unless defined (override) in the config file.

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

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

Versions of packages cil depends on:
ii  dpkg1.18.24
ii  libclass-accessor-perl  0.34-1
ii  libdatetime-perl2:1.44-1
ii  libemail-date-perl  1.104-1
ii  libemail-find-perl  0.10-dfsg-3
ii  libemail-simple-perl2.213-1
ii  libfile-homedir-perl1.00-1
ii  libfile-slurp-perl  .19-6
ii  libfile-touch-perl  0.11-1
ii  perl5.26.0-8
ii  perl-modules-5.26 [libdigest-perl]  5.26.0-8

cil recommends no packages.

cil suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#845542: Bug#844317: Bug#845542: include font-size extensions

[martin f krafft]

also sprach Ryan Kavanagh <r...@debian.org> [2017-10-11 23:45 +0200]:
> On Wed, Oct 11, 2017 at 05:21:45PM -0400, Antoine Beaupre wrote:
> > https://github.com/majutsushi/urxvt-font-size
> > https://github.com/simmel/urxvt-resize-font
> 
> majutsushi's seems to be a more recent version of the one by simmel, and
> according to the comments, is based off of simmel's.

I've been using the former successfully. It does what it promises.
I'd say that's enough.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
* Overfiend came out of the womb complaining.
-- #debian-devel


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#870463: Fixed in experimental?

[martin f krafft]

also sprach M G Berberich <deb...@oss.m-berberich.de> [2017-10-07 18:12 +0200]:
> I installed cups from experimental (2.2.4-91-g2cb1fda9f-1) on my
> testing (buster) system and the default printer is honored again.
> So it seems to solve this issue.

Great, so this bug report can now be about the issue to which it was
renamed. Nothing more to do or see here, please move along ;)

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
if you find a spelling mistake in the above, you get to keep it.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#878079: Does not handle target writing errors

[martin f krafft]

Package: rsync
Version: 3.1.2-2
Severity: important
Tags: upstream

If the destination of an rsync transfer is not writeable or runs out of free
space, the transfer does not abort. Instead, even the next file is
happily processed and errors are delayed until the very end:

  % sudo lvcreate -L 512M -n rsynctest albatross_hdd
Logical volume "rsynctest" created.

  % sudo mkfs.ext4 /dev/albatross_hdd/rsynctest
[…]

  % sudo mount /dev/albatross_hdd/rsynctest /mnt

  % cd /tmp; mkdir rsynctest; cd rsynctest

  % dd if=/dev/urandom of=one bs=1M count=1024
  1024+0 records in
  1024+0 records out
  1073741824 bytes (1,1 GB, 1,0 GiB) copied, 4,48301 s, 240 MB/s

  % ln one two

  % rsync -Pvr /tmp/rsynctest/ /mnt
  sending incremental file list
  one
1,073,741,824 100%  398.74MB/s0:00:02 (xfr#1, to-chk=1/3)
  two
1,073,741,824 100%  333.88MB/s0:00:03 (xfr#2, to-chk=0/3)
  rsync: mkstemp "/mnt/.one.REoYOa" failed: Permission denied (13)
  rsync: mkstemp "/mnt/.two.t6Pwx8" failed: Permission denied (13)

  sent 2,148,008,118 bytes  received 257 bytes  390,546,977.27 bytes/sec
  total size is 2,147,483,648  speedup is 1.00
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) at main.c(1196) [sender=3.1.2]

There, 2G of data transferred pointlessly. Or this:

  % rsync -Pvr /tmp/rsynctest/ /mnt
  sending incremental file list
  one
1,073,741,824 100%  251.77MB/s0:00:04 (xfr#1, to-chk=1/3)
  two
1,073,741,824 100%  328.21MB/s0:00:03 (xfr#2, to-chk=0/3)
  rsync: write failed on "/mnt/one": No space left on device (28)
  rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

And here, 1G of data transferred pointlessly.

This hasn't exactly caused data loss, but certainly a lot of time
was wasted.

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

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

Versions of packages rsync depends on:
ii  base-files   10
ii  init-system-helpers  1.49
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-17
ii  libpopt0 1.16-10+b2
ii  lsb-base 9.20170808

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.5p1-10
ii  openssh-server  1:7.5p1-10

-- debconf-show failed

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#870463: Fixed in experimental?

[martin f krafft]

also sprach M G Berberich <deb...@oss.m-berberich.de> [2017-10-07 18:12 +0200]:
> I installed cups from experimental (2.2.4-91-g2cb1fda9f-1) on my
> testing (buster) system and the default printer is honored again.
> So it seems to solve this issue.

Great, so this bug report can now be about the issue to which it was
renamed. Nothing more to do or see here, please move along ;)

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
if you find a spelling mistake in the above, you get to keep it.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#878078: Does not handle target writing errors

[martin f krafft]

Package: rsync
Version: 3.1.2-2
Severity: important
Tags: upstream

If the destination of an rsync transfer is not writeable or runs out of free
space, the transfer does not abort. Instead, even the next file is
happily processed and errors are delayed until the very end:

  % sudo lvcreate -L 512M -n rsynctest albatross_hdd
Logical volume "rsynctest" created.

  % sudo mkfs.ext4 /dev/albatross_hdd/rsynctest
[…]

  % sudo mount /dev/albatross_hdd/rsynctest /mnt

  % cd /tmp; mkdir rsynctest; cd rsynctest

  % dd if=/dev/urandom of=one bs=1M count=1024
  1024+0 records in
  1024+0 records out
  1073741824 bytes (1,1 GB, 1,0 GiB) copied, 4,48301 s, 240 MB/s

  % ln one two

  % rsync -Pvr /tmp/rsynctest/ /mnt
  sending incremental file list
  one
1,073,741,824 100%  398.74MB/s0:00:02 (xfr#1, to-chk=1/3)
  two
1,073,741,824 100%  333.88MB/s0:00:03 (xfr#2, to-chk=0/3)
  rsync: mkstemp "/mnt/.one.REoYOa" failed: Permission denied (13)
  rsync: mkstemp "/mnt/.two.t6Pwx8" failed: Permission denied (13)

  sent 2,148,008,118 bytes  received 257 bytes  390,546,977.27 bytes/sec
  total size is 2,147,483,648  speedup is 1.00
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 23) at main.c(1196) [sender=3.1.2]

There, 2G of data transferred pointlessly. Or this:

  % rsync -Pvr /tmp/rsynctest/ /mnt
  sending incremental file list
  one
1,073,741,824 100%  251.77MB/s0:00:04 (xfr#1, to-chk=1/3)
  two
1,073,741,824 100%  328.21MB/s0:00:03 (xfr#2, to-chk=0/3)
  rsync: write failed on "/mnt/one": No space left on device (28)
  rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

And here, 1G of data transferred pointlessly.

This hasn't exactly caused data loss, but certainly a lot of time
was wasted.

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

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

Versions of packages rsync depends on:
ii  base-files   10
ii  init-system-helpers  1.49
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-17
ii  libpopt0 1.16-10+b2
ii  lsb-base 9.20170808

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.5p1-10
ii  openssh-server  1:7.5p1-10

-- debconf-show failed


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#873175: Seems fixed

[martin f krafft]

reassign -1 cups
fixed -1 2.2.4-91-g2cb1fda9f-1
tags -1 fixed-upstream
kthxkbye

Seems like
https://github.com/apple/cups/commit/123cfe0202564a6ea0b2cdf33958bf550ab00016
fixes this. The version in experimental is no longer affected or so
it seems. Thanks Didier.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#873175: Seems fixed

[martin f krafft]

reassign -1 cups
fixed -1 2.2.4-91-g2cb1fda9f-1
tags -1 fixed-upstream
kthxkbye

Seems like
https://github.com/apple/cups/commit/123cfe0202564a6ea0b2cdf33958bf550ab00016
fixes this. The version in experimental is no longer affected or so
it seems. Thanks Didier.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#627085: Status

[martin f krafft]

also sprach Jochen Sprickerhof <jspri...@debian.org> [2017-10-04 11:41 +0200]:
> > I thought part of the deal with libpam-mount was that it kept
> > a session counter and only mounted if (!mounted) and only
> > unmounted if (mounted && n == 0)
> 
> I assume it does not, but I didn't check the sources.

modify_pm_count is the function that modifies the per-user counter:
https://sources.debian.net/src/libpam-mount/2.16-3/src/pmvarrun.c/#L209

man pmvarrun(8)…

pmt_already_mounted checks mtab for whether a volume is already
mounted:
https://sources.debian.net/src/libpam-mount/2.16-3/src/mount.c/#L140

So I'd say that this functionality is included, and if it's not
working as expected, then there's a bug.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"courage is not the absence of fear, but the decision
 that something else is more important than fear."
  -- ambrose redmoon


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#627085: Status

[martin f krafft]

also sprach Jochen Sprickerhof <jspri...@debian.org> [2017-09-29 23:16 +0200]:
> I assume you do multiple logins?

Who does not? ;)

But yes, this is the source of the "problem".

> So maybe we can implement a check if the directory is mounted
> already. Maybe you can even put in a simply script as
> a workaround.

I thought part of the deal with libpam-mount was that it kept
a session counter and only mounted if (!mounted) and only
unmounted if (mounted && n == 0)

> Would be great if you can give it a try and report back.

You mean I should write my own shell script to wrap the mount/umount
calls? Don't you think this should be fixed in source?

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"with sufficient thrust, pigs fly just fine. however, this is not
 necessarily a good idea. it is hard to be sure where they are going
 to land, and it could be dangerous sitting under them as they fly
 overhead."
   -- rfc 1925


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#534911: subnet topology requires static client subnet routes

[martin f krafft]

also sprach Jörg Frings-Fürst <deb...@jff-webhosting.net> [2017-10-03 21:38 
+0200]:
> at the follow-up from your ML link you found the soulution.

Thanks for cleaning up those old bug reports!

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"anyone who is capable of getting themselves made president
 should on no account be allowed to do the job"
  -- douglas adams


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#877066: Broken puppet(8) manpage

[martin f krafft]

Source: puppet
Version: 4.8.2-5
Severity: normal

The puppet(8) manpage is broken on Debian stretch:

  [1;31mError: Could not parse application options: invalid option: \-\-help[0m

Also: https://manpages.debian.org/stretch/puppet/puppet.8.en.html

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#627085: Status

[martin f krafft]

Is there anything I can contribute to getting this 6-year-old issue
fixed?

I currently have 174 mounts of a libpam-mount-controlled CIFS-mount
on this sid system:

% sort < /proc/mounts | uniq -c | sort -n | tail -1
174 //samba/tahi /srv/home/ssd/madduck/tahi cifs 
rw,nosuid,nodev,relatime,vers=1.0,cache=strict,username=madduck,domain=ALBATROSS,uid=1000,forceuid,gid=1000,forcegid,addr=2001:0470:77cb::22cf:30ff:fe2a:7c07,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1
 0 0

It goes without saying that I cannot unmount those. And #586009 does
not apply at all.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#876193: BackupPC_deleteFile: uses deprecated defined @{array}

[martin f krafft]

Package: backuppc
Version: 3.3.1-4
Severity: normal
Tags: patch
File: /usr/share/backuppc/bin/BackupPC_deleteFile

--- /tmp/BackupPC_deleteFile2017-09-19 14:41:18.724988937 +0200
+++ ./BackupPC_deleteFile   2017-09-19 14:42:09.229466557 +0200
@@ -429,7 +429,7 @@
 my $hrdlnkflg;
 foreach my $Host (keys %backupsHoHA) { #Loop through each host
$hrdlnkflg=0;
-   unless(defined @{$backupsHoHA{$Host}{baks}}) { #@baks is empty
+   unless(@{$backupsHoHA{$Host}{baks}}) { #@baks is empty
print "[$Host] ***NO BACKUPS FOUND IN DELETE RANGE***\n" unless 
$quietopt;
next;
}
@@ -970,7 +970,7 @@
push (@before, $baknum) if $baknum < $startnum; #sorted 
in decreasing order
unshift(@after, $baknum) if $baknum > $endnum; #sorted 
in increasing order
}
-   next unless defined @{$baksA}; # Nothing to backup on this host
+   next unless @{$baksA}; # Nothing to backup on this host

my $oldlevel = $$levelH{$$baksA[0]}; # i.e. level of first 
backup in baksA
for (@before) {

--- /tmp/BackupPC_deleteFile2017-09-19 13:53:56.722030824 +0200
+++ BackupPC_deleteFile 2017-09-19 13:07:22.171540831 +0200
@@ -269,7 +269,7 @@
 use File::Glob ':glob';
 use Data::Dumper;  #Just used for debugging...

-use lib "/usr/share/BackupPC/lib";
+use lib "/usr/share/backuppc/lib";
 use BackupPC::Lib;
 use BackupPC::jLib;
 use BackupPC::Attrib qw(:all);






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

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

Versions of packages backuppc depends on:
ii  adduser3.116
pn  apache2 | httpd
pn  apache2-utils  
ii  bzip2  1.0.6-8.1
ii  debconf1.5.63
ii  dpkg   1.18.24
ii  iputils-ping   3:20161105-1
ii  libarchive-zip-perl1.59-1
ii  libc6  2.24-15
ii  libcgi-pm-perl 4.36-1
pn  libdigest-md5-perl 
ii  libperl5.26 [libio-compress-perl]  5.26.0-5
pn  libtime-parsedate-perl 
ii  libwww-perl6.15-2
ii  perl   5.26.0-5
ii  postfix [mail-transport-agent] 3.2.2-1
pn  samba-common-bin   
ii  smbclient  2:4.6.7+dfsg-1
ii  tar1.29b-2
ii  ucf3.0036

Versions of packages backuppc recommends:
pn  libfile-rsyncp-perl  
pn  libio-dirent-perl
ii  openssh-client [ssh-client]  1:7.5p1-5
pn  rrdtool  
ii  rsync3.1.2-2

Versions of packages backuppc suggests:
ii  chromium [www-browser] 60.0.3112.78-1
ii  firefox [www-browser]  55.0-2
ii  firefox-esr [www-browser]  52.3.0esr-2
pn  par2   
ii  w3m [www-browser]          0.5.3-34

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#876190: Missing jLib.pm

[martin f krafft]

Package: backuppc
Version: 3.3.1-4
Severity: normal

At least BackupPC_deleteFile uses BackupPC::jLib, but the package
does not provide this file, nor can I find it in the archive.

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

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

Versions of packages backuppc depends on:
ii  adduser3.116
pn  apache2 | httpd
pn  apache2-utils  
ii  bzip2  1.0.6-8.1
ii  debconf1.5.63
ii  dpkg   1.18.24
ii  iputils-ping   3:20161105-1
ii  libarchive-zip-perl1.59-1
ii  libc6  2.24-15
ii  libcgi-pm-perl 4.36-1
pn  libdigest-md5-perl 
ii  libperl5.26 [libio-compress-perl]  5.26.0-5
pn  libtime-parsedate-perl 
ii  libwww-perl6.15-2
ii  perl   5.26.0-5
ii  postfix [mail-transport-agent] 3.2.2-1
pn  samba-common-bin   
ii  smbclient  2:4.6.7+dfsg-1
ii  tar1.29b-2
ii  ucf3.0036

Versions of packages backuppc recommends:
pn  libfile-rsyncp-perl  
pn  libio-dirent-perl
ii  openssh-client [ssh-client]  1:7.5p1-5
pn  rrdtool  
ii  rsync3.1.2-2

Versions of packages backuppc suggests:
ii  chromium [www-browser] 60.0.3112.78-1
ii  firefox [www-browser]  55.0-2
ii  firefox-esr [www-browser]  52.3.0esr-2
pn  par2   
ii  w3m [www-browser]  0.5.3-34


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#876188: Wrong path in BackupPC_deleteFile

[martin f krafft]

Package: backuppc
Version: 3.3.1-4
Severity: normal
Tags: patch
File: /usr/share/backuppc/bin/BackupPC_deleteFile

--- /tmp/BackupPC_deleteFile2017-09-19 13:53:56.722030824 +0200
+++ BackupPC_deleteFile 2017-09-19 13:07:22.171540831 +0200
@@ -269,7 +269,7 @@
 use File::Glob ':glob';
 use Data::Dumper;  #Just used for debugging...

-use lib "/usr/share/BackupPC/lib";
+use lib "/usr/share/backuppc/lib";
 use BackupPC::Lib;
 use BackupPC::jLib;
 use BackupPC::Attrib qw(:all);






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

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

Versions of packages backuppc depends on:
ii  adduser3.116
pn  apache2 | httpd
pn  apache2-utils  
ii  bzip2  1.0.6-8.1
ii  debconf1.5.63
ii  dpkg   1.18.24
ii  iputils-ping   3:20161105-1
ii  libarchive-zip-perl1.59-1
ii  libc6  2.24-15
ii  libcgi-pm-perl 4.36-1
pn  libdigest-md5-perl 
ii  libperl5.26 [libio-compress-perl]  5.26.0-5
pn  libtime-parsedate-perl 
ii  libwww-perl6.15-2
ii  perl   5.26.0-5
ii  postfix [mail-transport-agent] 3.2.2-1
pn  samba-common-bin   
ii  smbclient  2:4.6.7+dfsg-1
ii  tar1.29b-2
ii  ucf3.0036

Versions of packages backuppc recommends:
pn  libfile-rsyncp-perl  
pn  libio-dirent-perl
ii  openssh-client [ssh-client]  1:7.5p1-5
pn  rrdtool  
ii  rsync3.1.2-2

Versions of packages backuppc suggests:
ii  chromium [www-browser] 60.0.3112.78-1
ii  firefox [www-browser]  55.0-2
ii  firefox-esr [www-browser]  52.3.0esr-2
pn  par2   
ii  w3m [www-browser]  0.5.3-34


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Viktor Dukhovni  [2017-09-18 22:39 
+0200]:
> > No, they're all managed centrally and pushed regularly.
> 
> So, though this is not your best option, you can centrally capture
> the updated fingerprints and automate their deployment (along with
> the most recent previous fingerprint to avoid race conditions).

In fact, there are three options right now:

  a/ collect and deploy the fingerprints, as you say
  b/ use a self-signed certificate with life-time 99 years just for
 this purpose
  c/ use public key fingerprints instead of the cert fingerprints

I think (a) is really just ungood. I just implemented (c), which was
trivial and solves the problem. Thanks also to Daniel Kahn Gilmor
for the vital hint that made me realise Postfix 2.9 supports this.

Long-term, I think I might want to look into (b) though. I like the
idea of having a single certificate ("identity") of a host, that
then gets used in its various facets, but that's actually probably
not good security advice anyway.

> > At the moment, I have to assume, however, that LE wouldn't actually
> > care if I requested a cert renewal with a http-01 when I've used
> > dns-01 in the past.
> 
> I'd also be curious to know the answer to that.  Please follow-up
> if you find out.  I'm sure that enough folks here use LE certs to
> justify a slightly off-topic post.

I'll put this in my tickler file for 30 days from now.

> All that said, the case for submission based on CA authenticated
> key -> name bindings is not looking too strong.  This is not going
> to have a significant priority unless a more compelling use-case
> shows up.

Yeah, makes sense. Thanks for your patience!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"computer science is no more about computers
 than astronomy is about telescopes."
   -- edsgar w. dijkstra
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Viktor Dukhovni  [2017-09-18 00:31 
+0200]:
> So your certral system generates the keys, and obtains the LE
> certificates on behalf of the far-flung hosts?  And then pushes
> these keys to the hosts over an SSH tunnel?
> 
> Is that only for the initial key issuance?  And then each host
> rotates the certs independently of the central system using the
> existing key to authenticate to LE?

No, they're all managed centrally and pushed regularly.

> I am curious why you want to rotate the submission TLS client
> keys. If you are able to centrally push keys to the hosts, why
> bother with a CA at all?  Why not generate a self-signed key+cert,
> store the fingerprint in a database, and leave LE out of it?  The
> key would not change for the lifetime of the host.

This is a very good question, and I'm blushing a bit having to admit
that I haven't thought of that. Heck, Debian even gives you a free
snakeoil cert on installation. I'll totally have to look into it.
Thanks for the brainfood.

> DNSSEC helps with having CAA records that are difficult to MiTM,
> and protectst the DNS challenge protocol, but I don't whether it
> is possible to disable bootstrapping over weaker email challenges
> and/or control over port 80.

This is another excellent point I'lll bring up with the LE folks: if
I go through lengths securing my DNS chain for their challenges,
I'd like to be able to lock my account onto that, a bit like HSTS.
At the moment, I have to assume, however, that LE wouldn't actually
care if I requested a cert renewal with a http-01 when I've used
dns-01 in the past.

Anyway, this is getting vastly off-topic… sorry about that.

> I should also note that with LE and certbot's "--csr" option you
> can renew LE certificates *without* changing the public key.  In
> which case the public key fingerprint is stable, and need not
> change.

Hm, yes, I knew that, but I only just found out that postfix 2.9+
can do check_ccert_access based on the public key fingerprint (not
the certificate fingerprint). So that's that then…

> The reason I am asking them is not because I've decided to not
> implement access by subject name (though given the SAN situation,
> and the potentially large number of SANs to test, the feature is
> tricky to implement fully and correctly).

Indeed, it's not as easy as I had imagined. OTOH, it would not be
unfathomable to iterate all SANs and check each against an access
map. For sanity, one could introduce an upper bound. And it's
a policy decision whether the final decision would be the min or the
max of the set of sub-decisions…

Thanks a lot for this enlightening exchange.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
takt ist der auf das benehmen angewandte gute geschmack.
  -- nicolas de chamfort
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Wietse Venema  [2017-09-17 21:51 +0200]:
> I wonder, if this is used for 'internal' email traffic, why bother
> with certificates that require frequent renewal? If the organization
> is that large, I would expect that all external email is handled
> by relay hosts on the perimeter, instead of allowing direct mail
> from random 'internal' hosts.

That's precisely what we're trying to do, except the perimeter is
non-physical as the hosts are spread across the 'Net, and there's no
consistent VPN, unfortunately.

So yes, all external mail is handled by a defined set of relay hosts
on the perimeter, but we need a sensible way to authorize access to
those relay hosts. I'd prefer certificates over SASL passwords, and
I think that the ease of using letsencrypt far outweighs the
additional security we'd get in return for the effort required to
manage our own PKI.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
in the beginning was the word,
and the word was content-type: text/plain
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Viktor Dukhovni  [2017-09-17 21:49 
+0200]:
> I think you're saying your organization places machines you
> (collectively) build on other people's networks, but the machines
> need to send call home to send email, which is sometimes outbound
> to other domains?

I'll go with that.

> You don't have to the same key/cert across the board, the client
> certificate for submission does not need to be (and perhaps should
> not be) the one that's issued by Let's Encrypt (LE).

True. We could create a CA for this purpose, but tbh, we've done
this in the past and — given that 2 of the 3 organisations I'm
dealing with are non-profit and hence resource-limited, managing all
aspects of a CA was always just too hard.

> Are you using LE to obtain certificates that are trusted by other
> parties, or using LE because "certbot", ... make it easy to
> automate renewal?

A little bit of that, and a little bit of "it's just easier that
way".

> How does one of these far-flug clients get an LE certificate in
> your domain in the first place?

We control the DNS infrastructure centrally in all cases (using
DNSSEC, of course), and so we issue them centrally. They are
currently deployed over SSH tunnels to the hosts.

> > Given that we trust Letsencrypt (for benefit of doubt) —
> 
> I am trying to understand why you want to delegate relay control
> decisions for your domain to LE.

It's a valid question, for sure. But I wouldn't say we delegate
relay control decisions to LE per se. Of course they'd become part
of the equation and could abuse it, but that'd be the end of their
story, too.

I'm intending to make relay control decisions based on information
LE has authenticated.

And yes, I wouldn't do this with high security requirements, but
an SMTP smarthost just doesn't fall into that domain for me,
especially not if constantly monitored.

> > Given that LE's challenge-response means that only we can issue
> > certs that contain example.org in the CN or SubjectAltNames list —
>
> Can you explain a bit more detail here?

In order to obtain an LE certificate with foo.example.org in CN/SAN,
I have to regularly prove that I control foo.example.org towards LE.
That's their trust model. It's similar to CACert's, except it's
automated and there's a trust path to the existing set of CA certs
as distributed by e.g. Mozilla.

> > Why do I have to give postfix the fingerprints. Wouldn't it be just
> > as safe and a lot easier to say "certs matching¹ .example.org issued
> > by LE" and be done with it.
> 
> Well, it isn't typically "just as safe", the LE enrollment process
> is often vulnerable to on-path or BGP-route forgery MiTM attacks
> between the CA and the domain for which the certificates are being
> issued.

DNSSEC does address this somewhat. Nevertheless, in my
security-vs-cost calculation, getting relay access to a smarthost is
not worth the price it'd cost to infiltrate the enrollment process
as you say.

Apart, the current way by which Postfix uses cert fingerprints is
just as vulnerable to those kinds of attacks, no?

> > So there exists no longer a canonical name/identity of
> > a certificate?
> 
> The canonical identity is the issuer DN + serial number.
> The subject DN can be an empty RDN sequence.  Mind you,
> at the moment all the LE certificates I've seen have
> a nonempty CN as the sole component of the subject DN,
> and this may not change for a long time, but it is not
> guaranteed indefinitely...

Indeed. The problem with including the serial number means that the
ID of the certificate changes on every reissue. Part of the idea I'm
after is of course to have a canonical identity (i.e. the primary
DNS name, or whatever you want it to be) which just gets
reauthenticated at regular intervals, but doesn't change.

Thanks for your challenging questions. I'm well aware that this
isn't exactly postfix-users material, but it's helping me
tremendously, and I hope others also find this interesting. I do
hope Postfix will benefit from this long-term, by way of docs, or
something like check_certname_access or whatever we come up with.

Cheers,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"the mind of the thoroughly well-informed man is a dreadful thing.
 it is like a bric-à-brac shop, all monsters and dust,
 with everything priced above its proper value."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Viktor Dukhovni  [2017-09-17 18:09 
+0200]:
> Can you explain your use-case in a bit more detail? What sort of
> SMTP clients are these, that they authenticate using TLS client
> certificates not issued by a CA you control and you're then
> providing submission access to said clients based on their domain
> as found in the certificate CN?

I have three distinct use-cases, but they're all more or less the
same, involving 107 hosts altogether spread across the globe in
untrusted networks, often with weird firewalling or other policies.
There are several hundreds of users making use of cron and other
things that basically require sendmail on each host. To keep our
sanity, we currently have it such that all hosts forward their mail
to a smarthost via the submission port, TLS-secured, and
authenticated with the TLS cert fingerprint (using
check_ccert_access).

Our recent move to Letsencrypt means that the hosts now get new
client certificates every 2–3 months. At the moment, this means we
have to update the check_ccert_access map on the smarthost once
almost every day with new fingerprint.

Of course one could automate this, or switch to password
authentication, but in thinking about this, I was wondering:

Given that we trust Letsencrypt (for benefit of doubt) —

Given that LE's challenge-response means that only we can issue
certs that contain example.org in the CN or SubjectAltNames list —

Why do I have to give postfix the fingerprints. Wouldn't it be just
as safe and a lot easier to say "certs matching¹ .example.org issued
by LE" and be done with it.

Does that make it a bit clearer?

¹) see discussion on canonical identity and SubjAltNames lists below

> Keep in mind that DNS names stored as the CommonName of the
> certificate subject DN is a deprecated representation of the
> client identity.

Interesting, I didn't know that. I'll do some research.

> Though most CAs have not yet stopped putting nonempty subject DNs
> in certificates, the right place for certificate names is the
> subjectAlternativeName extension, which bears zero or more DNS
> names and perhaps names of other types too.

So there exists no longer a canonical name/identity of
a certificate? I am well aware of SubjectAltNames, but I am unsure
they're ordered, or whether there even exists such a convention
that e.g. the first one is the primary name.

In the present technical approach I'm proposing, the lack of
a canonical identity would mean that postfix would actually have to
check every single one of the SubjectAltNames against an access map,
which may cause problems depending on the length of this list,² and
may well render this approach meaningless.

²) I've seen certs with dozens, maybe even >100 SubjAltNames…

Obviously, one solution would be to create an intermediary CA that
we control. However, I think that's just asking for trouble. For
one, trust chains longer than 2 expose some nasty bugs in most
server and client implementations, and second, Letsencrypt doesn't
support that anyway I don't think, and we don't want to go back to
the X.509 Mafia.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"of course the music is a great difficulty.
 you see, if one plays good music, people don't listen,
 and if one plays bad music people don't talk."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Wietse Venema  [2017-09-17 17:26 +0200]:
> > > 2) Use a new check_certname_access feature to reject out-of-doman
> > >names. Postfix should not make 'allow' decisions based on name
> > >information in a certificate with an untrusted CA.
> 
> Any CA that is not in smtpd_tls_CA_file. I see no harm in allowing
> 'reject' decisions based on the name in a certificate from an unknown
> CA.

If a client connects to the submission port and presents
a certificate that is not from a trusted CA, then
check_certname_access obviously can't make an authoritative
decision, and the client will most likely end up in some "reject"
later on in the restriction list. I.e. I think in that case,
check_certname_access should always return DUNNO.

If a client connects and presents a certificate from a CA listed in
smtpd_tls_CA_file, then I don't see a reason why the new
check_certname_access shouldn't be able to cast an "OK" and thereby
permit accepting/relaying of the message.

I hope we're not talking past each other.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
remember, half the people are below average.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Wietse Venema  [2017-09-17 16:34 +0200]:
> 1) Use smtpd_tls_CA_file to trust ONLY the letsencrypt CA.

Right, especially since I could set this only for the smtpd handling
submissions and need not impose this setting on regular port 25 SMTP
connections.

I suppose it would get difficult if there was more than one issuing
CA, but that's probably a rare case, if at all.

> 2) Use a new check_certname_access feature to reject out-of-doman
>names. Postfix should not make 'allow' decisions based on name
>information in a certificate with an untrusted CA.

Why do you consider the CA untrusted? Isn't that the whole point of
the smtpd_tls_CA_file setting? Am I not making the statement "I
trust the certificates issued by this CA to have reliable CNs" by
specifying smtpd_tls_CA_file in our scenario?

If Postfix couldn't issue "allow" based on check_certname_access,
then the logic would have to be:

  check_certname_access (reject if !.example.org)
  permit

which IMHO is backwards and not any more secure than

  check_certname_access (permit if .example.org)
  reject

… unless you had something else in mind to issue that "permit" in
the first example?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
it is better to remain silent and be thought a fool
than to open one's mouth and remove all doubt.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Authenticating clients based on CA/CN-match

[martin f krafft]

Hello,

As far as I can tell, postfix can authenticate its clients using
certificates in two ways:

  check_ccert_access (also permit_tls_clientcerts), which
  authorizes clients based on the cert fingerprint;

  permit_tls_all_clientcerts, which authorizes clients if they
  present a cert signed by a specific CA;

We've been using the former for years, requiring us to manually
deploy the new fingerprints every two years. But we've now migrated
to Letsencrypt, and doing so every two months won't work anymore.
Furthermore, we can't just trust all certs issued by Letsencrypt,
nor is it feasible to introduce a custom CA just for this purpose.

So we can now either automate the deployment of fingerprints,
surely, but I was also wondering if it weren't possible to add the
following functionality to postfix:

Either extend check_ccert_access or introduce a new access map,
which takes the CN from the client cert and maps it to a CA
identifier. E.g.

  .example.org  /etc/ssl/certs/DST_Root_CA_X3.pem

meaning that if a client presents a certificate who's CN is
a subdomain of example.org, and the certificate trust chain is
complete up until the certificate provided in
/etc/ssl/certs/DST_Root_CA_X3.pem, then grant access.

This would allow users to easily grant access to all hosts in their
subdomain, even if the certs are issued by a common CA such as
Letsencrypt. The match on the cert CN should be sufficient to guard
against abuse.

What do you think?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"god is a comedian playing to an audience too afraid to laugh."
 -- voltaire
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#875762: [Pkg-libvirt-maintainers] Bug#875762: Does not follow /etc/network/interfaces includes

[martin f krafft]

also sprach Guido Günther <a...@sigxcpu.org> [2017-09-14 13:27 +0200]:
> Libvirt itself does not interface parsing. It relies on augeas for
> that (and I thought that would be fixed in stretch).

Yes, augeas parses this, but augeas also works fine:

  root@eugene:/etc/network/interfaces.d# augtool print 
/files/etc/network/interfaces.d/
  /files/etc/network/interfaces.d
  /files/etc/network/interfaces.d/local-wan
  /files/etc/network/interfaces.d/local-wan/#comment = "The primary network 
interface"
  /files/etc/network/interfaces.d/local-wan/auto
  /files/etc/network/interfaces.d/local-wan/auto/1 = "wan"
  /files/etc/network/interfaces.d/local-wan/iface = "wan"
  /files/etc/network/interfaces.d/local-wan/iface/family = "inet"
  /files/etc/network/interfaces.d/local-wan/iface/method = "static"
  […]

So this is likely a netcf issue, actually. Should I reassign to
libnetcf1?

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
i welcome your constructive criticism and corrections.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#875766: Don't fail if bridge port already exists

[martin f krafft]

Package: libvirt-daemon
Version: 3.0.0-4
Severity: wishlist

virt-install failed on me with this error:

  [Thu, 14 Sep 2017 13:10:14 virt-install 16798] DEBUG (cli:307)   File 
"/usr/share/virt-manager/virt-install", line 996, in 
  sys.exit(main())
File "/usr/share/virt-manager/virt-install", line 990, in main
  start_install(guest, options)
File "/usr/share/virt-manager/virt-install", line 716, in start_install
  fail(e, do_exit=False)
File "/usr/share/virt-manager/virtinst/cli.py", line 307, in fail
  logging.debug("".join(traceback.format_stack()))

  [Thu, 14 Sep 2017 13:10:14 virt-install 16798] ERROR (cli:308) Unable to add 
bridge wan port vnet0: Device or resource busy
  [Thu, 14 Sep 2017 13:10:14 virt-install 16798] DEBUG (cli:310) 
  Traceback (most recent call last):
File "/usr/share/virt-manager/virt-install", line 695, in start_install
  transient=options.transient)
File "/usr/share/virt-manager/virtinst/guest.py", line 461, in start_install
  doboot, transient)
File "/usr/share/virt-manager/virtinst/guest.py", line 396, in _create_guest
  self.domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3523, in createXML
  if ret is None:raise libvirtError('virDomainCreateXML() failed', 
conn=self)
  libvirtError: Unable to add bridge wan port vnet0: Device or resource busy

I tracked this down to the fact that systemd (presumably) had
already added vnet0 to the bridge, thanks to the following line in
/etc/network/interfaces:

  iface wan inet static
[…]
bridge_ports enp3s0f0 regex vnet[0-9]+

The reason I want this is because if I ever take an interface down
and bring it back up, I want the existing vnet interfaces to be
automatically added.

So I suggest that the libvirt code adding the bridge should not fail
if the very port it's trying to add already exists in the bridge. Or
maybe it'd be better made configurable…

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

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

Versions of packages libvirt-daemon depends on:
ii  libapparmor12.11.0-10
ii  libaudit1   1:2.7.7-1+b2
ii  libavahi-client30.6.32-2
ii  libavahi-common30.6.32-2
ii  libblkid1   2.29.2-4
ii  libc6   2.24-14
ii  libcap-ng0  0.7.7-3+b1
ii  libcurl3-gnutls 7.55.0-1
ii  libdbus-1-3 1.11.16+really1.10.22-1
ii  libdevmapper1.02.1  2:1.02.142-1
ii  libfuse22.9.7-1
ii  libgnutls30 3.5.14-2
pn  libnetcf1   
ii  libnl-3-200 3.2.27-2
ii  libnl-route-3-200   3.2.27-2
ii  libnuma12.0.11-2.1
ii  libparted2  3.2-17
ii  libpcap0.8  1.8.1-3
ii  libpciaccess0   0.13.4-1+b2
pn  librados2   
pn  librbd1 
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libselinux1 2.6-3+b2
ii  libssh2-1   1.8.0-1
ii  libudev1234-2
ii  libvirt03.6.0-1
ii  libxen-4.8  4.8.1-1+deb9u1
ii  libxenstore3.0  4.8.1-1+deb9u1
ii  libxml2 2.9.4+dfsg1-3
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-3
ii  netcat-openbsd  1.178-3
ii  qemu1:2.8+dfsg-7
ii  qemu-kvm1:2.8+dfsg-7

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-system  
pn  numad  

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#875762: Does not follow /etc/network/interfaces includes

[martin f krafft]

Package: libvirt-daemon
Version: 3.0.0-4
Severity: normal

libvirtd does not follow the "new" /e/n/i include directive.
Interfaces that are defined in included files won't be available to
libvirtd.

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

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

Versions of packages libvirt-daemon depends on:
ii  libapparmor12.11.0-10
ii  libaudit1   1:2.7.7-1+b2
ii  libavahi-client30.6.32-2
ii  libavahi-common30.6.32-2
ii  libblkid1   2.29.2-4
ii  libc6   2.24-14
ii  libcap-ng0  0.7.7-3+b1
ii  libcurl3-gnutls 7.55.0-1
ii  libdbus-1-3 1.11.16+really1.10.22-1
ii  libdevmapper1.02.1  2:1.02.142-1
ii  libfuse22.9.7-1
ii  libgnutls30 3.5.14-2
pn  libnetcf1   
ii  libnl-3-200 3.2.27-2
ii  libnl-route-3-200   3.2.27-2
ii  libnuma12.0.11-2.1
ii  libparted2  3.2-17
ii  libpcap0.8  1.8.1-3
ii  libpciaccess0   0.13.4-1+b2
pn  librados2   
pn  librbd1 
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libselinux1 2.6-3+b2
ii  libssh2-1   1.8.0-1
ii  libudev1234-2
ii  libvirt03.6.0-1
ii  libxen-4.8  4.8.1-1+deb9u1
ii  libxenstore3.0  4.8.1-1+deb9u1
ii  libxml2 2.9.4+dfsg1-3
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-3
ii  netcat-openbsd  1.178-3
ii  qemu1:2.8+dfsg-7
ii  qemu-kvm1:2.8+dfsg-7

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-system  
pn  numad  


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#870463: lp no longer honours default printers

[martin f krafft]

also sprach Didier 'OdyX' Raboud <o...@debian.org> [2017-08-26 15:20 +0200]:
> >   albatross:~/FOR_FILING% head -1 ~/.cups/lpoptions
> >   Default mfc9465cdn
> >   albatross:~/FOR_FILING% lp -P 30 2017-08-02-Scans.pdf
> >   lp: Error - no default destination available.

I am sorry, I totally forgot about this bug report. The problem was
that the cups-browsed upgrade ended up with new device names, so
obviously the previous one "mfc9465cdn" no longer works. The error
message could be improved, i.e. "Invalid default destination
specified in config file: mfc9465cdn", but other than that, this
isn't really a bug.

What do you want me to do? Take this upstream? Downgrade? Close?

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
i'd rather be riding a high speed tractor
with a beer on my lap,
and a six pack of girls next to me.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#873287: Fails to administer lists whose web interfaces have redirected

[martin f krafft]

Package: listadmin
Version: 2.42-1
Severity: normal

Due to HTTPS hosting requirements, lists.pantsfullofunix.net redirects to
https://pantsfullofunix-net.lists.madduck.net/. Unfortunately, listadmin is
unable to follow the redirection:

fetching data for recl...@lists.pantsfullofunix.net ...
ERROR: fetching http://lists.pantsfullofunix.net/mailman/admindb/reclass
ERROR: 301 Moved Permanently -- skipping list

Could this easily be fixed?

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

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

Versions of packages listadmin depends on:
ii  libcrypt-ssleay-perl   0.73.04-2+b2
ii  libnet-inet6glue-perl  0.603-2
ii  libtext-reform-perl1.20-3
ii  libwww-perl6.15-2

listadmin recommends no packages.

listadmin suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#610932: info

[martin f krafft]

also sprach Peter Gervai <g...@grin.hu> [2017-08-24 11:55 +0200]:
> this would be fixed by 4.xx released back in april.

that's great news. do you have a commit hash or changelog entry at
hand?

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#873175: Expiring subscriptions every second, battery/power hog

[martin f krafft]

Package: cups-browsed
Version: 1.16.3-1
Severity: normal

Once I start cups-browsed, as soon as it receives an announcement on
the web, it then wakes up every second to write to the log file:

I [24/Aug/2017:15:28:23 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:24 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:25 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:26 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:27 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:28 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:29 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:30 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:31 +0200] Expiring subscriptions...
I [24/Aug/2017:15:28:32 +0200] Expiring subscriptions...

This happens endlessly and means that cups-browsed consumes a whole
lot more power than most other processes on my system.

I've found no way to influence this. As soon as I stop browsed, it
stops.

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

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

Versions of packages cups-browsed depends on:
ii  cups-daemon  2.2.4-3
ii  init-system-helpers  1.49
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavahi-glib1   0.6.32-2
ii  libc62.24-15
ii  libcups2 2.2.4-3
ii  libcupsfilters1  1.16.3-1
ii  libglib2.0-0 2.53.6-1
ii  libldap-2.4-22.4.45+dfsg-1
ii  lsb-base 9.20161125

Versions of packages cups-browsed recommends:
pn  avahi-daemon  

cups-browsed suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872752: [Pkg-sugar-devel] Bug#872752: Following user config, nothing happens, strace exposes Heisenbug

[martin f krafft]

also sprach Jonas Smedegaard <jo...@jones.dk> [2017-08-20 23:00 +0200]:
> Did you file the bugreport on the system you also run Sugar?

No, and I am sorry about that. I'll augment that tonight. I have
all recommendations installed, but I also now learnt where to look
for logs, so I might well close this issue and open a new one with
all the details, for a fresh start. Sorry guys.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
time wounds all heels.
 -- groucho marx


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872752: [Pkg-sugar-devel] Bug#872752: Following user config, nothing happens, strace exposes Heisenbug

[martin f krafft]

also sprach Jonas Smedegaard <jo...@jones.dk> [2017-08-20 21:37 +0200]:
> Possibly there is some info in the various logfiles below ~/sugar - in 
> there should also be a config file where you can uncomment a debug flag 
> to get more verbose logs.

I'll look into this more later this week.

> Can you try remove/rename ~/.sugar and then login not via a custom
> .xsession shell call, but using the desktop entry (i.e. by
> selecting Sugar in the popup window in LightDM.  If using the
> default Gtk+ interface then that should be available in the top
> right corner. If that crashes too then there is some bug in the
> package - else I lean towards dismissing this as a user error (an
> undocumented way to start Sugar), but I can be persuaded to try
> dig deeper if you want to help explore it further.

The behaviour seems exactly the same if I choose "Sugar" as the
session to use from lightdm — thanks for letting me know how to do
that, I wasn't even aware of the menu up top ;)

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
if you see an onion ring -- answer it!


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872751: [Pkg-sugar-devel] Bug#872751: Cannot change colour when run from xsession

[martin f krafft]

also sprach Jonas Smedegaard <jo...@jones.dk> [2017-08-20 21:24 +0200]:
> Not quite sure what is the bug here - title says "cannot change colour" 
> but above you write that you "can select a colour" but not click the X.
> 
> Did you perhaps mean to say that you cannot _cancel_ while in the color 
> selection interface?

Sorry, was unclear. I am asked to change the colour, but clicking on
the X doesn't actually do anything. So I can only click "Next" and
be forced to use the colour that was selected on startup (always the
same).

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"the only difference between shakespeare and you
 was the size of his idiom list -- not the size of his vocabulary."
  -- alan perlis


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872748: [Pkg-sugar-devel] Bug#872748: Does not register as a session or window manager (alternatives system)

[martin f krafft]

also sprach Jonas Smedegaard <jo...@jones.dk> [2017-08-20 21:20 +0200]:
> Reason the package provides the virtual x-session-manager package
> is that it does satisfy the needs of recommendations by login
> managers and xinit.
> 
> If you have suggestions for handling the situation better, or am
> aware of problems with the current approach, please share them.
> Otherwise would you mind me closing this as a non-bug?

Sure, you can close this if it's a non-bug. From what you write, it
doesn't make sense to make Sugar the
x-session-manager/x-window-manager on a system by default, except
for the fewest cases.

At the moment, lightdm does not give me options over what session to
choose, and I need to figure that out, but as long as I can
configure the default session of individual users to be Sugar, then
that's just fine.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"prisons are built with stones of law,
 brothels with bricks of religion."
-- william blake


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872751: Cannot change colour when run from xsession

[martin f krafft]

Package: sugar-session
Version: 0.110.0-3
Severity: minor

Starting /usr/bin/sugar from ~/.xsession (after logging the user in
via lightdm) gets me the intro screen, where I can select a colour.
However, clicking on the X doesn't do anything. I can, however,
click "Next", select gender, and age…

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

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

Versions of packages sugar-session depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gconf2   3.2.6-4+b1
pn  gir1.2-gconf-2.0 
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gtk-3.0   3.22.16-1
pn  gir1.2-gudev-1.0 
pn  gir1.2-nmgtk-1.0 
ii  gir1.2-pango-1.0 1.40.6-1
pn  gir1.2-upowerglib-1.0
pn  gir1.2-xkl-1.0   
ii  python   2.7.13-2
ii  python-cairo 1.8.8-2.2
ii  python-dbus  1.2.4-1+b2
pn  python-jarabe
pn  python-sugar3
pn  sugar-themes 

Versions of packages sugar-session recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.20-1
ii  dbus-x11 [dbus-session-bus]   1.10.20-1
ii  ethtool   1:4.8-1+b1
ii  fonts-dejavu-core 2.37-1
pn  gvfs  
ii  lsb-release   9.20161125
pn  mobile-broadband-provider-info
ii  modemmanager  1.6.8-1
pn  network-manager   
pn  sugar-browse-activity 
pn  sugar-chat-activity   
pn  sugar-imageviewer-activity
pn  sugar-jukebox-activity
pn  sugar-log-activity
pn  sugar-pippy-activity  
pn  sugar-read-activity   
pn  sugar-terminal-activity   
pn  sugar-write-activity  
pn  telepathy-salut   
ii  tzdata2017b-2
ii  upower0.99.4-4+b1

Versions of packages sugar-session suggests:
ii  gdb   7.12-6
pn  gir1.2-maliit-1.0 
pn  maliit-keyboard   
pn  olpc-powerd   
pn  sucrose   
pn  sugar-calculate-activity  
pn  sugar-etoys-activity  
pn  sugar-turtleart-activity  

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872748: Does not register as a session or window manager (alternatives system)

[martin f krafft]

Package: sugar-session
Version: 0.110.0-3
Severity: minor

The package is said to be a session and window manager, but it does
not register itself with the alternatives system as such. Could this
be changed, or is there a reason this isn't the case?

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

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

Versions of packages sugar-session depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gconf2   3.2.6-4+b1
pn  gir1.2-gconf-2.0 
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gtk-3.0   3.22.16-1
pn  gir1.2-gudev-1.0 
pn  gir1.2-nmgtk-1.0 
ii  gir1.2-pango-1.0 1.40.6-1
pn  gir1.2-upowerglib-1.0
pn  gir1.2-xkl-1.0   
ii  python   2.7.13-2
ii  python-cairo 1.8.8-2.2
ii  python-dbus  1.2.4-1+b2
pn  python-jarabe
pn  python-sugar3
pn  sugar-themes 

Versions of packages sugar-session recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.20-1
ii  dbus-x11 [dbus-session-bus]   1.10.20-1
ii  ethtool   1:4.8-1+b1
ii  fonts-dejavu-core 2.37-1
pn  gvfs  
ii  lsb-release   9.20161125
pn  mobile-broadband-provider-info
ii  modemmanager  1.6.8-1
pn  network-manager   
pn  sugar-browse-activity 
pn  sugar-chat-activity   
pn  sugar-imageviewer-activity
pn  sugar-jukebox-activity
pn  sugar-log-activity
pn  sugar-pippy-activity  
pn  sugar-read-activity   
pn  sugar-terminal-activity   
pn  sugar-write-activity  
pn  telepathy-salut   
ii  tzdata2017b-2
ii  upower0.99.4-4+b1

Versions of packages sugar-session suggests:
ii  gdb   7.12-6
pn  gir1.2-maliit-1.0 
pn  maliit-keyboard   
pn  olpc-powerd   
pn  sucrose   
pn  sugar-calculate-activity  
pn  sugar-etoys-activity  
pn  sugar-turtleart-activity  


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#872747: Please make gender choice non-binary

[martin f krafft]

Package: sugar-session
Version: 0.110.0-3
Severity: minor

Upon session initialisation, the user is asked about their gender,
where only male and female are provided as options. Would it be
possible to add at least a third option, or skip this altogether?

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

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

Versions of packages sugar-session depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gconf2   3.2.6-4+b1
pn  gir1.2-gconf-2.0 
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gtk-3.0   3.22.16-1
pn  gir1.2-gudev-1.0 
pn  gir1.2-nmgtk-1.0 
ii  gir1.2-pango-1.0 1.40.6-1
pn  gir1.2-upowerglib-1.0
pn  gir1.2-xkl-1.0   
ii  python   2.7.13-2
ii  python-cairo 1.8.8-2.2
ii  python-dbus  1.2.4-1+b2
pn  python-jarabe
pn  python-sugar3
pn  sugar-themes 

Versions of packages sugar-session recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.20-1
ii  dbus-x11 [dbus-session-bus]   1.10.20-1
ii  ethtool   1:4.8-1+b1
ii  fonts-dejavu-core 2.37-1
pn  gvfs  
ii  lsb-release   9.20161125
pn  mobile-broadband-provider-info
ii  modemmanager  1.6.8-1
pn  network-manager   
pn  sugar-browse-activity 
pn  sugar-chat-activity   
pn  sugar-imageviewer-activity
pn  sugar-jukebox-activity
pn  sugar-log-activity
pn  sugar-pippy-activity  
pn  sugar-read-activity   
pn  sugar-terminal-activity   
pn  sugar-write-activity  
pn  telepathy-salut   
ii  tzdata2017b-2
ii  upower0.99.4-4+b1

Versions of packages sugar-session suggests:
ii  gdb   7.12-6
pn  gir1.2-maliit-1.0 
pn  maliit-keyboard   
pn  olpc-powerd   
pn  sucrose   
pn  sugar-calculate-activity  
pn  sugar-etoys-activity  
pn  sugar-turtleart-activity  

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Job offer Munich/remote: decentralised authentication startup

[martin f krafft]

Good day,

We have a number of job openings related to a business providing
a decentralised solution to authentication in beautiful Munich,
Germany, though working remotely is a possibility.

While none of the jobs are directly related to Debian, I'd be
willing to bet that the cause of the project (decentralised
authentication) should align with the values of a significant number
of people here, so in case you are looking for a new challenge, here
are a couple ideas:

  https://keyp.io/jobs/

We're a relatively young startup currently negotiating a larger
investment round and hence looking to grow our team.

Our product is decentralised authentication, i.e. an authentication
framework leased to services, which allows these providers to
granularly specify n-factor authentication requirements. For us,
authentication goes beyond passwords and even 2FA, as our approach
is designed to handle pretty much *any* data or process that can be
verified in one way or another.

When interacting with a Keyp-enabled service provider, users fulfill
the authentication requirements through a slick mobile or browser
app, while specialised third-party providers handle the actual
verification. Trust in these providers is bestowed by the service
providers who are the ones caring about the authenticity of the data
they require. The user is the one who remains in control over what
to share with whom. And it's designed to work offline and with the
IoT in mind.¹

For full disclosure: I'm co-founder of this business. Please feel
free to ask me anything, or write to j...@keyp.io (reply-to set).

Looking forward to hearing from you!
Martin

¹) If I also mentioned blockchain now, then I'd win at buzzword
bingo. Though we are exploring one specific way in which the
blockchain could be of great utility to our mission.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#807427: sane-utils: Can not provide access to hplip scanner over network

[martin f krafft]

also sprach Brian Potkin <claremont...@gmail.com> [2017-08-11 00:40 +0200]:
> I fell into the trap of confusing a scanner on the network with a
> network scanner. It wouldn't be any consolation to you that, once
> I had my thinking straightened out, I reproduced the behaviour you
> described. Is avoiding a 3 second delay in 'lpstat -s' worth having
> this?

I don't think so, but the proposed solution would be to make this
configurable anyway, either through a config file option, or maybe
(easiest) through LIBSANE_HPAIO_LOCALONLY=[0/1] in the environment.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"when women love us, they forgive us everything, even our crimes;
 when they do not love us, they give us credit for nothing,
 not even our virtues."
   -- honoré de balzac


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#807427: sane-utils: Can not provide access to hplip scanner over network

[martin f krafft]

also sprach Brian Potkin <claremont...@gmail.com> [2017-08-11 00:40 +0200]:
> I fell into the trap of confusing a scanner on the network with a
> network scanner. It wouldn't be any consolation to you that, once
> I had my thinking straightened out, I reproduced the behaviour you
> described. Is avoiding a 3 second delay in 'lpstat -s' worth having
> this?

I don't think so, but the proposed solution would be to make this
configurable anyway, either through a config file option, or maybe
(easiest) through LIBSANE_HPAIO_LOCALONLY=[0/1] in the environment.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"when women love us, they forgive us everything, even our crimes;
 when they do not love us, they give us credit for nothing,
 not even our virtues."
   -- honoré de balzac


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#807427: sane-utils: Can not provide access to hplip scanner over network

[martin f krafft]

also sprach Brian Potkin <claremont...@gmail.com> [2017-08-09 19:08 +0200]:
> Thank you for doing this. As it turns out it seems our experiences are
> quite different.

Indeed, and I'm providing details from my setup below.

However, the reason it works for you and not for me is that your
scanners are connected with USB cables and thus considerdd local,
whereas my scanner has an IP address and is thus considered remote.
But local_only==1 is hardcoded…

>   On the sid server: an access list in saned.conf with only 192.168.7.20
>   in it. dll.conf is empty.

I have a stretch server giving access to 192.168.14.0/24. dll.conf
is empty.

>   On the client: net.conf has the server IP 192.168.7.66 and net is
>   uncommented in dll.conf.

My client runs sid, has the server's IP in net.conf, and has net
uncommented in dll.conf.

>   libsane and sane-utils on server and client.

Server:

ii  hplip  3.16.11+repack0- amd64HP Linux Printing 
and Imaging System (HPLIP)
ii  libsane:amd64  1.0.25-4.1   amd64API library for 
scanners
ii  libsane-common 1.0.25-4.1   all  API library for 
scanners -- documentation and supp
un  libsane-extras   (no description 
available)
ii  libsane-hpaio:amd643.16.11+repack0- amd64HP SANE backend 
for multi-function peripherals
ii  libsane-perl   0.05-2+b4amd64Perl bindings for 
the SANE (Scanner Access Now Eas
ii  sane   1.0.14-12amd64scanner graphical 
frontends
ii  sane-utils 1.0.25-4.1   amd64API library for 
scanners -- utilities


Client:

ii  libsane:amd64  1.0.25+git201509 amd64API library for 
scanners
ii  libsane-common 1.0.25+git201509 all  API library for 
scanners -- documentation and supp
un  libsane-extras   (no description 
available)
ii  libsane-hpaio:amd643.17.6+repack0-2 amd64HP SANE backend 
for multi-function peripherals
ii  libsane-perl   0.05-2+b4amd64Perl bindings for 
the SANE (Scanner Access Now Eas
ii  sane   1.0.14-12amd64scanner graphical 
frontends
ii  sane-utils 1.0.26~git201511 amd64API library fo

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"i hate vulgar realism in literature. the man who could call a spade
 a spade should be compelled to use one. it is the only thing he is
 fit for."
  -- oscar wilde


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#807427: sane-utils: Can not provide access to hplip scanner over network

[martin f krafft]

also sprach Brian Potkin <claremont...@gmail.com> [2017-08-09 19:08 +0200]:
> Thank you for doing this. As it turns out it seems our experiences are
> quite different.

Indeed, and I'm providing details from my setup below.

However, the reason it works for you and not for me is that your
scanners are connected with USB cables and thus considerdd local,
whereas my scanner has an IP address and is thus considered remote.
But local_only==1 is hardcoded…

>   On the sid server: an access list in saned.conf with only 192.168.7.20
>   in it. dll.conf is empty.

I have a stretch server giving access to 192.168.14.0/24. dll.conf
is empty.

>   On the client: net.conf has the server IP 192.168.7.66 and net is
>   uncommented in dll.conf.

My client runs sid, has the server's IP in net.conf, and has net
uncommented in dll.conf.

>   libsane and sane-utils on server and client.

Server:

ii  hplip  3.16.11+repack0- amd64HP Linux Printing 
and Imaging System (HPLIP)
ii  libsane:amd64  1.0.25-4.1   amd64API library for 
scanners
ii  libsane-common 1.0.25-4.1   all  API library for 
scanners -- documentation and supp
un  libsane-extras   (no description 
available)
ii  libsane-hpaio:amd643.16.11+repack0- amd64HP SANE backend 
for multi-function peripherals
ii  libsane-perl   0.05-2+b4amd64Perl bindings for 
the SANE (Scanner Access Now Eas
ii  sane   1.0.14-12amd64scanner graphical 
frontends
ii  sane-utils 1.0.25-4.1   amd64API library for 
scanners -- utilities


Client:

ii  libsane:amd64  1.0.25+git201509 amd64API library for 
scanners
ii  libsane-common 1.0.25+git201509 all  API library for 
scanners -- documentation and supp
un  libsane-extras   (no description 
available)
ii  libsane-hpaio:amd643.17.6+repack0-2 amd64HP SANE backend 
for multi-function peripherals
ii  libsane-perl   0.05-2+b4amd64Perl bindings for 
the SANE (Scanner Access Now Eas
ii  sane   1.0.14-12amd64scanner graphical 
frontends
ii  sane-utils 1.0.26~git201511 amd64API library fo

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"i hate vulgar realism in literature. the man who could call a spade
 a spade should be compelled to use one. it is the only thing he is
 fit for."
  -- oscar wilde


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#807427: sane-utils: Can not provide access to hplip scanner over network

[martin f krafft]

Hey Brian,

Thanks for looking into this and providing me the impetus to check
the situation out again.

I've installed 3.17.6+repack0-2 from testing on this jessie machine,
alongside sane 1.0.14-12, and while a local scanimage -L listing
produces:

  device `hpaio:/net/HP_LaserJet_3052?ip=192.168.14.30' is
  a Hewlett-Packard HP_LaserJet_3052 all-in-one

doing so remotely just gets "No scanners were identified." Yet, he
logs on the sane server indicate that the connection attempt was
authorized, and one local scanner found:

  systemd[1]: Started Scanner Service ([2001:xxx]:58988).
  saned[29780]: saned (AF-indep+IPv6+systemd) from sane-backends 1.0.25 
starting up
  saned[29780]: check_host: access by remote host: 2001:xxx
  saned[29780]: init: access granted to madduck@2001:xxx
  saned[29780]: saned exiting
  saned[29780]: [sanei_debug] Setting debug level of dll to 255.
  saned[29780]: [dll] sane_init: SANE dll backend version 1.0.13 from 
sane-backends 1.0.25
  saned[29780]: [dll] sane_init/read_dlld: attempting to open directory 
`/etc/sane.d/dll.d'
  saned[29780]: [dll] sane_init/read_dlld: using config directory 
`/etc/sane.d/dll.d'
  saned[29780]: [dll] sane_init/read_dlld: considering /etc/sane.d/dll.d/hplip
  saned[29780]: [dll] sane_init/read_config: reading dll.d/hplip
  saned[29780]: [dll] add_backend: adding backend `hpaio'
  saned[29780]: [dll] sane_init/read_dlld: done.
  saned[29780]: [dll] sane_init/read_config: reading dll.conf
  saned[29780]: [dll] sane_get_devices
  saned[29780]: [dll] load: searching backend `hpaio' in 
`/usr/lib/x86_64-linux-gnu/sane:/usr/lib/sane'
  saned[29780]: [dll] load: trying to load 
`/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1'
  saned[29780]: [dll] load: dlopen()ing 
`/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1'
  saned[29780]: [dll] init: initializing backend `hpaio'
  saned[29780]: [sanei_debug] Setting debug level of hpaio to 255.
  saned[29780]: [hpaio] sane_hpaio_init(): scan/sane/hpaio.c 323
  saned[29780]: [dll] init: backend `hpaio' is version 1.0.0
  saned[29780]: [hpaio] sane_hpaio_get_devices(local=1): scan/sane/hpaio.c 342
  saned[29780]: [dll] sane_get_devices: found 0 devices
  saned[29780]: saned exiting

Judging from the local=1 followed by "found 0 devices", I'd say the
problem continues to exist precisely as I described in #838212.
I might of course be very wrong…

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"wer ein warum hat, dem ist kein wie zu schwer."
 - friedrich nietzsche


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#807427: sane-utils: Can not provide access to hplip scanner over network

[martin f krafft]

Hey Brian,

Thanks for looking into this and providing me the impetus to check
the situation out again.

I've installed 3.17.6+repack0-2 from testing on this jessie machine,
alongside sane 1.0.14-12, and while a local scanimage -L listing
produces:

  device `hpaio:/net/HP_LaserJet_3052?ip=192.168.14.30' is
  a Hewlett-Packard HP_LaserJet_3052 all-in-one

doing so remotely just gets "No scanners were identified." Yet, he
logs on the sane server indicate that the connection attempt was
authorized, and one local scanner found:

  systemd[1]: Started Scanner Service ([2001:xxx]:58988).
  saned[29780]: saned (AF-indep+IPv6+systemd) from sane-backends 1.0.25 
starting up
  saned[29780]: check_host: access by remote host: 2001:xxx
  saned[29780]: init: access granted to madduck@2001:xxx
  saned[29780]: saned exiting
  saned[29780]: [sanei_debug] Setting debug level of dll to 255.
  saned[29780]: [dll] sane_init: SANE dll backend version 1.0.13 from 
sane-backends 1.0.25
  saned[29780]: [dll] sane_init/read_dlld: attempting to open directory 
`/etc/sane.d/dll.d'
  saned[29780]: [dll] sane_init/read_dlld: using config directory 
`/etc/sane.d/dll.d'
  saned[29780]: [dll] sane_init/read_dlld: considering /etc/sane.d/dll.d/hplip
  saned[29780]: [dll] sane_init/read_config: reading dll.d/hplip
  saned[29780]: [dll] add_backend: adding backend `hpaio'
  saned[29780]: [dll] sane_init/read_dlld: done.
  saned[29780]: [dll] sane_init/read_config: reading dll.conf
  saned[29780]: [dll] sane_get_devices
  saned[29780]: [dll] load: searching backend `hpaio' in 
`/usr/lib/x86_64-linux-gnu/sane:/usr/lib/sane'
  saned[29780]: [dll] load: trying to load 
`/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1'
  saned[29780]: [dll] load: dlopen()ing 
`/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1'
  saned[29780]: [dll] init: initializing backend `hpaio'
  saned[29780]: [sanei_debug] Setting debug level of hpaio to 255.
  saned[29780]: [hpaio] sane_hpaio_init(): scan/sane/hpaio.c 323
  saned[29780]: [dll] init: backend `hpaio' is version 1.0.0
  saned[29780]: [hpaio] sane_hpaio_get_devices(local=1): scan/sane/hpaio.c 342
  saned[29780]: [dll] sane_get_devices: found 0 devices
  saned[29780]: saned exiting

Judging from the local=1 followed by "found 0 devices", I'd say the
problem continues to exist precisely as I described in #838212.
I might of course be very wrong…

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"wer ein warum hat, dem ist kein wie zu schwer."
 - friedrich nietzsche


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#870463: lp no longer honours default printers

[martin f krafft]

Package: cups-client
Version: 2.2.4-3
Severity: normal
File: /usr/bin/lp

Possibly related to #867818, /usr/bin/lp no longer honours a default
printer configured:

  albatross:~/FOR_FILING% head -1 ~/.cups/lpoptions
  Default mfc9465cdn
  albatross:~/FOR_FILING% lp -P 30 2017-08-02-Scans.pdf
  lp: Error - no default destination available.
  albatross:~/FOR_FILING% lp -d mfc9465cdn -P 30 2017-08-02-Scans.pdf
  request id is mfc9465cdn-1785 (1 file(s))

Btw, the printers are now available in Libreoffice & Co. again, so
#867818 really did help, but maybe it's not all the way there yet.

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

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

Versions of packages cups-client depends on:
ii  adduser3.115
ii  cups-common2.2.4-3
ii  libc6  2.24-12
ii  libcups2   2.2.4-3
ii  libcupsimage2  2.2.4-3

cups-client recommends no packages.

Versions of packages cups-client suggests:
ii  cups   2.2.4-3
pn  cups-bsd   
ii  smbclient  2:4.6.5+dfsg-3
ii  xpp1.5-cvs20081009-3

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#870463: lp no longer honours default printers

[martin f krafft]

Package: cups-client
Version: 2.2.4-3
Severity: normal
File: /usr/bin/lp

Possibly related to #867818, /usr/bin/lp no longer honours a default
printer configured:

  albatross:~/FOR_FILING% head -1 ~/.cups/lpoptions
  Default mfc9465cdn
  albatross:~/FOR_FILING% lp -P 30 2017-08-02-Scans.pdf
  lp: Error - no default destination available.
  albatross:~/FOR_FILING% lp -d mfc9465cdn -P 30 2017-08-02-Scans.pdf
  request id is mfc9465cdn-1785 (1 file(s))

Btw, the printers are now available in Libreoffice & Co. again, so
#867818 really did help, but maybe it's not all the way there yet.

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

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

Versions of packages cups-client depends on:
ii  adduser3.115
ii  cups-common2.2.4-3
ii  libc6  2.24-12
ii  libcups2   2.2.4-3
ii  libcupsimage2  2.2.4-3

cups-client recommends no packages.

Versions of packages cups-client suggests:
ii  cups   2.2.4-3
pn  cups-bsd   
ii  smbclient  2:4.6.5+dfsg-3
ii  xpp1.5-cvs20081009-3

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#864788: (no subject)

[martin f krafft]

retitle 864788 Unable to control cache expiry for smartcards
severity 864788 important
tags 864788 security
thanks

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#864788: (no subject)

[martin f krafft]

retitle -1 Unable to control cache expiry for smartcards
severity -1 important
tags -1 security
thanks

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#868176: "deleted" yields skip, not warning

[martin f krafft]

Package: myrepos
Version: 1.20160123
Severity: normal

Despite the manpage saying:

  If "deleted" is set and its command returns true, then mr will
  treat the repository as deleted. It won't ever actually delete the
  repository, but it will warn if it sees the repository's
  directory.

this is not the behaviour exposed:

  % cat .config/myrepos/base-config.d/cleanup
  [$HOME/.a2ps]
  deleted = true
  % mr up 2>&1 | grep a2ps
  [nothing]
  % mr -v up 2>&1 | grep a2ps
  mr deleted test: running deleted test >>true<<
  mr update: skip /home/01/madduck/.a2ps/ skipped
  […]

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

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

myrepos depends on no packages.

Versions of packages myrepos recommends:
ii  libhtml-parser-perl  3.72-3
pn  libio-pty-easy-perl  
ii  libwww-perl  6.15-1
ii  perl 5.24.1-6

Versions of packages myrepos suggests:
ii  ack [ack-grep]2.18-2
pn  bzr   
ii  curl  7.52.1-5
pn  cvs   
pn  darcs 
pn  fossil
ii  git [git-core]1:2.13.2-3
pn  kdesdk-scripts
ii  liburi-perl   1.71-1
ii  mercurial 4.0-1
pn  subversion
pn  subversion-tools  
ii  vcsh  1.20151229-1

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#793381: Status?

[martin f krafft]

What's the status of this bug? In #682622 it's being suggested that
paths should be made relative to the location of the .mrconfig file.
While this works, it does break the use of $XDG_CONFIG_PATH, should
that point to an absolute path involving a symlink.

What's to speak against properly resolving the symlink chain?

Thanks,

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#864788: [pkg-gnupg-maint] Bug#864788: Bug#864788: cache TTL values ignored for smartcard PINs

[martin f krafft]

also sprach martin f krafft <madd...@debian.org> [2017-06-16 20:26 +0200]:
> I tried card-timeout 5 just now and even after 10 seconds, I can
> sign messages without a PIN just fine… multiple times. So either
> I am doing it wrong or it's doing it wrong ;)

For the record, I've now had card-timeout=5 (in combination with
very low TTL values) for two weeks and have not had to re-enter my
PIN one single time… that's not ok if you ask me…

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
if god is perfect, why did he create discontinuous functions?


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Managing the WoT with GPG

[martin f krafft]

also sprach Peter Lebbing  [2017-06-23 17:56 +0200]:
> There are two hard problems in computer science: Cache invalidation,
> naming things, and off-by-one errors.

I haven't heard that one in years. Lol. ;)

> Martin, I think --no-auto-check-trustdb and a cron job will
> already make it much more bearable, with the current state of
> things. That's what I'd suggest.

I've been doing that for a long time already, and yes, it mitigates
the issue a little bit. I still think that the interface doesn't
exactly invite people to invest time into the WoT, which directly
translates into lesser quality.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"auch der mutigste von uns hat nur selten den mut zu dem,
 was er eigentlich weiß."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Managing the WoT with GPG

[martin f krafft]

also sprach Werner Koch  [2017-06-22 19:02 +0200]:
> For a key listing this means computing it for every listed key.  And the
> majority of frontends first do a key listing and show the validity of
> the keys before you can encrypt something.

Obviously, one could work with caching here…

Running --check-trustdb in the background once a day is doable, for
sure.

I guess what I'd really like is a way to run --update-trustdb just
for a specific key, and a way to do that automatically when using
a key, e.g. to verify or encrypt to…

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"president thieu says he'll quit if he doesn't get more than 50% of
 the vote. in a democracy, that's not called quitting."
-- the washington post
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key corruption: duplicate signatures and usage flags

[martin f krafft]

also sprach Werner Koch  [2017-06-23 09:40 +0200]:
> Those flags are tracked in self-signatures.  When changing a flag
> a new self-signature is used.  This will be uploaded to the
> keyserver.  gpg uses the flags from the latest self-signature it
> has.

So how does this explain

  % export GNUPGHOME=$(mktemp -d)
  % gpg --recv-key 55C9882D999BBCC4
  % gpg --list-key 55C9882D999BBCC4 | grep '^pub'   # [SC]
  % gpg --edit-key 55C9882D999BBCC4 save
  % gpg --list-key 55C9882D999BBCC4 | grep '^pub'   # [C]

Are you saying that gnupg 2.1.18 added the self-signature in the
wrong place?

Thanks,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"i wish i hadn't slept all day, it's really lowered my productivity"
   -- robert mcqueen
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key corruption: duplicate signatures and usage flags

[martin f krafft]

also sprach MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> [2017-06-23 00:33 
+0200]:
> I didn't know you could remove a usage flag once the key was on the
> keyservers.

Well, it somehow seems to work, apart from the fact that gnupg first
needs to clean up the key (using --edit-key) after downloading the
modified version from the keyservers.

> And I thought GnuPG would automatically sign with a valid signing
> subkey if there was one.

It does this independently, yes.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"work consists of whatever a body is obliged to do.
 play consists of whatever a body is not obliged to do."
   -- mark twain
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Managing the WoT with GPG

[martin f krafft]

also sprach Peter Lebbing  [2017-06-22 15:46 +0200]:
> > As far as I understand, the parameters --marginals-needed and
> > --completes-needed can be used to define a maximum search depth D,
> > so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
> > envision it to
> 
> Don't you mean
> 
> >--max-cert-depth n
> >   Maximum depth of a certification chain (default is 5).
> 
> ? I don't see how --*-needed would limit the search depth, other than
> that for an actual keyset increasing them would effectively probably
> decrease the actual depth.

Yeah, that too.

> 1) Consider every key signature potentially valid. Construct the
>graph of signatures. Discard anything that is not rooted in an
>ultimately trusted key.

That sounds like a worthwhile optimisation, indeed.

> 3) Start at the ultimately trusted keys and consider each signature that
> corresponds to an edge going out of a valid key. Check signatures until
> full validity of a key is reached (or all signatures on a key have been
> checked). Stop checking then; it can't become more than fully valid by
> more signatures. The fact that a key has been added to the valid keys
> means you now have more edges going out from a valid key; keep repeating.

And so does this…

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"durch frauen werden die höhepunkte des lebens bereichert
 und die tiefpunkte vermehrt."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Managing the WoT with GPG

[martin f krafft]

also sprach Andrew Gallagher  [2017-06-21 15:57 +0200]:
> I have a quick and dirty tool here:
> https://github.com/andrewgdotcom/synctrust

Yeah, that'll do the job, except it blindly overwrites changes made
locally. It's unlikely this happens, but say I declared your key
trustworthy last night at home, forgot to run sync, and
not-trustworthy this morning at the office (sorry, this is just
a silly example…), and then ran sync, your key would be trustworthy
again.

On the other hand, it'd be totally possible to export ownertrust
prior to the import, and then fire up vimdiff or the like on the two
versions. Not exactly a great UID at all.

It'd be better if trustdb would be journalled using a mergeable
approach.

And then again, something like jetring is far beyond overkill for
day-to-day usage…

#SyncIsHard

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"convictions are more dangerous enemies of truth than lies."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Managing the WoT with GPG

[martin f krafft]

also sprach Neal H. Walfield  [2017-06-21 14:00 +0200]:
> It starts with the set of ultimately trusted keys.  But let's say
> that you start with key X, which is not ultimately trusted.  What
> should GnuPG do with the result?  Or, let's say that X is
> ultimately trusted and it decides that key Y is only marginally
> trusted, but Y would have been fully trusted if you started with
> all ultimately trusted keys. How do you intelligently merge that?

As far as I understand, the parameters --marginals-needed and
--completes-needed can be used to define a maximum search depth D,
so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
envision it to

  1. enumerate all keys reachable within D steps

  2. iterate all these keys

  3. backpropagate the trust/validity level towards 0xdeadbeef

  4. update the nodes touched by this walk in trustdb

  5. do this for every key when it changes

  6. do this for every key upon use, such that missing information
 can be interactively provided, and expired keys pruned
 just-in-time.

  7. --check-trustdb could still be used to do overall cleaning at
 regular intervals.

Given how the keygraph is essentially a singly-linked graph with
keys containing pointers to other keys that signed them, while there
exists no such information implicitly about all the keys that have
been signed *by* a given key (e.g. one that's ultimately trusted),
the approach I've sketched actually seems more intuitive, don't you
think?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"here i was all convinced that if i sleep all day, bug counts go
 down, and if I work all day, they go up, so much for that theory."
   -- lars wirzenius
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Key corruption: duplicate signatures and usage flags

[martin f krafft]

Hey Justus, thanks for writing in. Here are the answers you wanted:

> gpg --version please?

2.1.18

> > So far, so good. Do note the [SC] usage flags.
> 
> What are the capabilities of your primary key supposed to be?

There were [SC] when I created it, but I've recently changed to
a signing subkey and removed the flag from the primary key.

> >   key 55C9882D999BBCC4:
> >   24 duplicate signatures removed
> >
> > That's a bit weird. Where do these come from?
> 
> Not sure, but anyone can append stuff to your key on the keyservers.
> Maybe some faulty software reordered the packages and uploaded it?

Yeah could be. And while there's no way this can be fixed, it also
doesn't really harm, does it?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"getting a scsi chain working is perfectly simple if you remember that
 there must be exactly three terminations: one on one end of the
 cable, one on the far end, and the goat, terminated over the scsi
 chain with a silver-handled knife whilst burning *black* candles."
 -- anthony deboer
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Managing the WoT with GPG

[martin f krafft]

also sprach Neal H. Walfield  [2017-06-21 11:53 +0200]:
> > 3. Is there a way to run --check-trustdb or --update-trustdb not
> >over the entire key graph, but only traversing to a certain depth
> >starting from a specific key? Then I could tell parcimonie to run
> >--check-trustdb for every key it imports, or have mutt run
> >--update-trustdb for every key I want to use. This would
> >iteratively achieve the job with the benefit that no cycles would
> >be wasted processing trust for keys I never use. I understand
> >--edit-key can be used to change the ownertrust, but I don't
> >think it recomputes the WoT on change, does it?
> > 
> >If there's no way to do this yet, would this be a useful addition
> >to the UI, assuming it's technically possible?
> 
> This isn't easy given the current implementation: GnuPG doesn't store
> the graph, but traverses the graph and only saves whether a particular
> key is trusted.

It's gotta start somewhere, though, right? Can't it pick the leaf
where to start?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
dies ist eine manuell generierte email. sie beinhaltet
tippfehler und ist auch ohne großbuchstaben gültig.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Key corruption: duplicate signatures and usage flags

[martin f krafft]

Hey,

My key on the keyservers is 0x55C9882D999BBCC4. If I download this
to a fresh keyring, I get some weird behaviours:

  % alias gpg='gpg --homedir=.'
  % gpg --recv-key 0x55C9882D999BBCC4
  gpg: keybox '/home/ssd/madduck/.tmp/cdt.p0R8ly/pubring.kbx' created
  gpg: /home/ssd/madduck/.tmp/cdt.p0R8ly/trustdb.gpg: trustdb created
  gpg: key 55C9882D999BBCC4: public key "Martin F. Krafft 
<m...@martin-krafft.net>" imported
  gpg: no ultimately trusted keys found
  gpg: Total number processed: 1
  gpg:   imported: 1

  % gpg --list-keys !$
  gpg --list-keys 0x55C9882D999BBCC4
  pub   rsa4096 2009-07-06 [SC] [expires: 2020-02-01]
2CCB26BC5C49BC221F20794255C9882D999BBCC4
  uid   [ unknown] Martin F. Krafft <m...@martin-krafft.net>
  uid       [ unknown] Martin F. Krafft <madd...@madduck.net>
  uid       [ unknown] Martin F. Krafft (Debian) <madd...@debian.org>
  uid   [ unknown] [jpeg image of size 2160]
  sub   rsa4096 2016-07-01 [E] [expires: 2018-02-01]
  sub   rsa4096 2016-12-01 [S] [expires: 2018-02-01]
  sub   rsa4096 2016-12-01 [A] [expires: 2018-02-01]

So far, so good. Do note the [SC] usage flags.

And then check this out:

  % gpg --edit-key 0x55C9882D999BBCC4
  gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

  uid  Martin F. Krafft <madd...@madduck.net>
  sig!355C9882D999BBCC4 2009-07-06 never   [self-signature]
  sig!355C9882D999BBCC4 2017-06-07 never   [self-signature]*
  [expires: 2020-02-01 11:20:11]
  sig!355C9882D999BBCC4 2009-07-06 never   [self-signature]
x-hkp://pool.sks-keyservers.net

  […]

  sub  AD18B605905834CC
  sig!P55C9882D999BBCC4 2015-07-01 never   [self-signature]*
Signature policy: 
http://martin-krafft.net/gpg/cert-policy/55c9882d999bbcc4/201412051354?sha512sum=a5f417ebe563ed63cc3bbc4b14da4983e30d8ada7b2ba94b6de5e7a74bee6ab55c6ca307e163c33a6bf242e8ce4ca5fe99a271dd3b41626d3b4a10203a5c7225
  [expires: 2010-08-07 08:37:18]

  […]

  key 55C9882D999BBCC4:
  24 duplicate signatures removed

That's a bit weird. Where do these come from?

But there's more: now the usage flag of the primary key has been
changed to just 'C' (which is what I uploaded), and …

  pub  rsa4096/55C9882D999BBCC4
  created: 2009-07-06  expires: 2020-02-01  usage: C
  trust: unknown   validity: unknown
  […]

… a subsequent save spews a weird list of "Preferred keyserver:"
text to stdout, but now the usage flag of the primary key is also
just [C] in the --list-keys output:

  gpg> save
  Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred 
keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: %

  % gpg --list-keys 0x55C9882D999BBCC4
  pub   rsa4096 2009-07-06 [C] [expires: 2020-02-01]
2CCB26BC5C49BC221F20794255C9882D999BBCC4
  […]

Do you have any idea what might be going on here? Is this a problem,
or just cosmetic? Is it fixable? How?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"life moves pretty fast. if you don't stop and look around once in
 a while, you could miss it."
 -- ferris bueller
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Managing the WoT with GPG

[martin f krafft]

Hello,

I've spent some time trying to figure out how to make actual use of
the web-of-trust (the "pgp" trust-model), and I am turning to this
list for some advice, related to a couple of questions:

1. My public keyring has several thousand keys and "weighs" almost
   500Mb. Every couple of runs, I'm told to run --check-trustdb,
   which takes several minutes to complete, then tells me that the
   next run will be in like 2 weeks, but three operations later, I'm
   again being asked to run --check-trustdb. The funny thing is that
   these operations are just message signing and authentication,
   sometimes decryption. However, parcimonie is running in the
   background, updating the keyring one key at a time. Is that the
   reason? If yes, is there any way to mitigate this? I've sketched
   out an idea under (3.) below, but maybe there's another way…?

2. I've also tried running --update-trustdb, but it seems that this
   process is *endless*. I have no idea how many keys remain, and
   I also got the impression that I keep seeing keys I already
   processed. How do you approach this? Or does everyone just use
   tofu these days?

3. Is there a way to run --check-trustdb or --update-trustdb not
   over the entire key graph, but only traversing to a certain depth
   starting from a specific key? Then I could tell parcimonie to run
   --check-trustdb for every key it imports, or have mutt run
   --update-trustdb for every key I want to use. This would
   iteratively achieve the job with the benefit that no cycles would
   be wasted processing trust for keys I never use. I understand
   --edit-key can be used to change the ownertrust, but I don't
   think it recomputes the WoT on change, does it?

   If there's no way to do this yet, would this be a useful addition
   to the UI, assuming it's technically possible?

4. Is there a tool to visualise or explain the computed validity of
   a key? I.e. one saying that e.g. Werner's key is valid because
   Daniel signed it, and I fully trust Daniel? There's wotsap, but
   I want to analyse my own keyring, not a .wot file…

5. Has anyone come up with a smart way to keep pubring/trustdb
   synchronised between multiple workstations?

Thanks for any insights!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
darwinism is nothing without enough dead bodies.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Bug#864788: [pkg-gnupg-maint] Bug#864788: Bug#864788: cache TTL values ignored for smartcard PINs

[martin f krafft]

also sprach Werner Koch <w...@gnupg.org> [2017-06-15 21:40 +0200]:
> A workaround is to force a reset of the card by putting
> 
>   card-timeout N
> 
> in scdaemon.conf which shuts down the card after N seconds.  Well, as of
> now N is just a binary flag to tell sdaemon to shutdown the card at the
> next timer tick; thus immediately after an operation.

I tried card-timeout 5 just now and even after 10 seconds, I can
sign messages without a PIN just fine… multiple times. So either
I am doing it wrong or it's doing it wrong ;)

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
in seattle, washington, it is illegal to carry a concealed weapon that
is over six feet in length.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#864788: [pkg-gnupg-maint] Bug#864788: Bug#864788: cache TTL values ignored for smartcard PINs

[martin f krafft]

also sprach Daniel Kahn Gillmor <d...@fifthhorseman.net> [2017-06-16 02:44 
+0200]:
> Does it make sense to keep this architectural parallel clean, when it
> makes the user's mental model more complex?  or would it make sense to
> try to map the simpler mental model to the underlying architecture, and
> have gpg-agent forward its configuration to the smartcard via scdaemon?
> 
> Particularly when the user's configuration says "be more conservative
> about caching" it seems unfriendly to ignore that directive when we know
> that we could (since the scdaemon access is filtered through gpg-agent
> itself).

I completely concur. IMHO, at least the max-ttl setting should be
imposed as card-timeout (it it worked…)

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"when a gentoo admin tells me that the KISS principle is good for
 'busy sysadmins', and that it's not an evolutionary step backwards,
 i wonder whether their tape is already running backwards."


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#864788: cache TTL values ignored for smartcard PINs

[martin f krafft]

also sprach Teemu Likonen <tliko...@iki.fi> [2017-06-14 22:48 +0200]:
> That's because the OpenPGP card (Yubikey) itself goes to authenticated
> mode and don't require the PIN anymore.

If that's the case — thanks for putting it so concisely — then why
does killing gpg-agent mean having to enter a PIN the next time
around? 

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
the only real advantage to punk music is
that nobody can whistle it.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#864788: cache TTL values ignored for smartcard PINs

[martin f krafft]

0E 00
2017-06-14 21:37:20 scdaemon DBG:  response: sw=61FF  datalen=254
2017-06-14 21:37:20 scdaemon DBG: apdu_send_simple(0): 255 more bytes available
2017-06-14 21:37:20 scdaemon DBG:  raw apdu: 00 C0 00 00 FF
2017-06-14 21:37:20 scdaemon DBG:  more: sw=6103  datalen=255
2017-06-14 21:37:20 scdaemon DBG: apdu_send_simple(0): 3 more bytes available
2017-06-14 21:37:20 scdaemon DBG:  raw apdu: 00 C0 00 00 03
2017-06-14 21:37:20 scdaemon DBG:  more: sw=9000  datalen=3
2017-06-14 21:37:20 scdaemon DBG:   dump:  3A B7 46 88 77 04 91 F6 A5 05 5E 
48 40 E6 F7 C8 DA 70 0B 2F CC FC 32 A9 4F 48 FB D2 D2 C2 67 4C C3 C1 FC 90 5C 
CD 6D 15 76 FF 20 B6 EB 26 A5 9F 0F 2A 93 BF B2 2E 7A B8 36 D7 42 C5 0B E2 11 
5E D8 A9 80 8E 64 0A FB 8A E8 71 C8 94 32 3E 6E B6 3F D5 F1 E3 8E 36 28 4A 38 
38 A3 E8 0F 86 9B 55 5D 9A F5 27 A0 67 25 1F BB 36 56 BE C0 EA C7 69 DE B6 B8 
79 BE 66 81 A1 F6 7C B9 29 D7 65 7B 8A C5 B5 A5 76 E1 10 C2 CB 64 DA 6C 48 AF 
F8 F6 DA 2E 93 DB 5B 01 EA 20 E6 43 9B CA 1C 02 23 2C BC 64 E7 77 7D 18 9C BE 
38 F1 58 FE DA EF 95 C8 28 4A 51 03 D5 A4 FF 31 E0 74 C7 78 FE 21 B6 14 8A 2A 
86 CC CB 41 91 F5 B8 A0 3C C7 4C B1 66 B7 96 18 70 54 BF C4 DB 08 52 B5 B9 BF 
D4 19 DA 6A 7C 5E DB 03 7C E0 3E C6 53 DC F5 4F 12 67 9D 70 CE 1C 11 DD 3E C6 
C5 57 36 65 3B 95 23 4B 26 9C 8C E8 53 E4 42 8E 1B 42 9D 04 D7 9A A6 C1 49 5B 
F4 76 F5 FA 97 A5 07 DB 58 04 14 8E 0B 3F 2D A1 98 3F 02 C3 D0 A1 2D 68 38 7B 
FE 50 51 79 7B 4F 23 E6 5B 8D 6B 07 DF 12 12 89 08 5F B8 E5 56 51 79 6B 31 AC 
6A AD 49 1E 21 66 43 B1 C5 57 08 3F E6 ED 83 58 BC B6 75 19 FE E6 93 A7 C1 3B 
3C A6 A4 BE DF 5E EE 4D 41 7B 0F 69 78 BF 41 65 32 E6 20 18 AE 7E 83 C3 2B 67 
2F 6F 8F B9 FB B1 78 48 27 81 1F C1 1F 59 51 AD 80 32 74 F2 2D 4B 50 96 77 42 
08 AC F1 CC 2E 4D 93 84 C6 05 CE 9B 5A C7 66 81 1F 37 9D 8C 08 4F BE 36 C8 A9 
C1 EC 98 58 2E F4 0C C6 31 D9 34 EC 57 1D 5B 2F 12 2E F0 CA F5 56 06 71 A2 26 
95 A0 A8 88 69 87 E5 A6 7D AD EE 7C B9 34 E4 85 77 5B 02 24 34 74 68 C2 FD 3C 
A9 C0 B5 93 96 CB 20 F0 31 82 C9 E9 99 E2 3B 1F 62 B4 50 02 E7 6D CD 7D 95 93 
E3 27 8E 08 2F 21 C9
2017-06-14 21:37:20 scdaemon operation sign result: Success
2017-06-14 21:37:20 scdaemon DBG: chan_7 -> [ 44 20 3a b7 46 88 77 04 91 f6 a5 
05 5e 48 40 e6 ...(502 byte(s) skipped) ]
2017-06-14 21:37:20 scdaemon DBG: enter: apdu_get_status: slot=0 hang=0
2017-06-14 21:37:20 scdaemon DBG: chan_7 -> OK
2017-06-14 21:37:20 scdaemon DBG: leave: apdu_get_status => sw=0x0 status=7
2017-06-14 21:37:20 scdaemon DBG: chan_7 <- RESTART
2017-06-14 21:37:20 scdaemon DBG: chan_7 -> OK

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

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

Versions of packages gnupg-agent depends on:
ii  libassuan02.4.3-2
ii  libc6 2.24-11
ii  libgcrypt20   1.7.6-1
ii  libgpg-error0 1.26-2
ii  libnpth0  1.3-1
ii  libreadline7  7.0-3
ii  pinentry-gtk2 [pinentry]  1.0.0-2

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.18-8
ii  gpgsm  2.1.18-8

Versions of packages gnupg-agent suggests:
ii  dbus-user-session  1.10.18-1
ii  libpam-systemd 232-24
pn  pinentry-gnome3
ii  scdaemon   2.1.18-8

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#864308: Manpage without command

[martin f krafft]

Package: libifd-cyberjack6
Version: 3.99.5final.sp09-1.1
Severity: normal

there's a cyberjack(8) manpage, but no such command installed.

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

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

Versions of packages libifd-cyberjack6 depends on:
ii  libc6 2.24-11
ii  libgcc1   1:6.3.0-18
ii  libstdc++66.3.0-18
ii  libusb-1.0-0  2:1.0.21-1
ii  pcscd 1.8.21-1

libifd-cyberjack6 recommends no packages.

Versions of packages libifd-cyberjack6 suggests:
ii  pcsc-tools  1.5.2-1

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#761658: urgency of a fix before stretch

[martin f krafft]

also sprach Norbert Preining <norb...@preining.info> [2017-06-03 00:12 +0200]:
> Then how are you planning to deal with this serious bug after
> years of inactivity?

Sounds like it might need ctte attention.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#761658: urgency of a fix before stretch

[martin f krafft]

also sprach Norbert Preining <norb...@preining.info> [2017-06-03 00:12 +0200]:
> Then how are you planning to deal with this serious bug after
> years of inactivity?

Sounds like it might need ctte attention.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#761658: urgency of a fix before stretch

[martin f krafft]

also sprach Norbert Preining <norb...@preining.info> [2017-06-03 00:12 +0200]:
> Then how are you planning to deal with this serious bug after
> years of inactivity?

Sounds like it might need ctte attention.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

[Pkg-mozext-maintainers] Bug#863947: Does not work with FF 5x

[martin f krafft]

Package: xul-ext-pentadactyl
Version: 1.2~r20151231-1
Severity: normal

The addon works with FF ESR 45 but not with FF 52 or 53, and
upstream doesn't seem to care.

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

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

Versions of packages xul-ext-pentadactyl depends on:
ii  iceweasel  45.9.0esr-1

xul-ext-pentadactyl recommends no packages.

xul-ext-pentadactyl suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Pkg-mozext-maintainers mailing list
Pkg-mozext-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mozext-maintainers

Bug#863947: Does not work with FF 5x

[martin f krafft]

Package: xul-ext-pentadactyl
Version: 1.2~r20151231-1
Severity: normal

The addon works with FF ESR 45 but not with FF 52 or 53, and
upstream doesn't seem to care.

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

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

Versions of packages xul-ext-pentadactyl depends on:
ii  iceweasel  45.9.0esr-1

xul-ext-pentadactyl recommends no packages.

xul-ext-pentadactyl suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

[Debconf-team] Stepping away from DC17 orga

[martin f krafft]

Dear team,

Recent events around dc-orga have made me realise that I cannot effectively
help DebConf17 orga anymore. As I do not wish to stand in the way, I am taking
a break until after DC17.

Good luck and strength as you enter the final stretch towards DC17.
See/talk to you in Montreal, or before, or after.

-- 
 .''`.   martin f. krafft <madd...@debconf.org> @martinkrafft
: :'  :  DebConf orga team
`. `'`
  `-  DebConf17 Montreal, CA: https://wiki.debconf.org/wiki/DebConf17
  DebConf18 Hsinchu, Taiwan: https://wiki.debconf.org/wiki/DebConf18


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team

Bug#863091: pelican-themes: cannot manage themes in /usr

[martin f krafft]

Package: pelican
Version: 3.7.1-1
Severity: normal

% pelican-themes -i pelican-themes/bluegrasshopper/
Cannot copy `pelican-themes/bluegrasshopper/' to 
`/usr/lib/python2.7/dist-packages/pelican/themes/bluegrasshopper':
[Errno 13] Permission denied: 
'/usr/lib/python2.7/dist-packages/pelican/themes/bluegrasshopper'

When installed as distro package, arguably the themes should be
managed under /var/lib or in the project root.

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

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

Versions of packages pelican depends on:
ii  libpython2.7-stdlib [python-argparse]  2.7.13-2
ii  python 2.7.13-2
ii  python-blinker 1.3.dfsg2-1
ii  python-dateutil2.5.3-2
ii  python-docutils0.13.1+dfsg-2
ii  python-feedgenerator   1.9-1
ii  python-jinja2  2.9.5-1
ii  python-markdown2.6.8-1
ii  python-pkg-resources   33.1.1-1
ii  python-pygments2.2.0+dfsg-1
ii  python-six 1.10.0-4
ii  python-tz  2016.7-0.3
ii  python-unidecode   0.04.19-1
pn  python:any 

pelican recommends no packages.

Versions of packages pelican suggests:
pn  pandoc   
pn  pelican-doc  
ii  python-bs4   4.5.3-1

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#863031: RM: nikola/7.6.4-1

[martin f krafft]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

The current version in stable is almost 2 years old. Bug#801796 has
been tracking the requests for new versions to be packaged. However,
the maintainer hasn't engaged. Upstream co-maintainer Chris Warrick
has made it clear in #801796 that they'd rather not have nikola in
Debian, than an ancient version that annoys people and causes them
spurious bug reports.

Given how nobody has put in any work on nikola in almost 2 years,
I think we should have the decency to remove the package from
stretch and sid before the release.

nikola has no reverse dependencies, so…

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

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


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#863031: RM: nikola/7.6.4-1

[martin f krafft]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

The current version in stable is almost 2 years old. Bug#801796 has
been tracking the requests for new versions to be packaged. However,
the maintainer hasn't engaged. Upstream co-maintainer Chris Warrick
has made it clear in #801796 that they'd rather not have nikola in
Debian, than an ancient version that annoys people and causes them
spurious bug reports.

Given how nobody has put in any work on nikola in almost 2 years,
I think we should have the decency to remove the package from
stretch and sid before the release.

nikola has no reverse dependencies, so…

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

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


-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#602486: closed by Jeff <jf...@posteo.net> ()

[martin f krafft]

also sprach Debian Bug Tracking System <ow...@bugs.debian.org> [2017-05-18 
19:15 +0200]:
> Cannot reproduce

The problem is related to the image compression algorithm. Ever
since I switched to PNG from Automatic/LZW, the problem hasn't
occured again.

-- 
 .''`.   martin f. krafft <madduck@d.o> @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: [Debconf-team] Fwd: Re: Revision of DebConf CoC

[martin f krafft]

also sprach martin f krafft <madd...@debconf.org> [2017-05-15 15:57 +0200]:
> I think you are referring to the currently valid CoC:
> 
>   https://debconf.org/codeofconduct.shtml

Ftr, since there's some confusion… this is the current CoC. The
original proposal is available here:

  https://storm.debian.net/shared/RSXPZEg8vWpe_XZ73ZCh6bcWuNT8c_Q9uNsGc6Lujrj

-- 
 .''`.   martin f. krafft <madd...@debconf.org> @martinkrafft
: :'  :  DebConf orga team
`. `'`
  `-  DebConf17 Montreal, CA: https://wiki.debconf.org/wiki/DebConf17
  DebConf18 Hsinchu, Taiwan: https://wiki.debconf.org/wiki/DebConf18


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team

Re: [Debconf-team] Fwd: Re: Revision of DebConf CoC

[martin f krafft]

also sprach Giacomo Catenazzi <c...@debian.org> [2017-05-15 15:37 +0200]:
> I also don't like such list. First, who will enforce it? DPL?
> Anti-harassment or organizers?

This — incidence response — is in part what we have to define.
Someone needs to have the power to enforce the rules, attendees need
to display their consent to this upon registration, and there really
ought to be well-defined processes in place *before* something
happens.

> But the main reason: the list is very weak and it seems to be done
> from harasser point of view.  The ban is also just temporary.

It *is* written *to* the potential harasser, yes, but maybe that can
and should be improved.

> It seems we say: "harassment could happens, don't do it again".
> Just an warning (#3), apologies (#1) or promise to stop (#2).

I think you are referring to the currently valid CoC:

  https://debconf.org/codeofconduct.shtml

Yes, that is weak, and this was precisely one of the motivations to
rework this.

The current list shows that only the first two of six possible
consequences are temporary:

  1. immediate ban from the venue for the remainder of the day, and
 possibly the next day;

  2. immediate ban from the rest of the conference;

  3. immediate ban from the rest of the conference, and all future
 conferences;

  4. immediate ban from the Debian Project;

  5. public statement about the incident by the conference
 organisers;

  6. report of the incident to the appropriate authorities.

-- 
 .''`.   martin f. krafft <madd...@debconf.org> @martinkrafft
: :'  :  DebConf orga team
`. `'`
  `-  DebConf17 Montreal, CA: https://wiki.debconf.org/wiki/DebConf17
  DebConf18 Hsinchu, Taiwan: https://wiki.debconf.org/wiki/DebConf18


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team

Re: [Debconf-team] Revision of DebConf CoC

[martin f krafft]

also sprach Laura Arjona Reina <larj...@debian.org> [2017-05-15 15:22 +0200]:
> The reason I said in my first mail:
> 
> "The third paragraph, about the measures that can be taken, I need
> to think about it a little bit more."

I am sorry, I missed that.

> And after thinking more, and cate's comments, I arrived to more
> doubts than clear proposals: I'm not sure not only the measures,
> but who is in charge of enforce them.

Indeed. But these are questions some of us think should really be
answered, and that's the direction that the initial proposal tried
to go. It isn't complete in that sense, but it took a step in the
direction of addressing those important points.

-- 
 .''`.   martin f. krafft <madd...@debconf.org> @martinkrafft
: :'  :  DebConf orga team
`. `'`
  `-  DebConf17 Montreal, CA: https://wiki.debconf.org/wiki/DebConf17
  DebConf18 Hsinchu, Taiwan: https://wiki.debconf.org/wiki/DebConf18


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team

Re: [Debconf-team] Revision of DebConf CoC

[martin f krafft]

Dear Laura,

Thanks for your hard work on this.

One thing I noticed is that in 6.7 there's the phrase "dismissal
from the conference". However, this is not mentioned beforehand and
even though I am sure people can imagine what this means, it does
seem a bit "out of the blue". Maybe just to me…

The original proposal listed a number of potential consequences to
offences, among other more concrete incidence response processes.

What's the reason you didn't include those in your version(s)?

-- 
 .''`.   martin f. krafft <madd...@debconf.org> @martinkrafft
: :'  :  DebConf orga team
`. `'`
  `-  DebConf17 Montreal, CA: https://wiki.debconf.org/wiki/DebConf17
  DebConf18 Hsinchu, Taiwan: https://wiki.debconf.org/wiki/DebConf18


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team