Bug#939960: libprelude: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: libprelude
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939770: wireshark: Wrong path in pre-install notification

[Balint Reczey]

Control: tags -1 pending

Hi Justin,

On Mon, Sep 9, 2019 at 8:49 PM Justin B Rye  wrote:
>
> Balint Reczey wrote:
> > Justin B Rye wrote:
> >> So instead of saying "after the package installation is finished" you
> >> might change it to something like:
> >>
> >>   For more detailed information please see
> > - /usr/share/doc/wireshark-common/README.Debian.
> > > + /usr/share/doc/wireshark-common/README.Debian.gz once the package is
> >> + installed.
> >
> > Good point. Can I apply this change as the one reviewed?
>
> If you're asking whether you can regard this as having received an
> official debian-l10n-english review, sure, as far as I'm concerned
> it's okay whether you include my bikeshedding or not.

Thanks, I pushed your proposal to the packaging repository:
https://salsa.debian.org/debian/wireshark/commit/4d21f2d33430229c693cf2999e50939a0eaf6cea

Cheers,
Balint

> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#939959: libtasn1-6: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Package: libtasn1-6
Version: 4.13-3
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939898: glibc: new getegid, geteuid and getppid syscalls used unconditionally on alpha

[Aurelien Jarno]

control: retitle -1 glibc: new getegid, geteuid and getppid syscalls used 
unconditionally on alpha

On 2019-09-10 09:27, Adhemerval Zanella wrote:
> 
> 
> On 10/09/2019 07:28, John Paul Adrian Glaubitz wrote:
> > On 9/10/19 11:05 AM, John Paul Adrian Glaubitz wrote:
> >> Yes, we have already figured out that this happens when the kernel is
> >> too old. According to Aurelien, the problem is that the glibc package
> >> has been built against the kernel 5.3 headers which is why users need
> >> to upgrade their kernel first before upgrading glibc.
> >>
> >> Currently fixing tsunami.
> > 
> > I have now kernel 5.2.9-1 and glibc 2.29-1 and logging in still doesn't
> > work. I type "root" at the login prompt, press enter and it shortly
> > returns to the login prompt. Logging in through SSH doesn't work either.
> > 
> > Adrian
> > 
> 
> I have consolidate the set* Linux implementations on dd5905de03bd2 
> (glibc 2.26), which means that all Linux architectures should use
> sysdeps/unix/sysv/linux/setuid.c for setuid and the auto-generated
> syscalls for getuid.
> 
> Alpha use the linux generic implementation since ever, the 
> dd5905de03bd2 change it will prioritize to use __NR_setuid32 instead
> of __NR_setuid. But since it is not the case for alpha AFAIK it should
> not change the code generation. I also checked that the code for
> setuid for both glibc 2.25 and glibc 2.31 hasn't change, it issues the
> __NR_setuid (23) for both cases.

The title of the bug is actually misleading, only getegid, geteuid and
getppid are affected. Let's retitle the bug accordingly.

> I am not sure this is an glibc issue in this case.

This is actually glibc issue, see:
https://sourceware.org/bugzilla/show_bug.cgi?id=24986
https://www.sourceware.org/ml/libc-alpha/2019-09/msg00152.html

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

Bug#939588: uim package lacks 2 files

[NIDE, Naoyuki]

In Message ,
Takatsugu Nokubi  writes:
> What Japanese engines do you use? I had uim-anthy and uim-mozc, and it works.

I use uim-anthy. If /var/lib/uim/{installed-modules,loader}.scm are
disappeared, uim-toolbar does not work properly, and I cannot switch
input system to anthy.

> I tried to upgrade a stretch machine to buster, but the problem is not
> reploduced.
> Those files are generated by uim-module-manager, and the command is
> invoked by maintainer scripts.

For test, I installed stretch, and upgraded it to buster. After that,
some stretch packages which have been removed during upgrading to buster
leaved conf files.

buster$ dpkg -l | egrep -v ^ii
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version 
Architecture Description
+++-=-===--===
rc  libreoffice-style-galaxy  1:5.2.7-1+deb9u11   all   
   office productivity suite -- Galaxy (Default) symbol style
rc  libsensors4:amd64 1:3.4.0-4   amd64 
   library to read temperature/voltage/fan sensors
rc  libuim-data   1:1.8.6+gh20161003.0.d63dadd-2  all   
   Universal Input Method - data files

Then I purged these packages.

buster# apt-get purge $(dpkg -l | awk '$1=="rc"{print $2}')

Then, when libuim-data is purged, /var/lib/uim/installed-modules.scm
and /var/lib/uim/loader.scm are disappeared, since the postrm script of
libuim-data deletes them.
This was the cause why these files disappeared in my environment.

Since /var/lib/uim/{installed-modules,loader}.scm are still used by uim,
I think that the postrm script of libuim-data should not delete these files
after upgrading to buster.

Bug#939957: libpreludedb: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: libpreludedb
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939958: librsvg: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: librsvg
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939956: liblangtag: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: liblangtag
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939955: libdbusmenu: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: libdbusmenu
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939954: libccss: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: libccss
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939951: keybinder-3.0: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: keybinder-3.0
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939953: kylin-burner: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: kylin-burner
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939949: sleepyhead: B-D on cruft package

[Esa Peuha]

Source: sleepyhead
Version: 1.0.0-beta-2+dfsg-6
Severity: serious

Currently sleepyhead build-depends on libquazip5-headers, which is
no longer built from source as its contents have been merged into
libquazip5-dev, thus making sleepyhead unbuildable since these two
packages are not coinstallable. Please remove the build-dependency
on libquazip5-headers.

Bug#939950: hkl: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: hkl
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#939952: keybinder: fails to build with gtk-doc 1.32

[Andreas Henriksson]

Source: keybinder
Severity: important
Control: block 939500 by -1

Hello,

Your package seems to fail to build from source with the new gtk-doc-tools 1.32 
(currently in experimental).
The issue seems to be that your sgml files include a file that's no longer 
being generated when there's no content to put in it.

https://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187

"... As a notable change we don't output empty tree_index files
anymore."


The build failure snippet looks something similar to this:

warning: failed to load external entity "../xml/tree_index.sgml"
../foobar.sgml:63: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found

Possible solutions could be:
- remove the lines referencing the non-existant (and previously empty) 
tree_index.sgml file.
- extend the include of tree_index.sgml with additional  tags.

For an example of the first alternative see:
https://salsa.debian.org/gnome-team/brasero/blob/f38e3a5838157432799c0ee29cebcca334af8f5a/debian/patches/0002-Stop-referencing-empty-Object-Hierarchy.patch

Regards,
Andreas Henriksson

Bug#932169: dante-server: systemd fails to start danted service

[Lukas Anzinger]

Hi,

I can confirm this behavior on armhf. Removing "lib64" from the
danted.service file fixes it.

Lukas

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[Adhemerval Zanella]

On 10/09/2019 07:28, John Paul Adrian Glaubitz wrote:
> On 9/10/19 11:05 AM, John Paul Adrian Glaubitz wrote:
>> Yes, we have already figured out that this happens when the kernel is
>> too old. According to Aurelien, the problem is that the glibc package
>> has been built against the kernel 5.3 headers which is why users need
>> to upgrade their kernel first before upgrading glibc.
>>
>> Currently fixing tsunami.
> 
> I have now kernel 5.2.9-1 and glibc 2.29-1 and logging in still doesn't
> work. I type "root" at the login prompt, press enter and it shortly
> returns to the login prompt. Logging in through SSH doesn't work either.
> 
> Adrian
> 

I have consolidate the set* Linux implementations on dd5905de03bd2 
(glibc 2.26), which means that all Linux architectures should use
sysdeps/unix/sysv/linux/setuid.c for setuid and the auto-generated
syscalls for getuid.

Alpha use the linux generic implementation since ever, the 
dd5905de03bd2 change it will prioritize to use __NR_setuid32 instead
of __NR_setuid. But since it is not the case for alpha AFAIK it should
not change the code generation. I also checked that the code for
setuid for both glibc 2.25 and glibc 2.31 hasn't change, it issues the
__NR_setuid (23) for both cases.

I am not sure this is an glibc issue in this case.

Bug#938952: [debian Buster] [arm64 pinebook] [sysvinit-core] libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not going to be installed

[Dmitry Bogatov]

[2019-09-08 17:53] Jean-Marc LACROIX 
>  > Please:
>  >
>  >   * Try installing something else, like `tor'. I expect you will get
>  > similar error (`tor' depends on libsystemd0, sigh)
>
> ansible@pinebook:~$ sudo apt install tor
> [...]

Okay, tor installs fine with your apt-pinning. My guess was wrong.

> ansible@pinebook:~$ dpkg -l |grep -v ii
> Desired=Unknown/Install/Remove/Purge/Hold
> | 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ NameVersion 
>  Architecture Description
> +++-===---===
> 
> ansible@pinebook:~$ dpkg -l |grep systemd
> ii  dbus-user-session 
> 1.12.16-1arm64simple interprocess messaging 
> system (systemd --user integration)
> ii  libpam-systemd:arm64241-5 
>  arm64system and service manager - PAM module
> ii  libsystemd0:arm64   241-5 
>  arm64systemd utility library
> ii  syslog-ng-mod-journal   3.19.1-5 
>  arm64Enhanced system logging daemon 
> (systemd journal plugin)
> ii  systemd 241-5 
>  arm64system and service manager
> ii  systemd-sysv241-5 
>  arm64system and service manager - SysV links

Okay, on this stage you have systemd as pid1 implementation.

> [...]
> Now, according Debian doc, i try to install sysvinit

Which exactly doc? I guess it needs to be adjusted.

> ansible@pinebook:~$ sudo apt install sysvinit sysvinit-utils
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package sysvinit is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> However the following packages replace it:
>sysvinit-core:armhf systemd-sysv:armhf sysvinit-core systemd-sysv
>
> E: Package 'sysvinit' has no installation candidate
>
> It seems on Debian 10.1, there is now one new package name ?
> [...]

There were no package renaming at least last year.

> ansible@pinebook:~$ sudo apt install sysvinit-core sysvinit-utils
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> sysvinit-utils is already the newest version (2.93-8).
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>   dconf-service : Depends: default-dbus-session-bus or
>dbus-session-bus
>   libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not 
> going to be installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be 
> caused by held packages.

Wait, do you have installation of "recommends" disabled? If I try to
install "dconf-service" on my system (antiX + Devuan + Debian,
pid1=runit-init), I too get resolution error, but

 # apt-get install dconf-service --no-install-recommends

resolves fine. Please, try this. Otherwise, your better bet would
be to reassign to libelogind or dbus or something like this.
sysvinit-core only depends on libc and libselinux (sigh), so it can't
cause conflicts with packages you show.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#939768: gimp: Downgrading gimp to 2.10.8-2 to ensure GEGL compatibility doesn't fix bug

[Lancelot PECQUET]

Package: gimp
Version: 2.10.8-2
Followup-For: Bug #939768

Dear Maintainer,

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

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

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

gimp 2.10.8-2+b1 crashed every time I tried to launch an image.

I read the comments in the current thread and downgraded gimp
(apt install gimp=2.10.8-2) to ensure GEGL compatibility.

Now gimp crashes only for some images. Here is the following trace.



```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13)

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.60.6 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```
/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7feebe5b2f98]
gimp(+0xd14a0)[0x55f3215754a0]
gimp(+0xd18d8)[0x55f3215758d8]
gimp(+0xd2037)[0x55f321576037]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7feebdaab730]
/usr/lib/x86_64-linux-gnu/babl-0.1/cairo.so(+0x14c4)[0x7feebebb94c4]
/usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0(+0x8701)[0x7feebde7b701]
/usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0(+0x8739)[0x7feebde7b739]
/usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0(babl_process+0x16)[0x7feebde7ca06]
/usr/lib/libgimpcolor-2.0.so.0(gimp_color_transform_process_buffer+0x1b6)[0x7feebe5e14f6]
gimp(gimp_view_renderer_render_temp_buf+0x64e)[0x55f3217690fe]
gimp(+0x2c81ac)[0x55f32176c1ac]
gimp(+0x2c3591)[0x55f321767591]
gimp(gimp_view_renderer_draw+0xc7)[0x55f321768727]
gimp(+0x2be957)[0x55f321762957]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x1331eb)[0x7feebe8051eb]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0xb1)[0x7feebdd76da1]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x26dad)[0x7feebdd89dad]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x47b)[0x7feebdd92b9b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7feebdd93b6f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x249cac)[0x7feebe91bcac]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x17e)[0x7feebe78b4ae]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8410a)[0x7feebe75610a]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0xb7f9b)[0x7feebe789f9b]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x1331eb)[0x7feebe8051eb]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0xb1)[0x7feebdd76da1]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x26dad)[0x7feebdd89dad]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x47b)[0x7feebdd92b9b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7feebdd93b6f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x249cac)[0x7feebe91bcac]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_container_propagate_expose+0x17e)[0x7feebe78b4ae]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0xf4f5b)[0x7feebe7c6f5b]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0xb7f9b)[0x7feebe789f9b]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0xf55af)[0x7feebe7c75af]

Bug#914336: netperfmeter: bogus debian/tests/control file

[Thomas Dreibholz]

Hi,

the problem is solved in the latest upstream version 1.8.5. I created an
updated package on the mentors server:
https://mentors.debian.net/package/netperfmeter . It requires a Debian
sponsor to upload it.

Den 22.11.2018 13:15, skrev Paul Gevers:
> Source: netperfmeter
> Version: 1.8.0-1
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: issue
> 
> Dear maintainer,
> 
> Recently you added (or at least you tried to add) an autopkgtest to you
> package. However, the current content of debian/tests/control is bogus.
> 
> Please read the spec [1] and adapt the control file or drop the file if
> you didn't intent to add a test.
> 
> Paul
> 
> [1]
> https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#939947: RFS: netperfmeter/1.8.5-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "netperfmeter":

Package name: netperfmeter
Version: 1.8.5-1
Upstream Author: Thomas Dreibholz 
URL: https://www.uni-due.de/~be0001/netperfmeter/
License: GPL-3+
Section: net

NetPerfMeter is a network performance meter for the UDP, TCP, MPTCP,
SCTP and DCCP transport protocols over IPv4 and IPv6. It simultaneously
transmits bidirectional flows to an endpoint and measures the resulting
flow bandwidths and QoS. The results are written as vector and scalar
files. The vector files can e.g. be used to create plots of the results.

"netperfmeter" builds these binary packages:

netperfmeter - Network Performance Meter (measurement program)
netperfmeter-plotting - Network Performance Meter (plotting program)
pdfproctools - PDF Processing Tools

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/netperfmeter.

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

dget -x
https://mentors.debian.net/debian/pool/main/n/netperfmeter/netperfmeter_1.8.5-1.dsc

More information about "netperfmeter" can be obtained from
https://www.uni-due.de/~be0001/netperfmeter/.

Most recent changelog entry:

netperfmeter (1.8.5-1ubuntu1) eoan; urgency=medium

New upstream release.
Renamed pdfmetadata to setpdfmetadata (Closes: #914333).
Added missing test script (Closes: #914336).

-- Thomas Dreibholz  Tue, 10 Sep 2019 14:46:09 +0300

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#939941: The solution

[JB]

I found the issue: yesterday I had been trying to see if another monitor was 
working on this particular machine, and shut it down.

The thing is: this particular monitor had precedence over all others and so, 
gdm was displaying the "primary" screen to this monitor. Since it was shut 
down, I was not obvious that it was taken into account.

Anyway, sorry for the inconvenience. It seems that all the "NVRM: Xid" errors 
were linked to this monitor being connected and not turned on, because there is 
no errors of this kind now.

Sorry again for pulling the trigger too soon.

Cheers,

JB

Bug#939946: telepathy-logger: missing python build-dependency causes FTBFS with gtk-doc-tools 1.32

[Andreas Henriksson]

Source: telepathy-logger
Severity: important
Control: block 939500 by -1

Dear Maintainer,

The telepathy-logger package seems to require python(2) during build,
but relies on gtk-doc-tools to actually pull in python.  This causes a
failure to build from source when building with the new gtk-doc-tools
1.32 (currently in experimental).
(The new gtk-doc-tools has been fully ported to python3 and no longer
pulls in python(2).)

Snippet from the build log:

make[3]: Entering directory '/build/telepathy-logger-0.8.2/extensions'
/bin/mkdir -p _gen
/usr/bin/python3 ../tools/xincludator.py all.xml > _gen/all.xml
Traceback (most recent call last):
  File "../tools/xincludator.py", line 36, in 
xincludate(dom, argv[0])
  File "../tools/xincludator.py", line 14, in xincludate
for i in xrange(dom.documentElement.attributes.length):
NameError: name 'xrange' is not defined
make[3]: *** [Makefile:936: _gen/all.xml] Error 1
make[3]: Leaving directory '/build/telepathy-logger-0.8.2/extensions'
make[2]: *** [Makefile:489: all-recursive] Error 1
make[2]: Leaving directory '/build/telepathy-logger-0.8.2'
make[1]: *** [Makefile:420: all] Error 2
make[1]: Leaving directory '/build/telepathy-logger-0.8.2'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:6: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

My conclusion is that it seems the tools/xincludator.py file is a
python2 (only) script, not compatible with python3.  The reason the
shebang in that file (which references python(2)) is not used, is
because it's invoked as "python3 ../tools/..." rather than directly
executing the script. The reason python3 is used here is because the
Makefile(.am) specifies $(PYTHON) which is set via AM_PATH_PYTHON in
configure(.ac) which will find python3 since python(2) is nowhere to be
found.

This issue could simply be fixed by adding the missing python (or
python:any) build-dependency. However, there's currently ongong work to
remove python2 from bullseye so a better solution would be to properly
port to python3 (and get rid of python(2) dependency).

Regards,
Andreas Henriksson

Bug#939926: This is only on Wayland

[Dennis van Dok]

The bug should probably be tagged for Wayland; since I switched back to Gnome 
on X11 the problem
is gone. (As well as some other problems. This Wayland thing is not ready for 
prime time.)

Bug#830726: Regrabbing(was: Re: Bug#830726: xtrlock: CVE-2016-10894: xtrlock does not block multitouch events)

[Chris Lamb]

[adding x...@lists.x.org to CC, dropping t...@security.debian.org; please 
retain all CCs]

Dear Xorg developers,

> […]

I recently became a co-maintainer for the xtrlock screen locking
utility. As part of this, I noticed a bug report filed by Antoine
Amarilli which points out that so-called multitouch events are not
blocked when xtrlock is enabled:

  https://bugs.debian.org/830726

This means that some applications (notably Chromium) can still be
controlled even when the machine is locked down.

When I looked at the code and the documentation regarding multitouch
events, this was "to be expected" due to it only calling the
XGrabPointer function. I therefore extended the code to enumerate over
all multitouch devices and lock them too via XIGrabDevice as part of
the version 2 of the X Input Extensions:

  https://bugs.debian.org/830726#43

However, Antoine then pointed out that this would not prevent an
attacker plugging in such a multitouch device *after* xtrlock has
been started and thus permit controlling the desktop. I thus revised
the patch to detect the introduction of the new device via the
XI_HierarchyChanged event:

  https://bugs.debian.org/830726#65

This appeared to work initially but we were seeing some strange
behaviour where the touchscreen is not "correctly" grabbed; one can
still work around the grab using multiple fingers (eg. press
somewhere, then interact with Chromium) but some even weirder
behaviour whereby grabs will persist *after* the xtrlock process has
ended! For more detail about this, please see:

  https://bugs.debian.org/830726#90

I would be interested in your input here. Hopefully I am doing
something obviously bogus which you will be able to point out for a
quick and easy fix but I have a gut feel something deeper is awry
given that locks persist beyond the end of the process.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#939945: frei0r-plugins-dev: frei0r.pc is not located correctly

[Kate]

Package: frei0r-plugins-dev
Severity: major

Dear Maintainers,

frei0r-plugins-dev contains a file named frei0r.pc used by pkg-config.
However the location for this file has changed since testing.
In stable it was in /usr/lib/pkgconfig which seems correct but it doesn't seem 
to be where most .pc files are located.
In testing and unstable it is located in /usr/share/pkgconfig/pkgconfig which 
is not correct, it should be /usr/share/pkgconfig (where most .pc are located)

As a consequence, the frei0r library cannot be used in testing and sid.

Kind regards,
Kate

Bug#939944: dput: make chown 0644 optional

[Dmitry Bogatov]

Package: dput
Version: 1.0.3
Severity: wishlist

Dear Maintainer,

Today I spent some time debugging why upload to my private server get
0644 permissions, no matter how I change permissions of built packages
and no matter how I tweak umask on both sending and receiving hosts.

Problem is following code (scp.py:53)

if change_mode:
fix_command = ['ssh']
for anopt in ssh_config_options:
fix_command += ['-o', anopt]
fix_command += [
'%s%s' % (login_spec, fqdn), 'chmod', '0644'
] + files_to_fix
if debug:
sys.stdout.write("D: Fixing some permissions\n")
sys.stdout.write("D: %s\n" % fix_command)
exit_status = dputhelper.check_call(fix_command)
if exit_status != dputhelper.EXIT_STATUS_SUCCESS:
sys.stdout.write("Error while fixing permissions.\n")
sys.exit(1)

Please, make this behavior optional. It is not documented (or I failed
spectacularly at finding documentation), causes major headache when I
need files to have another (664) permissions and makes `dput` report
error, if remote host allows scp/rsync execution, but not arbitrary
commands.


pgp3XzRhiyUkF.pgp
Description: PGP signature

Bug#939939: libterm-choose-perl: testsuite failures

[gregor herrmann]

On Tue, 10 Sep 2019 13:08:48 +0200, Gianfranco Costamagna wrote:

> Hello, since your last upload the testsuite is now failing.
> https://ci.debian.net/packages/libt/libterm-choose-perl/testing/amd64

Hm, how I love failures somewhere else when it worked for me locally
…
 
> https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libterm-choose-perl/2922560/log.gz

# tput: No value for $TERM and no -T specified

Oh, I see. That's indeed new and kind of makes sense.
 
> thanks for having a look

Thanks for your bug report.


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
   `-   BOFH excuse #391:  We already sent around a notice about that. 

Bug#939943: draft7 support missed, needed version 3

[Fabio Fantoni]

Package: python-jsonschema
Version: 2.6.0-4
Severity: wishlist

Hi, some python3 softwares uses draft7 but in actual packages version is 
missed, version 3.0 (latest is 3.0.2) is needed.
Can you package the new version please?

Thanks for any reply and sorry for my bad english.

Bug#939942: php-pecl-http; undefined symbol: uidna_IDNToASCII

[Dima Lytvyn]

Package: php-pecl-http
Version: Version: 3.2.1+2.6.0-1+ubuntu16.04.1+deb.sury.org+1

After upgrading from pecl_http-3.2.0+2.6.0-1+ubuntu16.04.1+deb.sury.org+10
- > pecl_http-3.2.1+2.6.0-1+ubuntu16.04.1+deb.sury.org+1  I get an error
message:

php7.1: symbol lookup error: /usr/lib/php/20160303/http.so: undefined
symbol: uidna_IDNToASCII

Reproduce:

getRequest('http://google.com', 500);
$pool->waitOnAll();

Thanks.

Bug#939941: Adding details to bug #939941

[JB]

Out of desperation, I went and purged everything labelled as nvidia on my 
system.

After rebooting, and nouveau being not blacklisted anymore,
I was surprised to see that I had the same issue.

Indeed, nouveau was back:

$ sudo lsmod | grep video
video  45056  1 nouveau

I guess I might have targeted the wrong package with "nvidia-driver" and I am 
sorry for the inconvenience. However, I do not know against which package I 
should submit this bug.

I am sort of lost at the moment because I do know what could have caused this 
issue, especially so suddenly (maybe the hardware became faulty?)

If you have any clue, I would appreciate anything that could point me in the 
right direction.

Cheers,

JB

Bug#852733: Cannot reproduce with 2.2.10

[Jonathan Carter]

I can't reproduce this with the latest version, can you please test with
Bluefish 2.2.10 and confirm whether this still affects you? Thanks.

Bug#939941: Adding details to bug #939941

[JB]

Here is an excerpt of dmesg after a reboot ; as you can see, it does not 
"flood" anymore the ttys with the "NVRM: Xid ... " error but still, I got 
several of them when booting up.

sudo dmesg | grep NVRM
[3.050208] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  418.74  Wed May  
1 11:49:41 CDT 2019
[   59.635526] NVRM: GPU at PCI::01:00: 
GPU-f0e782b4-4a3b-7bc5-6030-fd3d1d9afa12
[   59.635541] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 031c
[   67.836608] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 031d
[   76.024961] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 031e
[   84.215000] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 031f
[   92.405456] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 0320
[  100.596350] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 0321
[  108.787424] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 0322
[  116.978757] NVRM: Xid (PCI::01:00): 16, Head 0002 Count 0323

According to this link (https://docs.nvidia.com/deploy/xid-errors/#topic_4), 
this error refers to a driver error which causes the display engine to hang, 
which seems to be exactly what's affecting my system.

I could try to purge the package nvidia-driver and going back to nouveau to see 
if that works ; let me know if that's something you would be interested in, or 
if I could provide any other detail to help.

Cheers,

JB

Bug#700472: Upgrade of the foreign arch libc6 causes service restart

[Aurelien Jarno]

On 2019-09-09 22:18, Sven Joachim wrote:
> Control: tags -1 + patch
> 
> On 2013-02-13 06:20 +0600, Andrey Rahmatullin wrote:
> 
> > Package: libc6
> > Version: 2.17-0experimental2
> > Severity: wishlist
> >
> > Filing as wishlist, maybe it's minor or even worse for some people.
> >
> > The postinst script of libc6 checks services that need to be restarted not
> > taking into account that those services may be of a different arch and so 
> > not
> > using the libc6 being upgraded. That also means when you upgrade both
> > libc6:amd64 and libc6:i386 you get double restart of all those services.
> 
> Today, upgrading libc6:amd64 and libc6:i386 to 2.29-1, I got annoyed by
> this again and had a look what needs to be done.  The attached patch
> (lightly tested, I have only a few amd64 and no i386 services running)
> appears to do the trick.  It also drops the need for awk in the
> maintainer scripts.
> 
> Feedback and brave testers welcome!

Thanks for the patch, I have just applied it.

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

Bug#844449: Cannot reproduce

[Jonathan Carter]

Can you please check whether this still happens for you? I have tried
with version 2.2.10 and this doesn't seem to happen anymore. Thanks.

Bug#939940: libvirt-sandbox: missing python build-dependency causes FTBFS with gtk-doc-tools 1.32

[Andreas Henriksson]

Source: libvirt-sandbox
Severity: important
Control: block 939500 by -1

Dear Maintainer,

The libvirt-sandbox package seems to require python(2) during build, but relies 
on gtk-doc-tools to pull in python.
The new gtk-doc-tools (currently in experimental) has been ported to python3 
and no longer pulls in python2.
This makes libvirt-sandbox fail to build from source.

The simplest solution might be to just add python (or python:any) to 
build-dependencies, but please also note
that python2 is set to be removed from bullseye so porting to python3 is the 
preferred solution.
(See #936935 for detailed info on python2 removal.)

Regards,
Andreas Henriksson

Bug#935250: , #935252: buster-pu: mutter, gnome-shell

[Simon McVittie]

On Wed, 21 Aug 2019 at 08:41:31 +0100, Simon McVittie wrote:
> I uploaded some mutter fixes to unstable after the buster release which
> I think would be worth considering for a buster update - perhaps for
> 10.2 rather than 10.1 at this point.

On Wed, 21 Aug 2019 at 08:44:47 +0100, Simon McVittie wrote:
> I uploaded some GNOME Shell fixes to unstable after the buster release
> which I think would be worth considering for a buster update - perhaps
> for 10.2 rather than 10.1 at this point.

The GNOME team is starting to upload GNOME 3.34 to unstable, so these
3.30.x updates have had as much testing in testing/unstable as they are
going to get. I haven't seen any regression reports, either from
testing/unstable users or after asking stable users to test a prerelease.

Do these changes seem OK to upload to proposed-updates now
that 10.1 is out? Early in the cycle is probably a good time,
to get as much opportunity as possible for people to try them via
proposed-updates. Please let me know if any of the upstream fixes are
considered too intrusive and need to be reverted.

Test binaries for amd64 which should be equivalent to the version I have
prepared for proposed-updates (but with a slightly lower version number):
https://people.debian.org/~smcv/201908/mutter/
https://people.debian.org/~smcv/201908/gnome-shell/

Thanks,
smcv

Bug#939941: nvidia-driver: "display engine hung" error at boot with gdm background frozen

[Julien-Benjamin]

Package: nvidia-driver
Version: 418.74-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

   * What led up to the situation?
I tried to boot up my machine and ended up having the X server frozen on the
background of gdm.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to reboot.
   * What was the outcome of this action?
It did not work.
   * What outcome did you expect instead?
To be able to reach the login screen of gdm.

I switch to tty2 to try to see the logs and happened to see there was an
error, apparently between the X server and the Nvidia proprietary driver.
This problem flooded the ttys with this error on the standard output of 
each tty (do not know why).

I will send more details from a different machine after submitting this bug.

Cheers,

JB

-- Package-specific info:
uname -a:
Linux jul-desktop 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 
GNU/Linux

/proc/version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  418.74  Wed May  1 11:49:41 CDT 
2019
GCC version:  gcc version 8.3.0 (Debian 8.3.0-6) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 
970] [10de:13c2] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] GM204 [GeForce GTX 
970] [1462:3160]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Sep 10 12:36 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Sep 10 12:36 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Sep 10 12:36 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Sep 10 12:36 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Sep 10 12:36 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Sep 10 12:36 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Sep 10 12:36 pci-:01:00.0-render -> ../renderD128
video:x:44:jul

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Sep 10 12:34 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Feb 16  2019 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   49 Sep 10 12:34 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   51 Sep 10 12:34 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Feb 16  2019 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Feb 16  2019 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Sep 10 12:34 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   48 Sep 10 12:34 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Sep 10 12:34 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Sep 10 12:34 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   55 Feb 16  2019 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 Feb 16  2019 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 Sep 10 12:34 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   55 Sep 10 12:34 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Sep 10 12:34 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Sep 10 12:34 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   52 Feb 16  2019 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root 

Bug#939939: libterm-choose-perl: testsuite failures

[Gianfranco Costamagna]

Source: libterm-choose-perl
Version: 1.700-1
Severity: serious

Hello, since your last upload the testsuite is now failing.
https://ci.debian.net/packages/libt/libterm-choose-perl/testing/amd64

https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libterm-choose-perl/2922560/log.gz

thanks for having a look

Gianfranco

Bug#939938: harfbuzz: missing python build-dependency causes FTBFS with gtk-doc 1.32

[Andreas Henriksson]

Source: harfbuzz
Severity: important
Control: block 939500 by -1

Dear Maintainer,

The harfbuzz package fails to build from source when built using gtk-doc-tools 
1.32 (currently available in experimental).
The problem seems to be that harfbuzz uses python(2) during build, but relies 
on gtk-doc-tools to pull in python.
(The newer gtk-doc-tools version in experimental has been fully ported to 
python3 and no longer pulls in python(2).)

The simplest solution might be to just add python (or python:any) to 
build-dependencies, but please also note that
python2 will be removed during bullseye so solving this issue by porting to 
python3 would be preferable.

Regards,
Andreas Henriksson

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[John Paul Adrian Glaubitz]

On 9/10/19 11:05 AM, John Paul Adrian Glaubitz wrote:

Yes, we have already figured out that this happens when the kernel is
too old. According to Aurelien, the problem is that the glibc package
has been built against the kernel 5.3 headers which is why users need
to upgrade their kernel first before upgrading glibc.

Currently fixing tsunami.


I have now kernel 5.2.9-1 and glibc 2.29-1 and logging in still doesn't
work. I type "root" at the login prompt, press enter and it shortly
returns to the login prompt. Logging in through SSH doesn't work either.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#939937: Remotely exploitable null pointer dereference bug

[Max Kellermann]

Package: libapreq2-3
Version: 2.13-5+b3
Severity: grave

libapreq's multipart parser can be made dereference the null pointer
by issuing a simple CURL command:

 curl http://a/b -F 'foo=bar;type=multipart/dummy'

This POSTs a "multipart/form-data" body where one part has the
Content-Type "multipart/dummy" (i.e. a nested "multipart"), which
enables this branch:

 if (ct != NULL && strncmp(ct, "multipart/", 10) == 0) {

 https://github.com/apache/apreq/blob/v2_13/library/parser_multipart.c#L401

Later, this calls create_multipart_context() and dereferences the
returned pointer (without checking it):

 next_ctx = create_multipart_context(...
 next_ctx->param_name = "";

 https://github.com/apache/apreq/blob/v2_13/library/parser_multipart.c#L409-L414

The function create_multipart_context() however can return NULL if
there is no "boundary" attribute.  And omitting "boundary" is what my
CURL command does.

With this simple exploit, I can remotely crash any process which uses
libapreq2 only by issuing an invalid nested "multipart" body.  Since
this bug is remotely exploitable, I decided to set "grave" severity.

This bug affects all libapreq2 versions ever shipped in Debian, and
was introduced by SVN commit 227276 in 2005.  Prior to this commit,
there was a NULL check, but the commit removed it:

 
http://svn.apache.org/viewvc/httpd/apreq/trunk/library/parser_multipart.c?r1=227276=227275=227276

The attached patch fixes the bug by re-adding the NULL check.
commit f27d15e47000b0442e8071ab0fd76b82df9f2d2f
Author: Max Kellermann 
Date:   Tue Sep 10 12:15:07 2019 +0200

parser_multipart: fix NULL pointer dereference in nested multipart

create_multipart_context() can return NULL if the given Content-Type
was not recognized (if there is no "boundary" attribute).  This
crashes libapreq2.

This bug was introduced by SVN commit 227276.  Prior to this commit,
there was a NULL check, but the commit removed it:

 http://svn.apache.org/viewvc/httpd/apreq/trunk/library/parser_multipart.c?r1=227276=227275=227276

diff --git a/library/parser_multipart.c b/library/parser_multipart.c
index 60b5bad..4242b7e 100644
--- a/library/parser_multipart.c
+++ b/library/parser_multipart.c
@@ -410,6 +410,10 @@ APREQ_DECLARE_PARSER(apreq_parse_multipart)
 parser->brigade_limit,
 parser->temp_dir,
 ctx->level + 1);
+if (next_ctx == NULL) {
+ctx->status = MFD_ERROR;
+goto mfd_parse_brigade;
+}
 
 next_ctx->param_name = "";
 

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Santiago Vila]

reassign 939733 lsb-release
thanks

On Tue, 10 Sep 2019, Jonathan Wiltshire wrote:

> This stems from lsb_release switching to reading the cross-distro
> standard file, /usr/lib/os-release:

Therefore it was lsb_release who changed behaviour, not base-files.

> So arguably base-files should be updating that file with point release
> information, just as /etc/debian_version is. The spec [1] does not rule
> that out, and other distributions do so:

Not ruling out != mandating it.

> Severity upgraded because it causes an unexpected behaviour change in
> lsb_release, but feel free to adjust.

There was already a bug in base-files for this:

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

and it will be considered for bullseye, but the fact that os-release
does not change in Debian is clearly documented in the base-files
changelog:

 base-files (10.2) unstable; urgency=medium
 [...]
 Add also VERSION_ID and VERSION. (never expected to change)

So it may not be argued that this is a surprise from base-files side.

Reassigning again.

Thanks.

Bug#939935: stopped responding to play/next/previous keys; evtest and Keyboard Settings see them

[Hans-Christoph Steiner]

Package: rhythmbox
Version: 3.4.3-2
Severity: normal

Dear Maintainer,

I have a Debian/buster install that was a fresh install when buster
was in release freeze.  It is a regular GNOME install with minimal
customization.  The media keys all worked out-of-box.  Recently,
previous/play/next stopped working with Rhythmbox.  Everything else
seems to work the same.

Going to GNOME Keyboard Settings shows that the Shortcuts are set
appropriately there, and that panel also properly detects the keys.

evtest gets the events fine:
Event: time 1568109541.040019, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90
Event: time 1568109541.040019, type 1 (EV_KEY), code 165
(KEY_PREVIOUSSONG), value 1
Event: time 1568109541.040019, -- SYN_REPORT 
Event: time 1568109541.117165, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90
Event: time 1568109541.117165, type 1 (EV_KEY), code 165
(KEY_PREVIOUSSONG), value 0
Event: time 1568109541.117165, -- SYN_REPORT 
Event: time 1568109542.653000, type 4 (EV_MSC), code 4 (MSC_SCAN), value 99
Event: time 1568109542.653000, type 1 (EV_KEY), code 163 (KEY_NEXTSONG),
value 1
Event: time 1568109542.653000, -- SYN_REPORT 
Event: time 1568109542.656743, type 4 (EV_MSC), code 4 (MSC_SCAN), value 99
Event: time 1568109542.656743, type 1 (EV_KEY), code 163 (KEY_NEXTSONG),
value 0
Event: time 1568109542.656743, -- SYN_REPORT 
Event: time 1568109543.151864, type 4 (EV_MSC), code 4 (MSC_SCAN), value a2
Event: time 1568109543.151864, type 1 (EV_KEY), code 164
(KEY_PLAYPAUSE), value 1
Event: time 1568109543.151864, -- SYN_REPORT 
Event: time 1568109543.236944, type 4 (EV_MSC), code 4 (MSC_SCAN), value a2
Event: time 1568109543.236944, type 1 (EV_KEY), code 164
(KEY_PLAYPAUSE), value 0


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.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 rhythmbox depends on:
ii  dbus1.12.16-1
ii  gstreamer1.0-plugins-base   1.14.4-2
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-x  1.14.4-2
ii  libc6   2.28-10
ii  libglib2.0-02.58.3-2+deb10u1
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libpeas-1.0-0   1.22.0-4
ii  librhythmbox-core10 3.4.3-2
ii  libx11-62:1.6.7-1
ii  media-player-info   24-2
ii  rhythmbox-data  3.4.3-2

Versions of packages rhythmbox recommends:
ii  avahi-daemon   0.7-4+b1
ii  gnome-shell [notification-daemon]  3.30.2-9
ii  gstreamer1.0-plugins-ugly  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1
ii  gvfs-backends  1.38.1-5
ii  notification-daemon3.20.0-4
ii  rhythmbox-plugins  3.4.3-2
ii  yelp   3.31.90-1

Versions of packages rhythmbox suggests:
pn  gnome-codec-install  
ii  gnome-control-center 1:3.30.3-2~deb10u1
ii  gstreamer1.0-plugins-bad 1.14.4-1+b1
pn  rhythmbox-plugin-cdrecorder  

-- no debconf information

Bug#939936: ITP: xtl -- basic tools (containers, algorithms) used for xtensor and xeus

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: xtl
  Version : 0.6.5
  Upstream Author : QuantStack
* URL : https://github.com/QuantStack/xtl
* License : BSD
  Programming Lang: C++
  Description : basic tools (containers, algorithms) used for xtensor and 
xeus

This package contains additional containers and tools missing from STL
C++14.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl13dsISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX50i0P/2hQdi8/hP/3VkEOEd5IHmOg3qzADUcY
FxoRxQ0jnL8Ula0QjCRiCU/aQKD7aQKVlNKeAW1++Trq5UILwG/Q7vLWVJk/7j6C
x8bRusrRMd3txIn8q+XAiFdoaEiZgvmcy+kNd88S92ANBnpDFO95Xcqc7o6eZfXz
HFPvmeN3EpgzJGNp3SjqNyR7/yl3+7tCobx98smfRJVKRODWHdNcMk0kKqoQVH2U
JAjc7FhF+AJtV4z4cGXoQA4XPCiZJtKNa6y+YRQvgw9XXUd4TUMkvExK5Eryidid
N5ad+/hDF7syN/wP4mbQ5iS0Mq1BAfmKU8srDtIFQtFbSeiw12kMAfNOHdxEfXrx
+3lahGCCcXpQLrz+KuCMp1V3jQBFqBO3GjIHHHADKNIOmGGKtJzmF37OZknlVlO9
vlQ8G9PyXTgIK919tFxi62KyVEoucpgLuhaj/tYo/lQ714sI6yTKOGqlvMm4uLnt
6AC5ZVSoLOZeC8xnfchR/GAewhjvCeODFeHLQ840s1aYLI4gbleCtb1kvfP71Z1e
/szgk4HjJ1VwV9CnhybTBXsYc+AzvcxST+cqUeldGTN74dAsNIGqkHsJd4XqIGw+
E1sTsg7SlfQhVR2NzoXLU8hBoxIzf3LIbNOyeDWfIxx1MObOgtPitiTTp82wv0Ob
h0ohhmsQKSSq
=+wJw
-END PGP SIGNATURE-

Bug#779686: (no subject)

[Jeremy Rand]

Hi Masayuki,

Is there any news on the Namecoin Core package you submitted at
https://ftp-master.debian.org/new/namecoin_0.17.0~dfsg-1.html ?  I'm not
familiar enough with Debian procedures to have any idea whether the lack
of news since February 2019 is an indication of a problem, or if this is
just a typical delay for getting new packages into Sid.

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



signature.asc
Description: OpenPGP digital signature

Bug#939934: xserver-xorg-video-nouveau: Nouveau fails to work correctly for GeForce GT610 card with kernel 5.2.9

[Russel Winder]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: important

Dear Maintainer,

Nouveau seemed to work fine with kernel 5.2.7 on GeForce GT 610 card. With the 
upgrade to kernel
5.2.9 I get no graphics. It seems that the GNOME session tries to start but 
fails. Below is all
the entries in the journal about nouveau.


|> journalctl | grep nouveau
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: NVIDIA GF119 (0d90a0a1)
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: bios: version 
75.19.55.00.02
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: fb: 2048 MiB DDR3
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: VRAM: 2048 MiB
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: GART: 1048576 MiB
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: TMDS table version 
2.0
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB version 4.0
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB outp 00: 
02000300 
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB outp 01: 
01000302 00020030
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB outp 02: 
02011362 00020010
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB outp 03: 
04022310 
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB conn 00: 
1030
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB conn 01: 
2161
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: DCB conn 02: 
0200
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: DRM: MM: using COPY0 for 
buffer copies
Sep 10 10:47:30 anglides kernel: nouveau :01:00.0: disp: chid 0 stat 
1000 reason 1 [PUSHBUFFER_ERR] mthd  data  code 0001
Sep 10 10:47:31 anglides kernel: nouveau :01:00.0: DRM: allocated 2048x1152 
fb: 0x6, bo (ptrval)
Sep 10 10:47:31 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:31 anglides kernel: fbcon: nouveaudrmfb (fb0) is primary device
Sep 10 10:47:31 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:31 anglides kernel: nouveau :01:00.0: disp: chid 1 stat 
1000 reason 1 [PUSHBUFFER_ERR] mthd  data  code 0001
Sep 10 10:47:33 anglides kernel: nouveau :01:00.0: DRM: core notifier 
timeout
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: DRM: base-0: timeout
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides kernel: nouveau :01:00.0: fifo: PBDMA0: 8000 
[] ch 0 [007fbb4000 DRM] subc 0 mthd  data 
Sep 10 10:47:35 anglides 

Bug#939933: ITP: megadock -- ultra-high-performance protein-protein docking for heterogeneous supercomputers

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: megadock -- ultra-high-performance protein-protein docking for 
heterogeneous supercomputers
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: megadock
  Version : 4.1.1
  Upstream Author : Copyright: © 2014-2018 Akiyama Laboratory, Tokyo Institute 
of Technology, All Rights Reserved.
* URL : http://www.bi.cs.titech.ac.jp/megadock/
* License : GPL-3+
  Programming Lang: C
  Description : ultra-high-performance protein-protein docking for 
heterogeneous supercomputers
 MEGADOCK is an ultra-high-performance protein-protein prediction software for 
heterogeneous supercomputers using FFT-grid-based docking with MPI/OpenMP/GPU 
parallelization

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/megadock

Bug#939932: varnish-modules: FTBFS after new varnish update

[Gianfranco Costamagna]

Source: varnish-modules
Version: 0.15.0-1
Severity: serious

Hello, can you please update the package to cope with new varnish APIs?
the current package FTBFS in sid.

Upstream PR 142 might help in the porting work
https://github.com/varnish/varnish-modules/pull/142/files

G.

Bug#935304: #935304: Set severity to important

[Svante Signell]

reopen 935304
found 935304 243-1
severity 935304 important
thanks

On Tue, 2019-09-10 at 11:10 +0200, Michael Biebl wrote:
> Am 10.09.19 um 11:03 schrieb Svante Signell:
> > severity 935304 important
> > thanks
> > 
> > Michael: Next time you lower the importance of this bug, please give a
> > motivation. It is not especially instructive doing such a thing without
> > explaining why.
> 
> Svante, next you respect the decision of the maintainer, please.
> 
> Anyway, I marked this wishlist, wontfix as the dependency is there for a
> reason. libpam-systemd is non-functional without systemd as PID 1, so
> this dependency will stay and is not optional (recommends)

Please read the motivation in the bug report for making it a recommends. You
cannot guarantee that systemd runs as PID 1, even with this hard dependency!

Downloading the sources for systemd (241-7~deb10u1, 242-7 and 243-1) and looking
into debian/control one finds:
Package: libpam-systemd
Architecture: linux-any
Depends: ${shlibs:Depends},
 ${misc:Depends},
 systemd (= ${binary:Version}),
 libpam-runtime (>= 1.0.1-6),
 dbus,
 systemd-sysv

Bug#885156: ITA: daemonize -- tool to run a command as a daemon

[Alvin Chen]

Control: retitle -1 ITA: daemonize -- tool to run a command as a daemon
Control: owner -1  Sonoma 

Bug#903762: BOINC server experimental package python 2-3 transition error: Upstream is aware of it

[Steffen Möller]

Hi Andreas,

thank you for the report. A "once worked" patch is part of
https://github.com/BOINC/boinc/pull/3259. No exact idea what this is
waiting for but I remain confident that it will eventually be accepted.

Cheers,
Steffen

Bug#939931: Upgrading mstflint package to 4.12.0-1

[Mohamad Heib]

Package: mstflint
Version: 4.11.0+1-1
Priority: wishlist

>From Sept/2019 we are moving to a firmware image that is larger than 4M. 
This requires newer tools to be able to upgrade the firmware. 
Older tools will not support migration.
There where bugs fixed to support this in the version v4.12.0+.
Please upgrade mstflint package to version >= 4.12.

Regards, 
Mohamad 

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Jonathan Wiltshire]

Control: reassign -1 base-files
Control: severity -1 serious
Control: found -1 10.3+deb10u1

Hi,

On 09/09/2019 13:54, Andy Smith wrote:
> Hello,
> 
> On Sun, Sep 08, 2019 at 05:08:12PM +0200, Thorsten Glaser wrote:
>> On Sun, 8 Sep 2019, Markku Leiniö wrote:
>>> On Buster, "lsb_release -d" does not show the point release:
>>>
>>> $ lsb_release -d
>>> Description:Debian GNU/Linux 10 (buster)
>>
>> Isn’t that a feature?
>>
>> The x.y there was a remnant from Debian sarge times.
> 
> Up until squeeze I have seen it show x.y.z, then from wheezy to
> stretch I see only x.y, but it does seem new behaviour in buster to
> only show x.
> 
> $ ansible '*' -i inventories/testing -a 'lsb_release -d' | grep ^Descr | sort 
> -u
> Description:Debian GNU/Linux 10 (buster)
> Description:Debian GNU/Linux 8.11 (jessie)
> Description:Debian GNU/Linux 9.10 (stretch)

This stems from lsb_release switching to reading the cross-distro
standard file, /usr/lib/os-release:

| $ cat /etc/debian_version
| 10.1
| $ cat /usr/lib/os-release
| PRETTY_NAME="Debian GNU/Linux 10 (buster)"
| NAME="Debian GNU/Linux"
| VERSION_ID="10"
| VERSION="10 (buster)"

So arguably base-files should be updating that file with point release
information, just as /etc/debian_version is. The spec [1] does not rule
that out, and other distributions do so:

| $ cat /etc/os-release
| NAME="Red Hat Enterprise Linux Server"
| VERSION="7.7 (Maipo)"
| VERSION_ID="7.7"
| PRETTY_NAME="Red Hat Enterprise Linux"

Please consider doing this urgently in stable, and possible even as a
stable update - it's having knock-on effects for us in several places
already, and I'm sure there will be other users with similar stories.

Severity upgraded because it causes an unexpected behaviour change in
lsb_release, but feel free to adjust.

1: https://www.freedesktop.org/software/systemd/man/os-release.html

Thanks,

-- 
Jonathan Wiltshire

Red Hat Certified Engineer (#170-281-083)

Tiger Computing Ltd
ISO27001:2017 Certified

Tel: 01600 483 484
Web: http://www.tiger-computing.co.uk

Registered in England. Company number: 3389961
Registered address: Wyastone Business Park,
 Wyastone Leys, Monmouth, NP25 3SR



signature.asc
Description: OpenPGP digital signature

Bug#936045: Can not reproduce anymore ...

[Dietz Proepper]

Am Dienstag, 10. September 2019, 01:06:16 CEST schrieben Sie:
> On Sun, Sep 8, 2019 at 6:36 PM Dietz Proepper  wrote:
> > As in the subject - my bt headset now works with 12.99.2-1.
> 
> Thanks for coming back to report this.

You're welcome.

And now for the real source of the problem. Since I ran into it again today.

Somehow, the profile for the bt headset shifted from "Headset" to "a2dp" when 
updating to 12.99.2 the first time. And HF Playback has no microphone ;-).

By using i.e. pavucontrol, I reset it back to "Headset" (HSP/HFP) and 
everything works fine again.

Regards,
Dietz

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

Bug#939930: -doc package should recommend the python3 package

[Matthias Klose]

Package: src:python-lockfile
Version: 1:0.12.2-2
Tags: patch

The -doc package should recommend the python3 package. patch at

http://launchpadlibrarian.net/441479258/python-lockfile_1%3A0.12.2-2_1%3A0.12.2-2ubuntu1.diff.gz

Bug#936856: libfiu: Python2 removal in sid/bullseye

[Chris Lamb]

tags 936856 + pending
thanks

Hi Alberto,

> Sorry for the delay, I was away traveling.

No problem at all. Just uploading 1.00 now that drops Python 2.x
support; thanks.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#939910: arch-test.1: binfmt no longer requires an interpreter to live inside the chroot

[Adam Borowski]

Control: tags -1 +pending

On Tue, Sep 10, 2019 at 11:05:18AM +0800, Paul Wise wrote:
> Package: arch-test

> Since Debian buster, qemu-user-static enabled the "fix binary" mode,
> which means that interpreters no longer need to be copied or bind
> mounted into chroots, which means that this sentence from the manual
> page needs to be updated to mention the "fix binary" mode and that it
> is enabled by default in some cases:
> 
> $ man arch-test | grep -o \(note.*\) 
> (note that binfmt requires an interpreter to live inside the chroot)

Thank you; fixed in git.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#939929: terminator: crash when trying to start

[Benoît Masson]

Package: terminator
Version: 1.91-4
Severity: important

I am not able to start terminator v1.91, it crashes immediately.
Downgrading to 1.90 works.
Error report below, please let me know if you need any more information.

Traceback (most recent call last):
  File "/usr/bin/terminator", line 117, in 
TERMINATOR.reconfigure()
  File "/usr/share/terminator/terminatorlib/terminator.py", line 504, in
reconfigure
style_provider.load_from_data(css.encode('utf-8'))
gi.repository.GLib.Error: gtk-css-provider-error-quark:
:24:34Expected a valid selector (1)

With --debug flag:

ConfigBase::__init__: Borg::__init__: Preparing borg state for ConfigBase
noclass::get_config_dir: Found config dir: /home/benoit/.config
ConfigBase::load: looking for config file:
/home/benoit/.config/terminator/config
ConfigBase::load: config validated successfully
ConfigBase::load: ConfigBase::load: Processing section: global_config
ConfigBase::load: ConfigBase::load: Processing section: keybindings
ConfigBase::load: ConfigBase::load: Processing keybindings: zoom_in
ConfigBase::load: ConfigBase::load: Processing keybindings: zoom_out
ConfigBase::load: ConfigBase::load: Processing keybindings: zoom_normal
ConfigBase::load: ConfigBase::load: Processing keybindings: new_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: cycle_next
ConfigBase::load: ConfigBase::load: Processing keybindings: cycle_prev
ConfigBase::load: ConfigBase::load: Processing keybindings: go_next
ConfigBase::load: ConfigBase::load: Processing keybindings: go_prev
ConfigBase::load: ConfigBase::load: Processing keybindings: go_up
ConfigBase::load: ConfigBase::load: Processing keybindings: go_down
ConfigBase::load: ConfigBase::load: Processing keybindings: go_left
ConfigBase::load: ConfigBase::load: Processing keybindings: go_right
ConfigBase::load: ConfigBase::load: Processing keybindings: rotate_cw
ConfigBase::load: ConfigBase::load: Processing keybindings: rotate_ccw
ConfigBase::load: ConfigBase::load: Processing keybindings: split_horiz
ConfigBase::load: ConfigBase::load: Processing keybindings: split_vert
ConfigBase::load: ConfigBase::load: Processing keybindings: close_term
ConfigBase::load: ConfigBase::load: Processing keybindings: copy
ConfigBase::load: ConfigBase::load: Processing keybindings: paste
ConfigBase::load: ConfigBase::load: Processing keybindings: toggle_scrollbar
ConfigBase::load: ConfigBase::load: Processing keybindings: search
ConfigBase::load: ConfigBase::load: Processing keybindings: close_window
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_up
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_down
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_left
ConfigBase::load: ConfigBase::load: Processing keybindings: resize_right
ConfigBase::load: ConfigBase::load: Processing keybindings: move_tab_right
ConfigBase::load: ConfigBase::load: Processing keybindings: move_tab_left
ConfigBase::load: ConfigBase::load: Processing keybindings: toggle_zoom
ConfigBase::load: ConfigBase::load: Processing keybindings: scaled_zoom
ConfigBase::load: ConfigBase::load: Processing keybindings: next_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: prev_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: full_screen
ConfigBase::load: ConfigBase::load: Processing keybindings: reset
ConfigBase::load: ConfigBase::load: Processing keybindings: reset_clear
ConfigBase::load: ConfigBase::load: Processing keybindings: hide_window
ConfigBase::load: ConfigBase::load: Processing keybindings: group_all
ConfigBase::load: ConfigBase::load: Processing keybindings: ungroup_all
ConfigBase::load: ConfigBase::load: Processing keybindings: group_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: ungroup_tab
ConfigBase::load: ConfigBase::load: Processing keybindings: new_window
ConfigBase::load: ConfigBase::load: Processing keybindings: new_terminator
ConfigBase::load: ConfigBase::load: Processing keybindings: broadcast_off
ConfigBase::load: ConfigBase::load: Processing keybindings: broadcast_group
ConfigBase::load: ConfigBase::load: Processing keybindings: broadcast_all
ConfigBase::load: ConfigBase::load: Processing keybindings: insert_number
ConfigBase::load: ConfigBase::load: Processing keybindings: insert_padded
ConfigBase::load: ConfigBase::load: Processing keybindings:
edit_window_title
ConfigBase::load: ConfigBase::load: Processing keybindings: edit_tab_title
ConfigBase::load: ConfigBase::load: Processing keybindings:
edit_terminal_title
ConfigBase::load: ConfigBase::load: Processing keybindings: layout_launcher
ConfigBase::load: ConfigBase::load: Processing keybindings: help
ConfigBase::load: ConfigBase::load: Processing section: profiles
ConfigBase::load: ConfigBase::load: Processing profile: default
ConfigBase::load: ConfigBase::load: Processing profile: Présentation
ConfigBase::load: ConfigBase::load: Processing section: layouts
ConfigBase::load: ConfigBase::load: 

Bug#936613: ginac: Python2 removal in sid/bullseye

[Matthias Klose]

On 10.09.19 10:51, Richard B. Kreckel wrote:

I am very sure that ginac 1.7.6 does neither build-depend, depend on
Python2, or use Python2 in the autopkg tests.

How was this determined? Was it found by grepping for "python2" in the
extracted package? If so, grep will have found strings like
_ZN5GiNaC12print_python21get_class_info_staticEv, which is just the
mangled C++ symbol of GiNaC::print_python::get_class_info_static().

Unless shown that I'm wrong, I plan to just close this bug.


Please read the instructions, they mention to check dependencies, build 
dependencies, and test dependencies ...


$ apt-cache showsrc ginac|grep Depends
Build-Depends: cdbs (>= 0.4.28), debhelper (>= 9), libcln-dev, libgmp-dev, 
libreadline-dev, pkg-config (>= 0.18) | pkgconf, dh-autoreconf, python, texinfo

Bug#939877: closed by Josue Ortega (Bug#939877: fixed in rpcbind 1.2.5-7)

[Anton Ivanov]

I missed the actual receive line in the 1.2.5-7 apologies.

It alone DOES Not fix it though.

There is breakage in libwrap to accompany it.

Once the fix in 1.2.5-7 is in, rpcbind starts receiving (according to 
strace) messages which is followed by interrogating addresses and 
interfaces by netlink.


As I do not see any netlink references anywhere in the rpcbind or the 
libtirpc-dev, I believe this is wrap which now has broken broadcast 
check. So anything compiled with wrap which needs to receive broadcasts 
need to be set as ALL:ALL in hosts.allow - otherwise it is dropped.


Upgrading to both 1.2.5-7 _AND_ setting hosts.allow to ALL:ALL provides 
a viable workaround.


The remaining part of this bug is libwrap, you can refile it vs that.

Best Regards,

--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#939927: mariadb-server-10.1 Cannot complete the upgrade package

[Александр Воробьев]

Linux dev 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 
GNU/Linux
9.11

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[Aurelien Jarno]

On 2019-09-09 23:16, Aurelien Jarno wrote:
> On 2019-09-09 22:49, John Paul Adrian Glaubitz wrote:
> > Source: glibc
> > Version: 2.29-1
> > Severity: important
> > User: debian-al...@lists.debian.org
> > Usertags: alpha
> > 
> > Hello!
> > 
> > Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading 
> > glibc
> > to version 2.29-1 resulted in setuid/getuid breaking in a weird way:
> 
> As a side note, I have successfully upgrade a qemu-system-alpha based
> machine without issue. It actually fixes long standing issues with
> systemd. The VM runs kernel 5.2.0-2-alpha-smp.

The problem happens when running with kernel < 5.1. The problem is not
directly related to the new upstream version, but rather to the fact
that the glibc has been built against new kernel headers, which include
the following changes:

| commit ecf7e0a4ad1528710c90f0a6f4285741ac525f6e
| Author: Arnd Bergmann 
| Date:   Fri Jan 11 15:09:11 2019 +0100
|
| alpha: add generic get{eg,eu,g,p,u,pp}id() syscalls
|
| Alpha has traditionally followed the OSF1 calling conventions
| here, with its getxpid, getxuid, getxgid system calls returning
| two different values in separate registers.
|   
| Following what glibc has done here, we can define getpid,
| getuid and getgid to be aliases for getxpid, getxuid and getxgid
| respectively, and add new system call numbers for getppid, geteuid
| and getegid.
|
| Signed-off-by: Arnd Bergmann 

With this change the new syscalls are being used by the glibc instead of
the old OSF1 ones. However they do not exist on kernels < 5.1 so things
break.

The short term solution is to upgrade the kernel to > 5.1. The long term
solution is to write a wrapper on the glibc side to fallback on the old
syscalls if the new ones do not exist.

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

Bug#885156: ITA: daemonize -- tool to run a command as a daemonproperties

[Alvin Chen]

Control: retitle -1 ITA: daemonize -- tool to run a command as a daemon

Control: owner -1  Sonoma onoma...@gmail.com>

Bug#935304: #935304: Set severity to important

[Michael Biebl]

Am 10.09.19 um 11:03 schrieb Svante Signell:
> severity 935304 important
> thanks
> 
> Michael: Next time you lower the importance of this bug, please give a
> motivation. It is not especially instructive doing such a thing without
> explaining why.

Svante, next you respect the decision of the maintainer, please.

Anyway, I marked this wishlist, wontfix as the dependency is there for a
reason. libpam-systemd is non-functional without systemd as PID 1, so
this dependency will stay and is not optional (recommends)


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



signature.asc
Description: OpenPGP digital signature

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[John Paul Adrian Glaubitz]

Hi!

On 9/10/19 10:52 AM, Michael Cree wrote:

I assume this would also work on qemu-system-alpha although I haven't tried
yet. But it should work the same way but without the "--foreign" argument.


What kernel are you running?  Be aware that recent kernels on alpha
(since ecf7e0a4ad15287) now support the getuid and getgid syscalls
that the other arches always have had.  I wonder if glibc has been
updated in anyway for that?  If so, it should be checking kernel
version as to whether to use OSF1 syscall conventions or Linux
syscall conventions.  OSF1 calling conventions should work on any
kernel, whereas Linux calling conventions only on kernels since
v5.1.


Yes, we have already figured out that this happens when the kernel is
too old. According to Aurelien, the problem is that the glibc package
has been built against the kernel 5.3 headers which is why users need
to upgrade their kernel first before upgrading glibc.

Currently fixing tsunami.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#935304: #935304: Set severity to important

[Svante Signell]

severity 935304 important
thanks

Michael: Next time you lower the importance of this bug, please give a
motivation. It is not especially instructive doing such a thing without
explaining why.

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[Michael Cree]

On Mon, Sep 09, 2019 at 10:49:48PM +0200, John Paul Adrian Glaubitz wrote:
> Shortly after typing "root" and pressing enter, the following message is 
> printed to the
> console which seems to be an alpha-specific syscall:
> 
> [  195.414939] do_entUnaUser: 7 callbacks suppressed

No, that is not a syscall, that's the misaligned access by user space
interrupt vector letting you know the kernel fixed up 7 misaligned
memory accesses.

Cheers,
Michael.

Bug#939898: glibc: setuid/getuid broken on alpha with 2.29-1

[Michael Cree]

On Mon, Sep 09, 2019 at 11:14:50PM +0200, John Paul Adrian Glaubitz wrote:
> On 9/9/19 10:49 PM, John Paul Adrian Glaubitz wrote:
> > Both on my Alpha XP-1000 as well as inside a qemu-user chroot, upgrading 
> > glibc
> > to version 2.29-1 resulted in setuid/getuid breaking in a weird way:
> 
> To reproduce, one can simply run debootstrap with qemu-user-static installed 
> and
> enter the chroot:
> 
> root@epyc:/local_scratch> debootstrap --no-check-gpg --arch=alpha --foreign 
> --variant=minbase unstable sid-alpha-sbuild 
> http://ftp.ports.debian.org/debian-ports
> (...)
> root@epyc:/local_scratch> chroot sid-alpha-sbuild
> bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
> I have no name!@epyc:/local_scratch> ./debootstrap/debootstrap --second-stage
> E: debootstrap can only run as root
> I have no name!@epyc:/local_scratch>
> 
> I assume this would also work on qemu-system-alpha although I haven't tried
> yet. But it should work the same way but without the "--foreign" argument.

What kernel are you running?  Be aware that recent kernels on alpha
(since ecf7e0a4ad15287) now support the getuid and getgid syscalls
that the other arches always have had.  I wonder if glibc has been
updated in anyway for that?  If so, it should be checking kernel
version as to whether to use OSF1 syscall conventions or Linux
syscall conventions.  OSF1 calling conventions should work on any
kernel, whereas Linux calling conventions only on kernels since
v5.1.

Cheers
Michael.

Bug#939928: ovmf 0~20190606.20d2e5a1-4: VM does not start with UEFI BIOS

[Stefan Pietsch]

Package: ovmf
Version: 0~20190606.20d2e5a1-4
Severity: grave

It is not possible to start a virtual machine with UEFI BIOS.


qemu-system-x86_64 -bios /usr/share/qemu/OVMF.fd

The QEMU window shows: "Guest has not initialized the display (yet)."


Downgrading ovmf to 0~20181115.85588389-3 solves this.


$ qemu-system-x86_64 -version
QEMU emulator version 4.1.0 (Debian 1:4.1-1+b1)

Bug#920263: custom AMD-server kernel-package

[andrew glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I am no longer trying to configure backported kernel-sources now, but in
fact my build-pc has the stable (buster) distribution software-set now, there
seems to be some problem about SSL, and I cannot see which option to disable
in the crypto-section of the kernel.
What does it mean anyway, is it not necessary anymore to build a
server-configured custom kernel-image, or maybe do I have to wait for a few
years, until it works out with LLVM??
 

> build@virtsrv:~/linux-source-4.19$ time make -j8 LOCALVERSION=-asrv deb-pkg
>   UPD include/config/kernel.release
> make clean
> /bin/bash ./scripts/package/mkdebian
>   TAR linux-4.19.67-asrv.tar.gz
> origversion=$(dpkg-parsechangelog -SVersion |sed 's/-[^-]*$//');\
>   mv
> linux-4.19.67-asrv.tar.gz ../linux-4.19.67-asrv_${origversion}.orig.tar.gz
> dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -i.git -us -uc
> dpkg-buildpackage: info: source package linux-4.19.67-asrv
> dpkg-buildpackage: info: source version 4.19.67-asrv-1 dpkg-buildpackage:
> info: source distribution buster dpkg-buildpackage: info: source changed by
> build  dpkg-buildpackage: info: host architecture amd64
> dpkg-buildpackage: warning: debian/rules is not executable; fixing that
>  dpkg-source -i.git --before-build .
>  fakeroot -u debian/rules clean
> rm -rf debian/*tmp debian/files
> make clean
>  dpkg-source -i.git -b .
> dpkg-source: warning: no source format specified in debian/source/format,
> see dpkg-source(1) dpkg-source: info: using source format '1.0'
> dpkg-source: warning: source directory 'linux-source-4.19' is not
> - 'linux-4.19.67-asrv-4.19.67-asrv'
> dpkg-source: warning: .orig directory name linux-source-4.19.orig is not
> - (wanted linux-4.19.67-asrv-4.19.67-asrv.orig)
> dpkg-source: info: building linux-4.19.67-asrv using existing
> linux-4.19.67-asrv_4.19.67-asrv.orig.tar.gz dpkg-source: info: building
> linux-4.19.67-asrv in linux-4.19.67-asrv_4.19.67-asrv-1.diff.gz
> dpkg-source: warning: ignoring deletion of file .scmversion dpkg-source:
> warning: the diff modifies the following upstream
> files: .clang-format .cocciconfig .get_maintainer.ignore .mailmap
>  CREDITS
>  LICENSES/exceptions/Linux-syscall-note
>  LICENSES/other/Apache-2.0
>  LICENSES/other/CDDL-1.0
>  LICENSES/other/GPL-1.0
>  LICENSES/other/Linux-OpenIB
>  LICENSES/other/MPL-1.1
>  LICENSES/other/X11
>  LICENSES/preferred/BSD-2-Clause
>  LICENSES/preferred/BSD-3-Clause
>  LICENSES/preferred/BSD-3-Clause-Clear
>  LICENSES/preferred/GPL-2.0
>  LICENSES/preferred/LGPL-2.0
>  LICENSES/preferred/LGPL-2.1
>  LICENSES/preferred/MIT
>  MAINTAINERS
>  README
> dpkg-source: info: use the '3.0 (quilt)' format to have separate and
> documented changes to upstream files, see dpkg-source(1) dpkg-source: info:
> building linux-4.19.67-asrv in linux-4.19.67-asrv_4.19.67-asrv-1.dsc
> dpkg-source: warning: missing information for output field
> Standards-Version debian/rules build make KERNELRELEASE=4.19.67-asrv
> ARCH=x86  KBUILD_BUILD_VERSION=1 KBUILD_SRC= WRAP
> arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP
> arch/x86/include/generated/uapi/asm/poll.h HOSTCC  scripts/basic/fixdep
>   SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
>   UPD include/generated/uapi/linux/version.h
>   SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
>   UPD include/generated/package.h
>   SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
>   DESCEND  objtool
>   SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
>   HYPERCALLS arch/x86/include/generated/asm/xen-hypercalls.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
>   SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
>   HOSTCC   /home/build/linux-source-4.19/tools/objtool/fixdep.o
>   HOSTLD   /home/build/linux-source-4.19/tools/objtool/fixdep-in.o
>   LINK /home/build/linux-source-4.19/tools/objtool/fixdep
>   CC   /home/build/linux-source-4.19/tools/objtool/exec-cmd.o
>   CC   /home/build/linux-source-4.19/tools/objtool/help.o
>   CC   /home/build/linux-source-4.19/tools/objtool/pager.o
>   CC   /home/build/linux-source-4.19/tools/objtool/parse-options.o
>   GEN  
> /home/build/linux-source-4.19/tools/objtool/arch/x86/lib/inat-tables.c
>   CC   /home/build/linux-source-4.19/tools/objtool/arch/x86/decode.o
>   CC   /home/build/linux-source-4.19/tools/objtool/run-command.o
>   CC   /home/build/linux-source-4.19/tools/objtool/builtin-check.o
>   CC   /home/build/linux-source-4.19/tools/objtool/builtin-orc.o
>   CC   /home/build/linux-source-4.19/tools/objtool/sigchain.o
>   CC   /home/build/linux-source-4.19/tools/objtool/subcmd-config.o
>   LD   /home/build/linux-source-4.19/tools/objtool/arch/x86/objtool-in.o
>   CC   /home/build/linux-source-4.19/tools/objtool/check.o
>   CC   /home/build/linux-source-4.19/tools/objtool/orc_gen.o
>  

Bug#939927: mariadb-server-10.1 Cannot complete the upgrade package

[Александр Воробьев]

Package: mariadb-server-10.1
Version: 10.1.41-0+deb9u1

When I ran the command "apt-get update && apt-get upgrade" the process ended 
with a message:

ru

Настраивается пакет mariadb-server-10.1 (10.1.41-0+deb9u1) …
/var/lib/dpkg/info/mariadb-server-10.1.postinst: строка 18: 25729 Завершён  
  echo "$password_column_fix_query"
 25730 Аварийный останов | $MYSQL_BOOTSTRAP 2>&1
 25731   | $ERR_LOGGER
dpkg: ошибка при обработке пакета mariadb-server-10.1 (--configure):
 подпроцесс установлен сценарий post-installation возвратил код ошибки 134
При обработке следующих пакетов произошли ошибки:
 mariadb-server-10.1
===

en
==
Configures the package mariadb-server-10.1 (10.1.41-0+deb9u1) …
/var/lib/dpkg/info/mariadb-server-10.1.postinst: line 18: 25729 Completed echo 
"$password_column_fix_query"
 25730 Emergency stop | $MYSQL_BOOTSTRAP 2>&1
 25731 | $ERR_LOGGER
dpkg: error processing package mariadb-server-10.1 (--configure):
 subprocess installed post-installation script returned error code 134
Errors occurred while processing the following packets:
 mariadb-server-10.1
==

#systemctl status mariadb.service
● mariadb.service - MariaDB 10.1.41 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; disabled; vendor 
preset: enabled)
   Active: inactive (dead)
 Docs: man:mysqld(8)
   https://mariadb.com/kb/en/library/systemd/

10 11:12:14 dev systemd[1]: Starting MariaDB 10.1.41 database server...
10 11:12:14 dev mysqld[21060]: 2019-09-10 11:12:14 139796488449408 [Note] 
/usr/sbin/mysqld (mysqld 10.1.41-MariaDB-0+deb9u1) starting as process 21060 ...
10 11:12:18 dev systemd[1]: mariadb.service: Main process exited, code=killed, 
status=6/ABRT
10 11:12:18 dev systemd[1]: Failed to start MariaDB 10.1.41 database server.
10 11:12:18 dev systemd[1]: mariadb.service: Unit entered failed state.
10 11:12:18 dev systemd[1]: mariadb.service: Failed with result 'signal'.
10 11:12:23 dev systemd[1]: mariadb.service: Service hold-off time over, 
scheduling restart.
10 11:12:23 dev systemd[1]: Stopped MariaDB 10.1.41 database server.
10 11:12:23 dev systemd[1]: Starting MariaDB 10.1.41 database server...
10 11:12:24 dev systemd[1]: Stopped MariaDB 10.1.41 database server.



-- 
С уважением,
Воробьев Александр
Создание и поддержка сайтов https://va-soft.ru/

Bug#939926: gnome-shell: Window screen and workspace locations forgotten when working with an external monitor

[Dennis van Dok]

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

Dear Maintainer,

the window placement on my external screen is not remembered when I unplug and 
suspend my
laptop.

I upgraded from Debian stretch to buster. I'm using a laptop with a plain
Gnome desktop. At home, I use just the laptop, but at work I plug in an external
screen which I set as the primary display (i.e. it gets the menu bar and 
workspaces).

I leave most of my windows open when I go home; I simply detach the screen and
suspend the laptop. When I come in the next day and re-attach the external 
screen,
it is correctly positioned and set as the primary display again, but none of the
application windows are placed back in their original position. They are all 
piled
on top of one another on the laptop screen (now secondary screen).

I typically keep each application on its own workspace. Before the upgrade this 
used
to work smartly; applications that were running the day before would end up on 
their
own workspace. After the upgrade, the window position is remembered only when 
the
laptop has not been suspended in the mean time.

A simple test to replicate:

1. set up laptop with Debian buster and Gnome 3 desktop
2. attach external screen
3. configure external display to be the primary
4. launch an application. Place on primary display.
5. Detach screen.
6. Reattach screen.
7. Observe position of application window.

If between steps 5 and 6 a suspend an wake up the laptop, the observed position 
of
the application reverts to the laptop rather than the external screen.

-- 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-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_NL.UTF-8 (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
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.28.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.2-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.5-1
ii  gir1.2-gweather-3.0  3.28.2-2
ii  gir1.2-ibus-1.0  1.5.19-4
ii  gir1.2-mutter-3  3.30.2-7
ii  gir1.2-nm-1.01.14.6-2
ii  gir1.2-nma-1.0   1.8.20-1.1
ii  gir1.2-pango-1.0 1.42.4-7~deb10u1
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
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
ii  libedataserver-1.2-233.30.5-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
ii  libglib2.0-0 2.58.3-2
ii  libglib2.0-bin   2.58.3-2
ii  libgstreamer1.0-01.14.4-1
ii  libgtk-3-0   3.24.5-1
ii  libical3 3.0.4-3
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-7
ii  libnm0   1.14.6-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  

Bug#939877: closed by Josue Ortega (Bug#939877: fixed in rpcbind 1.2.5-7)

[Anton Ivanov]

That's not it.

Same story with 1.2.5-7 from unstable.

This is after NIS restart on the client on the NIS server:

root@jain:# tcpdump -nvvv -i enp7s0f1.502 udp and port 111

tcpdump: listening on enp7s0f1.502, link-type EN10MB (Ethernet), capture 
size 262144 bytes


    192.168.20.41.36268 > 192.168.20.63.111: [udp sum ok] UDP, length 92
09:02:57.820457 IP (tos 0x0, ttl 64, id 55627, offset 0, flags [DF], 
proto UDP (17), length 120)

    192.168.20.41.36268 > 192.168.20.63.111: [udp sum ok] UDP, length 92
09:03:03.826888 IP (tos 0x0, ttl 64, id 55969, offset 0, flags [DF], 
proto UDP (17), length 120)


And on - the RPC retransmits to broadcast address (63 on this subnet it 
is /26)


Traffic only one way, strace on rpcbind shows only netlink messages, no 
udp recv


Same thing after setting a nis server address on the client and 
restarting nis - immediate response


tcpdump -nvvv -i enp7s0f1.502 udp and port 111

   192.168.20.41.800 > 192.168.3.3.111: [udp sum ok] UDP, length 56
09:05:00.429940 IP (tos 0x0, ttl 64, id 22755, offset 0, flags [DF], 
proto UDP (17), length 56)
    192.168.3.3.111 > 192.168.20.41.800: [bad udp cksum 0x98b2 -> 
0x1245!] UDP,


strace of the rpcbind process

sendmsg(6, {msg_name={sa_family=AF_INET, sin_port=htons(800), 
sin_addr=inet_addr("192.168.20.41")}, msg_namelen=16, 
msg_iov=[{iov_base=".{\272q\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\265", 
iov_len=28}], msg_iovlen=1, msg_control=[{cmsg_len=28, 
cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=0, 
ipi_spec_dst=inet_addr("192.168.3.3"), 
ipi_addr=inet_addr("192.168.3.3")}}], msg_controllen=32, msg_flags=0}, 
0) = 28


That line (strace) never occurs in the broadcast case.

It simply is not listening to broadcast queries.

I will try to wade through the source to see exactly how it manages it, 
because listening on INADDR_ANY should in theory get you broadcasts.



On 09/09/2019 22:00, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the rpcbind package:

#939877: rpcbind: Does not receive any broadcast queries resulting in complete 
breakage of NIS

It has been closed by Josue Ortega .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Josue Ortega 
 by
replying to this email.



--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#939925: gmime: Add a superficial test for the -dev package

[Simon McVittie]

Source: gmime
Version: 3.2.1-1
Severity: wishlist
Tags: patch

I've recently been adding superficial autopkgtests for -dev packages
in GNOME and GNOME-adjacent libraries. These tests check that the
-dev package is usable, and in particular often detect missing -dev
dependencies like #939222 in gcab (although gmime does not seem to have
that problem).

Please consider the attached patch.

Thanks,
smcv
>From f66dced886616031deed2af1a3b6c63f8c460f75 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 10 Sep 2019 09:05:16 +0100
Subject: [PATCH] d/tests/libgmime-3.0-dev: Add a superficial test for the -dev
 package

Tests like this one check that the -dev package is usable, and in
particular often detect missing -dev dependencies like #939222 in gcab.
---
 debian/tests/control  |  5 +
 debian/tests/libgmime-3.0-dev | 29 +
 2 files changed, 34 insertions(+)
 create mode 100755 debian/tests/libgmime-3.0-dev

diff --git a/debian/tests/control b/debian/tests/control
index dce76310..4f0b0a1a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,7 @@
 Tests: gir
 Depends: diffutils, gir1.2-gmime-3.0, python3-gi
+
+Tests: libgmime-3.0-dev
+Depends: build-essential,
+ libgmime-3.0-dev
+Restrictions: allow-stderr superficial
diff --git a/debian/tests/libgmime-3.0-dev b/debian/tests/libgmime-3.0-dev
new file mode 100755
index ..43d1670d
--- /dev/null
+++ b/debian/tests/libgmime-3.0-dev
@@ -0,0 +1,29 @@
+#!/bin/sh
+# autopkgtest check: Build and run a program against gmime, to verify
+# that the headers and pkg-config file are installed correctly
+# (C) 2012 Canonical Ltd.
+# (C) 2018-2019 Simon McVittie
+# Authors: Martin Pitt, Simon McVittie
+
+set -eux
+
+WORKDIR=$(mktemp -d)
+trap 'rm -rf "$WORKDIR"' 0 INT QUIT ABRT PIPE TERM
+cd "$WORKDIR"
+cat <<'EOF' > trivial.c
+#include 
+
+int main(void)
+{
+g_assert_true(g_mime_check_version(3, 0, 0));
+return 0;
+}
+EOF
+
+# Deliberately word-splitting pkg-config's output:
+# shellcheck disable=SC2046
+gcc -o trivial trivial.c $(pkg-config --cflags --libs gmime-3.0)
+echo "build: OK"
+[ -x trivial ]
+./trivial
+echo "run: OK"
-- 
2.23.0

Bug#939924: iptables-nft 1.8.2-4 check reports bad rule on "-m mark --mark 0x8000"

[Wolfgang Jentner]

Package: iptables

Version: 1.8.2-4


Hi,


there is a bug in iptables-nft 1.8.2-4 in Debian buster:

|# lsb_release -a No LSB modules are available. Distributor ID: Debian 
Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster # 
dpkg -s iptables | grep ^Version Version: 1.8.2-4 # iptables-nft -N FOO 
# iptables-nft -A FOO -m comment --comment "kubernetes firewall for 
dropping marked packets" -m mark --mark 0x8000 -j DROP # iptables-nft -C 
FOO -m comment --comment "kubernetes firewall for dropping marked 
packets" -m mark --mark 0x8000 -j DROP && echo exists iptables: Bad rule 
(does a matching rule exist in that chain?). # iptables-legacy -N BAR # 
iptables-legacy -A BAR -m comment --comment "kubernetes firewall for 
dropping marked packets" -m mark --mark 0x8000 -j DROP # iptables-legacy 
-C BAR -m comment --comment "kubernetes firewall for dropping marked 
packets" -m mark --mark 0x8000 -j DROP && echo exists exists|



We filed the original issue here: 
https://github.com/kubernetes/kubernetes/issues/82361#issue-489594945



Best,
Wolfgang


--
Wolfgang Jentner
Department of Computer and Information Science
Chair for Data Analysis and Visualization
University of Konstanz
Box 78
D-78457 Konstanz, Germany

Mail:  jent...@dbvis.inf.uni-konstanz.de
Web:   https://www.vis.uni-konstanz.de/mitglieder/jentner/
Phone: +49 (0) 7531 88 3941
Fax:   +49 (0) 7531 88 3065
Room:  C201

Bug#919567: New version 3.2.3 available

[Simon McVittie]

Version: 3.2.3-1

On Thu, 17 Jan 2019 at 10:27:39 +0100, Sebastien Bacher wrote:
> There is a new version available including some fixes, it would be nice
> to get it into Debian

This version is available in experimental, although not unstable yet.

smcv

Bug#939834: claws-mail: Does not respond to `can_change_accels`

[Ricardo Mones]

control: tags -1 moreinfo

Hi Paul,

On Mon, Sep 09, 2019 at 12:32:31PM +0100, Paul "LeoNerd" Evans wrote:
> Package: claws-mail
> Version: 3.17.4-1
> Severity: normal
> 
> GTK applications ought to allow users to customise the keyboard
> shortcuts ("accelerators") if enabled globally, by users highlighting a
> menu option and pressing a new key.
> 
> I have it enabled globally:
> 
>   $ gconftool --get /desktop/gnome/interface/can_change_accels
>   true
> 
> but yet doing this has no effect in claws-mail.

Claws Mail it's not a GNOME application, no surprise here.

> Additionally I've even tried manually editing `.claws-mail/menurc` but
> the file seems to be ignored and rewritten on startup.

Because you don't have customisable keyboard shortcuts enabled, try
Configuration → Preferences → Other → Miscellaneous → Keyboard
shortchuts frame → Enable customisable keyboard shortcuts checkbox.

BTW, you can also edit menurc with clawsker instead of manually :)

> It may be significant that I am running xfce rather than gnome.

Should work on any desktop enviroment, even on non GTK+-based ones.

regards,
-- 
  Ricardo Mones 
  ~
  I'm sorry, my responses are limited. You must ask the right 
  questions.   A hologram



signature.asc
Description: PGP signature

Bug#939787: RFS: assaultcube/1.2.0.2.1-3 [ITA] -- realistic first-person-shooter

[Tobias Frost]

Control: tags -1 moreinfo

On Sun, Sep 08, 2019 at 03:50:55PM -0300, Carlos Donizete Froes wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 

(...)

> Changes since the last upload:
> 
>* debian/control: (Closes: #728193)
>  + Added Breaks+Replaces

This changelog entry does not really make sense / completly unclear.
Please be more concise. For the breaks+replace:
the changelog entry should answer the question "Why" not "what", it is
completly unclear what you want to archieve.

the mentioned bug is the ITA, you should have closed that with the
previous upload. It is wrong to close it now, you need to close it with
interacting with the BTS.

-- 
tobi 

Bug#939923: mono ftbfs in unstable (still calling python)

[Matthias Klose]

Package: src:mono
Version: 5.18.0.240+dfsg-4
Severity: serious
Tags: sid bullseye

https://buildd.debian.org/status/package.php?p=mono

Making all in mini
make[2]: Entering directory '/<>/mono/mini'
echo "#define FULL_VERSION \"Debian $(dpkg-parsechangelog 
-l../../debian/changelog | grep ^Vers | cut -d\  -f2)\"" > version.h

python ./genmdesc.py TARGET_ARM64 . cpu-arm64.h arm64_cpu_desc ./cpu-arm64.md
/bin/bash: python: command not found
make[2]: *** [Makefile:2964: cpu-arm64.h] Error 127
make[2]: *** Waiting for unfinished jobs

Bug#938823: wicd and Python 3 (was: "wicd" utf8 and too many APs nightmare/bug)

[Guido Maria Serra]

Hi Alex,

> I tried this one already, but bailed out, too. The other one
> lookedmore promising IMHO. What worked in the end was this, though:
> https://stackoverflow.com/questions/47838405/porting-a-sub-class-of-python2-file-class-to-python3
> https://salsa.debian.org/debian/wicd/blob/python3/debian/patches/02-python3-fixups.patch#L285-296

awesome!
>   File "/usr/lib/python3/dist-packages/wicd/logfile.py", line 52, in
> writedata = data.decode('utf-8').encode('utf-8')AttributeError:
> 'str' object has no attribute 'decode'

here you go... 
https://github.com/zeph/wicd/commit/15ca072eeda799cb84beb55934dea24720d431ce

> Need to go to bed now. If you want, I can provide the work so far
> aspull request against your repo. (But unless you say you want that,
> Iwon't do it.)

yes, please send me a PR
good night
GMS

Bug#934099: Pending bugs

[Ole Streicher]

Hi,

this error is locally fixed. However, since the last binNMU, the Python
package does not work anymore, and this still needs to be analyzed and
fixed (see Ci tests,
).

Stay tuned!

Cheers

Ole

Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error

[David Raison]

Thanks for looking into this, Daniel.


On 10/09/2019 02:24, Daniel Kahn Gillmor wrote:
> I note here that you're not running the latest kernel -- 4.19.0-5-amd64
> is not 4.19.0-6-amd64.  is it possible that you don't have
> linux-image-4.19.0-5-amd64 or its headers installed any more, despite
> running that kernel?


I did, and still do have the headers for the currently running kernel
installed:

linux-headers-4.19.0-5-amd64/stable,now 4.19.37-5+deb10u2 amd64
[installed,automatic]

linux-headers-4.19.0-6-amd64/stable,now 4.19.67-2 amd64
[installed,automatic]

However, I rebooted the machine since to boot into 4.19.0-6,
re-installed wireguard-dkms and have a successful build this time. I
could have tried that earlier but I'm not in a habit of rebooting my
machine.


Regards,
David

Bug#939922: greenbone-security-assistant: init script inconsistency wrt DAEMON_ARGS

[Christoph Biedl]

Package: greenbone-security-assistant
Version: 7.0.3+dfsg.1-1
Severity: normal

Dear Maintainer,

although probably nobody is still using the init scripts ...

The gsa daemon gets a few parameters via the DAEMONOPTS shell variable
which is built after sourcing the default file
/etc/default/greenbone-security-assistant. Now it's not obvious whether
a user should be allowed to add extra parameters - in my opinion yes,
mostly to override the --timeout setting. But if yes, the default file
was the right place for this.

However, the statements from line 24 on:

| [ "$GSA_ADDRESS" ] && DAEMONOPTS="--listen=$GSA_ADDRESS"
| [ "$GSA_PORT" ] && DAEMONOPTS="$DAEMONOPTS --port=$GSA_PORT"
| ...

makes this a wobbly game: If GSA_ADDRESS is set in the default file,
any DAEMONOPTS setting from that place will be discarded. If not, it's
taken into account.

The same happens in openvas-manager, depending on the value of
DATABASE_FILE, whie openvas-scanner explicitely clears DAEMONOPTS.

For clarity, please implement a unified behaviour.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#939921: greenbone-security-assistant: Please suggest "systemctl edit ..." instead of manually creating systemd service overrides

[Christoph Biedl]

Package: greenbone-security-assistant
Version: 7.0.3+dfsg.1-1
Severity: whishlist

Dear Maintainer,

For systems running systemd, the default file at
/etc/default/greenbone-security-assistant contains a note about
overriding the hardcoded daemon defaults, by manually creating a file
at a certain place.

May I suggest you'd recommend "systemctl edit " instead? It's
shorter, more obvious and uses a well-defined mechanism.

This applies to openvas-manager and openvas-scanner as well. Let me
know if you want extra bug reports for those as well.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#939920: openvas: Missing dependency on psmisc

[Christoph Biedl]

Package: openvas
Version: 9.0.3
Severity: normal

Dear Maintainer,

The openvas package ships a script /usr/bin/openvas-setup which in about
line 30 calls the killall program - which isn't necessarily installed.

Please consider adding an according install dependency.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#939918: openvas: Please consider making rsync a dependency

[Christoph Biedl]

Package: openvas
Version: 9.0.3
Severity: normal

Dear Maintainer,

The openvas package ships a script /usr/bin/openvas-feed-update which 
uses rsync to update the local database.

Currently, openvas only recommends rsync - while in my opinion there
isn't much use of the package without updating the feeds. Therefore, I'd
like to suggest raising this to a dependency.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#939919: openvas: Misleading package description "dummy"

[Christoph Biedl]

Package: openvas
Version: 9.0.3
Severity: minor

Dear Maintainer,

The short description of the openvas package

| remote network security auditor - dummy package

suggests it does basically nothing, besides possibly depending on other
packages. Your package however does ship a few files as seen in
https://packages.debian.org/sid/all/openvas/filelist

Therefore I find that description a bit misleading. Care to adjust this
in the next upload?

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#936030: ***UNCHECKED*** Bug#936030: /usr/bin/cloud-init: cloud-init 18.3 failed to detect network link type: cascading (datasource: OpenStack)

[Sabrina-Mueller]

Hello Thomas,

cascading is a network type only available in OpenTelekomCloud based on Huawei 
Fusion.

We found this problem solved in
https://github.com/number5/cloud-init/commit/5352dd99eb2937b4eaaaf596b40ad7ca69d87f64



This still is not aware of network type: cascading but has a fallback.

This will result in a working cloud-init for us again.

Not sure if that is a solution you also want.



BW

Sabrina

On Thu, 29 Aug 2019 23:51:03 +0200 Thomas Goirand  wrote:
> On 8/29/19 11:25 AM, sabrina-muel...@t-systems.com wrote:
> > [...]
> > # w3m -dump http://169.254.169.254/openstack/latest/network_data.json |
> > jq ''
> >
> > {
> > [...]
> >   "links": [
> > {
> >   "type": "cascading",
>
> Hi Sabrina,
>
> Could you explain a little bit more what is "cascading" network type?
> What I run is OpenStack with OVS, so therefore, on the above, I get:
>
>   "links": [
> {
>   "type": "ovs"
>
> and then it works perfectly for me. So, what exactly is your network setup?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>

Bug#930735: WireGuard: Add resolvconf as optional dependency

[Willem van den Akker]

Hi dkg,


> It sounds to me like there is still no great suggestion on how to make
> this work smoothly, or a clear consensus on what we should do to ensure
> that the DNS = directive works for wg-quick :(

Correct. 

> 
> On Sat 2019-09-07 08:55:17 +0200, Willem van den Akker wrote:
> > If resolvectl is symlinked to resolvconf this also should work. But the
> > symlinked is not on my system. Even with resolvectl available.
> 
> For most modern debian systems, this seems like the simplest approach,
> but i don't think it's safe to assume it will work automatically yet.

I have the standard bullseye installation and a simple symlink to
resolv gives an error when starting wg-quick up wg0.

'[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.3.21/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
Failed to set DNS configuration: Unit dbus-
org.freedesktop.resolve1.service not found.
[#] ip link delete dev wg0'

> Perhaps the systemd source package could ship a systemd-resolvconf
> binary package that (a) enables and runs the systemd-resolved service
> automatically, and (b) ships the symlink from /sbin/resolvconf to
> resolvectl, and (c) Provides: and Conflicts: with resolvconf itself
> (similar to how openresolv does).

Sound as a good solution and would explain the error above.


> If systemd would do that, then i'd be willing to add a new control line
> for wireguard-tools as something like this:
> 
>Recommends: systemd-resolvconf | resolvconf
> 
> Does this seem like a plausible suggestion?  

Sure. Perhals the even the recommend of resolvconf can be left behind
if the systemd integration works.

/Willem

Bug#939904: Processed (with 1 error): Re: Bug#930735: WireGuard: Add resolvconf as optional dependency

[Michael Biebl]

Am 10.09.19 um 08:54 schrieb Michael Biebl:

> You're right about the resolvconf.1 man page. We should not ship that in
> the systemd man page since we don't ship the resolvconf symlink either

systemd package...


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

Bug#939917: at-spi2-core: obsolete conffiles left behind

[Sven Joachim]

Package: at-spi2-core
Version: 2.34.0-1
Severity: normal

In recent versions, two conffiles have been dropped from at-spi2-core,
but they remain on the system:

,
| $ adequate at-spi2-core
| at-spi2-core: obsolete-conffile /etc/environment.d/90qt-a11y.conf
| at-spi2-core: obsolete-conffile /etc/X11/Xsession.d/90qt-a11y
`

Please refer to dpkg-maintscript-helper(1) and dh_installdeb(1) how to
properly clean up obsolete conffiles.


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

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

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.34.0-1
ii  libc6  2.29-1
ii  libdbus-1-31.12.16-1
ii  libglib2.0-0   2.60.6-2
ii  libx11-6   2:1.6.7-1
ii  libxtst6   2:1.2.3-1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information

Bug#939904: Processed (with 1 error): Re: Bug#930735: WireGuard: Add resolvconf as optional dependency

[Michael Biebl]

wouldn't it be better if wireguard calls resolvctl directly?
Then it knows exactly what kind of behaviour it'll get.

You're right about the resolvconf.1 man page. We should not ship that in
the systemd man page since we don't ship the resolvconf symlink either
(for obvious reasons).

Regards,
Michael

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

Bug#936281: Patch for Python3 [Was: Bug#936281: centrifuge: Python2 removal in sid/bullseye]

[Andreas Tille]

Hi,

as you can read below Debian will remove Python2 support in the next
release.  I noticed that the issue tracker of centrifuge is switched
off on github so I hope you can be reached via this e-Mail.  I've
crafted a patch using 2to3 to port centrifuge to Python3.  You can
find it in the Debian packaging Git here:

   
https://salsa.debian.org/med-team/centrifuge/blob/master/debian/patches/2to3.patch

Feel free to incorporate it into your next release.

Kind regards

   Andreas.


Control: forwarded -1 centrifuge.metagenom...@gmail.com

- Forwarded message from Matthias Klose  -

Date: Fri, 30 Aug 2019 07:12:58 +
From: Matthias Klose 
To: mainto...@bugs.debian.org
Subject: Bug#936281: centrifuge: Python2 removal in sid/bullseye
X-Debian-PR-Message: report 936281
X-Debian-PR-Package: src:centrifuge
X-Debian-PR-Keywords: bullseye sid
X-Debian-PR-Source: centrifuge

Package: src:centrifuge
Version: 1.0.3-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:centrifuge

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

- End forwarded message -

-- 
http://fam-tille.de

Bug#939916: clfow: CVE-2019-16166

[Salvatore Bonaccorso]

Source: cflow
Version: 1:1.6-4
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg0.html
Control: found -1 1:1.6-1

Hi,

The following vulnerability was published for cflow.

CVE-2019-16166[0]:
| GNU cflow through 1.6 has a heap-based buffer over-read in the
| nexttoken function in parser.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-16166
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16166
[1] https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg0.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#931950: transition: libgeotiff

[Sebastiaan Couwenberg]

libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
be removed from testing due to gnudatalanguage, which I don't
understand. But this should be resolved when the package get autoremoved
on the 14th.

Kind Regards,

Bas

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

Bug#939915: clfow: CVE-2019-16165

[Salvatore Bonaccorso]

Source: cflow
Version: 1:1.6-4
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg1.html
Control: found -1 1:1.6-1

Hi,

The following vulnerability was published for cflow.

CVE-2019-16165[0]:
| GNU cflow through 1.6 has a use-after-free in the reference function
| in parser.c.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-16165
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16165
[1] https://lists.gnu.org/archive/html/bug-cflow/2019-04/msg1.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#842292: libnss3: re-enable SSLKEYLOGFILE support

[Tech Jsnelson]

On Thu, 27 Oct 2016 21:56:32 +0300 Evgeny Kapun 
wrote:
> Package: libnss3
> Version: 2:3.26-2
> Severity: wishlist
>
> In previous versions of libnss, it was possible to use SSLKEYLOGFILE
environment variable to save session keys to a file. Since version 3.24,
this is disabled by default at compile time [1].
>
> I think that SSLKEYLOGFILE support should be enabled for Debian builds of
libnss, since otherwise users who need this functionality have to make
their own builds of libnss.
>
> [1]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.24_release_notes
>
> transparency = none bug you type becomes a null abject congrats you
downgraded to no integrity, good job廊