Bug#930176: dh-golang: support cross building go packages

[Helmut Grohne]

On Fri, Jun 28, 2019 at 09:12:33PM +0100, Michael Hudson-Doyle wrote:
> On Fri, 7 Jun 2019 at 21:33, Helmut Grohne  wrote:
> > If you upload a dh-golang with these changes, suddenly those go packages
> > that don't have any library dependencies will become cross satisfiable
> > (due to the Multi-Arch: foreign marking).  However their dependency on
> > golang-any will use the host architecture go, which cannot be run. We'll
> > have to somehow figure out what to do about this. I don't have an answer
> > yet.
> >
> 
> I don't know what to do here either. On the one hand, it's simple (at least
> for golang-go): we want to install the build go, because all go compilers
> are capable of cross compilation. How is this handled for the C compiler?

Difficult. The first issue is that we actually have at least two major C
compilers (gcc and clang). The majority of the archive uses gcc. gcc has
target-specific packages. We append a target to the binary package name
and get something like gcc-8-aarch64-linux-gnu. Thus far, this works for
many combinations but native building. There is work in progress to also
provide these names for native builds. The build-essential package
ensures that gcc is installed. For the purpose of cross building this
means that both a build gcc and a host gcc are present. No packages have
to issue any dependency here. Some packages want a versioned dependency
on gcc and we plan to support this using a special "gcc-for-host"
package. In any case, this is much different to go, because you select
the target by using a different compiler binary.

Then there is clang. Few packages use clang and we haven't done much
about it yet. It's in the same position as go as it also allows
supplying the target as a command line parameter. It's not presently
marked M-A:foreign and packages that depend on clang generally don't
cross build in Debian at present.

So go might just be the pioneer in this field. I don't have a good
intuition yet, how this should be solved. I therefore prefer
experimentation. Doing so becomes easier when the obvious bits (i.e.
this patch) are merged. For this reason, I suggest to sit back and wait
for buster to release, then upload the patch and observe its effects.
The experimentation approach involves cross building a package that is
slightly out of reach and using hacks to make it barely work. Then
filter the "obvious" and upstreamable bits and submit them as patches
(e.g. this one).  Eventually, everything becomes obvious (that's my
theory) and cross building will work.

I fear that the bigger problem than the go compiler will be go
libraries. These are currently arch:all and susceptible to the
Multi-Arch interpreter problem[1]. There are two estimators[2]. Mine
only finds 13 go packages, because it does not consider Build-Depends,
but josch's has numbers around 300. Again, we can learn from another
ecosystem: rust. Rust is effectively using the suggested workaround by
having converted all of their libraries from Arch:all to Arch:any
M-A:same for the sake of transporting dependencies. My gut feeling is
that we'll have to do the same for go if cross building is to be a
thing. It would be great if you could familiarize yourself with this
part, because my expectation is that it will require a lot of churn.

Helmut

[1] https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges
[2] https://people.debian.org/~helmutg/multiarch_interpreter.html
https://bootstrap.debian.net/ma_interpreter.html

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[andreimpopescu]

On Vi, 28 iun 19, 14:46:15, Baptiste BEAUPLAT wrote:
> On 6/28/19 2:39 PM, Michael Biebl wrote:
> 
> > Would be good to know how Baptiste is setting up those devices. If he is
> > doing it manually via some scripting of low level tool or uses a higher
> > level network management tool
> > Fwiw, with "ip link add dummy0 type dummy" (or "ip link add bond0 type
> > bond") I was e.g. able to create such a device manually as well.
> > I wonder whether such an approach isn't better then statically setting
> > the number of devices via a kernel module option.
> 
> My original setup was:
> 
> echo "dummy" > /etc/modules
> 
> cat << EOF >> /etc/network/interfaces
> auto dummy0
> iface dummy0 inet static
> address 192.168.64.1
> netmask 24
> EOF
> 
> The interface would pop up configured at boot time (by ifup). Then, I
> had services binding on 192.168.64.1.

A (quick) look at interfaces(5) doesn't reveal any specific method to 
create dummy or bond interfaces.

In order to keep things within one configuration file it would make 
sense to use a pre-up with ip commands as suggested above.

Would this work *without* overriding the systemd.conf file?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#810257: virtualbox-qt: Keyboard capture doesn't

[Nikos Voutsinas]

Package: virtualbox
Version: 6.0.8-dfsg-7
Followup-For: Bug #810257

Dear Maintainer,

To reproduce:

1. On the Host Machine configure via the Gnome Settings the F1 keyboard
Shortcut to launch e.g. the terminal-emulator
2. On the Guest Machine configure via the Gnome Setting both F1 and F2
keyboard Shortcuts to launch the terminal-emulator
3. On the Guest Machine press the F1 key. That will bring the terminal
of the Host Machine.
4. On the Guest Machine press the F2 key. That will bring the terminal
of the Guest Machine 

Expected outcome: Both F1 and F2 on the Guest Machine are expected to bring the 
terminal emulator of the Guest Machine assuming that the Auto captur keyboard 
setting is turned on.


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.64.0-4
ii  libdevmapper1.02.12:1.02.155-3
ii  libgcc1   1:8.3.0-6
ii  libgl11.1.0-1
ii  libgsoap-2.8.75   2.8.75-1
ii  libopus0  1.3-1
ii  libpng16-16   1.6.36-6
ii  libpython3.7  3.7.3-2
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5opengl5 5.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5x11extras5  5.11.3-2
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libssl1.1 1.1.1c-1
ii  libstdc++68.3.0-6
ii  libvncserver1 0.9.11+dfsg-1.3
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libxcursor1   1:1.1.15-2
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  python3   3.7.3-1
ii  python3.7 3.7.3-2
ii  virtualbox-dkms [virtualbox-modules]  6.0.8-dfsg-7
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages virtualbox recommends:
ii  libxcb11.13.1-2
ii  virtualbox-qt  6.0.8-dfsg-7

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  6.0.8-1

-- no debconf information

Bug#928300: secure boot via removable media path unavailable

[Chris Nospam]

Dear Steve,

I know that this bug is not closed yet, but maybe the following is of interest 
for you.

I noticed your report of bug #930531 which was recently fixed in grub2 version 
2.02+dfsg1-19. Thus, I decided to give secure boot another try on my Intel 
DH77KC board. Meanwhile grub2 2.02+dfsg1-20 was installed on my system.
So what I did is
$ apt-get install shim-signed grub-efi-amd64-signed
(and automatically all deendencies). Then, to be sure,
$ update-grub2
$ dpkg-reconfigure grub-efi-amd64
of course with force_efi_extra_removable set to/left on true.
$ update-grub2
$ shutdown -r now
Then I turned secure-boot on within the mainboard's UEFI Firmware. However, the 
system then won't boot and shows an error message about security violations. 
Pretty the same as with my first tries, which led to the initial posting. (A 
Windows media can be booted in secure mode.)

Chris

Bug#931243: libvirt0: does not work under cgroup v2 (and rtkit)

[Ryutaroh Matsumoto]

Package: libvirt0
Version: 5.0.0-4
Severity: important
Tags: patch upstream

Dear Maintainer,

* libvirt0 tries to add "cpu" controller under the cgroup v2
  (a.k.a. unified cgroup hierarchy), which can be enabled by
  "systemd.unified_cgroup_hierarchy=1" boot option in /etc/default/grub

* The cpu controller cannot be enabled if there exists a process
  with the realtime priority, as stated
WARNING: cgroup2 doesn't yet support control of realtime processes and
the cpu controller can only be enabled when all RT processes are in
the root cgroup.  Be aware that system management software may already
have placed RT processes into nonroot cgroups during the system boot
process, and these processes may need to be moved to the root cgroup
before the cpu controller can be enabled.

at https://www.kernel.org/doc/Documentation/cgroup-v2.txt

* If a user installs "pulseaudio", which is true for almost all
  desktop environments, then "rtkit" is also installed and
  "pulseaudio" runs in the realtime priority.

Under the above situation, when a user runs "virsh" or "virt-manager"
or something like that, he/she gets the error message

Invalid value '+cpu' for 'cgroup.subtree_control': Invalid argument

and cannot use an application relying on libvirt0. It is also
reported at 
https://unix.stackexchange.com/questions/525498/libvirt-will-not-start-vms-with-error-invalid-value-cpu-for-cgroup-subtree

Temporary workaround 1: apt-get remove rtkit

Temporary workaround 2: Use the following patch

--- libvirt-5.0.0/src/util/vircgroup.c-orig 2019-06-29 12:57:39.959731576 
+0900
+++ libvirt-5.0.0/src/util/vircgroup.c  2019-06-29 12:58:57.858871856 +0900
@@ -1268,6 +1268,7 @@
 {
 if (virLastErrorIsSystemErrno(ENXIO) ||
 virLastErrorIsSystemErrno(EPERM) ||
+   virLastErrorIsSystemErrno(EINVAL) ||
 virLastErrorIsSystemErrno(EACCES)) {
 virResetLastError();
 VIR_DEBUG("No cgroups present/configured/accessible, ignoring error");

A right solution:
An application should not try to enable the cpu controller in
cgroup v2, as instructed at 
https://github.com/systemd/systemd/blob/master/docs/CGROUP_DELEGATION.md

So a right solution is to stop touching "cgroup.subtree_control". It is also
discussed in the upstream as
https://github.com/libvirt/libvirt/commit/62dd4d25a2bc5ee33ed22728dc79a5da99906748

Best regards,
Ryutaroh Matsumoto


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

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

Versions of packages libvirt0 depends on:
ii  libacl1 2.2.53-4
ii  libapparmor12.13.2-10
ii  libaudit1   1:2.8.4-3
pn  libavahi-client3
ii  libavahi-common30.7-4+b1
ii  libc6   2.28-10
ii  libcap-ng0  0.7.9-2
ii  libcurl3-gnutls 7.64.0-4
ii  libdbus-1-3 1.12.16-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libsasl2-2  2.1.27+dfsg-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2.1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libvirt0 recommends:
ii  lvm2  2.03.02-3

libvirt0 suggests no packages.

-- no debconf information

Bug#815950: Explanation message for wiki blocks

[Nelson A. de Oliveira]

Hi!

What is the status of this issue, please?

As it is now, seeing only this message is not really user-friendly:

=
Forbidden

You are not allowed to access this!
=

Thank you!

Best regards,
Nelson

Bug#931242: vlc: cannot open files with # in name from playlist

[maney]

Package: src:vlc
Version: 3.0.7-0+deb9u1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Presumably one of the not so rare upgrades changed the parsing of m3u files

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Had a playlist with some file names containing #, like this (in the m3u)

06 - Bagatelle #2.flac

Loaded playlist to play the whole album.

   * What was the outcome of this action?

Failed to play all and only the files with # in their name.  Reported
unable to open mrl and gave full path that ended where the '#' would
go in the popup dialog.  Like this:

.../06%20-%20Bagatelle%20

The truncated names also appear, without the URL escaping, in the track
information in the UI with the "#2.flac" omitted. 

   * What outcome did you expect instead?

For the playlist to work as it has for many years (happened in an album
that has file dates from 2012) and play all the tracks.


Sanity check: if the track is added by "add file", the filename is not
truncated (in information from the UI) and plays.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages vlc depends on:
ii  dpkg 1.18.25
ii  vlc-bin  3.0.7-0+deb9u1
ii  vlc-l10n 3.0.7-0+deb9u1
ii  vlc-plugin-base  3.0.7-0+deb9u1
ii  vlc-plugin-qt3.0.7-0+deb9u1
ii  vlc-plugin-video-output  3.0.7-0+deb9u1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  3.0.7-0+deb9u1
ii  vlc-plugin-samba   3.0.7-0+deb9u1
ii  vlc-plugin-skins2  3.0.7-0+deb9u1
ii  vlc-plugin-video-splitter  3.0.7-0+deb9u1
ii  vlc-plugin-visualization   3.0.7-0+deb9u1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.24-11+deb9u4
ii  libvlc5  3.0.7-0+deb9u1

Versions of packages libvlc5 depends on:
ii  dpkg 1.18.25
ii  libc62.24-11+deb9u4
ii  libvlccore9  3.0.7-0+deb9u1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.7-0+deb9u1

Versions of packages vlc-bin depends on:
ii  libc6   2.24-11+deb9u4
ii  libvlc-bin  3.0.7-0+deb9u1
ii  libvlc5 3.0.7-0+deb9u1

Versions of packages vlc-plugin-base depends on:
ii  dpkg 1.18.25
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-2+deb9u1
ii  libasound2   1.1.3-5
ii  libass5  1:0.13.4-2
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavc1394-0 0.5.4-4+b1
ii  libavcodec57 7:3.2.14-1~deb9u1
ii  libavformat577:3.2.14-1~deb9u1
ii  libavutil55  7:3.2.14-1~deb9u1
ii  libbasicusageenvironment12016.11.28-1+deb9u2
ii  libbluray1   1:0.9.3-3
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.10.28-0+deb9u1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-10
ii  libdvbpsi10  1.3.0-5
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.4-1
ii  libfaad2 2.8.0~cvs20161113-1+deb9u1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libfribidi0  0.19.7-1+b1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgcrypt20  1.7.6-2+deb9u3
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u4
ii  libgpg-error01.26-2
ii  libgroupsock82016.11.28-1+deb9u2
ii  libharfbuzz0b1.4.2-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.9.4c-9
ii  liblivemedia57   2016.11.28-1+deb9u2
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8+d

Bug#931216: less: Ctrl-C has no effect with -c (--clear-screen) and process substitution

[Vincent Lefevre]

Control: forwarded -1 https://github.com/gwsw/less/issues/12

I've just reported the bug upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#931216: less: Ctrl-C has no effect with -c (--clear-screen) and process substitution

[Vincent Lefevre]

Control: tags -1 patch

On 2019-06-28 15:36:25 +0200, Vincent Lefevre wrote:
> This is where the behavior gets changed, in forwback.c:
> 
>   /*
>* If this is the first screen displayed and
>* we hit an early EOF (i.e. before the requested
>* number of lines), we "squish" the display down
>* at the bottom of the screen.
>* But don't do this if a + option or a -t option
>* was given.  These options can cause us to
>* start the display after the beginning of the file,
>* and it is not appropriate to squish in that case.
>*/
>   if (first_time && pos == NULL_POSITION && !top_scroll && 
> #if TAGS
>   tagoption == NULL &&
> #endif
>   !plusoption)
>   {
>   squished = 1;
>   continue;
>   }
> 
> With top_scroll being true, this "if" condition is false and "screen"
> still waits for input to paint the screen, instead of assuming that
> there is no more input (for the moment) and display the prompt
> immediately.
> 
> The issue is with the "put_line();" that follows. In the put_line
> code from output.c:
> 
>   if (ABORT_SIGS())
>   {
>   /*
>* Don't output if a signal is pending.
>*/
>   screen_trashed = 1;
>   return;
>   }
> 
> If I remove this, everything is fine.

I think that a solution would be to take Ctrl-C into account just
before the "put_line();" above.

I'm currently using the attached patch.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Honor Ctrl-C when a + or -c option is given
Author: Vincent Lefevre 
Bug-Debian: https://bugs.debian.org/931216
Last-Update: 2019-06-28

Index: less-487/forwback.c
===
--- less-487.orig/forwback.c
+++ less-487/forwback.c
@@ -260,6 +260,18 @@ forw(n, pos, force, only_last, nblank)
squished = 1;
continue;
}
+   /*
+* Process S_INTERRUPT now. Otherwise, if a + or -c option
+* is given, and Ctrl-C will have no effect due to the
+* ABORT_SIGS() condition in put_line: input will still
+* be considered for the output. Examples in bash/zsh:
+*   less -f +1 <(echo foo; sleep 3; echo bar)
+*   less -f -c <(echo foo; sleep 3; echo bar)
+* Note: This must not be done for Ctrl-Z, otherwise the
+* display is incorrect after "fg".
+*/
+   if (sigs & S_INTERRUPT)
+   psignals();
put_line();
 #if 0
/* {{ 

Bug#798559: cwidget: Restore old signal handlers after handling the signal

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending

--
Manuel A. Fernandez Montecelo 

Bug#931224: In default style, lettered lists come out as numbered

[Steve McIntyre]

On Fri, Jun 28, 2019 at 06:36:35PM +0100, Adam Barratt wrote:
>On Fri, 2019-06-28 at 15:43 +0100, Ian Jackson wrote:
>> See for example, the "footnote A" in
>>   https://wiki.debian.org/GitPackagingSurvey
>> where this wiki source text
>> 
>> > A. <>As noted in the introduction [etc. ...
>> 
>> is rendered like this by Firefox:
>> 
>>  | 1. As noted in the introduction, ...
>> 
>> Despite this in the HTML:
>> 
>>  | ... >  |  id="noteA">As noted in the introduction ...
>
>This appears to be due to the main Debian CSS setting "list-style-type: 
>decimal" for OL elements.

ACK, I saw that earlier when I started digging. It's a bit
... artbitrary :-/

>That could be overridden on the wiki side by setting "ol[type=A]
>{list-style-type:upper-alpha;}" in one of the stylesheets that is
>applied later.

Right, or just fixed at the top level.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Bug#412830: Ctrl-Z + fg confuses aptitude: down arrow runs reportbug

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending

--
Manuel A. Fernandez Montecelo 

Bug#931240: ITP: pmemkv -- key:value data store for persistent memory

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: pmemkv
  Version : 0.8
  Upstream Author : Intel
* URL : https://github.com/pmem/pmemkv
* License : BSD
  Programming Lang: C, C++; extra bindings come separately
  Description : key:value data store for persistent memory
 Pmemkv is a family of key:value stores, developed with persistent memory
 in mind -- yet rather than being tied to a single backing implementation,
 it presents a common interface to a number of engines, both provided by
 pmemkv itself and external.

Bug#931238: hot armor: please drop "Version: " header

[Daniel Kahn Gillmor]

Package: hopenpgp-tools
Version: 0.21.3-1
Severity: wishlist

"hot armor" currently adds a comment line to its enarmored content:

Version: hot 0.21.3

Best practices these days omits indicators of what particular OpenPGP
implementation is in use.   Please do not emit it by default!

  --dkg


signature.asc
Description: PGP signature

Bug#931239: please improve performance of hopenpgp-tools on large certificates

[Daniel Kahn Gillmor]

Package: hopenpgp-tools
Version: 0.21.3-1
Severity: wishlist

I'm looking at performance tests on large (spammed/flooded)
certificates.  hopenpgp-tools consumes more CPU than GnuPG by a factor
of 2×, 5×, or 10× depending on the operation.

I provide these figures as a target for hopenpgp to meet or beat, if
possible.

During these tests, xxx is the dearmored form of my flooded OpenPGP
certificate, as it is found on the SKS keyservers:

  wget -O - \
   'http://keys.mayfirst.org/pks/lookup?op=get&search=0xF20691179038E5C6' | \
   gpg --dearmor > xxx

it's about 17MiB in size, bloated with junk (see
https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html for
more details)

All tests were run on a quad-core Intel(R) Core(TM) i5-2540M CPU @
2.60GHz, and all data is in a tmpfs, so there should be no disk latency
to worry about.

--

Here is a performance comparison of just listing the contents of the
packet.  hopenpgp-tools takes 10× more time:

0 dkg@alice:/tmp/cdtemp.7QJ3xD$ time hot dump < xxx > /dev/null
hot (hopenpgp-tools) 0.21.3
Copyright (C) 2012-2019  Clint Adams
hot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are 
welcome to redistribute it under certain conditions.

real0m4.750s
user0m4.725s
sys 0m0.025s
0 dkg@alice:/tmp/cdtemp.7QJ3xD$ time pgpdump < xxx > /dev/null

real0m0.516s
user0m0.403s
sys 0m0.104s
0 dkg@alice:/tmp/cdtemp.7QJ3xD$ time gpg --list-packets < xxx > /dev/null

real0m0.511s
user0m0.506s
sys 0m0.005s
0 dkg@alice:/tmp/cdtemp.7QJ3xD$ 
--


--
Here is a comparison of adding or removing armor.  hot takes about 5× as
much time as gpg:

1 dkg@alice:/tmp/cdtemp.bOnXz6$ time gpg --enarmor < xxx > xxx.gpg.asc

real0m0.239s
user0m0.222s
sys 0m0.017s
0 dkg@alice:/tmp/cdtemp.bOnXz6$ time hot armor --armor-type pubkeyblock < xxx > 
xxx.hot.asc
hot (hopenpgp-tools) 0.21.3
Copyright (C) 2012-2019  Clint Adams
hot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are 
welcome to redistribute it under certain conditions.

real0m0.978s
user0m0.917s
sys 0m0.061s
0 dkg@alice:/tmp/cdtemp.bOnXz6$ time gpg --dearmor < xxx.gpg.asc  > /dev/null

real0m0.332s
user0m0.317s
sys 0m0.016s
0 dkg@alice:/tmp/cdtemp.bOnXz6$ time hot dearmor < xxx.gpg.asc  > /dev/null
hot (hopenpgp-tools) 0.21.3
Copyright (C) 2012-2019  Clint Adams
hot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are 
welcome to redistribute it under certain conditions.

real0m1.657s
user0m1.616s
sys 0m0.036s
0 dkg@alice:/tmp/cdtemp.bOnXz6$ 
---


---
and here is an attempt to look at parsing the data in more detail:

they're both pretty bad, but gpg is faster by a factor of ~2×:

0 dkg@alice:/tmp/cdtemp.bOnXz6$ time gpg --show-keys < xxx  | wc
  8  35 383

real0m34.374s
user0m34.297s
sys 0m0.080s
0 dkg@alice:/tmp/cdtemp.bOnXz6$ time hokey lint < xxx  | wc
hokey (hopenpgp-tools) 0.21.3
Copyright (C) 2012-2019  Clint Adams
hokey comes with ABSOLUTELY NO WARRANTY. This is free software, and you are 
welcome to redistribute it under certain conditions.
 42 2192054

real0m57.681s
user0m57.387s
sys 0m0.284s
0 dkg@alice:/tmp/cdtemp.bOnXz6$ 


It should not take a modern CPU more than a few seconds to produce ~2KiB
of output out of 17MiB of input!

---

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#931224: In default style, lettered lists come out as numbered

[Ian Jackson]

Adam D. Barratt writes ("Re: Bug#931224: In default style, lettered lists come 
out as numbered"):
> This appears to be due to the main Debian CSS setting "list-style-type: 
> decimal" for OL elements. That could be overridden on the wiki side by
> setting "ol[type=A] {list-style-type:upper-alpha;}" in one of the
> stylesheets that is applied later.

Is there a good reason for the main CSS setting ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#931211: s2s connections are broken after upgrading to buster

[Marco d'Itri]

On Jun 28, Philipp Huebner  wrote:

> I just noticed that after my latest ejabberd upload there have been
> several updates of Erlang for buster, maybe we need binNMUs for ejabberd
> and erlang-p1-*.
Maybe a missing dependency?

root@sarek:~# dpkg -l | egrep 'erlang|ejabberd'
ii  ejabberd   18.12.1-2i386 
distributed, fault-tolerant Jabber/XMPP server
ii  erlang-asn11:21.2.6+dfsg-1  i386 
Erlang/OTP modules for ASN.1 support
ii  erlang-base1:21.2.6+dfsg-1  i386 
Erlang/OTP virtual machine and base applications
ii  erlang-base64url   1.0-3i386 
standalone URL-safe base64-compatible codec for Erlang
ii  erlang-crypto  1:21.2.6+dfsg-1  i386 
Erlang/OTP cryptographic modules
ii  erlang-edoc1:21.2.6+dfsg-1  i386 
Erlang/OTP module for generating documentation
ii  erlang-ftp 1:21.2.6+dfsg-1  i386 
Erlang/OTP FTP client
ii  erlang-goldrush0.2.0-1  i386 small 
Erlang app that provides fast event stream processing
ii  erlang-inets   1:21.2.6+dfsg-1  i386 
Erlang/OTP Internet clients and servers
ii  erlang-jiffy   0.14.11+dfsg-4   i386 JSON 
NIFs (Native Implemented Functions) for Erlang
ii  erlang-jose1.9.0-1  i386 JSON 
Object Signing and Encryption (JOSE) for Erlang
ii  erlang-lager   3.6.8-1  i386 
logging framework for Erlang
ii  erlang-mnesia  1:21.2.6+dfsg-1  i386 
Erlang/OTP distributed relational/object hybrid database
ii  erlang-odbc1:21.2.6+dfsg-1  i386 
Erlang/OTP interface to SQL databases
ii  erlang-os-mon  1:21.2.6+dfsg-1  i386 
Erlang/OTP operating system monitor
ii  erlang-p1-cache-tab1.0.17-1 i386 
in-memory cache application for Erlang / Elixir apps
ii  erlang-p1-eimp 1.0.9-1  i386 Erlang 
application for manipulating graphic images
ii  erlang-p1-iconv1.0.10-1 i386 fast 
encoding conversion library for Erlang / Elixir
ii  erlang-p1-pkix 1.0.0-3  i386 PKIX 
certificates management library for Erlang
ii  erlang-p1-stringprep   1.0.14-1 i386 erlang 
interface to stringprep
ii  erlang-p1-tls  1.0.26-1 i386 native 
TLS / SSL driver for Erlang / Elixir
ii  erlang-p1-utils1.0.13-1 i386 set of 
small Erlang libraries
ii  erlang-p1-xml  1.1.34-1 i386 XML 
utilities for Erlang
ii  erlang-p1-xmpp 1.2.8-1  i386 
Erlang/Elixir XMPP parsing and serialization library
ii  erlang-p1-yaml 1.0.17-1 i386 erlang 
wrapper for libyaml C library
ii  erlang-p1-zlib 1.0.4-3  i386 erlang 
interface to zlib
ii  erlang-proper  1.2+git988ea0ed9f+dfsg-2 i386 
QuickCheck-inspired property-based testing tool for Erlang
ii  erlang-public-key  1:21.2.6+dfsg-1  i386 
Erlang/OTP public key infrastructure
ii  erlang-runtime-tools   1:21.2.6+dfsg-1  i386 
Erlang/OTP runtime tracing/debugging tools
ii  erlang-snmp1:21.2.6+dfsg-1  i386 
Erlang/OTP SNMP applications
ii  erlang-ssl 1:21.2.6+dfsg-1  i386 
Erlang/OTP implementation of SSL
ii  erlang-syntax-tools1:21.2.6+dfsg-1  i386 
Erlang/OTP modules for handling abstract Erlang syntax trees
ii  erlang-tftp1:21.2.6+dfsg-1  i386 
Erlang/OTP TFTP client and server
ii  erlang-xmerl   1:21.2.6+dfsg-1  i386 
Erlang/OTP XML tools

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#931211: s2s connections are broken after upgrading to buster

[Philipp Huebner]

Hi,

this is rather strange, could you please let me know what erlang
packages and versions you have installed? Looks like there is a mismatch
somewhere.

I just noticed that after my latest ejabberd upload there have been
several updates of Erlang for buster, maybe we need binNMUs for ejabberd
and erlang-p1-*.

Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#931236: connman: Sysv init script should do a noop if connman is not installed

[Alf Gaida]

test -x $DAEMON || exit 0


meh - why not, will not hurt. More verbose, normally i wouldn't care but 
it  seems to be common in sysv.


Cheers Alf

Bug#931236: connman: Sysv init script should do a noop if connman is not installed

[Alf Gaida]

I'm biased - if one remove connman and leave the configurations in place 
for a reason the system should be verbose about.


If one want to really get rid of connman one should purge it - solved, 
no changes needed.


Cheers Alf

Bug#930176: dh-golang: support cross building go packages

[Michael Hudson-Doyle]

On Fri, 7 Jun 2019 at 21:33, Helmut Grohne  wrote:

> Package: dh-golang
> Version: 1.39
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability ftcbfs
>
> I was recently asked how to cross build Debian packages with go sources
> and figured that presently it wouldn't work at all. Effectively, all go
> packages are cross bd-uninstallable due to the way Multi-Arch works.
>
> Packages typically Build-Depend on dh-golang. Such a dependency is
> interpreted as a host architecture dependency. Now dh-golang is
> Architecture: all, which is treated as a "native" architecture (for
> dependency resolution). "native" is formally defined as the architecture
> of the installed "dpkg" package and usually matches the build
> architecture. When build and host architecture differ (aka cross
> compiling), dh-golang:$host does not have any installation candidate.
> The usual fix is to mark it Multi-Arch: foreign. But doing so would be
> wrong in its present form.
>
> For getting started with cross building go packages, I looked for very
> simple go packages. Note that go libraries actually package source code
> and thus typically are Architecture: all. Such packages are irrelevant
> for cross building. What I looked for was a go package containing an
> executable. About the simplest package I could find was "canid". Now for
> actually trying a cross build, I simply installed the relevant packages
> for the build architecture and made dpkg-checkbuilddeps shut up using
> -d. Dependency satisfiability still needs to be taken care of somehow,
> but let's defer that for now.
>
> Martín Ferrari kindly pointed me to the GOOS and GOARCH environment
> variables. These need to be set. For Arm architectures one also needs to
> set GOARM. The values are ... not very obvious. The attached patch takes
> care of setting them up. As far as I understand it, go might also call a
> C compiler, so I also provide a CC variable. Once all these variables
> are set, I get a successful build.
>
> Unfortunately the contents of the build are broken. Instead of
> /usr/bin/canid, I now have /usr/bin/${GOOS}_${GOARCH}/canid. According
> to github user ishanjain28 this is an expected convention. Therefore my
> patch corrects the binary installation directory in the install step.
>
> Another aspect is that canid is now statically linked. This also is
> expected behaviour as https://golang.org/cmd/cgo/ explains:
>
> | The cgo tool is enabled by default for native builds on systems where it
> | is expected to work. It is disabled by default when cross-compiling. You
> | can control this by setting the CGO_ENABLED environment variable when
> | running the go tool:
>
> In the interest of reproducible builds, we need to match the native
> behaviour and set CGO_ENABLED=1.
>
> I also tried building mtail (again running dpkg-buildpackage with -d)
> and it appeared to produce reasonable packages.
>
> Since dh-golang now actually honours the dpkg architecture variables,
> marking it Multi-Arch: foreign is a reasonable thing to do.
>

This all makes sense to me, as far as I understand how multi-arch works
(which isn't terribly far).


> If you upload a dh-golang with these changes, suddenly those go packages
> that don't have any library dependencies will become cross satisfiable
> (due to the Multi-Arch: foreign marking).  However their dependency on
> golang-any will use the host architecture go, which cannot be run. We'll
> have to somehow figure out what to do about this. I don't have an answer
> yet.
>

I don't know what to do here either. On the one hand, it's simple (at least
for golang-go): we want to install the build go, because all go compilers
are capable of cross compilation. How is this handled for the C compiler?


> In the mean time, please consider applying the attached patch as an
> incremental step after buster is released.
>
> Helmut
>

Bug#931237: lvm2: "lvm2-lvmetad not found" on upgrade

[Alexander Galanin]

Package: lvm2
Version: 2.03.02-3
Severity: minor

During upgrade lvm2 from 2.03.02-2 to 2.03.02-3 I see a strange warning
in console:

invoke-rc.d: unknown initscript, /etc/init.d/lvm2-lvmetad not found.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-3
ii  dmsetup   2:1.02.155-3
ii  libaio1   0.3.112-3
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-10
ii  libdevmapper-event1.02.1  2:1.02.155-3
ii  libdevmapper1.02.12:1.02.155-3
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-5
ii  libudev1  241-5
ii  lsb-base  10.2019051400

Versions of packages lvm2 recommends:
pn  thin-provisioning-tools  

lvm2 suggests no packages.

-- no debconf information

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Paride Legovini]

Steffen Nurpmeso wrote on 28/06/2019:
> Paride Legovini wrote in  r.org>:
>  |Steffen Nurpmeso wrote on 27/06/2019:
>  |> Paride Legovini wrote in   |> r.org>:
>  |>|Steffen Nurpmeso wrote on 20/06/2019:
>  |>|> the patch was reversed; here is the right one.
>  |>|
>  |>|Just to be sure, is your last "ivan.diff" patch all that's needed to fix
>  |>|this bug? I would like to have it fixed in buster, but given that we're
>  |>|so deep in the freeze I'll have to ship only a minimal fix for this
>  |>|specific bug; an import of a new minor version changing other stuff
>  |>|won't be accepted. This will mean patching 14.9.11.
>  |> 
>  |> Oh-oh, 14.9.11 is a year old! :)  I do not understand that
>  |> security policy of Debian, for such a small program with a single
>  |> developer.  So many bugs fixed!  I would even update to [master]
>  |> or [stable/stable] and use the grappa mode!  Sigh. :)
>  |
>  |Yeah I'm sorry for the skipped release, I promise I will backport the
>  |latest one once buster is released, but for the moment v14.9.11 is the
>  |version we have to work with.
>  |
>  |The policy for acceptable changes during the full freeze period is
>  |pretty clear:
>  |
>  |https://release.debian.org/buster/freeze_policy.html
>  |
>  |and I don't think an update to e.g. 14.9.14 will fit.
> 
> That definetely not, i had to rewrite the entire child process and
> job control signal handling to something that i almost like.  And
> the rest of the way we will make, too!
> 
> I was thinking more of the [stable/stable] branch, which is
> v14.9.13 plus fixes, and which can be turned into a release with
> the grappa mode of mk/make-release.sh (as documented in README).

Hi Steffen,

This would totally make sense in my opinion, the problem is we don't
have v14.9.13 in Debian, but v14.9.11, and we need two "UPDATE" version
bumps (in the MAJOR.MINOR.UPDATE semantic) to get to 14.9.13, on which
we can apply the bug fixes in the stable/stable branch. And UPDATE
releases are not bugfix-only releases, so not really suitable for
inclusion while Debian is in deep freeze.

I can of course backport the latest stable version of s-nail once Buster
is released, and I will, but that's not the same of course.

Please let me know if I misunderstood something, and thanks a lot for
your feedback.

Paride

Bug#931215: many well known Android devices not supported

[殷啟聰 | Kai-Chung Yan]

Control: severity -1 wishlist

> You raised the severity of this bug to serious.

I think that was by mistake. Since this is a "metabug", I am now giving it a 
`wishlist`.



signature.asc
Description: OpenPGP digital signature

Bug#931236: connman: Sysv init script should do a noop if connman is not installed

[Lorenzo Puliti]

Source: connman
Version: 1.36-2
Severity: normal

Dear Connman Maintainer,
while doing some testing in a VM i realize that the connman sysv init script 
exits with an error during the boot sequence, because connman is not installed
(/usr/sbin/connmand does not exists on the system).
This has also the side effect of breaking the VM network connection after each 
boot, 
because the connman init script symlinks /etc/resolv.conf --> 
/run/connamn/resolv.conf 
which is empty and will be erased after each reboot.
To fix this, please add at the beginning of the init script a test like the 
following


DAEMON=/usr/sbin/connmand
DESC="Connection Manager"
NAME=connmand
. /lib/lsb/init-functions

test -x $DAEMON || exit 0

if [ -f /etc/default/connman ] ; then
. /etc/default/connman
fi


Thanks,
Lorenzo


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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Bug#931215: many well known Android devices not supported

[Paul Gevers]

Dear Hans-Christoph,

On Fri, 28 Jun 2019 14:20:35 +0200 Hans-Christoph Steiner 
wrote:
> Package: adb
> Version: 25.0.0+10

You raised the severity of this bug to serious. Do you want to remove
the package from buster? There is no time anymore to fix this issue, so
we ship buster with the current package (and you can go the point
release route), or we remove it.

> This is a kind of "meta" bug report to gather information about missing
> device support for the adb and fastboot packages.  Currently, the only
> blocker for LineageOS for recommending the Debian packages over the
> Google packages is missing device IDs in the udev rules for devices that
> LineageOS supports:
> 
> https://review.lineageos.org/c/LineageOS/lineage_wiki/+/244577
> 
> Upstream for the udev rules has recently merged some more USB device
> IDs.  Plus some other device rules have come via salsa merge requests:
> 
> * Add some more Amazon devices
> https://salsa.debian.org/android-tools-team/android-sdk-meta/merge_requests/2
> 
> * Add another Huawei ADB device
> https://salsa.debian.org/android-tools-team/android-sdk-meta/merge_requests/3

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929905: fdroidserver: Packaged version of fdroidserver incompatible with upstream's repository

[Paul Gevers]

Dear Hans-Christoph,

On Sun, 02 Jun 2019 17:16:21 -0400 Nicolas Braud-Santoni
 wrote:
> Package: fdroidserver
> Version: 1.1.1-1
> Severity: important

You raised the severity of this bug to serious. Do you want to remove
the package from buster? There is no time anymore to fix this issue, so
we ship buster with the current package (and you can go the point
release route), or we remove it.

> I installed fdroidserver hoping to contribute new package definitions
> to FDroid's upstream repository.
> 
> Unfortunately, the metadata schema evolved since v1.1.1-1, in particular the
> validation for the `Bitcoin` field changed, making `fdroid readmeta` fail on
> an unmodified copy of FDroid's repository.
> 
> The same command completes successfully with the version of fdroidserver from
> https://gitlab.com/fdroid/fdroidserver
> 
> 
> Considering that this makes the FDroid Debian package unsuitable for 
> contributing
> to that repository, I am marking this bug as important.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Ivan Vučica]

(bug to BCC, let's really not keep the discussion there)

On Fri, Jun 28, 2019 at 5:28 PM Steffen Nurpmeso  wrote:

>  |I didn't treat you as such; but, if XOAUTH2 was a supported SASL
>
> But Google does!  Google does.
>

It's not far off. If I can, I avoid giving software privileges it doesn't
need. I think s-nail is simple enough and would not call it really insecure.

But, if it can function without knowing a password that grants software
access to everything in my Google account, why not?

(Same applies to other accounts; why would a hypothetical deployment of
Dovecot accept the same authorization token -- password or otherwise --
that grants me access to code review tool Gerrit?)

>
> As above, Ivan.  The problem is solely on code level, and with
> filter i mean that we could implement a SASL layer which is
> temporarily installed as an event handler onto the socket's I/O while
> the SASL session is active.  This is identical in between all
> protocols (iirc), and this that single "filter" would be generic
> and could be shared.
>

SASL mechanisms are identical; how the SASL bytes are encapsulated is very
much protocol specific. XMPP encapsulation is nowhere near similar to
IMAP's, SMTP's or IRC's.


>
>  |Using libsasl2 for this, well, that's the interesting part. You get
>  |pluggability, you get a lot of SASL mechanisms already implemented for
>  |you, and users can write their own plugins as well.
>
> Oh!  You want SASL support  Now i got ya!!
>
> Oh, i'll tell you what i do.  I delay the release of v14.9.14 by
> one week, and promise i will use the time to look into SASL and
> try to hack (and it will be exactly that) it in, ok?  I do not
> promise i will make it, if it will be so dirty that i am going
> nuts over it i will stop the effort.  But i promise i will put
> some good will into it.  All right?  Ivan?
>

I do hope you did not perceive anything I wrote as a demand -- I do *not*
make demands of free software developers, merely share information in case
they can make some time for things that might be useful to me. In case of
libsasl2, its pluggability and widespread availability means you might
actually be able to simplify some s-nail code and not depend on GSSAPI
*directly*. (I didn't look at it yet.)

I will certainly keep using s-nail for my local mail as-is; there is *zero*
rush to have libsasl2 as the backend to implement SASL negotiation! I am
appreciative of it as-it-is.

If you do feel like it's an interesting thing to explore, I certainly
wouldn't mind it. But please, only look at adding this if you feel like it.

s-nail existing, being maintained, using GSSAPI and offering IMAP support
(insanely cool!) is already very much appreciated.

Vielen Dank für Ihre Arbeit, Steffen!

Bug#931235: shutdown reboots immediately without dbus

[Antoine Beaupre]

Package: systemd-sysv
Version: 241-5
Severity: grave

I have somehow managed to install a buster system with systemd-sysv
(so it boots under systemd) and without dbus (probably because I
installed without recommends).

This has all sorts of ... er... interesting properties. The most
noticeable (and disturbing) one is that `shutdown -r +DELAY` doesn't
work anymore.

root@archive-01:~# shutdown -r +1 "test" 
Failed to connect to bus: No such file or directory
root@archive-01:~# 

At this point, my SSH connexion froze and the machine stopped
answering pings. I am not exactly sure what happens because I don't
have a console on the server, but I suspect it just did a hard reboot,
because normal shutdown procedures would have killed the sshd process
and therefore closed the connexion (instead of just hanging).

Therefore, not only the +1 minute delay is not respected, but the
shutdown procedure is bypassed completely. The server eventually *did*
reboot so it's not a full crash, but it's still pretty nasty.

I would recommend a hard Depends on dbus for the systemd-sysv package
(which provides the shutdown command) to resolve this problem.

And I think this should be fixed in buster, sorry for the last minute
bug report. :/ I really appreciate your work and systemd is generally
working very well for me, so thank you for that! :)

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

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

Versions of packages systemd-sysv depends on:
ii  systemd  241-5

Versions of packages systemd-sysv recommends:
ii  libnss-systemd  241-5

systemd-sysv suggests no packages.

-- debconf-show failed

PS: this bug report was filed on a different machine than the original
one, but the environment should be similar (except the APT policy).

Bug#905022: Bug#908589: gcc-8 documentation packages

[Dmitry Eremin-Solenikov]

Hello,

пн, 24 июн. 2019 г. в 12:27, Guo Yixuan :
>
> Hello Matthias and Dmitry,
>
> Sorry for being MIA. As I'm currently busy with my life and work, I want to 
> give up all my packages for adoption. (I forgot about the proper procedure 
> here, so please kindly take over as you wish.)

Thank you for your previous work. I'm fine with co-maintaining
packages if you'd like to do that in future.

> Please let me know if a GPG-signed copy of this email is needed.
>
> Thank you!
> Yixuan
>
> On Mon, Jun 24, 2019 at 5:51 PM Matthias Klose  wrote:
>>
>> On 22.06.19 01:01, Dmitry Eremin-Solenikov wrote:
>> > Hello,
>> >
>> > вт, 21 мая 2019 г. в 16:58, Dmitry Eremin-Solenikov :
>> >>
>> >> Hello,
>> >>
>> >> I've updated gcc-doc/gcc-doc-defaults packages to support new gcc-8
>> >> documentation generation. NMU Packages are uploaded to
>> >> mentors.debian.net
>> >> for review, git trees are put on salsa.debian.org/gcc-doc (-defaults).
>> >
>> > It's been nearly a month without any response. Is it an expected thing 
>> > before
>> > buster release? Or should I contact debian-mentors looking for sponsors
>> > for these packages?
>>
>> I'm trying to stay away uploading the gcc*-doc packages.  Yes, maybe 
>> contacting
>> debian-mentors is the right thing to do, if Guo is MIA.



-- 
With best wishes
Dmitry

Bug#931234: glib2.0: CVE-2019-13012: keyfile settings backend: Consider tightening permissions

[Salvatore Bonaccorso]

Source: glib2.0
Version: 2.58.3-2
Severity: important
Tags: security upstream fixed-upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib/issues/1658

Hi,

The following vulnerability was published for glib2.0.

CVE-2019-13012[0]:
| The keyfile settings backend in GNOME GLib (aka glib2.0) before 2.59.1
| creates directories using g_file_make_directory_with_parents
| (kfsb->dir, NULL, NULL) and files using g_file_replace_contents
| (kfsb->file, contents, length, NULL, FALSE,
| G_FILE_CREATE_REPLACE_DESTINATION, NULL, NULL, NULL). Consequently, it
| does not properly restrict directory (and file) permissions. Instead,
| for directories, 0777 permissions are used; for files, default file
| permissions are used. This is similar to CVE-2019-12450.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13012
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13012
[1] https://gitlab.gnome.org/GNOME/glib/issues/1658

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#931224: In default style, lettered lists come out as numbered

[Adam D. Barratt]

On Fri, 2019-06-28 at 15:43 +0100, Ian Jackson wrote:
> See for example, the "footnote A" in
>   https://wiki.debian.org/GitPackagingSurvey
> where this wiki source text
> 
> > A. <>As noted in the introduction [etc. ...
> 
> is rendered like this by Firefox:
> 
>  | 1. As noted in the introduction, ...
> 
> Despite this in the HTML:
> 
>  | ...   |  id="noteA">As noted in the introduction ...

This appears to be due to the main Debian CSS setting "list-style-type: 
decimal" for OL elements. That could be overridden on the wiki side by
setting "ol[type=A] {list-style-type:upper-alpha;}" in one of the
stylesheets that is applied later.

Regards,

Adam

Bug#931233: quelcom FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: quelcom
Version: 0.4.0-13
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

quelcom fails to cross build from source, because it does not pass cross
tools to make. The easist way of fixing that - using dh_auto_build -
makes quelcom cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru quelcom-0.4.0/debian/changelog 
quelcom-0.4.0/debian/changelog
--- quelcom-0.4.0/debian/changelog  2012-01-17 10:28:22.0 +0100
+++ quelcom-0.4.0/debian/changelog  2019-06-28 19:30:30.0 +0200
@@ -1,3 +1,10 @@
+quelcom (0.4.0-13.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 28 Jun 2019 19:30:30 +0200
+
 quelcom (0.4.0-13) unstable; urgency=low
 
   * Convert to dpkg-source 3.0 (quilt)
diff --minimal -Nru quelcom-0.4.0/debian/rules quelcom-0.4.0/debian/rules
--- quelcom-0.4.0/debian/rules  2012-01-17 10:28:07.0 +0100
+++ quelcom-0.4.0/debian/rules  2019-06-28 19:30:29.0 +0200
@@ -16,7 +16,7 @@
dh_testdir
# stripping is disabled during the build so that it can
# be done (or not) by dh_strip
-   $(MAKE) PREFIX=/usr STRIP=/bin/true
+   dh_auto_build -- PREFIX=/usr STRIP=/bin/true
touch build-stamp
 
 clean:

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Michael Biebl]

Am 27.06.19 um 09:09 schrieb Raphael Hertzog:
> The net result of this problem is a server that is not reachable after a
> reboot so it can certainly be argued that it's worth documenting. It could
> be a debconf prompt that happens only when systemd-networkd is active
> and when ipv6 is disabled, but TBH the time spent in writing this code
> would be just as well spent backporting the upstream fix.

Could you give the packages at
https://people.debian.org/~biebl/systemd/buster/ a try?

The debdiff is larger then I had hoped, so I'm not sure if the SRMs will
ack this changeset. It's quite well possible that I messed something up
when doing the backport, so aaving at least a confirmation that it fixes
the issue at hand would be welcome.



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



signature.asc
Description: OpenPGP digital signature

Bug#931232: spout FTCBFS: upstream Makefile hard codes build architecture build tools

[Helmut Grohne]

Source: spout
Version: 1.4-4.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

spout fails to cross build from source, because the upstream Makefile
and config.mk hard code build architecture build tools such as cc and
pkg-config. The attached patch makes those tools substitutable to make
spout cross buildable. Please consider applying it.

Helmut
--- spout-1.4.orig/config.mk
+++ spout-1.4/config.mk
@@ -7,8 +7,9 @@
 MANPREFIX = /usr/share/man
 
 # includes and libs
-SDLINC = $(shell pkg-config --cflags sdl)
-SDLLIB = $(shell pkg-config --libs sdl)
+PKG_CONFIG ?= pkg-config
+SDLINC = $(shell $(PKG_CONFIG) --cflags sdl)
+SDLLIB = $(shell $(PKG_CONFIG) --libs sdl)
 
 INCS = -I. -I/usr/include ${SDLINC}
 LIBS = -lc ${SDLLIB}
--- spout-1.4.orig/Makefile
+++ spout-1.4/Makefile
@@ -18,11 +18,11 @@
 
 .c.o:
 	@echo CC $<
-	@cc -c $(CFLAGS) $(CPPFLAGS) $<
+	@$(CC) -c $(CFLAGS) $(CPPFLAGS) $<
 
 $(TARGETS): $(OBJ)
 	@echo LD $@
-	@cc -o $@ $(OBJ) $(LDFLAGS)
+	@$(CC) -o $@ $(OBJ) $(LDFLAGS)
 
 config.h:
 	@echo creating $@ from config.def.h

Bug#931228: policyd-weight: dead upstream

[Helmut Grohne]

Control: severity -1 important


On Fri, Jun 28, 2019 at 05:24:29PM +0200, Jonas Smedegaard wrote:
> Justification: renders package unusable

This is clearly wrong.

> Upstream homepage http://www.policyd-weight.org/ contains a single sentence:
> 
>Project discontinued
> 
> According to
> https://web.archive.org/web/20180810082500/http://policyd-weight.org/ and
> https://web.archive.org/web/20180317115359/http://www.policyd-weight.org:80/
> this changed a year ago, somewhere between 2018-03-17 and 2018-08-10, and
> last upstream release was 2011-09-18.

We have many packages in the archive that are dead upstream. Debian is
keping quite a number of packages on life-support. The question really
is how well it is maintained.

I see two bugs:
 * #891789 (missing systemd .service file)
 * #891790 (install example config)

Outdated standards version.
3 lintian warnings.

The package uses debhelper, but not dh.

To me this looks like it's not the top of packages, but certainly in
releaseable quality. I also happen to know that it just works for me.

> Setting severity to grave to keep it out of Buster _unless_ the package
> maintainer actively considers this package sane to release with Buster
> without upstream support to back it.

Given the above, I don't see a good reason not to ship it with buster.
Would you also file a grave bug against autoconf2.64, which was released
in 2009 and last uploaded 2.5 years ago?

Helmut

Bug#868087: light-locker: Locking screen with light-locker crashes system to blinking cursor

[nodiscc]

> nodiscc, could you tell us which devices drivers is used in both cases
(working, after nvidia-config, and not working). The information should be
available in /var/log/Xorg.0.log

Original, working, no xorg.conf, glx alternative = /usr/lib/mesa-diverted:

(II) LoadModule: "nouveau"
(II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so

glx alternative = /usr/lib/nvidia, no xorg.conf, triggers bug 868087:

(II) LoadModule: "nvidia"
(II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so

glx alternative = /usr/lib/nvidia, xorg.conf present, working:

(II) LoadModule: "nvidia"
(II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so

There are some differences between the logs using the non-free nvidia
driver, with and without xorg.conf present, I am attaching the diff
--- /tmp/Xorg.log.nvidia	2019-06-28 18:49:47.153580725 +0200
+++ /tmp/Xorg.log.nvidia-without-xorg-conf	2019-06-28 18:55:46.921035994 +0200
@@ -13,15 +13,14 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
 	(++) from command line, (!!) notice, (II) informational,
 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Fri Jun 28 18:38:04 2019
-(==) Using config file: "/etc/X11/xorg.conf"
+(==) Log file: "/var/log/Xorg.0.log", Time: Fri Jun 28 18:51:29 2019
 (==) Using system config directory "/usr/share/X11/xorg.conf.d"
-(==) ServerLayout "Layout0"
-(**) |-->Screen "Screen0" (0)
-(**) |   |-->Monitor "Monitor0"
-(**) |   |-->Device "Device0"
-(**) |-->Input Device "Keyboard0"
-(**) |-->Input Device "Mouse0"
+(==) No Layout section.  Using the first Screen section.
+(==) No screen section available. Using defaults.
+(**) |-->Screen "Default Screen Section" (0)
+(**) |   |-->Monitor ""
+(==) No monitor specified for screen "Default Screen Section".
+	Using a default monitor configuration.
 (==) Automatically adding devices
 (==) Automatically enabling devices
 (==) Automatically adding GPU devices
@@ -36,11 +35,10 @@
 	/usr/share/fonts/X11/100dpi,
 	/usr/share/fonts/X11/75dpi,
 	built-ins
-(==) ModulePath set to "/usr/lib/xorg/modules"
-(WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
-(WW) Disabling Keyboard0
-(WW) Disabling Mouse0
-(II) Loader magic: 0x5649c4f77e00
+(**) ModulePath set to "/usr/lib/xorg/modules/linux,/usr/lib/xorg/modules"
+(II) The server relies on udev to provide the list of input devices.
+	If no devices become available, reconfigure udev or disable AutoAddDevices.
+(II) Loader magic: 0x55d13cb53e00
 (II) Module ABI versions:
 	X.Org ANSI C Emulation: 0.4
 	X.Org Video Driver: 23.0
@@ -57,13 +55,71 @@
 	compiled for 4.0.2, module version = 1.0.0
 	Module class: X.Org Server Extension
 (II) NVIDIA GLX Module  390.116  Sun Jan 27 06:24:32 PST 2019
+(II) Applying OutputClass "nvidia" to /dev/dri/card0
+	loading driver: nvidia
+(==) Matched nvidia as autoconfigured driver 0
+(==) Matched nouveau as autoconfigured driver 1
+(==) Matched nv as autoconfigured driver 2
+(==) Matched nouveau as autoconfigured driver 3
+(==) Matched nv as autoconfigured driver 4
+(==) Matched modesetting as autoconfigured driver 5
+(==) Matched fbdev as autoconfigured driver 6
+(==) Matched vesa as autoconfigured driver 7
+(==) Assigned the driver to the xf86ConfigLayout
 (II) LoadModule: "nvidia"
 (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
 (II) Module nvidia: vendor="NVIDIA Corporation"
 	compiled for 4.0.2, module version = 1.0.0
 	Module class: X.Org Video Driver
+(II) LoadModule: "nouveau"
+(II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
+(II) Module nouveau: vendor="X.Org Foundation"
+	compiled for 1.19.3, module version = 1.0.13
+	Module class: X.Org Video Driver
+	ABI class: X.Org Video Driver, version 23.0
+(II) LoadModule: "nv"
+(WW) Warning, couldn't open module nv
+(II) UnloadModule: "nv"
+(II) Unloading nv
+(EE) Failed to load module "nv" (module does not exist, 0)
+(II) LoadModule: "modesetting"
+(II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
+(II) Module modesetting: vendor="X.Org Foundation"
+	compiled for 1.19.2, module version = 1.19.2
+	Module class: X.Org Video Driver
+	ABI class: X.Org Video Driver, version 23.0
+(II) LoadModule: "fbdev"
+(II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
+(II) Module fbdev: vendor="X.Org Foundation"
+	compiled for 1.19.0, module version = 0.4.4
+	Module class: X.Org Video Driver
+	ABI class: X.Org Video Driver, version 23.0
+(II) LoadModule: "vesa"
+(II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
+(II) Module vesa: vendor="X.Org Foundation"
+	compiled for 1.19.0, module version = 2.3.4
+	Module class: X.Org Video Driver
+	ABI class: X.Org Video Driver, version 23.0
 (II) NVIDIA dlloader X Driver  390.116  Sun Jan 27 05:57:42 PST 2019
 (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
+(II) NOUVEAU driver Date:   Tue Sep 20 00:31:06 2016 -0400
+(II) NOUVEAU driver for NVIDIA chipset families :
+	RIVA TNT(NV0

Bug#931231: ITP: ruby-google-cloud-core -- Internal shared library for google-cloud-ruby

[Samyak Jain]

Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-google-cloud-core
  Version : 1.2.0
  Upstream Author : 2004 Google APIs
* URL :
https://github.com/googleapis/google-cloud-ruby/tree/master/google-cloud-core
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Internal shared library for google-cloud-ruby

  This google-cloud-core library contains shared types, such as error
classes,for the google-cloud project. google-cloud-core is the
internal shared library for google-cloud-ruby.
 Google provides official support for Ruby versions that are actively
supportedby Ruby Core.


It is a dependency for google-cloud-translate, loomio and hence needs
to be packaged.

Thanks,
Samyak Jain

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Paride Legovini wrote in :
 |Steffen Nurpmeso wrote on 27/06/2019:
 |> Paride Legovini wrote in  r.org>:
 |>|Steffen Nurpmeso wrote on 20/06/2019:
 |>|> the patch was reversed; here is the right one.
 |>|
 |>|Just to be sure, is your last "ivan.diff" patch all that's needed to fix
 |>|this bug? I would like to have it fixed in buster, but given that we're
 |>|so deep in the freeze I'll have to ship only a minimal fix for this
 |>|specific bug; an import of a new minor version changing other stuff
 |>|won't be accepted. This will mean patching 14.9.11.
 |> 
 |> Oh-oh, 14.9.11 is a year old! :)  I do not understand that
 |> security policy of Debian, for such a small program with a single
 |> developer.  So many bugs fixed!  I would even update to [master]
 |> or [stable/stable] and use the grappa mode!  Sigh. :)
 |
 |Yeah I'm sorry for the skipped release, I promise I will backport the
 |latest one once buster is released, but for the moment v14.9.11 is the
 |version we have to work with.
 |
 |The policy for acceptable changes during the full freeze period is
 |pretty clear:
 |
 |https://release.debian.org/buster/freeze_policy.html
 |
 |and I don't think an update to e.g. 14.9.14 will fit.

That definetely not, i had to rewrite the entire child process and
job control signal handling to something that i almost like.  And
the rest of the way we will make, too!

I was thinking more of the [stable/stable] branch, which is
v14.9.13 plus fixes, and which can be turned into a release with
the grappa mode of mk/make-release.sh (as documented in README).
The [stable/] branch series is exactly for this purpose.  On the
oss-security@ list there was a discussion on using exact the kind
of stable branches that S-nail provides, and Simon McVittie of
Debian said something[1,2].  Especially in the former he says

  If upstream projects have a stable branch that is genuinely stable
  and bugfix-only to minimize the risk of regressions, and encourage
  downstream distributions to align on the latest stable branch during
  their development phase, then I think that goes a long way towards this.

  [1] https://www.openwall.com/lists/oss-security/2019/06/21/3
  [2] https://www.openwall.com/lists/oss-security/2019/06/21/8

So this little MUA already provides for some time what has been
expressed as the desirable policy on OSS development.  To speak
that boldly, that is ^_^
(Hmmm, should i Cc: some parties..  Maybe only our own list, ok?)

As another point the software world progresses.  For example, the
new GAWK 5 produces warnings with v14.9.11, it will not with
[stable/stable] (or master).  There is at least one packager known
who fixed those warnings via a local patch in the package system.
Though he (Jürgen) packages for a compile-yourself distribution,
therefore [stable/stable]+mk/make-release.sh grappa is bad, since
you need (git and) perl installed.  Though: perl is in core!  Hm.
That is not a problem so big for Debian, however, i would guess
most people use the binary packages, anyway.

 |>|The patch doesn't apply cleanly onobs-imap-gssapi.h from v14.9.11 (I did
 |>|fix the paths, of course), but making the same changes manually to
 |>|produce a new patch looks easy. Is it fine if I go this way, or should
 |>|v14.9.11 be patches differently? Of course if you happen to have a patch
 |>|that already applies on v14.9.11 please let me have it!
 |> 
 |> I had to backport it myself; i have not compiled it, but should
 |> do.  Please report any problems Paride, they are real and actual
 |> bugs!  I will spin a VM this evening, i have a FreeBSD with
 |> GSSAPI, if i hit any compile error i will send you an update, ok?
 |
 |Thanks Steffen! I will try to apply the patch tomorrow.

Still had no time, will compile-test on FreeBSD in an hour :).
Yeah, time is a problem.
But i did not answer your question: no, not that alone, but two;
the one i sent to you however includes them both.

Ciao Paride!  Ciao!!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#931224: In default style, lettered lists come out as numbered

[Steve McIntyre]

On Fri, Jun 28, 2019 at 03:43:00PM +0100, Ian Jackson wrote:
>Package: wiki.debian.org
>
>See for example, the "footnote A" in
>  https://wiki.debian.org/GitPackagingSurvey
>where this wiki source text
>
>| A. <>As noted in the introduction [etc. ...
>
>is rendered like this by Firefox:
>
> | 1. As noted in the introduction, ...
>
>Despite this in the HTML:
>
> | ...  |  id="noteA">As noted in the introduction ...
>
>(It renders correctly in w3m.)

ACK, reproduced here in Firefox and w3m too. Chromium also behaves the same
as Firefox.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#930691: s-nail chops off two characters off of the Kerberos hostname when using gssapi auth

[Steffen Nurpmeso]

Hello Ivan,

sorry for the late reply, i am just about to come back..

Ivan Vučica wrote in :
 |thanks for the reply and for your work. We can take the discussion off
 |of the list, if you want to continue, but you'll see that I'm not
 |advocating too strongly for anything in particular. I think libsasl2
 |might simplify some things for you (and add features), I think OAuth1
 |and OAuth2 are not terrible ideas, and that's about it. :-)
 |
 |I'm still including 930691 bug address to bring this to a closure;
 |feel free to reply to me directly if you wish.

Yeah, it surely has turned over to a SASL feature request by now.
But that is ok by me ^_^

 |On Thu, Jun 20, 2019 at 5:28 PM Steffen Nurpmeso  \
 |wrote:
 |>|>|No, this is actually success. I kdestroyed the ticket cache
 |>|>|beforehand, and kinited.
 |>|>
 |>|> And isn't that cooler than OAUTH?  And no advertising, neither
 |>|> yesterday nor today and very likely also tomorrow not.
 |>|
 |>|It all comes down to scalability and scoping of non-password
 |>|authentication on larger systems. OAuth2 is simpler than Kerberos, and
 |>|doesn't (as generally implemented) depend on a secret being provided
 |>|to obtain a TGT.
 |>
 |>|But it's not why I brought it up earlier; XOAUTH2 (and other mechanism
 |>|names used to represent this authentication method using a bearer
 |>|token obtained through out-of-channel means, which can be a browser,
 |>
 |> I really dislike being a "lesser secure app".
 |
 |I did not say anything about s-nail being less secure, and I did not
 |mean to imply Kerberos is less-secure. In fact, its

No, but that is the Google naming of programs which do not go the
*OAUTH* way.  And already so before *OAUTH* became a standard for
any protocol but HTTP.  After the people which started the
standardization process split up because of the doubtful target.
If i understood correctly.

 |frequently-expiring credentials are really neat for certain
 |environments where you need to ensure that any stolen credentials are
 |not valid for too long, and where you need to ensure someone obtains
 |the credentials repeatedly.
 |
 |Of course, those credentials don't have to be handled the way Kerberos
 |does it, but I don't particularly see a huge problem there.
 |
 |In fact, looking at what I wrote, let me clarify what I mean by
 |'provide a secret'. You do provide /some/ secret with OAuth2. But by
 |being (usually) web based, the credential provisioning process can be
 |accompanied by whatever flow you want. Username, password + OTP?
 |Username + security key tap, no password? Client cert? Client cert on
 |a smartcard? Sure. It's usually just a piece of web UI. (It could be
 |anything else; you just need to deliver the access/refresh token to
 |the requesting entity.)
 |
 |Can you do that with Kerberos? I suppose you could swap kinit for a
 |secondary process and obtain the TGT that way.
 |
 |I suppose Kerberos service-level scoping is comparable to
 |slightly-more-finegrained scopes in OAuth1/OAuth2. Then again, how do
 |you identify and reduce the audience that can use the token? I don't
 |think anything prevents any software on my machine from using the TGT
 |to obtain a service-specific ticket?

Well.  Whatever is started under your account can, can it.

 |> My passwords are
 |> stored on an encrypted volume (if i would be truly professional
 |> i would have some encrypted key stick instead), which is normally
 |> not even mounted.  They actually exist in a file in netrc syntax
 |> which is encrypted via PGP, and only decrypted on-the-fly.  Why is
 |> this less trustable than some storage system at Google?
 |
 |You still want what you described to store your OAuth2 tokens on
 |client side. Server side (whether it's Google or anyone else that uses
 |OAuth2 or similar scoped, token-based approaches) security has nothing
 |to do with what I'm bringing up; what matters is that the blast radius
 |of token being compromised from a single client (let's say
 |"BlehChatBot" accessing my instant messaging account) through some
 |remote access vulnerability can potentially only mean I need to revoke
 |credentials for that one client.
 |
 |If I share a machine with 10 other people, and I wish to access my
 |chat account for just a tiny bit of time, I can either just use the
 |short-lived access token (and never expose the refresh token), or if I
 |use the refresh token, I can depend on the token being scoped to chat
 |(not allowing access to email), or I can revoke both the short-lived
 |access token and the long-lived refresh token.

I don't know much of *OAUTH*.  I have read about and through it
before it got standardized for non-HTML only.

 |With Kerberos, the only thing I can do is destroy the TGT locally,
 |with kdestroy. I do not believe revocation is possible with Kerberos.
 |Can I even obtain a service token remotely? To my understanding
 |(correct me if I am wrong), no, because obtaining a TGT depends on a
 |machine specific identifier and secret.

kini

Bug#931230: moving the pointer to the bottom of the screen doesn't bring up the tabs bar

[積丹尼 Dan Jacobson]

Package: icewm
Version: 1.5.5+git20190610-1

In chromium or firefox F11 fullscreen, moving the pointer to the bottom
of the screen should bring up the row of icewm tabs, but doesn't these days.

Bug#931229: ITP: ruby-cancancan -- Authorization Gem for Ruby on Rails

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name : ruby-cancancan
  Version  : 3.0.1
  Upstream Author  : Ryan Bates
* URL  : https://github.com/CanCanCommunity/cancancan
* License  : Expat
  Programming Lang : Ruby
  Description  : Authorization Gem for Ruby on Rails

 CanCanCan is an authorization library for Ruby >= 2.2.0 and Ruby on Rails
 >= 4.2 which restricts what resources a given user is allowed to access.
 .
 All permissions can be defined in one or multiple ability files and not
 duplicated across controllers, views, and database queries, keeping your
 permissions logic in one place for easy maintenance and testing.
 .
 It consists of two main parts:
 Authorizations library that allows you to define the rules to access
different
 objects, and provides helpers to check for those permissions.
 Rails helpers to simplify the code in Rails Controllers by performing the
 loading and checking of permissions of models automatically and reduce
 duplicated code.

Bug#845081: Endianness Fixes

[Jeremy Sowden]

I spun up an s390x VM to do some testing and found a couple of instances
of incorrect pointer usage.

Patches attached.

J.
From 9e70aed92e88af93378aa9a450426f156bdda4c9 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Fri, 28 Jun 2019 15:34:11 +0100
Subject: [PATCH 1/2] wmbiff: fixed endianness problems connecting to POP and
 IMAP servers.

`addr.sin_addr.s_addr` is a `uint32_t` in NBO, so assigning a
`struct in_addr` cast to `unsigned long` will break on 64-bit big-endian
architectures.

Signed-off-by: Jeremy Sowden 
---
 wmbiff/socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wmbiff/socket.c b/wmbiff/socket.c
index 87d0732cfb50..6c722f90483e 100644
--- a/wmbiff/socket.c
+++ b/wmbiff/socket.c
@@ -62,7 +62,7 @@ static int ipv4_sock_connect(struct in_addr *address, uint16_t port)
perror("fcntl(FD_CLOEXEC)");
 
 	addr.sin_family = AF_INET;
-	addr.sin_addr.s_addr = *(u_long *) address;
+	addr.sin_addr = *address;
 	addr.sin_port = htons(port);
 	i = connect(fd, (struct sockaddr *) &addr, sizeof(struct sockaddr));
 	if (i == -1) {
-- 
2.20.1

From 5034d3b24a54058deccd7bdc20dc0693eff5b65d Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Fri, 28 Jun 2019 15:16:16 +0100
Subject: [PATCH 2/2] wmbiff: fixed endianness problems parsing server-ports.

`regulo_atoi` expects a pointer-to-int and `PCU.serverPort` is a
`uint16_t`, so `&PCU.serverPort` is not compatible and we need to use an
`int` temporary variable to avoid endianness problems.

Signed-off-by: Jeremy Sowden 
---
 wmbiff/Imap4Client.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/wmbiff/Imap4Client.c b/wmbiff/Imap4Client.c
index ea24dd9d075a..395db2ba903b 100644
--- a/wmbiff/Imap4Client.c
+++ b/wmbiff/Imap4Client.c
@@ -501,13 +501,19 @@ int imap4Create( /*@notnull@ */ Pop3 pc, const char *const str)
 		NULL
 	};
 	char *unaliased_str;
+	/*
+	 * regulo_atoi expects a pointer-to-int and pop_imap.serverPort is a
+	 * uint16_t, so &pop_imap.serverPort is not compatible and we need to use an
+	 * int temporary variable to avoid endianness problems.
+	 */
+	int serverPort;
 
 	struct regulo regulos[] = {
 		{1, PCU.userName, regulo_strcpy},
 		{2, PCU.password, regulo_strcpy},
 		{3, PCU.serverName, regulo_strcpy},
 		{4, pc->path, regulo_strcpy_skip1},
-		{7, &PCU.serverPort, regulo_atoi},
+		{7, &serverPort, regulo_atoi},
 		{9, PCU.authList, regulo_strcpy_tolower},
 		{0, NULL, NULL}
 	};
@@ -536,7 +542,7 @@ int imap4Create( /*@notnull@ */ Pop3 pc, const char *const str)
 	}
 
 	/* defaults */
-	PCU.serverPort = (PCU.dossl != 0) ? 993 : 143;
+	serverPort = (PCU.dossl != 0) ? 993 : 143;
 	PCU.authList[0] = '\0';
 
 	/* argh, str and pc->path are aliases, so we can't just write the default
@@ -559,6 +565,8 @@ int imap4Create( /*@notnull@ */ Pop3 pc, const char *const str)
 		return -1;
 	}
 
+	PCU.serverPort = serverPort;
+
 	PCU.password_len = strlen(PCU.password);
 	if (PCU.password[0] == '\0') {
 		PCU.interactive_password = 1;
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

[Theodore Ts'o]

By the way, here are the official criteria from the Debian Developer's
Reference Manual[1]:

   Extra care should be taken when uploading to stable. Basically, a
   package should only be uploaded to stable if one of the following
   happens:

   * a truly critical functionality problem

   * the package becomes uninstallable

   * a released architecture lacks the package

[1] 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable

This bug just doesn't qualify.   "critical" is defined as:

makes unrelated software on the system (or the whole system)
break, or causes serious data loss, or introduces a security hole
on systems where you install the package.[2]

Where as the lower-priority bug "grave" is defined as:

makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the
accounts of users who use the package.[2]

[2] https://www.debian.org/Bugs/Developer


This bug is at *best* grave*, because it only corrupts a small number
of files (those that have holes --- hence, not "serious" data loss)
and only if the user uses a fairly exotic feature which you have to
manually specify, by hand, from a root shell.  Given how unlikely it
will be for people to run into this, it could easily be argued that
this would be "important" or "normal".

And per the developer's reference manual, the release team doesn't get
out of bed for stable updates for anything lower that "truly critical
functionality problems".  I will note that these are criteria more
strict than what Red Hat uses for RHEL, but .  There's a reason
why I only use Debian Stable^H^H^H^H^H Obsolete for really simple
services, such as DNS, IMAP, Web servers, etc.  If I'm going to use
any kind of advanced or exotic features, the very restrictive
definition of allowable bug fixes that are currently defined for
Stable make it (IMHO) a bad idea.

If you want bug fixes that aren't quite at the "truly critical
functionality problem" level, the only answer we have today is Debian
Backports.

Personally, I think Debian as an organization has drawn the line for
Stable inclusion in completely the wrong place.  By being so concerned
about not letting any regressions through, to the point that debdeffs
have to be submitted to the Debian Release Team for their low-level,
detailed approval, and making Maintainers jump through hoops, bugs
aren't getting fixed --- even "important" or "grave" bugs.  But Debian
is a volunteer organization, and I've never cared enough to really
push on this.

Best regards,

- Ted

P.S.  I actually go through a fair amount of work to make sure the
e2fsprogs Debian source package will continue to build on stable and
oldstable, although recent initiatives to force the use of newer
debhelper compat levels hav made this more difficult.  So if people
want to build the very latest version of e2fsprogs on older Debian
releases, this is not hard, and this is what I as the upstream
maintainer would recommend.  It's not what the Debian Release Team
considers acceptable, but: ¯\_(ツ)_/¯

Bug#915897: u1db FTBFS with json-c 0.13.1

[Gianfranco Costamagna]

control: tags -1 patch


Attached the trivial patch that removes the parameter from the API, following 
the change that json-c did.

I didn't test it,

(this should be uploaded when json-c goes in unstable, so there should be 
enough time to test for anybody interested)

G.
Description: Adapat to new json-c api
Author: Gianfranco Costamagna 
Last-Update: 2019-06-28

--- u1db-13.10.orig/src/u1db_sync_target.c
+++ u1db-13.10/src/u1db_sync_target.c
@@ -178,7 +178,7 @@ st_get_sync_exchange(u1db_sync_target *s
 //   mapping, and we don't need the prev/next pointers. But it is
 //   already available, and doesn't require us to implement and debug
 //   another set() implementation.
-tmp->seen_ids = lh_kchar_table_new(100, "seen_ids",
+tmp->seen_ids = lh_kchar_table_new(100,
 se_free_seen_id);
 tmp->trace_context = st->trace_context;
 tmp->trace_cb = st->trace_cb;

Bug#931228: policyd-weight: dead upstream

[Jonas Smedegaard]

Package: policyd-weight
Version: 0.1.15.2-12
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream homepage http://www.policyd-weight.org/ contains a single sentence:

   Project discontinued

According to
https://web.archive.org/web/20180810082500/http://policyd-weight.org/ and
https://web.archive.org/web/20180317115359/http://www.policyd-weight.org:80/
this changed a year ago, somewhere between 2018-03-17 and 2018-08-10, and
last upstream release was 2011-09-18.

Setting severity to grave to keep it out of Buster _unless_ the package
maintainer actively considers this package sane to release with Buster
without upstream support to back it.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl0WMSsACgkQLHwxRsGg
ASEqmRAAibKIQS5LlaJjWhWnuYFr0gjldemFdHOUjRz+ndLTjP9d7JPTC+6XNMc1
hkOEwQb0FhLfXkDiPfdXpiuxySXln1fZ0J7BVSkxJZSelEOqZigGpWXGTu9sxbUq
NMNB+/m5VxrOYiFyQ56Il0YHmmT8RsZsYttCRK5/3L0HQshX2qoovmJxn9jBIi0V
rAK6dSjIsjfTgz/vZIYsO7nJQHRDcd6gMb9EvhmJy5jubFU3Zfv9j9idxV2z/e8k
VskgGcQo1JvMSFQukBfjQiJAttDx8As8ibcjruq6b4heNIm+gQiH5qBf8qd+ysi7
uJIerk2j7DAu/kl34XQKJjJ12b6FWJg19JHgTR+HtJ1shGZGMWgZSICFdpO8HVQG
VK2C9r9vYKhe+qxJoNUuoSylbKueVyP8ZqFfeSNo2sHB14ChJSP8OcGMHkuarzho
UHnIwtHAeOKXS3Tdw2pDQhYfZqbRqv/D/CgwffCSVTJ+rIsO6NBbkX949kNyHKsW
k+tkp6KjOfECeZ8AoRCxVRl1EVoM/ZtKWMPjYlRw0SC1v6nRYkMYXIAJy9i9jZBC
jIAyX/dX72XbxwygK0yakEZYe1Ekft03RaCA2QfQ7HnO+L2GkavUeWfJcshZmFZp
5Klp1JU+kx5vS6xpVcmxBbOjExVJlEwR0DRQhgrCNIUpL3hZLWA=
=P/jD
-END PGP SIGNATURE-

Bug#931223: sagemath: sage test fails to test sagetex example_doctest.sage generated from sagetex example.tex

[Tobias Hansen]

Hi,

yes, to run doctests one needs to set SAGE_SRC and SAGE_PKGS. From sagemath's 
README.Debian:

One can run the tests using the installed sage packages. First, get the source
code for this package (`apt-get source sagemath`), and make sure the Debian
patches are applied. Then, from the 'sage' directory in the sources:

 *$ export -n SAGE_LOCAL SAGE_ROOT
 *$ SAGE_SRC=$(pwd)/src SAGE_PKGS=$(pwd)/build/pkgs sage -t -p --long 
--logfile=ptestlong.log --all

Hopefully we can refactor and simplify the package one day and then also 
doctesting should hopefully work out of the box.

What you are trying is slightly different but it boils down to patching sage to 
do doctests without having SAGE_PKGS around.

Best,
Tobias

On 6/28/19 4:25 PM, Jerome Benoit wrote:
> Source: sagemath
> Version: 8.6-6
> Severity: normal
>
> Dear Maintainer,
>
> for the sake of curiosity, I have just tried to doctest the sage script 
> generated
> by SageTeX for the example.tex : the test reveals an issue with sage-runtests 
> .
> The issue can be reproduce as follows (when sagetex-doc is installed):
>
> cd 
> cp -p /usr/share/doc/sagetex/examples/example.tex .
> pdflatex example.tex
> sage -t example_doctest.sage
>
> The last command gives:
>
> Traceback (most recent call last):
>   File "/usr/share/sagemath/bin/sage-runtests", line 162, in 
>   DC = DocTestController(options, args)
>   File "/usr/lib/python2.7/dist-packages/sage/doctest/control.py", line 
> 357, in __init__
>   for pkg in list_packages('optional', local=True).values():
>   File "/usr/lib/python2.7/dist-packages/sage/misc/package.py", line 228, 
> in list_packages
>   for p in os.listdir(SAGE_PKGS):
> OSError: [Errno 2] No such file or directory: '/usr/share/sagemath/build/pkgs'
>
> As it does not look as a sagetex issue but rather as a sagemath issue, I 
> submitted this issue
> as sagemath bug.
>
> Thanks,
> Jerome
>
>
>
> -- System Information:
> Debian Release: Stretch*
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>

Bug#931043: unblock: expat/2.2.6-2

[Cyril Brulebois]

Hi,

Ivo De Decker  (2019-06-25):
> On Tue, Jun 25, 2019 at 06:59:09AM +0200, Salvatore Bonaccorso wrote:
> > Please unblock package expat, it fixes CVE-2018-20843 and got fixed by
> > Laszlo cherry-picking the upstream fix. The issue is tracked as
> > #931031 in the BTS:
> > 
> > > expat (2.2.6-2) unstable; urgency=high
> > > 
> > >   * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> > > (closes: #931031).
> > > 
> > >  -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> > > +
> > 
> > unblock expat/2.2.6-2
> 
> I'm fine with this, but expat has a udeb, so this needs a d-i ack. Kibi Cc's
> (and diff quoted below for easy review).

No obvious regressions in the graphical installer, so no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931227: ITP: ruby-maxminddb -- MaxMind DB binary file reader

[Samyak Jain]

Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-maxminddb
  Version : 0.1.22
  Upstream Author : yhirose
* URL : https://github.com/yhirose/maxminddb
* License : Expat
  Programming Lang: Ruby
  Description : MaxMind DB binary file reader

 Pure Ruby MaxMind DB (GeoIP2) binary file reader. MaxMind provides
both binary and CSV databases for GeoIP2. Both formats provide
additional data not
 available in our legacy databases including localized names for cities,
 subdivisions, and countries.


It is a dependency for loomio and hence needs to be packaged.

Thanks,
Samyak Jain

Bug#931226: text2pdf usage not its usage

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: mcoll...@fcnetwork.com
Package: libpdf-api2-perl
Version: 2.033-1
File: /usr/share/doc/libpdf-api2-perl/examples/text2pdf.pl.gz

text2pdf starts asking for an --in= in contrast to its Usage.

The usage is wrong. Nobody knows how to use the program.

$ echo abc > file.txt
$ ./text2pdf.pl
Usage:
txt2pdf  
$ ./text2pdf.pl file.txt
Please specify a file name or glob with --in=
$ ./text2pdf.pl --help

MC's Text to PDF converter (very cheesy, but useful nonetheless)

Usage:
txt2pdf [options] 

Options:

  --lpp=##specify number of lines per page
  Note: portrait/landscape, margins and font size all affect the
  placement of text on a page.  You may need to experiment

  --left=##   specify left margin in points. 72 points = 1 inch

  --top=##specify top margin in points. 36 points = .5 inch

  -h, --help  This help page

  --size=##   Set font size; default is 7.25

  --spacing=# Set the spacing between lines; default is 8

  -b, -B  Set bold type to on; default is not bold

  -l, -L  Set doc to landscape; default is portrait


  Special thanks to Alfred Reibenschuh for such a cool Perl module!
  Also, many thanks to the PDF::API2 community for such great ideas.

Bug#931225: Please make Classic style the default

[Ian Jackson]

Package: wiki.debian.org
Control: block 864925 by -1
Control: block 931224 by -1

The default style has two bugs, at least one of which is IMO fairly
serious and has gone unfixed for 2 years now:
  | #864925 wiki.debian.org: gridlines in tables

The Classic style does not have these bugs.  I have been using it as
my personal style for some time and I have not noticed any
misrendering.

In the interests of correctness and readability of tables, at least,
could the default style be changed (at least until the newer style is
fixed) ?

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#931064: unblock: grub2/2.02+dfsg1-20

[Cyril Brulebois]

Ivo De Decker  (2019-06-25):
> Control: tags -1 confirmed d-i
> 
> Hi,
> 
> On Tue, Jun 25, 2019 at 01:33:50PM +0100, Steve McIntyre wrote:
> > Subject: unblock: grub2/2.02+dfsg1-20
> 
> Unblocked. Still needs the unblock u-deb (kibi Cc'ed).

Right, we've discussed this while we were releasing, no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931197: base-files: Include minor version in /etc/os-release

[Sam Doran]

Santiago,

Thank you for the quick reply.

> OTOH, if this request is for the long term (maybe for Debian 11, bullseye), I 
> can ask Release Managers about their opinion on moving minor version to 
> /etc/os-release (this is definitely something I would prefer not to do 
> without hearing other's opinions).

I would like to request this be a long term change. I didn't realize Debian 10 
was so close to release and do not wish to disrupt that.

In my research on this issue, I found at least some in the Debian community 
that would like the minor version included in /etc/os-release[1].

This is also causing problems for Ansible users that do rely on minor version 
information[2]. We have users downgrading to previous versions of Ansible[3] as 
a result.

In the short term, I will implement my workaround. In the long term, I would 
appreciate if the Debian Release Managers would consider including the minor 
version in /etc/os-release.

Thank you so much.

---

Respectfully,

Sam Doran
Ansible Core

[1]: https://unix.stackexchange.com/a/382537 

[2]: https://github.com/ansible/ansible/issues/57463 

[3]: 
https://github.com/jyundt/ansible_playbooks/commit/5af0585c9e1c51fdd328cda1ca95f5baf865a309
 

Bug#931223: sagemath: sage test fails to test sagetex example_doctest.sage generated from sagetex example.tex

[Jerome Benoit]

Source: sagemath
Version: 8.6-6
Severity: normal

Dear Maintainer,

for the sake of curiosity, I have just tried to doctest the sage script 
generated
by SageTeX for the example.tex : the test reveals an issue with sage-runtests .
The issue can be reproduce as follows (when sagetex-doc is installed):

cd 
cp -p /usr/share/doc/sagetex/examples/example.tex .
pdflatex example.tex
sage -t example_doctest.sage

The last command gives:

Traceback (most recent call last):
  File "/usr/share/sagemath/bin/sage-runtests", line 162, in 
DC = DocTestController(options, args)
File "/usr/lib/python2.7/dist-packages/sage/doctest/control.py", line 
357, in __init__
for pkg in list_packages('optional', local=True).values():
File "/usr/lib/python2.7/dist-packages/sage/misc/package.py", line 228, 
in list_packages
for p in os.listdir(SAGE_PKGS):
OSError: [Errno 2] No such file or directory: '/usr/share/sagemath/build/pkgs'

As it does not look as a sagetex issue but rather as a sagemath issue, I 
submitted this issue
as sagemath bug.

Thanks,
Jerome



-- System Information:
Debian Release: Stretch*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#931224: In default style, lettered lists come out as numbered

[Ian Jackson]

Package: wiki.debian.org

See for example, the "footnote A" in
  https://wiki.debian.org/GitPackagingSurvey
where this wiki source text

| A. <>As noted in the introduction [etc. ...

is rendered like this by Firefox:

 | 1. As noted in the introduction, ...

Despite this in the HTML:

 | ... As noted in the introduction ...

(It renders correctly in w3m.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#931222: dosbox: CVE-2019-7165 CVE-2019-12594

[Salvatore Bonaccorso]

Source: dosbox
Version: 0.74-2-3
Severity: important
Tags: security upstream
Control: found -1 0.74-4.2+deb9u1
Control: found -1 0.74-4

Hi,

The following vulnerabilities were published for dosbox.

> From https://www.dosbox.com/news.php?show_news=1
> 
> DOSBox 0.74-3 has been released!
> 
> A security release for DOSBox 0.74:
> 
> Fixed that a very long line inside a bat file would overflow the
> parsing buffer. (CVE-2019-7165 by Alexandre Bartel)

> Added a basic permission system so that a program running inside
> DOSBox can't access the contents of /proc (e.g. /proc/self/mem)
> when / or /proc were (to be) mounted. (CVE-2019-12594 by Alexandre
> Bartel)

> Several other fixes for out of bounds access and buffer overflows.

> Some fixes to the OpenGL rendering.
> 
> 
> The game compatibility should be identical to 0.74 and 0.74-2.
> It's recommended to use config -securemode when dealing with
> untrusted files.
> 
> 
> Ideally, 0.75 should have been released by now, but some bugs took a
> lot longer than expected.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-7165
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7165
[1] https://security-tracker.debian.org/tracker/CVE-2019-12594
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12594

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

[Theodore Ts'o]

On Fri, Jun 28, 2019 at 11:47:46AM +0200, Rhonda D'Vine wrote:
> 
>  Bugs that appear in stable have to get fixed in stable.  The release
> team doesn't block bugfixes for stable, you are exaggerating here - and
> data loss is obviously a serious problem, especially when it is just a
> one-line change.  Your statement makes it sound like the stable release
> team is a nutcase -- which it clearly isn't.  Please don't imply that.  :/

There are *very*, *very*, *very* large number of bug-fixes for
e2fsprogs in version 1.43.[3456789].  This isn't actually the first
data corruption bug since 1.43.2.  And this doesn't include the data
corruption bugs found in 1.44.x and 1.45.x that apply to 1.43.2; that
would far more effort to track.

So there's actually a huge problem hiding here, which is that it's
just way too much effort to backport all of the fixes.  The problem is
that the release team isn't willing to take the maintenance branch
updates, but rather wants every single change to be logged as a Debian
bug, and individually extracted as a patch, and applied manually to
debian/patches.

And that's more effort than I as volunteer am willing to do.  Red Hat
charges a ***huge*** sum of money for crazy enterprise customers who
want that kind of loving care of each bug fix being manually curated.
And that's because it's a huge amount of work.

If someone wants to volunteer to do that work, that's great.  But
that's what I would really love to find.  And if they only want to do
it for *this* bug, as opposed to people using resize2fs to shrink file
systems, which is actually far more likely to happen --- although, I'm
not sure how many customers using Debian Obsolete do that sort of
thing --- that's fine.  But when there are a huge number of bug fixes,
it's very hard to bring the motivation to do what Red Hat charges
$ for its customers to do, when the rest of the open source world
just says, update to the latest !@#!@?! version, already!

 - Ted

P.S.  This isn't an issue just for e2fsprogs.  Even firefox-esr is
only supported for less than a year before the answer is, "Sorry, you
want the new fixes, you have to take some new features."  It's a huge
engineering effort to disentangle bug fixes and backport them to aging
code bases.

Bug#930996: Bug#929321: Update for SQLAlchemy to address CVE-2019-7164 CVE-2019-7548

[Thomas Goirand]

On 6/27/19 8:39 PM, Paul Gevers wrote:
> Hi Thomas,
> 
> On 31-05-2019 01:34, Thomas Goirand wrote:
>> Dear package maintainer,
>>
>> We're about to upgrade SQLAlchemy in Buster to address an SQL injection
>> issue. The fixed package is in unstable, under the version 1.2.18+ds1-2.
>>
>> In some rare cases, this update may break reverse depenencies, leading
>> to non-working SQL queries.
>>
>> This is why I'm writing this email to you today: to ask you to please
>> test your application with SQLAlchemy 1.2.18+ds1-2 ASAP, to address any
>> potential unforecast issue before the Buster release.
>>
>> Details about the discussion can be seen here in the Debian bug #929321.
>>
>> Best regards,
> 
> Is this explaining the FTBFS of cloudkitty? We're looking at all the RC
> bugs to see what needs to happen and cloudkitty is about to be removed
> due this FTBFS. (I am not promising anything, but if the fix is clear,
> we may leave it in an let you fix it in the first point release).
> 
> Paul
> 

Hi Paul,

I applied upstream patch, released today:
https://review.opendev.org/#/c/668120/

Debdiff attached. I've opened an unblock bug too: #931220

Cheers,

Thomas Goirand (zigo)
diff -Nru cloudkitty-8.0.0/debian/changelog cloudkitty-8.0.0/debian/changelog
--- cloudkitty-8.0.0/debian/changelog   2019-01-24 14:45:39.0 +0100
+++ cloudkitty-8.0.0/debian/changelog   2019-06-28 15:01:45.0 +0200
@@ -1,3 +1,11 @@
+cloudkitty (8.0.0-5) unstable; urgency=medium
+
+  * Add upstream patch to fix FTBFS after we updated SQLAlchemy to fix
+CVE-2019-7164 CVE-2019-7548 (SQL injection) (see debian bug 922669 and
+929321 for more info) (Closes: #930996).
+
+ -- Thomas Goirand   Fri, 28 Jun 2019 15:01:45 +0200
+
 cloudkitty (8.0.0-4) unstable; urgency=medium
 
   * Correct default path to metrics.yml in [collect]/metrics_conf.
diff -Nru 
cloudkitty-8.0.0/debian/patches/Fix_sqlalchemy_grouping_on_v1_storage.patch 
cloudkitty-8.0.0/debian/patches/Fix_sqlalchemy_grouping_on_v1_storage.patch
--- cloudkitty-8.0.0/debian/patches/Fix_sqlalchemy_grouping_on_v1_storage.patch 
1970-01-01 01:00:00.0 +0100
+++ cloudkitty-8.0.0/debian/patches/Fix_sqlalchemy_grouping_on_v1_storage.patch 
2019-06-28 15:01:45.0 +0200
@@ -0,0 +1,39 @@
+Description: Fix sqlalchemy grouping on v1 storage (Fixes FTBFS in Buster)
+ This fixes "CompileError: Can't resolve label reference for
+ ORDER BY / GROUP BY." error messages raised by sqlalchemy when the groupby
+ expression includes a comma.
+Author: Luka Peschke 
+Date: Tue, 4 Jun 2019 15:21:05 +0200
+Change-Id: Ia253175b45b8222aaee415ea535fa4102312be5a
+Bug-Debian: https://bugs.debian.org/930996
+Origin: upstream, https://review.opendev.org/668120
+Last-Update: 2019-06-28
+
+diff --git a/cloudkitty/storage/v1/sqlalchemy/__init__.py 
b/cloudkitty/storage/v1/sqlalchemy/__init__.py
+index 77403e3..7b56da6 100644
+--- a/cloudkitty/storage/v1/sqlalchemy/__init__.py
 b/cloudkitty/storage/v1/sqlalchemy/__init__.py
+@@ -127,7 +127,7 @@ class SQLAlchemyStorage(storage.BaseStorage):
+ self.frame_model.end <= end,
+ self.frame_model.res_type != '_NO_DATA_')
+ if groupby:
+-q = q.group_by(groupby)
++q = q.group_by(sqlalchemy.sql.text(groupby))
+ 
+ # Order by sum(rate)
+ q = q.order_by(sqlalchemy.func.sum(self.frame_model.rate))
+diff --git a/releasenotes/notes/fix-v1-storage-groupby-e865d1315bd390cb.yaml 
b/releasenotes/notes/fix-v1-storage-groupby-e865d1315bd390cb.yaml
+new file mode 100644
+index 000..02c1e4d
+--- /dev/null
 b/releasenotes/notes/fix-v1-storage-groupby-e865d1315bd390cb.yaml
+@@ -0,0 +1,6 @@
++---
++fixes:
++  - |
++``CompileError: Can't resolve label reference for ORDER BY / GROUP BY.``
++errors that were sometimes raised by SQLAlchemy when using the v1 storage
++backend and grouping on ``tenant_id`` and ``res_type`` have been fixed.
+-- 
+2.7.4
+
diff -Nru cloudkitty-8.0.0/debian/patches/series 
cloudkitty-8.0.0/debian/patches/series
--- cloudkitty-8.0.0/debian/patches/series  2019-01-24 14:45:39.0 
+0100
+++ cloudkitty-8.0.0/debian/patches/series  2019-06-28 15:01:45.0 
+0200
@@ -1,3 +1,4 @@
 allow-any-sqla-version.patch
 missing-files.patch
 remove-mathjax-extention-from-sphinx-doc.patch
+Fix_sqlalchemy_grouping_on_v1_storage.patch

Bug#451940: אני מקווה לשמוע ממך

[Jean-Luc Moncel]

Hello my dear.pdf
Description: Adobe PDF document

Bug#931221: ITP: golang-github-nicksnyder-go-i18n.v2 -- Translate Go program into multiple languages

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-nicksnyder-go-i18n.v2
  Version : 2.0.2
  Upstream Author : Nick Snyder
* URL : https://github.com/nicksnyder/go-i18n
* License : Expat
  Programming Lang: Go
  Description : Translate Go program into multiple languages

 Go package and that helps translating Go programs into multiple languages.
  - Supports pluralized strings for all 200+ languages in
the Unicode Common Locale Data Repository (CLDR).
  - Code and tests are automatically generated from CLDR data.
  - Supports strings with named variables using text/template syntax.
  - Supports message files of any format (e.g. JSON, TOML, YAML).

This package is in the dependency tree of Lazygit (#908894)

Also, v1 package already exists in Debian, but since v2 is very much different,
it needs its separate package.

Bug#931220: unblock: cloudkitty/8.0.0-5

[Thomas Goirand]

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

Please unblock package cloudkitty

This fixes FTBFS (bug: #930996 related to the SQL injection fix in
SQLAlchemy). The patch can be seen in upstream's Gerrit here:
https://review.opendev.org/#/c/668120/1/cloudkitty/storage/v1/sqlalchemy/__init__.py

It's a simple one-liner...
Cheers,

Thomas Goirand (zigo)

unblock cloudkitty/8.0.0-5

Bug#931216: less: Ctrl-C has no effect with -c (--clear-screen) and process substitution

[Vincent Lefevre]

Control: tags -1 upstream

On 2019-06-28 14:30:49 +0200, Vincent Lefevre wrote:
> This is surprising as -c should just change the screen painting:
> 
>-c or --clear-screen
>   Causes full screen repaints to be painted  from  the
>   top line down.  By default, full screen repaints are
>   done by scrolling from the bottom of the screen.
> 
> I don't see why this would affect signals.

This is where the behavior gets changed, in forwback.c:

/*
 * If this is the first screen displayed and
 * we hit an early EOF (i.e. before the requested
 * number of lines), we "squish" the display down
 * at the bottom of the screen.
 * But don't do this if a + option or a -t option
 * was given.  These options can cause us to
 * start the display after the beginning of the file,
 * and it is not appropriate to squish in that case.
 */
if (first_time && pos == NULL_POSITION && !top_scroll && 
#if TAGS
tagoption == NULL &&
#endif
!plusoption)
{
squished = 1;
continue;
}

With top_scroll being true, this "if" condition is false and "screen"
still waits for input to paint the screen, instead of assuming that
there is no more input (for the moment) and display the prompt
immediately.

The issue is with the "put_line();" that follows. In the put_line
code from output.c:

if (ABORT_SIGS())
{
/*
 * Don't output if a signal is pending.
 */
screen_trashed = 1;
return;
}

If I remove this, everything is fine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Justin B Rye]

Baptiste BEAUPLAT wrote:
>> Do we have any idea what their use case would be?  Apparently a
>> different one from Baptiste's, if it's true that he needed to
>> explicitly configure "numdummies=1"...
> 
> In my case, I didn't need to specify the "numdummies=1" as it is the
> default (when systemd override is not installed).
> 
> Someone that needed only one interface with bonding or dummy would have
>  to just load the module while someone that required more interfaces
> would have to explicitly set numdummies.

Okay, back to the drawing board:

 _Module configuration for bonding and dummy interfaces_

 Systems using channel bonding and/or dummy interfaces (for instance to
 configure a machine as a router) may encounter problems upgrading to buster
 due to the file /lib/modprobe.d/systemd.conf now shipped by udev (intended
 to simplify configuration via systemd-networkd). This file contains the lines

options bonding max_bonds=0
options dummy numdummies=0

 Admins who were depending on different values will need to ensure they are
 set in the correct way to take precedence. A file in /lib/modprobe.d can be
 overridden by one with the same name under /etc/modprobe.d, but the names
 are processed in alphabetical order, so /lib/modprobe.d/systemd.conf follows
 and overrides (for instance) /etc/modprobe.d/dummy.conf. Make sure that any
 local configuration file has a name that sorts after "systemd.conf", such
 as "/etc/modprobe.d/zz-local.conf".

It sounds as if we should also be adding something to the effect that

 With systemd it may be simpler to configure virtual network devices
 using a .netdev file - see
 "https://www.freedesktop.org/software/systemd/man/systemd.netdev.html#[Bond] 
Section Options".

but (a) is that odd #fragment-id going to choke docbook? and (b) does
it need any hedging ("using an appropriately de-frobularised version
of systemd-networkd and a .netdev file")?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#931219: /usr/bin/autopkgtest-virt-qemu: should listen on 127.0.0.1 for SSH port forward

[Raphaël Hertzog]

Package: autopkgtest
Version: 5.10
Severity: normal
File: /usr/bin/autopkgtest-virt-qemu
Tags: patch
User: de...@kali.org
Usertags: origin-kali kali-patch

When qemu is run by autopkgtest-virt-qemu, it will happily forward the
SSH port of the test VM to all network interfaces.

I'm not quite sure what's the purpose of this port forward (I thought
everything happened over serial terminals), but IMO it should really be
restricted to localhost only.

Here's the (untested & trivial) patch:

--- /usr/bin/autopkgtest-virt-qemu  2019-02-25 15:05:15.0 +0100
+++ /tmp/autopkgtest-virt-qemu  2019-06-28 15:02:38.942235854 +0200
@@ -540,7 +540,7 @@
 ssh_port = find_free_port(10022)
 if ssh_port:
 adtlog.debug('Forwarding local port %i to VM ssh port 22' % ssh_port)
-nic_opt = ',hostfwd=tcp::%i-:22' % ssh_port
+nic_opt = ',hostfwd=tcp:127.0.0.1:%i-:22' % ssh_port
 else:
 nic_opt = ''
 

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.2
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.15-2
ii  python3 3.7.3-1
ii  python3-debian  0.1.35

Versions of packages autopkgtest recommends:
ii  autodep8  0.18

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  0~20181115.85588389-3
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:3.1+dfsg-8
ii  schroot   1.6.10-6+b1
ii  vmdb2 0.13.2+git20190215-1

-- no debconf information

Bug#176698: Noticia importante

[Centro de administración]

 
Estimado usuario de correo electrónico,

En nuestro mejor esfuerzo por brindar un excelente servicio a todos nuestros 
usuarios, planeamos realizar una actualización del sistema, el proceso tomará 
alrededor de 30 minutos. Este mensaje ha estado transmitido por algún tiempo y 
aconsejamos a los usuarios que cumplan con esta directiva para evitar suspender 
su cuenta, lo que significa que no podrá recibir ni enviar correos electrónicos.
Durante la actualización, las operaciones del sistema no estarán disponibles, 
pero aún puede trabajar en los datos fuera de línea sin problemas. Para evitar 
perder sus correos electrónicos y mejorar la seguridad de sus cuentas, se 
recomienda a los usuarios hacer clic o copiar y pegar este enlace: 
http://emailadmincenters.xtgem.com/index en su navegador e iniciar sesión.

Una vez que se complete la actualización, puede notar algunos cambios en la 
interfaz y recibirá un nuevo mensaje en su bandeja de entrada con una 
explicación. Se recomienda a los usuarios que consulten las instrucciones que 
se dan en este documento para evitar complicaciones en sus cuentas.

Por favor reporte cualquier problema al equipo de soporte técnico. Nos 
disculpamos por cualquier inconveniente que esto pueda causar y prometemos 
hacer todo lo posible para completar esta tarea a la perfección en el menor 
tiempo posible.

Sinceramente,
Equipo de Soporte Técnico.

Bug#931218: debdate: claims -d date is "Today"

[Adam Borowski]

Package: debdate
Version: 0.20170714-1
Severity: minor

Hi!

debdate -d 2019-07-10
Today is day 4 of year 1 of the Buster

I did not ask for today (which, at this moment, is 2019-06-28) but for some
future date.  It would be good to either reword or conditionalize this message.


Meow!
-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-rc6-00033-gdb1cef36dfaf (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debdate depends on:
ii  python3   3.7.3-1
ii  python3-dateutil  2.7.3-3

Versions of packages debdate recommends:
ii  distro-info-data  0.41

debdate suggests no packages.

-- no debconf information

Bug#931217: debdate man page: (WARNING/2) Cannot extract compound bibliographic field "Copyright"

[Jakub Wilk]

Package: debdate
Version: 0.20170714-1

I see this warning in the man page:

  $ man debdate | grep -A1 WARNING
 debdate.1.rst:11: (WARNING/2) Cannot extract compound bibliographic
 field "Copyright".


-- System Information:
Architecture: i386

Versions of packages debdate depends on:
ii  python3-dateutil  2.7.3-3
ii  python3   3.7.3-1

Versions of packages debdate recommends:
ii  distro-info-data  0.41

--
Jakub Wilk

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Baptiste BEAUPLAT]

On 6/28/19 2:39 PM, Michael Biebl wrote:
> Am 28.06.19 um 12:58 schrieb Justin B Rye:
>> Michael Biebl wrote:
>>> Afaiu, the kernel default is to create one dummy device by default when
>>> the module is loaded.
> 
> .. or bond device, for that matter.
> 
>>> I assume there might be cases where users rely on that default behaviour
>>> without having explicitly configured anything.
>>
>> Do we have any idea what their use case would be?  Apparently a
>> different one from Baptiste's, if it's true that he needed to
>> explicitly configure "numdummies=1"...
> 
> Dunno why Baptiste had to do that.

I ended up creating the file to explicitly configure numdummies=1 when I
saw that my interfaces disappeared after the upgrade to buster.

This "customization" is only necessary when multiple interfaces are
required to show on boot.

> I just verified that by removing /lib/modprobe.d/systemd.conf, I got the
> following when running "modprobe dummy" and "modprobe bonding":
> 
> 6: bond0:  mtu 1500 qdisc noop state DOWN
> group default qlen 1000
> link/ether 82:e5:b3:41:67:17 brd ff:ff:ff:ff:ff:ff
> 7: dummy0:  mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether 5e:eb:30:64:69:ef brd ff:ff:ff:ff:ff:ff
> 
> With the modprobe.d config file installed, there obviously was neither a
> dummy0 nor bond0 device.
> 
> Fwiw, I know too little about those dummy and bonding devices and how
> they are usually used.
> E.g. network-manager and networkd seem to create them on the fly as
> needed. So I'm not sure, which users will actually be affected by that
> change.

All users not using networkd and network-manager. Usually servers, just
with ifup/ifdown.

> Would be good to know how Baptiste is setting up those devices. If he is
> doing it manually via some scripting of low level tool or uses a higher
> level network management tool
> Fwiw, with "ip link add dummy0 type dummy" (or "ip link add bond0 type
> bond") I was e.g. able to create such a device manually as well.
> I wonder whether such an approach isn't better then statically setting
> the number of devices via a kernel module option.

My original setup was:

echo "dummy" > /etc/modules

cat << EOF >> /etc/network/interfaces
auto dummy0
iface dummy0 inet static
address 192.168.64.1
netmask 24
EOF

The interface would pop up configured at boot time (by ifup). Then, I
had services binding on 192.168.64.1.

I hope this info helps.

Best,

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#931197: base-files: Include minor version in /etc/os-release

[Santiago Vila]

On Thu, Jun 27, 2019 at 06:58:06PM -0400, Sam Doran wrote:
> Package: base-files
> Version: 9.9+deb9u9
> Severity: minor
> 
> Dear Maintainer,
> 
> I am an Ansible Core maintainer and I would like to request that the
> minor verison information, e.g., 9.9, be included in /etc/os-release on
> Debian.
> 
> > What led up to the situaiton?
> 
> In Ansible, We recently switched to using the distro Python library for 
> parsing distribution
> version information. distro uses /etc/os-release as the main source of truth
> for information about a given distribution.
> 
> Previously, we were using platform.dist(), but this
> is now deprecated. With platform.dist(), we receieved the minor version
> information and our users found this information helpful.
> 
> With the switch to distro, the minor version of Debian is no longer returned 
> by
> default.
> 
> I have a workaround[1] to get minor version information using distro,
> but would prefer to have the minor version added to /etc/os-release in
> Debian if the maintainers of Debian feel the minor version number is valid 
> and/or
> supported.
> 
> We asked the CentOS maintainers[2] and they do not support point
> versions, so CentOS, omitting the minor version inforamition from
> /etc/os-release is appropirate.
> 
> I wanted to make the same request of the Debian maintainers.

Hi.

Our /etc/os-release file has been quite predictable for a long time
and I would consider not very likely that we will change it at this
point of the release cycle (we will release Debian 10 "buster" in
short, most probably in July).

As an Ansible user myself, sometimes I use ansible_distribution_major_version,
but I have never used the minor version in playbooks/roles, so I, for
one, would not consider such thing particularly interesting.

We support minor version information in /etc/debian_version,
and tools like reportbug take the full version from such file
so that it appears in bug reports.

So, if you absolutely need the minor version now, I would recommend
that you implement your workaround for now.

OTOH, if this request is for the long term (maybe for Debian 11, bullseye),
I can ask Release Managers about their opinion on moving minor version
to /etc/os-release (this is definitely something I would prefer not to do
without hearing other's opinions).

Thanks.

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Michael Biebl]

Am 28.06.19 um 12:58 schrieb Justin B Rye:
> Michael Biebl wrote:
>> Afaiu, the kernel default is to create one dummy device by default when
>> the module is loaded.

.. or bond device, for that matter.

>> I assume there might be cases where users rely on that default behaviour
>> without having explicitly configured anything.
> 
> Do we have any idea what their use case would be?  Apparently a
> different one from Baptiste's, if it's true that he needed to
> explicitly configure "numdummies=1"...

Dunno why Baptiste had to do that.
I just verified that by removing /lib/modprobe.d/systemd.conf, I got the
following when running "modprobe dummy" and "modprobe bonding":

6: bond0:  mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 82:e5:b3:41:67:17 brd ff:ff:ff:ff:ff:ff
7: dummy0:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 5e:eb:30:64:69:ef brd ff:ff:ff:ff:ff:ff

With the modprobe.d config file installed, there obviously was neither a
dummy0 nor bond0 device.

Fwiw, I know too little about those dummy and bonding devices and how
they are usually used.
E.g. network-manager and networkd seem to create them on the fly as
needed. So I'm not sure, which users will actually be affected by that
change.
Would be good to know how Baptiste is setting up those devices. If he is
doing it manually via some scripting of low level tool or uses a higher
level network management tool
Fwiw, with "ip link add dummy0 type dummy" (or "ip link add bond0 type
bond") I was e.g. able to create such a device manually as well.
I wonder whether such an approach isn't better then statically setting
the number of devices via a kernel module option.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#930869: feedback from an user

[Adam Borowski]

Just received this feedback from an user:

06:34  thanks for #930869, also heavy pm-utils users
06:37  */59 21-6 * * 1-5   root/usr/sbin/pm-suspend
06:37  */59 * * * 6-7  root/usr/sbin/pm-suspend
06:37  with hooks when it's ok to save or not
06:38  /etc/pm/sleep.d/99-$SOMEORG see for our implementation
06:39  pretty cool, to have automatic power saving on
multiuser/multimachine managed machines (when people have
cronjobs, day/week long running jobs and in-between-nfs
mountes between the managed machines)

So it's not like pm-utils is not used or used little.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Bug#931216: less: Ctrl-C has no effect with -c (--clear-screen) and process substitution

[Vincent Lefevre]

Package: less
Version: 487-0.1+b1
Severity: normal

Ctrl-C has no effect with -c (--clear-screen) and process substitution,
e.g. with

zira% less -fc <(echo foo; sleep 3; echo bar)

and Ctrl-C hit during the "sleep 3", while the following has no issue:

zira% less -f <(echo foo; sleep 3; echo bar)

(Tested with all LESS* environment variables unset.)

This is surprising as -c should just change the screen painting:

   -c or --clear-screen
  Causes full screen repaints to be painted  from  the
  top line down.  By default, full screen repaints are
  done by scrolling from the bottom of the screen.

I don't see why this would affect signals.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages less depends on:
ii  debianutils  4.8.6.1
ii  libc62.28-10
ii  libtinfo66.1+20181013-2

less recommends no packages.

less suggests no packages.

-- no debconf information

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Baptiste BEAUPLAT]

On 6/28/19 12:58 PM, Justin B Rye wrote:
> Michael Biebl wrote:
>> Afaiu, the kernel default is to create one dummy device by default when
>> the module is loaded.
>> I assume there might be cases where users rely on that default behaviour
>> without having explicitly configured anything.
> 
> Do we have any idea what their use case would be?  Apparently a
> different one from Baptiste's, if it's true that he needed to
> explicitly configure "numdummies=1"...

In my case, I didn't need to specify the "numdummies=1" as it is the
default (when systemd override is not installed).

Someone that needed only one interface with bonding or dummy would have
 to just load the module while someone that required more interfaces
would have to explicitly set numdummies.

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#931215: many well known Android devices not supported

[Hans-Christoph Steiner]

Package: adb
Version: 25.0.0+10

This is a kind of "meta" bug report to gather information about missing
device support for the adb and fastboot packages.  Currently, the only
blocker for LineageOS for recommending the Debian packages over the
Google packages is missing device IDs in the udev rules for devices that
LineageOS supports:

https://review.lineageos.org/c/LineageOS/lineage_wiki/+/244577

Upstream for the udev rules has recently merged some more USB device
IDs.  Plus some other device rules have come via salsa merge requests:

* Add some more Amazon devices
https://salsa.debian.org/android-tools-team/android-sdk-meta/merge_requests/2

* Add another Huawei ADB device
https://salsa.debian.org/android-tools-team/android-sdk-meta/merge_requests/3

Bug#931214: Acknowledgement (ImportError: No module named oslo.config)

[Jö Fahlke]

...and here is the log I promised.

-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

It is my conviction that killing under the cloak of war is nothing but
an act of murder.
-- Albert Einstein
-*- mode: compilation; default-directory: 
"/scp:epic:/home/joe/Projects/test-os-collect-config/" -*-
Compilation started at Fri Jun 28 12:20:46

docker build --no-cache .
Sending build context to Docker daemon  3.072kB
Step 1/9 : FROM debian:buster
 ---> 098963abf3c3
Step 2/9 : ENV DEBIAN_FRONTEND=noninteractive
 ---> Running in 774454fa1d95
Removing intermediate container 774454fa1d95
 ---> 2e0c4f7a7646
Step 3/9 : RUN apt-get update
 ---> Running in 9463fa4ab2bd
Get:2 http://cdn-fastly.deb.debian.org/debian buster InRelease [167 kB]
Get:1 http://security-cdn.debian.org/debian-security buster/updates InRelease 
[39.1 kB]
Get:3 http://cdn-fastly.deb.debian.org/debian buster-updates InRelease [46.8 kB]
Get:4 http://security-cdn.debian.org/debian-security buster/updates/main amd64 
Packages [1132 B]
Get:5 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages [7897 
kB]
Fetched 8151 kB in 3s (2877 kB/s)
Reading package lists...
Removing intermediate container 9463fa4ab2bd
 ---> 27d6a019fb75
Step 4/9 : RUN apt-get upgrade -y
 ---> Running in 99140ec9aed9
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  libbz2-1.0 libgnutls30
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1169 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://cdn-fastly.deb.debian.org/debian buster/main amd64 libbz2-1.0 
amd64 1.0.6-9.1 [45.1 kB]
Get:2 http://cdn-fastly.deb.debian.org/debian buster/main amd64 libgnutls30 
amd64 3.6.7-4 [1123 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 1169 kB in 1s (1920 kB/s)
(Reading database ... 6674 files and directories currently installed.)
Preparing to unpack .../libbz2-1.0_1.0.6-9.1_amd64.deb ...
Unpacking libbz2-1.0:amd64 (1.0.6-9.1) over (1.0.6-9) ...
Setting up libbz2-1.0:amd64 (1.0.6-9.1) ...
(Reading database ... 6674 files and directories currently installed.)
Preparing to unpack .../libgnutls30_3.6.7-4_amd64.deb ...
Unpacking libgnutls30:amd64 (3.6.7-4) over (3.6.7-3) ...
Setting up libgnutls30:amd64 (3.6.7-4) ...
Processing triggers for libc-bin (2.28-10) ...
Removing intermediate container 99140ec9aed9
 ---> 56b1c872136e
Step 5/9 : RUN apt-get install -y python-os-collect-config
 ---> Running in 56cac262163a
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  bzip2 ca-certificates dbus docutils-common docutils-doc file gir1.2-glib-2.0
  ieee-data javascript-common libapparmor1 libdbus-1-3 libexpat1 libfreetype6
  libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libicu63 libimagequant0
  libjbig0 libjpeg62-turbo libjs-jquery libjs-sphinxdoc libjs-underscore
  liblcms2-2 libmagic-mgc libmagic1 libpaper-utils libpaper1 libpcre2-8-0
  libpng16-16 libpsl5 libpython-stdlib libpython2-stdlib libpython2.7-minimal
  libpython2.7-stdlib libreadline7 libsqlite3-0 libssl1.1 libtiff5 libwebp6
  libwebpdemux2 libwebpmux3 libxml2 libxslt1.1 libyaml-0-2 mime-support
  netbase openssl publicsuffix python python-anyjson python-asn1crypto
  python-babel python-babel-localedata python-backports.functools-lru-cache
  python-blinker python-bs4 python-certifi python-cffi-backend python-chardet
  python-configparser python-cryptography python-dbus python-debtcollector
  python-docutils python-entrypoints python-enum34 python-eventlet
  python-funcsigs python-gi python-greenlet python-html5lib python-idna
  python-ipaddress python-iso8601 python-jwt python-keyring
  python-keystoneauth1 python-keystoneclient python-lxml python-minimal
  python-monotonic python-msgpack python-netaddr python-netifaces
  python-oauthlib python-olefile python-openssl python-os-service-types
  python-oslo.config python-oslo.i18n python-oslo.serialization
  python-oslo.utils python-pbr python-pil python-pkg-resources python-pygments
  python-pyparsing python-requests python-rfc3986 python-roman
  python-secretstorage python-setuptools python-six python-soupsieve
  python-stevedore python-tz python-urllib3 python-webencodings python-wrapt
  python-yaml python2 python2-minimal python2.7 python2.7-minimal
  readline-common sensible-utils sgml-base shared-mime-info ucf wget
  xdg-user-dirs xml-core xz-utils
Suggested packages:
  bzip2-doc default-dbus-session-bus | dbus-session-bus apache2 | lighttpd
  | httpd liblcms2-utils python-doc python-tk python-blinker-doc
  python-cryptography-doc python-cryptography-vectors python-dbus-dbg
  python-dbus-doc python-debtcollector-doc fonts-linuxlibertine
  | ttf-linux-libe

Bug#931214: ImportError: No module named oslo.config

[Jö Fahlke]

Package: python-os-collect-config
Version: 0.1.15-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm trying to use os-collect-config in a Debian stretch instance in an
openstack cluster.  However, running it immediately leads to an import error:
```
root@epic-sky-gate-server-texage5etawq:/home/debian# os-collect-config 
Traceback (most recent call last):
  File "/usr/bin/os-collect-config", line 6, in 
from os_collect_config.collect import __main__
  File "/usr/lib/python2.7/dist-packages/os_collect_config/collect.py", line 
25, in 
from openstack.common import log
  File 
"/usr/lib/python2.7/dist-packages/os_collect_config/openstack/common/log.py", 
line 43, in 
from oslo.config import cfg
ImportError: No module named oslo.config
root@epic-sky-gate-server-texage5etawq:/home/debian# cat /etc/debian_version
9.9
root@epic-sky-gate-server-texage5etawq:/home/debian# dpkg -l python-oslo.config
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
Architecture  Description
+++-=-=-=-
ii  python-oslo.config1:3.17.0-3all 
  Common code for Openstack Projects (configuration API) - 
Python 2.x
```

Here is a reproducer using Docker and Dockers debian:buster image:
```Dockerfile
FROM debian:buster

ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y python-os-collect-config
RUN dpkg -l
RUN dpkg -S 
/usr/lib/python2.7/dist-packages/os_collect_config/openstack/common/log.py
RUN grep '' /etc/apt/sources.list /etc/apt/sources.list.d/* || true
RUN os-collect-config --help
```

I'm attaching the output of running docker build on the above.

Regards,
Jorrit Fahlke.

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages python-os-collect-config depends on:
ii  dpkg   1.18.25
ii  python 2.7.13-2
ii  python-anyjson 0.3.3-1
ii  python-eventlet0.19.0-6
ii  python-iso8601 0.1.11-1
ii  python-keystoneclient  1:3.2.0-4
ii  python-lxml3.7.1-1
ii  python-oslo.config 1:3.17.0-3
ii  python-pbr 1.10.0-1
ii  python-requests2.12.4-1
ii  python-six 1.10.0-3

python-os-collect-config recommends no packages.

python-os-collect-config suggests no packages.

-- no debconf information

-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

Interpunktion, Orthographie und Grammatik der Email ist frei erfunden.
Eine Übereinstimmung mit aktuellen oder ehemaligen Regeln wäre rein
zufällig und ist nicht beabsichtigt.


signature.asc
Description: PGP signature

Bug#931213: rpush does not work with split brain quilt modes

[Ian Jackson]

Package: dgit
Version: 2.0
Tags: patch

This has never worked in any uploaded version of dgit, since 2.0 was
the first uploaded version to support split quilt modes at all.

Nevertheless, given the simplicity of the fix, and the fact that this
fix makes my new test case pass as expected, this is IMO a candidate
for a stable update to buster.

So I propose to push it, and the corresponding new test case, to the
"stable" branch.

Ian.

>From 4b81844a96c1784123cb47463ec77c0ea47ee2fb Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Fri, 28 Jun 2019 12:32:18 +0100
Subject: [PATCH] dgit: rpush: Work in splitting quilt modes, again

The failure case is missing the obviously-necessary check that the
protocol version is, indeed, insufficient!

This was broken in
  045ec681a42fd823280cdec86a177309ddd741f0
  Split tags: Genrate maintainer-view tag too
which was first uploaded as part of dgit 2.0.

Signed-off-by: Ian Jackson 
---
 dgit | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dgit b/dgit
index afe209e2..17745536 100755
--- a/dgit
+++ b/dgit
@@ -4751,7 +4751,7 @@ sub i_resp_want ($) {
 
 fail "rpush negotiated protocol version $protovsn".
" which does not support quilt mode $quilt_mode"
-   if quiltmode_splitbrain;
+   if quiltmode_splitbrain && $protovsn < 4;
 
 my @localpaths = i_method "i_want", $keyword;
 printdebug "[[  $keyword @localpaths\n";
-- 
2.11.0



-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#931130: Document that local configuration for dummy and bonding modules are getting overwritten by systemd

[Justin B Rye]

Michael Biebl wrote:
> Afaiu, the kernel default is to create one dummy device by default when
> the module is loaded.
> I assume there might be cases where users rely on that default behaviour
> without having explicitly configured anything.

Do we have any idea what their use case would be?  Apparently a
different one from Baptiste's, if it's true that he needed to
explicitly configure "numdummies=1"...
 
> Atm, the release note entry reads like only admins who have a modprobe.d
> config are possibly affected.

That's true.  I can't immediately see any way of rephrasing it without
making it much more complicated.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#931212: dgit should use distro-info-data.deb

[Ian Jackson]

Package: dgit
Version: 8.4

Simon McVittie writes ("Re: getting rid of "testing""):
> On Thu, 27 Jun 2019 at 12:04:39 +0100, Ian Jackson wrote:
> > [What is currently stable, etc.] is available via the ftpmaster API
> > service, and by reading symlinks
> > in archive mirrors.  I think the idea of having this information in a
> > .deb too (ideally kept up to date in all in-support releases,
> > including LTS) is a good one.
> 
> distro-info-data.deb has this information for Debian and Ubuntu, in a
> CSV file. It has convenience bindings for Perl, Python and CLI, and is
> also used by recent versions of Debian's implementation of lsb-release.
> 
> It doesn't currently get an exemption from (old)stable releases' stability
> policies, but the data is in src:distro-info-data, separated from the
> convenience bindings in src:distro-info, presumably so that it could
> get updated more often if that was felt to be important.

dgit currently has duplicated list of suite name to distro name
mappings, in its default config.

dgit should be able to use distro-info-data in the absence of a config
setting; and the existing duplicated data in the default configuration
should probably be retired.  (The facility to augment the mapping with
config settings should be retained.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#931211: s2s connections are broken after upgrading to buster

[Marco d'Itri]

Package: ejabberd
Version: 18.12.1-2
Severity: important

After upgrading to buster apparently all s2s connections are broken.
I have no idea of what is wrong here.

error.log:

2019-06-28 12:17:17.896 [error] <0.1995.0>@inet_dns:encode_labels:694 
gen_server <0.1995.0> terminated with reason: no function clause matching 
inet_dns:encode_labels(<<3,28,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,115,45,115,101,114,118,101,114,4,95,116,99,112,...>>,
 
{5,{[<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],12,{[<<"_tcp">>,<<"j...">>,...],...},...}},
 48, [<<>>]) line 694
2019-06-28 12:17:17.896 [error] <0.1995.0>@inet_dns:encode_labels:694 CRASH 
REPORT Process <0.1995.0> with 0 neighbours exited with reason: no function 
clause matching 
inet_dns:encode_labels(<<3,28,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,115,45,115,101,114,118,101,114,4,95,116,99,112,...>>,
 
{5,{[<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],12,{[<<"_tcp">>,<<"j...">>,...],...},...}},
 48, [<<>>]) line 694 in p1_server:terminate/7 line 878
2019-06-28 12:17:17.896 [error] <0.449.0>@inet_dns:encode_labels:694 Supervisor 
ejabberd_s2s_out_sup had child undefined started with 
{ejabberd_s2s_out,start_link,undefined} at <0.1995.0> exit with reason no 
function clause matching 
inet_dns:encode_labels(<<3,28,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,115,45,115,101,114,118,101,114,4,95,116,99,112,...>>,
 
{5,{[<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],12,{[<<"_tcp">>,<<"j...">>,...],...},...}},
 48, [<<>>]) line 694 in context child_terminated
2019-06-28 12:17:49.741 [error] <0.2002.0>@inet_dns:encode_labels:694 
gen_server <0.2002.0> terminated with reason: no function clause matching 
inet_dns:encode_labels(<<3,36,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,115,45,115,101,114,118,101,114,4,95,116,99,112,...>>,
 
{5,{[<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],12,{[<<"_tcp">>,<<"j...">>,...],...},...}},
 48, [<<>>]) line 694
2019-06-28 12:17:49.741 [error] <0.2002.0>@inet_dns:encode_labels:694 CRASH 
REPORT Process <0.2002.0> with 0 neighbours exited with reason: no function 
clause matching 
inet_dns:encode_labels(<<3,36,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,115,45,115,101,114,118,101,114,4,95,116,99,112,...>>,
 
{5,{[<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],12,{[<<"_tcp">>,<<"j...">>,...],...},...}},
 48, [<<>>]) line 694 in p1_server:terminate/7 line 878
2019-06-28 12:17:49.741 [error] <0.449.0>@inet_dns:encode_labels:694 Supervisor 
ejabberd_s2s_out_sup had child undefined started with 
{ejabberd_s2s_out,start_link,undefined} at <0.2002.0> exit with reason no 
function clause matching 
inet_dns:encode_labels(<<3,36,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,115,45,115,101,114,118,101,114,4,95,116,99,112,...>>,
 
{5,{[<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],12,{[<<"_tcp">>,<<"j...">>,...],...},...}},
 48, [<<>>]) line 694 in context child_terminated


2019-06-28 12:17:49 =ERROR REPORT
** Generic server <0.2002.0> terminating 
** Last message in was {'$gen_cast',connect}
** When Server state == #{codec_options => [ignore_els],db_enabled => true,lang 
=> <<"en">>,mod => ejabberd_s2s_out,on_route => queue,owner => <0.2002.0>,passwo
rd => <<>>,queue => {{[],[]},0,unlimited},remote_server => <<"jabber.seeweb.it">
>,resource => <<>>,server => <<"jabber.linux.it">>,server_host => <<"jabber.linu
x.it">>,shaper => none,stream_authenticated => false,stream_direction => out,str
eam_encrypted => false,stream_id => <<"7906429956378776902">>,stream_restarted =
> false,stream_state => connecting,stream_timeout => 160999,stream_verified => f
alse,user => <<>>,xmlns => <<"jabber:server">>}
** Reason for termination == 
** 
{function_clause,[{inet_dns,encode_labels,[<<3,36,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,115,45,115,101,114,118,101,114,4,95,116,99,112,6,106,97,98,98,101,114,6,115,101,101,119,101,98,2,105,116>>,{5,{[<<"_xmpps-server">>,<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],12,{[<<"_tcp">>,<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],26,nil,nil},{[<<"jabber">>,<<"seeweb">>,<<"it">>,<<>>],31,{[<<"it">>,<<>>],45,nil,nil},{[<<"seeweb">>,<<"it">>,<<>>],38,nil,nil,48,[<<>>]],[{file,"inet_dns.erl"},{line,694}]},{inet_dns,encode_name,4,[{file,"inet_dns.erl"},{line,675}]},{inet_dns,encode_query_section,3,[{file,"inet_dns.erl"},{line,269}]},{inet_dns,encode,1,[{file,"inet_dns.erl"},{line,240}]},{inet_res,make_query,5,[{file,"inet_res.erl"},{line,646}]},{inet_res,make_query,4,[{file,"inet_res.erl"},{line,614}]},{inet_res,res_query,6,[{file,"inet_res.erl"},{line,598}]},{inet_res,res_getby_query,4,[{file,"inet_res.erl"},{line,565}]}]}
2019-06-28 12:17:49 =CRASH REPORT
  crasher:
initial call: xmpp_stream_out:init/1
pid: <0.2002.0>
registered_name: []
exception exit: 
{{function_clause,[{inet_dns,encode_labels,[<<3,36,1,0,0,1,0,0,0,0,0,0,13,95,120,109,112,112,1

Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1

[Alex Mestiashvili]

> With your solution I assume that /lib/udev/hdparm would call hdparm
> twice on each HDD during udev invocation, once for non-spindown options
> returned by /lib/hdparm/hdparm-functions, and once through
> /usr/lib/pm-utils/power.d/95hdparm-apm for spindown options.

Exactly, for the APM options, apm, spindown_time and force_spindown_time
/lib/udev/hdparm will call "/usr/lib/pm-utils/power.d/95hdparm-apm"
For the other option hdparm will be called the second time. But I see no
problem here. Please see the updated script here:
 https://salsa.debian.org/debian/hdparm/blob/930796/debian/udev-scripts/hdparm

With the new /lib/udev/hdparm, hdparm follows the logic below:

No config (/etc/hdparm.conf doesn't list any drives):
  * If disk supports APM, the defaults:
- on boot, -B 254
- on power, -B 254
- on battery -B 128 -S36 (3 min)
  * no APM support:
- hdparm will not run (no config!)

If disk config is present in /etc/hdparm.conf:
  * disk supports APM
- on boot, udev will call /lib/udev/hdparm, which in turn will call
  /usr/lib/pm-utils/power.d/95hdparm-apm for apm options and hdparm
  for other options.
- on power, /usr/lib/pm-utils/power.d/95hdparm-apm
- on battery, defaults -B 128 -S 36, use apm_battery and
  spindown_time to set non-default values
  * no APM support:
- force_spindown_time and other options are applied,
  apm and spindown_time are ignored

For USB or FireWere disks, APM & spindown_time options are ignored,
other options are applied, force_spindown_time will be applied too.
There is bug, https://bugs.launchpad.net/bugs/515023
explaining why USB and FireWire drives are ignored, however the
situation might have improved since then.

> Custom
> scripts relying on hdparm_options() function in
> /lib/hdparm/hdparm-functions would still fail if force_spindown_time is
> used in /etc/hdparm.conf. I would suggest implementing the conversion
> code directly into hdparm_options() function to avoid code duplication,
> prevent misuse, and possibly avoid calling hdparm twice on each HDD.

This makes sense, but
1. hdparm-functions is the debian specific helper script. The chances
that somebody will use it for custom scripts is very low.
2. force_spindown_time is a hackish workaround and in order to implement
it I need to parse this option later in "95hdparm-apm" script.
Implementing proper handling of "force_spindown_time" in
hdparm-functions will result in bringing part of
resume_hdparm_spindown() function from 95hdparm-apm in hdparm-functions
code. I don't like this idea, but please feel free to implement and send
me a patch. :)

> 
> 4. Thanks for your feedback. I have done some experiments and it appears
> that the -S issue comes from something else. I can only confirm that the
> -S option was still working fine at the time of hdparm 9.56+ds-2 in
> buster/testing (Fall 2018) and it had been working for over 5 years with
> various kernel and hdparm versions. Between hdparm 9.56+ds-2 and hdparm
> 9.58+ds-1, the kernel was updated (4.17.8-1 => 4.19.37-3) and there were
> also changes in udev (239-7 => 241-3).

To exclude hdparm, one can try to build hdparm 9.58 on a stretch system.
Building it with make will also work.

> 
> Below is a summary of what I did so far to try and debug hdparm -S:
> 
> 
> A) hdparm versions tried:
> 
> $ hdparm-jessie -V
> hdparm-jessie v9.43
> 
> $ hdparm-stretch -V
> hdparm-stretch v9.51
> 
> $ hdparm-buster -V
> hdparm-buster v9.58
> 
> 
> B) What currently works for all versions:
> 
> $ hdparm -y /dev/sdx
> 
> /dev/sdx:
>  issuing standby command
> 
> $ hdparm -C /dev/sdx
> 
> /dev/sdx:
>  drive state is:  standby
> 
> ## Accessing a mounted partition on /dev/sdx ##
> 
> $ hdparm -C /dev/sdx
> 
> /dev/sdx:
>  drive state is:  active/idle
> 
> ## Will still work if hdparm -y is repeated at this stage ##

Good, from my expirience -y works reliable most of the time, however
some disks may wakeup when hdparm -C is invoked, one can use
smartctl -i -n standby $disk instead.

> 
> 
> C) What worked before at the time of hdparm 9.56+ds-2 (successful
> spindown after the delay):
> 
> $ hdparm -S248 /dev/sdx
> 
> /dev/sdx:
>  setting standby to 248 (4 hours)
> 
> ## Other delays not tested ##
> 
> 
> D) What does not work (anymore) for all versions (hdparm runs
> successfully but will not spindown after the delay):
> 
> $ hdparm -S1 /dev/sdx
> 
> /dev/sdx:
>  setting standby to 1 (5 seconds)
> 
> $ hdparm -S10 /dev/sdx
> 
> /dev/sdx:
>  setting standby to 10 (50 seconds)
> 
> $ hdparm -S241 /dev/sdx
> 
> /dev/sdx:
>  setting standby to 241 (30 minutes)
> 
> $ hdparm -S248 /dev/sdx
> 
> /dev/sdx:
>  setting standby to 248 (4 hours)

Well, this is a tricky question.
First of all the timeout -S248 is really long. As far as I know some
disks may decide to go for standby by themselves. Are you sure that
during this 4 hours there is no disk activity? Can you see that the
drive goes to standby exactly after 4 hours and not 2.5?

In hdparm

Bug#929011: unblock: singularity-container/3.1.1+ds-1

[Afif Elghraoui]

On June 28, 2019 5:00:00 AM EDT, Ivo De Decker  wrote:
>Hi,
>
>On Thu, Jun 27, 2019 at 09:30:09AM -0400, Afif Elghraoui wrote:
>> On June 27, 2019 9:06:41 AM EDT, Afif Elghraoui 
>wrote:
>> >
>> >
>> >On June 27, 2019 5:47:28 AM EDT, Ivo De Decker 
>> >wrote:
>> >>Hi,
>> >>> 
>> >>> So I think the two options we have is (in order of preference):
>1.
>> >>> unblock singularity-container and let the 3.1 based version in to
>> >>> buster, or 2. remove singularity-container from buster.
>> >>
>> >>It's really too late for option 1. Sorry.
>> >>
>> >>I added a removal hint.
>> >>
>> >
>> >This request was not just filed recently. I don't understand why I'm
>> >being penalized for this being late--the version requested for
>> >unblocking as been in unstable for 43 days with no new bugs. And
>it's
>> >also a leaf package.
>> >
>> >Please reconsider.
>> >
>> 
>> I at least want to know what I could have done because, from my
>perspective,
>> I did everything in my power to do this as quickly as possible. At
>the time
>> I made the request, the buster release date had not yet even been
>set.
>
>Please look at the freeze policy:
>
>https://release.debian.org/buster/freeze_policy.html

I have seen it. I hoped we would be trying to make the best possible release 
rather than just following the freeze policy for its own sake. My understanding 
of its strictness is to keep packages with reverse-dependencies from breaking 
them with large changes.

This was a very low/no-risk request because it is a leaf package. firefox-esr 
updates to new versions all the time for security support and actually does 
break reverse-dependency packages in Stable much of the time as a result.

>
>The upload of 3.1.1+ds-1 was done on 2019-05-15, the full freeze
>started on
>2019-03-12. 
>
>During the full freeze, we only accept targeted fixes. Your upload
>didn't come
>close to that, as you admitted yourself in your original mail to the
>unblock
>request. The chances of such a request being granted were extremely
>small,
>even at the point the request was made.
>
>The unblock won't be granted. Sorry.
>


Removal of the existing version in buster, on the other hand, I thought was too 
extreme. I would have tried to support 3.0.3 in buster if any CVEs in it came 
up  and, if that proved too difficult, asked for the exemption to bump to this 
3.1 lts version again at that point.

regards
Afif

Bug#797807: Don't mention ascii2uni -a R if always just giving an error message

[積丹尼 Dan Jacobson]

$ echo -n 00E9|ascii2uni -a R
It isn't possible reliably to parse raw hex unicode out of ASCII text.

How about please at least mentioning to use -R along with -p in the error 
message?

Pretty please.

Anybody home?

I'm falling for this trap every two years.

Bug#931210: debci: Display requestor and priority in the /status/pending/ pages

[Raphaël Hertzog]

Source: debci
Version: 2.1
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

It would be nice if /status/pending/ pages could show the requestor of a
specific job as well as its priority.

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

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

Bug#868760: Blocked by this bug

[Rick van Rein]

This bug is blocking me from developing software for Kerberos and
compiling it for Raspberry Pi (ARMHF) with Multiarch.  Can you please
fix it?

When I run
 apt-get install krb5-user:armhf
I get
 krb5-user:armhf : Depends: krb5-config:armhf but it is not installable
however, there is just
 rc  krb5-config 2.6all
which depends on
 bind9-host

Installing bind9-host:armhf manually does not help.


Note https://wiki.ubuntu.com/MultiarchSpec
which states

Multi-Arch: foreign
The package is not co-installable and should be allowed to satisfy the
dependencies of a package of another architecture than its own.

If a package is declared Multi-Arch: foreign, preference should be given
to a package for the native architecture if available; if it is not
available, the package manager may automatically install any available
package, regardless of architecture, or it may choose to make this an
option controlled by user configuration.

Thanks,
 -Rick

Bug#931209: Please add libjabber.so.0 to shlibs

[Guido Günther]

Package: libpurple0
Version: 2.13.0-2+b1
Severity: wishlist

Hi,
things like lurch (which we want to get into debian) want to link
against libjabber.so but that currently doesn't work out of the box due
to libjabber.so.0 not being handled in libpurple0.shlibs. Could that be
added so a debian/slibs.local can be avoided?

Reference: https://source.puri.sm/Librem5/lurch/-/jobs/65436

Since the pidgin package itself uses a shlibs.local I there's a reason
like it being considered private api?

Cheers,
 -- Guido


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages libpurple0 depends on:
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libavahi-glib1  0.7-4+b1
ii  libc6   2.28-10
ii  libdbus-1-3 1.12.16-1
ii  libdbus-glib-1-20.110-4
ii  libfarstream-0.2-5  0.2.8-4.1
ii  libgadu31:1.12.2-3
ii  libglib2.0-02.58.3-2
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libidn111.33-2.2
ii  libmeanwhile1   1.0.2-9
ii  libnm0  1.14.6-2
ii  libnspr42:4.20-1
ii  libnss3 2:3.42.1-1
ii  libperl5.28 5.28.1-6
ii  libsasl2-2  2.1.27+dfsg-1
ii  libsasl2-modules2.1.27+dfsg-1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libzephyr4  3.1.2-1+b3
ii  perl-base   5.28.1-6
pn  perlapi-5.28.0  
ii  pidgin-data 2.13.0-2

Versions of packages libpurple0 recommends:
ii  ca-certificates  20190110
ii  libpurple-bin2.13.0-2

Versions of packages libpurple0 suggests:
ii  libtcl8.6  8.6.9+dfsg-2
ii  libtk8.6   8.6.9-2

-- no debconf information

Bug#931208: ecryptfs-utils: Has ecryptfs lost sync with kernel?

[clayton]

Package: ecryptfs-utils
Version: 111-4
Severity: important

Happening today on a mixed testing / unstable machine.

# mount -t ecryptfs test test
Unable to link the KEY_SPEC_USER_KEYRING into the KEY_SPEC_SESSION_KEYRING; 
there is something wrong with your kernel keyring. 
Did you build key retention support into your kernel?

This works with the same version of Debian, as virtual machine in QubesOS using 
a Qubes kernel.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_HK:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ecryptfs-utils depends on:
ii  gettext-base0.19.8.1-9
ii  keyutils1.6-6
ii  libassuan0  2.5.2-1
ii  libc6   2.28-10
ii  libecryptfs1111-4
ii  libgpg-error0   1.35-1
ii  libgpgme11  1.12.0-6
ii  libkeyutils11.6-6
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  libtspi10.3.14+fixed1-1

ecryptfs-utils recommends no packages.

Versions of packages ecryptfs-utils suggests:
ii  cryptsetup  2:2.1.0-5

-- no debconf information

Bug#931207: tiger: Honor Single Unix Specification (SUS) by allowing multiple arguments to be grouped behind single `-`

[Avinash Sonawane]

Package: tiger
Version: 1:3.2.3-14.3
Severity: normal

Dear Maintainer,

As per SUS Utility syntax guideline 5[0], command-line utility should allow
multiple arguments to be grouped behind single `-` delimiter.

I have yet to come across the *nix utility which doesn't follow this
convention. Can we please honor the Single Unix Specification?

[0] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/

$ sudo tiger -HE
...
--ERROR-- [con006e] Unknown option -HE
...
$ sudo tiger -H -E
...
13:48> Beginning security report for foo
...
$



-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages tiger depends on:
ii  binutils   2.28-5
ii  bsdmainutils   9.0.12+nmu1
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u4
ii  net-tools  1.60+git20161116.90da8a0-1
ii  ucf3.0036

Versions of packages tiger recommends:
ii  chkrootkit 0.50-4+deb9u1
ii  exim4-daemon-light [mail-transport-agent]  4.89-2+deb9u4
pn  john   
pn  tripwire | aide

Versions of packages tiger suggests:
ii  lsof  4.89+dfsg-0.1

-- debconf information:
  tiger/mail_rcpt: root
  tiger/policy_adapt:

Bug#931206: debci-worker: /etc/cron.daily/debci-worker will block for days when workers are not idle

[Raphaël Hertzog]

Package: debci-worker
Version: 2.1
Severity: important
User: de...@kali.org
Usertags: origin-kali

On our setup, we use the qemu backend on a big machine with lots of RAM
and CPU, so we have many workers running concurrently.

With a backlog, there's often no point in time where the qemu image is
not used at all. This means that /usr/share/debci/bin/debci-setup will
never get the exclusive lock that it is trying to get... and thus the
daily cron will get stuck indefinitely. They will even accumulate days
after days...

The cron should fail it's not able to get the lock it wants in a
reasonable timeframe. Given the time it can take until the lock is
acquired (some tests take multiple hours), the script should likely be
moved out of /etc/cron.daily/.

There should also be an option to stop the worker at the start so that the
update can happen immediately (and they should be restarted at the end
if they were running before).

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

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

Versions of packages debci-worker depends on:
ii  autodep8 0.18
ii  autopkgtest  5.10
pn  debci
ii  init-system-helpers  1.57
ii  schroot  1.6.10-6+b1

debci-worker recommends no packages.

debci-worker suggests no packages.

Bug#931205: chkrootkit: Honor Single Unix Specification (SUS) by allowing multiple arguments to be grouped behind single `-`

[Avinash Sonawane]

Package: chkrootkit
Version: 0.50-4+deb9u1
Severity: normal

Dear Maintainer,

As per SUS Utility syntax guideline 5[0], command-line utility should allow
multiple arguments to be grouped behind single `-` delimiter.

I have yet to come across the *nix utility which doesn't follow this
convention. Can we please honor the Single Unix Specification?

[0] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/

$ chkrootkit -qn
Usage: ./chkrootkit [options] [test ...]
Options:
-hshow this help and exit
-Vshow version information and exit
-lshow available tests and exit
-ddebug
-qquiet mode
-xexpert mode
-r diruse dir as the root directory
-p dir1:dir2:dirN path for the external commands used by chkrootkit
-nskip NFS mounted dirs
$ chkrootkit -q -n

$



-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages chkrootkit depends on:
ii  binutils   2.28-5
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u4
ii  net-tools  1.60+git20161116.90da8a0-1
ii  openssh-client 1:7.4p1-10+deb9u6
ii  procps 2:3.3.12-3+deb9u1

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information:
  chkrootkit/run_daily_opts: -q
  chkrootkit/diff_mode: false
  chkrootkit/run_daily: false

Bug#930669: unblock: qtbase-opensource-src/5.11.3+dfsg1-2

[Dmitry Shachnev]

Hi Paul!

On Thu, Jun 27, 2019 at 06:46:43AM +0200, Paul Gevers wrote:
> Hi Dmitry,
>
> Your package is blocked behind gcc-8. So although unblocked, it will not
> be part of buster at release time. Sorry. If you still want to deploy
> the fix in buster, please take the point release route.

Yes, I have seen that. No problem for me.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#931203: gpg has a serious performance problem on flooded certificates

[Daniel Kahn Gillmor]

Package: gnupg
Version: 2.2.16-2
Control: clone -1 -2
Control: affects -1 monkeysphere enigmail sks
Control: found -1 2.2.13-2
Control: found -1 2.2.12-1
Control: found -1 2.1.18-8~deb9u4
Control: forwarded -1 https://dev.gnupg.org/T4592
Control: reassign -2 monkeysphere 0.41-1
Control: retitle -2 monkeysphere-authentication chokes on flooded certificates

When an OpenPGP certificate is flooded with too many certifications, and
a GnuPG installation imports it into `pubring.gpg`, performance of gpg
is atrocious.  I've documented that performance problem at
https://dev.gnupg.org/T4592.

This is apparently breaking people's enigmail installations
(https://dev.gnupg.org/T3972#127338).

This is also an issue for monkeysphere-authentication, because it pulls
keys from the keyserver network and then tries to use them.  Any system
that has monkeysphere-authentication scheduled in a cronjob to pull from
the SKS keyserver network, for example, can get automatic heavy CPU
load, if one of the certificates they're pulling gets flooded like this.

A handful of (complementary) workarounds present themselves as an option
for the monkeysphere (and any other tools that are affected):

 * switch from the keyring format (pubring.gpg) to the keybox format
   (pubring.kbx), which has narrower limits about what it is willing to
   import.

 * do your fetches from the keyserver using "--import-options
   import-clean" -- while this won't fix everything, it'll still be
   useful.

 * fetch keys via other mechanisms, like WKD or DANE, instead of the SKS
   keyserver network.  Unfortunately, this only works for retrieving
   certificates by e-mail address, and requires cooperation from the
   domain owner to set it up.  It also doesn't provide revocation or
   subkey update necessarily, it could go stale.

 * use hkps://keys.openpgp.org instead of the SKS keyserver network --
   this won't let you fetch third-party certifications, but it will let
   you fetch revocations and key material updates.

Ultimately, we'll need a fix in GnuPG, though. (or for tools to move
away from using GnuPG as their OpenPGP implementation)

   --dkg


signature.asc
Description: PGP signature

Bug#931135: German translation made me laugh during a meeting

[Colin Watson]

On Fri, Jun 28, 2019 at 02:11:44AM +0200, Guillem Jover wrote:
> On Thu, 2019-06-27 at 11:52:05 +0100, Colin Watson wrote:
> > I can't speak to the quality of most of the translation (I read German,
> > but not fluently enough to have a good sense of how idiomatic it is);
> > but -D__DEB_CANARY_flag_random-id__ and -Wl,-z,deb-canary-random-id
> > currently have individual "words" within them translated and this is
> > definitely wrong.
> 
> No, these are supposed to be translated, they are marked with italics
> (which got lost on the paste above), as part of replaceable text.

Oops, of course you're right.  Sorry for derailing!

-- 
Colin Watson   [cjwat...@debian.org]

Bug#931202: ITP: fonts-bajaderka -- Warsaw's sign painters styled font

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: fonts-bajaderka
  Version : 1.0
  Upstream Authors: Stowarzyszenie Kulturotwórcze Miastodwa
* URL : https://kroje.org/en/fonts/bajaderka/
* License : OFL-1.1
  Description : Warsaw's sign painters styled font
 This font is inspired by lettering of the small signage tablets found 
in Warsaw
 shops. The letters feature details typical for traditional calligraphy, 
with

 visible brush strokes, referring to the charming style of Warsaw's sign
 painters.

Package is availabe at http://phd-sid.ethz.ch/debian/fonts-bajaderka/

Bug#930719: autopkgtest: Hangs with qemu backend when copyup destination failed

[Raphael Hertzog]

On Wed, 19 Jun 2019, Raphaël Hertzog wrote:
> In Kali we do have a debci setup at autopkgtest.kali.org, we have
> configured it to use the qemu backend. Unfortunately, after a while
> all our workers were stuck... upon investigation it looks like that
> autopkgtest can get stuck with the qemu backend when the VM image
> is not big enough for the "copyup" operation to complete.

That diagnostic was wrong. The size of the image was not the problem.
In fact the failing "copyup" was copying from the VM back into the host.
We use a "tmpfs" for TMPDIR and /var/lib/debci/tmp so that all autopkgtest
files get copied there (qemu overlay and everything)... but that tmpfs was
badly sized:
# grep debci /etc/fstab 
tmpfs   /srv/debci/tmp  tmpfs   
size=300G,nr_inodes=300k,rw,uid=debci,gid=debci,mode=755 0 0

The 300k inodes was too small, thunderbird alone has 327000 files in its
source package. Thus the copy operation was failing. Still, it would be
nice if autopkgtest could avoid to get stuck in such situations...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/