Bug#932020: cloudcompare: Don't build depend on liblas, will be removed from Debian

[Bas Couwenberg]

On 2019-07-15 07:47, Gürkan Myczko wrote:
thanks for the patch, can do it in 2 weeks... am abroad without 
computer.


Shall I do an NMU or team upload in the mean time then?

Kind Regards,

Bas

Bug#923372: e2fsprogs: sharing of /sbin/logsave

[Theodore Y. Ts'o]

Control: tags -1 +pending

On Wed, Feb 27, 2019 at 03:01:52AM +, Dmitry Bogatov wrote:
> 
> Package: e2fsprogs
> Version: 1.44.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> for long time e2fsprogs were essential, and bin:initscripts used
> /sbin/logsave from e2fsprogs. Nowdays, e2fsprogs are not essential,
> so initscripts switched to using /sbin/logsave on best-effort basis (use
> if present), which is suboptimal.
> 
> Upstream maintainer of sysvinit imported sources of logsave from
> e2fsprogs into sysvinit, and now initscripts can again be sure, that
> logsave is present, if we settle question, who will provide
> /sbin/logsave.
> 
> So here I propose, that e2fsprogs no longer installs logsave, and it
> switch owner to bin:sysvinit-utils. Not the best solution, given there
> is desire (but not much of action) of dropping essential flag from
> bin:sysvinit-utils.
> 
> Alternatively, one of us could build bin:logsave.

I've separated logsave out into its own (Priority: optional) package[1];
it's currently pending in the NEW queue as part of the e2fsprogs
1.45.3 release.

[1] 
https://browse.dgit.debian.org/e2fsprogs.git/commit/?id=bb788de9b021d21686d08366f02415a4c0a91f5e


 - Ted

Bug#932020: cloudcompare: Don't build depend on liblas, will be removed from Debian

[Gürkan Myczko]

thanks for the patch, can do it in 2 weeks... am abroad without computer.

best,

> On Jul 14, 2019, at 21:30, Sebastiaan Couwenberg  wrote:
> 

Bug#932078: Starting systemd-docker directly

[Moritz Lenz]

When I start systemd-docker directly, I get this error:

root@tina:~# /usr/bin/systemd-docker run -p 127.0.0.1:1:1 --rm
--name tau-alert  moritzlenz/tau-alert
docker: Error response from daemon: driver failed programming external
connectivity on endpoint tau-alert
(e06175d196da0a900cb6cfa34c3e083fbf34c8773b0ce9b065b6cf1b6a4ad8cc): Bind
for 127.0.0.1:1 failed: port is already allocated.

I don't know what "allocated" means in this context, it's not in use at
least:

root@tina:~# netstat -tlpen|grep 1|wc -l
0



-- 
Moritz Lenz
https://deploybook.com/ -- https://perlgeek.de/ -- https://perl6.org/

Bug#916783: command-not-found unable to open database file

[Adam Bolte]

Package: command-not-found
Version: 18.04.5-1
Followup-For: Bug #916783
Tags: patch

This patch seems to be working for me:

--- a/CommandNotFound/db/creator.py
+++ b/CommandNotFound/db/creator.py
@@ -88,6 +88,7 @@ class DbCreator:
 "%s does not require an update (inputs unchanged)", dbname)
 return
 tmpdb = dbname+".tmp"
+oldmask = os.umask(0o022)
 with sqlite3.connect(tmpdb) as con:
 con.executescript(create_db_sql)
 self._fill_commands(con)
@@ -98,6 +99,7 @@ class DbCreator:
 # add new metadata
 with open(metadata_file, "w") as fp:
 json.dump(self._calc_input_metadata(), fp)
+os.umask(oldmask)
 def _db_update_needed(self, metadata_file):
 if not os.path.exists(metadata_file):
 return True

I'm not sure if it's the correct way to solve this.

Regards,
Adam


signature.asc
Description: PGP signature

Bug#932089: openssh-server: Cannot log into openssh-server on buster/mipsel

[Francois Marier]

On 2019-07-14 at 23:23:35, Colin Watson wrote:
> Judging from this, the crash (or is it a hang?  I'm assuming a crash) is
> near the start of ensure_minimum_time_since, probably inside
> monotime_ts.  I suspect there's something wrong with the seccomp
> sandboxing of the privileged monitor process on mipsel.

Yes, I also think it's a crash. It doesn't hang at all.

> Could you try installing the auditd package, and then running this
> before starting sshd:
> 
>   auditctl -a exit,always -F uid="$(id -u sshd)"

auditd fails to start after installation (and restart doesn't help):

  $ systemctl status auditd
  ● auditd.service - Security Auditing Service
 Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Mon 2019-07-15 05:03:21 UTC; 3min 
8s ago
   Docs: man:auditd(8)
 https://github.com/linux-audit/audit-documentation
Process: 6841 ExecStart=/sbin/auditd (code=exited, status=1/FAILURE)
  
  Jul 15 05:03:21 gnubee-n1.gnubee systemd[1]: Starting Security Auditing 
Service...
  Jul 15 05:03:21 gnubee-n1.gnubee systemd[1]: auditd.service: Control process 
exited, code=exited, status=1/FAILURE
  Jul 15 05:03:21 gnubee-n1.gnubee systemd[1]: auditd.service: Failed with 
result 'exit-code'.
  Jul 15 05:03:21 gnubee-n1.gnubee systemd[1]: Failed to start Security 
Auditing Service.
  
  $ auditctl -a exit,always -F uid="$(id -u sshd)"
  Error - audit support not in kernel
  Cannot open netlink audit socket

Looks like I might be missing some kernel features. Perhaps sandboxing in
openssh also relies on something that's not compiled in either? Is there an
easy way to check?

By the way, this machine is sadly not using a Debian kernel. It's using
librecmc-ramips-mt7621-gb-pc1-squashfs-sysupgrade_2017-11-28.bin from
https://github.com/gnubee-git/gnubee-git.github.io/blob/master/debian/.

  $ uname -a
  Linux gnubee-n1.gnubee 4.4.87-gnu #0 SMP Wed Nov 22 13:06:13 2017 mips 
GNU/Linux

Francois

-- 
https://fmarier.org/

Bug#932105: ListenStream= references a path below legacy directory /var/run/

[積丹尼 Dan Jacobson]

Package: dbus
Version: 1.13.12-1
File: /lib/systemd/system/dbus.socket

journalctl says
/lib/systemd/system/dbus.socket:4: ListenStream= references a path below legacy 
directory /var/run/, updating /var/run/dbus/system_bus_socket → 
/run/dbus/system_bus_socket; please update the unit file accordingly.

Bug#462389: Bug#932073: dh_installinit fails with "--name=foo option specified, but init script not found"

[Helmut Grohne]

Control: affects -1 + src:policycoreutils

On Sun, Jul 14, 2019 at 05:59:00PM +, Niels Thykier wrote:
> Of the two issues spotted:

Please also look into policycoreutils.

Helmut

Bug#932104: ListenFIFO= references a path below legacy directory /var/run/

[積丹尼 Dan Jacobson]

Package: acpi-fakekey
Version: 0.142-8+b1
File: /lib/systemd/system/acpi-fakekey.socket

journalctl says
/lib/systemd/system/acpi-fakekey.socket:4: ListenFIFO= references a path below 
legacy directory /var/run/, updating /var/run/acpi_fakekey → /run/acpi_fakekey; 
please update t...

Bug#754498: checkinstall: module packaging includes unwanted files

[Stephen Gelman]

Hi Guillaume,

Sorry for the reply that is 5 years too late!  Responses inline:

On Fri, 11 Jul 2014 21:10:56 +0200 Guillaume Millet  wrote:
> Using checkinstall to create a Debian package that installs a kernel module
> adds three undesired files.
> 
> $ sudo checkinstall
> 
> The package created contained three unwanted files:
> /lib/modules/$(uname -r)/modules.softdep
> /lib/modules/$(uname -r)/modules.builtin.bin
> /lib/modules/$(uname -r)/modules.devname
> 
> As a workaround, I removed those files with the exclude option.

I’m not quite sure that this is a mistake.  I believe those files are, in fact, 
touched by installing a module.  Therefore, I think your workaround is the 
correct way to handle it.  If this answers your question please let me know and 
I will close this bug, otherwise definitely let me know if you disagree!

Thanks,

Stephen

Bug#754498: checkinstall: module packaging includes unwanted files

[Stephen Gelman]

Hi Guillaume,

Sorry for the reply that is 5 years too late!  Responses inline:

On Fri, 11 Jul 2014 21:10:56 +0200 Guillaume Millet  wrote:
> Using checkinstall to create a Debian package that installs a kernel module
> adds three undesired files.
> 
> $ sudo checkinstall
> 
> The package created contained three unwanted files:
> /lib/modules/$(uname -r)/modules.softdep
> /lib/modules/$(uname -r)/modules.builtin.bin
> /lib/modules/$(uname -r)/modules.devname
> 
> As a workaround, I removed those files with the exclude option.

I’m not quite sure that this is a mistake.  I believe those files are, in fact, 
touched by installing a module.  Therefore, I think your workaround is the 
correct way to handle it.  If this answers your question please let me know and 
I will close this bug, otherwise definitely let me know if you disagree!

Thanks,

Stephen

Bug#785441: Support maintainer name and email address

[Stephen Gelman]

tags 785441 -patch
thanks
--

Viktor,

This seems like a reasonable idea, however I do not see a patch attached to the 
bug.  If you have one could you please send it?

Thanks!

Stephen

Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist

Package name: fuidshift
Version : 3.0
Upstream Author : Name 
URL : https://github.com/lxc/lxd/tree/master/fuidshift
License : Apache 2.0
Programming Lang: Go
Description : remap a filesystem tree to shift one set of UID/GID ranges to 
another

Fuidshift is useful for converting privileged containers to
unprivileged ones, and also to adapt a container master to multiple
users' authorised subuid and subguid ranges.  It also sounds like it
might be useful for fixing up cases where --numeric-owner should have
been used, but where it would be too labour-intensive to manually chown.

I learned about this tool via the following document:
  https://github.com/BenSartor/unprivileged-lxc-containers

Here is the upstream description:

  This tool lets you remap a filesystem tree, switching it from one
  set of UID/GID ranges to another.
  This is mostly useful when retrieving a wrongly shifted filesystem tree
  from a backup or broken system and having to remap everything either to
  the host UID/GID range (uid/gid 0 is root) or to an existing container's
  range.
  A range is represented as :::.
  Where "u" means shift uid, "g" means shift gid and "b" means shift uid and 
gid.

https://github.com/lxc/lxd/blob/81b81b9ace3064c8065319f4e984378244587d80/fuidshift/main_shift.go#L26-L36

It's part of the LXD project, but I'm not sure if it's as difficult to
package as LXD itself, which is one reason why I've CCed the Go team.
I also wonder if the best way to get this into Debian would be a
src:lxd that produces bin:fuidshift.


Regards,
Nicholas

Bug#929816: RFS: simhash/0.0.20161225-1 [ITA] -- generate similarity hashes to find nearly duplicate files

[laokz]

Hello Adam,

Congratulations to Buster release! Now it's time for my trip in Debian
again. Will you kind to sponsor 'simhash' anymore and upload it to
salsa.debian.org/debian/?.

Thanks,
laoks

Bug#932102: FATAL_ERROR: Can't receive value from the server at pulseaudio volume over 100

[William Chung]

Package: moc
Version: 1:2.6.0~svn-r2994-3
Severity: normal

Dear Maintainer,

Turning up the volume over 100 in pulseaudio settings kills mocp. This happens
in both the build in buster and testing.

Turning the volume over 100% makes mocp throw the error on the title

`FATAL_ERROR: Can't receive value from the server!`



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 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)
LSM: AppArmor: enabled

Versions of packages moc depends on:
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.64.0-4
ii  libdb5.3  5.3.28+dfsg1-0.6
ii  libfaad2  2.8.8-3
ii  libflac8  1.3.2-3
ii  libgcc1   1:8.3.0-7
ii  libid3tag00.15.1b-14
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libltdl7  2.4.6-10
ii  libmad0   0.15.1b-10
ii  libmagic1 1:5.35-4
ii  libmodplug1   1:0.8.9.0-2
ii  libmpcdec62:0.1~r495-1+b2
ii  libncursesw6  6.1+20181013-2
ii  libogg0   1.3.2-1+b1
ii  libopusfile0  0.9+20170913-1
ii  libpopt0  1.16-12
ii  librcc0   0.2.12-0.1
ii  libresid-builder0c2a  2.1.1-15
ii  libsamplerate00.1.9-2
ii  libsidplay2   2.1.1-15
ii  libsidutils0  2.1.1-15
ii  libsndfile1   1.0.28-6
ii  libspeex1 1.2~rc1.2-1+b2
ii  libstdc++68.3.0-7
ii  libtagc0  1.11.1+dfsg.1-0.3
ii  libtinfo6 6.1+20181013-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisfile31.3.6-2
ii  libwavpack1   5.1.0-6
ii  zlib1g1:1.2.11.dfsg-1

moc recommends no packages.

Versions of packages moc suggests:
ii  moc-ffmpeg-plugin  1:2.6.0~svn-r2994-3

-- no debconf information

Bug#932097: Found the reason it fails, and a workaround

[Henry J. Douglas]

Thanks to some people on the IRC channel, we were able to pinpoint the
cause of the problem.

When installing firmware-amd-graphics, the initramfs is not rebuilt, which
makes it impossible for the device to be used.

Running `update-initramfs -u -k all` and rebooting fixed the problem.

Regarding my other computer, it uses Intel graphics, so it must be an
unrelated issue.

Bug#932101: release-notes: S3QL unable to resolve hostname due to S3 URL format change

[Shannon Dealy]

Package: release-notes
Severity: normal

Dear Maintainer,

After upgrading from Stretch to Buster, I was unable to use S3QL with any of
my Amazon S3 buckets. All attempts to access gave errors like:

 ERROR: Can't connect to backend: unable to resolve hostname

I was eventually able to track the problem down to a change in the format
of the Amazon S3 URL which occurred two years ago. The new format of the
URL is:

 s3:

Note the addition of a "region" section in the URL.

Unfortunately this change is not displayed by "apt-listchanges" during the
upgrade, nor is it documented in the release notes.

Please add this information to the release notes for Buster so that others 
don't waste hours trying to figure it out.


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

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

Bug#932100: ITP: golang-github-knqyf263-go-version -- Go library for parsing and verifying versions, and version constraints

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-version
  Version : 1.1.1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-version
* License : MPL-2.0
  Programming Lang: Go
  Description : Go library for parsing and verifying versions, and version 
constraints

 go-version is a library for parsing versions and version constraints,
 and verifying versions against a set of constraints. go-version can sort
 a collection of versions properly, handles prerelease/beta versions,
 can increment versions, etc.

Bug#932099: jdim: thread title search does not show results

[Masayuki Yamamoto]

Package: jdim
Version: 0.1.0-1
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?
Thread title search (Ctrl+T) shold be able to show thread title list which
include search keywords, but always nothing display (zero hit).

   * What exactly did you do (or not do) that was effective (or ineffective)?
1. Install jdim and launch it.
$ sudo apt install jdim
$ jdim

2. Click close button for setup wizard window.

3. In main window, enter Ctrl+T to open thread title search.

4. Enter search keywords (eg. baseball) and Enter key.

   * What was the outcome of this action?
show result : baseball 0 件 (zero hit)

   * What outcome did you expect instead?
   show thread title list which include "baseball"

   * Patch
   New version 0.2.0 is released in this weekend (2019-07-20).
This has already merged the bugfix patches. (see
https://github.com/JDimproved/JDim/issues/60).

   * Which version occurs the bug?
  Result of jdim --version
JDim 0.1.0-20190122
(c) 2006-2015 JD project
(c) 2017-2019 yama-natuki
(c) 2019 JDimproved project
configure: '--build=x86_64-linux-gnu' '--includedir=/usr/include' '--
infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-
silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--
disable-maintainer-mode' '--disable-dependency-tracking' '--prefix=/usr' '--
mandir=/usr/share/man' '--with-sessionlib=xsmp' '--with-alsa' '--with-gthread'
'--with-migemo' '--with-migemodict=/usr/share/cmigemo/utf-8/migemo-dict'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-
map=/build/jdim-t7xxJg/jdim-0.1.0=. -fstack-protector-strong -Wformat
-Werror=format-security' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro
-Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2
-fdebug-prefix-map=/build/jdim-t7xxJg/jdim-0.1.0=. -fstack-protector-strong
-Wformat -Werror=format-security'

   Result of copying environment to clipboard
[バージョン] JDim 0.1.0-20190122
[ディストリ ] Ubuntu 19.04 (x86_64)
[パッケージ] バイナリ/ソース( <配布元> )
[ DE／WM ] KDE
[　gtkmm 　] 2.24.5
[　glibmm 　] 2.58.0
[オプション ] '--with-sessionlib=xsmp'
'--with-alsa'
'--with-gthread'
'--with-migemo'
'--with-migemodict=/usr/share/cmigemo/utf-8/migemo-dict'
[ そ の 他 ]

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



-- System Information:
Debian Release: buster/sid
  APT prefers disco-updates
  APT policy: (500, 'disco-updates'), (500, 'disco-security'), (500, 'disco'), 
(100, 'disco-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-20-generic (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jdim depends on:
ii  libasound2  1.1.8-1
ii  libatkmm-1.6-1v52.28.0-2
ii  libc6   2.29-0ubuntu2
ii  libgcc1 1:9.1.0-2ubuntu2~19.04
ii  libgcrypt20 1.8.4-3ubuntu1
ii  libglib2.0-02.60.4-0ubuntu0.19.04.1
ii  libglibmm-2.4-1v5   2.58.0-2
ii  libgnutls30 3.6.5-2ubuntu1.1
ii  libgtk2.0-0 2.24.32-3ubuntu1
ii  libgtkmm-2.4-1v51:2.24.5-4
ii  libmigemo1  1:1.2+gh0.20150404-7
ii  libpango-1.0-0  1.42.4-6
ii  libpangomm-1.4-1v5  2.42.0-2
ii  libsigc++-2.0-0v5   2.10.1-2
ii  libstdc++6  9.1.0-2ubuntu2~19.04
ii  libx11-62:1.6.7-1
ii  zlib1g  1:1.2.11.dfsg-1ubuntu2

Versions of packages jdim recommends:
ii  cmigemo-common  1:1.2+gh0.20150404-7

Versions of packages jdim suggests:
ii  fonts-mona1:2.90-1
ii  fonts-monapo  20170722-2

-- no debconf information

Bug#932098: gcc-8: LTO with -fdebug-prefix-map results in unreproducible build

[Theodore Y. Ts'o]

Package: gcc-8
Version: 8.3.0-19
Severity: normal

Dear Maintainer,

The e2fsprogs package is currently not reproducible.  See:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/e2fsprogs.html

This is caused by an unfortunate interaction between LTO and the flags
from dpkg-buildflags which are meant to try to create reproducible
builds in the debug symbols.

% dpkg-buildflags  --get CFLAGS
-g -O2 -fdebug-prefix-map=/tmp/gbp/e2fsprogs-1.45.3=. -fstack-protector-strong 
-Wformat -Werror=format-security

While this does a good thing in that it maps away the build pathname in
the debugsym files, to prevent reproducible build problems, it results
in an extremely perverse result for LTO builds, because this debug
option --- complete with build pathname --- is encoded in the
gnu.lto_.opts section.  :-(

This is leaving me in a difficult position, since it means I have to
decide which is more important to Debian --- LTO builds, or reproducible
builds.   I suspect I'll eventually decide that reproducible builds are
more important, since the bloat to e2fsprogs is only 60k or so.  But I
figure I'll file a bug against gcc-8 in the hopes that it's not too hard
to fix this problem.

Thanks!!


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

Kernel: Linux 5.1.0-00062-gc804857673ae (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#932096: tag2upload. upstream handling

[Ian Jackson]

Package: dgit-infrastructure
Version: 9.2

git-debpush 
  - sends upstream commitish and tag info 
whenever processing a non-native package.

The tag2upload bot
  - runs git-deborig iff upstream info was provided;
this should cause a .orig to exist
  - passes --upstream... to dgit iff --quilt=baredebian (only)
(subject to the bug I have just filed)
dgit
  - always checks that the orig (if there is one) is treesame enough
  - uses upstream git history iff --quilt=baredebian

So this means that in the non-baredebian non-native case, nothing
checks that the supplied git tag is an ancestor of the maintainer
history.

I think the supplied git tag should be an ancestor of the maintainer
history except with --quilt=baredebian.  Is this a thing that should
be checked ?

If so, I propose the following changes:

dgit --upstream-commitish should be tolerated in all non-native
packages and should check that the specified commitish is an ancestor
of the maintainer view.

tag2upload should pass --upstream-commitish whenever upstream info
appeared in the tag.

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#932095: tag2upload always fails with baredebian

[Ian Jackson]

Package: dgit-infrastructure
Version: 9.2

The tag2upload code contains this:

die "needed upstream commmitish with --quilt=baredebian";
push @dgitcmd, "--upstream-commitish=$upstreamc";

The former die should be qualified.  But see the next bug I am about
to file.

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#932042: [pkg-wicd-maint] Bug#932042: wicd-daemon: does not automatically reconnect on network connection loss when this is enabled

[Vincent Lefevre]

On 2019-07-15 01:26:48 +0200, Vincent Lefevre wrote:
> Control: retitle -1 wicd-daemon: does not automatically reconnect on network 
> connection loss if this network is invisible during the unique attempt
> 
> according to my explanation (which matches the code and log messages).

Actually, there may be 3 or 4 attempts, but during a short period.
Also, I'm not sure, because I didn't get the output

print 'Starting automatic reconnect process'

in the logs, but this may be another issue...

AutoConnect can be called in 2 places:

1.
if not daemon.GetGUIOpen():
print 'Killing wireless connection to switch to wired...'
wireless.DisconnectWireless()
daemon.AutoConnect(False, reply_handler=lambda *a:None,
   error_handler=lambda *a:None)
return self.update_state(misc.NOT_CONNECTED)

which is not possible when the GUI is open (thus this is not
what I could observe in some tests), and anyway the output
of the print is not in the logs.

2.
if daemon.ShouldAutoReconnect():
print 'Starting automatic reconnect process'
self.last_reconnect_time = time.time()
self.reconnect_tries += 1

# If we just lost a wireless connection, try to connect to that
# network again.  Otherwise just call Autoconnect.
cur_net_id = wireless.GetCurrentNetworkID(self.iwconfig)
if from_wireless and cur_net_id > -1:
# make sure disconnect scripts are run
# before we reconnect
print 'Disconnecting from network'
wireless.DisconnectWireless()
print 'Trying to reconnect to last used wireless ' + \
  'network'
wireless.ConnectWireless(cur_net_id)
else:
daemon.AutoConnect(True, reply_handler=reply_handle,
   error_handler=err_handle)

Same issue with the output of the print.

But the log system in wicd seems broken. I've just reported another
bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932094

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

Bug#932094: wicd-daemon: some log messages do not appear correctly and are mixed up with other log messages

[Vincent Lefevre]

Package: wicd-daemon
Version: 1.7.4+tb2-6
Severity: normal

In the wicd log file:

[...]
Throttling autoreconnect
Throttling autoreconnect
Throttling autoreconnect
Throttling autoreconnect
Throttling a2019/07/12 11:46:22 :: GetCurrentNetworkID: Returning -1, current 
network not found
2019/07/12 11:46:22 :: Autoconnecting...
[...]
2019/07/12 11:56:37 :: Autoconnecting...
2019/07/12 11:56:37 :: Starting wireless autoconnect...
2019/07/12 11:56:37 :: No wired connection present, attempting to autoconnect 
to wireless network
2019/07/12 11:56:37 :: scanning start
2019/07/12 11:56:37 :: scanning done
2019/07/12 11:56:37 :: found 0 networks:
2019/07/12 11:56:37 :: Unable to autoconnect, you'll have to manually connect
utoreconnect
Throttling autoreconnect
[...]

and similar problem in other places.

Thus there seems to be something completely wrong with the logs:
* Why no date for "Throttling autoreconnect"?
* Why has such a message been split by other log messages?

For the second item, I suspect some buffering issue. But I know
almost nothing about Python.

The concerned buggy log messages are:

  Starting automatic reconnect process
  Throttling autoreconnect

which both come from print from monitor.py (I got no other messages
from monitor.py).

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (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 wicd-daemon depends on:
ii  adduser   3.118
ii  dbus  1.12.16-1
ii  debconf   1.5.72
ii  iputils-ping  3:20190515-2
ii  isc-dhcp-client   4.4.1-2
ii  lsb-base  10.2019051400
ii  psmisc23.2-1
ii  python2.7.16-1
ii  python-dbus   1.2.8-3
ii  python-gobject-2  2.28.6-13+b1
ii  python-wicd   1.7.4+tb2-6
ii  wireless-tools30~pre9-13
ii  wpasupplicant 2:2.8-3

Versions of packages wicd-daemon recommends:
ii  rfkill 2.33.1-0.1
ii  wicd-curses [wicd-client]  1.7.4+tb2-6
ii  wicd-gtk [wicd-client] 1.7.4+tb2-6

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages wicd depends on:
ii  wicd-curses [wicd-client]  1.7.4+tb2-6
ii  wicd-gtk [wicd-client] 1.7.4+tb2-6

Versions of packages wicd-gtk depends on:
ii  python 2.7.16-1
ii  python-glade2  2.24.0-6
ii  python-gtk22.24.0-6

Versions of packages wicd-gtk recommends:
ii  menu   2.1.47+b1
ii  policykit-10.105-25
ii  python-notify  0.1.1-4

Versions of packages wicd-curses depends on:
ii  python2.7.16-1
ii  python-urwid  2.0.1-2+b1

Versions of packages wicd-curses recommends:
ii  sudo  1.8.27-1

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20180626.aebd88e-1
ii  python 2.7.16-1

Versions of packages python-wicd suggests:
ii  ethtool   1:4.19-1
ii  iproute2  5.2.0-1

-- Configuration Files:
/etc/wicd/encryption/templates/active changed:
wpa
wpa-peap
wpa-peap-wo-domain
wpa-psk
wpa-psk-hex
wpa2-leap
wpa2-peap
wpa2-peap-wo-domain
wep-hex
wep-passphrase
wep-shared
leap
ttls
eap
peap
peap-eduroam
peap-tkip
eap-tls
psu


-- debconf information:
* wicd/users:

Bug#932044: calibre: PDF to EPUB conversion failed with "No module named html2text"

[Norbert Preining]

Can you try installing
   python-html2text
And see if that fixes the problem? I send that there are insufficient 
dependencies declared.

Thanks

Norbert

(Away from PC so cannot check myself atm)

On July 14, 2019 7:59:32 PM GMT+09:00, Vincas Dargis  wrote:
>Package: calibre
>Version: 3.45.2+dfsg-1
>Severity: normal
>
>Dear Maintainer,
>
>I've tried to convert freely available "Elements of Programming" PDF
>(from http://elementsofprogramming.com) into EPUB, and got this error:
>
>```
>Traceback (most recent call last):
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 198, in
>_manifest_add_missing
>data = item.data
> File "/usr/lib/calibre/calibre/ebooks/oeb/base.py", line 1043, in data
>data = self._parse_xhtml(data)
>File "/usr/lib/calibre/calibre/ebooks/oeb/base.py", line 960, in
>_parse_xhtml
>filename=fname, non_html_file_tags={'ncx'})
>File "/usr/lib/calibre/calibre/ebooks/oeb/parse_utils.py", line 207, in
>parse_html
>data = preprocessor(data)
>File "/usr/lib/calibre/calibre/ebooks/conversion/preprocess.py", line
>684, in __call__
>html = preprocessor(html)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 784,
>in __call__
>html = self.markup_chapters(html, self.totalwords,
>self.blanks_between_paragraphs)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 334,
>in markup_chapters
>html = recurse_patterns(html, False)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 329,
>in recurse_patterns
>html = chapdetect.sub(self.chapter_head, html)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 63, in
>chapter_head
>txt_chap = delete_quotes.sub('', delete_whitespace.sub('\\g',
>html2text(chap)))
>File "/usr/lib/calibre/calibre/utils/html2text.py", line 8, in
>html2text
>from html2text import HTML2Text
>ImportError: No module named html2text
>
>Spine item 'id1' not found
>Traceback (most recent call last):
>  File "/usr/bin/calibre-parallel", line 20, in 
>sys.exit(main())
> File "/usr/lib/calibre/calibre/utils/ipc/worker.py", line 200, in main
>result = func(*args, **kwargs)
>File "/usr/lib/calibre/calibre/gui2/convert/gui_conversion.py", line
>42, in gui_convert_override
>override_input_metadata=True)
>File "/usr/lib/calibre/calibre/gui2/convert/gui_conversion.py", line
>27, in gui_convert
>plumber.run()
>File "/usr/lib/calibre/calibre/ebooks/conversion/plumber.py", line
>1121, in run
>for_regex_wizard=self.for_regex_wizard,
>removed_items=getattr(self.input_plugin, 'removed_items_to_ignore',
>()))
>File "/usr/lib/calibre/calibre/ebooks/conversion/plumber.py", line
>1315, in create_oebbook
>reader()(oeb, path_or_stream)
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 71, in
>__call__
>self._all_from_opf(opf)
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 703, in
>_all_from_opf
>self._spine_from_opf(opf)
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 348, in
>_spine_from_opf
>raise OEBError("Spine is empty")
>calibre.ebooks.oeb.base.OEBError: Spine is empty
>```
>
>Is it expected to installe additional Calibre dependencies manually
>or..?
>
>Full conversion log is attached.
>
>-- System Information:
>Debian Release: bullseye/sid
>  APT prefers unstable-debug
>APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
>'experimental-debug'), (1, 'experimental')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>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=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8),
>LANGUAGE=lt (charmap=UTF-8)
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages calibre depends on:
>ii  calibre-bin  3.45.2+dfsg-1
>ii  fonts-liberation 1:1.07.4-10
>ii  imagemagick  8:6.9.10.23+dfsg-2.1
>ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
>ii  libjpeg-turbo-progs  1:1.5.2-2+b1
>ii  libjs-coffeescript   1.12.8~dfsg-4
>ii  libjs-mathjax2.7.4+dfsg-1
>ii  optipng  0.7.7-1
>ii  poppler-utils0.71.0-5
>ii  python-apsw  3.27.2-r1-1
>ii  python-bs4   4.7.1-1
>ii  python-chardet   3.0.4-3
>ii  python-cherrypy3 8.9.1-2
>ii  python-css-parser1.0.4-1
>ii  python-cssselect 1.0.3-1
>ii  python-cssutils  1.0.2-2
>ii  python-dateutil  2.7.3-3
>ii  python-dbus  1.2.8-3
>ii  python-feedparser5.2.1-1
>ii  python-html5-parser  0.4.5-1
>ii  python-html5lib  1.0.1-1
>ii  python-lxml  4.3.3-2
>ii  python-markdown  3.0.1-3
>ii  python-mechanize 

Bug#931774: RFS: paho.mqtt.c/1.3.0-1 [ITP] -- Eclipse Paho MQTT C client library

[Nobuhiro Iwamatsu]

Hi,

2019年7月15日(月) 7:30 Roman Ondráček :
>
> Dear Mr Matsui,
>
> I am not sure if you received my answer on your comment on the site
> mentors.debian.net because I replied you via comment on the site
> mentors.debian.net.
>
> It should be fixed in the latest upload where I uploaded the forgotten
> source tarball.

Thanks, I can download all files from mentors.debian.net.
And I noticed two problem.

debian/control:

   We does not need libc6-dev (>= 2.19.18) in Build-Depends.
   This is provided in the build-essential package.

debian/changelog:

  Please squash changelog from -1 and -3.
  There are changelogs up to -3 now, but put them together. Packages uploaded to
  mentrors are not included in the package as Debian yet.

Best regards,
  Nobuhiro

Bug#932044: calibre: PDF to EPUB conversion failed with "No module named html2text"

[Norbert Preining]

Hi Vincas,

Thanks for the report, I'll look into it asap, most probably already tomorrow.

Best

Norbert

On July 14, 2019 7:59:32 PM GMT+09:00, Vincas Dargis  wrote:
>Package: calibre
>Version: 3.45.2+dfsg-1
>Severity: normal
>
>Dear Maintainer,
>
>I've tried to convert freely available "Elements of Programming" PDF
>(from http://elementsofprogramming.com) into EPUB, and got this error:
>
>```
>Traceback (most recent call last):
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 198, in
>_manifest_add_missing
>data = item.data
> File "/usr/lib/calibre/calibre/ebooks/oeb/base.py", line 1043, in data
>data = self._parse_xhtml(data)
>File "/usr/lib/calibre/calibre/ebooks/oeb/base.py", line 960, in
>_parse_xhtml
>filename=fname, non_html_file_tags={'ncx'})
>File "/usr/lib/calibre/calibre/ebooks/oeb/parse_utils.py", line 207, in
>parse_html
>data = preprocessor(data)
>File "/usr/lib/calibre/calibre/ebooks/conversion/preprocess.py", line
>684, in __call__
>html = preprocessor(html)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 784,
>in __call__
>html = self.markup_chapters(html, self.totalwords,
>self.blanks_between_paragraphs)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 334,
>in markup_chapters
>html = recurse_patterns(html, False)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 329,
>in recurse_patterns
>html = chapdetect.sub(self.chapter_head, html)
>File "/usr/lib/calibre/calibre/ebooks/conversion/utils.py", line 63, in
>chapter_head
>txt_chap = delete_quotes.sub('', delete_whitespace.sub('\\g',
>html2text(chap)))
>File "/usr/lib/calibre/calibre/utils/html2text.py", line 8, in
>html2text
>from html2text import HTML2Text
>ImportError: No module named html2text
>
>Spine item 'id1' not found
>Traceback (most recent call last):
>  File "/usr/bin/calibre-parallel", line 20, in 
>sys.exit(main())
> File "/usr/lib/calibre/calibre/utils/ipc/worker.py", line 200, in main
>result = func(*args, **kwargs)
>File "/usr/lib/calibre/calibre/gui2/convert/gui_conversion.py", line
>42, in gui_convert_override
>override_input_metadata=True)
>File "/usr/lib/calibre/calibre/gui2/convert/gui_conversion.py", line
>27, in gui_convert
>plumber.run()
>File "/usr/lib/calibre/calibre/ebooks/conversion/plumber.py", line
>1121, in run
>for_regex_wizard=self.for_regex_wizard,
>removed_items=getattr(self.input_plugin, 'removed_items_to_ignore',
>()))
>File "/usr/lib/calibre/calibre/ebooks/conversion/plumber.py", line
>1315, in create_oebbook
>reader()(oeb, path_or_stream)
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 71, in
>__call__
>self._all_from_opf(opf)
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 703, in
>_all_from_opf
>self._spine_from_opf(opf)
>File "/usr/lib/calibre/calibre/ebooks/oeb/reader.py", line 348, in
>_spine_from_opf
>raise OEBError("Spine is empty")
>calibre.ebooks.oeb.base.OEBError: Spine is empty
>```
>
>Is it expected to installe additional Calibre dependencies manually
>or..?
>
>Full conversion log is attached.
>
>-- System Information:
>Debian Release: bullseye/sid
>  APT prefers unstable-debug
>APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
>'experimental-debug'), (1, 'experimental')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>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=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8),
>LANGUAGE=lt (charmap=UTF-8)
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages calibre depends on:
>ii  calibre-bin  3.45.2+dfsg-1
>ii  fonts-liberation 1:1.07.4-10
>ii  imagemagick  8:6.9.10.23+dfsg-2.1
>ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
>ii  libjpeg-turbo-progs  1:1.5.2-2+b1
>ii  libjs-coffeescript   1.12.8~dfsg-4
>ii  libjs-mathjax2.7.4+dfsg-1
>ii  optipng  0.7.7-1
>ii  poppler-utils0.71.0-5
>ii  python-apsw  3.27.2-r1-1
>ii  python-bs4   4.7.1-1
>ii  python-chardet   3.0.4-3
>ii  python-cherrypy3 8.9.1-2
>ii  python-css-parser1.0.4-1
>ii  python-cssselect 1.0.3-1
>ii  python-cssutils  1.0.2-2
>ii  python-dateutil  2.7.3-3
>ii  python-dbus  1.2.8-3
>ii  python-feedparser5.2.1-1
>ii  python-html5-parser  0.4.5-1
>ii  python-html5lib  1.0.1-1
>ii  python-lxml  4.3.3-2
>ii  python-markdown  3.0.1-3
>ii  python-mechanize 1:0.2.5-3
>ii  python-msgpack   0.5.6-1+b1
>ii  python-netifaces

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Diederik de Haas]

On maandag 15 juli 2019 00:33:31 CEST Colin Watson wrote:
> > In the not too distant future, I'll remove that old drive (with WinXP on
> > it) from my system and my guess is that I then will have a problem.
> 
> That shouldn't be the case: we store the installation device using a
> /dev/disk/by-id/ path, which isn't affected by removing other disks.

It's not just any disk, it's the disk that grub-install is writing to on 
upgrade (iiutc), i.e. 'hd0,msdos2'. It should then boot (directly) from 
my NVMe drive, with has a gpt partition table. Pointing my BIOS to 
boot from that NVMe drive caused this problem for me and changing 
that to the drive-to-be-removed, fixed it.
Would that still not matter?

$ lsblk --output NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,PTTYPE,MODEL
NAMETYPE   SIZE FSTYPE MOUNTPOINT   PTTYPE MODEL
sda disk 279.5G dosWDC_WD3000HLFS-01G6U0
├─sda2  part20G ntfsdos
├─sda4  part 1K dos
├─sda5  part 8G swap   [SWAP]   dos
└─sda6  part 249.8G ext4   /home/diederik/media dos
sdb disk 232.9G dos
Samsung_SSD_750_EVO_250GB
└─sdb3  part 232.9G ext4dos
sdc disk 931.5G gpt
Samsung_SSD_860_EVO_1TB
└─sdc1  part   400G ext4gpt
nvme0n1 disk 953.9G gptSamsung SSD 960 PRO 
1TB
├─nvme0n1p1 part 3M gpt
├─nvme0n1p2 part 4G ext4   /bootgpt
├─nvme0n1p3 part30G ext4   /gpt
├─nvme0n1p4 part 108.6G ext4gpt
└─nvme0n1p5 part 811.3G ext4   /homegpt

(I might do a complete fresh install in which case my worry would be moot)

> > Will 'dpkg-reconfigure grub' update the debconf database and thereby fix
> > that problem?
> 
> grub-pc not grub, but yes, that updates the debconf database.

Thanks.

> NEWS file entries document issues that relate to upgrading to specific
> newer versions.  However, as I noted in my original closing message,
> this isn't triggered by upgrading to any specific version, but rather
> simply by upgrading or downgrading to *any* version ...

I just checked and saw that even old-old-stable has version 2.02X, so I 
might have actually ran into this issue before, but just not remember it or 
I did not have this issue to begin with.
I see/agree with your point and hopefully you won't have to deal with lots of 
bug reports like this.

Cheers,
   Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#932026: gnumeric: Gnumeric shows old version of ods spreadsheet

[Dmitry Smirnov]

On Sunday, 14 July 2019 7:11:02 PM AEST Helge Kreutzmann wrote:
> The attached file shows different content when opend with gnumeric
> than with libreoffice.

I could not reproduce the problem with the attached file.
Content looks identical in Gnumeric and LibreOffice Calc:
the exact number of rows and the same values in cells.
I could not see any difference whatsoever...

-- 
All the best,
 Dmitry Smirnov.

---

When everything has to be right, something isn't.
-- Stanisław Jerzy Lec


signature.asc
Description: This is a digitally signed message part.

Bug#932093: apt-cacher-ng: Remap-secdeb security urls are not merged

[Ryan Tandy]

Package: apt-cacher-ng
Version: 3.2-1
Severity: minor

Dear maintainer,

Thank you for adding the Remap-secdeb rule in the default config 
(#900325). However I think it could be improved.

The "MergingURLs" field contains only security.debian.org, so 
security.debian.org is remapped to secdeb but 
deb.debian.org/debian-security is not remapped at all.

Also, security.debian.org/debian-security is not remapped, so it gets 
interpreted as secdeb/debian-security instead secdeb.

To resolve both of these issues without regressing #884881, I propose 
this configuration:

Remap-secdeb: security.debian.org security.debian.org/debian-security 
deb.debian.org/debian-security /debian-security ; security.debian.org

This should remap all of the following to secdeb:

deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb http://security.debian.org/ buster/updates main contrib non-free
deb http://security.debian.org/debian-security/ buster/updates main contrib 
non-free
deb http://localhost:3142/debian-security/ buster/updates main contrib non-free

Of course then I start wondering whether that line gets long enough to 
be worth creating debsec_mirrors/backend_debsec files... :)

Thank you,
Ryan

Bug#932092: ITP: golang-github-knqyf263-nested -- Golang library for easier way to handle the nested data structure

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-nested
  Version : 0.0.1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/nested
* License : Expat
  Programming Lang: Go
  Description : Golang library for easier way to handle the nested data 
structure

 nested is a golang library that this provides functionality to easily handle
 nested data structures.
 .
 This library provides functions for set, get and delete data, and converting
 and getting data into integer.

Bug#932091: ITP: golang-github-knqyf263-go-dep-parser -- Golang library for dependency parser

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-knqyf263-go-dep-parser
  Version : 0.0~git20190521.1ef8521-1
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-dep-parser
* License : Expat
  Programming Lang: Go
  Description : Golang library for dependency parser

 go-dep-parser is golang library that dependency parser for multiple
 programming languages.
 .
 This parses package dependencies using the packaging system of each language.
 Supports the following systems:

  -bundler / Ruby
  -cargo / Haskell
  -composer / PHP
  -npm / node.js
  -pipinv / Python
  -poetry / Python
  -types / Python
  -yarn / node.js

Bug#932042: [pkg-wicd-maint] Bug#932042: wicd-daemon: does not automatically reconnect on network connection loss when this is enabled

[Vincent Lefevre]

Control: retitle -1 wicd-daemon: does not automatically reconnect on network 
connection loss if this network is invisible during the unique attempt

according to my explanation (which matches the code and log messages).

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

Bug#932042: [pkg-wicd-maint] Bug#932042: wicd-daemon: does not automatically reconnect on network connection loss when this is enabled

[Vincent Lefevre]

On 2019-07-14 15:30:01 +0200, Axel Beckert wrote:
> So I suspect that finding the reason for the "Unable to autoconnect,
> you'll have to manually connect" message is what would help to solve
> this.

I have an idea of what could have happened. When I did the test,
the network was not available for a few seconds; in particular,
if there was a scan or a connection attempt at that time, this
network could not be visible.

Thus I suppose that after the connection loss, wicd tried to
reconnect immediately, but the network was not there, and it failed
("GetCurrentNetworkID: Returning -1, current network not found"
in the log). Then wicd switched to the autoconnection feature
("Autoconnecting..." in the log), and could not due to my settings
(no networks had the "Automatically connect to this network" set).

... After looking at monitor.py, this seems to be the reason:

# If we just lost a wireless connection, try to connect to that
# network again.  Otherwise just call Autoconnect.
cur_net_id = wireless.GetCurrentNetworkID(self.iwconfig)
if from_wireless and cur_net_id > -1:
# make sure disconnect scripts are run
# before we reconnect
print 'Disconnecting from network'
wireless.DisconnectWireless()
print 'Trying to reconnect to last used wireless ' + \
  'network'
wireless.ConnectWireless(cur_net_id)
else:
daemon.AutoConnect(True, reply_handler=reply_handle,
   error_handler=err_handle)

Here, cur_net_id was -1 (network temporarily unavailable), and the
"else" case was executed.

On connection loss, wicd should keep on trying to connect to what
was the current network, just as if it had "Automatically connect
to this network" set. This is important. For instance, a hotspot
could reboot. In my Gemini WiFi case (not the test), I don't know
what happened, as my Gemini device was still running and I hadn't
touched it; perhaps a bad reception due to some nearby device...

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

Bug#833929: wicd-daemon: takes time to reconnect / autoconnect after connection loss

[Vincent Lefevre]

On 2018-12-04 20:12:59 +0700, Giap Tran wrote:
> Hi Vincent Lefevre,
> 
> The first, I'm sorry for handling late.
> Thank you for your patch. I applied the patch
> 
> https://salsa.debian.org/debian/wicd/merge_requests/1

Actually the patch may be wrong (though currently, wicd would
be better with it than without it); I think that it is just a
workaround to a more general bug:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932042

(there, for a network without "Automatically connect to this network"
set, this patch does not improve anything).

The reason is given here:

def GetGUIOpen(self):
""" Returns the value of gui_open.

Returns the vlaue of gui_open, which is a boolean that keeps track
of the state of the wicd GUI.  If the GUI is open, wicd will not
try to automatically reconnect to networks, as this behavior can
be annoying for the user while trying to use the GUI.

NOTE: It's possible for this to become out of sync, particularly if
the wicd.py is not exited properly while the GUI is open.  We should
probably implement some kind of pid system to do it properly.

ANOTHER NOTE: This isn't used by anything yet!

"""
return bool(self.gui_open)

but I disagree. I think that one needs to make a difference between
reconnecting to some network because the connection was lost due to
some external cause and connecting to some network that has the
option "Automatically connect to this network".

In the former case, one wants wicd to reconnect even when the GUI is
open. The latter case occurs when the user chose to disconnect, e.g.
via the GUI (but not necessarily). Obviously, if the user chose to
disconnect from the GUI, one does not want wicd to reconnect to this
network (or another one). But IMHO, if the user closes the GUI after
disconnecting, wicd shouldn't try to connect automatically either.

The autoconnection logic should be rethought. IMHO, it should occur
in 2 cases (if I'm not missing anything):
  * on startup;
  * when the network was not present in the previous scan (there may
be corner cases, where the user disconnected from this network,
then this network was no longer present, and later this network
reappears... it is not clear what to do, but well, in this case,
the user could disconnect again anyway).

Note: This does not cover the reconnection after a connection loss,
which should have a separate logic.

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

Bug#931969: grub2 fails to boot on sparc64 systems with GPT partitioning

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hello!

The attached patch by James Clarke fixes the problem.
Could you please include it in the next upload of grub2?

It has already been forwarded upstream [1].

Adrian

> [1] https://lists.gnu.org/archive/html/grub-devel/2019-07/msg00031.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From fdaeef94ff74db77a45ee0bb0df11fc540bcb78c Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Mon, 15 Jul 2019 00:52:07 +0200
Subject: [PATCH] sparc64: Fix BIOS Boot Partition support

Currently, gpt_offset is uninitialised when using a BIOS Boot Partition
but is used unconditionally inside save_blocklists. Instead, ensure it
is always initialised to 0 (note that there is already separate code to
do the equivalent adjustment after we call save_blocklists on this code
path).

This patch has been tested on a T5-2 LDOM.
---
 util/setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/util/setup.c b/util/setup.c
index 6f88f3cc4..3be88aae1 100644
--- a/util/setup.c
+++ b/util/setup.c
@@ -270,6 +270,9 @@ SETUP (const char *dir,
 #ifdef GRUB_SETUP_BIOS
   bl.current_segment =
 GRUB_BOOT_I386_PC_KERNEL_SEG + (GRUB_DISK_SECTOR_SIZE >> 4);
+#endif
+#ifdef GRUB_SETUP_SPARC64
+  bl.gpt_offset = 0;
 #endif
   bl.last_length = 0;
 
@@ -730,7 +733,6 @@ unable_to_embed:
 #ifdef GRUB_SETUP_SPARC64
   {
 grub_partition_t container = root_dev->disk->partition;
-bl.gpt_offset = 0;
 
 if (grub_strstr (container->partmap->name, "gpt"))
   bl.gpt_offset = grub_partition_get_start (container);
-- 
2.22.0

Bug#932090: firebird3.0: Please include patch to ensure correct sizes of on-disk structures

[John Paul Adrian Glaubitz]

Source: firebird3.0
Version: 3.0.5.33100.ds4-3
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

firebird3.0 currently fails to build from source on m68k because the native
alignment of 16 bits on this architecture causes the on-disk structures to
have unexpected sizes.

With the attached patch, padding is added to the affected on-disk structures
such that the correct sizes are always guaranteed. Since this particular
padding happens automatically and implicitly for architectures with 32 or
64 bits native alignment, the actual sizes and offsets of the on-disk
structures do not change and therefore no compatibility break is going
to occur.

Using explicit padding has the advantage that the actual sizes and offsets
are completely visible and transparent to anyone reading the code.

I will forward this patch upstream.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add padding for on-disk structures
 In order to guarantee that the on-disk structures have always the expected
 sizes, we should use padding fields within these structs rather than relying
 on the native alignment of the target architecture which can result in
 unexpected sizes for architectures with unusual native alignment.
 .
Author: John Paul Adrian Glaubitz 
Last-Update: 2019-07-14

Index: firebird3.0-3.0.5.33100.ds4/src/jrd/ods.h
===
--- firebird3.0-3.0.5.33100.ds4.orig/src/jrd/ods.h
+++ firebird3.0-3.0.5.33100.ds4/src/jrd/ods.h
@@ -423,6 +423,7 @@ struct header_page
SLONG hdr_att_high; // High word of the 
next attachment counter
USHORT hdr_tra_high[4]; // High words of the 
transaction counters
UCHAR hdr_data[1];  // Misc data
+   USHORT hdr_padding; // Padding
 };
 
 #define HDR_SIZE static_cast(offsetof(Ods::header_page, 
hdr_data[0]))
@@ -479,6 +480,7 @@ struct page_inv_page
ULONG pip_extent;   // Lowest free extent
ULONG pip_used; // Number of pages allocated 
from this PIP page
UCHAR pip_bits[1];
+   USHORT pip_padding; // Padding
 };
 
 
@@ -530,6 +532,7 @@ struct pointer_page
USHORT ppg_count;   // Number of slots active
USHORT ppg_relation;// Relation id
USHORT ppg_min_space;   // Lowest slot with space available
+   USHORT ppg_padding; // Padding
ULONG ppg_page[1];  // Data page vector
 };
 
@@ -564,6 +567,7 @@ struct tx_inv_page
pag tip_header;
ULONG tip_next; // Next transaction inventory 
page
UCHAR tip_transactions[1];
+   USHORT tip_padding; // Padding
 };
 
 
@@ -588,6 +592,7 @@ struct rhd
USHORT rhd_flags;   // flags, etc
UCHAR rhd_format;   // format version
UCHAR rhd_data[1];  // record data
+   USHORT rhd_padding; // padding
 };
 
 #define RHD_SIZE static_cast(offsetof(Ods::rhd, rhd_data[0]))
@@ -603,6 +608,7 @@ struct rhde
UCHAR rhde_format;  // format version   // 
until here, same as rhd
USHORT rhde_tra_high;   // higher bits of transaction id
UCHAR rhde_data[1]; // record data
+   USHORT rhde_padding;// padding
 };
 
 #define RHDE_SIZE static_cast(offsetof(Ods::rhde, rhde_data[0]))
@@ -634,6 +640,7 @@ struct blh
USHORT blh_max_segment; // Longest segment
USHORT blh_flags;   // flags, etc
UCHAR blh_level;// Number of address levels, 
see blb_level in blb.h
+   USHORT blh_padding; // Padding
ULONG blh_count;// Total number of segments
ULONG blh_length;   // Total length of data
USHORT blh_sub_type;// Blob sub-type
Index: firebird3.0-3.0.5.33100.ds4/src/misc/ods.txt
===
--- firebird3.0-3.0.5.33100.ds4.orig/src/misc/ods.txt
+++ firebird3.0-3.0.5.33100.ds4/src/misc/ods.txt
@@ -87,6 +87,7 @@ hdr_crypt_plugin 88
 hdr_att_high 120
 hdr_tra_high 124
 hdr_data 132
+hdr_padding 134
 
  *** struct page_inv_page 32
 pip_header 0
@@ -94,6 +95,7 @@ pip_min 16
 pip_extent 20
 pip_used 24
 pip_bits 28
+pip_padding 30
 
  *** struct scns_page 24
 scn_header 0
@@ -107,12 +109,14 @@ ppg_next 20
 ppg_count 24
 ppg_relation 26
 ppg_min_space 28
+ppg_padding 30
 ppg_page 32
 
  *** struct tx_inv_page 24
 tip_header 0

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Colin Watson]

On Sun, Jul 14, 2019 at 11:56:39PM +0200, Diederik de Haas wrote:
> On zaterdag 13 juli 2019 09:05:44 CEST Sven Joachim wrote:
> > What I finally figured out after getting my system to boot again, is
> > that grub was still configured to install its core image to /dev/sda,
> > the old hard disk.  This configuration is apparently only stored in the
> > debconf database and nowhere else.
> 
> In the not too distant future, I'll remove that old drive (with WinXP on it) 
> from my system and my guess is that I then will have a problem.

That shouldn't be the case: we store the installation device using a
/dev/disk/by-id/ path, which isn't affected by removing other disks.

> Will 'dpkg-reconfigure grub' update the debconf database and thereby fix that 
> problem?

grub-pc not grub, but yes, that updates the debconf database.  (This is
not the same problem that the original reporter of this bug had; they
were using UEFI, not BIOS, which is generally less susceptible to this
class of problem although apparently they still managed to run into it.
In your case the bug is in whatever documentation advised you to simply
run grub-install when switching over to a new disk rather than
reconfiguring the system to make this persistent.)

> Storing that value in f.e. /etc/default/grub seems like a much more logical 
> place (to me).

In the abstract I can see that point, but I'm afraid that specific
location isn't possible since that file is used by a different layer of
the code.  At some point it would probably be a good idea to put the
configuration somewhere in /etc instead, although I'm sure people would
still miss it.

> I understand that this bug was closed as it was in my case indeed a 
> misconfiguration. Due to the closing of the bug, apt-listbugs didn't inform 
> me 
> of a potential issue and it also didn't turn up when I started reportbug 
> myself to report the issue. I happened to see this bug by accident.
> Having the NEWS file inform me and others of this potential issue would've 
> been 
> nice and probably prevents several similar bugs from being reported.

NEWS file entries document issues that relate to upgrading to specific
newer versions.  However, as I noted in my original closing message,
this isn't triggered by upgrading to any specific version, but rather
simply by upgrading or downgrading to *any* version with a different
interface between core image and modules.  While this happens to have
been somewhat stable for a while, it could in principle change as
frequently as every single package upload, so the NEWS file isn't a
suitable place to discuss it.

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

Bug#931774: RFS: paho.mqtt.c/1.3.0-1 [ITP] -- Eclipse Paho MQTT C client library

[Roman Ondráček]

Dear Mr Matsui,

I am not sure if you received my answer on your comment on the site
mentors.debian.net because I replied you via comment on the site
mentors.debian.net.

It should be fixed in the latest upload where I uploaded the forgotten
source tarball.

Yours sincerely,
Roman Ondráček

Dne 11. 07. 19 v 10:06 Roman Ondráček napsal(a):
> Dear Mr Iwamatsu,
> 
> Thank you for your suggestion. License under the debian directory is
> already changed to the same license as upstream.
> 
> Yours sincerely,
> Roman Ondráček
> 
> Dne 11. 07. 19 v 4:08 Nobuhiro Iwamatsu napsal(a):
>> Hi,
>>
>> I have a question.
>> You are overriding possible-gpl-code-linked-with-openssl. This is
>> because the license under the debian directory is GPL v2+.
>> If possible, change to the same license (EPL) as Upstream. If you do,
>> you will solve this overriding.
>>
>> Best regards,
>>   Nobuhiro
>>
>> 2019年7月10日(水) 18:33 Roman Ondráček :
>>>
>>> Package: sponsorship-requests
>>> Severity: wishlist
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "paho.mqtt.c"
>>>
>>> * Package name: paho.mqtt.c
>>>   Version : 1.3.0-1
>>>   Upstream Author : Eclipse Paho Development Team 
>>> * URL : https://github.com/eclipse/paho.mqtt.c
>>> * License : EPL-1.0
>>>   Section : libs
>>>
>>> It builds those binary packages:
>>>
>>> libpaho-mqtt-dev - Eclipse Paho MQTT C client - development files
>>> libpaho-mqtt1.3 - Eclipse Paho MQTT C client - shared libraries
>>> paho.mqtt.c-examples - Eclipse Paho MQTT C client - example files
>>>
>>> To access further information about this package, please visit the
>>> following URL:
>>>
>>> https://mentors.debian.net/package/paho.mqtt.c
>>>
>>>
>>> Alternatively, one can download the package with dget using this command:
>>>
>>>   dget -x
>>> https://mentors.debian.net/debian/pool/main/p/paho.mqtt.c/paho.mqtt.c_1.3.0-1.dsc
>>>
>>> More information about paho.mqtt.c can be obtained from
>>> https://www.eclipse.org/paho/clients/c/.
>>>
>>> Changes since the last upload:
>>>
>>>   * Initial release (Closes: #931716)
>>>
>>> Regards,
>>>  Roman Ondráček
>>>
>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Bug#932089: openssh-server: Cannot log into openssh-server on buster/mipsel

[Colin Watson]

On Sun, Jul 14, 2019 at 02:22:21PM -0700, Francois Marier wrote:
> $ systemctl stop sshd
> $ mkdir /run/sshd
> $ /usr/sbin/sshd -ddd

(You might find it more convenient to temporarily run sshd on a high
port using the -p option, rather than having to stop the system's sshd
service.)

> debug3: user_specific_delay: user specific delay 0.000ms [preauth]
> debug1: monitor_read_log: child log fd closed

Judging from this, the crash (or is it a hang?  I'm assuming a crash) is
near the start of ensure_minimum_time_since, probably inside
monotime_ts.  I suspect there's something wrong with the seccomp
sandboxing of the privileged monitor process on mipsel.

Could you try installing the auditd package, and then running this
before starting sshd:

  auditctl -a exit,always -F uid="$(id -u sshd)"

(Replace -a with -d to undo this.)  You should then get a log of
syscalls made by sshd's privileged monitor process in
/var/log/audit/audit.log; I'd like the lines containing the string
'exe="/usr/sbin/sshd"'.

> 6. I explicitly disabled the sandbox using `UsePrivilegeSeparation yes` as
> per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868009.

You're right that this would once have been a good test to run to
exclude the possibility of a seccomp sandbox bug.  However, the ability
to configure UsePrivilegeSeparation was withdrawn in OpenSSH 7.5, so
this test is now ineffective.

Thanks,

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

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Russ Allbery]

Guillem Jover  writes:

>> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
>> index 81b3542..d491d57 100644
>> --- a/policy/ch-controlfields.rst
>> +++ b/policy/ch-controlfields.rst
>> @@ -979,7 +979,10 @@ repository where the Debian source package is developed.
>>  or ``hg clone`` command. If no branch is specified, the packaging
>>  should be on the default branch.
>>  
>> -More than one different VCS may be specified for the same package.
>> +Only one ``Vcs-`` field should be given for a package.  If the
>> +package is maintained in multple version control systems, the
>> +maintainer should specify the one that they would prefer other people
>> +to use as the basis for proposing changes to the package.
>>  
>>  For both fields, any URLs given should use a scheme that provides
>>  confidentiality (``https``, for example, rather than ``http`` or ``git``)
>> 
>> Before we make that change it would be great if someone could check how
>> many packages we would make buggy.  (I'm sure there's some good way to do
>> this with standard tools, but I don't know off-hand how to do it.)

> Yeah, that's something that crossed my mind too before reassigning.
> I've just done it now:

Ah, thank you, the awk magic was the piece that didn't come to mind.

> And that one instance seems to be "bogus" anyway as the Vcs-Svn URL
> does not exist anymore. So I'd say the above change looks perfectly
> fine to me, thanks! :)

> So, «Seconded».

In that case, should we increase the strength of this by changing the
first sentence?  I'm not seeing much purpose served by developer
discretion here, and this clarifies matters for tool developers.

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 81b3542..8124d64 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -979,7 +979,10 @@ repository where the Debian source package is developed.
 or ``hg clone`` command. If no branch is specified, the packaging
 should be on the default branch.
 
-More than one different VCS may be specified for the same package.
+A package control file must not have more than one ``Vcs-``
+field.  If the package is maintained in multple version control
+systems, the maintainer should specify the one that they would prefer
+other people to use as the basis for proposing changes to the package.
 
 For both fields, any URLs given should use a scheme that provides
 confidentiality (``https``, for example, rather than ``http`` or ``git``)

-- 
Russ Allbery (r...@debian.org)   

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Diederik de Haas]

Thanks for your reply, it was very helpful :)

On zaterdag 13 juli 2019 09:05:44 CEST Sven Joachim wrote:
> Most likely you had grub configured to install to the wrong disk, this
> is what happened to me.  When I installed an SSD into my old PC back in
> December 2016, I copied all files from the already present hard drive,
> ran "grub-install /dev/sdb" and told the BIOS to boot from the SSD
> (which is /dev/sdb).  Everything was working fine until I upgraded
> grub-pc to version 2.04.

That sounds familiar.
$ grep 'set root' /boot/grub/grub.cfg
set root='hd0,msdos2'

And that indeed points to my WinXP partition.
Which makes sense as this system was setup as dual boot between WinXP 
(installed first) and Debian.
But I had configured in my BIOS (in an updated system with new MB/CPU/RAM/etc) 
to use my NVMe drive as first boot option. And that turned out to be the 
misconfiguration Colin talked about. Setting it to the drive that hosts my 
WinXP drive, made it work again.

> What I finally figured out after getting my system to boot again, is
> that grub was still configured to install its core image to /dev/sda,
> the old hard disk.  This configuration is apparently only stored in the
> debconf database and nowhere else.

In the not too distant future, I'll remove that old drive (with WinXP on it) 
from my system and my guess is that I then will have a problem.
Will 'dpkg-reconfigure grub' update the debconf database and thereby fix that 
problem?
Storing that value in f.e. /etc/default/grub seems like a much more logical 
place (to me).

I understand that this bug was closed as it was in my case indeed a 
misconfiguration. Due to the closing of the bug, apt-listbugs didn't inform me 
of a potential issue and it also didn't turn up when I started reportbug 
myself to report the issue. I happened to see this bug by accident.
Having the NEWS file inform me and others of this potential issue would've been 
nice and probably prevents several similar bugs from being reported.

Thanks again for your help,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#932085: grub-common: Grub can't load initrd for Xen after upgrade to Buster

[Colin Watson]

On Sun, Jul 14, 2019 at 01:27:23PM -0700, Slava Kryvel wrote:
> After upgrade from Debian 9.9 to Debian 10 I have got unbootable system.
> 
> I'm using Xen hypervisor, which was also upgraded from 4.8 to 4.11
> during OS upgrade.
> UEFI is enabled.
> 
> After upgrade was finished, I was unable to boot again to Xen kernel.
> But normal Debian kernel was still bootable.

Were there any specific error messages when trying to boot Xen?

> I have found a workaround to fix my issue - remove option --nounzip from
> initrd loading line in grub configuration file /etc/grub.d/20_linux_xen
> 
> - module2 --nounzip /boot/initrd.img-4.19.0-5-amd64
> + module2 /boot/initrd.img-4.19.0-5-amd64
> 
> I'm not sure there is issue in config, maybe I did something wrong.
> So in this case please explain what is correct behavior ?

I'm using Xen and things seem to work fine for me (without removing
--nounzip); my Xen system doesn't use UEFI, though.

I'm CCing a few folks who've contributed to GRUB's Xen support in one
way or another in the recent past; hopefully at least one of them can
help here?

Thanks,

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

Bug#932088: gdebi: more info

[m . alfaeko]

Package: gdebi
Version: 0.9.5.7+nmu3
Followup-For: Bug #932088

Dear Maintainer,

When attempting last try through cli i managed to get to the authentication
phase, but auth with correct password failed. The failure was with following
message
 "polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
 AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.
".

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

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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu3
ii  gir1.2-gtk-3.03.24.5-1
ii  gir1.2-vte-2.91   0.54.2-2
ii  gnome-icon-theme  3.12.0-3
ii  policykit-1   0.105-25
ii  python3   3.7.3-1
ii  python3-gi3.30.4-1

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.24992-1+b2
ii  lintian   2.15.0
ii  shared-mime-info  1.10-1

gdebi suggests no packages.

-- no debconf information

Bug#532815: latex-beamer: Please include the "beamerthemeprogressbar"

[Hilmar Preusse]

On 12.06.09 00:20, Alexander Reichle-Schmehl wrote:

Hi Alexander,

> There's a nice theme for Latex beamer.  Main advantage of that theme is, that
> it has a progress bar showing how far your progressed in your talk.
>
> It's available from
> http://www.cert.fr/dcsd/THESES/sbouveret/francais/LaTeX.html and licensend
> under the terms of the GPL-2.  I think it would be worth to be added in 
> Debian,
> but don't think it warrants a package for itself, since it's archive is just
> 5kb.  So, maybe you could add it to the latex-beamer main package?
>
The old URL is dead, I guess it is now [1]. I didn't find the package on
CTAN. Please tell the author he should upload to CTAN, so it will make
its way into TeX Live.

Hilmar

[1] https://github.com/cedricmauclair/beamer-progressbar
--
sigfault
#206401 http://counter.li.org

Bug#932089: openssh-server: Cannot log into openssh-server on buster/mipsel

[Francois Marier]

Package: openssh-server
Version: 1:7.9p1-10
Severity: important

In a fairly minimal buster installation on mipsel, I am unable to log into
openssh-server from a Debian unstable client.

Here's the debug log when I start sshd manually:

$ systemctl stop sshd
$ mkdir /run/sshd
$ /usr/sbin/sshd -ddd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 262
debug2: parse_server_config: config /etc/ssh/sshd_config len 262
debug3: /etc/ssh/sshd_config:32 setting PermitRootLogin yes
debug3: /etc/ssh/sshd_config:56 setting PasswordAuthentication yes
debug3: /etc/ssh/sshd_config:61 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:84 setting UsePAM yes
debug3: /etc/ssh/sshd_config:89 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:93 setting PrintMotd no
debug3: /etc/ssh/sshd_config:111 setting AcceptEnv LANG LC_* TZ
debug1: sshd version OpenSSH_7.9, OpenSSL 1.1.1c  28 May 2019
debug1: private host key #0: ssh-rsa SHA256:x
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:x
debug1: private host key #2: ssh-ed25519 SHA256:x
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug3: oom_adjust_setup
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 262
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.1.5 port 44740 on 192.168.1.172 port 22
debug1: Client protocol version 2.0; client software version OpenSSH_8.0p1 
Debian-3
debug1: match: OpenSSH_8.0p1 Debian-3 pat OpenSSH* compat 0x0400
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 6055
debug3: preauth child monitor started
debug3: privsep user:group 104:65534 [preauth]
debug1: permanently_set_uid: 104/65534 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: ssh_sandbox_child: prctl(PR_SET_SECCOMP): Invalid argument [preauth]
debug1: list_hostkey_types: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug3: send packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug3: receive packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: local server KEXINIT proposal [preauth]
debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-shh
a256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
 [preauth]
debug2: host key algorithms: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
 [preauth]
debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
 [preauth]
debug2: MACs ctos: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac-66
4...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 
[preauth]
debug2: MACs stoc: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac-66
4...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 
[preauth]
debug2: compression ctos: none,z...@openssh.com [preauth]
debug2: compression stoc: none,z...@openssh.com [preauth]
debug2: languages ctos:  [preauth]
debug2: languages stoc:  [preauth]
debug2: first_kex_follows 0  [preauth]
debug2: reserved 0  [preauth]
debug2: peer client KEXINIT proposal [preauth]
debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-shh
a256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
 [preauth]
debug2: host key algorithms: 
ssh-ed25519-cert-...@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdss

Bug#928631:

[Diederik de Haas]

Hi,

On zondag 14 juli 2019 21:38:14 CEST Hillel Lubman wrote:
> 20190502-1 is already outdated, since amdgpu firmware had some updates
> upstream:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> /log/amdgpu
> 
> Does this problem still occur if you use latest upstream firmware?

I first updated my local git repo to 3d1e5537dbd8ac36c01fc33e7bf525e5c8e4b708.

I then upgraded back to the latest package versions and rebooted and 
encountered the same issue as reported.

Started SystemRescueCD and chrooted into my system (just like before), but I 
now copied the vega10* files from the amdgpu dir to /lib/firmware/amdgpu/ and 
rebooted again.
And now it succeeded :D
Thanks a lot for the hint!

> By the way, it works well for me (Ryzen 7 2700X / Vega 56), but I'm running
> kernel 5.2.1 in Debian testing.

I didn't upgrade my kernel, so I'm still on 4.19.0-5-amd64 (4.19.37-5) in 
Debian Sid.
So the only thing that was needed for me was updating the firmware files to the 
latest version.

Cheers,
  Diederik

signature.asc
Description: This is a digitally signed message part.

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Guillem Jover]

Hi!

On Sun, 2019-07-14 at 09:31:16 -0700, Russ Allbery wrote:
> Yeah, this just seems generally wrong to me.  I assume the idea was that a
> package may have mirrors of its packaging repository in multiple VCS
> systems and list all of them, but I'm dubious there's much point.  My
> leaning is to make the following change:

Right, the problem though is that I'm not even sure consumers of these
fields will behave properly and consistently when multiple Vcs-
fields are present? (I'd assume they do not handle that case
gracefully.)

> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 81b3542..d491d57 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -979,7 +979,10 @@ repository where the Debian source package is developed.
>  or ``hg clone`` command. If no branch is specified, the packaging
>  should be on the default branch.
>  
> -More than one different VCS may be specified for the same package.
> +Only one ``Vcs-`` field should be given for a package.  If the
> +package is maintained in multple version control systems, the
> +maintainer should specify the one that they would prefer other people
> +to use as the basis for proposing changes to the package.
>  
>  For both fields, any URLs given should use a scheme that provides
>  confidentiality (``https``, for example, rather than ``http`` or ``git``)
> 
> Before we make that change it would be great if someone could check how
> many packages we would make buggy.  (I'm sure there's some good way to do
> this with standard tools, but I don't know off-hand how to do it.)

Yeah, that's something that crossed my mind too before reassigning.
I've just done it now:

  ,--- grep-deb-sources ---
  #!/bin/sh
  set -e
  set -u
  Sources=$(apt-get indextargets --format '$(FILENAME)' 'Identifier: Sources')
  /usr/lib/apt/apt-helper cat-file $Sources | grep-dctrl "$@"
  `---

  ,---
  $ grep-deb-sources -sPackage,Vcs-Arch,Vcs-Bzr,Vcs-Cvs,Vcs-Darcs,\
  Vcs-Git,Vcs-Hg,Vcs-Mtn,Vcs-Svn Vcs- \
| awk -F "\n" -v RS="" '{ if (NF > 2) print $0, "\n" }'
  Package: netselect
  Vcs-Git: git://github.com/apenwarr/netselect.git
  Vcs-Svn: svn://svn.debian.org/svn/collab-maint/deb-maint/netselect/trunk
  `---

And that one instance seems to be "bogus" anyway as the Vcs-Svn URL
does not exist anymore. So I'd say the above change looks perfectly
fine to me, thanks! :)

So, «Seconded».

Thanks,
Guillem

Bug#932088: gdebi doenst ask for a root password. just silently closes

[m . alfaeko]

Package: gdebi
Version: 0.9.5.7+nmu3
Severity: important

Dear Maintainer,

I would want to report a bug in package gdebi. When i attempt to install some 
package
with gdebi it just closes without displaing any error. I found a error message 
in
.xsession-errors saying "Refusing to render service to dead parents.". Tried on 
my host
system with debian 10 and not modified debian 10 in vbox.

Gdebi is not usable.

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

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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu3
ii  gir1.2-gtk-3.03.24.5-1
ii  gir1.2-vte-2.91   0.54.2-2
ii  gnome-icon-theme  3.12.0-3
ii  policykit-1   0.105-25
ii  python3   3.7.3-1
ii  python3-gi3.30.4-1

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.24992-1+b2
ii  lintian   2.15.0
ii  shared-mime-info  1.10-1

gdebi suggests no packages.

-- no debconf information

Bug#931771: subversion: E170013 (unable to connect to a repository) and E120171 (Error occured during SSL communication)

[Florian Weimer]

* Martin:

> svn version 1.9.5-1+deb9u3 from stretch works fine, but after upgrading to the
> fresh Debian buster stable release I cannot svn checkout using subversion
> v1.10.4-1

Is the affected repository publicly accessible?

Bug#932081: sogo: Unable to connect to a remote IMAP server.

[Koichi MATSUMOTO]

*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
  Fresh install of Dovecot IMAP server with SSL.
  Fresh install of Sogo on a different instance from Dovecot server.
* What exactly did you do (or not do) that was effective (or ineffective)?
  I add account to SOGo on a remote IMAP server that I could retrieve mails 
from Desktop mail client.
* What was the outcome of this action?
  Please see attached the log file.
* What outcome did you expect instead?
  Connection to a remote IMAP server successfully.
*** End of the template - remove these template lines *** 

—Log File
-- SOGo Log
Jul 13 06:49:38 sogod [4645]: <0x0x5643dd010430[NGImap4Client]> TLS started 
successfully.
Jul 13 06:49:38 sogod [4645]: <0x0x5643dd010430[NGImap4Client]> 
ERROR(-[NGImap4Client _processUnknownCommandParserException:]): catched 
non-IMAP4 parsing exception UnexpectedEndOfStream: the parsed stream ended 
unexpectedly
Jul 13 06:49:38 sogod [4645]: [ERROR] 
<0x0x5643dd00e2f0[NGImap4ConnectionManager]> IMAP4 login failed:
Jul 13 06:49:38 sogod [4645]: <0x5643dccac200[SOGoMailAccount]:0> renewing 
imap4 password
Jul 13 06:49:38 sogod [4645]: <0x0x5643dd034ef0[NGImap4Client]> TLS started 
successfully.
Jul 13 06:49:38 sogod [4645]: <0x0x5643dd034ef0[NGImap4Client]> 
ERROR(-[NGImap4Client _processUnknownCommandParserException:]): catched 
non-IMAP4 parsing exception UnexpectedEndOfStream: the parsed stream ended 
unexpectedly
Jul 13 06:49:38 sogod [4645]: [ERROR] 
<0x0x5643dd00e2f0[NGImap4ConnectionManager]> IMAP4 login failed:
Jul 13 06:49:38 sogod [4645]: [ERROR] <0x5643dccac200[SOGoMailAccount]:0> Could 
not connect IMAP4
Jul 13 06:49:38 sogod [4645]: 203.141.134.112 "GET /SOGo/so/mzch/Mail/0/view 
HTTP/1.1" 200 17/0 0.168 - - 4M
Jul 13 06:49:38 sogod [4645]: <0x0x5643dcf5fda0[NGHttpRequest]> got 2 values 
for cookie 'XSRF-TOKEN', using first only: 
046eab9994feeb60b2bb8f1a867c3e5eec55ac9c,1561253855.lejy384sa9ro.KwYdIDKYPsvb60g
Jul 13 06:49:38 sogod [4645]: <0x0x5643dd04f1e0[NGImap4Client]> TLS started 
successfully.
Jul 13 06:49:38 sogod [4645]: <0x0x5643dd04f1e0[NGImap4Client]> 
ERROR(-[NGImap4Client _processUnknownCommandParserException:]): catched 
non-IMAP4 parsing exception UnexpectedEndOfStream: the parsed stream ended 
unexpectedly
Jul 13 06:49:38 sogod [4645]: [ERROR] 
<0x0x5643dd00e2f0[NGImap4ConnectionManager]> IMAP4 login failed:
Jul 13 06:49:38 sogod [4645]: <0x5643dd046c10[SOGoMailAccount]:0> renewing 
imap4 password
Jul 13 06:49:38 sogod [4645]: <0x0x5643dcff3950[NGImap4Client]> TLS started 
successfully.
Jul 13 06:49:38 sogod [4645]: <0x0x5643dcff3950[NGImap4Client]> 
ERROR(-[NGImap4Client _processUnknownCommandParserException:]): catched 
non-IMAP4 parsing exception UnexpectedEndOfStream: the parsed stream ended 
unexpectedly
Jul 13 06:49:38 sogod [4645]: [ERROR] 
<0x0x5643dd00e2f0[NGImap4ConnectionManager]> IMAP4 login failed:
Jul 13 06:49:38 sogod [4645]: [ERROR] <0x5643dd046c10[SOGoMailAccount]:0> Could 
not connect IMAP4
Jul 13 06:49:38 sogod [4645]: 203.141.134.112 "POST 
/SOGo/so/mzch/Mail/unseenCount HTTP/1.1" 200 21/31 0.145 - - 0

-- Dovecot Log

Jul 12 23:49:38 n03 dovecot: auth: Debug: Loading modules from directory: 
/usr/lib/dovecot/modules/auth
Jul 12 23:49:38 n03 dovecot: auth: Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/lib20_auth_var_expand_crypt.so
Jul 12 23:49:38 n03 dovecot: auth: Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/libdriver_mysql.so
Jul 12 23:49:38 n03 dovecot: auth: Debug: Read auth token secret from 
/var/run/dovecot/auth-token-secret.dat
Jul 12 23:49:38 n03 dovecot: auth: Debug: auth client connected (pid=31797)
Jul 12 23:49:38 n03 dovecot: auth: Debug: client in: 
AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=3PE/boqNIJ/AqM+K#011lip=192.168.207.22#011rip=192.168.207.138#011lport=143#011rport=40736#011ssl_cipher=TLS_AES_256_GCM_SHA384#011ssl_cipher_bits=256#011ssl_pfs=KxANY#011ssl_protocol=TLSv1.3#011resp=
Jul 12 23:49:38 n03 dovecot: auth-worker(31800): Debug: Loading modules from 
directory: /usr/lib/dovecot/modules/auth
Jul 12 23:49:38 n03 dovecot: auth-worker(31800): Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/lib20_auth_var_expand_crypt.so
Jul 12 23:49:38 n03 dovecot: auth-worker(31800): Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/libdriver_mysql.so
Jul 12 23:49:38 n03 dovecot: auth: Debug: auth client connected (pid=31801)
Jul 12 23:49:38 n03 dovecot: auth-worker(31800): Debug: 
sql(m...@uixis.com,192.168.207.138,<3PE/boqNIJ/AqM+K>): query: SELECT username 
as user, password FROM mailbox WHERE username = 'm...@uixis.com' AND active = 
'1'
Jul 12 23:49:38 n03 dovecot: auth: Debug: client passdb out: 
OK#0111#011user=m...@uixis.com#011
Jul 12 23:49:38 n03 dovecot: auth: Debug: master in: 
REQUEST#0111400766465#01131797#0111#0118232a486f12d97195f237ee1009552cb#011session_pid=31803#011request_auth_token
Jul 12 23:49:38 n03 dovecot: auth-worker(31800): Debug: 

Bug#932087: knot-host: Add to update-alternatives

[Puck Mousit]

Package: knot-host
Version: 2.7.6-2
Severity: normal

I am on Buster 10.0.

The knot-host package provides the 'host' command, or at least so
says the package's own description. However, bug #741645 for
knot-dnsutils (which was also applied to knot-host) was submitted
a couple years ago about conflicts with the 'host', 'dig' and 'nsupdate'
commands that are provided by the dnsutils and bind9-host packages.

That bug concluded with removing the conflicting commands from
the knot packages with the mention that update-alternatives seems
the better option, which I agree is a reasonable solution.  Problem
is the knot-host and knot-dnsutils packages never actually had any
update-alternatives configuration added to them.  They therefore no
longer provide the 'host', 'dig', or 'nsupdate' commands that their
package descriptions claim they do, at least not under those
specific command names.

I'm using these packages to provide those commands.  The change
didn't impact me until Debian Buster (Stretch's version didn't have
this change applied), so once I upgraded dists I noticed, otherwise
I would've commented on the earlier bug report and change
considerably sooner.

Basically, the knot-host and knot-dnsutils packages should provide
update-alternatives functionality, and that is the purpose of this bug
report, which should be applied to both packages.  Through this
method they would provide the 'host', 'dig' and 'nsupdate' commands
they previously did.  Yes I can set that up manually, but I shouldn't
have to.  These packages should have the alternatives functionality
included.

Thank you.

Bug#932086: Missing modules for laptops

[thomasw]

package: linux-image-amd64

Was looking at the config and noticed these missing. Guess this also applies to 
32 bit.
# CONFIG_SURFACE3_WMI is not set
# CONFIG_ACER_WIRELESS is not set
# CONFIG_INTEL_WMI_THUNDERBOLT is not set

Bug#932085: grub-common: Grub can't load initrd for Xen after upgrade to Buster

[Slava Kryvel]

Package: grub-common
Version: 2.02+dfsg1-20
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

After upgrade from Debian 9.9 to Debian 10 I have got unbootable system.

I'm using Xen hypervisor, which was also upgraded from 4.8 to 4.11
during OS upgrade.
UEFI is enabled.

After upgrade was finished, I was unable to boot again to Xen kernel.
But normal Debian kernel was still bootable.

I have found a workaround to fix my issue - remove option --nounzip from
initrd loading line in grub configuration file /etc/grub.d/20_linux_xen

- module2 --nounzip /boot/initrd.img-4.19.0-5-amd64
+ module2 /boot/initrd.img-4.19.0-5-amd64

I'm not sure there is issue in config, maybe I did something wrong.
So in this case please explain what is correct behavior ?

I can provide additional info about HW and installed packages if necessary.

TIA

Best regards,
Slava

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vg--hdd-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/mapper/vg--hdd-data /data ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="Debian GNU/Linux, with Xen hypervisor"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod lvm
insmod ext2
set
root='lvmid/8ri89z-G4cl-Qaz6-ro97-nM6c-4wGh-eb1moP/evRTac-oZIt-LWLM-qktE-3a50-CM8q-wclHgz'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root
--hint='lvmid/8ri89z-G4cl-Qaz6-ro97-nM6c-4wGh-eb1moP/evRTac-oZIt-LWLM-qktE-3a50-CM8q-wclHgz'
 2fc4ef36-a507-47bc-9b50-92fd3123217d
else
  search --no-floppy --fs-uuid --set=root
2fc4ef36-a507-47bc-9b50-92fd3123217d
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi

terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-2fc4ef36-a507-47bc-9b50-92fd3123217d' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod lvm
insmod ext2
set
root='lvmid/8ri89z-G4cl-Qaz6-ro97-nM6c-4wGh-eb1moP/evRTac-oZIt-LWLM-qktE-3a50-CM8q-wclHgz'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root
--hint='lvmid/8ri89z-G4cl-Qaz6-ro97-nM6c-4wGh-eb1moP/evRTac-oZIt-LWLM-qktE-3a50-CM8q-wclHgz'
 2fc4ef36-a507-47bc-9b50-92fd3123217d
else
  search --no-floppy --fs-uuid --set=root
2fc4ef36-a507-47bc-9b50-92fd3123217d
fi
echo'Loading Linux 4.19.0-5-amd64 ...'
linux   /boot/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/vg--hdd-root
ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-4.19.0-5-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-2fc4ef36-a507-47bc-9b50-92fd3123217d' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-5-amd64' --class
debian --class gnu-linux --class gnu --class os 

Bug#932084: (no subject)

[Leon Gehling]

Package: linux-image-amd64
Version: 4.19+105
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Coreboot on kgpe-d16, newsest microcode
OUTPUT kernel:

Jul 14 09:20:25 lain kernel: [  632.450689] general protection fault:  [#1] 
SMP
Jul 14 09:20:25 lain kernel: [  632.455668] Modules linked in: vhost_net vhost 
macvtap macvlan msr dm_crypt twofish_generic twofish_avx_x86_64 
twofish_x86_64_3way twofish_x86_64 twofish_common xts algif_skcipher af_alg 
dm_mod nft_chain_route_ipv4 xt_CHECKSUM nft_chain_nat_ipv4 nf_nat_ipv4 
ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_nat xt_conntrack ipt_REJECT 
nf_reject_ipv4 xt_tcpudp nft_compat tun bridge stp llc nf_tables_bridge devlink 
cpufreq_userspace cpufreq_powersave cpufreq_conservative xfs amd64_edac_mod 
edac_mce_amd edac_core snd_hda_intel kvm_amd ast snd_hda_codec ttm snd_hda_core 
kvm snd_hwdep drm_kms_helper irqbypass snd_pcm crct10dif_pclmul snd_timer 
crc32_pclmul drm snd evdev pcspkr soundcore fam15h_power k10temp 
ghash_clmulni_intel i2c_algo_bit serio_raw sp5100_tco sg shpchp button 
acpi_cpufreq nft_counter nf_conntrack_ipv6
Jul 14 09:20:25 lain kernel: [  632.529573]  nf_defrag_ipv6 nf_conntrack_ipv4 
nf_defrag_ipv4 nft_ct nf_conntrack nft_meta nft_set_hash nft_set_rbtree 
nf_tables_inet nf_tables_ipv6 nf_tables_ipv4 nf_tables nfnetlink ip_tables 
x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb mbcache raid10 raid1 raid0 
multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor 
async_tx xor raid6_pq libcrc32c crc32c_generic md_mod sd_mod ata_generic 
ohci_pci ahci libahci pata_atiixp xhci_pci ehci_pci ohci_hcd xhci_hcd libata 
ehci_hcd crc32c_intel aesni_intel aes_x86_64 glue_helper usbcore lrw 
firewire_ohci gf128mul e1000e ablk_helper cryptd firewire_core ptp psmouse 
crc_itu_t scsi_mod i2c_piix4 usb_common pps_core
Jul 14 09:20:25 lain kernel: [  632.590648] CPU: 11 PID: 1497 Comm: CPU 0/KVM 
Not tainted 4.9.0-9-amd64 #1 Debian 4.9.168-1+deb9u3
Jul 14 09:20:25 lain kernel: [  632.599753] Hardware name: ASUS 
KGPE-D16/KGPE-D16, BIOS 4.9-2456-g9fe5dde68d 07/14/2019
Jul 14 09:20:25 lain kernel: [  632.607867] task: 8b161d556080 task.stack: 
b3430481c000
Jul 14 09:20:25 lain kernel: [  632.613881] RIP: 0010:[]  
[] svm_vcpu_load+0xf9/0x130 [kvm_amd]
Jul 14 09:20:25 lain kernel: [  632.623138] RSP: 0018:b3430481fd28  EFLAGS: 
00010246
Jul 14 09:20:25 lain kernel: [  632.628576] RAX: 0001 RBX: 
0028 RCX: 0049
Jul 14 09:20:25 lain kernel: [  632.635824] RDX:  RSI: 
 RDI: c103
Jul 14 09:20:25 lain kernel: [  632.643077] RBP: 8b15f65b8040 R08: 
 R09: 0001
Jul 14 09:20:25 lain kernel: [  632.650341] R10: 8000 R11: 
0001 R12: 000b
Jul 14 09:20:25 lain kernel: [  632.657593] R13: 8b161f314940 R14: 
8b15f65b8040 R15: 
Jul 14 09:20:25 lain kernel: [  632.664874] FS:  7f7f293bc700() 
GS:8b16378c() knlGS:
Jul 14 09:20:25 lain kernel: [  632.673119] CS:  0010 DS:  ES:  CR0: 
80050033
Jul 14 09:20:25 lain kernel: [  632.678944] CR2: 7f7f2010 CR3: 
00041eb64000 CR4: 000406f0
Jul 14 09:20:25 lain kernel: [  632.686226] Stack:
Jul 14 09:20:25 lain kernel: [  632.688276]  8b15f65b8040 b3430481fd80 
000b 
Jul 14 09:20:25 lain kernel: [  632.695903]  c0935bd6 b3430481fd9c 
010a 
Jul 14 09:20:25 lain kernel: [  632.703511]  8b15f65b8040 000b 
 
Jul 14 09:20:25 lain kernel: [  632.711135] Call Trace:
Jul 14 09:20:25 lain kernel: [  632.713689]  [] ? 
kvm_arch_vcpu_load+0x46/0x290 [kvm]
Jul 14 09:20:25 lain kernel: [  632.722897]  [] ? 
vcpu_load+0x3c/0x50 [kvm]
Jul 14 09:20:25 lain kernel: [  632.731210]  [] ? 
kvm_arch_vcpu_setup+0x29/0x60 [kvm]
Jul 14 09:20:25 lain kernel: [  632.740428]  [] ? 
kvm_vm_ioctl+0x314/0x800 [kvm]
Jul 14 09:20:25 lain kernel: [  632.749151]  [] ? 
__seccomp_filter+0x74/0x270
Jul 14 09:20:25 lain kernel: [  632.757612]  [] ? 
do_vfs_ioctl+0xa2/0x620
Jul 14 09:20:25 lain kernel: [  632.765706]  [] ? 
syscall_trace_enter+0x117/0x2c0
Jul 14 09:20:25 lain kernel: [  632.774481]  [] ? 
SyS_ioctl+0x74/0x80
Jul 14 09:20:25 lain kernel: [  632.782196]  [] ? 
do_syscall_64+0x8d/0x100
Jul 14 09:20:25 lain kernel: [  632.790312]  [] ? 
entry_SYSCALL_64_after_swapgs+0x58/0xc6
Jul 14 09:20:25 lain kernel: [  632.799770] Code: c0 89 d6 48 c1 ea 20 e8 f6 df 
c5 c5 66 90 48 8b 85 40 45 00 00 49 39 45 28 74 12 49 89 45 28 31 d2 b8 01 00 
00 00 b9 49 

Bug#932082: sox: CVE-2019-13590

[Salvatore Bonaccorso]

Source: sox
Version: 14.4.2+git20190427-1
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/sox/bugs/325/

Hi,

The following vulnerability was published for sox.

CVE-2019-13590[0]:
| An issue was discovered in libsox.a in SoX 14.4.2. In sox-fmt.h
| (startread function), there is an integer overflow on the result of
| integer addition (wraparound to 0) fed into the lsx_calloc macro that
| wraps malloc. When a NULL pointer is returned, it is used without a
| prior check that it is a valid pointer, leading to a NULL pointer
| dereference on lsx_readbuf in formats_i.c.


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-13590
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13590
[1] https://sourceforge.net/p/sox/bugs/325/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932083: linux-image-amd64: KERNEL PANIC at early boot

[Leon Gehling]

Package: linux-image-amd64
Version: 4.19+105
Severity: normal

Kernel Panic at early boot.
OUTPUT:
Loading Linux 4.19.0-5-amd64 ...Loading Linux 4.19.0-5-amd64 ..
.
Loading initial ramdisk ...Loading initial ramdisk ..
.
[0.00] Linux version 4.19.0-5-amd64
(debian-ker...@lists.debian.org) (g)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=0
[0.00] random: get_random_u32 called from
bsp_init_amd+0x20b/0x2b0 with0
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
point reg'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832
bytes,.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x0010-0xb7d97fff] usable
[0.00] BIOS-e820: [mem 0xb7d98000-0xb7ff]
reserved
[0.00] BIOS-e820: [mem 0xb800-0xbfffafff] usable
[0.00] BIOS-e820: [mem 0xbfffb000-0xcfff]
reserved
[0.00] BIOS-e820: [mem 0xfcf0-0xfcf03fff]
reserved
[0.00] BIOS-e820: [mem 0xfeb0-0xfeb00fff]
reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff]
reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff]
reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff]
reserved
[0.00] BIOS-e820: [mem 0x0001-0x000437ff] usable
[0.00] BIOS-e820: [mem 0x00043800-0x00043fff]
reserved
[0.00] bootconsole [earlyser0] enabled
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.9-1859-gf3510cbe36
05/31/2019
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2500.121 MHz processor
[0.010404] AGP: No AGP bridge found
[0.013881] last_pfn = 0x438000 max_arch_pfn = 0x4
[0.021404] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC-
WT 
Memory KASLR using RDTSC...
[0.030856] last_pfn = 0xbfffb max_arch_pfn = 0x4
[0.042030] Using GB pages for direct mapping
[0.046429] RAMDISK: [mem 0x3476f000-0x363aefff]
[0.050877] ACPI: Early table checksum verification disabled
[0.056563] ACPI: RSDP 0x000F6250 24 (v02 COREv4)
[0.062225] ACPI: XSDT 0xB7D990E0 74 (v01 COREv4 COREBOOT
00)
[0.070720] ACPI: FACP 0xB7D9B9A0 F4 (v03 COREv4 COREBOOT
00)
[0.079213] ACPI: DSDT 0xB7D99280 00271A (v02 COREv4 COREBOOT
00)
[0.087704] ACPI: FACS 0xB7D99240 40
[0.092298] ACPI: FACS 0xB7D99240 40
[0.096890] ACPI: SSDT 0xB7D9BAA0 0020F2 (v02 COREv4 COREBOOT
00)
[0.105383] ACPI: MCFG 0xB7D9DBA0 3C (v01 COREv4 COREBOOT
00)
[0.113875] ACPI: APIC 0xB7D9DBE0 DE (v02 COREv4 COREBOOT
00)
[0.122369] ACPI: SRAT 0xB7D9DCC0 0001A8 (v01 COREv4 COREBOOT
00)
[0.130862] ACPI: SLIT 0xB7D9DE68 30 (v01 COREv4 COREBOOT
00)
[0.139355] ACPI: SRAT 0xB7D9DEA0 0001A8 (v01 COREv4 COREBOOT
00)
[0.147848] ACPI: SLIT 0xB7D9E048 30 (v01 COREv4 COREBOOT
00)
[0.156341] ACPI: IVRS 0xB7D9E080 BC (v01 COREv4 COREBOOT
00)
[0.164834] ACPI: HPET 0xB7D9E140 38 (v01 COREv4 COREBOOT
00)
[0.173380] SRAT: PXM 0 -> APIC 0x00 -> Node 0
[0.177747] SRAT: PXM 0 -> APIC 0x01 -> Node 0
[0.182167] SRAT: PXM 0 -> APIC 0x02 -> Node 0
[0.186586] SRAT: PXM 0 -> APIC 0x03 -> Node 0
[0.191006] SRAT: PXM 0 -> APIC 0x04 -> Node 0
[0.195426] SRAT: PXM 0 -> APIC 0x05 -> Node 0
[0.199845] SRAT: PXM 0 -> APIC 0x06 -> Node 0
[0.204264] SRAT: PXM 0 -> APIC 0x07 -> Node 0
[0.208685] SRAT: PXM 1 -> APIC 0x08 -> Node 1
[0.213104] SRAT: PXM 1 -> APIC 0x09 -> Node 1
[0.217525] SRAT: PXM 1 -> APIC 0x0a -> Node 1
[0.221944] SRAT: PXM 1 -> APIC 0x0b -> Node 1
[0.226364] SRAT: PXM 1 -> APIC 0x0c -> Node 1
[0.230784] SRAT: PXM 1 -> APIC 0x0d -> Node 1
[0.235204] SRAT: PXM 1 -> APIC 0x0e -> Node 1
[0.239624] SRAT: PXM 1 -> APIC 0x0f -> Node 1
[0.244046] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
[0.250025] ACPI: SRAT: Node 1 PXM 1 [mem 0x0010-0xbfff]
[0.256004] ACPI: SRAT: Node 1 PXM 1 [mem 0x1-0x43fff]
[0.262162] NUMA: Node 1 [mem 0x0010-0xbfff] + [mem
0x1-0x43]
[0.272647] NODE_DATA(1) 

Bug#932081: sogo: Unable to connect to a remote IMAP server.

[Koichi MATSUMOTO]

Package: sogo
Version: 4.0.7-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages sogo depends on:
ii  adduser   3.118
ii  gnustep-base-runtime  1.26.0-4
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.64.0-4
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2
ii  libgnustep-base1.26   1.26.0-4
ii  libgnutls30   3.6.7-4
ii  liblasso3 2.6.0-2+b2
ii  libmemcached111.0.18-4.2
ii  libobjc4  8.3.0-6
ii  libsbjson2.3  2.3.2-4+b1
ii  libsope1  4.0.7-1
ii  lsb-base  10.2019051400
ii  memcached 1.5.6-1.1
ii  sogo-common   4.0.7-1
ii  systemd   241-5
ii  zip   3.0-11+b1

sogo recommends no packages.

Versions of packages sogo suggests:
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- Configuration Files:
/etc/sogo/sogo.conf changed:
{
  SOGoProfileURL = 
"postgresql://sogo:password@192.168.207.11:5432/sogo/sogo_user_profile";
  OCSFolderInfoURL = 
"postgresql://sogo:password@192.168.207.11:5432/sogo/sogo_folder_info";
  OCSSessionsFolderURL = 
"postgresql://sogo:password@192.168.207.11:5432/sogo/sogo_sessions_folder";
  OCSEMailAlarmsFolderURL = 
"postgresql://sogo:password@192.168.207.11:5432/sogo/sogo_alarms_folder";
  SOGoLanguage = English;
  SOGoAppointmentSendEMailNotifications = YES;
  SOGoMailingMechanism = smtp;
  SOGoSMTPServer = 127.0.0.1;
  SOGoTimeZone = Asia/Tokyo;
  SOGoSentFolderName = Sent;
  SOGoTrashFolderName = Trash;
  SOGoDraftsFolderName = Drafts;
  SOGoIMAPServer = "imap://localhost:143/?tls=NO";
  SOGoSieveServer = "sieve://localhost:4190/?tls=NO";
  SOGoIMAPAclConformsToIMAPExt = YES;
  SOGoVacationEnabled = NO;
  SOGoForwardEnabled = NO;
  SOGoSieveScriptsEnabled = NO;
  SOGoFirstDayOfWeek = 0;
  SOGoMailMessageCheck = manually;
  SOGoMailAuxiliaryUserAccountsEnabled = YES;
  SOGoMemcachedHost = 127.0.0.1;
  SOGoUserSources =
  (
{
  type = sql;
  id = directory;
  viewURL = 
"postgresql://sogo:password@192.168.207.11:5432/sogo/sogo_users";
  userPasswordAlgorithm = plain;
  canAuthenticate = YES;
  displayName = "Default Address Book";
}
  );
}


-- no debconf information

Bug#932080: sssd fails to start: #886483 raises from the dead

[Juha Jäykkä]

Package: sssd
Version: 2.2.0-3
Severity: grave
Justification: renders package unusable

After upgrading to 2.2.0-3, sssd will not start (automatically).

There are two failure modes, both likely related to #886483 I 
reported over a year ago.

First failure mode happens if any services are listed in sssd.conf
like (any service here will cause failure)

service = pam, nss

Startig sssd with systemctl will now (correctly) start the listed
services, BUT it will also insist on trying to start the corresponding
socket listener, which times out trying to get the socket, eventually
causing systemd to kill the whole stack of processes, leaving no sssd
processes running. It is, however, possible to start sssd manually
from command line: "sssd -i" works as expected.

Second failure mode is triggered by trying the obvious: commenting out
the whole "service" line from sssd.conf. However, now sssd fails both
from command line and from systemd because

"sssd: SSSD couldn't load the configuration database [22]: Invalid argument."

There does not seem to be any way of disabling all non-socket services
but if at least one non-socket service is active, systemd will time out
trying to load the corresponding socket.

I even removed every .socket file related to sssd from my systemd but
it didn't help (yes, I did a daemon-reexec and daemon-reload).

Only fix I managed to find is a downgrade to 1.16.3-3.1.

Cheers,
Juha

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

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

Bug#932079: imagemagick: CVE-2019-13135

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.10.23+dfsg-2.1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1599

Hi,

The following vulnerability was published for imagemagick.

CVE-2019-13135[0]:
| ImageMagick before 7.0.8-50 has a "use of uninitialized value"
| vulnerability in the function ReadCUTImage in coders/cut.c.


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-13135
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13135
[1] https://github.com/ImageMagick/ImageMagick/issues/1599
[2] 
https://github.com/ImageMagick/ImageMagick6/commit/1e59b29e520d2beab73e8c78aacd5f1c0d76196d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932078: systemd: errors out starting docker: Failed to trim compat systemd cgroup [...]: Device or resource busy

[Moritz Lenz]

Package: systemd
Version: 241-5
Severity: normal

Dear Maintainer,

after an upgrade from stretch to buster, starting a systemd service
fails. It tries to start a docker container, and fails with

> > Failed to trim compat systemd cgroup
/system.slice/tau-alert.service: Device or resource busy

More information:

root@tina:~# systemctl cat tau-alert.service
# /etc/systemd/system/tau-alert.service
[Unit]
Description=tau-alert
After=docker.service
Requires=docker.service

[Service]
ExecStart=/usr/bin/systemd-docker run -p 127.0.0.1:1:1 --rm
--name %n moritzlenz/tau-alert
Restart=always
RestartSec=10s
Type=notify
NotifyAccess=all
TimeoutStartSec=120
TimeoutStopSec=15

[Install]
WantedBy=multi-user.target

root@tina:~# systemctl status tau-alert.service
● tau-alert.service - tau-alert
   Loaded: loaded (/etc/systemd/system/tau-alert.service; enabled;
vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Sun
2019-07-14 21:35:13 CEST; 3s ago
  Process: 22243 ExecStart=/usr/bin/systemd-docker run -p
127.0.0.1:1:1 --rm --name tau-alert.service moritzlenz/tau-alert
(code=exited,
 Main PID: 22243 (code=exited, status=1/FAILURE)

Jul 14 21:35:13 tina systemd[1]: tau-alert.service: Main process exited,
code=exited, status=1/FAILURE
Jul 14 21:35:13 tina systemd[1]: tau-alert.service: Failed with result
'exit-code'.
Jul 14 21:35:13 tina systemd[1]: Failed to start tau-alert.

root@tina:~# journalctl -xe|tail
-- The unit tau-alert.service has entered the 'failed' state with result
'exit-code'.
Jul 14 21:35:54 tina systemd[1]: Failed to trim compat systemd cgroup
/system.slice/tau-alert.service: Device or resource busy
Jul 14 21:35:54 tina systemd[1]: Failed to start tau-alert.
-- Subject: A start job for unit tau-alert.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit tau-alert.service has finished with a failure.
--
-- The job identifier is 14130 and the job result is failed.


I have no idea how to debug this.


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-5

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-5

-- no debconf information

Bug#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Helmut Grohne]

Hi Michael,

On Sun, Jul 14, 2019 at 09:10:45PM +0200, Michael Biebl wrote:
> can you have a look at this?
> I'd rather not ship this as a downstream patch.

I tried to write the patch in an upstreamable way. I think that it
should help other cross distributions as well. For instance, yocto
carries
http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/rsyslog/rsyslog/use-pkgconfig-to-check-libgcrypt.patch?h=master
for avoiding libgcrypt-config. This patch could also be upstreamed by
trying pkg-config before libgcrypt-config. ptxdist simply disabled mysql
integration.

> @Helmut: Is that mysqlclient.pc file provided via a Debian specific patch?

Prior to the mariadb fork, the standard mysql client library provided
this .pc file. As far as I understand, it is now provided by mariadb as
a compatibility symlink much in the same way as it provides mysql_config
as a compatibility symlink. I think it is pretty safe to assume its
presence, but we can extend the patch to explicitly check for mariadb.pc
if that is preferred. I don't expect mysqlclient.pc (or mysql_config) to
go away anytime soon due to its widespread usage.

Helmut

Bug#928631:

[Hillel Lubman]

Hi.

20190502-1 is already outdated, since amdgpu firmware had some updates upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdgpu

Does this problem still occur if you use latest upstream firmware?

By the way, it works well for me (Ryzen 7 2700X / Vega 56), but I'm running 
kernel 5.2.1
in Debian testing.

Best regards,
Hillel Lubman.

Bug#532815: latex-beamer: Please include the "beamerthemeprogressbar"

[Hilmar Preuße]

On 12.06.09 00:20, Alexander Reichle-Schmehl wrote:

Hi Alexander,

> There's a nice theme for Latex beamer.  Main advantage of that theme is, that
> it has a progress bar showing how far your progressed in your talk.
> 
> It's available from
> http://www.cert.fr/dcsd/THESES/sbouveret/francais/LaTeX.html and licensend
> under the terms of the GPL-2.  I think it would be worth to be added in 
> Debian,
> but don't think it warrants a package for itself, since it's archive is just
> 5kb.  So, maybe you could add it to the latex-beamer main package?
> 
The old URL is dead, I guess it is now [1]. I didn't find the package on
CTAN. Please tell the author he should upload to CTAN, so it will make
its way into TeX Live.

Hilmar

[1] https://github.com/cedricmauclair/beamer-progressbar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#932077: python3.8 FTCBFS: multiple reasons

[Helmut Grohne]

Source: python3.8
Version: 3.8.0~b2-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

python3.8 fails to cross build from source.

The initial failure comes from ./configure which insists that we have a
python3.8 (not any earlier python). A dependency on python3.8:any
 can fix that.

The next failure comes from dtrace as it fails finding sdt headers using
the build architecture compiler. For it to work, CC must be exported.
This could be considered a fault of dtrace. However, exporting CC for
the whole build fixes this aspect.

Some import tests are not conditionalized to DEB_BUILD_OPTIONS=nocheck
and fail.

Finally sysconfigdata-name.diff fails to update one cross
compilation-specific occasion in configure.ac. As a consequence, the
original name is used and the intended file is not created.

After fixing all of these, python3.8 cross builds successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru python3.8-3.8.0~b2/debian/changelog 
python3.8-3.8.0~b2/debian/changelog
--- python3.8-3.8.0~b2/debian/changelog 2019-07-11 11:55:03.0 +0200
+++ python3.8-3.8.0~b2/debian/changelog 2019-07-14 12:07:34.0 +0200
@@ -1,3 +1,14 @@
+python3.8 (3.8.0~b2-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Build-Depends, when cross compiling we need python3.8.
++ Export CC, because dtrace needs it.
++ Honour DEB_BUILD_OPTIONS=nocheck more thoroughly.
++ Fix up sysconfigdata-name.diff.
+
+ -- Helmut Grohne   Sun, 14 Jul 2019 12:07:34 +0200
+
 python3.8 (3.8.0~b2-5) unstable; urgency=high
 
   * Bump standards version.
diff --minimal -Nru python3.8-3.8.0~b2/debian/control 
python3.8-3.8.0~b2/debian/control
--- python3.8-3.8.0~b2/debian/control   2019-07-11 11:55:03.0 +0200
+++ python3.8-3.8.0~b2/debian/control   2019-07-14 12:07:34.0 +0200
@@ -14,7 +14,7 @@
   locales-all,
   libsqlite3-dev, libffi-dev (>= 3.0.5) [!or1k !avr32],
   libgpm2 [linux-any],
-  mime-support, netbase, bzip2, time, python3:any,
+  mime-support, netbase, bzip2, time, python3:any, python3.8:any ,
   net-tools, xvfb , xauth ,
   systemtap-sdt-dev
 Build-Depends-Indep: python3-sphinx, python3-docs-theme, texinfo
diff --minimal -Nru python3.8-3.8.0~b2/debian/patches/sysconfigdata-name.diff 
python3.8-3.8.0~b2/debian/patches/sysconfigdata-name.diff
--- python3.8-3.8.0~b2/debian/patches/sysconfigdata-name.diff   2019-07-11 
11:55:03.0 +0200
+++ python3.8-3.8.0~b2/debian/patches/sysconfigdata-name.diff   2019-07-14 
12:07:34.0 +0200
@@ -50,3 +50,14 @@
  multiarch=getattr(sys.implementation, '_multiarch', ''),
  ))
  _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
+--- python3.8-3.8.0~b2.orig/configure.ac
 python3.8-3.8.0~b2/configure.ac
+@@ -75,7 +75,7 @@
+   AC_MSG_ERROR([python$PACKAGE_VERSION interpreter not found])
+   fi
+ AC_MSG_RESULT($interp)
+-  PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) 
_PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f 
pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) 
'$interp
++  PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) 
_PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f 
pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MULTIARCH) '$interp
+ fi
+ elif test "$cross_compiling" = maybe; then
+ AC_MSG_ERROR([Cross compiling required --host=HOST-TUPLE and 
--build=ARCH])
diff --minimal -Nru python3.8-3.8.0~b2/debian/rules 
python3.8-3.8.0~b2/debian/rules
--- python3.8-3.8.0~b2/debian/rules 2019-07-11 11:55:03.0 +0200
+++ python3.8-3.8.0~b2/debian/rules 2019-07-14 12:07:34.0 +0200
@@ -153,6 +153,9 @@
 AR=$(DEB_HOST_GNU_TYPE)-ar
 RANLIB=$(DEB_HOST_GNU_TYPE)-ranlib
 
+# configure and dtrace consume these
+export CC CXX
+
 DPKG_CPPFLAGS= $(shell $(dpkg_buildflags) --get CPPFLAGS)
 DPKG_CFLAGS  := $(shell $(dpkg_buildflags) --get CFLAGS)
 DPKG_CFLAGS  := $(subst 
-fstack-protector-strong,-fstack-protector,$(DPKG_CFLAGS))
@@ -313,8 +316,8 @@
CONFIGURE_LDFLAGS="$(DPKG_LDFLAGS) $(LTO_CFLAGS)" \
PROFILE_TASK='$(PROFILE_TASK)' $(make_build_target)
 
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
: # check that things are correctly built
-ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
   ifneq (,$(filter $(DEB_HOST_ARCH_OS), linux))
cd $(buildd_static) && ./python -c 'from _multiprocessing import 
SemLock'
   endif
@@ -343,8 +346,10 @@
$(MAKE) $(NJOBS) -C $(buildd_debug) \
EXTRA_CFLAGS="$(DEBUG_CFLAGS)"
 
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
cd $(buildd_static) && ./python -c 'import _decimal'
cd $(buildd_debug) && ./python -c 

Bug#801084: bluez-firmware: Please include firmware for Broadcom Corp. BCM20702 Bluetooth 4.0

[Malvin Gattinger]

Hi,

after upgrading from stretch to buster with bluez-firmware 1.2-4 the
card stopped working for me, asking for brcm/BCM20702A0-0a5c-21e6.hcd.

After copying
https://github.com/winterheart/broadcom-bt-firmware/blob/master/brcm/BCM20702A1-0a5c-21e6.hcd
to /lib/firmware/brcm and shutting down it now works again.

~ $ sudo dmidecode -s bios-version; sudo dmidecode -s bios-release-date
8DET76WW (1.46 )
06/21/2018
~ $ lsusb | grep Blue
Bus 001 Device 005: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0
[ThinkPad]
~ $ uname -a
Linux hostname 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19)
x86_64 GNU/Linux

(This is a ThinkPad x220 where I replaced the bluetooth module.)

@nicoo: Do you maybe still have other firmware files lying around that
make it work?

best,
Malvin


On Wed, 2 Jan 2019 22:30:55 +0100 Nicolas Braud-Santoni
 wrote:
> Control: fixed -1 1.2-4
> Control: tag -1 + stretch
> 
> Hi,
> 
> The exact same controller works on Buster, with bluez-firmware/1.2-4,
> so I am marking it as fixed there.
> 
> 
> Best,
> 
>   nicoo

Bug#932020: cloudcompare: Don't build depend on liblas, will be removed from Debian

[Sebastiaan Couwenberg]

On 7/14/19 8:59 AM, Bas Couwenberg wrote:
> liblas will be removed from Debian, it's dead upstream, has outstanding
> security issues, and FTBFS with GDAL 3.
> 
> Please drop the build dependencies from your package as per the attached
> patch.
> 
> Those build dependencies seems to be unused any way, as cloudcompare
> does not actually link to liblas.

PDAL 1.9.1 with LASzip support has been uploaded to unstable.

You can move cloudcompare 2.10.3 to unstable too, but make sure to fix
this issue in that upload.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#932013: Red message upon boot

[Michael Biebl]

Am 14.07.19 um 08:52 schrieb 積丹尼 Dan Jacobson:
> MB> Can you attach the output of
> MB> journalctl -alb
> I sent it to your private mail.
> 

There is some other software which sends SIGHUP to rsyslog during boot
(most likely a cron job).
Looking at your journal file:
rsyslog is scheduled to be started, but not running yet, then some
cronjobs run and send SIGHUP when rsyslog is not fully up yet.

I'm afraid there is not much that the rsyslog package can do about that.

Can you please find out which packages sends HUP/SIGHUP to rsyslog?

-- 
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#932068: Fwd: Bug#932068: rsyslog FTCBFS: uses mysql_config

[Michael Biebl]

Rainer,

can you have a look at this?
I'd rather not ship this as a downstream patch.

@Helmut: Is that mysqlclient.pc file provided via a Debian specific patch?

$ apt-file search mysqlclient.pc
libmariadb-dev-compat: /usr/lib/x86_64-linux-gnu/pkgconfig/mysqlclient.pc
libmysqlclient-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/mysqlclient.pc


 Weitergeleitete Nachricht 
Betreff: Bug#932068: rsyslog FTCBFS: uses mysql_config
Weitersenden-Datum: Sun, 14 Jul 2019 16:09:14 +
Weitersenden-Von: Helmut Grohne 
Weitersenden-An: debian-bugs-dist@lists.debian.org
Weitersenden-CC: Michael Biebl 
Datum: Sun, 14 Jul 2019 17:12:48 +0200
Von: Helmut Grohne 
Antwort an: Helmut Grohne , 932...@bugs.debian.org
An: Debian Bug Tracking System 

Source: rsyslog
Version: 8.1907.0-1
Tags: patch upstream

rsyslog fails to cross build from source, because it uses mysql_config
and mysql_config is unfixably broken for cross compilation. It would be
better to use pkg-config. The attached patch makes rsyslog try
pkg-config first and fall back to mysql_config. Please consider applying
it.

Helmut

--- rsyslog-8.1907.0.orig/configure.ac
+++ rsyslog-8.1907.0/configure.ac
@@ -759,24 +759,26 @@
  esac],
 [enable_mysql=no]
 )
-if test "x$enable_mysql" = "xyes"; then
-  AC_CHECK_PROG(
-[MYSQL_CONFIG],
-[mysql_config],
-[mysql_config],
-[no],,
-  )
-  if test "x${MYSQL_CONFIG}" = "xno"; then
-AC_MSG_FAILURE([mysql_config not found - usually a package named mysql-dev, libmysql-dev or similar, is missing - install it to fix this issue])
-  fi
+AS_IF([test "x$enable_mysql" = "xyes"],[
+  PKG_CHECK_MODULES([MYSQL],[mysqlclient],,[
+AC_CHECK_PROG(
+  [MYSQL_CONFIG],
+  [mysql_config],
+  [mysql_config],
+  [no],,
+)
+AS_IF([test "x${MYSQL_CONFIG}" = "xno"],[
+  AC_MSG_FAILURE([mysql_config not found - usually a package named mysql-dev, libmysql-dev or similar, is missing - install it to fix this issue])
+])
+MYSQL_CFLAGS=`$MYSQL_CONFIG --cflags`
+MYSQL_LIBS=`$MYSQL_CONFIG --libs`
+  ])
   AC_CHECK_LIB(
 [mysqlclient],
 [mysql_init],
-[MYSQL_CFLAGS=`$MYSQL_CONFIG --cflags`
- MYSQL_LIBS=`$MYSQL_CONFIG --libs`
-],
+,
 [AC_MSG_FAILURE([MySQL library is missing])],
-[`$MYSQL_CONFIG --libs`]
+[$MYSQL_LIBS]
   )
   AC_MSG_CHECKING(if we have mysql_library_init)
   save_CFLAGS="$CFLAGS"
@@ -791,7 +793,7 @@
 [have_mysql_library_init=no])
   CFLAGS="$save_CFLAGS"
   LIBS="$save_LIBS"
-fi
+])
 AM_CONDITIONAL(ENABLE_MYSQL, test x$enable_mysql = xyes)
 if test "$have_mysql_library_init" = "yes"; then
   AC_DEFINE([HAVE_MYSQL_LIBRARY_INIT], [1], [mysql_library_init available])



signature.asc
Description: OpenPGP digital signature

Bug#932042: [pkg-wicd-maint] Bug#932042: wicd-daemon: does not automatically reconnect on network connection loss when this is enabled

[Vincent Lefevre]

On 2019-07-14 15:30:01 +0200, Axel Beckert wrote:
> > 2019/07/14 12:42:53 :: Gemini WiFi has profile
> 
> I assume "Gemini WiFi" is the essid of your described setup.

Yes.

> > 2019/07/14 12:42:53 :: Unable to autoconnect, you'll have to manually 
> > connect
> [...]
> > 2019/07/14 12:42:58 :: Gemini WiFi has profile
> > 2019/07/14 12:42:58 :: Unable to autoconnect, you'll have to manually 
> > connect
> [...]
> > 2019/07/14 12:43:03 :: Gemini WiFi has profile
> > 2019/07/14 12:43:03 :: Unable to autoconnect, you'll have to manually 
> > connect
> 
> So I suspect that finding the reason for the "Unable to autoconnect,
> you'll have to manually connect" message is what would help to solve
> this.

Obviously the log should give the reason.

> > Note: I think that wicd will automatically reconnect when the option
> > "Automatically connect to this network" for the network is on, just
> > because of that, independently from the "Automatically reconnect on
> > network connection loss" global setting. Thus make sure that this
> > option "Automatically connect to this network" for the tested network
> > is off when doing the test.
> 
> Hrm, you've got a point there, but I'm not sure if this is by design.

This is *not* by design, as clearly documented in the wicd(8) man page:
"even if that network does not have automatic connection enabled".

The man page then says: "should that fail, it will try both a wired
connection and any available wireless networks which have automatic
connection enabled.", which could explain why it works when
"Automatically connect to this network" in on for the considered
network.

> Being picky you could say that "Automatically reconnect on network
> connection loss" should only work for wifi networks where
> "Automatically connect to this network" is set, too.

But for some reason, this is not what I want (e.g. I don't want
to auto-connect to some networks after start up).

> There is also this rather old bug report at
> https://bugs.launchpad.net/wicd/+bug/480097 and
> https://bugs.debian.org/544410 which might be related. The one on
> launchpad is still open, the one in the Debian BTS has been closed,
> because two of the reporters could no more reproduce it without any
> code change.

This one could also be the bug when the GUI is open.

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

Bug#925463: pytest: Please provide a pytest binary for Python 3.x

[Joel Cross]

On Sun, 14 Jul 2019, at 12:37 PM, Robie Basak wrote:
> [I'm not the maintainer; just driving by]
> 
> On Mon, Mar 25, 2019 at 01:14:34PM +, Joel Cross wrote:
> > I noticed today that while the python3-pytest package works fine when 
> > invoked
> > as `python3 -m pytest`, it does not provide a binary, and the only binary
> > provided is as part of the `python-pytest` package which is built on Python 
> > 2.
> 
> python3-pytest provides /usr/bin/pytest-3 and /usr/bin/py.test-3, does
> it now? I've been using these for years:
> 
> https://packages.debian.org/sid/all/python3-pytest/filelist
> 
So it does! In which case, I will close this ticket.

Bug#932076: gnome-sound-recorder: Starting gnome-sound-recorder and then trying to play back a (previous) recording results in crash program.

[Jury Mazurov]

Package: gnome-sound-recorder
Version: 3.28.2-1
Severity: normal

Dear Maintainer,

The error is old. There are fixes.
https://gitlab.gnome.org/GNOME/gjs/issues/223

But the error is in a stable release. When will it get to buster?

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

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

Versions of packages gnome-sound-recorder depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gst-plugins-base-1.0  1.14.4-2
ii  gir1.2-gstreamer-1.0 1.14.4-1
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-pango-1.0 1.42.4-6
ii  gjs  1.54.3-1
ii  gstreamer1.0-plugins-base1.14.4-2
ii  gstreamer1.0-plugins-good1.14.4-1
ii  gstreamer1.0-pulseaudio  1.14.4-1

gnome-sound-recorder recommends no packages.

gnome-sound-recorder suggests no packages.

-- no debconf information

(org.gnome.SoundRecorder:6732): Gjs-WARNING **: 18:30:29.547: Some code 
accessed the property 'Application' on the module 'application'. That property 
was defined with 'let' or 'const' inside the module. This was previously 
supported, but is not correct according to the ES6 standard. Any symbols to be 
exported from a module must be defined with 'var'. The property access will 
work as previously for the time being, but please fix your code anyway.

(org.gnome.SoundRecorder:6732): Gtk-WARNING **: 18:30:29.548: Locale not 
supported by C library.
Using the fallback 'C' locale.
Gjs-Message: 18:30:29.652: JS LOG: Sound Recorder started
Gjs-Message: 18:30:29.653: JS WARNING: 
[resource:///org/gnome/SoundRecorder/js/application.js 84]: Too many arguments 
to function Gst.init: expected 1, got 2

(org.gnome.SoundRecorder:6732): Gjs-WARNING **: 18:30:29.682: Some code 
accessed the property 'MainWindow' on the module 'mainWindow'. That property 
was defined with 'let' or 'const' inside the module. This was previously 
supported, but is not correct according to the ES6 standard. Any symbols to be 
exported from a module must be defined with 'var'. The property access will 
work as previously for the time being, but please fix your code anyway.

(org.gnome.SoundRecorder:6732): Gjs-WARNING **: 18:30:29.683: Some code 
accessed the property 'AudioProfile' on the module 'audioProfile'. That 
property was defined with 'let' or 'const' inside the module. This was 
previously supported, but is not correct according to the ES6 standard. Any 
symbols to be exported from a module must be defined with 'var'. The property 
access will work as previously for the time being, but please fix your code 
anyway.

(org.gnome.SoundRecorder:6732): Gjs-WARNING **: 18:30:29.683: Some code 
accessed the property 'OffsetController' on the module 'fileUtil'. That 
property was defined with 'let' or 'const' inside the module. This was 
previously supported, but is not correct according to the ES6 standard. Any 
symbols to be exported from a module must be defined with 'var'. The property 
access will work as previously for the time being, but please fix your code 
anyway.

(org.gnome.SoundRecorder:6732): Gjs-WARNING **: 18:30:29.683: Some code 
accessed the property 'DisplayTime' on the module 'fileUtil'. That property was 
defined with 'let' or 'const' inside the module. This was previously supported, 
but is not correct according to the ES6 standard. Any symbols to be exported 
from a module must be defined with 'var'. The property access will work as 
previously for the time being, but please fix your code anyway.

(org.gnome.SoundRecorder:6732): Gjs-WARNING **: 18:30:29.684: Some code 
accessed the property 'Listview' on the module 'listview'. That property was 
defined with 'let' or 'const' inside the module. This was previously supported, 
but is not correct according to the ES6 standard. Any symbols to be exported 
from a module must be defined with 'var'. The property access will work as 
previously for the time being, but please fix your code anyway.

(org.gnome.SoundRecorder:6732): Gjs-WARNING **: 18:30:29.685: Some code 
accessed the property 'Record' on the module 'record'. That property was 
defined with 'let' or 'const' inside the module. This was previously supported, 
but is not correct according to the ES6 standard. Any symbols to be exported 
from a module must be defined with 'var'. The property access will work as 
previously for the time being, but please fix your code anyway.

(org.gnome.SoundRecorder:6732): 

Bug#932075: needs some kind of automated unpin function

[Eduard Bloch]

Package: apt-listbugs
Version: 0.1.28
Severity: wishlist

Hi,

I miss some feature which I cannot discover in the documentation. This
is: some function to run automatically, read the list of bugs that
caused package version pinning in /etc/apt/preferences.d/apt-listbugs
and then check again whether those bugs have been reported as fixed and
then clean the preferences file automatically.

Maybe something ike: apt-listbugs --auto-unpin

In case I just failed to RTFM please improve the FM to make this easier
to find.

Best regards,
Eduard.

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

Kernel: Linux 5.2.0+ (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt   1.8.2
ii  ruby  1:2.5.1
ii  ruby-debian   0.3.9+b8
ii  ruby-gettext  3.2.9-1
ii  ruby-soap4r   2.0.5-4
ii  ruby-unicode  0.4.4-2+b9
ii  ruby-xmlparser0.7.3-3+b2
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.484-2
ii  ruby2.0 [ruby-interpreter]2.0.0.484+really457-3
ii  ruby2.1 [ruby-interpreter]2.1.5-4
ii  ruby2.2 [ruby-interpreter]2.2.4-1

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2
ii  s6   2.7.2.2-3

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser] 74.0.3729.108-1
ii  elinks [www-browser]   0.13~20190125-3
ii  firefox [www-browser]  67.0.1-1
ii  firefox-esr [www-browser]  60.5.1esr-1
ii  lynx [www-browser] 2.8.9rel.1-3
ii  qupzilla [www-browser] 2.2.5~dfsg1-1
ii  reportbug  7.5.2
ii  sensible-utils 0.0.12
ii  w3m [www-browser]  0.5.3-37
ii  xdg-utils  1.1.3-1

-- no debconf information

--
Atheismus ist keine Philosophie, er ist noch nicht ein mal eine
Weltsicht. Er ist schlichtweg die Weigerung, ohne Grund das Gegenteil
des Offensichtlichen zu glauben.

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Russ Allbery]

Sean Whitton  writes:

> This is more than the minimal change required to fix this bug.  It seems
> like a good idea on a first look, but we should see if we're going to
> make any packages buggy by introducing a 'should' requirement here.

Agreed.  The minimal change is probably this:

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 81b3542..fb2b6e5 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -979,7 +979,8 @@ repository where the Debian source package is developed.
 or ``hg clone`` command. If no branch is specified, the packaging
 should be on the default branch.
 
-More than one different VCS may be specified for the same package.
+More than one ``Vcs-`` field may be specified for the same
+package, but only if the  parameters are all unique.
 
 For both fields, any URLs given should use a scheme that provides
 confidentiality (``https``, for example, rather than ``http`` or ``git``)

I think one could argue that the above change is informative, given that
Policy already says "A paragraph must not contain more than one instance
of a particular field name" in Policy 5.1.

-- 
Russ Allbery (r...@debian.org)   

Bug#932074: viking: can't zoom the map relative to the Viking zoom level, e.g. for HiDPI screens

[Vincent Lefevre]

Package: viking
Version: 1.7-1
Severity: normal

On HiDPI screens, the text on the map is hardly readable.
One can zoom the map by using the contextual menu on
Default Map → Properties → Zoom Level, but once one zooms
with Ctrl+ or Ctrl-, the zoom level of the map becomes
wrong, as this is an absolute zoom instead of relative.

Absolute zoom is probably useless. It should be changed to
relative. At least, relative zooms should be available by
an option.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (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 viking depends on:
ii  gpsbabel 1.5.4-2
ii  libatk1.0-0  2.30.0-2
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcurl3-gnutls  7.64.0-4
ii  libexpat12.2.6-2
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:9.1.0-8
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgeoclue-2-0   2.5.3-1
ii  libgexiv2-2  0.10.9-1
ii  libglib2.0-0 2.58.3-3
ii  libgps23 3.17-7
ii  libgtk2.0-0  2.24.32-3
ii  libicu63 63.2-2
ii  libmagic11:5.35-4
ii  libmapnik3.0 3.0.22+ds-2
ii  libnettle6   3.4.1-1
ii  liboauth01.0.3-3
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libsqlite3-0 3.29.0-1
ii  libstdc++6   9.1.0-8
ii  libx11-6 2:1.6.7-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages viking recommends:
ii  expect [expect-dev]  5.45.4-2

Versions of packages viking suggests:
pn  gpsd  

-- no debconf information

Bug#462389: Bug#932073: dh_installinit fails with "--name=foo option specified, but init script not found"

[Niels Thykier]

Helmut Grohne:
> Package: debhelper
> Version: 12.2
> Severity: serious
> Tags: ftbfs
> Control: affects -1 + src:openssh src:util-linux
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> debhelper 12.2 fixes #462389 and makes dh_installinit fail when the
> --name'd init script does not exist. This behaviour change makes at
> least openssh and util-linux FTBFS. These are two high popcon example
> packages. I expect more.
> 
> It is unclear to me whether it can be fixed in debhelper at all. Yet I
> am filing the bug to have something recorded. If you determine that this
> should be fixed in the individual packages, please clone and reassign.
> 
> Helmut
> 

Hi Dmitry,

This report seems to be a regression related to your patch from #462389.

Of the two issues spotted:

 * openssh: Could be fixed by having openssh pass -p openssh-server to
   dh_installinit AFAICT (not tested)

 * util-linux: It does something "funky" where I am not really sure what
   the best solution is[1]

Could you please have a look at it?  If you do not have time to look at
it in a short timeframe, then please let me know.  In that case, I will
prefer to revert the patch for now to avoid having breakage for too long.

Thanks,
~Niels

[1]:

from d/rules:
"""
# install /etc/init.d/hwclock.sh
dh_installinit --name=hwclock.sh --no-start
# install /etc/default/hwclock
dh_installinit --name=hwclock
"""

It contains the following related packaging files AFAICT:

debian/util-linux.hwclock.default
debian/util-linux.hwclock.sh.init

Source:
 * https://salsa.debian.org/debian/util-linux/blob/master/debian/rules
 * https://salsa.debian.org/debian/util-linux/tree/master/debian

Bug#884989: simple-scan: doesn't show scanned images in 3.26

[Jörg Frings-Fürst]

tags 884989 - patch + moreinfo
thanks

Hello Cyril,

I have uploaded the release 3.32.2.1-1 into sid.

Please can you test if the bug still exists in the new release?

Many thanks.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



signature.asc
Description: This is a digitally signed message part

Bug#932073: dh_installinit fails with "--name=foo option specified, but init script not found"

[Helmut Grohne]

Package: debhelper
Version: 12.2
Severity: serious
Tags: ftbfs
Control: affects -1 + src:openssh src:util-linux
User: helm...@debian.org
Usertags: rebootstrap

debhelper 12.2 fixes #462389 and makes dh_installinit fail when the
--name'd init script does not exist. This behaviour change makes at
least openssh and util-linux FTBFS. These are two high popcon example
packages. I expect more.

It is unclear to me whether it can be fixed in debhelper at all. Yet I
am filing the bug to have something recorded. If you determine that this
should be fixed in the individual packages, please clone and reassign.

Helmut

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Sean Whitton]

Hello,

On Sun 14 Jul 2019 at 09:31AM -07, Russ Allbery wrote:

> Guillem Jover  writes:
>
>>> From Debian policy 4.4.0 paragraph 5.6.26:
>>>
>>> More than one different VCS may be specified for the same package.
>
>> Right, and apparently I seconded that change, with this very confused
>> wording :/, although my reading is different: as in diffferent VCS
>> types are allowed, which would be consistent with the current behavior.
>> But even then I'm not sure what's the point alogether. At a minimum
>> this sentences needs to be clarified, or maybe just entirely dropped,
>> as it looks very confusing?
>
> Yeah, this just seems generally wrong to me.  I assume the idea was that a
> package may have mirrors of its packaging repository in multiple VCS
> systems and list all of them, but I'm dubious there's much point.  My
> leaning is to make the following change:
>
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 81b3542..d491d57 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -979,7 +979,10 @@ repository where the Debian source package is developed.
>  or ``hg clone`` command. If no branch is specified, the packaging
>  should be on the default branch.
>
> -More than one different VCS may be specified for the same package.
> +Only one ``Vcs-`` field should be given for a package.  If the
> +package is maintained in multple version control systems, the
> +maintainer should specify the one that they would prefer other people
> +to use as the basis for proposing changes to the package.

This is more than the minimal change required to fix this bug.  It seems
like a good idea on a first look, but we should see if we're going to
make any packages buggy by introducing a 'should' requirement here.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#932072: gnome-settings-daemon: please allow low battery warnings to be deactivated

[Stephen Kitt]

Package: gnome-settings-daemon
Version: 3.30.2-3
Severity: normal

Dear Maintainer,

I use Logitech Marathon mice, which work for about two years off one
set of (non-rechargeable) batteries. This means that they spend quite
a while at the 5% level, and g-s-d pops up warnings every few minutes
saying that “Wireless mouse is very low in power (5%). This device
will soon stop functioning if not charged.” This notification doesn’t
even go away on its own, it requires user action, and pops over
anything going on (including full-screen videos).

I’d rather not change batteries prematurely; would it be possible to
deactivate the warning, or at least make it go away on its own?

Thanks,

Stephen


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

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

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  3.30.2-3
ii  gsettings-desktop-schemas 3.28.1-1
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libcolord21.4.3-4
ii  libcups2  2.2.10-6
ii  libfontconfig12.13.1-2
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libgeoclue-2-02.5.2-1
ii  libgeocode-glib0  3.26.1-1
ii  libglib2.0-0  2.58.3-2
ii  libgnome-desktop-3-17 3.30.2.1-2
ii  libgtk-3-03.24.5-1
ii  libgudev-1.0-0232-2
ii  libgweather-3-15  3.28.2-2
ii  liblcms2-22.9-3
ii  libnm01.14.6-2
ii  libnotify40.7.7-4
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1
ii  libpam-systemd241-5
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libpolkit-gobject-1-0 0.105-25
ii  libpulse-mainloop-glib0   12.2-4
ii  libpulse0 12.2-4
ii  libupower-glib3   0.99.10-1
ii  libwacom2 0.32-1
ii  libwayland-client01.16.0-1
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy  2.4-2
ii  pulseaudio12.2-4

gnome-settings-daemon suggests no packages.

-- no debconf information

Bug#932012: Please upload backport for stretch

[gregor herrmann]

On Sat, 13 Jul 2019 14:48:39 -0700, Felix Lechner via pkg-perl-maintainers 
wrote:

> Future versions of Lintian will likely require version 0.20, which is
> not available in stretch. Will you please upload the backported
> package from Mentors [1] to stretch-backports?

And will lintian be backported to oldoldstable? And if yes wouldn't
this go sid -> buster -> buster-backports + maybe
strech-backports-sloppy?

Backporting the buster version of libio-async-loop-epoll-perl to
stretch-backports might work (I haven't checked dependencies etc.)
but does this really make sense?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#932071: openssh-client: [Regr. 7.9p1-10 -> 8.0p1-3] Always prompts for Yubikey (PKCS#11) PIN, even if already in agent

[Andreas Kloeckner]

Package: openssh-client
Version: 1:8.0p1-3
Severity: normal

Dear Maintainer,

I have a Yubikey ("Yubikey 5 NFC") with my (RSA-2048) SSH key on it.
This connects to OpenSSH via OpenSC, through the line

PKCS11Provider /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so

which I have in my $HOME/.ssh/config. The key is configured to require a
PIN and a button press in order to sign. In 7.9p1, I was able to add the
PIN to the SSH agent for the current session with

ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

and then, upon ssh'ing into a host, only touch the key to sign in. This
behavior no longer works in 8.0p1. Instead, I now have to enter the PIN
for every single sign-in attempt, even if adding the key to the agent
succeeds. Simply downgrading openssh-client (while leaving the same
agent running) restores the prior behavior, so a workaround exists for
now. But it would be fantastic if this (convenient) function could be
restored.

Here are logs of what occurs with ssh -v in each case:

---
8.0p1: (bad)
---
$ ssh -v marten
OpenSSH_8.0p1 Debian-3, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/andreas/.ssh/config
debug1: /home/andreas/.ssh/config line 7: Deprecated option "useroaming"
debug1: /home/andreas/.ssh/config line 173: Applying options for marten
debug1: /home/andreas/.ssh/config line 189: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to marten.tiker.net [2a01:4f8:191:73ea::2] port 22.
debug1: Connection established.
debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so: 
manufacturerID  cryptokiVersion 2.20 libraryDescription  libraryVersion 0.19
debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so slot 0: 
label  manufacturerID  model  serial 
<7ecd62c148f8bee> flags 0x40d
Enter PIN for 'SSH key': 
---
7.9p1: (good)
---
$ ssh -v marten
OpenSSH_7.9p1 Debian-10, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/andreas/.ssh/config
debug1: /home/andreas/.ssh/config line 7: Deprecated option "useroaming"
debug1: /home/andreas/.ssh/config line 173: Applying options for marten
debug1: /home/andreas/.ssh/config line 189: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to marten.tiker.net [2a01:4f8:191:73ea::2] port 22.
debug1: Connection established.
debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so: 
manufacturerID  cryptokiVersion 2.20 libraryDescription  libraryVersion 0.19
debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so slot 0: 
label  manufacturerID  model  serial 
<7ecd62c148f8bee> flags 0x40d
debug1: have 1 keys
debug1: pkcs11_provider_unref: 0x556a2fafabb0 refcount 2
debug1: identity file /home/andreas/.ssh/id_rsa type 0
debug1: identity file /home/andreas/.ssh/id_rsa-cert type -1
debug1: identity file /home/andreas/.ssh/id_dsa type -1
debug1: identity file /home/andreas/.ssh/id_dsa-cert type -1
debug1: identity file /home/andreas/.ssh/id_ecdsa type -1
debug1: identity file /home/andreas/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/andreas/.ssh/id_ed25519 type 3
debug1: identity file /home/andreas/.ssh/id_ed25519-cert type -1
debug1: identity file /home/andreas/.ssh/id_xmss type -1
debug1: identity file /home/andreas/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 
Debian-10
debug1: match: OpenSSH_7.9p1 Debian-10 pat OpenSSH* compat 0x0400
debug1: Authenticating to marten.tiker.net:22 as 'akadmin'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug0: expecting SSH2_MSG_KEX_ECDH_REPLY
[snip]
---

Thanks,
Andreas

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 

Bug#932070: xvfb leaves lock files around if killed too early

[Tobias Gruetzmacher]

Package: xvfb
Version: 2:1.20.4-1
Severity: normal
Tags: patch

This is probably the corner case of a corner case, but took me some
hours to debug...

When using xvfb-run inside of docker (especially as a step in a
Dockerfile), Xvfb might still be running when xvfb-run exits (since
xvfb-run kills Xvfb, but doesn't wait until it exits). Then docker comes
around and hard-kills all remaining processes, killing Xvfb before it
had time to shut down completly. This might leave at least the .X99-lock
file in /tmp around. If you then try to use xvfb-run again as a
different user, this lock file prevents the startup of Xvfb.

Attached is a simple patch which fixed the problem for me (it just waits
for Xvfb to shut down).

Regards, Tobias

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
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=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xvfb depends on:
ii  libaudit1   1:2.8.5-1
ii  libbsd0 0.9.1-2
ii  libc6   2.28-10
ii  libgcrypt20 1.8.4-5
ii  libgl1  1.1.0-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 2.9-2
ii  libsystemd0 241-6
ii  libunwind8  1.2.1-9
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.4-1

Versions of packages xvfb recommends:
ii  xauth  1:1.0.10-1

xvfb suggests no packages.

-- no debconf information
diff --git a/debian/local/xvfb-run b/debian/local/xvfb-run
index af565c495..955760630 100644
--- a/debian/local/xvfb-run
+++ b/debian/local/xvfb-run
@@ -89,6 +89,7 @@ clean_up() {
 fi
 if [ -n "$XVFBPID" ]; then
 kill "$XVFBPID" >>"$ERRORFILE" 2>&1
+wait "$XVFBPID" >>"$ERRORFILE" 2>&1
 fi
 }
 

Bug#931975: dpkg-checkbuilddeps don't allow multiple Vcs-Git statements

[Russ Allbery]

Guillem Jover  writes:

>> From Debian policy 4.4.0 paragraph 5.6.26:
>> 
>> More than one different VCS may be specified for the same package.

> Right, and apparently I seconded that change, with this very confused
> wording :/, although my reading is different: as in diffferent VCS
> types are allowed, which would be consistent with the current behavior.
> But even then I'm not sure what's the point alogether. At a minimum
> this sentences needs to be clarified, or maybe just entirely dropped,
> as it looks very confusing?

Yeah, this just seems generally wrong to me.  I assume the idea was that a
package may have mirrors of its packaging repository in multiple VCS
systems and list all of them, but I'm dubious there's much point.  My
leaning is to make the following change:

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 81b3542..d491d57 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -979,7 +979,10 @@ repository where the Debian source package is developed.
 or ``hg clone`` command. If no branch is specified, the packaging
 should be on the default branch.
 
-More than one different VCS may be specified for the same package.
+Only one ``Vcs-`` field should be given for a package.  If the
+package is maintained in multple version control systems, the
+maintainer should specify the one that they would prefer other people
+to use as the basis for proposing changes to the package.
 
 For both fields, any URLs given should use a scheme that provides
 confidentiality (``https``, for example, rather than ``http`` or ``git``)

Before we make that change it would be great if someone could check how
many packages we would make buggy.  (I'm sure there's some good way to do
this with standard tools, but I don't know off-hand how to do it.)

-- 
Russ Allbery (r...@debian.org)   

Bug#932065: sosi2osm FTCBFS: upstream Makefile hard codes build architecture pkg-config

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Helmut,

On 7/14/19 11:56 AM, Helmut Grohne wrote:
> sosi2osm fails to cross build from source, because the upstream Makefile
> hard codes the build architecture pkg-config. The attached patch makes
> it substitutable and sosi2osm becomes cross buildable. Please consider
> applying it.

Thanks for the patch, I've added it in git and it will be included in
the next upload.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#932069: buster-pu: calamares-settings-debian 10.0.20-1+deb10u1

[Jonathan Carter]

Package: release.debian.org
Severity: normal

Below is a debfiff for CVE-2019-13179, as discussed with the
release team over e-mail:

This adds a snipet so that the initramfs will be created with safer
permissions when using an encrypted / on a full-disk encrypted system.

"""
diff -Nru calamares-settings-debian-10.0.20/debian/changelog 
calamares-settings-debian-10.0.20/debian/changelog
--- calamares-settings-debian-10.0.20/debian/changelog  2019-04-18 
10:18:37.0 +0200
+++ calamares-settings-debian-10.0.20/debian/changelog  2019-07-03 
15:05:47.0 +0200
@@ -1,3 +1,11 @@
+calamares-settings-debian (10.0.20-1+deb10u1) buster-security; urgency=medium
+
+  * New upstream release
+-  Fixes permissions for initramfs image when full-desk encryption
+   is enabled. (CVE-2019-13179) (Closes: #931373)
+
+ -- Jonathan Carter   Wed, 03 Jul 2019 13:05:47 +
+
 calamares-settings-debian (10.0.20-1) unstable; urgency=medium

 * New upstream release
 diff -Nru 
calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions 
calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions
 --- 
calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions 
1970-01-01 02:00:00.0 +0200
 +++ 
calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions 
2019-07-03 15:05:47.0 +0200
 @@ -0,0 +1,26 @@
 +Description: fix umask for initramfs permissions
 + By default, initramfs is world-readable. This configures a snippet
 + to ensure that the initramfs that will be generated is only accessable
 + by root.
 +Author: Jonathan Carter 
 +Bug-Debian: https://bugs.debian.org/931373
 +Bug: https://github.com/calamares/calamares/issues/1191
 +Last-Update: 2019-07-08
 +
 +--- calamares-settings-debian-10.0.20.orig/scripts/bootloader-config
  calamares-settings-debian-10.0.20/scripts/bootloader-config
 +@@ -2,6 +2,14 @@
 +
 + CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e 
"s#/proc##g")
 +
 ++# Set secure permissions for the initramfs if we're configuring
 ++# full-disk-encryption. The initramfs is re-generated later in the
 ++# installation process so we only set the permissions snippet without
 ++# regenerating the initramfs right now:
 ++if [ "$(mount | grep $CHROOT" " | cut -c -16)" = "/dev/mapper/luks" ]; 
then
 ++echo "UMASK=0077" > 
$CHROOT/etc/initramfs-tools/conf.d/initramfs-permissions
 ++fi
 ++
 + echo "Running bootloader-config..."
 +
 + if [ -d /sys/firmware/efi/efivars ]; then
 diff -Nru calamares-settings-debian-10.0.20/debian/patches/series 
calamares-settings-debian-10.0.20/debian/patches/series
 --- calamares-settings-debian-10.0.20/debian/patches/series
1970-01-01 02:00:00.0 +0200
 +++ calamares-settings-debian-10.0.20/debian/patches/series
2019-07-03 15:05:47.0 +0200
 @@ -0,0 +1 @@
 +fix-initramfs-permissions
"""

Bug#910783: Remove doc-base recommendation

[Russ Allbery]

Sean Whitton  writes:

> Therefore I would like to propose the following change:

This looks good to me, and I agree that this thread has shown a consensus
that lack of doc-base registration should not be considered a bug, given
our belief that it is not widely used.

Seconded.

> diff --git a/policy/ch-customized-programs.rst 
> b/policy/ch-customized-programs.rst
> index 529aa66..dbba4fc 100644
> --- a/policy/ch-customized-programs.rst
> +++ b/policy/ch-customized-programs.rst
> @@ -151,9 +151,8 @@ web servers and web applications in the Debian system.
>  
> Web Applications should try to avoid storing files in the Web
> Document Root. Instead they should use the /usr/share/doc/package
> -   directory for documents and register the Web Application via the
> -   doc-base package. If access to the web document root is unavoidable
> -   then use
> +   directory for documents. If access to the web document root is
> +   unavoidable then use
>  
> ::
>  
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 6e0c020..fa1428f 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -976,11 +976,11 @@ Here is an example of a wrapper script for this purpose:
>  Registering Documents using doc-base
>  
>  
> -The doc-base package implements a flexible mechanism for handling and
> -presenting documentation. The recommended practice is for every Debian
> -package that provides online documentation (other than just manual
> -pages) to register these documents with doc-base by installing a
> -doc-base control file in ``/usr/share/doc-base/``.
> +The doc-base package implements a mechanism for handling and
> +presenting documentation. Debian packages that provides online
> +documentation (other than just manual pages) may register these
> +documents with doc-base by installing a doc-base control file in
> +``/usr/share/doc-base/``.
>  
>  Please refer to the documentation that comes with the doc-base package
>  for information and details.

-- 
Russ Allbery (r...@debian.org)   

Bug#931837: lightdm: Depends =~ s/libpam-systemd/default-logind/

[Adam Borowski]

On Thu, Jul 11, 2019 at 08:51:37PM +0200, Yves-Alexis Perez wrote:
> Is default-logind [linux-any] as well?

I don't think of any logind implementations for non-Linux, so a hard
dependency would need to be qualified, yeah.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Yo momma uses IPv4!
⢿⡄⠘⠷⠚⠋⠀ But why should you?
⠈⠳⣄ https://ipv4flagday.net/

Bug#932068: rsyslog FTCBFS: uses mysql_config

[Helmut Grohne]

Source: rsyslog
Version: 8.1907.0-1
Tags: patch upstream

rsyslog fails to cross build from source, because it uses mysql_config
and mysql_config is unfixably broken for cross compilation. It would be
better to use pkg-config. The attached patch makes rsyslog try
pkg-config first and fall back to mysql_config. Please consider applying
it.

Helmut
--- rsyslog-8.1907.0.orig/configure.ac
+++ rsyslog-8.1907.0/configure.ac
@@ -759,24 +759,26 @@
  esac],
 [enable_mysql=no]
 )
-if test "x$enable_mysql" = "xyes"; then
-  AC_CHECK_PROG(
-[MYSQL_CONFIG],
-[mysql_config],
-[mysql_config],
-[no],,
-  )
-  if test "x${MYSQL_CONFIG}" = "xno"; then
-AC_MSG_FAILURE([mysql_config not found - usually a package named mysql-dev, libmysql-dev or similar, is missing - install it to fix this issue])
-  fi
+AS_IF([test "x$enable_mysql" = "xyes"],[
+  PKG_CHECK_MODULES([MYSQL],[mysqlclient],,[
+AC_CHECK_PROG(
+  [MYSQL_CONFIG],
+  [mysql_config],
+  [mysql_config],
+  [no],,
+)
+AS_IF([test "x${MYSQL_CONFIG}" = "xno"],[
+  AC_MSG_FAILURE([mysql_config not found - usually a package named mysql-dev, libmysql-dev or similar, is missing - install it to fix this issue])
+])
+MYSQL_CFLAGS=`$MYSQL_CONFIG --cflags`
+MYSQL_LIBS=`$MYSQL_CONFIG --libs`
+  ])
   AC_CHECK_LIB(
 [mysqlclient],
 [mysql_init],
-[MYSQL_CFLAGS=`$MYSQL_CONFIG --cflags`
- MYSQL_LIBS=`$MYSQL_CONFIG --libs`
-],
+,
 [AC_MSG_FAILURE([MySQL library is missing])],
-[`$MYSQL_CONFIG --libs`]
+[$MYSQL_LIBS]
   )
   AC_MSG_CHECKING(if we have mysql_library_init)
   save_CFLAGS="$CFLAGS"
@@ -791,7 +793,7 @@
 [have_mysql_library_init=no])
   CFLAGS="$save_CFLAGS"
   LIBS="$save_LIBS"
-fi
+])
 AM_CONDITIONAL(ENABLE_MYSQL, test x$enable_mysql = xyes)
 if test "$have_mysql_library_init" = "yes"; then
   AC_DEFINE([HAVE_MYSQL_LIBRARY_INIT], [1], [mysql_library_init available])

Bug#932064: onscripter FTCBFS: uses build architecture build tools

[Helmut Grohne]

Source: onscripter
Version: 20190527-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

onscripter fails to cross build from source, because it uses build
architecture build tools. In debian/rules, pkg-config is hard coded.
Seeding pkg-config from dpkg's buildtools.mk is the common way to fix
that. Then it fails to pass cross tools to Makefile.Linux. We cannot
easily rely on dh_auto_build doing this, because it uses non standard
variables. CC usually contains the C compiler, but onscripter stores a
C++ compiler there. Thus the attached patch also constructs these values
explicitly. Please consider applying it.

Helmut
diff --minimal -Nru onscripter-20190527/debian/changelog 
onscripter-20190527/debian/changelog
--- onscripter-20190527/debian/changelog2019-07-07 05:31:57.0 
+0200
+++ onscripter-20190527/debian/changelog2019-07-14 12:00:43.0 
+0200
@@ -1,3 +1,10 @@
+onscripter (20190527-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Seed build tools from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 14 Jul 2019 12:00:43 +0200
+
 onscripter (20190527-1) unstable; urgency=low
 
   * New upstream release
diff --minimal -Nru onscripter-20190527/debian/control 
onscripter-20190527/debian/control
--- onscripter-20190527/debian/control  2018-12-05 05:58:52.0 +0100
+++ onscripter-20190527/debian/control  2019-07-14 12:00:22.0 +0200
@@ -2,7 +2,7 @@
 Section: games
 Priority: optional
 Maintainer: Ying-Chun Liu (PaulLiu) 
-Build-Depends: debhelper (>= 11), docbook-to-man,
+Build-Depends: debhelper (>= 11), docbook-to-man, dpkg-dev (>= 1.19.0),
libsdl1.2-dev, libavifile-0.7-dev,
libsdl-image1.2-dev, libsdl-mixer1.2-dev, libsdl-ttf2.0-dev,
libbz2-dev, libjpeg-dev, liblua5.2-dev, libfontconfig1-dev,
diff --minimal -Nru onscripter-20190527/debian/rules 
onscripter-20190527/debian/rules
--- onscripter-20190527/debian/rules2018-11-06 08:09:31.0 +0100
+++ onscripter-20190527/debian/rules2019-07-14 12:00:43.0 +0200
@@ -9,6 +9,8 @@
 DEB_FONTCONFIG_FLAG := $(findstring ok installed,$(shell dpkg-query -W 
-f='$${Status}' libfontconfig1-dev))
 DEB_LUA_FLAG:= $(findstring ok installed,$(shell dpkg-query -W 
-f='$${Status}' liblua5.2-dev))
 
+include /usr/share/dpkg/buildtools.mk
+
 M_CFLAGS = $(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags --get 
CPPFLAGS) -Wall
 M_LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
 
@@ -26,8 +28,8 @@
 else
 # Use mad if it is installed
 ifneq (,$(DEB_MP3MAD_FLAG))
-CONFINCS += `pkg-config --cflags mad`
-CONFLIBS += `pkg-config --libs mad`
+CONFINCS += `$(PKG_CONFIG) --cflags mad`
+CONFLIBS += `$(PKG_CONFIG) --libs mad`
 CONFDEFS += -DMP3_MAD
 endif
 endif
@@ -47,23 +49,23 @@
 CONFDEFS += -DUSE_OGG_VORBIS -DINTEGER_OGG_VORBIS
 else
 ifneq (,$(DEB_VORBIS_FLAG))
-CONFINCS += `pkg-config --cflags vorbisfile`
-CONFLIBS += `pkg-config --libs vorbisfile`
+CONFINCS += `$(PKG_CONFIG) --cflags vorbisfile`
+CONFLIBS += `$(PKG_CONFIG) --libs vorbisfile`
 CONFDEFS += -DUSE_OGG_VORBIS
 endif
 endif
 
 # Use fontconfig if it is installed
 ifneq (,$(DEB_FONTCONFIG_FLAG))
-CONFINCS += `pkg-config --cflags fontconfig`
-CONFLIBS += `pkg-config --libs fontconfig`
+CONFINCS += `$(PKG_CONFIG) --cflags fontconfig`
+CONFLIBS += `$(PKG_CONFIG) --libs fontconfig`
 CONFDEFS += -DUSE_FONTCONFIG
 endif
 
 # Use lua if it is installed
 ifneq (,$(DEB_LUA_FLAG))
-CONFINCS += `pkg-config --cflags lua5.2`
-CONFLIBS += `pkg-config --libs lua5.2`
+CONFINCS += `$(PKG_CONFIG) --cflags lua5.2`
+CONFLIBS += `$(PKG_CONFIG) --libs lua5.2`
 CONFDEFS += -DUSE_LUA
 CONFEXT_OBJS += LUAHandler.o
 endif
@@ -87,6 +89,7 @@
$(MAKE) DEFS="$(CONFDEFS) -DENABLE_1BYTE_CHAR -DFORCE_1BYTE_CHAR" \
INCS="$(CONFINCS)" LIBS="$(CONFLIBS)" \
TARGET="$(CONFTARGET)" EXT_OBJS="$(CONFEXT_OBJS)" \
+   'CC=$(CXX)' 'LD=$(CXX) -o' \
-f Makefile.Linux
if test ! -e onscripter-1byte; then \
cp -f onscripter onscripter-1byte; \
@@ -94,6 +97,7 @@
$(MAKE) -f Makefile.Linux clean
$(MAKE) DEFS="$(CONFDEFS)" INCS="$(CONFINCS)" LIBS="$(CONFLIBS)" \
TARGET="$(CONFTARGET)" EXT_OBJS="$(CONFEXT_OBJS)" \
+   'CC=$(CXX)' 'LD=$(CXX) -o' \
-f Makefile.Linux
 
 override_dh_auto_clean:

Bug#932066: rna-star FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: rna-star
Version: 2.7.1a+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

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

Helmut
diff --minimal -Nru rna-star-2.7.1a+dfsg/debian/changelog 
rna-star-2.7.1a+dfsg/debian/changelog
--- rna-star-2.7.1a+dfsg/debian/changelog   2019-07-08 17:28:41.0 
+0200
+++ rna-star-2.7.1a+dfsg/debian/changelog   2019-07-14 11:58:07.0 
+0200
@@ -1,3 +1,10 @@
+rna-star (2.7.1a+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 14 Jul 2019 11:58:07 +0200
+
 rna-star (2.7.1a+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru rna-star-2.7.1a+dfsg/debian/rules 
rna-star-2.7.1a+dfsg/debian/rules
--- rna-star-2.7.1a+dfsg/debian/rules   2019-07-08 17:28:19.0 +0200
+++ rna-star-2.7.1a+dfsg/debian/rules   2019-07-14 11:58:02.0 +0200
@@ -15,7 +15,7 @@
dh $@
 
 override_dh_auto_build:
-   cd source && $(MAKE) CCFLAGS_common_add="-flto $(CCFLAGS)" 
CCFLAGS="$(CCFLAGS)" LDFLAGS_add="$(LDFLAGS)"
+   dh_auto_build --sourcedirectory=source -- CCFLAGS_common_add="-flto 
$(CCFLAGS)" CCFLAGS="$(CCFLAGS)" LDFLAGS_add="$(LDFLAGS)"
 
 override_dh_auto_clean:
cd source && $(MAKE) clean

Bug#932067: libinih cross builds broken packages

[Helmut Grohne]

Source: libinih
Version: 44-1
Tags: patch

libinih successfully cross builds broken packages, because the upstream
Makefile uses the build architecture compiler to determine the multiarch
directory. It needs to use the host architecture compiler there. The
attached patch makes that work. Please consider applying it.

Helmut
diff --minimal -Nru libinih-44/debian/changelog libinih-44/debian/changelog
--- libinih-44/debian/changelog 2019-07-08 10:37:32.0 +0200
+++ libinih-44/debian/changelog 2019-07-14 17:13:57.0 +0200
@@ -1,3 +1,10 @@
+libinih (44-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build/host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 14 Jul 2019 17:13:57 +0200
+
 libinih (44-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru libinih-44/debian/patches/cross.patch 
libinih-44/debian/patches/cross.patch
--- libinih-44/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ libinih-44/debian/patches/cross.patch   2019-07-14 17:13:33.0 
+0200
@@ -0,0 +1,10 @@
+--- libinih-44.orig/Makefile
 libinih-44/Makefile
+@@ -1,6 +1,6 @@
+ PROJECT = libinih
+ 
+-MULTIARCH := $(shell gcc --print-multiarch)
++MULTIARCH := $(shell $(CC) --print-multiarch)
+ 
+ INCLUDEDIR := $(DESTDIR)/usr/include
+ LIBDIR := $(DESTDIR)/usr/lib/$(MULTIARCH)
diff --minimal -Nru libinih-44/debian/patches/series 
libinih-44/debian/patches/series
--- libinih-44/debian/patches/series2019-07-08 10:37:32.0 +0200
+++ libinih-44/debian/patches/series2019-07-14 17:13:23.0 +0200
@@ -1,2 +1,3 @@
 Makefile.patch
 runtime-options.patch
+cross.patch
diff --minimal -Nru libinih-44/debian/rules libinih-44/debian/rules
--- libinih-44/debian/rules 2019-07-08 10:37:32.0 +0200
+++ libinih-44/debian/rules 2019-07-14 17:13:57.0 +0200
@@ -8,9 +8,13 @@
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 include /usr/share/dpkg/pkg-info.mk
+-include /usr/share/dpkg/buildtools.mk
 
 export VERSION := $(DEB_VERSION_UPSTREAM)
 
 
 %:
dh $@
+
+override_dh_auto_install:
+   dh_auto_install -- CC=$(CC)

Bug#932065: sosi2osm FTCBFS: upstream Makefile hard codes build architecture pkg-config

[Helmut Grohne]

Source: sosi2osm
Version: 1.0.0-6
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sosi2osm fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. The attached patch makes
it substitutable and sosi2osm becomes cross buildable. Please consider
applying it.

Helmut
--- sosi2osm-1.0.0.orig/Makefile
+++ sosi2osm-1.0.0/Makefile
@@ -1,8 +1,9 @@
 PROGNAME=sosi2osm
 OBJFILES=sosi2osm.o sosi.o tag.o node.o
 
-CPPFLAGS := $(CPPFLAGS) `pkg-config --cflags lua5.1-c++ fyba` -DLINUX -DUNIX -g
-LDFLAGS := $(LDFLAGS) -lproj `pkg-config --libs lua5.1-c++ fyba`
+PKG_CONFIG ?= pkg-config
+CPPFLAGS := $(CPPFLAGS) `$(PKG_CONFIG) --cflags lua5.1-c++ fyba` -DLINUX -DUNIX -g
+LDFLAGS := $(LDFLAGS) -lproj `$(PKG_CONFIG) --libs lua5.1-c++ fyba`
 
 all: $(PROGNAME)
 

Bug#932063: x11: Dual monitors, identicam units, Expanding window to full size does not expand to both screens.

[Duncan]

Package: x11-Common
Version: 1:7.7+19
Severity: important
File: x11

Dear Maintainer,

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

   * What led up to the situation?
Install 2 identica screen on Linux system
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Resized opr windo to full screen
   * What was the outcome of this action
Window expanded on single monitor?
   * What outcome did you expect instead?
Window to expand to occupy both Monitors.

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


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.57-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages x11-Common depends on:
ii  lsb-base  10.2019051400+rpi1

x11-Common recommends no packages.

x11-Common suggests no packages.

-- no debconf information

Bug#932062: remmina: Raspberry Pi, Two Monitors, icons on LHS of Windows window to move right off in the RDP window

[Duncan]

Package: remmina
Version: 1.3.3+dfsg-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Dual Monitors of identical resolution on Raspberry Pi,
stretching windw from LHS montion to the right, 
caused the vertical set of icons on the LHS of the rdp window 
to move right off the RDP border.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
Less screen are to use, RDP wind icone in middle of LHS screen.
   * What outcome did you expect instead?
Vertical set of Incons to remain on LHS of RDP window

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


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.57-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  libatk1.0-0   2.30.0-2
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavahi-ui-gtk3-00.7-4+b1
ii  libayatana-appindicator3-10.5.3-4
ii  libc6 2.28-10+rpi1
ii  libcairo2 1.16.0-4+rpt1
ii  libgcrypt20   1.8.4-5
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2
ii  libgtk-3-03.24.5-1+rpt2
ii  libice6   2:1.0.9-2
ii  libjson-glib-1.0-01.4.4-2
ii  libpango-1.0-01.42.4-6
ii  libsm62:1.2.3-1
ii  libsoup2.4-1  2.64.2-2
ii  libssh-4  0.8.7-1
ii  libssl1.1 1.1.1c-1
ii  libvte-2.91-0 0.54.2-2
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  remmina-common1.3.3+dfsg-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.3.3+dfsg-2
ii  remmina-plugin-secret  1.3.3+dfsg-2
ii  remmina-plugin-vnc 1.3.3+dfsg-2

Versions of packages remmina suggests:
pn  remmina-plugin-exec   
pn  remmina-plugin-nx 
pn  remmina-plugin-spice  
pn  remmina-plugin-telepathy  
pn  remmina-plugin-xdmcp  

-- no debconf information

Bug#932061: wavpack: CVE-2019-1010319

[Salvatore Bonaccorso]

Source: wavpack
Version: 5.1.0-6
Severity: important
Tags: security upstream
Forwarded: https://github.com/dbry/WavPack/issues/68

Hi,

The following vulnerability was published for wavpack.

CVE-2019-1010319[0]:
| WavPack 5.1.0 and earlier is affected by: CWE-457: Use of
| Uninitialized Variable. The impact is: Unexpected control flow,
| crashes, and segfaults. The component is: ParseWave64HeaderConfig
| (wave64.c:211). The attack vector is: Maliciously crafted .wav file.
| The fixed version is: After commit https://github.com/dbry/WavPack/com
| mit/33a0025d1d63ccd05d9dbaa6923d52b1446a62fe.


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-1010319
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010319
[1] https://github.com/dbry/WavPack/issues/68
[2] 
https://github.com/dbry/WavPack/commit/33a0025d1d63ccd05d9dbaa6923d52b1446a62fe

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932060: wavpack: CVE-2019-1010317

[Salvatore Bonaccorso]

Source: wavpack
Version: 5.1.0-6
Severity: important
Tags: security upstream
Forwarded: https://github.com/dbry/WavPack/issues/66

Hi,

The following vulnerability was published for wavpack.

CVE-2019-1010317[0]:
| WavPack 5.1.0 and earlier is affected by: CWE-457: Use of
| Uninitialized Variable. The impact is: Unexpected control flow,
| crashes, and segfaults. The component is: ParseCaffHeaderConfig
| (caff.c:486). The attack vector is: Maliciously crafted .wav file. The
| fixed version is: After commit https://github.com/dbry/WavPack/commit/
| f68a9555b548306c5b1ee45199ccdc4a16a6101b.


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-1010317
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010317
[1] https://github.com/dbry/WavPack/issues/66
[2] 
https://github.com/dbry/WavPack/commit/f68a9555b548306c5b1ee45199ccdc4a16a6101b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#932046: simple-scan: Ctrl+1 does nothing but is documented to scan a page

[Jörg Frings-Fürst]

forwarded 932046  https://gitlab.gnome.org/GNOME/simple-scan/issues/115
thanks

Hello Bruno,

bug forwarded to upstream.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



signature.asc
Description: This is a digitally signed message part

Bug#849895: Fixed

[Anton Gladky]

fixed 849895 0~20140302.gitc8919a0+dfsg-3
thanks

Bug#831973: smartd sometimes starts before USB drives are detected by the system during boot

[Muhammad Fahd Waseem]

Hello,

I'm unable to solve this using the method mentioned by Darkbox - probably
because I'm doing something wrong while putting the unit names at

[Unit]
Requires=XX.mount
After=XX.mount

My unit name is really long winded, like below, and doesn't seem like that
should go there:

sys-devices-platform-soc-3f98.usb-usb1-1\x2d1-1\x2d1.1-1\x2d1.1.2-1\x2d1.1.2:1.0-host0-target0:0:0-0:0:0:0-block-sda.device

Any suggestions?

Thanks!

Regards, Muhammad Fahd Waseem
http://www.muhammadfahd.com/