Bug#805711: Info received (light-locker: no login possible after suspend)

[Lin Zhihang]

Yes. I can still reproduce the problem, too.

By the way, I can type my password directly and press enter to unlock 
the session while the screen is black.


On Tue, 4 Jun 2019 03:12:57 +0200 (CEST) Matthew Crews 
 wrote:

 > This issue is still present in Buster. The workaround (switch to VT8
 > then back to VT7) also still works in Buster.
 >

Bug#926924: Bug still applies to 3.1+dfsg-8~deb10u1

[Michael Kesper]

Dear Michael,

On 08.08.19 16:55, Michael Tokarev wrote:
> Control: severity -1 minor
> Control: tag -1 + wontfix
> 
> 30.07.2019 13:19, Michael Kesper wrote:
>> $ kvm -drive if=none,cache=none,media=cdrom,id=drive_cd,readonly=on
>> qemu-system-x86_64: -drive 
>> if=none,cache=none,media=cdrom,id=drive_cd,readonly=on: Must specify either 
>> driver or file
> 
> It makes little sense to specify cache mode for a read-only CD-rom device.
> In order to trigger this using virt-manager, one has to explicitly specify
> cache mode (by default virt-manager does not specify one).

It is an issue triggered by cloudstack via libvirt.

> So I'm lowering this bug severity to minor.
> 
> Note that upstream did not "fix" this "issue" at all even for 4.1 version
> (4.1 emits the same error message), for upstream it is not an issue per
> se.
> 
> (And note that the hack applied by redhat is not "upstream change").

So, this needs to be resolved on the cloudstack / libvirt side, I guess.

Thanks for your attention!
Michael



signature.asc
Description: OpenPGP digital signature

Bug#934282: zfs-dkms: fails to install for 5.2.0-2-amd64 due to GPL-only symbol 'alternatives_patched'

[Harry Sintonen]

Package: zfs-dkms
Version: 0.8.1-3
Severity: important
Tags: patch

Dear Maintainer,

The module fails to build against 5.2.0-2-amd64 due to use of GPL-only symbol:
"
  Building modules, stage 2.
  MODPOST 8 modules
FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 
'alternatives_patched'
make[6]: *** 
[/usr/src/linux-headers-5.2.0-2-common/scripts/Makefile.modpost:91: __modpost] 
Error 1
"

Apparently this is due to the kernel being built with CONFIG_X86_DEBUG_FPU=Y 
which results
in pulling the symbol. Patch fixing this issue is here:

https://github.com/zfsonlinux/zfs/commit/095b5412b31c07cad5cec74a4eb5ace011c92b27


-- System Information:
Debian Release: bullseye/sid
  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)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  dkms   2.7.1-2
ii  file   1:5.37-5
ii  libc6-dev [libc-dev]   2.28-10
ii  libpython3-stdlib  3.7.3-1
ii  lsb-release10.2019051400
ii  perl   5.28.1-6
ii  python3-distutils  3.7.4-3

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.2.7-1
ii  zfs-zed 0.8.1-3
ii  zfsutils-linux  0.8.1-3

zfs-dkms suggests no packages.

-- debconf information:
  zfs-dkms/stop-build-for-32bit-kernel: true
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-unknown-kernel: true

Bug#934217: Acknowledgement (libselinux1: libselinux1:i386 : breaks: libselinux1 (!= 2.9-2) but installed 2.9-2+b2)

[Егор Соколенко]

Resolved now, thank you.

Bug#933827: "dgit fetch" fails with "cannot remove directory for ..."

[Stéphane Glondu]

Control: tags -1 + patch

Le 09/08/2019 à 07:12, Stéphane Glondu a écrit :
> Adding "close F;" to line 4023 of /usr/bin/dgit (before chomp) seems to
> fix the bug.

Patch attached.

-- 
Stéphane
>From 676ce92febebbae76a8860e7299c9b157dbb73d2 Mon Sep 17 00:00:00 2001
From: Stephane Glondu 
Date: Fri, 9 Aug 2019 07:16:46 +0200
Subject: [PATCH] Fix a leaking open file (Closes: #933827)

The file debian/source/format was open by "dgit fetch" but never
closed, causing failure to remove the extracted tree on NFS.
---
 dgit | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dgit b/dgit
index 6401524e..b2147244 100755
--- a/dgit
+++ b/dgit
@@ -4020,6 +4020,7 @@ sub get_source_format () {
 }
 $_ = ;
 F->error and confess "$!";
+close F;
 chomp;
 return ($_, \%options);
 }
-- 
2.20.1

Bug#934281: r-bioc-metagenomeseq: Should not migrate to testing

[Andreas Tille]

Package: r-bioc-metagenomeseq
Severity: grave
Tags: upstream
Justification: renders package unusable

Hi,

we can not upgrade r-bioc-metagenomeseq to the new upstream version
since it got a new dependency from a non-free package.  We are sorting
this out with upstream but this might take time.  All other r-bioc
packages are depending from the virtual package r-api-bioc-3.9 while
r-bioc-metagenomeseq 1.24.1-1 depends r-api-bioc-3.8.  So there is a
conflicting dependency.

Kind regards

  Andreas.

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

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

Versions of packages r-bioc-metagenomeseq depends on:
pn  r-api-bioc-3.8   
ii  r-base-core [r-api-3.5]  3.5.2-1
pn  r-bioc-biobase   
pn  r-bioc-limma 
pn  r-cran-foreach   
pn  r-cran-glmnet
pn  r-cran-gplots
ii  r-cran-matrix1.2-15-1
ii  r-cran-matrixstats   0.54.0-1
ii  r-cran-rcolorbrewer  1.1-2-2

Versions of packages r-bioc-metagenomeseq recommends:
ii  r-cran-testthat  2.0.1-1

Versions of packages r-bioc-metagenomeseq suggests:
pn  r-bioc-annotate  
pn  r-bioc-biocgenerics  
pn  r-bioc-biomformat
pn  r-cran-gss   
ii  r-cran-knitr 1.21+dfsg-2
pn  r-cran-vegan 

Bug#934280: empty list returned by package_facts

[Marc Haber]

Package: ansible
Version: 2.8.3+dfsg-1
Severity: normal

Hi,

see what happens with ansible 2.8:

[125/5639]mh@drop:~/git/zgdebansible (master *$% u+185) (crm) $ ansible -m 
package_facts emptystretch82 
BECOME password: 
emptystretch82 | SUCCESS => {
"ansible_facts": {
"packages": {}
},
"changed": false
}
[126/5640]mh@drop:~/git/zgdebansible (master *$% u+185) (crm) $ 

after going back to ansible 2.7 everything is fine again:

[145/5659]mh@drop:~/git/zgdebansible (master *$% u+185) (crm) $ ansible -m 
package_facts emptystretch82  | head -n 20
SUDO password: 
emptystretch82 | SUCCESS => {
"ansible_facts": {
"packages": {
"adduser": [
{
"arch": "all",
"name": "adduser",
"source": "apt",
"version": "3.115"
}
],
"aide": [
{
"arch": "amd64",
"name": "aide",
"source": "apt",
"version": "0.16.2-0.1~zg90+2"
}
],
"aide-common": [
Exception ignored in: <_io.TextIOWrapper name='' mode='w' 
encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe
[146/5660]mh@drop:~/git/zgdebansible (master *$% u+185) (crm) $ 

Calling with ANSIBLE_KEEP_REMOTE_FILES=yes and using the python debugger
on the remote host revealed that the 2.8 code tries to return data from
some cache without even trying to build it. The upstream code on
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/packaging/os/package_facts.py
looks similar but not identical to what gets uploaded to the remote
host.

I'm back on 2.7 for the time being.

Greetings
Marc

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

Kernel: Linux 5.2.7-zgws1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ansible depends on:
ii  openssh-client1:8.0p1-4
ii  python3   3.7.3-1
ii  python3-crypto2.6.1-10
ii  python3-cryptography  2.6.1-3
ii  python3-httplib2  0.11.3-2
ii  python3-jinja22.10.1-1
ii  python3-netaddr   0.7.19-1
ii  python3-paramiko  2.4.2-0.1
ii  python3-yaml  5.1.2-1

Versions of packages ansible recommends:
ii  python3-jmespath   0.9.4-1
ii  python3-kerberos   1.1.14-2
ii  python3-libcloud   2.4.0-2
ii  python3-selinux2.9-2+b2
ii  python3-winrm  0.3.0-2
ii  python3-xmltodict  0.11.0-2

Versions of packages ansible suggests:
ii  cowsay   3.03+dfsg2-6
pn  sshpass  

-- no debconf information

Bug#933827: "dgit fetch" fails with "cannot remove directory for ..."

[Stéphane Glondu]

Le 09/08/2019 à 06:57, Stéphane Glondu a écrit :
>> Is there an easy way for you to tell me what the name or contents of
>> the errant file is ?
> 
> The file must be debian/source/format, as it is the only file in that
> directory.
> 
>> Eg, maybe adding END { sleep 100; } somewhere
> 
> I added "sleep 100;" before the offending call to rmtree (line 2721).
> Then "ls -l /proc/$PID_OF_DGIT/fd" reveals that the debian/source/format
> is indeed open (with stdio, /dev/null and /usr/share/perl5/JSON.pm).

Adding "close F;" to line 4023 of /usr/bin/dgit (before chomp) seems to
fix the bug.


Cheers,

-- 
Stéphane

Bug#933080: pekka-kana-2 FTCBFS: uses build architecture build tools

[Carlos Donizete Froes]

Hi,

Pekka-kana-2 was released in version 1.2.3 where bugs were fixed:

  * Renamed non-default CPP variable to CXX
  * Encountered a misspelling on manpage
  * Fix saves and settings path
  * Try to fix negative times on records

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#933827: "dgit fetch" fails with "cannot remove directory for ..."

[Stéphane Glondu]

Le 04/08/2019 à 16:19, Ian Jackson a écrit :
> Is there an easy way for you to tell me what the name or contents of
> the errant file is ?

The file must be debian/source/format, as it is the only file in that
directory.

> Eg, maybe adding END { sleep 100; } somewhere

I added "sleep 100;" before the offending call to rmtree (line 2721).
Then "ls -l /proc/$PID_OF_DGIT/fd" reveals that the debian/source/format
is indeed open (with stdio, /dev/null and /usr/share/perl5/JSON.pm).


Cheers,

-- 
Stéphane

Bug#934279: RFS: pekka-kana-2/1.2.3-1 -- 2D Oldschool platform game where you control a rooster

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "pekka-kana-2"

 * Package name: pekka-kana-2
   Version : 1.2.3-1
   Upstream Author : Janne Kivilahti (Piste Gamez) 
 * URL : https://pistegamez.net/game_pk2.html
 * License : BSD-2-Clause
   Section : games

  It builds those binary packages:

  pekka-kana-2 - 2D Oldschool platform game where you control a rooster
  pekka-kana-2-data - 2D Oldschool platform game where you control a rooster 
(data file)

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/pekka-kana-2

  Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pekka-kana-2/pekka-kana-2_1.2.3-1.dsc

  More information about pekka-kana-2 can be obtained from 
https://gitlab.com/coringao/pekka-kana-2.

  Changes since the last upload:

  pekka-kana-2 (1.2.3-1) unstable; urgency=medium

  * New upstream release. (Closes: #933080)
  * debian/control:
- Removed ${source:Version} from Depends.
  * debian/rules:
+ Added the DEB_BUILD_MAINT_OPTIONS variable to improve the GCC hardening.

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#933835: Info received (Bug#933835: libreoffice not start with fatal exception signal 11)

[Timur Irikovich Davletshin]

I believe this bug should be reopened. Right version of atk library is
not in the dependencies of this build. Regular installation via apt-get 
-t buster-backports install libreoffice leads to non working state.

Regards,

Timur.

P.S. Official builds work fine btw...

On Sun, 4 Aug 2019 21:41:26 +0200 Rene Engelhard 
wrote:
> Hi,
> 
> On Sun, Aug 04, 2019 at 07:44:35PM +0200, sanskryt wrote:
> > OK the problem was solved by today's upgrade.
> > In it were upgraded cpid gir1.2-atk-1.0 gpicview libarmadillo9
> > libatk1.0-0 libatk1.0-0:i386 libatk1.0-data libatk1.0-dev
libatk1.0-doc 
> > liblockfile-bin liblockfile1 libreoffice-mysql-connector wget.
>^^^
>  Besides the fact that this is a empty
>  dummy package this again shows your
>  system was not clean - as that package
>  got updated in the repos with exactly
the
>  same version you reported against.
> 
> > In effect libreoffice starts again in new version so the bug can be
> > closed in my humble oppinion.
> 
> In my humble opinion you should have not reported it in the first
place.
> 
> But thanks, closing.
> 
> Regards,
> 
> Rene
> 
> 

Bug#934270: Homepage: requires log in

[Andrej Shadura]

Hi,

On Thu, 8 Aug 2019, 23:54 Christoph Biedl, 
wrote:

> trying to learn more about this new package - possibly it could replace
> pristine-tar? - I followed the Homepage: URL to
>  but unfortunately
> that page does not provide any information without logging in.
>
> Can you please rectify the situation?


The homepage page is on Salsa, that's why the URL above doesn't work. I'll
update the package with the next upload.

-- 
Cheers,
  Andrej

Bug#931503: protobuf: FTBFS on x32 (now for a different reason)

[Laurence Parry]

Unfortunately the build now fails earlier on x32 (indeed it seems on
most 32-bit platforms) during the Python 2.7 tests, so we can't see if
the fix worked yet:
https://buildd.debian.org/status/package.php?p=protobuf&suite=experimental

I believe this is
https://github.com/protocolbuffers/protobuf/issues/6205 though, and I
left some thoughts there about what might have caused the test to
fail.

Best regards,
-- 
Laurence "GreenReaper" Parry
https://www.greenreaper.co.uk/

Bug#933914: python3-pytest: pytest v4 breaks existing tests

[Drew Parsons]

On 2019-08-08 15:57, Ondřej Nový wrote:



I see, coming from flaky.  Thanks Ondrej.


this should be fixed now with python-flaky 3.6.1-1.


Thanks again Ondrej.  That fixes the mpi4py 3.0.2-10 tests.

Drew

Bug#934236: openafs-fileserver: postinst uses akeyconvert, but the package does not depend on openafs-krb5

[Arne Nordmark]

Den 2019-08-09 kl. 03:10, skrev Benjamin Kaduk:
> On Thu, Aug 08, 2019 at 03:16:31PM +0200, Arne Nordmark wrote:

> I will think a bit about whether it is better to leave the akeyconvert
> invocation in openafs-fileserver and make it conditional on akeyconvert's
> presence, add the openafs-krb5 dependency, or move the call to the
> openafs-krb5 maintainer script. 

As input for that, in my case the file servers running stretch did not
have openafs-krb5 installed, only a copied rxkad.keytab, so options 1
and 3 I guess would have left the file servers non-functional (lacking
the KeyFileExt). Depending on the error messages, this may have been
hard to track down.

Thanks again
Arne

Bug#933511: partman-base: reformatting md raid 0.90 metadata does not delete metadata

[Michael Hudson-Doyle]

The patch attached to this mail is better.

On Wed, 31 Jul 2019 at 14:12, Michael Hudson-Doyle <
michael.hud...@ubuntu.com> wrote:

> Source: partman-base
> Severity: normal
> Tags: d-i patch
>
> Dear Maintainer,
>
> As reported in
>
> https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1828558
>
> installing over a drive previously used as a md raid can leave a system
> that does not boot.  I tried and failed to convince parted upstream this
> was their bug (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853) so
> it probably makes sense to fix it in parted_server instead.
>
> I'm attaching a WIP patch to this report. I'll probably upload something
> like this to Ubuntu once I've tested it a bit.
>
> Cheers,
> mwh
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic-updates
>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
> 'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-55-generic (SMP w/4 CPU cores)
> Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
diff --git a/Makefile.am b/Makefile.am
index f93bf8e..e8027ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,7 +2,8 @@ bin_PROGRAMS = parted_server parted_devices partmap
 bin_SCRIPTS = partman partman-command partman-commit
 
 parted_server_SOURCES = parted_server.c
-parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS)
+parted_server_CPPFLAGS = $(blkid_CFLAGS)
+parted_server_LDADD = $(libparted_fs_resize_LIBS) $(libparted_LIBS) $(blkid_LIBS)
 
 parted_devices_SOURCES = parted_devices.c
 parted_devices_LDADD = $(libparted_LIBS)
diff --git a/configure.ac b/configure.ac
index 987cc4d..3d081ff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,6 +7,7 @@ AC_DEFINE([_POSIX_C_SOURCE], [200809L], [Define the POSIX version])
 AC_PROG_CC
 
 PKG_CHECK_MODULES([libparted], [libparted])
+PKG_CHECK_MODULES([blkid], [blkid])
 
 AC_ARG_VAR([libparted_fs_resize_LIBS], [linker flags for libparted-fs-resize])
 AC_MSG_CHECKING([for libparted >= 3.1])
diff --git a/parted_server.c b/parted_server.c
index 41784b7..5c75684 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
Logging
@@ -1360,6 +1361,61 @@ is_system_with_firmware_on_disk()
 return result;
 }
 
+/*
+ * wipe all superblocks libblkid knows about from a device
+ * (condensed from wipefs in util-linux)
+ */
+static int
+do_wipe(char *devname)
+{
+blkid_probe pr = NULL;
+int fd = -1;
+int r = -1;
+
+fd = open(devname, O_RDWR);
+
+if (fd < 0) {
+log("open(%s) failed errno %d", devname, errno);
+goto error;
+}
+
+log("do_wipe open(%s), %d", devname, fd);
+
+
+pr = blkid_new_probe();
+if (!pr || blkid_probe_set_device(pr, fd, 0, 0) != 0) {
+log("setting up probe failed");
+goto error;
+}
+
+blkid_probe_enable_superblocks(pr, 1);
+blkid_probe_set_superblocks_flags(pr, BLKID_SUBLKS_MAGIC |  /* return magic string and offset */
+  BLKID_SUBLKS_TYPE |   /* return superblock type */
+  BLKID_SUBLKS_BADCSUM);/* accept bad checksums */
+
+blkid_probe_enable_partitions(pr, 1);
+blkid_probe_set_partitions_flags(pr, BLKID_PARTS_MAGIC |
+ BLKID_PARTS_FORCE_GPT);
+
+while (blkid_do_probe(pr) == 0) {
+char *type = "unknown";
+if (blkid_probe_lookup_value(pr, "TYPE", &type, NULL) < 0)
+blkid_probe_lookup_value(pr, "PTTYPE", &type, NULL);
+log("wiping superblock of type %s", type);
+if (blkid_do_wipe(pr, 0) != 0) {
+log("wiping failed");
+}
+}
+
+fsync(fd);
+r = 0;
+  error:
+if (fd >= 0)
+close(fd);
+blkid_free_probe(pr);
+return r;
+}
+
 void
 command_commit()
 {
@@ -1382,8 +1438,25 @@ command_commit()
 }
 
 open_out();
-if (disk != NULL && named_is_changed(device_name))
-ped_disk_commit(disk);
+if (disk != NULL) {
+/* ped_disk_clobber does not remove all superblock information
+ * -- in particular it does not wipe mdraid 0.90 metadata,
+ * which can lead to an unbootable system as in
+ * https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1828558.
+ * parted upstream didn't think this was a bug so here we give
+  

Bug#934237: [pkg-gnupg-maint] Bug#934237: yubikey communication fails on startup

[Antoine Beaupré]

Control: found -1 2.2.12-1

On 2019-08-08 22:49:08, Antoine Beaupré wrote:
> I'll try again without the startup scripts next.

I can confirm that the problem still occurs with the GPG version in
Debian buster (2.2.12-1), when my startup scripts talk with SSH
prematurely.

Those scripts don't even *need* the SSH key on the Yubikey, mind
you. They just start looking around and find a key with a handle and try
to offer it. The interesting thing is there's an on-disk key that works
for that SSH connexion: it's its entire purpose. While the Yubikey can
*also* authenticate to that server, I don't actually *use* that key to
connect anyways.

So if I could rephrase that bug, I'd say that gpg-agent is
"sticky". Whenever it gets called first is what determines the TTY. If
that TTY is messed up (because it gets called too early in the session),
it's forever doomed and needs to restart or be retold where it is:

gpg-connect-agent UPDATESTARTUPTTY /bye

This seems sub-optimal. It's also quite strange it affects only
authentication and not signing: it might be something specific to
gpg-agent's SSH support.

I would argue that GPG's concept of a TTY is somewhat broken. I've
encountered this before, as I said earlier, in #719908, and I'm still
unconvinced at the way things are handled. But I'm not skilled enough in
all those interactions to tell what would be the correct way.

All I know is weird stuff happens like this all the time, and I often
end up restarting those daemons and things kind of work. But "kind of
works" isn't great: I'd love if GnuPG "just worked" all the time. :)

Thanks for the excellent feedback, and I hope the details I've provided
are useful. I have found the problem on my side, so from my point of
view the problem is "solved" in its immediacy, so feel free to close
this bug. But if you think (like me) the underlying problem should be
solved, I'd be happy to assist you with further testing.

Thanks!

A.

-- 
Government is the Entertainment division of the military-industrial
complex.
- Frank Zappa

Bug#934278: varnishlog: loaded failed failed

[Allan Wind]

Package: varnish
Version: 6.1.1-1+b1
Severity: normal

Dear Maintainer,

varnishlog fails to start on reboot:

2019-08-09T02:41:13.581+00:00 pawan varnishlog[784]: Starting HTTP 
accelerator log deamon: failed!
2019-08-09T02:41:13.581+00:00 pawan varnishlog[784]: 
2019-08-09T02:41:13.581+00:00 pawan varnishlog[784]: VSM: Could not get 
hold of varnishd, is it running?
2019-08-09T02:41:13.581+00:00 pawan systemd[1]: varnishlog.service: 
Control process exited, code=exited, status=1/FAILURE
2019-08-09T02:41:13.581+00:00 pawan systemd[1]: varnishlog.service: 
Failed with result 'exit-code'.
2019-08-09T02:41:13.581+00:00 pawan systemd[1]: Failed to start LSB: 
Start HTTP accelerator log daemon.

It appears to be a timing issue restarting it manually works fine:

systemctl restart varnishlog.service

root@pawan:/var/log# systemctl status varnishlog
● varnishlog.service - LSB: Start HTTP accelerator log daemon
   Loaded: loaded (/etc/init.d/varnishlog; generated)
   Active: active (running) since Thu 2019-08-08 22:55:15 EDT; 1min 5s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 6568 ExecStart=/etc/init.d/varnishlog start (code=exited, 
status=0/SUCCESS)
Tasks: 1 (limit: 4915)
   Memory: 1.2M
   CGroup: /system.slice/varnishlog.service
   └─6576 /usr/bin/varnishlog -a -w /var/log/varnish/varnish.log -D -P 
/run/varnishlog/varnishlog.pid

Aug 08 22:55:15 pawan systemd[1]: Starting LSB: Start HTTP accelerator log 
daemon...
Aug 08 22:55:15 pawan varnishlog[6568]: Starting HTTP accelerator log deamon:.
Aug 08 22:55:15 pawan systemd[1]: Started LSB: Start HTTP accelerator log 
daemon.

That said, I am not really sure this even works.  The only reference I see to
varnishlog is:

root@pawan:/# find /lib/systemd/ /etc -name varnishlog\*
/etc/systemd/system/multi-user.target.wants/varnishlog.service
/etc/default/varnishlog
/etc/init.d/varnishlog

and varnishlog.service is a dangling symlink to:

/lib/systemd/system/varnishlog.service

it seems to some type of left-over from a previous version:

dpkg -S varnishlog
varnish: /usr/bin/varnishlog
varnish: /etc/init.d/varnishlog
varnish: /usr/share/man/man1/varnishlog.1.gz
varnish: /etc/default/varnishlog

So I stopped the service the service and removed the file:

# systemctl disable varnishlog.service
# systemctl stop varnishlog.service
# rm /etc/systemd/system/multi-user.target.wants/varnishlog.service

I wanted to document this, but maybe there is a cleanup process missing
somewhere?


/Allan

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 varnish depends on:
ii  adduser   3.118
ii  gcc   4:8.3.0-1
ii  libc6 2.28-10
ii  libc6-dev [libc-dev]  2.28-10
ii  libedit2  3.1-20181209-1
ii  libjemalloc2  5.1.0-3
ii  libncursesw6  6.1+20181013-2
ii  libpcre3  2:8.39-12
ii  libtinfo6 6.1+20181013-2
ii  libvarnishapi26.1.1-1+b1
ii  lsb-base  10.2019051400

varnish recommends no packages.

Versions of packages varnish suggests:
pn  varnish-doc  

-- Configuration Files:
/etc/default/varnish changed:
START=yes
NFILES=131072
MEMLOCK=82000
DAEMON_OPTS="-a :6081 \
 -f /etc/varnish/default.vcl \
 -S /etc/varnish/secret \
 -s file,/var/lib/varnish/$(uname -n)/varnish_storage.bin,32G \
 -T localhost:6082 \
 -t 120"

/etc/default/varnishlog changed:
VARNISHLOG_ENABLED=1

/etc/logrotate.d/varnish changed:
/var/log/varnish/varnish.log {
compress
daily
delaycompress
missingok
postrotate
systemctl -q is-active varnishncsa.service &&
/usr/sbin/invoke-rc.d varnishncsa reload > /dev/null
systemctl -q is-active varnishlog.service &&
/usr/sbin/invoke-rc.d varnishlog reload > /dev/null
endscript
rotate 30
}

/etc/varnish/default.vcl changed:
vcl 4.0;
import std;
backend default {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_backend_response {
if (bereq.url ~ "^[^?]*\.(mp[34]|pdf|wav)(\?.*)?$") {
unset beresp.http.set-cookie;
set beresp.do_stream = true;
} else if (bereq.uncacheable) {
} else if (beresp.ttl <= 0s || beresp.http.Set-Cookie || 
beresp.http.Surrogate-control ~ "no-store" || (!beresp.http.Surrogate-Control 
&& beresp.http.Cache-Control ~ "no-cache|no-store|private") || beresp.http.Vary 
== "*") {
# Mark as "Hit-For-Pass" for the next 2 minutes
set b

Bug#934274: cloud.debian.org: stretch AMIs not available in new regions

[Noah Meyerhans]

On Thu, Aug 08, 2019 at 05:56:44PM -0700, Tarjei Husøy wrote:
> > The AMIs in the AWS marketplace should be launchable in the new regions.
> > See https://aws.amazon.com/marketplace/pp/B073HW9SP3 and let me know if
> > it'll work for you. The Marketplace AMIs are identical to the ones we
> > publish directly.
> 
> I wasn’t able to get this to work. I usually launch instances via the
> API, but the API returns zero AMIs for the account (379101102735) in
> the ap-east-1 region. I tried via the web console too, that errors
> with "AWS Marketplace was unable to proceed with the product you
> selected. Please try selecting this product later."

Interesting. You might consider asking your AWS support people why
you're not able to launch AMIs that the Marketplace reports as
available.

> > I'll see about getting the new regions enabled for the Debian account
> > that we use for publishing the AMIs on
> > https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch
> 
> Great, thanks! If you have web access it’s quite easy to activate,
> just click  “My Account”, scroll down to “AWS Regions” and click the
> buttons.

Unfortunately, I don't have the necessary permission to opt our AWS
account into those regions...

noah

Bug#934135: [Aptitude-devel] Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer

[Guillem Jover]

Hi!

On Thu, 2019-08-08 at 01:49:24 +0200, Axel Beckert wrote:
> Guillem Jover wrote:
> > I'm attaching an old patch I had around, which I thought I had sent
> > out, but apparently not (perhaps only on IRC), to switch to
> > libdpkg-perl's parser which is the successor of this package.
> 
> Yay, thanks! I really didn't want to go back to dpkg-parsechangelog
> which would pull in whole dpkg-dev.

> Looks fine on a first glance. I though nowadays would probably replace
> "-e" with "-E". But that's details.
> 
> But seeq also my reply to your mail in the thread of
> https://bugs.debian.org/933128 — waiting for a reply there before
> continuing here...

After some thought, I think a local aptitude-specific wrapper might be
even better and obviates the question of whether dpkg-parsechangelog
should be moved or not. :)

See the attached patch, which has seen no testing, but can do that
once and if it is deemed a good path forward.

Thanks,
Guillem
From 226aa8349cd90a6fa3b7595f0f3e6febf5312747 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 18 Oct 2016 23:55:28 +0200
Subject: [PATCH] Switch from libparse-debianchangelog-perl to libdpkg-perl

The former was merged into the latter some time ago, with the main
difference being the lack of some of the output formats that are not
being used by aptitude.

This seems to have been attempted in the past, but was reverted due to
performance problems. The performance from current libdpkg-perl should
be comparable.

We use the perl module directly via a new aptitude-changelog-parser
wrapper to avoid pulling dpkg-dev and its dependencies. This new
wrapper will also make sure the module is available before proceeding.
---
 Makefile.am|  3 ++-
 aptitude-changelog-parser  | 27 +++
 debian/control |  2 +-
 src/generic/apt/changelog_parse.cc | 17 +++--
 4 files changed, 37 insertions(+), 12 deletions(-)
 create mode 100755 aptitude-changelog-parser

diff --git a/Makefile.am b/Makefile.am
index 4e234efc..72ccbd7c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -9,7 +9,8 @@ TESTDIRS=@TESTDIRS@
 
 SUBDIRS=buildlib $(SRCDIRS) $(DOCDIRS) po $(TESTDIRS)
 
-dist_bin_SCRIPTS = aptitude-create-state-bundle aptitude-run-state-bundle
+dist_bin_SCRIPTS = apitude-changelog-parser \
+	aptitude-create-state-bundle aptitude-run-state-bundle
 
 MANPAGE_LOCALES=gl
 
diff --git a/aptitude-changelog-parser b/aptitude-changelog-parser
new file mode 100755
index ..aee1dfd1
--- /dev/null
+++ b/aptitude-changelog-parser
@@ -0,0 +1,27 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+eval {
+require Dpkg::Changelog::Parse;
+Dpkg::Changelog::Parse->import();
+1;
+} or do {
+warn "warning: Dpkg::Changelog::Parse not present, install libdpkg-perl\n";
+exit 0;
+};
+
+# Usage: aptitude-changelog-parser [ []]
+
+my %opts;
+if (scalar @ARGV >= 1) {
+$opts{file} = shift @ARGV;
+}
+if (scalar @ARGV == 1) {
+$opts{from} = $ARGV[0];
+} else {
+$opts{all} = undef;
+}
+
+print join "\n", changelog_parse(format => 'rfc822', %opts);
diff --git a/debian/control b/debian/control
index c4a17d58..cd114861 100644
--- a/debian/control
+++ b/debian/control
@@ -41,7 +41,7 @@ Multi-Arch: foreign
 Depends: aptitude-common (= ${source:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
-Recommends: libparse-debianchangelog-perl,
+Recommends: libdpkg-perl,
 sensible-utils
 Suggests: aptitude-doc-en | aptitude-doc,
   apt-xapian-index,
diff --git a/src/generic/apt/changelog_parse.cc b/src/generic/apt/changelog_parse.cc
index 9cf1ab5b..3d20867f 100644
--- a/src/generic/apt/changelog_parse.cc
+++ b/src/generic/apt/changelog_parse.cc
@@ -18,8 +18,8 @@
 //   the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
 //   Boston, MA 02110-1301, USA.
 //
-// At the moment this code uses parsechangelog to convert changelogs
-// into something easier to read.
+// At the moment this code uses aptitude-changelog-parser which abstracts
+// the actual parsing to convert changelogs into something easier to read.
 
 #include "changelog_parse.h"
 
@@ -326,20 +326,17 @@ namespace aptitude
   temp::name rval("parsedchangelog");
 
   std::string version_fragment;
-  if(from.empty())
-	version_fragment = "--all";
-  else
+  if(!from.empty())
 	{
-	  version_fragment = "-f ";
 	  // Note that escaping the version is *critical*, because
 	  // it is untrusted data.
-	  version_fragment += backslash_escape_nonalnum(from);
+	  version_fragment = backslash_escape_nonalnum(from);
 	}
 
   std::string cmd =
-	cw::util::ssprintf("/usr/bin/parsechangelog --format rfc822 %s -l %s > %s 2> /dev/null",
-			   version_fragment.c_str(),
+	cw::util::ssprintf("aptitude-changelog-parser %s %s > %s",
 			   filename.c_str(),
+			   version_fragment.c_str(),
 			   rval.get_name().c_str());
 
   if(system(cmd.c_str()) == 0)
@@ -432,7 +429,7 @@ namespace aptitude

Bug#933128: Would you be willing to pass Parse::DebianChangelog upstream development to someone else?

[Guillem Jover]

On Wed, 2019-08-07 at 16:19:30 +0200, Axel Beckert wrote:
> Guillem Jover wrote:
> > Some of the features got removed, to trim down dependencies, and the
> > API adapted to match the rest of the libdpkg-perl codebase, but if
> > the removed output formats are needed, or anything else seems
> > suboptimal or worth improving/adding, I'm happy to work on those.
> 
> What I quickly checked a few weeks ago was if libdpkg-perl has an
> equivalent of parsechangelog which is used in aptitude. But it hasn't,
> so I didn't consider it to be a suitable replacement.
> 
> And your patch against aptitude (see https://bugs.debian.org/934135)
> uses "perl -MDpkg::Changelog::Parse -e …" which probably works well,
> but having a drop-in replacement for /usr/bin/parsechangelog which is
> not in dpkg-dev would be nice.

I'm not very fond of placing programs in lib.*-perl packages TBH. I've
pondered in the past to split some of the tools out from dpkg-dev, but
I'm not really sure it is worth it. And checking again, for the
aptitude case I think a local aptitude-specific wrapper makes more
sense. I'm sending a follow-up patch there.

Thanks,
Guillem

Bug#934237: [pkg-gnupg-maint] Bug#934237: yubikey communication fails on startup

[Antoine Beaupré]

On 2019-08-09 09:08:35, NIIBE Yutaka wrote:
> Antoine Beaupre  wrote:
>> When I login in the morning, my Yubikey setup fails to let me connect
>> to remove SSH servers:
>
> How do you invoke gpg-agent?  If it is through your first SSH
> invocation, gpg-agent wouldn't know the place where to ask PIN (TTY and
> DISPLAY).
>
> You can check if you can use your tokan with SSH after your first
> invocation of:
>
>   $ gpg --card-status
>
> or
>
> $ gpg-connect-agent UPDATESTARTUPTTY /bye
>
> Then, that's the case.

Okay, I can confirm the above (`UPDATESTARTUPTTY`) is a valid
workaround.

I also observed something strange. I sign all git commits automatically
here. I just did a commit, and git was able to make gpg-agent pop up the
pinentry dialog without problem for the commit OpenPGP signature, which
happens on the Yubikey. But the *push* part failed as described in this
bug report.

Then the above gpg-connect-agent hack worked around the issue.

It's strange that one function (signing) works while the other
(authentication) doesn't, no?

$ gpg --card-status
Reader ...: Yubico Yubikey NEO OTP U2F CCID 00 00
Application ID ...: [REDACTED]
Version ..: 2.0
Manufacturer .: Yubico
Serial number : [REDACTED]
Name of cardholder: [non positionné]
Language prefs ...: [non positionné]
Sex ..: non indiqué
URL of public key : [non positionné]
Login data ...: [non positionné]
Signature PIN : non forcé
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 12896
Signature key : 7B16 4204 D096 723B 0196  35AB 3EA1  B261 D97B
  created : 2017-08-23 23:10:50
Encryption key: 7301 8B4C D3E4 82C6 E90F  B7C3 C665 A3C5 2513 53D0
  created : 2017-08-25 18:18:02
Authentication key: 5A23 7308 8863 DBDF 2E00  7607 604E 4B3E EE02 855A
  created : 2012-07-20 00:17:35
General key info..: sub  rsa2048/3EA1B261D97B 2017-08-23 Antoine Beaupré 

sec   rsa4096/792152527B75921E  créé : 2009-05-29  expire : 2020-06-05
ssb#  rsa2048/B7F648FED2DF2587  créé : 2012-07-18  expire : jamais
ssb>  rsa2048/604E4B3EEE02855A  créé : 2012-07-20  expire : jamais
nº de carte : 0006 03647189
ssb#  rsa2048/46DC033CAFD0FDF8  créé : 2012-07-24  expire : jamais
ssb   rsa4096/A51D5B109C5A5581  créé : 2009-05-29  expire : jamais
ssb>  rsa2048/3EA1B261D97B  créé : 2017-08-23  expire : jamais
nº de carte : 0006 03647189

> gpg-agent should know the place where to ask PIN (TTY and DISPLAY), and
> it is told by gpg frontend or gpg-connct-agent.  But in the case of SSH
> (external/foreign program), there is no such mechanism telling the
> place.

But in this case, I ran 'git push' in a terminal I control,
interactively. gpg knows which terminal it's on, and it even knows which
DISPLAY it's on, and could definitely prompt me, either on the terminal
or the GUI.

I'll try again without the startup scripts next.

a.
-- 
Your injured body has become the burden of your digital soul.
- Yin Aiwen, 2013, The Massage is the Medium

Bug#934104: [pkg-php-pear] Bug#934104: composer: Don't use debian/copyright for LICENSE when generating autoloader

[David Prévot]

Hi Kunal,

Thank you for your report.

Le 06/08/2019 à 22:33, Kunal Mehta a écrit :

> 0005-Pick-up-copyright-instead-of-LICENSE.patch switches the composer autoload
> generator to use debian/copyright instead of upstream's LICENSE file. This is
> problematic for a few reasons:
> 
> First, vendor/ directories are no longer identical with people who use an
> upstream version of composer or from a different distribution (example:
> https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/526262/1/composer/LICENSE).

Why is that a problem?

> And secondly, minimal installations (e.g. docker containers) of Debian that
> don't keep doc/ around can no longer run composer install.

That is definitely an issue.

> Is there a reason we need the patch?

We provide composer files in /usr/share/php, not in src/, so the LICENSE
file is not available in ../ (i.e., /usr/share/). Furthermore,
duplicating LICENSE information already provided in the package is
usually a bad idea, but as you pointed out, we should not rely on
/usr/share/doc at run time.

I’ve updated the package to provide the upstream LICENSE file from
/usr/share/php/data/Composer, so both issues should be fixed after the
next upload, thanks.

Regards.

David



signature.asc
Description: OpenPGP digital signature

Bug#934237: [pkg-gnupg-maint] Bug#934237: yubikey communication fails on startup

[Antoine Beaupré]

On 2019-08-09 09:08:35, NIIBE Yutaka wrote:
> Antoine Beaupre  wrote:
>> When I login in the morning, my Yubikey setup fails to let me connect
>> to remove SSH servers:
>
> How do you invoke gpg-agent?  If it is through your first SSH
> invocation, gpg-agent wouldn't know the place where to ask PIN (TTY and
> DISPLAY).

I don't directly invoke it. It might be through the first SSH connexion,
or earlier (see below). But it's running under `systemd --user`.

> You can check if you can use your tokan with SSH after your first
> invocation of:
>
>   $ gpg --card-status
>
> or
>
> $ gpg-connect-agent UPDATESTARTUPTTY /bye
>
> Then, that's the case.

`gpg --card-status` works, as I said.

> gpg-agent should know the place where to ask PIN (TTY and DISPLAY), and
> it is told by gpg frontend or gpg-connct-agent.  But in the case of SSH
> (external/foreign program), there is no such mechanism telling the
> place.

Oh god, that TTY thing. I have this in my .bashrc because of problems
with GPG on that front:

# see http://bugs.debian.org/719908
export GPG_TTY=$(tty)

I have no idea what it does or why it matters. It might be related.

It wouldn't explain why this suddenly started failing.

You know what, now that I think of it, one thing that changed recently
in my startup sequence, and that might affect this, is this:

|  .config/systemd/user/{multi-user.target.wants => 
default.target.wants}/smd-pull.service| 0

This is me switching my "systemd --user"-level services from
`multi-user.target` (which does nothing) to `default.target` (which does
start services on session start.

This peculiar service is something that connects over SSH to fetch my
mail. It *might* try to talk to the Yubikey and fire up GPG agent (maybe
even before Xorg comes up, and definitely before the Yubikey is
entered).

This might be the actual trigger for this problem I'll test this (and an
older version of GPG) to see if I can backtrack the issue.

>> aoû 08 09:51:37 curie gpg-agent[3298]: smartcard signing failed: Ioctl() 
>> inapproprié pour un périphérique 
>> aoû 08 09:51:37 curie gpg-agent[3298]: ssh sign request failed: Ioctl() 
>> inapproprié pour un périphérique  
>
> If it is "Inappropriate ioctl for device", it means that pinentry failed
> because of no place to ask.

Thanks! That's very useful information, although I can't help but think
that a better error message would be useful here.. ;)

>> Once gpg-agent is restarted, the Yubikey works fine again. And that
>> is, even if it's unplugged and plugged back in again.
>
> For me, it sounds like... it is your first invocation of SSH (by systemd
> watching the socket), which invokes gpg-agent.

For what it's worth, gpg-agent runs as "supervised" here, i.e. it seems
to be under the control of `systemd --user`. Not sure what that means,
but when it's running, it's running under systemd and I can restart it
with `systemctl --user restart gpg-agent`.

But thanks for all the great information, I have a lot of things to move
forward with now!

A.

-- 
Uncompromising war resistance and refusal to do military service under
any circumstances.
   - Albert Einstein

Bug#934277: slapd segfault on rwm filter parse error

[Ryan Tandy]

Package: slapd
Version: 2.4.21-1
Severity: important
Tags: security
Control: fixed -1 2.4.48+dfsg-1
Control: forwarded -1 https://openldap.org/its/?findid=8964

This is already fixed in unstable, but filing this for tracking anyway 
as I think it warrants fixing in stable as well.

If rwm modifies the search filter and the resulting filter is invalid, 
slapd crashes while cleaning up the operation. I believe it ends up 
freeing the same pointer twice (where the happy path frees two different 
ones).

Depending on the rwm configuration, users (possibly even 
anonymous/unprivileged ones) with access to search the directory in a 
way that causes the search filter to be rewritten can crash slapd 
remotely.

Fixed in master by d40b357, in RE24 by 0f7ec3a.

Also reported in Ubuntu: https://bugs.launchpad.net/bugs/1838370

Bug#592124: Németh család öröksége kapcsolatba lép velem

[Olivier Percy]

Helló barátom, van egy fontos kérdés, amelyet szeretnék megbeszélni veled a
Németh B. A késő 2.5 millió eurós örökségéről, ezért kérjük, vegye fel a
kapcsolatot velem további részletekért, amilyen hamar csak lehetséges.

Olivier Esq.

Bug#931930: firmware-misc-nonfree: Please, include i915/icl_dmc_ver1_07.bin

[Dmitry Eremin-Solenikov]

Package: firmware-misc-nonfree
Version: 20190717-1
Followup-For: Bug #931930

With 5.2 kernel I started to get two missing firmware entries. One for
the icl_dmc_ver1_07.bin, another one being bxc_huc_ver01_8_2893.bin:

W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for
module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_8_2893.bin
for module i915

-- 
With best wishes
Dmitry


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

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

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.133

-- no debconf information

Bug#934276: O: rpl -- replace strings in files

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the rpl package.

The new upstream of rpl removed two significative options for me in last
version (1.6.0): -R and -x.

 -R, --recursive  Recurse into subdirectories.
 -xSUFFIX Search only files ending with SUFFIX, e.g. ''.txt''.
  May be specified multiple times.

Consequently, this package is no longer useful for me.

The package description is:
 rpl is an intelligent search and replacement utility. It will change strings
 with new strings in multiple text files at the same time.
 .
 rpl can verify, find  and edit several plain texts quickly.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Regards,

Eriberto

Bug#934230: unattended-upgrades: Prevents regular usage of package tools

[fmneto]

Greetings!

On 2019-08-08 17:47, Bálint Réczey wrote:

Control: tags -1 moreinfo

Hi Francisco,


<...>


Unattended-upgrades is expected to run only for a few seconds per day
and should not block installation of packages when it is not running.
Could you please check if it was stuck?
You can use pstree and check the logs in /var/log/unattended-upgrades/ 
.


Thanks,
Balint



  I checked the log files for it. Two things:

1) Ironically, unattended-upgrades.log reports an error because it could 
not get the lock at /var/lib/dpkg/lock


2) unattended-upgrades-dpkg.lost shows nothing out of the ordinary, 
except it suddenly stops (most likely when I manually killed the 
process).


These files do not contain logs for other times, though. However, it may 
be supposed to run only for a few seconds, but these logs span several 
minutes (which, come to think of it, make _some_ sense since the logs 
report several packages to be installed).


Thinking back, and considering this installation as well as others (my 
computer at work and my desktop at home), the impression that I get is 
that it seems to check for updates right after I log in to the system, 
which is usually the moment I decide to do the same (check for upgrades 
or installing new packages).


I have no idea if that is the expected behavior for it or not, but I 
have encountered dpkg locked more often than not, and that can become 
really annoying after some time.


Perhaps, instead of simply complaining about an unobtainable lock, apt 
could give the user a message like "hang on, there are upgrades being 
installed, these are the packages that are being upgraded" - or 
something along those lines. That way at least I'd know to wait for a 
bit until the upgrade is complete.


With hopes of making this whole issue a bit clearer, I'm gonna try and 
summarize:


1- I log in to the system
2a- The first thing I do is run apt update
2b- Alternatively, I search for something with apt search then try to 
install it with apt install

3- In either case, I get a message about the locks not being available

I hope this is more illuminating (the log files I mentioned are 
attached).


Best,
FranciscoLog started: 2019-08-08  08:25:54
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 536853 files and directories currently installed.)
Preparing to unpack .../000-libreoffice-l10n-zh-tw_1%3a6.1.5-3+deb10u2_all.deb 
...
Unpacking libreoffice-l10n-zh-tw (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../001-libreoffice-help-zh-cn_1%3a6.1.5-3+deb10u2_all.deb 
...
Unpacking libreoffice-help-zh-cn (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../002-libreoffice-help-sv_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-sv (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../003-libreoffice-help-sl_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-sl (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../004-libreoffice-help-sk_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-sk (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../005-libreoffice-help-ru_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-ru (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../006-libreoffice-help-pt_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-pt (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../007-libreoffice-help-pl_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-pl (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../008-libreoffice-help-nl_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-nl (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../009-libreoffice-help-ko_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-ko (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../010-libreoffice-help-km_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-km (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../011-libreoffice-help-ja_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-ja (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../012-libreoffice-help-it_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-it (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../013-libreoffice-help-hu_1%3a6.1.5-3+deb10u2_all.deb ...
Unpacking libreoffice-help-hu (1:6.1.5-3+deb10u2) over (1:6.1.5-3) ...
Preparing to unpack .../014-libreoffice

Bug#934236: openafs-fileserver: postinst uses asetkey, but the package does not depend on openafs-krb5

[Benjamin Kaduk]

On Thu, Aug 08, 2019 at 03:16:31PM +0200, Arne Nordmark wrote:
> Package: openafs-fileserver
> Version: 1.8.2-1
> Severity: normal
> 
> The stanza
> 
> if [ -r /etc/openafs/server/rxkad.keytab ] ; then
> akeyconvert
> fi
> 
> in the postinst will fail if openafs-krb5 is not installed or is of version 
> 1.6.
> 
> This happens for example when doing a partial upgrade from stretch to buster 
> using apt-get upgrade.
> 
> A dependency on openafs-krb5 should be added to the package.

Thanks for the report; this is quite clearly a bug in the maintainer
script.
I will think a bit about whether it is better to leave the akeyconvert
invocation in openafs-fileserver and make it conditional on akeyconvert's
presence, add the openafs-krb5 dependency, or move the call to the
openafs-krb5 maintainer script.  Adding the hard dependency would break a
property that the original packaging split had as a strong requirement,
though the incentive to have that requirement is probably much smaller now
that it was originally.

-Ben

Bug#934273: python3-debian: please support parsing Source: package (version)

[David Bremner]

Stuart Prescott  writes:

>
> Any opinions on whether it should return the data unparsed as
>
>   source_package (version)
>
> or whether it should be clever enough to return a 
>
>   namedtuple(..., ['source', 'version'])
>

Hmm. I'm not (blush) familiar with named tuples. I was thinking
something simple-minded like the following. By all means feel free to do
the pythonic thing though.

import re

rex=re.compile('([^(\s]+)\s*[(]([^)]+)[)]$')

def parse_source(string):
matches=rex.match(string)
if matches:
return (matches.group(1),matches.group(2))
else:
return string

def test_parse_source_without():
assert parse_source('0x') == '0x'

def test_parse_source_with():
assert parse_source('0x (0.8-1)') == ('0x','0.8-1')

Bug#934274: cloud.debian.org: stretch AMIs not available in new regions

[Tarjei Husøy]

> On Aug 8, 2019, at 17:19, Noah Meyerhans  wrote:
> 
> The AMIs in the AWS marketplace should be launchable in the new regions.
> See https://aws.amazon.com/marketplace/pp/B073HW9SP3 and let me know if
> it'll work for you. The Marketplace AMIs are identical to the ones we
> publish directly.

I wasn’t able to get this to work. I usually launch instances via the API, but 
the API returns zero AMIs for the account (379101102735) in the ap-east-1 
region. I tried via the web console too, that errors with "AWS Marketplace was 
unable to proceed with the product you selected. Please try selecting this 
product later."

> On Aug 8, 2019, at 17:19, Noah Meyerhans  wrote:
> 
> I'll see about getting the new regions enabled for the Debian account
> that we use for publishing the AMIs on
> https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch

Great, thanks! If you have web access it’s quite easy to activate, just click  
“My Account”, scroll down to “AWS Regions” and click the buttons.


Have a splendid day!

--
Tarjei Husøy
Co-founder, megacool.co

Bug#934275: ptpd newer upstream release 2.3.2

[Andrew Thomson]

Package: ptpd
Version: 2.3.1-debian1-4

Just flagging the newer upstream version of ptpd that is available.

https://github.com/ptpd/ptpd

I actually think it will solve the existing bug reported against this package 
(925470) too!

Regards,

Andrew

Bug#934273: python3-debian: please support parsing Source: package (version)

[Stuart Prescott]

On Friday, 9 August 2019 09:42:02 AEST David Bremner wrote:
> Source: 0x (0.8-1)
> 
> is a legit line in a Packages (and buildinfo) file, we should
> impliment a parser for that once, rather than letting everyone
> re-invent their own hack.

Yes, sounds very sensible.

Since that field is also an optional one, I guess Packages should also make 
sure that it always works, providing the binary package name and binary 
package version when it is omitted.

Any opinions on whether it should return the data unparsed as

source_package (version)

or whether it should be clever enough to return a 

namedtuple(..., ['source', 'version'])


thanks for the suggestion
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

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

[Gerald Turner]

Control: found -1 4.0.8-1

FYI, bug still exists in 4.0.8-1 (bullseye version).

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#934237: [pkg-gnupg-maint] Bug#934237: yubikey communication fails on startup

[NIIBE Yutaka]

Antoine Beaupre  wrote:
> When I login in the morning, my Yubikey setup fails to let me connect
> to remove SSH servers:

How do you invoke gpg-agent?  If it is through your first SSH
invocation, gpg-agent wouldn't know the place where to ask PIN (TTY and
DISPLAY).

You can check if you can use your tokan with SSH after your first
invocation of:

$ gpg --card-status

or

$ gpg-connect-agent UPDATESTARTUPTTY /bye

Then, that's the case.

gpg-agent should know the place where to ask PIN (TTY and DISPLAY), and
it is told by gpg frontend or gpg-connct-agent.  But in the case of SSH
(external/foreign program), there is no such mechanism telling the
place.

> aoû 08 09:51:37 curie gpg-agent[3298]: smartcard signing failed: Ioctl() 
> inapproprié pour un périphérique 
> aoû 08 09:51:37 curie gpg-agent[3298]: ssh sign request failed: Ioctl() 
> inapproprié pour un périphérique  

If it is "Inappropriate ioctl for device", it means that pinentry failed
because of no place to ask.

> Once gpg-agent is restarted, the Yubikey works fine again. And that
> is, even if it's unplugged and plugged back in again.

For me, it sounds like... it is your first invocation of SSH (by systemd
watching the socket), which invokes gpg-agent.
-- 

Bug#934274: cloud.debian.org: stretch AMIs not available in new regions

[Noah Meyerhans]

> Amazon recently launched two new regions, Hong Kong (ap-east-1) and
> Bahrain (me-south-1). All new regions after March 20, 2019 come on a
> opt-in basis [1], thus you might not have seen them show up unless you
> saw the news when they were introduced. Would it be possible to have
> stretch images published for these regions?

Yep, that's an oversight on my end. The need to opt in to new regions
is not something I've fully internalized yet.

The AMIs in the AWS marketplace should be launchable in the new regions.
See https://aws.amazon.com/marketplace/pp/B073HW9SP3 and let me know if
it'll work for you. The Marketplace AMIs are identical to the ones we
publish directly.

I'll see about getting the new regions enabled for the Debian account
that we use for publishing the AMIs on
https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch

noah

Bug#934274: cloud.debian.org: stretch AMIs not available in new regions

[Noah Meyerhans]

Package: cloud.debian.org
Severity: important
Control: submitter -1 Tarjei Husøy 

Hi,

Amazon recently launched two new regions, Hong Kong (ap-east-1) and Bahrain 
(me-south-1). All new regions after March 20, 2019 come on a opt-in basis [1], 
thus you might not have seen them show up unless you saw the news when they 
were introduced. Would it be possible to have stretch images published for 
these regions?

Thanks!

[1]: https://docs.aws.amazon.com/general/latest/gr/rande-manage.html

Have a splendid day!

—
Tarjei Husøy
Co-founder, megacool.co

Bug#934273: python3-debian: please support parsing Source: package (version)

[David Bremner]

Package: python3-debian
Version: 0.1.35
Severity: wishlist

Since

Source: 0x (0.8-1)

is a legit line in a Packages (and buildinfo) file, we should
impliment a parser for that once, rather than letting everyone
re-invent their own hack.


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

Versions of packages python3-debian depends on:
ii  python3  3.7.3-1
ii  python3-chardet  3.0.4-3
ii  python3-six  1.12.0-1

Versions of packages python3-debian recommends:
ii  python3-apt  1.8.4

Versions of packages python3-debian suggests:
ii  gpgv  2.2.17-3

-- no debconf information

Bug#874176: wrk: Fails to run with 'PANIC: unprotected error in call to Lua API'

[Alex Andreotti]

Package: wrk
Version: 4.0.2-2
Followup-For: Bug #874176

Dear Maintainer,

  * What led up to the situation?

I needed to use wrk for some benchmark.

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

apt install wrk && wrk -c 800 -d 10 -t 24 http://127.0.0.1:8080/

   * What was the outcome of this action?

PANIC: unprotected error in call to Lua API (attempt to index a nil value)

   * What outcome did you expect instead?

the benchmark to run.

Currently luajit-2.1 is installed but the sources are looking for luajit-2.0, 
also luajit-2.1 is missing a define (luaL_reg luaL_Reg) and src/script.c fail 
to compile.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (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=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 wrk depends on:
ii  libc62.28-10
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.1
ii  libssl1.11.1.1c-1

wrk recommends no packages.

wrk suggests no packages.

-- no debconf information
Index: wrk-4.0.2/src/script.h
===
--- wrk-4.0.2.orig/src/script.h
+++ wrk-4.0.2/src/script.h
@@ -2,9 +2,9 @@
 #define SCRIPT_H
 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 #include "stats.h"
 #include "wrk.h"
Index: wrk-4.0.2/src/wrk.h
===
--- wrk-4.0.2.orig/src/wrk.h
+++ wrk-4.0.2/src/wrk.h
@@ -10,7 +10,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "stats.h"
 #include "ae.h"
Index: wrk-4.0.2/src/script.c
===
--- wrk-4.0.2.orig/src/script.c
+++ wrk-4.0.2/src/script.c
@@ -26,6 +26,8 @@ static void set_fields(lua_State *, int,
 static void set_field(lua_State *, int, char *, int);
 static int push_url_part(lua_State *, char *, struct http_parser_url *, enum 
http_parser_url_fields);
 
+#define luaL_reg  luaL_Reg
+
 static const struct luaL_reg addrlib[] = {
 { "__tostring", script_addr_tostring   },
 { "__gc",   script_addr_gc },

Bug#934066: sysv-rc: /etc/init.d/README is misleading wrt *.sh

[Adam Borowski]

On Thu, Aug 08, 2019 at 08:21:34PM +, Dmitry Bogatov wrote:
> [2019-08-06 18:36] Adam Borowski 
> > The documentation in /etc/init.d/README talks a lot about *.sh files in that
> > dir, in a way that suggests that's the way regular init scripts should be
> > named.  Could you please disambiguate?
> >
> > (Apologies for not submitting patches myself -- I'm on a phoney PDA until
> > mid August.)
> 
> Copy-editing is welcome.
> 
> From 949cb25e210d8f896068a018223c8cc2d78ac98f Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Tue, 6 Aug 2019 22:41:56 +
> Subject: [PATCH] Do not imply in README that init scripts must have extension
> 
> Avoid refererring to init scripts using /etc/init.d/*.sh wildcard,
> most of them do not have (and should not!) extension.

> -Debian Policy dictates that /etc/init.d/*.sh scripts must work properly
> -when sourced.  The following additional rules apply:
> +Debian Policy dictates that scripts in /etc/init.d/ must work properly when
> +sourced.  The following additional rules apply:
>  
> -* /etc/init.d/*.sh scripts must not rely for their correct functioning
> +* /etc/init.d/* scripts must not rely for their correct functioning
>on their being sourced rather than executed.  That is, they must work
>properly when executed too. They must include "#!/bin/sh" at the top.

This part is not true: there's also #!/usr/bin/env /lib/init/init-d-script

>This is useful when running scripts in parallel.
>  
> -* /etc/init.d/*.sh scripts must conform to the rules for sh scripts as
> +* /etc/init.d/* scripts must conform to the rules for sh scripts as


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#672361: bootlogd: escape sequences should be filtered out

[Jesse Smith]

On Thu, 08 Aug 2019 20:21:50 + Dmitry Bogatov wrote:
>
> control: tags -1 +upstream
>
> [2019-08-07 05:13] Adam Borowski
> > [...]
> > > a /var/log/boot.log file is
> > > generated where nothing is filtered out, so that the file is readable
> > > with "cat" or "less" (and text is colored).
> >
> > I don't think files in /var/log/ should be anything but plain text -- at
> > least unless colorized-logs becomes essential :þ and/or less defaults to
> > -R. But until a solution is implemented, I agree that leaving binaryish
> > control codes intact is better than corrupting them.
>
> Jesse, there seems to be demand on turning-off escape sequence filtering
> in bootlogd. Can you please make it configurable?

It is pretty easy to make an option for printing the escape sequences to
the log file. This will allow tools like "less" to print the boot log
with its colour codes.

I'd like to point out though that with such an option enabled, it is
going to result in some weird output. If all escape sequences are
printed to the file, tools like "less" can handle it, but other (more
raw) text manipulation tools such as "head" and "tail" will end up
mangling the lines. This is partly because escape characters include
positional instructions like '\r' for carriage-return.

In other words, if we make the boot log completely unfiltered, lines in
"less" will display properly, but using "cat", "head" or "tail" will
result in mangled lines that look like this:

Thu Aug 8 19:06:30 2019:
[ ok ug 8 19:06:30 2019: [... starting ]


I'm not sure we want to do that. Perhaps the ideal would be a small
degree of filtering to remove the positional control characters (like
'\r') while leaving the rest in to allow for colour to be displayed?

- Jesse

Bug#934272: python-asdf: newer pyyaml changes default_flow_style

[Mathieu Trudel-Lapierre]

Package: python-asdf
Version: 2.3.3-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

default_flow_style=None changed to default_flow_style=False by default
in pyyaml 5.1 [1].

I wrote the following pretty heavy-handed patch to address the situation
and maintain previous behavior, though you might want to change the tests
instead and follow the changes made upstream.

[1] https://github.com/yaml/pyyaml/issues/265


*** /tmp/tmpGHYumu/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all calls
to yaml.dump() include default_flow_style=None, to retain previous behavior
that is checked for in tests, unless it's already otherwise specified.


Thanks for considering the patch.


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

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch 
python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch
--- python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch
1969-12-31 19:00:00.0 -0500
+++ python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch
2019-08-08 17:58:05.0 -0400
@@ -0,0 +1,31 @@
+From: Mathieu Trudel-Lapierre 
+Subject: Force yaml.dump() calls to specify default_flow_style=None
+
+default_flow_style changed to False by default, which actually changes
+the output format. Make sure we retain the previous behavior expected
+by the tests.
+
+cf. https://github.com/yaml/pyyaml/issues/265
+
+Index: python-asdf-2.3.3/asdf/block.py
+===
+--- python-asdf-2.3.3.orig/asdf/block.py
 python-asdf-2.3.3/asdf/block.py
+@@ -397,6 +397,7 @@ class BlockManager:
+ offsets, Dumper=yamlutil._yaml_base_dumper, stream=fd,
+ explicit_start=True, explicit_end=True,
+ version=yaml_version,
++default_flow_style=None,
+ allow_unicode=True, encoding='utf-8')
+ 
+ _re_index_content = re.compile(
+Index: python-asdf-2.3.3/asdf/yamlutil.py
+===
+--- python-asdf-2.3.3.orig/asdf/yamlutil.py
 python-asdf-2.3.3/asdf/yamlutil.py
+@@ -340,4 +340,5 @@ def dump_tree(tree, fd, ctx):
+ explicit_start=True, explicit_end=True,
+ version=yaml_version,
+ allow_unicode=True, encoding='utf-8',
++default_flow_style=None,
+ tags=tags)
diff -Nru python-asdf-2.3.3/debian/patches/series 
python-asdf-2.3.3/debian/patches/series
--- python-asdf-2.3.3/debian/patches/series 2019-07-18 08:16:44.0 
-0400
+++ python-asdf-2.3.3/debian/patches/series 2019-08-08 17:56:37.0 
-0400
@@ -3,3 +3,4 @@
 Emulate-importlib.resources-for-Python-3.6.patch
 Remove-loopback-internet-access-test.patch
 Remove-test-that-requires-the-non-existence-of-an-externa.patch
+fix_pyyaml_default_flow_style.patch

Bug#934209: steam: libGL.so.1 requieres symlink

[Simon McVittie]

Control: tags -1 = moreinfo

On Thu, 08 Aug 2019 at 10:53:10 +0200, Stephan Lachnit wrote:
> I installed steam and got the error "Missing 32-bit libraries: libGL.so.1"
> 
> I was able to fix it by setting this symlink:
> sudo ln -s /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 
> /usr/lib/libGL.so.1

Steam requires working 32-bit and (usually) 64-bit GL drivers,
somewhere in the default library search path. libGL.so.1 should
usually be in /usr/lib/x86_64-linux-gnu/libGL.so.1 for 64-bit and
/usr/lib/i386-linux-gnu/libGL.so.1 for 32-bit. /usr/lib/libGL.so.1 should
not usually exist at all on recent Debian systems.

Creating these symbolic links is not Steam's responsibility,
and unilaterally creating them could break other packages and
systems. Arranging for a suitable libGL.so.1 to be put in place on systems
that have the proprietary NVIDIA driver installed is a complicated process
involving glx-alternatives, several layers of dpkg alternatives, and
dpkg-divert (it would be nice if it was simpler, but currently it isn't).

Please send the output of these commands to this bug, after removing
the /usr/lib/libGL.so.1 symlink that you created:

dpkg-query -W 'libgl1*'
dpkg-query -W 'libglx*'
dpkg-query -W 'nvidia-*'
dpkg-query -W 'nvidia-*'
dpkg-query -W 'glx-*'
update-alternatives --query glx
update-alternatives --query nvidia
ldconfig -p|grep libGL

Thanks,
smcv

Bug#934271: python-tablib: newer pyyaml changes default_flow_style

[Mathieu Trudel-Lapierre]

Package: python-tablib
Version: 0.12.1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

default_flow_style=None changed to default_flow_style=False by default
in pyyaml 5.1 [1].

I wrote the following pretty heavy-handed patch to address the situation
and maintain previous behavior, though you might want to change the tests
instead and follow the changes made upstream.

[1] https://github.com/yaml/pyyaml/issues/265


*** /tmp/tmpU9xam4/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all calls
to yaml.dump() include default_flow_style=None, to retain previous behavior
that is checked for in tests, unless it's already otherwise specified.


Thanks for considering the patch.


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

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch 
python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch
--- python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch 
1969-12-31 19:00:00.0 -0500
+++ python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch 
2019-08-08 18:06:41.0 -0400
@@ -0,0 +1,30 @@
+From: Mathieu Trudel-Lapierre 
+Subject: Force yaml.dump() calls to specify default_flow_style=None
+
+default_flow_style changed to False by default, which actually changes
+the output format. Make sure we retain the previous behavior expected
+by the tests.
+
+cf. https://github.com/yaml/pyyaml/issues/265
+
+Index: python-tablib-0.12.1/tablib/formats/_yaml.py
+===
+--- python-tablib-0.12.1.orig/tablib/formats/_yaml.py
 python-tablib-0.12.1/tablib/formats/_yaml.py
+@@ -13,12 +13,14 @@ extensions = ('yaml', 'yml')
+ def export_set(dataset):
+ """Returns YAML representation of Dataset."""
+ 
+-return yaml.safe_dump(dataset._package(ordered=False))
++return yaml.safe_dump(dataset._package(ordered=False),
++  default_flow_style=None)
+ 
+ 
+ def export_book(databook):
+ """Returns YAML representation of Databook."""
+-return yaml.safe_dump(databook._package(ordered=False))
++return yaml.safe_dump(databook._package(ordered=False),
++  default_flow_style=None)
+ 
+ 
+ def import_set(dset, in_stream):
diff -Nru python-tablib-0.12.1/debian/patches/series 
python-tablib-0.12.1/debian/patches/series
--- python-tablib-0.12.1/debian/patches/series  1969-12-31 19:00:00.0 
-0500
+++ python-tablib-0.12.1/debian/patches/series  2019-08-08 18:05:44.0 
-0400
@@ -0,0 +1 @@
+fix_pyyaml_default_flow_style.patch

Bug#934171: sagemath: FTFBS with libreadline8

[John Scott]

Control: block -1 by 933021

The FTBFS / 22,979 test failures are due to #933021, and until it's fixed I 
don't think it can be determined whether libreadline8 might cause them too.

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

Bug#934267: kconfig: CVE-2019-14744

[Moritz Mühlenhoff]

On Thu, Aug 08, 2019 at 11:29:25PM +0200, Salvatore Bonaccorso wrote:
> Source: kconfig
> Version: 5.54.0-1
> Severity: grave
> Tags: patch security upstream
> Justification: user security hole
> Control: found -1 5.28.0-2
> Control: clone -1 -2
> Control: reassign -2 src:kde4libs 4:4.14.38-3
> Control: retitle -2 kde4libs: CVE-2019-14744
> Control: found -2 4:4.14.26-2
> 
> Hi,
> 
> The following vulnerability was published for kconfig.
> 
> CVE-2019-14744[0]:
> | In KDE Frameworks KConfig before 5.61.0, malicious desktop files and
> | configuration files lead to code execution with minimal user
> | interaction. This relates to libKF5ConfigCore.so, and the mishandling
> | of .desktop and .directory files, as demonstrated by a shell command
> | on an Icon line in a .desktop file.

JFTR, I've prepared updates for Stretch/Buster, which should go out tomorrow.

Cheers,
Moritz

Bug#934270: Homepage: requires log in

[Christoph Biedl]

Package: pristine-lfs
Version: 20190717.0-1
Severity: minor

Dear Maintainer,

trying to learn more about this new package - possibly it could replace
pristine-tar? - I followed the Homepage: URL to
 but unfortunately
that page does not provide any information without logging in.

Can you please rectify the situation?

Cheers,
Christoph



signature.asc
Description: PGP signature

Bug#934269: lavacli: default_flow_style changed in newer pyyaml

[Mathieu Trudel-Lapierre]

Package: lavacli
Version: 0.9.7-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

pyyaml 5.2.1 appears to have some changes in the default flow style used.
Rather than representing sequences and dicts similary to python, it now
defaults to printing them in longform [1]:

 - item 1
 - item 2

etc.

I've written a quick and heavyhanded patch to add default_flow_style=None
to all of the calls to yaml.dump() that otherwise don't include options, but
that might not be the best solution. Maybe upstream would rather fix the tests?

[1] https://github.com/yaml/pyyaml/issues/265


*** /tmp/tmpton7Uz/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all calls
to yaml.dump() include default_flow_style=None, to retain previous behavior
that is checked for in tests, unless it's already otherwise specified.


Thanks for considering the patch.


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

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch 
lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
--- lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
1969-12-31 19:00:00.0 -0500
+++ lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
2019-08-08 16:56:08.0 -0400
@@ -0,0 +1,185 @@
+Index: lavacli-0.9.7/lavacli/commands/aliases.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/aliases.py
 lavacli-0.9.7/lavacli/commands/aliases.py
+@@ -99,7 +99,7 @@ def handle_list(proxy, options, _):
+ if options.output_format == "json":
+ print(json.dumps(aliases))
+ elif options.output_format == "yaml":
+-print(yaml.dump(aliases).rstrip("\n"))
++print(yaml.dump(aliases, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Aliases:")
+ for alias in aliases:
+@@ -112,7 +112,7 @@ def handle_show(proxy, options, config):
+ if options.output_format == "json":
+ print(json.dumps(alias))
+ elif options.output_format == "yaml":
+-print(yaml.dump(alias).rstrip("\n"))
++print(yaml.dump(alias, default_flow_style=None).rstrip("\n"))
+ else:
+ if config["version"] >= (2019, 5):
+ print("name   : %s" % alias["name"])
+Index: lavacli-0.9.7/lavacli/commands/device_types.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/device_types.py
 lavacli-0.9.7/lavacli/commands/device_types.py
+@@ -260,7 +260,7 @@ def handle_aliases(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(aliases))
+ elif options.output_format == "yaml":
+-print(yaml.dump(aliases).rstrip("\n"))
++print(yaml.dump(aliases, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Aliases:")
+ for alias in aliases:
+@@ -287,7 +287,7 @@ def handle_list(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(device_types))
+ elif options.output_format == "yaml":
+-print(yaml.dump(device_types).rstrip("\n"))
++print(yaml.dump(device_types, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Device-Types:")
+ for dt in device_types:
+@@ -301,7 +301,7 @@ def handle_show(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(dt))
+ elif options.output_format == "yaml":
+-print(yaml.dump(dt).rstrip("\n"))
++print(yaml.dump(dt, default_flow_style=None).rstrip("\n"))
+ else:
+ print("name: %s" % dt["name"])
+ print("description : %s" % dt["description"])
+Index: lavacli-0.9.7/lavacli/commands/devices.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/devices.py
 lavacli-0.9.7/lavacli/commands/devices.py
+@@ -337,7 +337,7 @@ def handle_list(proxy, options, config):
+ if options.output_format == "json":
+ print(json.dumps(devices))
+ elif options.output_format == "yaml":
+-print(yaml.dump(devices).rstrip("\n"))
++print(yaml.dump(devices, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Devices:")
+ for device in devices:
+@@ -386,7 +386,7 @@ def handle_show(proxy, options, config):
+ if options.output

Bug#869733: ispell.1X: Fix some formatting and textual matters

[Robert Luberda]

Bjarni Ingi Gislason writes:

Hi,

> Package: ispell
> Version: 3.4.00-6
> Severity: minor
> 
>   The patch is in the attachment.

Sorry for the delay, Thanks for the patch, I've just applied it in git,
see [1].

As your patch was apparently for the older version of ispell (3.3.02),
some of your corrections were already there. Additionally I've changed
your fix for:
  "-munching a normal-sized dictionary (15K roots, 45K expanded words)"
from:
  "+munching a normal-sized dictionary (15\ kB roots, 45\ kB expanded
words)"
to:
  "+munching a normal-sized dictionary (15000 roots, 45000 expanded words)"
as K meaning just "kilo", i.e. "thousand", here seemed more sensible to me.

[1]
https://salsa.debian.org/debian/ispell/blob/7416a731b3efb8586bca56099194e2fc66996399/debian/patches/0039-Man-page-issues-fix.patch

Regards,
robert

Bug#934267: kconfig: CVE-2019-14744

[Salvatore Bonaccorso]

Source: kconfig
Version: 5.54.0-1
Severity: grave
Tags: patch security upstream
Justification: user security hole
Control: found -1 5.28.0-2
Control: clone -1 -2
Control: reassign -2 src:kde4libs 4:4.14.38-3
Control: retitle -2 kde4libs: CVE-2019-14744
Control: found -2 4:4.14.26-2

Hi,

The following vulnerability was published for kconfig.

CVE-2019-14744[0]:
| In KDE Frameworks KConfig before 5.61.0, malicious desktop files and
| configuration files lead to code execution with minimal user
| interaction. This relates to libKF5ConfigCore.so, and the mishandling
| of .desktop and .directory files, as demonstrated by a shell command
| on an Icon line in a .desktop file.


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-14744
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14744
[1] https://kde.org/info/security/advisory-20190807-1.txt
[2] 
https://cgit.kde.org/kconfig.git/commit/?id=5d3e71b1d2ecd2cb2f910036e614ffdfc895aa22
[3] 
https://cgit.kde.org/kdelibs.git/commit/?id=2c3762feddf7e66cf6b64d9058f625a715694a00

Regards,
Salvatore

Bug#934246: munin-node doesn't start any more after upgrade to buster

[devel]

Hello Paolo,

thank you for your bug report!


Am Thu, 08 Aug 2019 19:36:08 +0200
schrieb Paolo Benvenuto :

> I had munin and munin-node working well on stretch, after upgrading to buster
> munin-node service doesn't start any more.

That sounds unpleasant.

Did you already find a reason for this behaviour?
What is the result of running "munin-node" directly (as root)?

Cheers,
Lars

Bug#934266: ITP: whawty-auth -- simple file based authentication suite

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: whawty-auth
  Version : 0.2
  Upstream Author : whawty contributors (see AUTHORS file)
* URL : https://github.com/whawty/auth/blob/master/AUTHORS
* License : BSD-3
  Programming Lang: Go
  Description : simple file based authentication suite

whawty.auth is a simple file based authentication suite. Its store uses flat
files containing password hashes. These hashes are currently based on scrypt but
the algorithm can be upgraded to newer/stronger formats on the fly. To find out
more about the storage backend read [SCHEMA.md].

It is possible to interact with whawty through a simple web UI, or a Unix socket
implementing the saslauthd protocol; a PAM module is provided using the socket.

[SCHEMA.md]: https://github.com/whawty/auth/blob/master/doc/SCHEMA.md

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1Mk54RHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7Mu5Bw//dZTmXgHl4jJm6/cLO0K9IigH3TjrPyW8
yL89mJrUC4b7QjOfd9v5u7VzutIw/TK/DQ8gZHxbAIuAcvbSeWNGBibvs0ZIajw1
S8cWLH345kxf/vQxRjwdkxs3JsHFlqLnkrziJk3Q8JCAILvVo/4MHOeMC4Pcx/gO
NccibaHhVdG1xLgDKaeX97jR/xGiHFaXaJvPmFqf7qwFpcmXCUmdcrQftVFlzpxz
TCx0VlnwLh+nRJ5HMbAXWVi/+eClqqMPLmDOHyqHQsbbihs4boHp02D7Z44JLHN6
g9ankGH2t4PT2vM9f7pHazYfyp/O/AaNSHQMccBpQA6so7r+ZLh1bBhVY15VHZuF
0anJxAVEGjLF7Z+ix64xc6agXnqGxG1CyEjzdVOqnS06DtVlddc8p7WvMXdFFvgw
3and4nHt/P5FlUt/CvzG3merQkNThL3b62TMWwqCzekrfzgGxPHv5WmtBXUwdFGY
nF2khXtaicORawUWA68q+3rc/z5vpMEhEIThgipugvqbS0V8p6NZkt0u5Lxuo/2f
hHrk8JD9e2pWKQNLBuRxrG2z64m56HXXVMdGW3cB/HZe3B6nSzigYFEHdFwy1TmN
VA3uYMQfSWv209sKgPCu747y99YCj3m0gt62XIMvRTk+DfSXpA/KRb1YkTYFkViT
Jrlruk3qYuY=
=jBSi
-END PGP SIGNATURE-

Bug#934265: qtbase5-dev: different archs ship different version of Qt-logo.png

[ydirson]

Package: qtbase5-dev
Version: 5.11.3+dfsg1-2+b1
Severity: serious

Unpacking qtbase5-dev:i386 (5.11.3+dfsg1-2+b1) over (5.11.3+dfsg1-2) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-01jgzV/14-qtbase5-dev_5.11.3+dfsg1-2+b1_i386.deb 
(--unpack):
 trying to overwrite shared 
'/usr/share/qt5/doc/global/template/images/Qt-logo.png', which is different 
from other instances of package qtbase5-dev:i386
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

Bug#934254: Time to provide python3-mne package

[Yaroslav Halchenko]

FYI -- pushed 

(git)hopa:~exppsy/mne-python[debian-0.18.x]git
$> git push  salsa debian-0.18.x upstream/0.18.1+dfsg pristine-tar
Enumerating objects: 1576, done.
Counting objects: 100% (1131/1131), done.
Delta compression using up to 4 threads
Compressing objects: 100% (603/603), done.
Writing objects: 100% (674/674), 844.52 KiB | 8.98 MiB/s, done.
Total 674 (delta 387), reused 207 (delta 67)
remote: Resolving deltas: 100% (387/387), completed with 369 local 
objects.
remote: 
remote: To create a merge request for pristine-tar, visit:
remote:   
https://salsa.debian.org/med-team/python-mne/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar
remote: 
remote: To create a merge request for debian-0.18.x, visit:
remote:   
https://salsa.debian.org/med-team/python-mne/merge_requests/new?merge_request%5Bsource_branch%5D=debian-0.18.x
remote: 
To salsa.debian.org:med-team/python-mne
   b2d5d2b87..471ad3a79  pristine-tar -> pristine-tar
 * [new branch]  debian-0.18.x -> debian-0.18.x
 * [new tag] upstream/0.18.1+dfsg -> upstream/0.18.1+dfsg


current bottleneck is mayavi2 -- there is no python3 bindings yet (filed a
bugreport), and 0.18.x of python-mne is python3 only.

we could patch up to make pytest not error out upon mayavi2
non-availability but not sure if there would be no other gotchas.

if someone finds time to push it forward -- would be great

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#934264: Please update (4.6.2?) and provide/switch to python3

[Yaroslav Halchenko]

Package: mayavi2
Version: 4.5.0-1
Severity: normal

4.5.0 still causes segfaults for me (while trying to build/test python-mne
package).  I could not get to upstream's download page for mayavi2 (server bogs
out), but conda seems to have 4.6.2 https://anaconda.org/anaconda/mayavi  so I 
guess
it is out there.

Also a new version of python-mne (0.18.x) already dropped python2 support, so
we need mayavi being available in python3. ATM mayavi2 seems to provide only
python2. Given that python2 is going away you might as well just switch to
provide python3 bindings only (but ideally both if only for a bit longer to
smoothen transition)

Cheers and thanks in advance

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mayavi2 depends on:
ii  libc6 2.28-8
ii  libjs-jquery  3.3.1~dfsg-1
ii  python2.7.16-1
ii  python-apptools   4.4.0-3
ii  python-configobj  5.0.6-3
ii  python-envisage   4.4.0-1
ii  python-numpy [python-numpy-abi9]  1:1.16.2-1
ii  python-pkg-resources  40.8.0-1
ii  python-traits 4.6.0-1+b2
ii  python-traitsui   4.5.1-1
ii  python-vtk6   6.3.0+dfsg2-2+b5
ii  python-wxgtk3.0   3.0.2.0+dfsg-8

mayavi2 recommends no packages.

Versions of packages mayavi2 suggests:
ii  ipython   5.8.0-1
ii  python-scipy  1.1.0-7

-- debconf-show failed

Bug#934230: unattended-upgrades: Prevents regular usage of package tools

[Bálint Réczey]

Control: tags -1 moreinfo

Hi Francisco,

Francisco M Neto  ezt írta (időpont: 2019. aug.
8., Cs, 14:09):
>
> Package: unattended-upgrades
> Severity: important
>
> Dear Maintainer,
>
> While I do understand the importance of having upgrades being
> installed automatically to keep the system updated, unatended-upgrades
> is blocking my own attempts to upgrade, install or remove packages.
>
> Its process runs automatically, so more often than not, when I try to
> do any of the mentioned tasks I'm confronted with the following
> message:
>
> mosca: /home/fmneto#> sudo apt upgrade
> E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource 
> temporarily unavailable)
> E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is 
> another process using it?
>
> Taking a careful look, the following processes are running that are
> using those locks:
>
> mosca: /home/fmneto#> ps aux | grep apt
> root  7209  0.0  0.0   2388   756 ?Ss   08:24   0:00 /bin/sh 
> /usr/lib/apt/apt.systemd.daily install
> root  7221  0.0  0.0   2388  1520 ?S08:24   0:00 /bin/sh 
> /usr/lib/apt/apt.systemd.daily lock_is_held install
> fmneto   10803  0.0  0.0   6076   824 pts/0S+   08:28   0:00 grep apt
>
> I take two issues with this.
>
> 1. Although the task being run is listed as "daily", this lock is in
> place no matter what the time I try to run apt.
> 2. Because of this I need to kill those processes and remove the locks
> in order to be able to actually perform the tasks I need
> (e.g. install/remove packages)
>
> As I said before, I completely understand the necessity and usefulness
> of having unattended upgrades, but as of now I prefer to remove the
> package and upgrade my system manually. This way at least I can
> install packages when I actually need to.
>
> I propose that some kind of countermeasure is implemented in dpkg,
> making it possible for the processes related to unattended upgrades to
> abort their actions and release the locks when it detects that dpkg is
> trying to perform some task that was started by the user.

Unattended-upgrades is expected to run only for a few seconds per day
and should not block installation of packages when it is not running.
Could you please check if it was stuck?
You can use pstree and check the logs in /var/log/unattended-upgrades/ .

Thanks,
Balint

Bug#934263: RM: pyrrd -- ROM; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

No upstream activity at https://launchpad.net/pyrrd since the last package
upload. No Python 3 support. RFH #876679.

Reverse deps checked by dak rm -Rnb python-pyrrd

Bug#934066: sysv-rc: /etc/init.d/README is misleading wrt *.sh

[Dmitry Bogatov]

[2019-08-06 18:36] Adam Borowski 
> Package: sysv-rc
> Version: 2.95-4
> Severity: wishlist
>
> Hi!
> The documentation in /etc/init.d/README talks a lot about *.sh files in that
> dir, in a way that suggests that's the way regular init scripts should be
> named.  Could you please disambiguate?
>
> (Apologies for not submitting patches myself -- I'm on a phoney PDA until
> mid August.)

Copy-editing is welcome.

From 949cb25e210d8f896068a018223c8cc2d78ac98f Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Tue, 6 Aug 2019 22:41:56 +
Subject: [PATCH] Do not imply in README that init scripts must have extension

Avoid refererring to init scripts using /etc/init.d/*.sh wildcard,
most of them do not have (and should not!) extension.

Closes: #934066
---
 debian/src/sysv-rc/doc/init.d-README | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/src/sysv-rc/doc/init.d-README 
b/debian/src/sysv-rc/doc/init.d-README
index 8477036a..9d2d1428 100644
--- a/debian/src/sysv-rc/doc/init.d-README
+++ b/debian/src/sysv-rc/doc/init.d-README
@@ -20,15 +20,15 @@ installed you can probably read it at
 Some more detailed information can also be found in the files in the
 /usr/share/doc/sysv-rc directory.
 
-Debian Policy dictates that /etc/init.d/*.sh scripts must work properly
-when sourced.  The following additional rules apply:
+Debian Policy dictates that scripts in /etc/init.d/ must work properly when
+sourced.  The following additional rules apply:
 
-* /etc/init.d/*.sh scripts must not rely for their correct functioning
+* /etc/init.d/* scripts must not rely for their correct functioning
   on their being sourced rather than executed.  That is, they must work
   properly when executed too. They must include "#!/bin/sh" at the top.
   This is useful when running scripts in parallel.
 
-* /etc/init.d/*.sh scripts must conform to the rules for sh scripts as
+* /etc/init.d/* scripts must conform to the rules for sh scripts as
   spelled out in the Debian policy section entitled "Scripts" (§10.4).
 
 Use the update-rc.d command to create symbolic links in the /etc/rc?.d
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#730824: initscripts: please document INIT_VERBOSE in /etc/default/rcS (and/or rcS (5) )

[Thomas Viehweger]

>> I wondered why some messages don't appear even if I had set VERBOSE=yes
>> Looking at the code I found the solution (setting INIT_VERBOSE to yes).
>>
>> What about adding the following lines (or similar) to /etc/default/rcS:
>>
>> # be verbose even if kernel commandline contains "quiet"
>> #INIT_VERBOSE=yes
> Yes, this definitely can be done. But I'd ask, whether INIT_VERBOSE
> variable is actually needed.
>
> We have $VERBOSE variable, that defaults to "yes", can be set in
> /etc/default/rcS and may be modified according to kernel option. And
> also we have $INIT_VERBOSE, that overrides $VERBOSE independent of
> kernel option.
>
> Isn't it is too much complexity for such simple thing? Why would anyone
> desire non-verbose boot?

Yes, it is very complex.

I don't want to see regular kernel messages, only irregular. So I use the 
"quiet" parameter.

While debugging enormous shutdown delays I found the solution with INIT_VERBOSE 
even
if it was not documented and only deep buried in /lib/init/vars.sh.

The point for this bug report was to just document this variable.

Bug#934065: sysv-rc: please include/refer to skeleton in /etc/init.d/README

[Dmitry Bogatov]

[2019-08-06 18:17] Adam Borowski 
> Package: sysv-rc
> Version: 2.95-4
> Severity: wishlist
>
> [A different approach to #912651]
>
> As you decided to drop the example init script from the live dir, could you
> please link to appropriate documentation from /etc/init.d/README (aka
> /usr/share/doc/sysv-rc/init.d-README).  That file talks about LSB headers
> but nothing about how to actually write an init script.
>
> Or alternatively, edit the file to include such a description inline.
>
> I think it would be nice to discuss both the init-d-script approach and the
> traditinal skeleton, too.

Copy-editing is welcome. You may want to take a look on 82441288 on my
improvements (I believe) of init-d-script(5).

Remove requirements that init.d scripts work sources. They usually
don't, and it is not required by Policy since 3.8.1

From 5d6f6d1121ec7882e227e91242f42c752152b0d1 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 7 Aug 2019 15:06:09 +
Subject: [PATCH] Update /etc/init.d/README to current practices

Closes: #934065
---
 debian/src/sysv-rc/doc/init.d-README | 44 ++--
 1 file changed, 3 insertions(+), 41 deletions(-)

diff --git a/debian/src/sysv-rc/doc/init.d-README 
b/debian/src/sysv-rc/doc/init.d-README
index 9d2d1428..793bbffc 100644
--- a/debian/src/sysv-rc/doc/init.d-README
+++ b/debian/src/sysv-rc/doc/init.d-README
@@ -17,44 +17,6 @@ installed you can probably read it at
 
 file://localhost/usr/share/doc/debian-policy/
 
-Some more detailed information can also be found in the files in the
-/usr/share/doc/sysv-rc directory.
-
-Debian Policy dictates that scripts in /etc/init.d/ must work properly when
-sourced.  The following additional rules apply:
-
-* /etc/init.d/* scripts must not rely for their correct functioning
-  on their being sourced rather than executed.  That is, they must work
-  properly when executed too. They must include "#!/bin/sh" at the top.
-  This is useful when running scripts in parallel.
-
-* /etc/init.d/* scripts must conform to the rules for sh scripts as
-  spelled out in the Debian policy section entitled "Scripts" (§10.4).
-
-Use the update-rc.d command to create symbolic links in the /etc/rc?.d
-as appropriate. See that man page for more details.
-
-All init.d scripts are expected to have a LSB style header documenting
-dependencies and default runlevel settings.  The header look like this
-(not all fields are required):
-
-### BEGIN INIT INFO
-# Provides:  skeleton
-# Required-Start:$remote_fs $syslog
-# Required-Stop: $remote_fs $syslog
-# Should-Start:  $portmap
-# Should-Stop:   $portmap
-# X-Start-Before:nis
-# X-Stop-After:  nis
-# Default-Start: 2 3 4 5
-# Default-Stop:  0 1 6
-# X-Interactive: true
-# Short-Description: Example initscript
-# Description:   This file should be used to construct scripts to be
-#placed in /etc/init.d.
-### END INIT INFO
-
-More information on the format is available from insserv(8).  This
-information is used to dynamicaly assign sequence numbers to the
-boot scripts and to run the scripts in parallel during the boot.
-See also /usr/share/doc/insserv/README.Debian.
+Required behaviour and arguments of init script are described in Policy, but
+for usual cases it is enough to use init-d-script(5). More information about
+LSB headers (mentioned in init-d-script manual) is available in insserv(8).
\ No newline at end of file


-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#934065: sysv-rc: please include/refer to skeleton in /etc/init.d/README

[Dmitry Bogatov]

[2019-08-06 18:17] Adam Borowski 
> Package: sysv-rc
> Version: 2.95-4
> Severity: wishlist
>
> [A different approach to #912651]
>
> As you decided to drop the example init script from the live dir, could you
> please link to appropriate documentation from /etc/init.d/README (aka
> /usr/share/doc/sysv-rc/init.d-README).  That file talks about LSB headers
> but nothing about how to actually write an init script.
>
> Or alternatively, edit the file to include such a description inline.
>
> I think it would be nice to discuss both the init-d-script approach and the
> traditinal skeleton, too.

Copy-editing is welcome. You may want to take a look on 82441288 on my
improvements (I believe) of init-d-script(5).

Remove requirements that init.d scripts work sources. They usually
don't, and it is not required by Policy since 3.8.1

From 5d6f6d1121ec7882e227e91242f42c752152b0d1 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 7 Aug 2019 15:06:09 +
Subject: [PATCH] Update /etc/init.d/README to current practices

Closes: #934065
---
 debian/src/sysv-rc/doc/init.d-README | 44 ++--
 1 file changed, 3 insertions(+), 41 deletions(-)

diff --git a/debian/src/sysv-rc/doc/init.d-README 
b/debian/src/sysv-rc/doc/init.d-README
index 9d2d1428..793bbffc 100644
--- a/debian/src/sysv-rc/doc/init.d-README
+++ b/debian/src/sysv-rc/doc/init.d-README
@@ -17,44 +17,6 @@ installed you can probably read it at
 
 file://localhost/usr/share/doc/debian-policy/
 
-Some more detailed information can also be found in the files in the
-/usr/share/doc/sysv-rc directory.
-
-Debian Policy dictates that scripts in /etc/init.d/ must work properly when
-sourced.  The following additional rules apply:
-
-* /etc/init.d/* scripts must not rely for their correct functioning
-  on their being sourced rather than executed.  That is, they must work
-  properly when executed too. They must include "#!/bin/sh" at the top.
-  This is useful when running scripts in parallel.
-
-* /etc/init.d/* scripts must conform to the rules for sh scripts as
-  spelled out in the Debian policy section entitled "Scripts" (§10.4).
-
-Use the update-rc.d command to create symbolic links in the /etc/rc?.d
-as appropriate. See that man page for more details.
-
-All init.d scripts are expected to have a LSB style header documenting
-dependencies and default runlevel settings.  The header look like this
-(not all fields are required):
-
-### BEGIN INIT INFO
-# Provides:  skeleton
-# Required-Start:$remote_fs $syslog
-# Required-Stop: $remote_fs $syslog
-# Should-Start:  $portmap
-# Should-Stop:   $portmap
-# X-Start-Before:nis
-# X-Stop-After:  nis
-# Default-Start: 2 3 4 5
-# Default-Stop:  0 1 6
-# X-Interactive: true
-# Short-Description: Example initscript
-# Description:   This file should be used to construct scripts to be
-#placed in /etc/init.d.
-### END INIT INFO
-
-More information on the format is available from insserv(8).  This
-information is used to dynamicaly assign sequence numbers to the
-boot scripts and to run the scripts in parallel during the boot.
-See also /usr/share/doc/insserv/README.Debian.
+Required behaviour and arguments of init script are described in Policy, but
+for usual cases it is enough to use init-d-script(5). More information about
+LSB headers (mentioned in init-d-script manual) is available in insserv(8).
\ No newline at end of file


-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#672361: bootlogd: escape sequences should be filtered out

[Dmitry Bogatov]

control: tags -1 +upstream

[2019-08-07 05:13] Adam Borowski 
> [...]
> > a /var/log/boot.log file is
> > generated where nothing is filtered out, so that the file is readable
> > with "cat" or "less" (and text is colored).
>
> I don't think files in /var/log/ should be anything but plain text -- at
> least unless colorized-logs becomes essential :þ and/or less defaults to
> -R.  But until a solution is implemented, I agree that leaving binaryish
> control codes intact is better than corrupting them.

Jesse, there seems to be demand on turning-off escape sequence filtering
in bootlogd. Can you please make it configurable?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#934261: speech-dispatcher and speechd-el client error

[Samuel Thibault]

Source: speechd-el
Version: 2.8-2
Severity: important

Hello,

loredana, le mar. 06 août 2019 14:30:39 +, a ecrit:
> I am trying to use the emacs client for speech-dispatehcer, but I get an 
> error:
> 
> ssip-connection-error: (file-error make client process failed no such
> file or directory :name speechd :family local :remote
> /home/user/.speech-dispatcher/speechd.sock)
> 
> Indeed, the .speech-dispatcher directory does not exist.

[...]

Raphaël POITEVIN a ecrit:
> Check that path:
> /run/user//speech-dispatcher
> create an symbolink link into /home/user/.speech-dispatcher

[...]

loredana a ecrit:
> Just wonder. Should such a symbolick link be added automatically when
> installing the speech-dispatcher package? It could save time and some
> frustration to people less stubborn than me...

Rather, speechd-el should be taught to use the new place.  Anybody out
here to help working on the lisp speechd.el script, to make it try not
only $SPEECHD_SOCK, $XDG_RUNTIME_DIR/speech-dispatcher/speechd.sock,
and ~/.speech-dispatcher/speechd.sock, but also
/run/user//speech-dispatcher/speechd.sock?

Samuel

Bug#934262: RM: pylogsparser -- RoQA; orphaned; dead upstream; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

http://www.wallix.org/pylogsparser-project/ is dead.
https://pypi.org/project/pylogsparser/ has a newer version than in the package
but still 7 years old.

Reverse deps checked by dak rm -Rnb python-logsparser

Bug#934260: RM: pykickstart -- ROM; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

The package is 5 years old, the new version at
https://github.com/dcantrell/pykickstart supports Python 3.

Reverse deps checked by dak rm -Rnb python-pykickstart

Bug#933753: fixed in mesa 19.1.4-1

[Rigas, Evangelos]

On Thu, 08 Aug 2019 05:10:03 + Timo Aaltonen 
wrote:
> Source: mesa
> Source-Version: 19.1.4-1
> 
> We believe that the bug you reported is fixed in the latest version
of
> mesa, which is due to be installed in the Debian FTP archive.
> 

I tested the new version from unstable and I can confirm that it works.

Thanks,

Evangelos

Bug#913481: confirm

[Axel Beckert]

Hi Alexander,

Alexander Dahl wrote:
> I suspect the problem being the use of 'fallocate' and 'f2fs'. man
> mkswap(8) states this:
> 
>Note  that  a swap file must not contain any holes.  Using cp(1)
> to create the file is not
>acceptable.  Neither is use of fallocate(1) on  file  systems
> that  support  preallocated
>files, such as XFS or ext4, or on copy-on-write filesystems like
> btrfs.  It is recommended
>to use dd(1) and /dev/zero in these cases.  Please read notes
> from swapon(8) before adding
>a swap file to copy-on-write filesystems.

Thanks for these hints!

> Hope that helps to fix the package?!

Well, it helps to decide to drop debian/patches/fallocate.patch.

I though never ran into this myself (and wasn't aware of that comment
in mkswap). I also never came across a Raspbian using F2FS so far
although the idea sounds quite obvious.

Will drop that patch with the next upload to Debian Unstable. That
won't fix it for Debian/Raspbian Buster, though, but I might be able
to get it into a stable update.

It's though interesting to see that this patch was in Debian Stretch
and Raspbian Stretch since January 2017 and the first bug report
showed up in late 2018, i.e. nearly two years and a stable release
later, especially since ext4 is said to be affected. (This is no
accusation but rather an explanation why I so far considered this to
be a rather exotic issue.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#934259: RM: epsilon -- ROM; no Python 3 support and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

No Python 3 support even in the new upstream at
https://github.com/twisted/epsilon

The only reverse dep is python-axiom, whose RM bug is #934176.

Reverse deps checked by dak rm -Rnb python-epsilon

Bug#934250: Solved, I think.

[Charles Curley]

On Thu, 08 Aug 2019 18:06:04 +
"Debian Bug Tracking System"  wrote:

> Thank you for filing a new Bug report with Debian.

More information.

1) This does not appear to be a problem with packagekit, but with
   systemd. Removing packaged from the system appears to have solved the
   problem for apt, but not for apache.

2) After trying many possible fixes, I finally rebooted. That appears
   to have solved the problem. Indeed, it appears to have solved a
   problem which *shouldn't* be related, an inability of HPLIP to find
   my printer.

Systemd is turning out to be the kudzu of Linux. It egregiously
violates the Unix precept of "do one thing and do it very well."

It should not be necessary to reboot to solve Linux
problems.

Thank you.

-- 
"When we talk of civilization, we are too apt to limit the meaning of
the word to its mere embellishments, such as arts and sciences; but
the true distinction between it and barbarism is, that the one
presents a state of society under the protection of just and
well-administered law, and the other is left to the chance government
of brute force."
- The Rev. James White, Eighteen Christian Centuries, 1889
Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
https://charlescurley.com

Bug#913481: confirm

[Alexander Dahl]

Hello,

I can confirm this problem for Raspbian 10 (buster, after upgrading from
9, stretch) on a F2FS rootfs. Deleting /var/swap, creating it with dd
from /dev/zero and manually mkswap it, solves the problem, the service
starts again then.

swapon failed before with the aforementioned error in kernellog:

[Thu Aug  8 21:39:30 2019] swapon: swapfile has holes

I suspect the problem being the use of 'fallocate' and 'f2fs'. man
mkswap(8) states this:

   Note  that  a swap file must not contain any holes.  Using cp(1)
to create the file is not
   acceptable.  Neither is use of fallocate(1) on  file  systems
that  support  preallocated
   files, such as XFS or ext4, or on copy-on-write filesystems like
btrfs.  It is recommended
   to use dd(1) and /dev/zero in these cases.  Please read notes
from swapon(8) before adding
   a swap file to copy-on-write filesystems.

Hope that helps to fix the package?!

Kind regards
Alex



signature.asc
Description: OpenPGP digital signature

Bug#923717: closed by Domenico Andreoli (Bug#923717: fixed in dwarves-dfsg 1.15-1)

[Domenico Andreoli]

Control: close -1

On Thu, Aug 08, 2019 at 09:33:18PM +0200, Paul Gevers wrote:
> Hi Domenico, [also in To: to prevent the time lag]
> 
> On 08-08-2019 00:35, Domenico Andreoli wrote:
> >> On 30-07-2019 19:09, Debian Bug Tracking System wrote:
> >>>* Autopkgtest on libc-bin-dbgsym instead of dwarves-dbgsym. Closes: 
> >>> #923717.
> >>
> >> Unless I am very much mistaken, this is not really fixing the issue. The
> >> problem is that the unstable debug archive isn't available during
> >> migration testing (that's bug #917528, to be fixed in debci). Hence, the
> >> test will still fail if it needs the libc-bin-dbgsym package from
> >> unstable. Please add the skip-not-installable restriction as I
> >> recommended in my initial bug report.
> > 
> > The "test" (much to be improved) just needs debug symbols for trying
> > to analyze some binary. It's very simple test to prove that pahole does
> > not die badly like when DWARF-4 has been introduced.
> > 
> > At the moment does not really matter if such symbols are coming from
> > testing or unstable as long as they match the version of the binary
> > being analyzed.
> > 
> > I thought to untangle a little bit the situation in using some binary
> > different from dwarves itself, in that:
> > 
> >  dwarves/unstable + dwarves-dbgsym/testing => unsatisfiable
> >  
> > Do you still think that skip-not-installable is better? Why?
> 
> So this libc-bin-dbgsym has no relation with dwarves? Than I guess it

Indeed it has not any.

> will work as you can always install the version from testing and no
> relation will pull in the version from unstable. If that's the case,
> just close the bug again. Otherwise, skip-not-installable *on top of*
> other improvements will just mean that *if* any package is unsatisfiable
> than the test is marked as skipped and as such adds a neutral result to
> the final outcome.

Thanks, I'll consider it.

Dom

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

Bug#934093: Orca becomes unresponsive when running reportbug

[Samuel Thibault]

This can be reproduced very easily with the attached script, which just
imports gtk and sleeps. Importing gtk makes it register to at-spi, but
since it doesn't run the gtk loop, it doesn't answer at-spi requests.

Samuel
#!/usr/bin/python3

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk

import time
time.sleep(60)

Bug#934093: Orca becomes unresponsive when running reportbug

[Samuel Thibault]

Hello,

thom...@fastmail.cn, le mar. 06 août 2019 18:31:07 -0400, a ecrit:
> When running reportbug from a terminal in debian, Orca becomes unresponsive 
> for a long while. More specifically, I am using the mate-terminal. 
> Eventually, it starts reading but it is after almost a minute. I am using the 
> text interface. Also, this was reproduced in the initial setup.

It looks like reportbug is very briefly running some gui thingy that
disappears very quickly but Orca still tries to contact. One way to work
around it is to use

DISPLAY= reportbug

to disable any gui use in reportbug.

Samuel

Bug#927335: r-base breaks 9 autopkgtests

[Dirk Eddelbuettel]

On 8 August 2019 at 20:38, Paul Gevers wrote:
| Hi Graham, Dirk,
| 
| On 08-08-2019 19:17, Graham Inggs wrote:
| > I've prepared the attached list of Breaks to be added to the r-base-core
| > binary package.
| > 
| > I believe these will ease migration.  Paul, do you concur?
| 
| Adding the breaks helps the migration, yes.

Am I understanding this correctly in that the Breaks: block is temporary and
once the (current) migration is complete, I should remove that block?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#683163: xmlto fail to convert example docbook to PDF (LaTeX Error, missing \item?)

[Hilmar Preuße]

Control: severity 683163 important
Control: merge 683163 170477

Am 29.07.2012 um 13:01 teilte Petter Reinholdtsen mit:

Hi,

> I ran into a problem with the PDF suport in xmlto.  I see the problem
> with a larger file (the freeculture.xml file available from
> https://github.com/petterreinholdtsen/free-culture-lessig >, but
> was also able to see it with an example file available from
>  https://trac.v2.nl/export/7884/v2fo/trunk/v2fo/lib/docbook/test/book.xml >.
> 
Known issue, not solved yet. It is 170477 and friends. I'm merging your bug.

Unfortunately nobody did some substantial work on the issue for now. So
we don't even know if this is an issue in passivetex or xmltex. In the
first case there is no hope b/c it was maintained by Sebastian Rahtz and
nobody took over the maintainer-ship. I'll see, whether I can invest
some time into investigation in the next days.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#923717: closed by Domenico Andreoli (Bug#923717: fixed in dwarves-dfsg 1.15-1)

[Paul Gevers]

Hi Domenico, [also in To: to prevent the time lag]

On 08-08-2019 00:35, Domenico Andreoli wrote:
>> On 30-07-2019 19:09, Debian Bug Tracking System wrote:
>>>* Autopkgtest on libc-bin-dbgsym instead of dwarves-dbgsym. Closes: 
>>> #923717.
>>
>> Unless I am very much mistaken, this is not really fixing the issue. The
>> problem is that the unstable debug archive isn't available during
>> migration testing (that's bug #917528, to be fixed in debci). Hence, the
>> test will still fail if it needs the libc-bin-dbgsym package from
>> unstable. Please add the skip-not-installable restriction as I
>> recommended in my initial bug report.
> 
> The "test" (much to be improved) just needs debug symbols for trying
> to analyze some binary. It's very simple test to prove that pahole does
> not die badly like when DWARF-4 has been introduced.
> 
> At the moment does not really matter if such symbols are coming from
> testing or unstable as long as they match the version of the binary
> being analyzed.
> 
> I thought to untangle a little bit the situation in using some binary
> different from dwarves itself, in that:
> 
>  dwarves/unstable + dwarves-dbgsym/testing => unsatisfiable
>  
> Do you still think that skip-not-installable is better? Why?

So this libc-bin-dbgsym has no relation with dwarves? Than I guess it
will work as you can always install the version from testing and no
relation will pull in the version from unstable. If that's the case,
just close the bug again. Otherwise, skip-not-installable *on top of*
other improvements will just mean that *if* any package is unsatisfiable
than the test is marked as skipped and as such adds a neutral result to
the final outcome.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#933147: buster-pu: package libsdl2-image/2.0.4+dfsg1+deb10u1

[Hugo Lefeuvre]

Hi Salvatore,

> > Done! You can find an updated debdiff for buster in attachement. The new
> > debdiff ships CVE-2019-5058.patch which addresses the remaining issue in
> > IMG_xcf.c.
> 
> Is the attachment missing?

Right, attachment is missing! Better now :)

regards,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
diff -Nru libsdl2-image-2.0.4+dfsg1/debian/changelog libsdl2-image-2.0.4+dfsg1/debian/changelog
--- libsdl2-image-2.0.4+dfsg1/debian/changelog	2019-02-03 11:59:26.0 +0100
+++ libsdl2-image-2.0.4+dfsg1/debian/changelog	2019-07-26 22:01:14.0 +0200
@@ -1,3 +1,18 @@
+libsdl2-image (2.0.4+dfsg1-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Multiple security issues (Closes: #932754):
+- CVE-2019-5058: buffer overflow in do_layer_surface (IMG_xcf.c).
+- CVE-2019-5052: integer overflow and subsequent buffer overflow in
+  IMG_pcx.c.
+- CVE-2019-7635: heap buffer overflow in Blit1to4 (IMG_bmp.c).
+- CVE-2019-12216, CVE-2019-12217,
+  CVE-2019-12218, CVE-2019-12219,
+  CVE-2019-12220, CVE-2019-12221,
+  CVE-2019-1, CVE-2019-5051: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).
+
+ -- Hugo Lefeuvre   Fri, 26 Jul 2019 17:01:14 -0300
+
 libsdl2-image (2.0.4+dfsg1-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch
--- libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch	1970-01-01 01:00:00.0 +0100
+++ libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-12218.patch	2019-07-26 22:01:14.0 +0200
@@ -0,0 +1,84 @@
+Description: fix heap buffer overflow issue in IMG_pcx.c
+ Issue known as TALOS-2019-0841, CVE-2019-12218.
+Author: Sam Lantinga 
+Origin: upstream, https://hg.libsdl.org/SDL_image/rev/7453e79c8cdb
+--- a/IMG_pcx.c	2019-07-26 17:35:40.331470589 -0300
 b/IMG_pcx.c	2019-07-26 17:48:45.760965290 -0300
+@@ -98,6 +98,8 @@
+ Uint8 *row, *buf = NULL;
+ char *error = NULL;
+ int bits, src_bits;
++int count = 0;
++Uint8 ch;
+ 
+ if ( !src ) {
+ /* The error message has been set in SDL_RWFromFile */
+@@ -146,14 +148,14 @@
+ bpl = pcxh.NPlanes * pcxh.BytesPerLine;
+ if (bpl > surface->pitch) {
+ error = "bytes per line is too large (corrupt?)";
++goto done;
+ }
+-buf = (Uint8 *)SDL_calloc(SDL_max(bpl, surface->pitch), 1);
++buf = (Uint8 *)SDL_calloc(surface->pitch, 1);
+ row = (Uint8 *)surface->pixels;
+ for ( y=0; yh; ++y ) {
+ /* decode a scan line to a temporary buffer first */
+-int i, count = 0;
+-Uint8 ch;
+-Uint8 *dst = (src_bits == 8) ? row : buf;
++int i;
++Uint8 *dst = buf;
+ if ( pcxh.Encoding == 0 ) {
+ if(!SDL_RWread(src, dst, bpl, 1)) {
+ error = "file truncated";
+@@ -166,14 +168,15 @@
+ error = "file truncated";
+ goto done;
+ }
+-if( (ch & 0xc0) == 0xc0) {
+-count = ch & 0x3f;
+-if(!SDL_RWread(src, &ch, 1, 1)) {
++if ( ch < 0xc0 ) {
++count = 1;
++} else {
++count = ch - 0xc0;
++if( !SDL_RWread(src, &ch, 1, 1)) {
+ error = "file truncated";
+ goto done;
+ }
+-} else
+-count = 1;
++}
+ }
+ dst[i] = ch;
+ count--;
+@@ -205,10 +208,16 @@
+ int x;
+ dst = row + plane;
+ for(x = 0; x < width; x++) {
++if ( dst >= row+surface->pitch ) {
++error = "decoding out of bounds (corrupt?)";
++goto done;
++}
+ *dst = *innerSrc++;
+ dst += pcxh.NPlanes;
+ }
+ }
++} else {
++SDL_memcpy(row, buf, bpl);
+ }
+ 
+ row += surface->pitch;
+@@ -225,8 +234,9 @@
+ /* look for a 256-colour palette */
+ do {
+ if ( !SDL_RWread(src, &ch, 1, 1)) {
+-error = "file truncated";
+-goto done;
++/* Couldn't find the palette, try the end of the file */
++SDL_RWseek(src, -768, RW_SEEK_END);
++break;
+ }
+ } while ( ch != 12 );
+ 
diff -Nru libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-5052.patch libsdl2-image-2.0.4+dfsg1/debian/patches/CVE-2019-5052.patch
--- libsdl2-image-2.0

Bug#934026: python-django: CVE-2019-14232 CVE-2019-14233 CVE-2019-14234 CVE-2019-14235

[Salvatore Bonaccorso]

Hi,

On Thu, Aug 08, 2019 at 02:16:29PM +0100, Chris Lamb wrote:
> Hi Moritz,
> 
> > > > > Security team (added to CC), would you be interested in uploads for
> > > > > buster (currently 1:1.11.22-1~deb10u1) and stretch (currently
> > > > > 1:1.10.7-2+deb9u5)?
> […]
> > I just realised that there's a 1.11.23 (thanks Salvatore!), given that
> > we agreed to follow 1.11.x in buster, shouldn't we rather use that one?
> 
> D'oh, that makes more sense. Okay, I can prepare a debdiff for that --
> however, can you just confirm the version we should use?
> 1:1.11.23-1~deb10u1?

Although I'm late for the game ;-). You can use both
1:1.11.23-1~deb10u1 or 1:1.11.23-0+deb10u1. It is a matter of what you
want the oxpress.

1:1.11.23-1~deb10u1 ... is mainly are rebuild of 1:1.11.23-1 with
maybe some additional changes. Examples for this one are e.g. the
opnejdk packages.

1:1.11.23-0+deb10u1 means ... I import 1:1.11.23 on top of the
existing packaging but released for a lower suite than sid. This in
the theoretiical case there would have been a 1:1.11.23-1 in the upper
suite it is 1:1.11.23-0+deb10u1 < 1:1.11.23-1. If you want examples
for this one for instance ghostscript, mariadb, ...

Regards,
Salvatore

Bug#934258: RFP: jupyterlab -- JupyterLab computational environment

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist

* Package name: jupyterlab
  Version : 1.0.4
  Upstream Author : Jupyter Team
* URL : https://github.com/jupyterlab/jupyterlab
* License : BSD-3
  Programming Lang: Python, JS
  Description : JupyterLab computational environment

An extensible environment for interactive and reproducible computing,
based on the Jupyter Notebook and Architecture. 
.
JupyterLab is the next-generation user interface for Project Jupyter
offering all the familiar building blocks of the classic Jupyter Notebook
(notebook, terminal, text editor, file browser, rich outputs, etc.) in a
flexible and powerful user interface. JupyterLab will eventually replace the
classic Jupyter Notebook.

Bug#933147: buster-pu: package libsdl2-image/2.0.4+dfsg1+deb10u1

[Salvatore Bonaccorso]

Hi Hugo,

On Thu, Aug 08, 2019 at 03:21:31PM +0200, Hugo Lefeuvre wrote:
> Hi,
> 
> > > Buster received [0] per 2.0.4+dfsg1-1, but not [1]. Even if I was aware
> > > that the initial patch was broken (see stretch patch descriptions), I
> > > failed to handle this properly in the buster version.
> > > 
> > > As far as I remember, I did not upload this diff yet. I'll just provide an
> > > updated version asap. I will also update the testing NMU[2], which I
> > > fortunately did not upload yet.
> > 
> > Perfect, thank you for that!
> 
> Done! You can find an updated debdiff for buster in attachement. The new
> debdiff ships CVE-2019-5058.patch which addresses the remaining issue in
> IMG_xcf.c.

Is the attachment missing?

Regards,
Salvatore

Bug#934093: Orca becomes unresponsive when running reportbug

[Samuel Thibault]

thom...@fastmail.cn, le mar. 06 août 2019 18:31:07 -0400, a ecrit:
> When running reportbug from a terminal in debian, Orca becomes unresponsive 
> for a long while. More specifically, I am using the mate-terminal. 
> Eventually, it starts reading but it is after almost a minute. I am using the 
> text interface. Also, this was reproduced in the initial setup.

FTR, orca seems stuck on waiting for an at-spi reply, trying to print

21:15:08 - EVENT MANAGER: object:children-changed:add for [desktop frame | 
main] in None (4, 0, [DEAD])

([DEAD] shows that there's something odd in the any_data part of the produced 
event)

Samuel

Bug#934257: RM: python-shogun -- RoQA; orphaned; no Python 3 subpackage and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

Source seems to support Python 3 in some form but this is not used in the
package, some related packaging parts exist but are commented out. The version
in Debian is 5 years old, the upstream is active. It also depends on shogun
which is currently orphaned and RC-buggy too, but that RC bug looks like it
will be fixed soon.

Reverse deps checked by dak rm -Rnb python-shogun. There is one reverse
Recommends, from python-mvpa2. It is Python 2-only itself, RC-buggy and without
reverse deps (but not under DPMT so I'm not touching it).

Bug#780706: Stay in the Herd - or join the American Free Sovereigns!

[Neo]

**

If you don't want to receive these emails in the future,
please unsubscribe here: 
//track.mdrctr.com/track/pre-unsubscribe/category/EMAIL/empId/74112/subId/91/listId/1/conId/8326/signature/9fb49e12e12dff1caf8fa476e5aedfd1/conEmail/780...@bugs.debian.org/conMovil/-/snapId/17992

Bug#934256: transition: ros-rosconsole

[Jochen Sprickerhof]

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

Hey release team,

I would like to transition to the new rosconsole ABI. Changes where
minimal so I don't expect any problems and I'm maintaining all
downstream packages anyway.

Cheers Jochen

Ben file:

title = "ros-rosconsole";
is_affected = .depends ~ /\b(librosconsole2d)\b/ | .depends ~ 
/\b(librosconsole3d)\b/;
is_good = .depends ~ /\b(librosconsole3d)\b/;
is_bad = .depends ~ /\b(librosconsole2d)\b/;


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: armhf (armv7l)

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

Bug#934254: Time to provide python3-mne package

[Yaroslav Halchenko]

Actually I am looking into it right now, and will push some (if not
final) changes soon.

Cheers!

On Thu, 08 Aug 2019, Yaroslav Halchenko wrote:

> Package: python-mne
> Version: 0.17+dfsg-1
> Severity: normal

> With python2 being deprecated away, now it is more than a wishlist.  If noone
> from the team would find time, I will be doomed to try progressing
> packaging myself.

> Cheers!

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#926701: [tlbuild] Bug#926701: dvisvgm binary fails to link on GNU Hurd

[Hilmar Preuße]

Control: block 926701 by 932968
Control: tags 926701 + pending

Am 30.07.2019 um 08:20 teilte Norbert Preining mit:
> On Tue, 30 Jul 2019, Hilmar Preuße wrote:

>> rejected) you have to tag commit
> 
> Thanks for the warning, but I have already tagged, but not pushed ;-)
> 
Bug manipulation.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#934255: RM: python-jsonrpc2 -- ROM; dead upstream; no Python 3 subpackage and no reverse deps

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

Source claims to support Python 3.4 but there is no Python 3 subpackage.

https://github.com/aodag/jsonrpc2 has no updates since the packaged version (5
years ago).

Reverse deps checked by dak rm -Rnb python-jsonrpc2

Bug#934254: Time to provide python3-mne package

[Yaroslav Halchenko]

Package: python-mne
Version: 0.17+dfsg-1
Severity: normal

With python2 being deprecated away, now it is more than a wishlist.  If noone
from the team would find time, I will be doomed to try progressing
packaging myself.

Cheers!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-mne depends on:
ii  help2man   1.47.8
ii  libgl1-mesa-dri18.3.4-2
ii  libjs-bootstrap3.4.1+dfsg-1
ii  libjs-d3   3.5.17-2
ii  libjs-jquery   3.3.1~dfsg-1
ii  libjs-jquery-ui1.12.1+dfsg-5
ii  python 2.7.16-1
ii  python-joblib  0.13.0-2
ii  python-matplotlib  2.2.3-6
ii  python-numpy   1:1.16.2-1
ii  python-scipy   1.1.0-7
ii  python-sklearn 0.20.2+dfsg-6
ii  xauth  1:1.0.10-1
ii  xvfb   2:1.20.3-1

Versions of packages python-mne recommends:
ii  mayavi2 4.5.0-1
ii  python-nibabel  2.5.0-1
ii  python-nose 1.3.7-4
ii  python-pytest   3.10.1-2

Versions of packages python-mne suggests:
ii  ipython5.8.0-1
pn  python-dap 
pn  python-pycuda  

-- debconf-show failed

Bug#925775: mediastreamer2: ftbfs with GCC-9

[Steve Langasek]

Package: mediastreamer2
Followup-For: Bug #925775
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

This build failure hit Ubuntu as part of the libvpx6 transition, so I've
prepared a patch which fixes mediastreamer2 compatibility with gcc9.  Please
find it attached.

Although it is possible to suppress these errors by manipulating -W options
to gcc instead, strncpy is an error-prone interface and gcc is right that
it's impossible to determine by local code inspection that these are not
buggy (with the exception of one, which was not buggy but which was overly
complicated).  So it's better to fix the lines that gcc complains about.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru mediastreamer2-2.16.1/debian/control 
mediastreamer2-2.16.1/debian/control
--- mediastreamer2-2.16.1/debian/control2019-08-08 08:35:21.0 
-0700
+++ mediastreamer2-2.16.1/debian/control2019-08-08 09:08:09.0 
-0700
@@ -1,7 +1,6 @@
 Source: mediastreamer2
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian VoIP Team 

+Maintainer: Debian VoIP Team 
 Uploaders: Mark Purcell ,
Kilian Krause ,
Tzafrir Cohen ,
diff -Nru mediastreamer2-2.16.1/debian/patches/gcc-9-compatibility.patch 
mediastreamer2-2.16.1/debian/patches/gcc-9-compatibility.patch
--- mediastreamer2-2.16.1/debian/patches/gcc-9-compatibility.patch  
1969-12-31 16:00:00.0 -0800
+++ mediastreamer2-2.16.1/debian/patches/gcc-9-compatibility.patch  
2019-08-08 09:08:09.0 -0700
@@ -0,0 +1,97 @@
+Description: fix wrong uses of strncpy with off-by-one errors
+ gcc 9 detects wrong uses of strncpy that may result in strings that are not
+ null terminated.  Fix afew invocations of strncpy that have this problem.
+ (If null-termination was not desired, this should be using memcpy instead.)
+Author: Steve Langasek 
+Last-Modified: 2019-08-08
+Bug-Debian: https://bugs.debian.org/925775
+
+Index: mediastreamer2-2.16.1/src/audiofilters/tonedetector.c
+===
+--- mediastreamer2-2.16.1.orig/src/audiofilters/tonedetector.c
 mediastreamer2-2.16.1/src/audiofilters/tonedetector.c
+@@ -173,7 +173,8 @@
+   if 
(gs->dur>=tone_def->min_duration && !gs->event_sent){
+   MSToneDetectorEvent 
event;
+   
+-  
strncpy(event.tone_name,tone_def->tone_name,sizeof(event.tone_name));
++  
strncpy(event.tone_name,tone_def->tone_name,sizeof(event.tone_name)-1);
++  event.tone_name[7] = 
'\0';
+   
event.tone_start_time=gs->starttime;
+   
ms_filter_notify(f,MS_TONE_DETECTOR_EVENT,&event);
+   gs->event_sent=TRUE;
+Index: mediastreamer2-2.16.1/src/audiofilters/pulseaudio.c
+===
+--- mediastreamer2-2.16.1.orig/src/audiofilters/pulseaudio.c
 mediastreamer2-2.16.1/src/audiofilters/pulseaudio.c
+@@ -235,7 +235,7 @@
+   if (sourceCard!= NULL) {
+   pa_device_t *sourceCard_data = (pa_device_t *)sourceCard->data;
+   pa_device->bidirectionnal = 1;
+-  strncpy(pa_device->source_name,sourceCard_data->name, 
PA_STRING_SIZE -1);
++  strncpy(pa_device->source_name,sourceCard_data->name, 
PA_STRING_SIZE);
+   *pa_source_list = bctbx_list_remove(*pa_source_list, 
sourceCard->data);
+   ms_free(sourceCard_data);
+   }
+Index: mediastreamer2-2.16.1/src/voip/ice.c
+===
+--- mediastreamer2-2.16.1.orig/src/voip/ice.c
 mediastreamer2-2.16.1/src/voip/ice.c
+@@ -2748,7 +2748,8 @@
+   }
+ 
+   candidate = ms_new0(IceCandidate, 1);
+-  strncpy(candidate->taddr.ip, ip, sizeof(candidate->taddr.ip));
++  strncpy(candidate->taddr.ip, ip, sizeof(candidate->taddr.ip) - 1);
++  candidate->taddr.ip[sizeof(candidate->taddr.ip)-1] = '\0';
+   candidate->taddr.port = port;
+   candidate->taddr.family = family;
+   candidate->type = candidate_type;
+@@ -3033,7 +3034,7 @@
+   /* We found a candidate that should have the same foundation, 
so copy it from this candidate. */
+   IceCandidate *other_candidate = (IceCandidate *)l->data;
+   if (st

Bug#513974: Se ha intentado iniciar sesión en su cuenta

[Zimbra IT Helpdesk]

Su acceso al correo electrónico ha sido restringido. Se ha intentado iniciar 
sesión en su cuenta desde esta IP 168.195.206.93:3389. Si no valida su cuenta 
dentro de las 24 horas, no podrá enviar o recibir correo nuevo hasta que vuelva 
a validar su buzón de correo. Antes de mantener su INBOX. HAGA CLIC AQUÍ para 
verificar.

Christian Oliveira
Verificación de Zimbra IT Helpdesk
Derechos de autor © 2019 Zimbra Technical Team, Inc.

Bug#927335: r-base breaks 9 autopkgtests

[Paul Gevers]

Hi Graham, Dirk,

On 08-08-2019 19:17, Graham Inggs wrote:
> I've prepared the attached list of Breaks to be added to the r-base-core
> binary package.
> 
> I believe these will ease migration.  Paul, do you concur?

Adding the breaks helps the migration, yes.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#934253: ITP: xdg-utils-cxx -- Implementation of the Free Desktop Standards in C++.

[Scarlett Moore]

Package: wnpp
Severity: wishlist
Owner: Scarlett Moore 

* Package name: xdg-utils-cxx
  Version : 1.0.0
  Upstream Author : Alexis López Zubieta
* URL : https://github.com/azubieta/xdg-utils-cxx
* License : MIT/X
  Programming Lang: C++
  Description : Implementation of the Free Desktop Standards in C++.

Implementation of the Free Desktop Standards in C++.

This is a project was started to fulfill the need of a reliable implementations 
of such standards in the AppImage project. It is totally standalone and only 
depends on the standard c++ libraries (stdlib).

It has been split in different modules according to the Free Desktop Standards, 
currently are implemented:

Desktop Entry 1.2 (mostly complete)
Base Dir 0.7 (draft)

This is a dependency of libappimage.

Bug#933934: unmount bash completion complains about "awk: line 18: function gensub never defined"

[Étienne Mollier]

Good day,

I happened to see this issue in the how-can-i-help, and tracked
gensub() down to /usr/share/bash-completion/completions/umount.
At the end of the script, the COMPREPLY variable is set by the
use of `findmnt` and `awk`:

COMPREPLY=( $( compgen -W "$(findmnt -lno TARGET | awk \
'{
if ($0 ~ ENVIRON["HOME"]) {
homeless = $0
homeless = gensub(ENVIRON["HOME"], "~", 
"g", homeless)
homeless = gensub(/(\s)/, "\\1", "g", 
homeless)
print homeless
}
if ($0 ~ ENVIRON["PWD"]) {
reldir = $0
reldir = gensub(ENVIRON["PWD"]"/", "", "g", 
reldir)
reldir = gensub(/(\s)/, "\\1", "g", reldir)
print "./" reldir
print reldir
}
gsub(/\s/, "&")
print $0
}'

These code sections enable to take in account, on one side, the
"~" expansion for home directories, and for the other, building
"./" relative paths from the current working directory.  The gsub
at the end is an attempt to escape space characters, so that the
tab completion already gives a properly escaped command.

When trying to port the AWK script, I stumbled upon failures to
escape properly said spaces.  Besides, it is not the only
dangerous character available in the ASCII interpreter,
regarding the Bash shell.  Apparently the problems with escape
sequences are related to the peculiar behavior of the Bash
built-ins related to completion, here `compgen`.  To clear
things up, I ended up having to move the code block in a side
function _umount_points_list(), which adds up to the user
namespace as soon as an attempt to autocomplete a umount command
is done; so if the name is not fine, perhaps another one can be
considered:

_umount_points_list()
{
# List of characters to escape, shamelessly stolen from "scp" 
comp.
local escape_chars='[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]'
# This is most odd, but we are adding artifically a space after 
the
# file name because, somehow, it enables proper escaping of 
dangerous
# characters, e.g. "|" -> "\|".  Without space, it is possible 
to get
# either 0 "|" or 2 "\\|" backslashes, but 1 does not work.  
Also,
# sticking to sub() and gsub(), instead of gensub(), allows to 
be AWK
# implementation agnostic.
findmnt -lno TARGET | awk '{
if ($0 ~ "^"ENVIRON["HOME"]) {
homeless = $0
sub("^"ENVIRON["HOME"], "~", homeless)
gsub("'"$escape_chars"'", "&", homeless)
print homeless " "
}
if ($0 ~ "^"ENVIRON["PWD"]) {
reldir = $0
sub("^"ENVIRON["PWD"]"/?", "", reldir)
gsub("'"$escape_chars"'", "&", reldir)
print "./" reldir " "
print reldir " "
}
gsub("'"$escape_chars"'", "&")
print $0 " "
}'
}

And the call to set COMPREPLY is thus cleared up a bit:

local IFS=$'\n'
COMPREPLY=( $( compgen -W '$( _umount_points_list )'  -- "$cur" ) )

These changes go a bit beyond the scope of the description of
the bug, but I thought it would be a good idea to let you know
about the issue.

Oh, by the way, when hard coding the AWK interpreter name in the
script, I could ensure compatibility with gawk, mawk, and even
busybox awk.  :)

Should you find this useful, there is a patch in attachment,
against util-linux 2.34-0.1.

I hope this helps instead of bringing confusion,
Kind Regards,
-- 
Étienne Mollier 
   5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D
diff -Naur a/bash-completion/umount b/bash-completion/umount
--- a/bash-completion/umount	2019-04-02 12:12:03.180261025 +0200
+++ b/bash-completion/umount	2019-08-08 20:14:17.758472003 +0200
@@ -1,3 +1,33 @@
+_umount_points_list()
+{
+	# List of characters to escape, shamelessly stolen from "scp" comp.
+	local escape_chars='[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]'
+
+	# This is most odd, but we are adding artifically a space after the
+	# file name because, somehow, it enables proper escaping of dangerous
+	# characters, e.g. "|" -> "\|".  Without space, it is possible to get
+	# either 0 "|" or 2 "\\|" backslashes, but 1 does not work.  Also,
+	# sticking to sub() and gsub(), 

Bug#933378: thunderbird: disappearing messages

[David Christensen]

On 8/8/19 11:19 AM, David Christensen wrote:
I recall creating a message rule to make copies of received messages, 
but I deleted it because I did not want to deal with the the extra 
clutter.  Perhaps I should re-implement the rule, and clean the folder 
periodically -- say, once a week delete everything older than one week. 
That would save me if the bug occurs in the Inbox folder (the most 
common use-case).


In my primary incoming account dpchr...@holgerdanske.com, I created a 
folder "Inbox_log" and a Message Filter rule "Inbox_log":


  Apply filter when:
Manually Run
Getting new mail: Filter after Junk Classification
  Match all meesages
  Perform these actions:
Copy Message to Inbox_log on dpchr...@holgerdanske.com


The rule is ordered after SpamAssassinYes and my manual blacklist, and 
before rules that move mailing list incoming messages into mailing list 
folders (debian-u...@lists.debian.com, etc.).



When a new message comes in that is not from a mailing list, the 
Inbox_log rule seems to work.



When a new message comes in that is from a mailing list, Thunderbird 
goes into an infinite loop putting copies of the message into the 
mailing list folder.  I needed to disable the rule to break the loop.



David

Bug#929752: Changing quote signs in GPL allowed? [Was: Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf ]

[Holger Wansing]

Control: tags -1 + pending


lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> On Tue, Aug 06, 2019 at 08:30:56PM +0200, Holger Wansing wrote:
> > I was about to commit these changes, however it came to my mind if such
> > changes to the GPL are allowed?
> > 
> > At least the English variant of the GPL is 'official' and is not to be
> > changed, so what about changing the quoting signs into   
> > entities?
> 
> gpl.xml isn't official.  It isn't one of the files from the FSF.
> There is a gpl-2.0.dbk[1] version available which in fact does use 
> and  while every other file format uses ` and '.  So at least
> there is precedence for using  tags instead.  After all if you
> decided to use the docbook file as your source text, you would get the
> quotes desired.
> 
> [1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.dbk

Therefore I have committed the changes; tagging this bug as pending.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#934252: libgl1-mesa-dri: SegFPE in ../src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c

[Hilmar Preuße]

Package: libgl1-mesa-dri
Version: 19.1.4-1
Severity: important

Dear Maintainer,

https://bugs.launchpad.net/ubuntu/+source/asymptote/+bug/1470662

I try to process a sample file using asymptote. The binary crashes,
generating a core dump. A backtrace (attached) shows that the
crash happens in the mesa code.

   * What outcome did you expect instead?

Not crashing asymptote binary.

Hilmar

-- Package-specific info:
glxinfo:

glxinfo is not available (missing mesa-utils package).

/usr/share/bug/xserver-xorg-core/script not available

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

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

Versions of packages libgl1-mesa-dri depends on:
ii  libc62.28-10
ii  libdrm-amdgpu1   2.4.97-1
ii  libdrm-intel12.4.97-1
ii  libdrm-nouveau2  2.4.97-1
ii  libdrm-radeon1   2.4.97-1
ii  libdrm2  2.4.97-1
ii  libelf1  0.176-1.1
ii  libexpat12.2.7-1
ii  libgcc1  1:9.1.0-10
ii  libglapi-mesa19.1.4-1
ii  libllvm8 1:8.0.1-2
ii  libsensors5  1:3.5.0-3
ii  libstdc++6   9.1.0-10
ii  zlib1g   1:1.2.11.dfsg-1+b1

libgl1-mesa-dri recommends no packages.

libgl1-mesa-dri suggests no packages.

hille@debian-amd64-sid:~$ gdb asy core_asy
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from asy...
Reading symbols from 
/usr/lib/debug/.build-id/d8/b817de14e33310af3d975659f0d0759eab39fc.debug...
[New LWP 8718]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `asy -vvv 
/usr/share/doc/asymptote/examples/RiemannSurface.asy'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x7f35b30955c0 in lp_build_tgsi_info (tokens=,
info=info@entry=0x55e3fe21cae8)
at ../src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c:582
582 ../src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c: No such file or 
directory.
(gdb) bt
#0  0x7f35b30955c0 in lp_build_tgsi_info (tokens=,
info=info@entry=0x55e3fe21cae8)
at ../src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c:582
#1  0x7f35b289502f in llvmpipe_create_fs_state (pipe=0x55e3fe157b50,
templ=0x7ffcb28b8740) at ../src/gallium/drivers/llvmpipe/lp_state_fs.c:2927
#2  0x7f35b2864108 in ureg_create_shader (ureg=ureg@entry=0x55e3fe1f6350,
pipe=pipe@entry=0x55e3fe157b50, so=so@entry=0x0)
at ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2155
#3  0x7f35b2836940 in ureg_create_shader_with_so_and_destroy (so=0x0,
pipe=0x55e3fe157b50, p=0x55e3fe1f6350)
at ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:156
#4  ureg_create_shader_and_destroy (pipe=0x55e3fe157b50, p=0x55e3fe1f6350)
at ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:156
#5  util_make_fragment_tex_shader_writemask (pipe=pipe@entry=0x55e3fe157b50,
tex_target=tex_target@entry=TGSI_TEXTURE_1D,
interp_mode=interp_mode@entry=TGSI_INTERPOLATE_LINEAR,
writemask=writemask@entry=15, stype=,
dtype=, load_level_zero=false, use_txf=false)
at ../src/gallium/auxiliary/util/u_simple_shaders.c:354
#6  0x7f35b2836b60 in util_make_fragment_tex_shader (
pipe=pipe@entry=0x55e3fe157b50,
tex_target=tex_target@entry=TGSI_TEXTURE_1D,
interp_mode=interp_mode@entry=TGSI_INTERPOLATE_LINEAR,
stype=, dtype=,
load_level_zero=, use_txf=false)
at ../src/gallium/auxiliary/util/u_simple_shaders.c:372
#7  0x7f35b3063bf6 in blitter_get_fs_texfetch_col (
ctx=ctx@entry=0x55e3fe1f1170,
src_format=src_format@entry=PIPE_FORMAT_R32_UINT,
dst_format=dst_format@entry=PIPE_FORMAT_R32_SINT,
target=target@entry=PIPE_TEXTURE_1D,
src_nr_samples=src_nr_samples@entry=1,
dst_nr_samples=dst_nr_samples@entry=1, filter=0, use_txf=false)
at ../src/gallium/auxiliary/util/u_blitter.c:975
#8  0x7f35b3064cc8 in util_blitter_cache_all_shaders (
blitter=0x55e3fe1f1170) at ../src/gallium/auxiliary/ut

Bug#933378: thunderbird: disappearing messages

[David Christensen]

On 8/7/19 10:34 PM, Carsten Schoenert wrote:

Hello David,

On Wed, Aug 07, 2019 at 02:33:10PM -0700, David Christensen wrote:

It did it again -- VERY ANNOYING.


there can be several reasons why this is happen, but I also agree this
should not happen.

As long it's not reproducible it will be impossible to fix anything. And
I haven't experienced such behaviour so I can't see anyhow that's going
wrong here.

There is a extra section within the Debian Wiki about steps a reporter
should take, maybe you have alreday done something about this?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

Without further details there isn't much we can do, and I guess this is
more a upstream issue.

As a work around I wouldn't use move but copy the messages instead.

Regards
Carsten



Thanks for the reply.  This bug is rare, but infuriating.


My guess is that Thunderbird launches threads to print messages and 
launches threads to move messages, and that there is a multi-threading 
race condition in the code that handles the message store.



Validating the thread safety of the message store code would require 
running 2 threads for all possible scheduler interleaving orders and 
checking that the axioms of the system are never violated.  Testing with 
and without various Add-ons would another dimension of complexity. 
Testing all the various configuration settings adds many dimensions. 
Once all those combinations and permutations have been exhausted, the 
process would need to be repeated for 3 threads.  Then again for 4 
threads.  Etc..  It would be an interesting challenge in concurrent 
programming, but I have other problems I need to work on.



My habit has been to start the print job, move the message, and then 
grab the hard copy.  The defect can occur if the move thread starts 
before the print thread has progressed sufficiently (written the job 
file and passed it to CUPS?).



My work-around, when I remember, is to start the print job, wait until 
all the pages have been printed, and then move the message.  This seems 
to be the safest approach.



I don't know if I want to try printing, copying, and then deleting the 
original.  The same bug could occur during the copy, as the defective 
use-case (move) is likely to be a copy followed by a delete.



Perhaps I will try moving the message and then starting the print job 
from the destination folder.



I have disabled Lightning (I did not install Lightning; it came OOTB?).


I previously created a dpchrist_...@holgerdanske.com mailbox and 
configured Thunderbird to send a bcc there as protection against when I 
accidentally nuke my file system/ partition/ drive.  This saves me if 
the bug occurs with a message in the Sent folder.  (It may be possible 
to achieve the same effect with a message rule.)



I recall creating a message rule to make copies of received messages, 
but I deleted it because I did not want to deal with the the extra 
clutter.  Perhaps I should re-implement the rule, and clean the folder 
periodically -- say, once a week delete everything older than one week. 
That would save me if the bug occurs in the Inbox folder (the most 
common use-case).



David

Bug#934251: coinor-dylp: unbuildable in testing due to B-D on texlive-omega

[Esa Peuha]

Source: coinor-dylp
Version: 1.6.0-1.1
Severity: serious

src:texlive-base no longer builds binary package texlive-omega, which
has been removed from testing (and will be removed from unstable at
some point in the future, even if other packages still depend on it).
As a result, coinor-dylp is unbuildable in testing (and eventually is
going to be in unstable as well). Please fix this by changing the
build-dependency in coinor-dylp to texlive-formats-extra instead.