Bug#925913: uhubctl: autopkgtest always fails

[gustavo panizzo]

Hello

On Mon, Jul 22, 2019 at 10:51:02AM +0200, Jakob Haufe wrote:

On Wed, 3 Apr 2019 09:40:06 +0800 gustavo panizzo  wrote:


I've just uploaded 2.0.0-4 to experimental


Please note that this still fails on DebCI, presumably because tests
are run as non-root by default, which means /usr/sbin is not in $PATH.


I was aware but waiting until buster release


A local test, with debian/tests/run-uhubctl-v changed to contain the
full path, passed.



the test pass as is (and before 2.0.0-3, 2.0.0-2) on my local machine
I tried to fix this twice in the archive but failed



diff --git a/debian/tests/run-uhubctl-v b/debian/tests/run-uhubctl-v
index ad9ad39..ecefbff 100644
--- a/debian/tests/run-uhubctl-v
+++ b/debian/tests/run-uhubctl-v
@@ -4,4 +4,4 @@ exec 2>&1

set -e

-uhubctl -v
+/usr/sbin/uhubctl -v


--
ceterum censeo microsoftem esse delendam




--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#813815: Open ITPs (turned into RFPs)

[Andreas Tille]

Hi Joost,

you have at least two long standing ITPs (#813815 - r-cran-nfactors,
#835082 - r-cran-semplot, may be others) which were turned into RFPs
automatically.  Could you give some statement whether these packages
might remain interesting for you and whether we should fire up
prepare_missing_cran_package for these?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#932750: ITS: gdisk

[Christoph Biedl]

Package: gdisk
Version: 1.0.3-1.1
Severity: important

Dear Maintainer,

hereby I declare my intentention to salvage the gdisk package as
described in the developer's reference and also
https://wiki.debian.org/PackageSalvaging
by uploading a new upstream version.

Checking the "conservative" criteria:

| A package is eligible for salvaging
| [x] if it is in clear need of some love and care, i.e. there are open
| bugs, missing upstream releases, or there is work needed from a
| quality-assurance perspective;
| [x] AND there is the need to upload the package to deal with these issues;
| [x] AND at least one of these criteria applies:
|
| [x] There is no visible activity regarding the package for six
| months, OR
|
| [-]
| [x] A previous NMU was not acknowledged, and
| [-] a bug justifying another NMU is pending for one month 1, OR
|
| [x] The last upload was an NMU and there was no maintainer upload
| within one year, OR
|
| [-]
| [-] Bugs exist for more than one major missing upstream version2 and
| [-] the first bug is older than one year, OR
|
| [-] The package blocks a sourceful transition for six months after a
| transition bug was filed against the package in question.

This will also fix #769631 and #932483, and possibly more.

Following the procedure, please object by the end of August 12th the
latest.

All the best,

Christoph



signature.asc
Description: PGP signature

Bug#932675: postgres: Changing of data_directory does not work

[Christoph Berg]

Re: Georg Limbach 2019-07-21 
<156373776064.19386.987783353539086837.reportbug@zotac>
> 2. change the config file: vim /etc/postgresql/11/main/postgresql.conf
> - data_directory = '/var/lib/postgresql/11/main'
> + data_directory = '/media/postgresql/data/11/main'

Hi Georg,

that's a side-effect of bug #931635. After pg_upgrading the cluster,
the postgresql.auto.conf file will have a data_directory setting as
well.

To fix, edit /media/postgresql/data/11/main/postgresql.auto.conf and
remove the data_directory line.

I'll prepare a fix for #931635 over the next days and will also see if
we can fix this one as well.

Christoph

Bug#932640: debi: regression in 2.19.6: won't install new package without --with-depends

[Eriberto Mota]

Hi folks,

Initially, thanks to Simon and Xavier for all effort to solve this issue.

The current status is:

1. https://salsa.debian.org/debian/devscripts/merge_requests/137,
created by Xavier Guimard was closed.

2. https://salsa.debian.org/debian/devscripts/merge_requests/135,
created by Simon McVittie works for new installs only if used with
--with-depends. So, this issue is not solved yet.

Thanks for your attention.

Regards,

Eriberto

Bug#799090: Still present in buster version (3.30.1.1-1)

[Ivan Kohler]

reopen 799090
thanks

There is no change to this bug in version 3.30.1.1-1 in buster.  Window 
borders are still missing when using the application in KDE.

-- 
_ivan

Bug#932644: reconfigure writes to /usr/lib/locale/locale-archive

[Aurelien Jarno]

On 2019-07-21 17:11, Marc Haber wrote:
> Package: locales
> Version: 2.28-10
> Severity: minor
> 
> Hi,
> 
> reconfiguring the locales package updates the file
> /usr/lib/locale/locale-archive.

This is indeed where the libc looks for the compiled locales.

> I am not sure whether this is allowed by policy, hence severity: minor.

I do not find anything that prevents that in the policy. In addition
many other packages are also writing files to /usr when they are
configured (for example __pycache__ files or the various kernel
modules.* files used by depmod, udev hwdb.bin, etc.).

> Maybe this file would better be in /var.

/var is for files whose content is expected to continually change during
normal operation of the system. This is not the case of the
locale-archive file which doesn't change until the next reconfiguration
of the package. As such it doesn't prevent for example mounting the / or
/usr partition read-only once apt or dpkg have finished their work.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#932708: rewrites comments in /etc/locale.gen

[Aurelien Jarno]

On 2019-07-22 07:08, Marc Haber wrote:
> Package: locales
> Version: 2.28-10
> Severity: minor
> 
> Hi,
> 
> a least in buster and later, reconfiguring locales will rewrite
> the comments in /etc/locale.gen which indicate available locales. This
> might confuse file integrity checkers and causes value ping-pong with
> configuration management systems.

This is not something new, basically the postinst script just updates
the file to remove the locales that are not supported anymore and adds
the newly supported ones. The added ones are just added at the end of
the file without modifying the order. Therefore the file is indeed
modified when new locales are added (usually for a new major version),
but for subsequent runs of the posting script, the content should be
left unchanged.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#932751: ITP: ckati --Experimental GNU make clone

[Katerina]

Package: wnpp
Severity: wishlist

Package name: android-platform-build-ckati
Version : 9.0.0+r45-1
Upstream Author : The Android Open Source Project
URL : https://android.googlesource.com/platform/build/kati
License : Apache-2.0
Programming Lang: C/C++
Description : Experimental GNU make clone
Salsa   :
https://salsa.debian.org/android-tools-team/android-platform-build-kati

 the main goal of this tool is to speed up incremental build of Android.
 Currently, kati does not offer a faster build by itself. It instead converts
 your Makefile to a ninja file.
 ckati is the C++ version of kati.

-- 

Katia

Bug#799090: Upstream bug tracker moved without importing old issues.

[Ivan Kohler]

notforwarded 799090
thanks

Upstream bug tracker moved without importing old issues.

-- 
_ivan

Bug#932752: apt-get dist-upgrade fails on missing locales

[Jo Drexl]

Package: apt
Version: 1.4.9
Severity: important

Dear Maintainer,

when upgrading a fresh install of Stretch to Buster (German
localization) and having a Gnome desktop environment, libpam0g:amd64
fails to configure due to missing locales:

Preparing to unpack .../libpam0g_1.3.1-5_amd64.deb ...
Unpacking libpam0g:amd64 (1.3.1-5) over (1.1.8-3.6) ...
Setting up libpam0g:amd64 (1.3.1-5) ...
locale: Kann LC_ALL nicht auf die Standard-Lokale einstellen: Datei oder
Verzeichnis nicht gefunden
Checking for services that may need to be restarted...awk: error while
loading shared libraries: libtinfo.so.6: cannot open shared object file:
No such file or directory
Checking init scripts...
awk: error while loading shared libraries: libtinfo.so.6: cannot open
shared object file: No such file or directory
dpkg: error processing package libpam0g:amd64 (--configure):
subprocess installed post-installation script returned error exit
status 127
Errors were encountered while processing:
libpam0g:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is resulting in a dependency loop with libtinfo6, that can't be 
resolved by running apt-get install -f, even after regenerating the 
locales by hand (which is possible).

test@debian-test:~$ sudo locale-gen 
Generating locales (this might take a while)...
  de_DE.UTF-8... done
Generation complete.
test@debian-test:~$ sudo apt-get update && sudo apt-get dist-upgrade 
OK:1 http://debian.mirror.lrz.de/debian buster InRelease
OK:2 http://debian.mirror.lrz.de/debian buster-updates InRelease
OK:3 http://security.debian.org/debian-security buster/updates InRelease   
Paketlisten werden gelesen... Fertig   
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht 
installiert
 libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne 
Angabe eines Pakets (oder geben Sie eine Lösung an).
test@debian-test:~$ sudo apt-get install -f
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
  guile-2.2-libs libncurses6 libpython3.7-minimal libsasl2-modules libzstd1
  mariadb-common python3.7-minimal
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
The following additional packages will be installed:
  libtinfo6
Die folgenden NEUEN Pakete werden installiert:
  libtinfo6
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 1323 nicht aktualisiert.
47 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 325 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 534 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 
libpam0g:amd64 (1.3.1-5) wird eingerichtet ...
Checking for services that may need to be restarted...awk: error while loading 
shared libraries: libtinfo.so.6: cannot open shared object file: No such file 
or directory
Checking init scripts...
awk: error while loading shared libraries: libtinfo.so.6: cannot open shared 
object file: No such file or directory
dpkg: Fehler beim Bearbeiten des Paketes libpam0g:amd64 (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 127 
zurück
Fehler traten auf beim Bearbeiten von:
 libpam0g:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Delaying configuration won't help either:

test@debian-test:~$ sudo apt full-upgrade -o APT::Immediate-Configure=0
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht 
installiert
 libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne 
Angabe eines Pakets (oder geben Sie eine Lösung an).

The issue can be resolved by combining apt --fix-broken install with
configuration delay:

test@debian-test:~$ sudo apt --fix-broken install -o APT::Imm

Bug#932753: tag2upload should record git tag signer info in .dsc

[Ian Jackson]

Package: dgit-infrastructure
Version: 9.4

Raphael Hertzog writes ("Re: git & Debian packaging sprint report"):
> On Sun, 21 Jul 2019, Ian Jackson wrote:
> > IME as a sponsor I get (AFAICT) no mails as a result of my sponsorship
> > signatures so I think there are few automatic processes.
> 
> That's actualy not true, dak is sending mails to the person who signs the
> upload when it has to send mails like NEW notifications, etc.
> 
> > Hrm, I think tracker may become confused.  It seems to be looking at the
> > .dsc signatur.  So maybe the .dsc field is indeed needed.
> 
> Yes, definitely. 

Thanks to all for the info.  I thought I would capture this here in
a bug, which I can mention in my commit messages, giving a link back
to this -devel thread.

The signing robot's key email address will be a mailing list, so any
stray emails will go there.  That's clearly far from perfect but I
don't think it's a blocker for deployment.  (Which is good because
fixing it will involve patching dak and the other things which use
that signing identity.)

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#932755: sdl-image1.2: multiple security issues

[Hugo Lefeuvre]

Source: sdl-image1.2
Version: 1.2.12-10
Severity: important
Tags: security upstream

Hi,

the following security issues[0] were published for sdl-image1.2:

* CVE-2019-5052: integer overflow and subsequent buffer overflow in IMG_pcx.c.

* CVE-2019-5051: heap-based 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: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).

Fixing these issues:

Patches are quite straightforward and I believe that some of these
issues are worth fixing (reporter claims that they are "exploitable").

I have prepared and uploaded a jessie LTS update addressing most of these
issues (all of them apart from CVE-2019-5051) via targeted fixes.

If the security team agrees, I will provide targeted fixes for buster and
stretch.

For testing, I suggest to package the latest upstream release. If needed, I
can provide an update with targeted fixes.

regards,
Hugo

[0] https://security-tracker.debian.org/tracker/source-package/sdl-image1.2

-- 
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


signature.asc
Description: PGP signature

Bug#932417: nmu: ocamlnet_4.1.2-3

[Paul Gevers]

Control: tags -1 moreinfo

Hi Kyle,

On 19-07-2019 02:12, Kyle Robbertze wrote:
> Please rebuild ocamlnet to use camlzip 1.08-1, uploaded to unstable
> yesterday. Without this, ocamlnet fails to install as it depends on an
> old build of camlzip.
> 
> nmu ocamlnet_4.1.2-3 . ANY . unstable . -m "rebuild against camlzip 1.08-1"

I'm relatively new on the team so give me some slack. There is a
permanent transition tracker for ocaml, so I *guess* this is handled
differently than via regular binNMU requests:
https://release.debian.org/transitions/html/ocaml.html Is there anything
special here?

Paul

Bug#932754: libsdl2-image: multiple security issues

[Hugo Lefeuvre]

Source: libsdl2-image
Version: 2.0.4+dfsg1-1
Severity: important
Tags: security upstream

Hi,

the following security issues[0] were published for libsdl2-image:

* CVE-2019-5052: integer overflow and subsequent buffer overflow in IMG_pcx.c.

* CVE-2019-5051: heap-based 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: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).

Fixing these issues:

Patches are quite straightforward and I believe that some of these
issues are worth fixing (reporter claims that they are "exploitable").

I have prepared and uploaded a jessie LTS update addressing most of these
issues (all of them apart from CVE-2019-5051) via targeted fixes.

If the security team agrees, I will provide targeted fixes for buster and
stretch.

For testing, I suggest to package the latest upstream release. If needed, I
can provide an update with targeted fixes.

regards,
Hugo

[0] https://security-tracker.debian.org/tracker/source-package/libsdl2-image

-- 
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


signature.asc
Description: PGP signature

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Ian Jackson]

Hi.  I am consulting on the name and syntax of a new field I intend to
put in .dsc's.

This is for our tag-to-upload service[1], as described here:
  https://spwhitton.name/blog/entry/tag2upload/

The tag2upload service will take a signed git tag, and verify it
against the Debian keyrings and dm.txt.  It then turns that into a
source package which it signs with its own key.

That means the original "uploader" information (ie the identity of the
person signing the git tag) is not any more present in the source
package.  To rememdy that I propose the following new field:

  Git-Tag-Info: FINGERPRINT Firstname Surname 

The parsing rules are: the first word is the fingerprint entirely in
hex.  The rest is from the tag's "tagger" line (and may not match).

Consumers which want to know which OpenPGP key ws used should use
FINGERPRINT.  Consumers which want to send email should use the RHS.

This syntax does not contain the signature date, nor the tag message,
nor any OpenPGP cert name.  An OpenPGP cert name would be a pain to
provide in a securely meaningful way.  The tag/signature date is not
that important I think (and might be annoying to extract from gpgv).

I think consumers won't need that information.

It also eldides some tag2upload-specific metadata, info about git
branch formats, and so on, but I think a .dsc consumer does not need
that.

Comments welcome.

If you are likely to have an opinion, please reply as soon as you
can, since I hope to do the engineering work to make this thing
production-ready as soon as the relevant design reviews etc. are done.

If it will take you more than a few days to comment, please reply
right away with a holding mail saying when you hope to find the time
to write a substantive reply.

Thanks,
Ian.

[1] The service is still a prototype, but will hopefully be deployed
soon, after some review, privsep work, integration discussions, etc.

Bug#932417: nmu: ocamlnet_4.1.2-3

[Mattia Rizzolo]

On Mon, Jul 22, 2019 at 08:41:09PM +0200, Paul Gevers wrote:
> I'm relatively new on the team so give me some slack. There is a
> permanent transition tracker for ocaml, so I *guess* this is handled
> differently than via regular binNMU requests:
> https://release.debian.org/transitions/html/ocaml.html Is there anything
> special here?

nomeata has scripts to detect this kind of stuff, for ocaml here:
https://people.debian.org/~nomeata/binNMUs-ocaml.txt
Those files are written in a way you can just pipe them into `wb`.

Incidentally, IMHO ocaml and haskell have the same issue golang has
regarding security and stuff, but the release team never really bothered
with them much, I think you should definitely try to work out something
to track decently all these statically linked languages.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#932757: fwupd: should include Built-Using fields in the signed packages

[Adam D. Barratt]

Source: fwupd
Version: 1.2.5-2

Hi,

As discussed with Steve at Debconf, the fwupd-*-signed binary packages
are missing Built-Using fields pointing back to the unsigned source
package. Please add them. :-)

Regards,

Adam

Bug#932756: fwupdate: should include Built-Using fields in the signed packages

[Adam D. Barratt]

Source: fwupdate
Version: 12-4

Hi,

As discussed with Steve at Debconf, the fwupdate-*-signed binary
packages are missing Built-Using fields pointing back to the unsigned
source package. Please add them. :-)

Regards,

Adam

Bug#932758: OPD checkpoint deadlock in libdb5.3.28-12+deb9u1

[Thomas Walker]

Package: libdb5.3
Version: 5.3.28-12+deb9u1

I've been running into https://bugzilla.redhat.com/show_bug.cgi?id=1349779
for some time now and patched it locally more than a year ago and the issue
went away.  Only recently when we updated to a more recent version of Debian
and began running into the issue again did I realize that I had never pushed
the patch with Debian upstream.

Unfortunately, I don't have an easy reproducer (we run into it every month or
two, but presumably increasing compaction frequency in 389ds would make it
happen somewhat sooner).

Note that this also used to be:
https://pagure.io/389-ds-base/issue/49360
Which is what I originally found, but that issue seems to have disappeared.
The patch I got from there in Jan 2018 and the one in Fedora appear to be the
same (with the exception of some fuzz) though.

Patch is little more than:

$ cat debian/patches/checkpoint-opd-deadlock.patch 
Index: db5.3-5.3.28/src/db/db_cam.c
===
--- db5.3-5.3.28.orig/src/db/db_cam.c
+++ db5.3-5.3.28/src/db/db_cam.c
@@ -868,6 +868,11 @@ __dbc_iget(dbc, key, data, flags)
flags == DB_PREV || flags == DB_PREV_DUP)) {
if (tmp_rmw && (ret = dbc->am_writelock(dbc)) != 0)
goto err;
+   /* Latch the primary tree page here in order to not deadlock 
later. */
+   if (cp->page == NULL &&
+   (ret = __memp_fget(mpf, &cp->pgno,
+dbc->thread_info, dbc->txn, 0, &cp->page)) != 0)
+   goto err;
if (F_ISSET(dbc, DBC_TRANSIENT))
opd = cp->opd;
else if ((ret = __dbc_idup(cp->opd, &opd, DB_POSITION)) != 0)

Bug#932759: After upgrade from stretch to buster, removal of obsolete xen 4.8 packages seems to trigger shutdown of xenconsoled

[niek]

Package:  xen-hypervisor-4.11-amd64
Version: 4.11.1+92-g6c33308a8d-2
System: Linux [host] 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1
(2019-07-19) x86_64 GNU/Linux
Debian Release:10
Codename:   buster

In Reference To: Debian bug #851654 (archived)
> On Mon, 21 Jan 2019 00:48:09 +0100 Hans van Kranenburg
>  wrote:
>> reassign 851654 src:xen
>> thanks
>>
>> Hm!
>>
>> I think this is the same one that I've been observing during upgrade
>> tests from 4.8 -> 4.11 and 4.10 -> 4.11.
>>
>> In my IRC logs I can find myself complaining about xenconsoled that's
>> suddenly gone multiple times during 2018. I didn't manage to track this
>> issue down yet. The IRC logs contain some links to expired pastebin
>> entries. :|
>>
>> Also, in some cases xenconsoled just got shut down during the night,
>> during some systemd reload whatever was happening.
>>
>> I suspect more users are going to run into this issue when upgrading to
>> Buster.
>>
>> Hans

What happened:
- upgraded Debian Xen Dom0 from stretch to buster and rebooted, as
described in
https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html

- started some Linux pv domu without problems

- removed obsolete packages with 'apt autoremove'. This removed (among
others)
xen-hypervisor-4.8-amd64:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11),
libxen-4.8:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11),
xen-utils-4.8:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11)

- starting another pv domu the next day using 'xl create -c [domu.cfg]'
raised an error message:
"xenconsole: Could not read tty from store: Success"

- opening a console for an already running domu raised another error
message that I believe was:
"xenconsole: Could not open tty `/dev/pts/2': No such file or directory"

- some internet searching hinted that this could be caused by
xenconsoled not running.

- xenconsoled was not running

- searching system logs revealed that xenconsoled seemed to have stopped
when 'apt autoremove' removed the obsolete xen 4.8
packages after upgrading to xen 4.11.

- this coincided with a systemd reload as seen in journalctl:
Jul 21 07:38:40 host systemd[1]: Reloading.
Jul 21 07:38:40 host systemd[1]: serial-getty@hvc0.service: Current
command vanished from the unit file, execution of the command list won't
be resumed.
Jul 21 07:38:40 host systemd[1]: serial-getty@ttyS1.service: Current
command vanished from the unit file, execution of the command list won't
be resumed.
Jul 21 07:38:40 host systemd[1]: getty@tty1.service: Current command
vanished from the unit file, execution of the command list won't be resumed.
Jul 21 07:38:41 host systemd[1]: Stopping LSB: Xen daemons...
Jul 21 07:38:41 host xen[9092]: Stopping Xen daemons: xenconsoled.
Jul 21 07:38:41 host systemd[1]: xen.service: Succeeded.
Jul 21 07:38:41 host systemd[1]: Stopped LSB: Xen daemons.

Note that at this time domu's where already running under xen4.11.

'systemctl restart xen.service' solved the issue. I report the issue
because it could affect others that are performing upgrades.

Bug#929954: Status of this issue WRT freeze

[Sebastiaan Couwenberg]

Hi Elena,

On Fri, 7 Jun 2019 09:21:22 +0200 Elena ``of Valhalla'' wrote:
> Of course after the release the severity can be raised back, as then it
> would apply to the majority of users indeed (but I'd just upload the
> new version of the package and be done with it).

With the buster release and severity increase behind us, now would be a
good time to upload the new version.

Anything preventing you from doing that?

Kind Regards,

Bas

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

Bug#932752: apt-get dist-upgrade fails on missing locales

[Julian Andres Klode]

Control: reassign -1 libpam0g

On Mon, Jul 22, 2019 at 08:16:54PM +0200, Jo Drexl wrote:
> Package: apt
> Version: 1.4.9
> Severity: important
> 
> Dear Maintainer,
> 
> when upgrading a fresh install of Stretch to Buster (German
> localization) and having a Gnome desktop environment, libpam0g:amd64
> fails to configure due to missing locales:
> 
> Preparing to unpack .../libpam0g_1.3.1-5_amd64.deb ...
> Unpacking libpam0g:amd64 (1.3.1-5) over (1.1.8-3.6) ...
> Setting up libpam0g:amd64 (1.3.1-5) ...
> locale: Kann LC_ALL nicht auf die Standard-Lokale einstellen: Datei oder
> Verzeichnis nicht gefunden
> Checking for services that may need to be restarted...awk: error while
> loading shared libraries: libtinfo.so.6: cannot open shared object file:
> No such file or directory
> Checking init scripts...
> awk: error while loading shared libraries: libtinfo.so.6: cannot open
> shared object file: No such file or directory
> dpkg: error processing package libpam0g:amd64 (--configure):
> subprocess installed post-installation script returned error exit
> status 127
> Errors were encountered while processing:
> libpam0g:amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> This is resulting in a dependency loop with libtinfo6, that can't be 
> resolved by running apt-get install -f, even after regenerating the 
> locales by hand (which is possible).
> 
> test@debian-test:~$ sudo locale-gen 
> Generating locales (this might take a while)...
>   de_DE.UTF-8... done
> Generation complete.
> test@debian-test:~$ sudo apt-get update && sudo apt-get dist-upgrade 
> OK:1 http://debian.mirror.lrz.de/debian buster InRelease
> OK:2 http://debian.mirror.lrz.de/debian buster-updates InRelease
> OK:3 http://security.debian.org/debian-security buster/updates InRelease  
>  
> Paketlisten werden gelesen... Fertig  
>  
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.   
> Statusinformationen werden eingelesen Fertig
> Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
> Die folgenden Pakete haben unerfüllte Abhängigkeiten:
>  guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
>  libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
>  libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
>  libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht 
> installiert
>  libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
> E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne 
> Angabe eines Pakets (oder geben Sie eine Lösung an).
> test@debian-test:~$ sudo apt-get install -f
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.   
> Statusinformationen werden eingelesen Fertig
> Abhängigkeiten werden korrigiert ... Fertig
> Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
> benötigt:
>   guile-2.2-libs libncurses6 libpython3.7-minimal libsasl2-modules libzstd1
>   mariadb-common python3.7-minimal
> Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
> The following additional packages will be installed:
>   libtinfo6
> Die folgenden NEUEN Pakete werden installiert:
>   libtinfo6
> 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 1323 nicht aktualisiert.
> 47 nicht vollständig installiert oder entfernt.
> Es müssen noch 0 B von 325 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 534 kB Plattenplatz zusätzlich benutzt.
> Möchten Sie fortfahren? [J/n] 
> libpam0g:amd64 (1.3.1-5) wird eingerichtet ...
> Checking for services that may need to be restarted...awk: error while 
> loading shared libraries: libtinfo.so.6: cannot open shared object file: No 
> such file or directory
> Checking init scripts...
> awk: error while loading shared libraries: libtinfo.so.6: cannot open shared 
> object file: No such file or directory
> dpkg: Fehler beim Bearbeiten des Paketes libpam0g:amd64 (--configure):
>  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 127 
> zurück
> Fehler traten auf beim Bearbeiten von:
>  libpam0g:amd64
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Delaying configuration won't help either:
> 
> test@debian-test:~$ sudo apt full-upgrade -o APT::Immediate-Configure=0
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.   
> Statusinformationen werden eingelesen Fertig
> Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
> Die folgenden Pakete haben unerfüllte Abhängigkeiten:
>  guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
>  libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
>  libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
>  libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht 
> installiert
>  libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nich

Bug#932747: apt-get: AppStream system cache updated, failing on APT::Update::Post-Invoke-Success

[Julian Andres Klode]

Control: reassign -1 appstream

On Mon, Jul 22, 2019 at 07:39:10PM +0200, Jo Drexl wrote:
> Package: apt
> Version: 1.4.9
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> on running apt-get update, sometimes the AppStream subprocess returns an
> error:
> 
> The AppStream system cache was updated, but some errors were detected,
> which might lead to missing metadata. Refer to the verbose log for more
> information.
> Paketlisten werden gelesen... Fertig
> E: Problem executing scripts APT::Update::Post-Invoke-Success 'if
> /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then
> appstreamcli refresh-cache > /dev/null; fi'
> E: Sub-process returned an error code
> 
> I've seen this error being persistent on some machines, while others
> were thrown off repeatedly. A popular suggestion on the internet is to
> comment out the test statement and proceed without a refreshed appstream
> cache, which seems to work, so I suggest this being rolled out at least
> to Debian Stretch.
> 
> FYI: Writing this from a freshly installed Debian Stretch, which now
> undergoes another dist-upgrade test for me to report the bugs I've seen
> on other machines and am able to reproduce here.
> 

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#932417: nmu: ocamlnet_4.1.2-3

[Paul Gevers]

Hi,

On 22-07-2019 20:54, Mattia Rizzolo wrote:
> On Mon, Jul 22, 2019 at 08:41:09PM +0200, Paul Gevers wrote:
>> I'm relatively new on the team so give me some slack. There is a
>> permanent transition tracker for ocaml, so I *guess* this is handled
>> differently than via regular binNMU requests:
>> https://release.debian.org/transitions/html/ocaml.html Is there anything
>> special here?
> 
> nomeata has scripts to detect this kind of stuff, for ocaml here:
> https://people.debian.org/~nomeata/binNMUs-ocaml.txt
> Those files are written in a way you can just pipe them into `wb`.

I noticed that. But is the RT doing that? Or do ocaml people have access
to wb to do this themselves?

> Incidentally, IMHO ocaml and haskell have the same issue golang has
> regarding security and stuff, but the release team never really bothered
> with them much, I think you should definitely try to work out something
> to track decently all these statically linked languages.

It's mostly s/you/these statically linked language teams together with
the security team/ here. The release team doesn't have the spoons to
drive this. And I think the golang team will have to do some of that
work if they want the golang ecosystem to be in bullseye. If nothing
happens, golang is going to be removed from testing.

Paul

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Russ Allbery]

Ian Jackson  writes:

> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package.  To rememdy that I propose the following new field:

>   Git-Tag-Info: FINGERPRINT Firstname Surname 

> The parsing rules are: the first word is the fingerprint entirely in
> hex.  The rest is from the tag's "tagger" line (and may not match).

One thing that jumps out at me here is that this field isn't extensible,
since anything after the first space-separated word has to be taken to be
the tagger line.

Unfortunately, doing something extensible within the field requires adding
a separator, which in turn requires dealing with escaping, and thus is
kind of a mess.  Given that, what if you instead used two fields:

Git-Tag-Info: fingerprint=FINGERPRINT
Git-Tag-Tagger: Firstname Surname 

and then Git-Tag-Info could be extended later using additional key/value
pairs to hold other information, use spaces or commas between attributes,
and so forth?  For instance, that would let us add the date later if it
looked like that might be useful for some reason.

That also allows the tagger field to be defined has having the same syntax
as Maintainer (or one of the other existing RFC-2822-style fields we
have), which I think increases the chances that parsers will get this
right.

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

Bug#932760: RM: qct - ROM; Upstream Inactive; Affected by Qt4/Python2 Removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: vdanj...@debian.org

Dear FTP Masters,

Package qct has an inactive upstream since 2011 and is using Qt4 and Python2
currently, which are due to be removed. The original package maintainer has
filed an RFA bug back in 2016, in which suggested to remove this package ( 
https://bugs.debian.org/827169 ). I think 3 years later it's appropriate to
have it removed in the Bullseye cycle.

Thanks,
Boyuan Yang


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

Bug#932514: gdb: Don't build against flex-old

[Héctor Orón Martínez]

Hello,

  I have pushed a slightly updated version of your patch to Git
(salsa) now, so it should be part of next release.

  
https://salsa.debian.org/gdb-team/gdb/commit/c9f210a8e1fcd89d2f24630a0283d68fa3b6275f

Regards

Missatge de Tommi Vainikainen  del dia ds., 20 de
jul. 2019 a les 11:42:
>
> Source: gdb
> Severity: normal
> Tags: patch
>
> Hi, as a maintainer of flex-old package I'm considering requesting
> removing it as obsolete and unmaintained version of flex.  The
> gdb Build-Depends on flex-old optionally. Please build the
> package only against current flex by removing references to flex-old
> package such as changed in the following patch.
>
> --- a/debian/control
> +++ b/debian/control
> @@ -17,7 +17,7 @@ Build-Depends:
> gettext,
> bison,
> dejagnu,
> -   flex | flex-old,
> +   flex,
> procps,
>  # Do we really care that much about running the Java tests?
>  #   gcj-jdk | gcj,



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#932417: nmu: ocamlnet_4.1.2-3

[Mattia Rizzolo]

On Mon, Jul 22, 2019 at 09:21:19PM +0200, Paul Gevers wrote:
> Hi,
> 
> On 22-07-2019 20:54, Mattia Rizzolo wrote:
> > On Mon, Jul 22, 2019 at 08:41:09PM +0200, Paul Gevers wrote:
> >> I'm relatively new on the team so give me some slack. There is a
> >> permanent transition tracker for ocaml, so I *guess* this is handled
> >> differently than via regular binNMU requests:
> >> https://release.debian.org/transitions/html/ocaml.html Is there anything
> >> special here?
> > 
> > nomeata has scripts to detect this kind of stuff, for ocaml here:
> > https://people.debian.org/~nomeata/binNMUs-ocaml.txt
> > Those files are written in a way you can just pipe them into `wb`.
> 
> I noticed that. But is the RT doing that? Or do ocaml people have access
> to wb to do this themselves?

nomeata himself has wb access, and has been doing quite some of those
binnmus in the past.
However, at least in the last year, quite some of them were done by
pochu instead, coordinated on IRC on #-haskell or similar channels.

This is to say: I don't actually know where we are left, but I actually
believe there is nothing really set and properly decided, it just
happened to come up like that and that worked well enough that it stuck
there (the fact that they run in a private cronjob on people.d.o should
say enough).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#932761: RM: python-fs-browser,python-fs-plugin-django,python-fs-plugin-s3,python-fs-plugin-sftp,python-fs-plugin-tahoe-lafs,python-fs-plugin-webdav -- NBS; cruft (upstream separated the source)

[魏銘廷]

Package: ftp.debian.org
Severity: normal

Hi,

please remove the following packages:

python-fs-browser   | 0.5.4-1   | unstable   | all
python-fs-plugin-django | 0.5.4-1   | unstable   | all
python-fs-plugin-s3 | 0.5.4-1   | unstable   | all
python-fs-plugin-sftp   | 0.5.4-1   | unstable   | all
python-fs-plugin-tahoe-lafs | 0.5.4-1   | unstable   | all
python-fs-plugin-webdav | 0.5.4-1   | unstable   | all

Upstream removed the above packages from the main project since
python-fs 2.0.0:
  * ~-s3 [1] is separated into another upstream project
  * ~-sftp [2], ~-django [3], ~-webdav [4] are maintained by different
upstreams
  * others are probably gone
  
Since there's no dependencies to the above packages in Debian, I would
like to remove these pacakges for now.  We can reupload these packages
if needed.

Thanks,
Yao Wei

[1]: https://pypi.org/project/fs-s3fs/
[2]: https://pypi.org/project/fs.sshfs/
[3]: https://pypi.org/project/django-pyfs/
[4]: https://pypi.org/project/fs.webdavfs/


signature.asc
Description: PGP signature

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Ian Jackson]

Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer info 
in .dsc [and 1 more messages]"):
> One thing that jumps out at me here is that this field isn't extensible,
> since anything after the first space-separated word has to be taken to be
> the tagger line.

Hi.  Thanks for the review.

How hilarious that you are making this point back to me now here :-).

> Unfortunately , doing something extensible within the field requires adding
> a separator, which in turn requires dealing with escaping, and thus is
> kind of a mess.  Given that, what if you instead used two fields:
> 
> Git-Tag-Info: fingerprint=FINGERPRINT
> Git-Tag-Tagger: Firstname Surname 

This LGTM if other people like the look.

> That also allows the tagger field to be defined has having the same syntax
> as Maintainer (or one of the other existing RFC-2822-style fields we
> have), which I think increases the chances that parsers will get this
> right.

Right.  I already need and have code to turn a git-style
committer/author/tagger line into deb822 form.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#932569: xterm: Returning from Tek mode using escape sequence reports incorrect terminal size

[Thomas Dickey]

On Sat, Jul 20, 2019 at 02:32:51PM -0400, Jonathan Irwin wrote:
> Package: xterm
> Version: 344-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Executing the following 4 commands in xterm:
> 
> stty -a | grep rows
> printf "\033[?38h"
> printf "\033\003"
> stty -a | grep rows
> 
> to get it to switch in and then out of Tek mode using the escape
> sequences results in the following pair of stty outputs:
> 
> speed 38400 baud; rows 24; columns 80; line = 0;
> speed 38400 baud; rows 37; columns 75; line = 0;
> 
> where the first is the correct size for the VT window.  In the second
> line the size of the Tek window is being reported even though xterm is
> in VT mode.
> 
> Some perusal of the changes between stretch (where this worked
> properly) and buster indicates this may be related to the changes in
> the xterm-327y patchset released as part of xterm-328, corresponding
> to the following changelog entry:
> 
> "improve integration between configure-events and updates for reported
> screensize, in particular when switching between vt100 and tek4014
> modes."
> 
> I was able to apparently fix the problem with the following one-line
> change:

It can't hurt, but it's likely a race that is hard to see if there's
more to fix (I can't reproduce it here).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#932593: squid: started by systemd before local file systems are up and therefore fails

[Tilmann Böß]

Am 22.07.19 um 08:31 schrieb Amos Jeffries:

On Sun, 21 Jul 2019 12:57:16 +0200 =?UTF-8?B?VGlsbWFubiBCw7bDnw==?= wrote:

Hi,

please close the bug report #932593. The problem disappeared after I
manually reinstalled the packages systemd and squid („apt --reinstall
install systemd squid“). It seems to me that release updates can confuse
systemd's startup logic - maybe a hint in the release notes to reinstall
systemd after the upgrade might be helpful?



IMO it would be better if we can resolve this without asking people to
(re)install systemd manually.

Were you running a different Squid-4 or a Squid-3 version before this
issue came up?


The issue appeared after the upgrade from Stretch to Buster. (Sorry i 
didn't mention that before.)

Therefore the previous version of Squid must have been 3.5.23-5+deb9u1.



Do you recall what version of systemd were you running before/after the
issue?

Last version in Stretch: 232-25+deb9u11


PS. Your local-fs.target suggestion was a good one even though it did
not help here. I intend to take that upstream in the next few days.  I
assume the name and email used for this public report are appropriate
for me to credit the change to you?


Yes (too much honour for such a small thought …)

Thanks

--
  Dr. Tilmann Böß  

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[gregor herrmann]

On Mon, 22 Jul 2019 20:54:29 +0100, Ian Jackson wrote:

> > Unfortunately , doing something extensible within the field requires adding
> > a separator, which in turn requires dealing with escaping, and thus is
> > kind of a mess.  Given that, what if you instead used two fields:
> > 
> > Git-Tag-Info: fingerprint=FINGERPRINT
> > Git-Tag-Tagger: Firstname Surname 
> 
> This LGTM if other people like the look.

I wonder if just

Git-Tag-Fingerprint: FINGERPRINT

for the first field might be not only simpler but also enough?
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#932762: fakeroot file somefile: Bad system call

[Helmut Grohne]

Package: file
Version: 1:5.37-3
Severity: serious
Control: affects -1 + src:unbound

file no longer works under fakeroot. For example:

$ fakeroot file /bin/true
Bad system call
$ echo $?
159
$

This is relevant when packages that still require root for building use
fakeroot and then call file. autoconf tends to use file and such use
breaks cross building unbound for mips64el as it detects LD="ld -m elf"
instead of LD="ld -m elf64smip". I suspect that this is also what breaks
building binutils and causes the autopkgtest regression.

Can we please disable seccomp until a solution for fakeroot is found?

Helmut

Bug#932763: haproxy: `haproxy.cfg` contains an outdated URL and cipher choices

[April King]

Subject: haproxy: `haproxy.cfg` contains an outdated URL
Package: haproxy
Version: 1.8.19-1
Severity: normal
Tags: newcomer

The existing `haproxy.cfg`, from `debian/haproxy.cfg` contains this URL:
https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy 


However, it should point to this URL:
https://ssl-config.mozilla.org/#server=haproxy 


Additionally, I would taking the list of ciphers from:
ssl-default-bind-ciphers 
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
ssl-default-bind-options no-sslv3

And updating to the Mozilla Intermediate profile, as you can see here:
https://ssl-config.mozilla.org/#server=haproxy&server-version=1.9.8&config=intermediate
 


I would also strongly suggest bundling the RFC 7919 2048-bit Diffie-Hellman 
parameters file in the haproxy debian package as well.

Thanks!

April King (Mozilla)

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

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

Versions of packages haproxy depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.28-10
ii  liblua5.3-0   5.3.3-1.1
ii  libpcre2-8-0  10.32-5
ii  libssl1.1 1.1.1c-1
ii  libsystemd0   241-5
ii  lsb-base  10.2019051400
ii  zlib1g1:1.2.11.dfsg-1

haproxy recommends no packages.

Versions of packages haproxy suggests:
pn  haproxy-doc  
pn  vim-haproxy  

-- Configuration Files:
/etc/haproxy/haproxy.cfg changed [not included]

-- no debconf information

Bug#932764: networkd-dispatcher: requires dbus but package dependency not set

[Michael Norton]

Package: networkd-dispatcher
Version: 2.0-2
Severity: important
X-Debbugs-Cc: spam2019-debian...@mikenorton.ca

Dear Maintainer,


Networkd-dispatcher fails to start if DBus is not installed. The deb 
package should therefore require dbus as a dependency.


Error log:

systemd[1]: Starting Dispatcher daemon for systemd-networkd...
networkd-dispatcher[542]: No valid path found for iwconfig
networkd-dispatcher[542]: No valid path found for iw
networkd-dispatcher[542]: WARNING: systemd-networkd is not running, 
output will be incomplete.

networkd-dispatcher[542]: Traceback (most recent call last):
networkd-dispatcher[542]:   File "/usr/bin/networkd-dispatcher", line 
487, in 

networkd-dispatcher[542]: init()
networkd-dispatcher[542]:   File "/usr/bin/networkd-dispatcher", line 
484, in init

networkd-dispatcher[542]: main()
networkd-dispatcher[542]:   File "/usr/bin/networkd-dispatcher", line 
468, in main

networkd-dispatcher[542]: dispatcher.register()
networkd-dispatcher[542]:   File "/usr/bin/networkd-dispatcher", line 
242, in register

networkd-dispatcher[542]: bus = dbus.SystemBus()
networkd-dispatcher[542]:   File 
"/usr/lib/python3/dist-packages/dbus/_dbus.py", line 194, in __new__

networkd-dispatcher[542]: private=private)
networkd-dispatcher[542]:   File 
"/usr/lib/python3/dist-packages/dbus/_dbus.py", line 100, in __new__
networkd-dispatcher[542]: bus = BusConnection.__new__(subclass, 
bus_type, mainloop=mainloop)
networkd-dispatcher[542]:   File 
"/usr/lib/python3/dist-packages/dbus/bus.py", line 122, in __new__
networkd-dispatcher[542]: bus = cls._new_for_bus(address_or_type, 
mainloop=mainloop)
networkd-dispatcher[542]: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket 
/var/run/dbus/system_bus_socket: No such file or directory
systemd[1]: networkd-dispatcher.service: Main process exited, 
code=exited, status=1/FAILURE

systemd[1]: networkd-dispatcher.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Dispatcher daemon for systemd-networkd.

Workaround:

sudo apt-get install dbus


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages networkd-dispatcher depends on:
ii  gir1.2-glib-2.0  1.58.3-2
ii  python3  3.7.3-1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.30.4-1

networkd-dispatcher recommends no packages.

Versions of packages networkd-dispatcher suggests:
pn  iw | wireless-tools  

-- no debconf information

Bug#932765: kitemmodels FTCBFS: missing Build-Depends: qttools5-dev

[Helmut Grohne]

Source: kitemmodels
Version: 5.54.0-1
Tags: pending

kitemmodels fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/kitemmodels/commit/189c24c5f477756b162998c8487171276b884422
Please close this bug with the next upload to trigger a qa rebuild.

Helmut

Bug#932767: gnome-shell: Segmentation fault in js engine

[Felipe Sateler]

Package: gnome-shell
Version: 3.30.2-9
Severity: important

Hi,

Today, gnome-shell crashed with the following backtrace. I was not at
the computer at the time of the crash.

#0  0x7f1622285714 in js::InterpreterFrame::trace(JSTracer*, JS::Value*, 
unsigned char*)
(this=0x5631b2248b10, trc=0x7f1614335f10, sp=0x5631b28bc870, pc=0xdf 
) at ./js/src/vm/Stack.cpp:348
#1  0x7f1622287bac in js::LifoAlloc::allocImpl(unsigned long) (n=1, 
this=0x0) at ./js/src/ds/LifoAlloc.h:527
#2  0x7f1622287bac in js::LifoAlloc::alloc(unsigned long) (n=1, this=0x0) 
at ./js/src/ds/LifoAlloc.h:593
#3  0x7f1622287bac in js::InterpreterStack::allocateFrame(JSContext*, 
unsigned long) (size=1, cx=0x7f1614335fd0, this=0x0) at 
./js/src/vm/Stack-inl.h:237
#4  0x7f1622287bac in js::InterpreterStack::pushExecuteFrame(JSContext*, 
JS::Handle, JS::Value const&, JS::Handle, 
js::AbstractFramePtr)
(this=0x0, cx=0x7f1614335fd0, script=..., newTargetValue=..., envChain=..., 
evalInFrame=...) at ./js/src/vm/Stack.cpp:456
#5  0x7f162221e8a4 in JSScript::partiallyInit(JSContext*, 
JS::Handle, unsigned int, unsigned int, unsigned int, unsigned int, 
unsigned int, unsigned int, unsigned int)
(cx=, script=..., nscopes=338911184, nconsts=, nobjects=, ntrynotes=573078444, nscopenotes=, nyieldoffsets=, nTypeSets=) at 
./js/src/vm/JSScript.cpp:2847
#6  0x7f162221eb04 in js::GSNCache::purge() (this=0x0) at 
./debian/build/dist/include/js/HashTable.h:92
#7  0x5631afde2100 in  ()
#8  0x7f1624363680 in _IO_2_1_stderr_ () at /lib/x86_64-linux-gnu/libc.so.6
#9  0x5631b2248a00 in  ()
#10 0x5631b6da3100 in  ()
#11 0x27993b5cf4a5d800 in  ()
#12 0x5631b6da3100 in  ()
#13 0x5631b6da3100 in  ()
#14 0x5631b21531f0 in  ()
#15 0x7f1624755d13 in _gjs_profiler_setup_signals () at /lib/libgjs.so.0
#16 0x0041 in  ()
#17 0x5631afde2140 in __bss_start ()
#18 0x0006 in  ()
#19 0x5631afddee1c in  ()
#20 0x7f162437a730 in  () at 
/lib/x86_64-linux-gnu/libpthread.so.0
#21 0x7f16241de7bb in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#22 0x7f16241c9535 in __GI_abort () at abort.c:79
#23 0x7f1624220508 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f162432b28d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#24 0x7f1624226c1a in malloc_printerr (str=str@entry=0x7f162432943b 
"free(): invalid pointer") at malloc.c:5341
#25 0x7f162422842c in _int_free (av=, p=, 
have_lock=) at malloc.c:4165
#26 0x7f1621ef35cd in js::jit::MCallGetProperty::name() const 
(this=) at ./js/src/jit/shared/Assembler-shared.h:253
#27 0x7f1621ef35cd in 
js::jit::CodeGenerator::visitCallGetProperty(js::jit::LCallGetProperty*) 
(this=0x7f15e4008490, lir=0x7f1614336c30) at 
./js/src/jit/CodeGenerator.cpp:10412
#28 0x7f1621f6a4d8 in js::detail::BumpChunk::begin() (this=) 
at ./js/src/ds/LifoAlloc.h:405
#29 0x7f1621f6a4d8 in js::detail::BumpChunk::release() (this=0x0) at 
./js/src/ds/LifoAlloc.h:405
#30 0x7f1621f6a4d8 in js::detail::BumpChunk::~BumpChunk() (this=0x0, 
__in_chrg=) at ./js/src/ds/LifoAlloc.h:326
#31 0x7f1621f6a4d8 in js_delete (p=0x0) at 
./debian/build/dist/include/js/Utility.h:541
#32 0x7f1621f6a4d8 in 
JS::DeletePolicy::operator()(js::detail::BumpChunk 
const*) (this=0x0, ptr=0x0) at ./debian/build/dist/include/js/Utility.h:643
#33 0x7f1621f6a4d8 in mozilla::UniquePtr >::reset(js::detail::BumpChunk*) 
(aPtr=0x0, this=0x0)
at ./debian/build/dist/include/mozilla/UniquePtr.h:343
--Type  for more, q to quit, c to continue without paging--c
#34 0x7f1621f6a4d8 in mozilla::UniquePtr >::~UniquePtr() (this=0x0, 
__in_chrg=) at 
./debian/build/dist/include/mozilla/UniquePtr.h:288
#35 0x7f1621f6a4d8 in 
js::detail::SingleLinkedListElement::~SingleLinkedListElement()
 (this=0x0, __in_chrg=) at ./js/src/ds/LifoAlloc.h:47
#36 0x7f1621f6a4d8 in js::detail::BumpChunk::~BumpChunk() (this=0x0, 
__in_chrg=) at ./js/src/ds/LifoAlloc.h:325
#37 0x7f1621f6a4d8 in js_delete (p=0x0) at 
./debian/build/dist/include/js/Utility.h:541
#38 0x7f1621f6a4d8 in 
JS::DeletePolicy::operator()(js::detail::BumpChunk 
const*) (this=0x0, ptr=0x0) at ./debian/build/dist/include/js/Utility.h:643
#39 0x7f1621f6a4d8 in mozilla::UniquePtr >::reset(js::detail::BumpChunk*) 
(aPtr=0x0, this=0x7fff) at 
./debian/build/dist/include/mozilla/UniquePtr.h:343
#40 0x7f1621f6a4d8 in mozilla::UniquePtr >::~UniquePtr() 
(this=0x7fff, __in_chrg=) at 
./debian/build/dist/include/mozilla/UniquePtr.h:288
#41 0x7f1621f6a4d8 in 
js::detail::SingleLinkedListElement::~SingleLinkedListElement()
 (this=0x0, __in_chrg=) at ./js/src/ds/LifoAlloc.h:47
#42 0x7f1621f6a4d8 in js::detail::BumpChunk::~BumpChunk() 
(this=0x7fff, __in_chrg=) at 
./js/src/ds/LifoAlloc.h:325
#43 0x7f1621f6a4d8 in js_delete 
(p=0x7fff) at ./debian/build/dist/include/js/Utility.h:541
#44 0x7f162

Bug#932766: calamaris: README.Debian gives incorrect image instructions

[James Youngman]

Package: calamaris
Version: 2.99.4.5-3
Severity: normal

The README.Debian file says this:

> With release 2.99 calamaris is able to produce graphics in its reports. If
> you want to use this feature, install libgd-graph-perl and change the
> HTMLOPTIONS in /etc/cron.daily/calamaris to "-F html,graph".

However, /etc/cron.daily/calamaris doesn't allow this:

> #!/bin/sh
> 
> set -e
> 
> if [ -x "/usr/lib/calamaris/calamaris-cron-script" ]; then
>   /usr/lib/calamaris/calamaris-cron-script
> else
>   exit 0
> fi

There is nowhere to set HTMLOPTIONS.  If you just add it to that file,
it's ignored because /usr/lib/calamaris/calamaris-cron-script
unconditionally sets HTMLOPTIONS to "-F html".

If /usr/lib/calamaris/calamaris-cron-script is intended to be
user-editable (a) it is in the wrong place and (b) it should, I
assume, be listed in /var/lib/dpkg/info/calamaris.conffiles.


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

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

Versions of packages calamaris depends on:
ii  bc 1.07.1-2+b1
ii  debconf [debconf-2.0]  1.5.71
ii  perl   5.28.1-6

calamaris recommends no packages.

Versions of packages calamaris suggests:
pn  libgd-graph-perl
pn  libnetaddr-ip-perl  
pn  squid | squid   

-- debconf information:
  calamaris/daily/html: /var/www/calamaris/daily/index.html
  calamaris/cache_type: auto
  calamaris/monthly/title: Squid monthly
  calamaris/daily/title: Squid daily
  calamaris/weekly/title: Squid weekly
  calamaris/weekly/html: /var/www/calamaris/weekly/index.html
  calamaris/weekly/task: mail
  calamaris/monthly/mail: root
  calamaris/weekly/mail: root
  calamaris/daily/task: mail
  calamaris/monthly/task: mail
  calamaris/daily/mail: root
  calamaris/cache_file: access.log
  calamaris/monthly/html: /var/www/calamaris/monthly/index.html

Bug#932629: [Piuparts-devel] Bug#932629: piuparts.debian.org: stable2sid broken by buster release

[Holger Levsen]

rescheduled 11429 packages in buster2next, buster, stable22sid and
stable2sid. Thanks again!

-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#932768: contributors.debian.org: voter info is old

[Uwe Kleine-König]

Package: nm.debian.org
Severity: normal

Hello,

it seems the voters on https://www.debian.org/vote/2019/vote_001 are not
recognised on contributors.debian.org.

On https://contributors.debian.org/contributor/ukleinek@debian/ it is
claimed I voted last time in April 2017, but I voted on both elections
since then:

https://www.debian.org/vote/2019/vote_001 (in April 2019)
https://www.debian.org/vote/2018/vote_001 (in April 2018)

I checked a few other accounts, and they seem to be affected, too.
(https://contributors.debian.org/contributor/paultag@debian/ claims
August 2016, but he also voted on this April's election. Ditto for
hartmans, joerg.)

Best regards
Uwe

Bug#932769: general: DHCP request bug when storage lost

[Mark Hutchison]

Package: general
Severity: important
Tags: l10n

Dear Maintainer,

While doing unrelated storage testing for our VMware integrated product, we 
purposefully recreated
a storage outage by removing the iSCSI initiators from the backing array 
hosting the vmdk disk 
images for the virtual machine.

Upon removal of uplinks to storage, the VM goes into a R/O file system state 
after 5-10 minutes.
When storage initiators are brought back up and the LUNs are rescanned, the VM 
begins to 
rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server in 
a way due
to the number of DHCPDECLINE errors, and the interface attempts to take and 
discard IP's in a
rapid fashion. 

This only seems to appear on this distribution, and I can't replicate the 
behavior on Debian 9
or in a desktop environment.



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

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

Bug#923307: partial fix for upload functionality

[Andrey Skvortsov]

Hi,

after my freedombox upgraded from stretch to buster, I've noticed that
I can't use coquelicot to share files any more.

Here is patch, that at least makes coquelicot usable on buster.

It's available on salsa as well, if it's more convenient to take.
https://salsa.debian.org/skv-guest/coquelicot

Tags: patch

-- 
Best regards,
Andrey Skvortsov
From b2a2081137b8bae17f9c86554af132e85dec569f Mon Sep 17 00:00:00 2001
From: Andrey Skvortsov 
Date: Mon, 22 Jul 2019 22:48:19 +0300
Subject: [PATCH] fix upload functionality with rack 2.x

because of changes in rack 2.x upload functionality in coquelicot was broken.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923307

First by default rack requires rewindable input stream.
Coquelicot tried to avoid rewindable streams for performance and
security reasons. See HACKING for more details.
This change enables usage of rewindable streams to make rack
happy again.

Because of changes in rack API following build error was fixed as well:

Coquelicot::Rack::Upload#call when called for POST /upload when no file has been submitted should set X_COQUELICOT_FORWARD in env
Failure/Error: @params = Rack::Utils::KeySpaceConstrainedParams.new

ArgumentError:
 wrong number of arguments (given 0, expected 1)
 # ./lib/coquelicot/rack/multipart_parser.rb:26:in `new'
 # ./lib/coquelicot/rack/multipart_parser.rb:26:in `initialize'
 ...
 # ./spec/coquelicot/rack/upload_spec.rb:291:in `block (5 levels) in '
 # ./spec/spec_helper.rb:49:in `block (2 levels) in '

Signed-off-by: Andrey Skvortsov 
---
 lib/coquelicot/app.rb   | 2 +-
 lib/coquelicot/rack/multipart_parser.rb | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/coquelicot/app.rb b/lib/coquelicot/app.rb
index c9c7ed3..7a12b40 100644
--- a/lib/coquelicot/app.rb
+++ b/lib/coquelicot/app.rb
@@ -143,7 +143,7 @@ module Coquelicot
 :pid => settings.pid,
 :listeners => settings.listen,
 :use => :ThreadSpawn,
-:rewindable_input => false,
+:rewindable_input => true,
 :client_max_body_size => nil
   })
   unless options[:no_daemon]
diff --git a/lib/coquelicot/rack/multipart_parser.rb b/lib/coquelicot/rack/multipart_parser.rb
index a4be335..2d99624 100644
--- a/lib/coquelicot/rack/multipart_parser.rb
+++ b/lib/coquelicot/rack/multipart_parser.rb
@@ -23,7 +23,7 @@ module Coquelicot::Rack
   class ManyFieldsStep < Struct.new(:block)
 def initialize(block)
   super
-  @params = Rack::Utils::KeySpaceConstrainedParams.new
+  @params = Rack::Utils::KeySpaceConstrainedParams.new(65536)
 end
 
 def call_handler
@@ -31,7 +31,7 @@ module Coquelicot::Rack
 end
 
 def add_param(name, data)
-  Rack::Utils.normalize_params(@params, name, data)
+  Rack::Utils.default_query_parser.normalize_params(@params, name, data, 100)
 end
 
 # borrowed from Sinatra::Base
-- 
2.11.0

Bug#932767: gnome-shell: Segmentation fault in js engine

[Simon McVittie]

I think this is the actual crash:

On Mon, 22 Jul 2019 at 16:31:43 -0400, Felipe Sateler wrote:
> #24 0x7f1624226c1a in malloc_printerr (str=str@entry=0x7f162432943b 
> "free(): invalid pointer") at malloc.c:5341
> #25 0x7f162422842c in _int_free (av=, p=, 
> have_lock=) at malloc.c:4165
> #26 0x7f1621ef35cd in js::jit::MCallGetProperty::name() const 
> (this=) at ./js/src/jit/shared/Assembler-shared.h:253

Unfortunately this is often a result of prior memory corruption, so
it's unlikely to be feasible to debug without knowing how to reproduce it.

Are there any interesting assertion messages from gnome-shell in the
system log?

smcv

Bug#905147: Acknowledgement (lektor: Fails to install plugin)

[spalax+debian]

Hello,
as discussed on github [1], I think that this bug can be closed.

[1] https://github.com/lektor/lektor/issues/596#issuecomment-452880948

Regards,
Louis

Bug#932701: Please switch to libidn2

[Paride Legovini]

Laurent Bigonville wrote on 22/07/2019:
> Hi,
> 
> Currently s-nail uses libidn but also supports libidn2.
> 
> libidn2 is already installed by default on a fresh debian system and
> having to pull an other library is a bit useless, would it be possible
> to switch to libidn2 instead of libidn?
> 
> Switching the build-dependency from libidn11-dev to libidn2-dev seems to
> be enough:

Hi Laurent,

It totally makes sense, I'll do the change in the next upload.

Paride

Bug#932770: RM: ebnetd -- RoQA; unmaintained, dead upstream, unused

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ebnetd, it hasn't seen a maintainer upload since
11 years and hasn't seen an adopter since 2016 and is dead upstream.

Cheers,
Moritz

Bug#932768: contributors.debian.org: voter info is old

[Mattia Rizzolo]

On Mon, Jul 22, 2019 at 10:38:36PM +0200, Uwe Kleine-König wrote:
> it seems the voters on https://www.debian.org/vote/2019/vote_001 are not
> recognised on contributors.debian.org.

The vote.d.o data source is marked as experimental, so I assume the data
source owner did a prototype and a one-off send of the data, without
setting up the proper machinery to keep it up to date.

I'm CCing Q_, as he is the one behing it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#932767: gnome-shell: Segmentation fault in js engine

[Felipe Sateler]

On Mon, Jul 22, 2019 at 5:02 PM Simon McVittie  wrote:

> I think this is the actual crash:
>
> On Mon, 22 Jul 2019 at 16:31:43 -0400, Felipe Sateler wrote:
> > #24 0x7f1624226c1a in malloc_printerr (str=str@entry=0x7f162432943b
> "free(): invalid pointer") at malloc.c:5341
> > #25 0x7f162422842c in _int_free (av=, p= out>, have_lock=) at malloc.c:4165
> > #26 0x7f1621ef35cd in js::jit::MCallGetProperty::name() const
> (this=) at ./js/src/jit/shared/Assembler-shared.h:253
>
> Unfortunately this is often a result of prior memory corruption, so
> it's unlikely to be feasible to debug without knowing how to reproduce it.
>
> Are there any interesting assertion messages from gnome-shell in the
> system log?
>

This is the log leading up to the crash:

-- Logs begin at Sun 2019-03-24 17:30:04 -03, end at Mon 2019-07-22
17:11:13 -04. --
Jul 22 14:50:27 felipedell google-chrome.desktop[2665]:
[3160:3160:0722/145027.070494:ERROR:os_exchange_data_provider_aurax11.cc(498)]
Not implemented reached in virtual uint32_t
ui::OSExchangeDataProviderAuraX11::DispatchEvent(const ui::PlatformEvent &)
Jul 22 14:50:27 felipedell org.gnome.Shell.desktop[2665]: libinput error:
client bug: timer event7 debounce short: offset negative (-1ms)
Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error:
client bug: timer event7 debounce: offset negative (-0ms)
Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error:
client bug: timer event7 debounce: offset negative (-7ms)
Jul 22 14:50:42 felipedell org.gnome.Shell.desktop[2665]: libinput error:
client bug: timer event7 debounce short: offset negative (-20ms)
Jul 22 14:50:51 felipedell org.gnome.Shell.desktop[2665]: libinput error:
client bug: timer event7 debounce short: offset negative (-0ms)
Jul 22 14:51:00 felipedell org.gnome.Shell.desktop[2665]: libinput error:
client bug: timer event7 debounce short: offset negative (-3ms)
Jul 22 14:51:05 felipedell org.gnome.Shell.desktop[2665]: libinput error:
client bug: timer event7 debounce short: offset negative (-6ms)
Jul 22 14:56:54 felipedell gnome-shell[2665]: Object St.Button
(0x5631b4ff6e30), has been already deallocated — impossible to access it.
This might be caused by the object having been destroyed from C code using
something such as destroy(), dispose(), or remove() vfuncs.
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: == Stack trace
for context 0x5631b21531f0 ==
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #0   5631b563d6b8
i   
/home/felipe/.local/share/gnome-shell/extensions/hibernate-status@dromi/extension.js:202
(7f15e2e3ac10 @ 353)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #1   7ffcc6b61610
b   resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #2   5631b563d5f8
i   resource:///org/gnome/shell/ui/extensionSystem.js:83 (7f15e3b54d30 @
436)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #3   5631b563d578
i   resource:///org/gnome/shell/ui/extensionSystem.js:354 (7f15e3b5b8b0 @
13)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #4   7ffcc6b625b0
b   self-hosted:261 (7f15e3fc1dc0 @ 223)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #5   5631b563d4f8
i   resource:///org/gnome/shell/ui/extensionSystem.js:353 (7f15e3b5b820 @
64)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #6   5631b563d478
i   resource:///org/gnome/shell/ui/extensionSystem.js:371 (7f15e3b5b940 @
87)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #7   7ffcc6b63700
b   resource:///org/gnome/gjs/modules/signals.js:128 (7f15e3fc18b0 @ 386)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #8   7ffcc6b64330
b   resource:///org/gnome/shell/ui/sessionMode.js:206 (7f15e3a40790 @ 254)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #9   7ffcc6b64fb0
b   resource:///org/gnome/gjs/modules/_legacy.js:82 (7f15e3fb0b80 @ 71)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #10
5631b563d338 i   resource:///org/gnome/shell/ui/sessionMode.js:168
(7f15e3a40550 @ 40)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #11
7ffcc6b65f30 b   resource:///org/gnome/gjs/modules/_legacy.js:82
(7f15e3fb0b80 @ 71)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #12
5631b563d290 i   resource:///org/gnome/shell/ui/screenShield.js:1279
(7f15e3a284c0 @ 188)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #13
7ffcc6b66eb0 b   resource:///org/gnome/gjs/modules/_legacy.js:82
(7f15e3fb0b80 @ 71)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #14
5631b563d1e0 i   resource:///org/gnome/shell/ui/screenShield.js:1328
(7f15e3a28550 @ 391)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #15
7ffcc6b67e30 b   resource:///org/gnome/gjs/modules/_legacy.js:82
(7f15e3fb0b80 @ 71)
Jul 22 14:56:54 felipedell org.gnome.Shell.desktop[2665]: #16
5631b563d160 i   resource:///org/gnome/shell/ui/screenShield.js:851
(7f15e3a263a0 

Bug#932768: contributors.debian.org: voter info is old

[Mattia Rizzolo]

[ now with a valid address in Cc... ]

On Mon, Jul 22, 2019 at 10:38:36PM +0200, Uwe Kleine-König wrote:
> it seems the voters on https://www.debian.org/vote/2019/vote_001 are not
> recognised on contributors.debian.org.

The vote.d.o data source is marked as experimental, so I assume the data
source owner did a prototype and a one-off send of the data, without
setting up the proper machinery to keep it up to date.

I'm CCing Q_, as he is the one behing it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#931548: Migration to Sphinx

[Holger Levsen]

Hi,

adding Sean to cc: for the question mentioned below.


On Mon, Jul 22, 2019 at 11:24:41PM +0900, Osamu Aoki wrote:
> Do you know anyone good in this.   Is there any volunteer?  (I am
> seeking help on the mailinglist at sphinx-us...@googlegroups.com now)

I'm currently constantly asking on the #debconf channel for any takers :)

> > I think it's ok if the master branch is broken for some time, this
> > conversation has been much desired to get developers-reference in an
> > editable state again, so here we go.
> 
> One thing stopping me to move forward is the difference of i18n HTML
> page arrangement:
> 
>  * Debian web site https://www.debian.org/doc/manuals/developers-reference/
>It offers the automatic locale adjusted content by using
>index.en.html, index.fr.html, ...
>  * Sphinx based web sites such as https://docs.python.org/3/
>It offers the manual pull-down menu and web pages are placed at
>.../en/index.html .../fr/index.html
> 
> How should we arrange web page? I want to migrate to Sphinx-style.
> But that will break current URL links.  Any opinion?

I wonder how this was done for debian-policy which is also hosted on
www.debian.org. Sean, do you have any insight on this?

> Please note Debian web pages will be generated from the latest unstable
> version binary package. 
 
nods. Given how few development there was in recent years on dev-ref I
do think its ok if it will take 1-3 months until the next release ;)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#932771: RM: swftools -- RoQA; obsolete, unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

See #915128 and #843033. I've just uploaded an NMU for yui3, so all
reverse/build dependencies are now resolved.

Cheers,
Moritz

Bug#930643: npm: same error when building atom

[Alessandro Barbieri]

Package: npm
Version: 5.8.0+ds6-4
Followup-For: Bug #930643

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Alessandro Barbieri 
To: Debian Bug Tracking System <930...@bugs.debian.org>
Subject: npm: same error when building atom
Message-ID: <156383100105.9441.3420895093212984226.reportbug@Debian>
X-Mailer: reportbug 7.5.2
Date: Mon, 22 Jul 2019 23:30:01 +0200

Package: npm
Version: 5.8.0+ds6-4
Followup-For: Bug #930643

Dear Maintainer,

I have the same issue

   * What led up to the situation?

Building atom as explained here 
https://flight-manual.atom.io/hacking-atom/sections/hacking-on-atom-core/#platform-linux
after running script/build from a fresh unpack of the tarball this error appear
prior to this I have removed $HOME/.node-gyp and $HOME/.npm

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

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

Versions of packages npm depends on:
ii  ca-certificates 20190110
ii  node-abbrev 1.1.1-1
ii  node-ansi   0.3.0-3
ii  node-ansi-regex 3.0.0-1
ii  node-ansistyles 0.1.3-1
ii  node-aproba 1.2.0-1
ii  node-archy  1.0.0-2
ii  node-bluebird   3.5.1+dfsg2-2
ii  node-boxen  1.2.2-1
ii  node-cacache11.3.2-2
ii  node-call-limit 1.1.0-1
ii  node-chownr 1.1.1-1
ii  node-config-chain   1.1.11-1
ii  node-detect-indent  5.0.0-1
ii  node-detect-newline 2.1.0-1
ii  node-editor 1.0.0-1
ii  node-encoding   0.1.12-2
ii  node-errno  0.1.4-1
ii  node-from2  2.3.0-1
ii  node-fs-vacuum  1.2.10-2
ii  node-fs-write-stream-atomic 1.0.10-4
ii  node-glob   7.1.3-2
ii  node-graceful-fs4.1.11-1
ii  node-gyp3.8.0-6
ii  node-has-unicode2.0.1-2
ii  node-hosted-git-info2.7.1-1
ii  node-iferr  1.0.2-1
ii  node-import-lazy3.0.0.REALLY.2.1.0-1
ii  node-inflight   1.0.6-1
ii  node-inherits   2.0.3-1
ii  node-ini1.3.5-1
ii  node-is-npm 1.0.0-1
ii  node-json-parse-better-errors   1.0.2-2
ii  node-jsonstream 1.3.2-1
ii  node-latest-version 3.1.0-1
ii  node-lazy-property  1.0.0-3
ii  node-libnpx 10.2.0+repack-1
ii  node-lockfile   1.0.4-1
ii  node-lru-cache  5.1.1-4
ii  node-mississippi3.0.0-1
ii  node-mkdirp 0.5.1-1
ii  node-move-concurrently  1.0.1-2
ii  node-nopt   3.0.6-3
ii  node-normalize-package-data 2.4.0-1
ii  node-npm-package-arg6.0.0-2
ii  node-npmlog 4.1.2-1
ii  node-once   1.4.0-3
ii  node-opener 1.4.3-1
ii  node-osenv  0.1.5-1
ii  node-path-is-inside 1.0.2-1
ii  node-promise-inflight   1.0.1-1
ii  node-promzard   0.3.0-1
ii  node-qw 1.0.1-1
ii  node-read   1.0.7-1
ii  node-read-package-json  2.0.13-1
ii  node-request2.88.1-2
ii  node-resolve-from   4.0.0-1
ii  node-retry  0.10.1-1
ii  node-rimraf 2.6.2-1
ii  node-safe-buffer5.1.2-1
ii  node-semver 5.5.1-1
ii  node-semver-diff2.1.0-2
ii  node-sha2.0.1-1
ii  node-slide  1.1.6-2
ii  node-sorted-object  2.0.1-1
ii  node-ssri   5.2.4-2
ii  node-stream-iterate 1.2.0-4
ii  node-strip-ansi 4.0.0-1
ii  node-tar4.4.6+ds1-3
ii  node-text-table 0.2.0-2
ii  node-uid-number 0.0.6-1
ii  node-unique-filename1.1.0+ds-2
ii  node-unpipe 1.0.0-1
ii  node-validate-npm-package-name  3.0.0-1
ii  node-which  1.3.0-2
ii  node-wrappy 1.0.2-1
ii  node-write-file-atomic  2.3.0-1
ii  node-xdg-basedir3.0.0-1
ii  nodejs  10.15.2~dfsg-2

npm recommends no packages.

npm suggests no packages.

-- no debconf information

-- System Information:
Debian Release: 10

Bug#406701: Upload of arphic fonts, Advocate: Problems reaching you

[Hilmar Preuße]

On 09.02.07 13:38, Norbert Preining wrote:
> On Don, 08 Feb 2007, Danai SAE-HAN wrote:
>>> Anyway, Norbert is building your packages and will upload them if it's
> 
> Upload done.
> 
How about that issue? Was it solved by some upload and anybody forgot to
close it?

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



signature.asc
Description: OpenPGP digital signature

Bug#932453: CVE-2019-12815

[Moritz Mühlenhoff]

On Sun, Jul 21, 2019 at 02:31:56PM -0300, Markus Koschany wrote:
> Hi,
> 
> On Fri, 19 Jul 2019 20:35:19 +0200 =?UTF-8?Q?Hilmar_Preu=c3=9fe?=
>  wrote:
> > On 19.07.19 17:41, Moritz Muehlenhoff wrote:
> > 
> > Hi,
> > 
> > > Please see:
> > > http://bugs.proftpd.org/show_bug.cgi?id=4372
> > > https://github.com/proftpd/proftpd/pull/816
> > > 
> > The patch from upstream applies nicely to our master branch (and would
> > apply to the buster package too). I could upload the fix to Debian sid
> > right now. Will you care about stable and oldstable?
> 
> I can take care of oldstable because I wanted to upload a new stretch-pu
> anyway. We can either choose to release the fix for CVE-2019-12815 via
> DSA separately and afterwards I merge it into the stretch-pu or we can
> do all at once. There are considerable changes to fix the previous
> memory leaks which would make the diff harder to review though.

Let's better untangle those.

Cheers,
Moritz

Bug#932754: libsdl2-image security issues in testing

[Hugo Lefeuvre]

Hi Felix,

(CC-ing #932754 which tracks this issue)

> > I have prepared a jessie (LTS) update addressing libsdl2-image's current
> > security issues. I will coordinate with the security team to possibly fix
> > them in a future stretch/buster point update.
> > 
> > Are you planning to address these issues in testing?  Packaging upstream's
> > latest 2.0.5 release should be sufficient, but they can also be addressed
> > with more targeted fixes.
> > 
> > I can provide some help if needed.
> 
> Thanks for your work!
>
> I'm preparing a 2.0.5 upload right now.

Great, thanks!

> As far as I can tell all CVEs in the tracker are fixed with 2.0.5.
> Do you agree?

Exactly.

By the way, I had a second look and it appears that CVE-2019-5051 was also
fixed by the jessie LTS upload. CVE-2019-5051 is also a member of the
CVE-2019-12221 family, and is therefore fixed by [0].

cheers,
Hugo

[0] https://hg.libsdl.org/SDL_image/rev/e7e9786a1a34

-- 
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


signature.asc
Description: PGP signature

Bug#932772:

[The Real Plato]

Package: installation-reports

Boot method: unetbootin usb
Image version:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.0.0+nonfree/amd64/bt-cd/firmware-10.0.0-amd64-netinst.iso.torrent
Date: 2019-07-22-19:00:00Z

Machine: Lenovo Thinkpad T440p
Processor: unknown
Memory: unknown
Partitions: unknown

Output of lspci -knn (or lspci -nn): N/A

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

Heard of Debian as a no-BS upstream of ubuntu and mint. Decided to try to
resurrect my Thinkpad with it.
Started by spending about half an hour trying to find the appropriate image
for a USB install.
Followed links from homepage and started downloading a 3-DVD set before
realizing I did not have three USB drives available and looked for other
media.
Downloaded
https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-10.0.0-amd64-netinst.iso.torrent
and made bootable USB drive with unetbootin.
Booted successfully but was stymied by message "Detect network hardware -
Some of your hardware needs non-free firmware files to operate. The
firmware can be loaded from removable media, such as a USB stick or floppy.
The missing firmware files are: iwlwifi-7260-17.ucode"
Googled to find resolution. Found a note that an unofficial net install
including nonfree drivers is available.
Downloaded that, loaded to USB drive, booted, encountered same message.
Googled again to find the missing file.
Downloaded
http://ftp.us.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_20190502-1_all.deb
to root of another USB drive.
Plugged the drive in to installation machine.
Clicked "Yes, load missing firmware from removable media".
Clicked Continue.
Waited approximately 20 seconds for installer to search. No option to
select the file appeared. No error message appeared.
Gave up and downloaded Mint 19.1 and it works
I need a working machine right now so I'm not interested in fixing this atm

Bug#910783: Remove doc-base recommendation

[Ansgar]

Sean Whitton writes:
> On Sun 14 Jul 2019 at 10:22AM +02, Ansgar wrote:
>> How should we continue with this issue?
>
> Thank you for following up.
>
> I still do not see any positive reason for deleting documentation which
> might be helpful to someone, especially when discussion in the bug has
> indicated that people are doing work which might come to depend on
> doc-base.

Deleting it has the minor advantage of there being less stuff to read.
But I'm fine with keeping the reference if it is still helpful for
others.

So your proposed change looks good to me.  Thanks.

Ansgar

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

Bug#932499: tigervnc-standalone-server: does not start in buster on arm64

[Bernhard Übelacker]

Am 22.07.19 um 15:44 schrieb Kevin Otte:
> As soon as I disconnect the client, the server again crashes with a
> backtrace:

I was told in the upstream report [1], mentioned in #923962,
that the crash on disconnect is known and handled upstream in [2].

[1] https://github.com/TigerVNC/tigervnc/issues/800
[2] https://github.com/TigerVNC/tigervnc/issues/812


> Additionally, I discovered that if you provide the wrong password from
> the client, the server will crash with a nearly identical traceback, the
> only change being where terminate is called:
> 
> terminate called after throwing an instance of 'rfb::AuthFailureException'
> 
> So it appears that any exception thrown will cause the server to crash.

That might strengthen the hypothesis of an issue in libunwind8 ...

Bug#564832: exim4-daemon-heavy: exim4-base 4.71.3 - start and stop runlevels changed, warnings

[Jesse Smith]

I'm not entirely sure, but based on the information provided here it
looks like there may have been an override file in place which later got
removed.

If this bug is still occurring and/or reproducible then I'll happily
look into it. However, if it is not longer happening then I suspect this
was an override/config error and the bug could be closed.

- Jesse

Bug#932768: contributors.debian.org: voter info is old

[Kurt Roeckx]

On Mon, Jul 22, 2019 at 11:17:21PM +0200, Mattia Rizzolo wrote:
> [ now with a valid address in Cc... ]
> 
> On Mon, Jul 22, 2019 at 10:38:36PM +0200, Uwe Kleine-König wrote:
> > it seems the voters on https://www.debian.org/vote/2019/vote_001 are not
> > recognised on contributors.debian.org.
> 
> The vote.d.o data source is marked as experimental, so I assume the data
> source owner did a prototype and a one-off send of the data, without
> setting up the proper machinery to keep it up to date.
> 
> I'm CCing Q_, as he is the one behing it.

Enrico asked me to do this, and wrote me a script for it, called
"parse". I'm not sure if I needed to modify it or not, I think I
did. The only thing I can currently find is his mail from 3 Aug
2017. It might be on my old laptop. It parses the *_voters.txt
file and submits that.


Kurt

Bug#932759: [Pkg-xen-devel] Bug#932759: After upgrade from stretch to buster, removal of obsolete xen 4.8 packages seems to trigger shutdown of xenconsoled

[Hans van Kranenburg]

Hi niek,

Thanks for the report!

On 7/22/19 8:32 PM, niek wrote:
> Package:  xen-hypervisor-4.11-amd64
> Version: 4.11.1+92-g6c33308a8d-2
> 
> What happened:
> - upgraded Debian Xen Dom0 from stretch to buster and rebooted, as
> described in
> https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html
> 
> - started some Linux pv domu without problems
> 
> - removed obsolete packages with 'apt autoremove'. This removed (among
> others)
> xen-hypervisor-4.8-amd64:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11),
> libxen-4.8:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11),
> xen-utils-4.8:amd64 (4.8.5+shim4.10.2+xsa282-1+deb9u11)
> 
> [...]
> - xenconsoled was not running
> 
> - searching system logs revealed that xenconsoled seemed to have stopped
> when 'apt autoremove' removed the obsolete xen 4.8
> packages after upgrading to xen 4.11.

Well, there it is again. We tried to make a fix, exactly for this...

https://salsa.debian.org/xen-team/debian-xen/commit/ef242a700765a971a6afc12d25ee19944dd3a27a

...and apparently there's another scenario in which even this doesn't work?

Can you show the lines from /var/log/dpkg.log from that moment, the
seconds around 07:38:40? It tells exactly what got removed, in what
second, just to confirm?

I'm pretty sure I tried to reproduce this after we added the fix I just
referenced, and I was unable to. So, I'm very interested in finding out
what's still going on here.

Usually being able to reproduce a problem is one of the biggest steps
towards finding a solution. (since it can be done over and over again,
finding out what exactly causes it). So, finding the right sequence of
steps to make it happen again is crucial here.

Do you think the systemd reload has anything to do with it? Maybe the
whole systemd init-script-wrapper-trickery is misbehaving in some way?

Can you reproduce this by manually grabbing the
xen-hypervisor-4.8-amd64, libxen-4.8 and xen-utils-4.8 from stretch
again, installing them and removing them again? Do you have any other idea?

Thanks,
Hans

Bug#932773: xserver-xorg: "no signal" on monitor when computer goes in suspend mode in Buster

[Jack Anderson]

Package: xserver-xorg
Version: 1:7.7+19
Severity: important
Tags: a11y



-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19)

Xorg X server log files on system:
--
-rw-r--r-- 1 jkanders jkanders 28076 Jul 22 18:46 
/home/jkanders/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/jkanders/.local/share/xorg/Xorg.0.log):
-
[23.583] (--) Log file renamed from 
"/home/jkanders/.local/share/xorg/Xorg.pid-782.log" to 
"/home/jkanders/.local/share/xorg/Xorg.0.log"
[23.584] 
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[23.584] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[23.584] Current Operating System: Linux garage 4.19.0-5-amd64 #1 SMP 
Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64
[23.584] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=7cf2c7ad-83bf-4d6e-9306-26d7b0739241 ro quiet
[23.584] Build Date: 05 March 2019  08:11:12PM
[23.584] xorg-server 2:1.20.4-1 (https://www.debian.org/support) 
[23.585] Current version of pixman: 0.36.0
[23.585]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[23.585] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[23.585] (==) Log file: "/home/jkanders/.local/share/xorg/Xorg.0.log", 
Time: Mon Jul 22 18:46:51 2019
[23.586] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[23.588] (==) No Layout section.  Using the first Screen section.
[23.588] (==) No screen section available. Using defaults.
[23.588] (**) |-->Screen "Default Screen Section" (0)
[23.588] (**) |   |-->Monitor ""
[23.590] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[23.590] (==) Automatically adding devices
[23.590] (==) Automatically enabling devices
[23.591] (==) Automatically adding GPU devices
[23.591] (==) Max clients allowed: 256, resource mask: 0x1f
[23.591] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[23.591]Entry deleted from font path.
[23.592] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[23.592] (==) ModulePath set to "/usr/lib/xorg/modules"
[23.592] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[23.593] (II) Loader magic: 0x55d11e7e4e20
[23.593] (II) Module ABI versions:
[23.593]X.Org ANSI C Emulation: 0.4
[23.593]X.Org Video Driver: 24.0
[23.593]X.Org XInput driver : 24.1
[23.593]X.Org Server Extension : 10.0
[23.601] (++) using VT number 2

[23.608] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_32
[23.613] (II) xfree86: Adding drm device (/dev/dri/card0)
[23.615] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0
[23.621] (--) PCI:*(0@0:2:0) 8086:0f31:1019:a8dd rev 14, Mem @ 
0xd000/4194304, 0xc000/268435456, I/O @ 0xf080/8, BIOS @ 
0x/131072
[23.622] (II) LoadModule: "glx"
[23.623] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[23.628] (II) Module glx: vendor="X.Org Foundation"
[23.628]compiled for 1.20.4, module version = 1.0.0
[23.628]ABI class: X.Org Server Extension, version 10.0
[23.628] (==) Matched modesetting as autoconfigured driver 0
[23.628] (==) Matched fbdev as autoconfigured driver 1
[23.628] (==) Matched vesa as autoconfigured driver 2
[23.628] (==) Assigned the driver to the xf86ConfigLayout
[23.628] (II) LoadModule: "modesetting"
[23.629] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[23.632] (II) Module modesetting: vendor="X.Org Foundation"
[23.632]compiled for 1.20.4, module version = 1.20.4
[23.633] 

Bug#932762: fakeroot file somefile: Bad system call

[Christoph Biedl]

Control: tags 932762 pending

Helmut Grohne wrote...

> Package: file
> Version: 1:5.37-3
> Severity: serious
> Control: affects -1 + src:unbound
> 
> file no longer works under fakeroot. For example:
(...)
> Can we please disable seccomp until a solution for fakeroot is found?

Hm, let's give this a quick fix as a sound one. My plan is to whitelist
all the syscalls used by fakeroot. Are you aware of other environments
that might be caught by the same issue? Or in other words, which
syscalls were reported as inacceptable in the kernel log?

Christopg


signature.asc
Description: PGP signature

Bug#932774: ircd-hybrid: Segfault in libgmp.so.10.3.2

[devel]

Source: ircd-hybrid
Version: 1:8.2.24+dfsg.1-1
Severity: normal

Dear Maintainer,

after upgrading a host from Stretch to Buster, ircd-hybrid fails to
start:

  irc@example:~$ ircd-hybrid -foreground
  ircd: version hybrid-1:8.2.24+dfsg.1-1(20180404_8492)
  ircd: pid 32127
  ircd: running in foreground mode from /usr
  Segmentation fault


gdb shows the following output:

  irc@example:~$ gdb --args ircd-hybrid -foreground
  GNU gdb (Debian 8.2.1-2) 8.2.1
  Copyright (C) 2018 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 ircd-hybrid...(no debugging symbols found)...done.
  (gdb) run
  Starting program: /usr/sbin/ircd-hybrid -foreground
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  ircd: version hybrid-1:8.2.24+dfsg.1-1(20180404_8492)
  ircd: pid 28120
  ircd: running in foreground mode from /usr

  Program received signal SIGSEGV, Segmentation fault.
  0x7765a5f0 in __gmpz_sizeinbase () from 
/usr/lib/x86_64-linux-gnu/libgmp.so.10
  (gdb) bt
  #0  0x7765a5f0 in __gmpz_sizeinbase () from 
/usr/lib/x86_64-linux-gnu/libgmp.so.10
  #1  0x77f3acce in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
  #2  0x77e6e1b4 in gnutls_certificate_set_dh_params () from 
/usr/lib/x86_64-linux-gnu/libgnutls.so.30
  #3  0x555778f3 in tls_new_cred ()
  #4  0x55566bfd in read_conf_files ()
  #5  0xefc4 in main ()


ltrace shows the following at the end of its run:

  calloc(1, 32) 
= 0x558d1fc9f3a0
  gnutls_global_init(0, 1265, 40, 0)
= 0
  gnutls_certificate_allocate_credentials(0x558d1fc9f3a0, 0, 0x7f3c4f66a620, 0) 
= 0
  gnutls_priority_init(0x558d1fc9f3a8, 0x558d1dbc7748, 0, 0x558d1fca8a00)   
= 0
  gnutls_certificate_set_x509_key_file(0x558d1fc9f3d0, 0x558d1fca0490, 
0x558d1fca0450, 1)   = 0
  gnutls_dh_params_init(0x558d1fc9f3b0, 0, 0, 0)
= 0
  gnutls_certificate_set_dh_params(0x558d1fc9f3d0, 0x558d1fc897c0, 24, 0 
  --- SIGSEGV (Segmentation fault) ---
  +++ killed by SIGSEGV +++


The kernel log contains the following:

  ircd-hybrid[32122]: segfault at 4 ip 7f5548d1b5f0 sp 7ffc4241e6a8 
error 4 in libgmp.so.10.3.2[7f5548d02000+5e000]


I took a quick look at "gnutls_certificate_set_dh_params".  Its manpage
[1] describes this function as deprecated for quite some time.  I do not
know, whether this is relevant.

Thank you for your time!

Cheers,
Lars


[1] 
https://manpages.debian.org/buster/gnutls-doc/gnutls_certificate_set_dh_params.3.en.html

Bug#925941: nvenc not in ffmpeg

[James Cowgill]

Hi,

On 19/05/2019 16:30, Sebastian Ramacher wrote:
> On 2019-05-09 23:32:04, Chris wrote:
>> On Thu, 28 Mar 2019 16:16:32 -0600 miltonshane...@gmail.com wrote:
>>> Package: FFMPEG
>>> Version: 4.1.1-1 and others
>>>
>>> When running command ffmpeg -codecs nvenc is not showing in h264  or
>>> nvenc_hevc.  This is supported in Debian 9 but not Buster/Testing.
>>>
>>> I suggest enabling this duing build as it is a widly used feature
>>> along with vaapi
>>>
>>> I am using Debian Linux Buster/Testing with nvidia driver stack in
>>> Testing.
>>
>> This is also the case in Sid. Would be extremely helpful to have this
>> built with nvenc support.
>> The version in Sid seems to have VAAPI support, though.
>>
> 
> Someone needs to package https://github.com/FFmpeg/nv-codec-headers.

I've been having a little look at this. Unfortunately, the more I look,
the more I've come to the conclusion that the way FFmpeg dynamically
loads nvenc violates the LGPL - but I'm not 100% settled, so feel free
to persuade me otherwise :) On that basis, it's unfortunate that nvenc
was allowed to be enabled in buster in the first place.

This is the patch which marked nvenc as "free" upstream:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193467.html

Upstream appears to be relying on the GPL's "system library" exception
to make it possible to dynamically load nvenc without the GPL requiring
the source of nvenc to be provided. I don't think Debian can rely on
this though because nvenc is not normally distributed by Debian (and you
have to enable non-free to get it).

James



signature.asc
Description: OpenPGP digital signature

Bug#932775: snmpd: init script does not respect /etc/default/snmpd

[Daniel Reichelt]

Package: snmpd
Version: 5.7.3+dfsg-5
Severity: important

Hi,

first of all, I'm running sysvinit, not systemd.

The init script shipped with snmpd is broken as it does not respect 
/etc/default/snmpd. The code which handled this in the stretch version is 
missing from the buster version:

-8<--
# Reads config file (will override defaults above)
[ -r /etc/default/snmpd ] && . /etc/default/snmpd
-8<--


Thanks,

Daniel

-- System Information:
Versions of packages snmpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libmariadb31:10.3.15-1
ii  libsnmp-base   5.7.3+dfsg-5
ii  libsnmp30  5.7.3+dfsg-5
ii  libssl1.1  1.1.1c-1
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

Bug#925941: nvenc not in ffmpeg

[James Cowgill]

On 23/07/2019 00:59, James Cowgill wrote:
> On that basis, it's unfortunate that nvenc was allowed to be enabled in 
> buster in the first place.

Sorry, I meant to say "stretch" here not "buster".

James



signature.asc
Description: OpenPGP digital signature

Bug#932776: cqrlog: Receiving QSO data in WSJT-X remote mode generates a "Access Violation" message box

[Nate Bargmann]

Package: cqrlog
Version: 2.3.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I am reporting this in case other users of CQRlog and WSJT-X run into this bug.
This issue has been known by upstream for over a year and yet no release
incorporating the fix has been made.  I first encountered this error after
upgrading to CQRlog 2.3.0 last year.  The CQRlog forum has a workaround
described and a link to unofficial fixed binaries:

https://www.cqrlog.com/node/2061

It is important to know that anyone following the directions of copying the
fixed unofficial binary should be aware that a version later than
cqrtest230-216 will force a change to the database schema.  I am using the
216 version here with WSJT-X without issue now.  It is not ideal, and
certainly not likely recommended by the Debian maintainers, but this is out
there and I think it should be useful to document it so others can make a
choice.

73, Nate, N0NB


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

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

Versions of packages cqrlog depends on:
ii  default-mysql-server-core 1.0.5
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2
ii  libgtk2.0-0   2.24.32-3
ii  libhamlib-utils   3.3-5
ii  libhamlib23.3-5
ii  libmariadb-dev-compat 1:10.3.15-1
ii  libpango-1.0-01.42.4-6
ii  libx11-6  2:1.6.7-1
ii  mariadb-client-core-10.3 [virtual-mysql-client-core]  1:10.3.15-1
ii  mariadb-server-core-10.3 [virtual-mysql-server-core]  1:10.3.15-1

Versions of packages cqrlog recommends:
ii  default-mysql-server  1.0.5
ii  xplanet   1.3.0-5.1

cqrlog suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQHBBAEBCgArFiEEG5vcSeqIHtMzWHg79yYl4u2+1ZgFAl02SxgNHG4wbmJAbjBu
Yi51cwAKCRD3JiXi7b7VmAcXC/4zpMa+NY28LBfxt41xBFzxcmCskzREMZZA1PGa
0fZuZatUXm+bflV4zq6slXQGuTwyoa5/amApo9niXJIUoyy6+UlfOHNKcwH1uTv0
c/yy7WHK8s/vbs8JA3l5WlF7vqrH5c+Ds5G2gANtVdsBw8oUU7VIA2jW4JNFYifd
4f7Es4kp17FCSBtcnNHKtxTg98COxlYQES3bjRzPDbWGvZObdQm0CwglvAjlHaWV
siUv+H+mTghF7ME8t4WbAxxlK7JguwAoR6pTypinfEyK4NYzGN2fGM9xfAPwd5xN
6MnWoTC3ybfzTvSTHGe4XfDes/Q+m4/2tBjea69SXUEC4wr1cnd4aCPL/myt+qI5
bJaRcJu6VgWwqmQeSFbB0GHFbTN44tNDvzpLJW3pXdetmICAJ3VQsZZML5MDoBNT
zapk9S/rLo4YmWN6HW47IaAOT5E6anF8Y7s9tb0y++QO80kzycggKvsLHdH0j2R+
agKqKdE9Gtcp8KrD50WFTbj7go4=
=omfB
-END PGP SIGNATURE-

Bug#760080: virtualenvwrapper - Build python3 package

[Nicholas D Steeves]

Control: retitle -1 virtualenvwrapper - Build python3 package

Hi Jan and Ondřej,

Given the "Python BoF and Python 2 removing", it seems like there is a
need to upload the changes that are in git (which close this bug) and
enable the Python 3 variant of this package soon, so leaf packages can
stop using the Python 2 one.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#932777: scotch: 6.0.7 FTBFS: test fails test_libmetis data/bump_b1.grf: invalid pointer

[Drew Parsons]

Package: scotch
Version: 6.0.7-1
Severity: normal
Forwarded: 
https://gforge.inria.fr/tracker/index.php?func=detail&aid=21768&group_id=248&atid=1079

Scotch 6.0.7 FTBFS on most arches, 
see https://buildd.debian.org/status/package.php?p=scotch&suite=experimental

The error message looks like:

mpicc -g -O2 -fdebug-prefix-map=/<>/src/check=. 
-fstack-protector-strong -Wformat -Werror=format-security -O3 -fPIC -I. 
-I/usr/include/mpi -Drestrict=__restrict -DCOMMON_FILE_COMPRESS_GZ 
-DCOMMON_FILE_COMPRESS_BZ2 -DCOMMON_FILE_COMPRESS_LZMA -DCOMMON_PTHREAD 
-DSCOTCH_PTHREAD_NUMBER=2 -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME 
-DSCOTCH_RENAME_PARSER -DCOMMON_PTHREAD_AFFINITY_LINUX -DINTSIZE64 
-I../../include -L../../lib test_libmetis.c -o test_libmetis -lscotchmetis 
-lscotch -lscotcherr -Wl,-z,relro -pthread -lz -lbz2 -llzma -lm -lrt
./test_libmetis data/bump.grf
./test_libmetis data/bump_b1.grf
munmap_chunk(): invalid pointer
make[3]: *** [Makefile:206: check_libmetis] Aborted


test_libmetis is new in 6.0.7 but the test failure seems to be
localised in the sense that only bump_b1.grf fails.
test_libmetis succeeds on bump.grf and bump_imbal_32.grf.
bump_b1.grf passes on ppc64el, hppa and m68k.


Debian patch skip_failing_tests.patch has been prepared to skip
test_libmetis bump_b1.grf.  But waiting to hear back from upstrea
https://gforge.inria.fr/tracker/index.php?func=detail&aid=21768&group_id=248&atid=1079
to hear whether the failure indicates a bigger problem in 6.0.7,
meaning we should keep 6.0.6 for the time being.


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

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

Versions of packages scotch depends on:
ii  libbz2-1.0 1.0.6-9.2
ii  libc6  2.28-10
ii  liblzma5   5.2.4-1
ii  libopenmpi33.1.3-11
ii  libscotch-6.0  6.0.6-2
ii  zlib1g 1:1.2.11.dfsg-1

scotch recommends no packages.

scotch suggests no packages.

-- no debconf information

Bug#928099: RFS: shc/4.0.1, Close

[Tong Sun]

close bugnumber 928099
thanks

Closing the RFS as I'm not able to get the help/sponsor to finish the job.

"Who serves as a soldier at his own expense?" (1Cor 9:7 NIV)

I helped Debian packaging for almost 10 years and never get paid for
doing so. Instead, I put in my own time and sacrifice my own holidays
to get a bigger block of time to work-on/learn-with Debian packaging.

And now someone told me to refer to paid service to get this packaging
done. IHMO, that's a bit too much -- Not offering help is
understandable, but telling me to go to paid service is like rubbing
salt into the wound.

Thus, Closing the RFS.

On Sat, Apr 27, 2019 at 6:51 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 928099: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928099.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Mentors 
>
> If you wish to submit further information on this problem, please
> send it to 928...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 928099: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928099
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#932778: /etc/monit/conf-available/openssh-server: Depending service 'sshd_dsa_key' is not defined in the control file

[Joseph Nahmias]

Package: monit
Version: 1:5.26.0-1~bpo10+1
Severity: normal
File: /etc/monit/conf-available/openssh-server

Hello,

I upgraded monit to the version from buster-backports and it updated the
file /etc/monit/conf-available/openssh-server.  However, this file marks
the sshd service dependent on sshd_dsa_key, but fails to provide a
definition for it.  This broke my upgrade as monit wouldn't start since
I have the openssh-server template included in my monit configuration
(via a symlink in /etc/monit/conf-enabled).

Here's a patch that fixes the issue for me:

--- openssh-server.orig 2019-07-13 05:21:25.0 +
+++ openssh-server  2019-07-23 01:55:55.655575968 +
@@ -23,6 +23,10 @@
group sshd
include /etc/monit/templates/rootstrict

+ check file sshd_dsa_key with path /etc/ssh/ssh_host_dsa_key
+   group sshd
+   include /etc/monit/templates/rootstrict
+
  check file sshd_rc with path /etc/ssh/sshd_config
group sshd
include /etc/monit/templates/rootrc


While you're at it, you might want to include sections for the ecdsa &
ed25519 keys.  But, that's probably a separate bug and likely needs to
go upstream...

Thanks for maintaining this package!
--Joe


-- Package-specific info:

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

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

Versions of packages monit depends on:
ii  libc6  2.28-10
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1c-1
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

monit recommends no packages.

Versions of packages monit suggests:
ii  msmtp-mta [mail-transport-agent]  1.8.3-1
pn  sysvinit-core 

-- no debconf information

Bug#928099: RFS: shc/4.0.1, Close

[Tong Sun]

close 928099
thanks

Try again...

Bug#406701: Upload of arphic fonts, Advocate: Problems reaching you

[韓達耐]

Hi Hilmar
I'll have a look at it this evening.
Cheers

On Tue, 23 Jul 2019, 05:48 Hilmar Preuße,  wrote:

> On 09.02.07 13:38, Norbert Preining wrote:
> > On Don, 08 Feb 2007, Danai SAE-HAN wrote:
> >>> Anyway, Norbert is building your packages and will upload them if it's
> >
> > Upload done.
> >
> How about that issue? Was it solved by some upload and anybody forgot to
> close it?
>
> H.
> --
> sigfault
> #206401 http://counter.li.org
>
>

Bug#932779: lirc: Fails to install due to missing /etc/lirc/lirc_options.conf

[Pat Coulthard]

Package: lirc
Version: 0.10.1-5.2
Severity: grave
Justification: renders package unusable
Control: found -1 0.10.1-6

The versions of lirc in both buster and testing/unstable do not install
cleanly and are left in a half configured state. This appears to be due
to the file /etc/lirc/lirc_options.conf being missing. Copying
/etc/lirc/lirc_options.conf.dist to /etc/lirc/lirc_options.conf allows
the package to finish installing successfully.



root@debian-vm:~# apt install lirc
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libicu57 libperl5.24 rename sgml-base tcpd xml-core
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  gir1.2-glib-2.0 libasound2 libasound2-data libftdi1-2 libgirepository-1.0-1 
libglib2.0-0 libglib2.0-data libjack-jackd2-0 liblirc-client0 liblirc0 libopus0 
libportaudio2
  libpython3.7 libsamplerate0 python3-gi python3-yaml shared-mime-info 
xdg-user-dirs
Suggested packages:
  libasound2-plugins alsa-utils jackd2 opus-tools lirc-compat-remotes 
lirc-drv-irman lirc-doc lirc-x setserial ir-keytable
Recommended packages:
  gir1.2-vte
The following NEW packages will be installed:
  gir1.2-glib-2.0 libasound2 libasound2-data libftdi1-2 libgirepository-1.0-1 
libglib2.0-0 libglib2.0-data libjack-jackd2-0 liblirc-client0 liblirc0 libopus0 
libportaudio2
  libpython3.7 libsamplerate0 lirc python3-gi python3-yaml shared-mime-info 
xdg-user-dirs
0 upgraded, 19 newly installed, 0 to remove and 0 not upgraded.
Need to get 7,891 kB of archives.
After this operation, 33.5 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.us.debian.org/debian buster/main amd64 libglib2.0-0 amd64 
2.58.3-2 [1,259 kB]
Get:2 http://ftp.us.debian.org/debian buster/main amd64 libgirepository-1.0-1 
amd64 1.58.3-2 [92.8 kB]
Get:3 http://ftp.us.debian.org/debian buster/main amd64 gir1.2-glib-2.0 amd64 
1.58.3-2 [143 kB]
Get:4 http://ftp.us.debian.org/debian buster/main amd64 libasound2-data all 
1.1.8-1 [59.6 kB]
Get:5 http://ftp.us.debian.org/debian buster/main amd64 libasound2 amd64 
1.1.8-1 [361 kB]
Get:6 http://ftp.us.debian.org/debian buster/main amd64 libftdi1-2 amd64 
1.4-1+b2 [30.2 kB]
Get:7 http://ftp.us.debian.org/debian buster/main amd64 libglib2.0-data all 
2.58.3-2 [1,109 kB]
Get:8 http://ftp.us.debian.org/debian buster/main amd64 libopus0 amd64 1.3-1 
[191 kB]
Get:9 http://ftp.us.debian.org/debian buster/main amd64 libsamplerate0 amd64 
0.1.9-2 [949 kB]
Get:10 http://ftp.us.debian.org/debian buster/main amd64 libjack-jackd2-0 amd64 
1.9.12~dfsg-2 [299 kB]
Get:11 http://ftp.us.debian.org/debian buster/main amd64 liblirc-client0 amd64 
0.10.1-5.2 [70.6 kB]
Get:12 http://ftp.us.debian.org/debian buster/main amd64 liblirc0 amd64 
0.10.1-5.2 [131 kB]
Get:13 http://ftp.us.debian.org/debian buster/main amd64 libportaudio2 amd64 
19.6.0-1 [66.6 kB]
Get:14 http://ftp.us.debian.org/debian buster/main amd64 libpython3.7 amd64 
3.7.3-2 [1,498 kB]
Get:15 http://ftp.us.debian.org/debian buster/main amd64 lirc amd64 0.10.1-5.2 
[511 kB]
Get:16 http://ftp.us.debian.org/debian buster/main amd64 python3-gi amd64 
3.30.4-1 [180 kB]
Get:17 http://ftp.us.debian.org/debian buster/main amd64 python3-yaml amd64 
3.13-2 [121 kB]
Get:18 http://ftp.us.debian.org/debian buster/main amd64 shared-mime-info amd64 
1.10-1 [766 kB]
Get:19 http://ftp.us.debian.org/debian buster/main amd64 xdg-user-dirs amd64 
0.17-2 [53.8 kB]
Fetched 7,891 kB in 3s (3,127 kB/s)
Selecting previously unselected package libglib2.0-0:amd64.
(Reading database ... 34382 files and directories currently installed.)
Preparing to unpack .../00-libglib2.0-0_2.58.3-2_amd64.deb ...
Unpacking libglib2.0-0:amd64 (2.58.3-2) ...
Selecting previously unselected package libgirepository-1.0-1:amd64.
Preparing to unpack .../01-libgirepository-1.0-1_1.58.3-2_amd64.deb ...
Unpacking libgirepository-1.0-1:amd64 (1.58.3-2) ...
Selecting previously unselected package gir1.2-glib-2.0:amd64.
Preparing to unpack .../02-gir1.2-glib-2.0_1.58.3-2_amd64.deb ...
Unpacking gir1.2-glib-2.0:amd64 (1.58.3-2) ...
Selecting previously unselected package libasound2-data.
Preparing to unpack .../03-libasound2-data_1.1.8-1_all.deb ...
Unpacking libasound2-data (1.1.8-1) ...
Selecting previously unselected package libasound2:amd64.
Preparing to unpack .../04-libasound2_1.1.8-1_amd64.deb ...
Unpacking libasound2:amd64 (1.1.8-1) ...
Selecting previously unselected package libftdi1-2:amd64.
Preparing to unpack .../05-libftdi1-2_1.4-1+b2_amd64.deb ...
Unpacking libftdi1-2:amd64 (1.4-1+b2) ...
Selecting previously unselected package libglib2.0-data.
Preparing to unpack .../06-libglib2.0-data_2.58.3-2_all.deb ...
Unpacking libglib2.0-data (2.58.3-2) ...
Selecting previously unselected package libopus0:amd64.
Preparing to unpack .../07-libopus0_1.3-1_amd64.deb ...
Unpacking libopus0:amd64 (1.3-1) ...
Selectin

Bug#930780: ITS: pssh

[Tobias Frost]

Hi Mo Zhou,

In preparation for my talk (ITS -- one year later) I came across this
bug and as the 21 day delay has been reached I'm wondering if your are
still intending to salvage the package or if this bug somehow slipped
through some gaps and/or should be closed?

Cheers,
tobi

Bug#927231: ITS: pastebinit -- command-line pastebin client

[Tobias Frost]

Hi Simon,

In preparation for my talk (ITS -- one year later) I came across this
bug and as the 21 day delay has been reached I'm wondering if your are
still intending to salvage the package or if this bug somehow slipped
through some gaps and/or should be closed?

Cheers,
tobi

On Tue, 16 Apr 2019 11:48:42 -0500 Simon Quigley 
wrote:
> Package: pastebinit
> Severity: important
> X-Debbugs-CC: f...@rolf.leggewie.biz, m...@qa.debian.org
> 
> Dear Maintainer,
> 
> I have noticed that no work has been done on pastebinit in the past
> year; there are seven bugs open at the time of writing, not including
> the one that is fixed in DELAYED.
> 
> I intend to salvage this package as laid forth in the Debian
Developers
> Reference[1]. If you disagree with this and either want to continue
> maintaining this package or add me as a co-maintainer, please respond
to
> this bug before Tuesday, May 7, 2019, at which point I will upload a
> package to DELAYED/7 making myself the maintainer (if you do not
> respond). If you would like me to go ahead and just do it, please
> respond as well.
> 
> Thank you for your work on this package!
> 
> [1]
> 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#ps-guidelines
> 
> -- 
> Simon Quigley
> tsimo...@debian.org
> tsimonq2 on freenode and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
> 

Bug#932752: apt-get dist-upgrade fails on missing locales

[Steve Langasek]

Julian, I don't see how this can be a pam bug, and you didn't include any
explanation when you reassigned.

The failure here is due to libpam0g calling awk in its postinst, and awk not
having all of its libraries unpacked, making awk unusable.  However,
libpam0g does not depend on awk because packages are not supposed to: awk is
"virtually essential" by way of a pre-dependency from base-files to the
'awk' virtual package.  (This is not documented in debian-policy, but it has
always been understood that awk is meant to be treated as essential
functionality and that this is why base-files pre-depends on it.)

This problem only affects users who have /etc/alternatives/awk pointing to
gawk instead of mawk.  If you are using mawk (the default), it does not
require libtinfo6.  If you are using gawk, then it requires libreadline7 ->
libtinfo6, and this is a new dependency when upgrading from stretch to
buster (libtinfo5->6 transition).

So if this is a pam bug, it looks to me like a bug that can also affect many
other packages (with pam most likely to be affected, due to its own location
deep in the dependency tree).  And if it is a pam bug, I'm also not sure how
to fix it.  Should I add an explicit dependency on mawk?  But the reason awk
is "virtually essential" is to allow installations to pick a different
implementation for /usr/bin/awk, and optionally remove mawk from their
system entirely, which would no longer be possible.

Or, since gawk is an implementor of the virtually-essential awk, should its
transitive dependencies not be held to the same standard as other essential
packages, and be required to pre-depend on their shared library dependencies
instead of depending on them?

On Mon, Jul 22, 2019 at 04:18:23PM -0300, Julian Andres Klode wrote:
> Control: reassign -1 libpam0g
> 
> On Mon, Jul 22, 2019 at 08:16:54PM +0200, Jo Drexl wrote:
> > Package: apt
> > Version: 1.4.9
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > when upgrading a fresh install of Stretch to Buster (German
> > localization) and having a Gnome desktop environment, libpam0g:amd64
> > fails to configure due to missing locales:
> > 
> > Preparing to unpack .../libpam0g_1.3.1-5_amd64.deb ...
> > Unpacking libpam0g:amd64 (1.3.1-5) over (1.1.8-3.6) ...
> > Setting up libpam0g:amd64 (1.3.1-5) ...
> > locale: Kann LC_ALL nicht auf die Standard-Lokale einstellen: Datei oder
> > Verzeichnis nicht gefunden
> > Checking for services that may need to be restarted...awk: error while
> > loading shared libraries: libtinfo.so.6: cannot open shared object file:
> > No such file or directory
> > Checking init scripts...
> > awk: error while loading shared libraries: libtinfo.so.6: cannot open
> > shared object file: No such file or directory
> > dpkg: error processing package libpam0g:amd64 (--configure):
> > subprocess installed post-installation script returned error exit
> > status 127
> > Errors were encountered while processing:
> > libpam0g:amd64
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > 
> > This is resulting in a dependency loop with libtinfo6, that can't be 
> > resolved by running apt-get install -f, even after regenerating the 
> > locales by hand (which is possible).
> > 
> > test@debian-test:~$ sudo locale-gen 
> > Generating locales (this might take a while)...
> >   de_DE.UTF-8... done
> > Generation complete.
> > test@debian-test:~$ sudo apt-get update && sudo apt-get dist-upgrade 
> > OK:1 http://debian.mirror.lrz.de/debian buster InRelease
> > OK:2 http://debian.mirror.lrz.de/debian buster-updates InRelease
> > OK:3 http://security.debian.org/debian-security buster/updates InRelease
> >
> > Paketlisten werden gelesen... Fertig
> >
> > Paketlisten werden gelesen... Fertig
> > Abhängigkeitsbaum wird aufgebaut.   
> > Statusinformationen werden eingelesen Fertig
> > Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
> > Die folgenden Pakete haben unerfüllte Abhängigkeiten:
> >  guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
> >  libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
> >  libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
> >  libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht 
> > installiert
> >  libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
> > E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne 
> > Angabe eines Pakets (oder geben Sie eine Lösung an).
> > test@debian-test:~$ sudo apt-get install -f
> > Paketlisten werden gelesen... Fertig
> > Abhängigkeitsbaum wird aufgebaut.   
> > Statusinformationen werden eingelesen Fertig
> > Abhängigkeiten werden korrigiert ... Fertig
> > Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
> > benötigt:
> >   guile-2.2-libs libncurses6 libpython3.7-minimal libsasl2-modules libzstd1
> >   mariadb-common python3.7

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer 
info in .dsc [and 1 more messages]"):
> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer 
> info in .dsc [and 1 more messages]"):
> > Git-Tag-Info: fingerprint=FINGERPRINT
> > Git-Tag-Tagger: Firstname Surname 
> 
> This LGTM if other people like the look.

It occurs to me based on another conversation I had: should this be in
.dsc or .changes ?

Ian.

Bug#815950: Jesus returns in the 21st century 00-12-22

[Tupirani21]

Шанс для вознесения церкви, это служение восстановления.
https://youtu.be/sLLWJV6OArk
 
Библия Да, Конституция НЕ!
 

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Russ Allbery]

Ian Jackson  writes:

> SGTM.  We can specify that [ ] contains optional information.  I guess
> that is why that syntax was chosen...

> Then critical information which *should* cause an old parser to fail
> can also be added.

> So the overall syntax is roughly

>[ " -b "  ] [ " "  ]
>  [ " [" (  |  "="  "; " )* "]" ]

> We can say that it's  if it has "=" before any "/".  Then paths
> containing = are expressable as ./foo=bar

This is a little more complicated than I'd like (we have a few too many
different ad hoc parsers and novel grammars in Debian), but I think it's
unavoidable at this point without breaking backward compatibility in ways
that aren't worth it.

So, looks good to me.  Next step is for someone to get a chance to write
the language.  (I'll tag the bug accordingly.)

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

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Russ Allbery]

Ian Jackson  writes:
> Ian Jackson writes ("Re: Bug#932753: tag2upload should record git tag signer 
> info in .dsc [and 1 more messages]"):
>> Russ Allbery writes ("Bug#932753: tag2upload should record git tag signer 
>> info in .dsc [and 1 more messages]"):
>> > Git-Tag-Info: fingerprint=FINGERPRINT
>> > Git-Tag-Tagger: Firstname Surname 
>> 
>> This LGTM if other people like the look.

> It occurs to me based on another conversation I had: should this be in
> .dsc or .changes ?

I personally think it should be in the *.dsc file because that makes it
more visible directly in the archive if we need to track down how a
package was uploaded for some reason.  (This is the security engineer in
me talking, probably.)  We probably *could* track down the same
information via *.changes and other systems, but I don't see a reason to
not put it in the *.dsc file and conceptually think of it as "replacing"
the current uploader signature on the *.dsc file.

That said, I could be missing some subtlety of why the *.changes file
would be better.

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

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Jonathan Nieder]

Hi,

Ian Jackson wrote:
> Russ Allbery writes:

>> So, maybe something like:
>>
>>  -b  [; = ...]
>>
>> to build off of what we already have?  (With, obviously, a bunch of that
>> syntax marked as optional.)  If we ban "=" in , we can allow for
>>  to be optional but some other key/value pair to be provided.
>
> SGTM.  We can specify that [ ] contains optional information.

Taking a step back, I'd like to understand the use case a little better.

In Subversion, it's standard to use paths to represent multiple projects
and even branches within a repository.  So in that setting, I completely
understand why  is part of the URL.

In Git, when you "git clone" a repository, that represents a single
codebase.  There is no parameter you can pass to "git clone" that
tells it to clone just a subdirectory.  So we aren't including the
 in Vcs-Git in order to determine what parameters to pass to
"git clone".

Given that, what *are* we including the  for?  And similarly,
what is the use case behind the other key/value pairs described here?

It's possible that it might make sense to use separate fields for this
information --- e.g. a

  Vcs-Git-Path: 

or something like that.  That way, you get extensibility for free.

Alternatively, maybe there is a lurking Git feature request here, for
example for an atomic view across multiple repositories, or for the
ability to clone just a subdirectory of a repository (with
https://crbug.com/git/2 you already almost have that, though it's
fussy to set up sparse checkout to do it and you still have to "cd"
into the subdirectory).

Curious,
Jonathan

Bug#932762: fakeroot file somefile: Bad system call

[Helmut Grohne]

Hi Christoph,

On Tue, Jul 23, 2019 at 01:13:51AM +0200, Christoph Biedl wrote:
> Hm, let's give this a quick fix as a sound one. My plan is to whitelist
> all the syscalls used by fakeroot. Are you aware of other environments
> that might be caught by the same issue? Or in other words, which
> syscalls were reported as inacceptable in the kernel log?

The blocked syscall is 68 aka msgget. It is an IPC call used by
fakeroot to communicate the faked permissions. I think allowing more
syscalls in the sandbox is a bad idea.

 * You're whitelisting amd64 syscalls now. Other architectures use
   different numbers and hunting them down for each and every
   architecture is painful.
 * fakeroot uses msgget when used with faked-sysv. For use with
   faked-tcp, you will need socket and connect and stuff.
 * Blocking IPC or network was exactly the job of seccomp. If you allow
   these calls, you are significantly weakening the sandbox.
 * Have you tried faketime, fakechroot, eatmydata, ...?

Let me propose a much simpler option: Check for the presence of
LD_PRELOAD and imply -S when it is non-empty.

Helmut

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

Jonathan Nieder  writes:

> In Git, when you "git clone" a repository, that represents a single
> codebase.  There is no parameter you can pass to "git clone" that
> tells it to clone just a subdirectory.  So we aren't including the
>  in Vcs-Git in order to determine what parameters to pass to
> "git clone".

> Given that, what *are* we including the  for?

If you want to do what vcswatch is doing (analyze the current code
repository for Debian packaging for commits that haven't been uploaded),
and the team is, like Haskell, using a single repository for all the
packages, you need to be able to find that specific package in the
repository to look for unreleased changes.

Similarly, dgit presumably wants to be able to find the part of the
repository that's used for packaging a specific package, and I assume Ian
is thinking about doing some dark magic to make that work with the rest of
dgit's workflow (although I don't know what that is, or how it would work
with, e.g., dgit tagging).

> And similarly, what is the use case behind the other key/value pairs
> described here?

We don't know, but we've now had to add two different things we didn't
anticipate, and so it seems like a reasonable assumption there may be
more.

> It's possible that it might make sense to use separate fields for this
> information --- e.g. a

>   Vcs-Git-Path: 

> or something like that.  That way, you get extensibility for free.

This is definitely true, and if I were paying more attention when this
first came up and had thought of it, I'd probably recommend that.  But I
think the water is already under the bridge since the bracket syntax is
already being used, and I'm not sure it's worth asking them to change
something that's already implemented in at least a couple of places.

> Alternatively, maybe there is a lurking Git feature request here, for
> example for an atomic view across multiple repositories, or for the
> ability to clone just a subdirectory of a repository (with
> https://crbug.com/git/2 you already almost have that, though it's fussy
> to set up sparse checkout to do it and you still have to "cd" into the
> subdirectory).

Being able to clone a subdirectory of a Git repository would be lovely,
speaking as someone who works at a company that insists on using a
monorepo.  I think that's a pretty long-standing feature request, though.

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

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Jonathan Nieder]

Russ Allbery wrote:

> If you want to do what vcswatch is doing (analyze the current code
> repository for Debian packaging for commits that haven't been uploaded),
> and the team is, like Haskell, using a single repository for all the
> packages, you need to be able to find that specific package in the
> repository to look for unreleased changes.

Thanks.  Once someone writes some proposed text, it seems like it would
be worth mentioning this kind of use case in it.

> Similarly, dgit presumably wants to be able to find the part of the
> repository that's used for packaging a specific package, and I assume Ian
> is thinking about doing some dark magic to make that work with the rest of
> dgit's workflow (although I don't know what that is, or how it would work
> with, e.g., dgit tagging).

*nod*

>> And similarly, what is the use case behind the other key/value pairs
>> described here?
>
> We don't know, but we've now had to add two different things we didn't
> anticipate, and so it seems like a reasonable assumption there may be
> more.

For command line options like "-b", I would be okay with following the
same model as last time and using space as a source of extensibility
(i.e., breaking compatibility).  So for that I wouldn't want to use
the bracket syntax.

For future settings in the same spirit as  that don't involve
command line options, or for command-line options that are okay to
ignore, the

  Vcs-Git-Whatsit: 

approach should work okay.

So I'm thinking the bracketed path might be enough here, without need
for the additional complexity of in-field key/value pairs.

[...]
> Being able to clone a subdirectory of a Git repository would be lovely,
> speaking as someone who works at a company that insists on using a
> monorepo.

Interesting.  That's helpful context.

>I think that's a pretty long-standing feature request, though.

No one's filed it at bugs.debian.org/git or https://crbug.com/git yet.
But there's a similar internal feature request at $DAYJOB.  Thanks for
indulging my questions.

Jonathan

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

Jonathan Nieder  writes:

> For command line options like "-b", I would be okay with following the
> same model as last time and using space as a source of extensibility
> (i.e., breaking compatibility).  So for that I wouldn't want to use
> the bracket syntax.

> For future settings in the same spirit as  that don't involve
> command line options, or for command-line options that are okay to
> ignore, the

>   Vcs-Git-Whatsit: 

> approach should work okay.

> So I'm thinking the bracketed path might be enough here, without need
> for the additional complexity of in-field key/value pairs.

Yeah, this is a pretty good point, and it decreases the complexity of the
syntax a fair bit.  Ian, what do you think about making the extensibility
model for any future thing be add another field?

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

Bug#932643: [pkg-cryptsetup-devel] Bug#932643: cryptsetup upgrade causes cryptsetup-initramfs autoremoval and boot failure

[Ben Caradoc-Davies]

On 22/07/2019 13:09, Guilhem Moulin wrote:

Ooops.  We don't want ‘cryptsetup’ to hard-depend on ‘cryptsetup-initramfs’,
as that would make the 2:2.0.3-1 package split moot.  I just uploaded
2:2.1.0-7 where ‘cryptsetup’ *Recommends* ‘cryptsetup-initramfs’, which
is enough to convince APT not to auto-remove the latter upon `apt
upgrade --autoremove`.


Thanks, Guilhem. Confirmed fixed in 2:2.1.0-7.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#932780: live-task-standard should not depend on hdparm

[Daniel Lewart]

Package: src:live-tasks
Version: 0.7
Severity: normal
Tags: patch

Dear Live Systems Maintainers,

#891635 - override: hdparm:admin/optional:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891635
changed hdparm priority from standard to optional.

Therefore, live-task-standard should not depend on hdparm.

Untested patch below.

Thank you!
Daniel Lewart
Urbana, Illinois
---
diff -ru a/debian/control b/debian/control
--- a/debian/control2019-05-24 04:59:42.0 -0500
+++ b/debian/control2019-07-23 00:00:00.0 -0500
@@ -386,7 +386,6 @@
file,
gettext-base,
groff-base,
-   hdparm,
krb5-locales,
libc-l10n,
liblockfile-bin,

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Sean Whitton]

Hello,

On Mon 22 Jul 2019 at 07:55PM +01, Ian Jackson wrote:

> That means the original "uploader" information (ie the identity of the
> person signing the git tag) is not any more present in the source
> package.  To rememdy that I propose the following new field:
>
>   Git-Tag-Info: FINGERPRINT Firstname Surname 
>
> The parsing rules are: the first word is the fingerprint entirely in
> hex.  The rest is from the tag's "tagger" line (and may not match).

AIUI a fingerprint fails to uniquely identify a PGP key unless you also
include the cryptographic algorithm that was used and the key size.  So
for example, my current key is uniquely identified by writing both 4096R
and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.

Even though it's unlikely we'll get a clash of fingerprints within the
Debian keyring, it seems the algorithm and keysize ought to be included
alongside the fingerprint, if the above is right.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#932781: gnome-shell crashed on laptop lid close

[Vasudev Kamath]

Package: gnome-shell
Version: 3.30.2-9
Severity: important

Dear Maintainer,

Closing laptop lid normally puts laptop sleep and I get back my session on 
reopen. But after recent update
I see that I get logged out and closer inspection revealed that gnome-shell is 
crashing with following error

[  746.169795] gnome-shell[13847]: segfault at 2300022 ip 7f3718787e04 
sp 7ffd56a0f0b0 error 4 in libwayland-server.so.0.1.0[7f3718787000+7000]

I managed to get the coredump and backtrace of the same. I'm attaching it with 
this bug report.

Cheers,
Vasudev


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1.1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.33.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.3-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-3
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.10-1
ii  gir1.2-gweather-3.0  3.28.3-1
ii  gir1.2-ibus-1.0  1.5.19-4+b1
ii  gir1.2-mutter-3  3.30.2-7
ii  gir1.2-nm-1.01.18.0-3
ii  gir1.2-nma-1.0   1.8.22-2
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1+b1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-9
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1.1
ii  libedataserver-1.2-233.30.5-1.1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1+b1
ii  libglib2.0-0 2.60.5-1
ii  libglib2.0-bin   2.60.5-1
ii  libgstreamer1.0-01.16.0-2
ii  libgtk-3-0   3.24.10-1
ii  libical3 3.0.5-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-7
ii  libnm0   1.18.0-3
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0  241-7
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-7
ii  python3  3.7.3-1

Versions of packages gnome-shell recommends:
ii  bolt  0.7-2
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.30.2-3
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.30.3-1
ii  gnome-user-docs   3.30.2-1
ii  iio-sensor-proxy  2.4-2
ii

Bug#932760: RM: qct - ROM; Upstream Inactive; Affected by Qt4/Python2 Removal

[Vincent Danjean]

Le 22/07/2019 à 21:32, Boyuan Yang a écrit :
> Package: ftp.debian.org
> Severity: normal
> User: ftp.debian@packages.debian.org
> Usertags: remove
> X-Debbugs-CC: vdanj...@debian.org
> 
> Dear FTP Masters,
> 
> Package qct has an inactive upstream since 2011 and is using Qt4 and Python2
> currently, which are due to be removed. The original package maintainer has
> filed an RFA bug back in 2016, in which suggested to remove this package ( 
> https://bugs.debian.org/827169 ). I think 3 years later it's appropriate to
> have it removed in the Bullseye cycle.

As the package maintainer, I approve this request for removal.

  Thanks to all of you
  Regards,
Vincent

> Thanks,
> Boyuan Yang
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main