Bug#799355: add found & fixed versions

[Nicholas D Steeves]

found 799355 apache-mode-el/2.1+4.g97bf66c-1
fixed 799355 apache-mode-el/2.2.0-2
tag 799355 - pending


signature.asc
Description: PGP signature

Bug#940933: Screensaver logins still broken

[I. Am]

Please ignore what I said about screensaver working. It's apparently 
intermittent.
-- 
Sent from my cellphone. Please excuse my brevity.

Bug#940933: upower.service fails to start; apparmor, hardening-runtime, or torbrowser conflict?

[ithink314]

Package: upower
Version: 0.99.11-1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
Relatively fresh install of Debian 10.1, upgraded to sid.
Installed apparmor profiles, and hardening-runtime 5+ hours later.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Installed hardening-runtime on a different hardware, 386, with delay
of ~20 hours after installing apparmor-profiles.
   * What was the outcome of this action?
Saw upower entries in syslog start showing errors after hardening-runtime
was installed. (see logs copied at end)
Screensaver logins (a previous bug report) work OK since this.
   * What outcome did you expect instead?
upower (and screensaver) works without errors.

NOTE: apparmor is mentioned because a log entry mentioned torbrowser,
which had issues on the 386 related to apparmor:

Sep 21 15:11:26 machine dbus-daemon[565]: [system] Activating via systemd: 
service name='org.freedesktop.UPower' unit='upower.service' 
requested by ':1.179' (uid=1000 pid= comm="./firefox.real --class Tor 
Browser -profile TorBro")



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

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

Versions of packages upower depends on:
ii  dbus   1.12.16-1
ii  libc6  2.29-1
ii  libglib2.0-0   2.60.6-2
ii  libgudev-1.0-0 233-1
ii  libimobiledevice6  1.2.1~git20181030.92c5462-1
ii  libplist3  2.0.1~git20190104.3f96731-1
ii  libupower-glib30.99.11-1
ii  libusb-1.0-0   2:1.0.23-1
ii  udev   242-7

Versions of packages upower recommends:
ii  policykit-1  0.105-26

upower suggests no packages.

-- no debconf information

syslog.6.gz:Sep 15 05:49:38 machine dbus-daemon[476]: [system] Activating via 
systemd: service name='org.freedesktop.UPower' unit='upower.service' requested 
by ':1.43' (uid=1000 pid=798 comm="xfsettingsd ")
syslog.6.gz:Sep 15 05:49:39 machine dbus-daemon[476]: [system] Successfully 
activated service 'org.freedesktop.UPower'
syslog.6.gz:Sep 15 13:12:15 machine systemd[1]: upower.service: Main process 
exited, code=killed, status=15/TERM
syslog.6.gz:Sep 15 13:12:15 machine systemd[1]: upower.service: Succeeded.
syslog.6.gz:Sep 15 14:09:47 machine systemd[1]: upower.service: Main process 
exited, code=killed, status=15/TERM
syslog.6.gz:Sep 15 14:09:47 machine systemd[1]: upower.service: Succeeded.
syslog.6.gz:Sep 15 14:11:09 machine dbus-daemon[525]: [system] Activating via 
systemd: service name='org.freedesktop.UPower' unit='upower.service' requested 
by ':1.90' (uid=1000 pid=822 comm="xfsettingsd ")
syslog.6.gz:Sep 15 14:11:10 machine dbus-daemon[525]: [system] Successfully 
activated service 'org.freedesktop.UPower'
syslog.6.gz:Sep 15 15:19:06 machine dbus-daemon[527]: [system] Activating via 
systemd: service name='org.freedesktop.UPower' unit='upower.service' requested 
by ':1.91' (uid=1000 pid=829 comm="xfsettingsd ")
syslog.6.gz:Sep 15 15:19:07 machine dbus-daemon[527]: [system] Successfully 
activated service 'org.freedesktop.UPower'
syslog.6.gz:Sep 16 19:06:27 machine systemd[1]: upower.service: Main process 
exited, code=killed, status=15/TERM
syslog.6.gz:Sep 16 19:06:27 machine systemd[1]: upower.service: Succeeded.
syslog.6.gz:Sep 16 19:07:07 machine dbus-daemon[527]: [system] Activating via 
systemd: service name='org.freedesktop.UPower' unit='upower.service' requested 
by ':1.2677' (uid=1000 pid=9619 comm="xfsettingsd ")
syslog.6.gz:Sep 16 19:07:09 machine dbus-daemon[527]: [system] Successfully 
activated service 'org.freedesktop.UPower'
syslog.6.gz:Sep 16 19:07:27 machine systemd[1]: upower.service: Main process 
exited, code=killed, status=15/TERM
syslog.6.gz:Sep 16 19:07:27 machine systemd[1]: upower.service: Succeeded.
syslog.6.gz:Sep 16 19:09:09 machine dbus-daemon[571]: [system] Activating via 
systemd: service name='org.freedesktop.UPower' unit='upower.service' requested 
by ':1.90' (uid=1000 pid=874 comm="xfsettingsd --display :0.0 --sm-client-id 
2bb50908")
syslog.6.gz:Sep 16 19:09:11 machine dbus-daemon[571]: [system] Successfully 
activated service 'org.freedesktop.UPower'


Start-Date: 2019-09-21  07:16:12
Commandline: apt-get install apparmor-easyprof apparmor-notify 
apparmor-profiles apparmor-profiles-extra apparmor-utils
Install: python3-libapparmor:amd64 (2.13.3-5, automatic), apparmor-notify:amd64 
(2.13.3-5), apparmor-profiles:amd64 (2.13.3-5), apparmor-easyprof:amd64 
(2.13.3-5), libapparmor-perl:amd64 (2.13.3-5, automatic), 
apparmor-profiles-extra:amd64 (1.27), python3-apparmor:amd64 (2.13.3-5, 
automatic), apparmor-utils:amd64 (2.13.3-5)
End-Date: 2019-09-21  07:16:27

Start-Date: 2019-09-21  11:20:55
Commandline: apt-get inst

Bug#940932: zfs-dkms: Reads from ZFS volumes cause system instability when SIMD acceleration is enabled.

[Alexander]

Package: zfs-dkms
Version: 0.8.1-4~bpo10+1
Severity: critical
Tags: upstream
Justification: causes serious data loss

Dear Maintainer,

recently I have noticed some instability on one of my machines.
The mprime (https://www.mersenne.org/download/) Torture Tests would occasionaly 
show errors like 

"FATAL ERROR: Rounding was 0.5, expected less than 0.4
Hardware failure detected, consult stress.txt file."

random commands would occasionaly segfault.

While trying to narrow down the problem I have replaced the PSU, RAM and the 
CPU. Multiple hour long runs of memtest86 did not show any problem.

Finally I was able to narrow down the reads from ZFS volumes as the trigger for 
the instability. 
Scrubbing the volume would cause mprime to error out especially quickly.

As a workaround I switched the SIMD acceleration off by piping "scalar" to 

/sys/module/zfs/parameters/zfs_vdev_raidz_impl and 
/sys/module/zcommon/parameters/zfs_fletcher_4_impl

and that made the system stable again.

Here are the details on the hardware I'm using:

Motherboard:X470 GAMING PLUS (MS-7B79) 
BIOS version: 7B79vAC
CPU:Ryzen 5 2600 and Ryzen 5 2600X

Please let me know if I can provide any other useful information for this issue.

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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  dkms   2.6.1-4
ii  file   1:5.35-4
ii  libc6-dev [libc-dev]   2.28-10
ii  libpython3-stdlib  3.7.3-1
ii  lsb-release10.2019051400
ii  perl   5.28.1-6
ii  python3-distutils  3.7.3-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  4.19.67-2
ii  zfs-zed 0.8.1-4~bpo10+1
ii  zfsutils-linux  0.8.1-4~bpo10+1

zfs-dkms suggests no packages.

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

Bug#940931: Gimp bug

[Darshan Narayan]

Package: gimp amd64 2.10.8-2+b1
```
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/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--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-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=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,hsa 
--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 9.2.1 20190827 (Debian 9.2.1-6) 

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.58.3 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
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:
```

# Stack traces obtained from PID 4172 - Thread 4172 #

[New LWP 4192]
[New LWP 4193]
[New LWP 4194]
[New LWP 4195]
[New LWP 4196]
[New LWP 4197]
[New LWP 4335]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffc8dfb3690, fd=16) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id  Frame 
* 1Thread 0x7febc50b1e00 (LWP 4172) "gimp-2.10"   __libc_read (nbytes=256, 
buf=0x7ffc8dfb3690, fd=16) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7febc3860700 (LWP 4192) "gmain"   0x7febc6f91b69 in 
__GI___poll (fds=0x56123827e2b0, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  3Thread 0x7febc2cee700 (LWP 4193) "gdbus"   0x7febc6f91b69 in 
__GI___poll (fds=0x5612382cec80, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  4Thread 0x7feba700 (LWP 4194) "async"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7febaf7fe700 (LWP 4195) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7febaeffd700 (LWP 4196) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7febae7fc700 (LWP 4197) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7febadffb700 (LWP 4335) "swap writer" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 8 (Thread 0x7febadffb700 (LWP 4335)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7febc72a6f9f in g_cond_wait () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x7febc79400cd in ?? () from /lib/x86_64-linux-gnu/libgegl-0.4.so.0
No symbol table info available.
#3  0x7febc7285425 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x7febc706dfa3 in start_thread (arg=) at 
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140650213259008, 
6519144276422616457, 140722690535774, 140722690535775, 140650213259008, 
94636254298768, -6507704954915854967, -6507937717817252471}, mask_was_saved = 
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 
canceltype = 0}}}
not_first_call = 
#5  0x7febc6f9c82f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Thread 7 (Thread 0x7febae7fc700 (LWP 4197)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7febc72a6f9f in g_cond_wait () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x561237b7fd73 in ?? ()
No symbol table info available.
#3  0x7febc7285425 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x7febc706dfa3 in start_thread (arg=) at 
pthread_create.c:486
ret = 

Bug#940881: RFH: freedombox -- debian pure blend, user-friendly, privacy-oriented home server

[Paul Wise]

On Sat, Sep 21, 2019 at 8:39 PM James Valleroy wrote:

> FreedomBox is looking for new contributors.

I invite you to announce this on d-d-a via Misc Developer News:

https://wiki.debian.org/DeveloperNews

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#940930: devscripts: add new script for self-service give-backs

[Paul Wise]

Package: devscripts
Severity: wishlist
X-Debbugs-CC: Philiip Kern , debian-wb-t...@lists.debian.org

Please add a new script for contributors to do self-service give-backs
from the command-line, perhaps something like this:

   wanna-build-sso gb --packages foo bar baz --architectures amd64 i386 
--suites unstable experimental

Here is a copy of the announcement and blog post for your reference:

https://lists.debian.org/msgid-search/8b000c23ac2defbfeea7d5a0bc28ec2e3df55baa.ca...@debian.org

   Self-service buildd givebacks
   -

Philipp Kern has created[1] an *experimental* service that allows Debian
members to perform self-service retries of failed package builds (aka
give-backs). This service aims to reduce the time it takes for give-back
requests to be processed, which was done manually by the wanna-build
admins until now. The service is authenticated using the Debian Single
Signon[2] service. Debian members are still expected to act responsibly
when looking at build failures; do your due diligence and try reproducing
the issue on a porterbox first. Access to this service is logged and logs
will be audited by the admins.

 -- Paul Wise

[1] 
https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html
[2] https://sso.debian.org/

https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html

Alpha: Self-service buildd givebacks

   Builds on Debian's build farm sometimes fail transiently. Sometimes
   those failures are legitimate flakes, for instance when an in-
   progress build happens to exhaust its resources because of other
   builds on the same machine. Until now, you always needed to mail the
   buildd, wanna-build admins or the Release Team directly in order to
   get the builds re-queued.

   As an alpha trial I implemented self-service givebacks as a web
   script. As SSO for Debian developers is now a thing, it is trivial
   to add authentication in a way that a role account can use to act on
   your behalf. While at work this would all be an RPC service, I
   figured that a little CGI script would do the job just as well. So
   lo and behold, accessing
   
https://buildd.debian.org/auth/giveback.cgi?pkg=&suite=&arch=
   with the right parameters set:

  You are authenticated as pkern. ✓
  Working on package fife, suite sid and architecture mipsel. ✓
  Package version 0.4.2-1 in state Build-Attempted, can be given back. ✓
  Successfully given back the package. ✓

   Note that you need to be a Debian developer with a valid SSO client
   certificate to access this service.

   So why do I say alpha? We still expect Debian developers to act
   responsibly when looking at build failures. A lot of times there is
   a legitimate bug in the package and the last thing we would like to
   see as a project is someone addressing flakiness by continuously
   retrying a build. Access to this service is logged. Most people
   coming to us today did their due diligence and tried reproducing the
   issue on a porterbox. We still expect these things to happen but
   this aims to cut on the round-trip time until an admin gets around
   to process your request, which have been longer than necessary
   recently. We will audit the logs and see if particular packages
   stand out.

   There can also still be bugs. Please file them against
   buildd.debian.org when you see them. Please include a copy of the
   output, which includes validation and important debugging
   information when requests are rejected. Also this all only works for
   packages in Build-Attempted. If the build has been marked as Failed
   (which is a manual process), you still need to mail us. And lastly
   the API can still change. Luckily the state change can only happen
   once, so it's not much of a problem for the GET request to be
   retried. But it should likely move to POST anyhow. In that case I
   will update this post to reflect the new behavior.

   Thanks to DSA for making sure that I run the service sensibly using
   a dedicated role account as well as WSGI and doing the work to set
   up the necessary bits.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#863118: devscripts configuration

[Paul Wise]

On Sat, 2019-09-21 at 18:21 +0200, Nicolas Boulenguez wrote:

> Could you give an example of unsafety not yet covered by Confvar tests?
> I fail to understand what you mean by reading your commits.

My commits were about establishing a protocol between the generated
config parser bash script and the Perl code calling that bash script
such that the Perl code does not have to have knowledge of how shell
quoting works, only of how to establish the protocol from shell.

It does that by avoiding layering violations between shell and Perl;
passing filenames as arguments and returning variables NUL separated.

> My point was that your sentence suggests
> - that several scripts use Config. Actually, only one does.

I count three scripts that use Config (salsa, uscan, mk-origtargz).

> Could you detail some of the needed differences?

A few thoughts:

Don't use an absolute path to bash.

Unsetting the environment represents a change in the interface between
devscripts and people's config files. An example of what could break:
if someone sets HOME in their running zsh to a subdirectory, and in
that directory has a devscripts config that uses ~/ then unsetting HOME
could mean that the devscripts config would use their main home
directory instead of the subdirectory they wanted to use.

Checking the syntax of the config files represents a change in the
interface between devscripts and people's config files; config files
that contain valid variables at the start and syntax errors at the end
would stop setting the valid variables from the start.

Telling bash to exit on errors by passing the -e option to bash
represents a change in the interface between devscripts and people's
config files. It could cause later parts of the config files to
silently stop working if they have a command near the start that does
not succeed.

In the perl code use q{}/qq{} instead of ''/"" for readability; this is
so that you can use quoting characters in the shell code without
escaping them with backslash characters, which reduce the readability.

Use the spawn function from Dpkg::IPC instead of backticks because they
introduce an extra unnecessary shell process while spawn does not use
the shell so there can be no quoting issues no matter what is passed.

Pass the config filenames as arguments to the generated bash script and
load the files from those arguments instead of from quoted strings.
This avoids any possible mismatch between bash/Perl quoting code.

Use NUL characters (\0) to split the output up, this allows all
characters to be represented instead of relying on Perl code to parse
the output of the bash set command.

One enhancement I should have added to the Config module but didn't
think of until now is to ensure that the stderr isn't parsed and that
any output the devscripts config generates also isn't parsed by the
Perl code. Probably the way to do this is to print a few NUL characters
in a row to indicate the start of the exported variables and discard
any output before those NUL characters. Of course the devscripts config
could print the NULs too and thus break the parsing, but outputting
NULs from one's devscripts config seems unlikely to exist today.

> It seemed right to answer a bug requesting help in the bug log,
> but let us try a merge request instead.
> https://salsa.debian.org/debian/devscripts/merge_requests/162

This seems like a few separate issues all on one branch, usually they
would be separate merge requests. I'd also squash the new code plus
fixes to and perltidy of the new code into one commit.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#940929: quassel-client: support wayland

[Alok Singh]

Package: quassel-client
Version: 1:0.13.1-1
Severity: wishlist

Dear Maintainer,

QT5 does have some wayland support. Since quassel-core already brings
in a bunch of dependencies, would you consider adding wayland to the
mix?

Currently, adding -platform wayland to the command line causes a segfault.

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

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

Versions of packages quassel-client depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.16-1
ii  libc62.29-2
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-2
ii  libgcc1  1:9.2.1-8
ii  libkf5configwidgets5 5.62.0-1
ii  libkf5coreaddons55.62.0-1
ii  libkf5notifications5 5.62.0-1
ii  libkf5notifyconfig5  5.62.0-1
ii  libkf5sonnetui5  5.62.0-1
ii  libkf5textwidgets5   5.62.0-1
ii  libkf5widgetsaddons5 5.62.0-1
ii  libkf5xmlgui55.62.0-1
ii  libqt5core5a 5.11.3+dfsg1-4
ii  libqt5dbus5  5.11.3+dfsg1-4
ii  libqt5gui5   5.11.3+dfsg1-4
ii  libqt5multimedia55.11.3-2
ii  libqt5network5   5.11.3+dfsg1-4
ii  libqt5webenginewidgets5  5.11.3+dfsg-2+b1
ii  libqt5widgets5   5.11.3+dfsg1-4
ii  libstdc++6   9.2.1-8
ii  quassel-data 1:0.13.1-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

quassel-client recommends no packages.

quassel-client suggests no packages.

-- no debconf information

Bug#940927: RFS: color-theme-modern/0.0.2+4.g42a7926-1 [ITP] -- deftheme reimplementation of classic Emacs color-themes

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "color-theme-modern".  This
functionality was previously provided by the emacs-goodies-el package.

Package name: color-theme-modern
Version : 0.0.2+4.g42a7926-1
Upstream Author : Syohei YOSHIDA
URL : https://github.com/emacs-jp/replace-colorthemes
License : GPL-3+
Vcs : https://salsa.debian.org/emacsen-team/color-theme-modern.git
Section : lisp

It builds this binary package:

  elpa-color-theme-modern - deftheme reimplementation of classic Emacs 
color-themes

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

  https://mentors.debian.net/package/color-theme-modern

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/color-theme-modern/color-theme-modern_0.0.2+4.g42a7926-1.dsc

Changes since the last upload:

   * Initial release. (Closes: #905246)

Regards,
Nicholas

Bug#940928: texlive-latex-recommended: File 'pgfcore.sty' not found during minimal example Beamer compile

[Karl Sickendick]

Package: texlive-latex-recommended
Version: 2019.20190830-1
Severity: normal

Dear Maintainer,
After installing the "texlive" package, which depends on "texlive-latex-
recommended", I attempted to compile a beamer document (just the minimal
working example from here: https://www.overleaf.com/learn/latex/Beamer).  I
got
the following error:

'''
! LaTeX Error: File `pgfcore.sty' not found.
'''

Full output:
'''
 % pdflatex talk_presentation.latex
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian)
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./talk_presentation.latex
LaTeX2e <2018-12-01>
(/usr/share/texlive/texmf-dist/tex/latex/beamer/beamer.cls
Document Class: beamer 2019/07/23 v3.56 A class for typesetting
presentations
(/usr/share/texlive/texmf-dist/tex/latex/beamer/beamerbasemodes.sty
(/usr/share/texlive/texmf-dist/tex/latex/etoolbox/etoolbox.sty)
(/usr/share/texlive/texmf-dist/tex/latex/beamer/beamerbasedecode.sty))
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty)
(/usr/share/texlive/texmf-dist/tex/latex/beamer/beamerbaseoptions.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty))
(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty)
(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty))
(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo)

! LaTeX Error: File `pgfcore.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name: ^C! Interruption.
'''


I installed "texlive-pictures" to fix this bug, after which the file
compiled
fine.  Additional packages installed were "tcl tcl8.6 tk tk8.6".

I suspect texlive-pictures should be a dependency of "texlive-latex-
recommended".


##
 List of ls-R files

-rw-r--r-- 1 root root 1336 Sep 21 16:14 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jul 31 01:21 /usr/share/texmf/ls-R ->
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Aug 29 19:33 /usr/share/texlive/texmf-dist/ls-R
-> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Aug 29 19:33 /usr/share/texlive/texmf-dist/ls-R
-> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Sep 21 15:59 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Aug 29 19:33 /usr/share/texmf/web2c/fmtutil.cnf
-> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Aug 29 19:33 /usr/share/texmf/web2c/updmap.cfg ->
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2763 Sep 21 15:59
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jul 31 01:21 mktex.cnf
-rw-r--r-- 1 root root 475 Sep 21 15:59 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-recommended depends on:
ii  tex-common  6.12
ii  texlive-base2019.20190830-1
ii  texlive-binaries2019.20190605.51237-2
ii  texlive-latex-base  2019.20190830-1

texlive-latex-recommended recommends no packages.

Versions of packages texlive-latex-recommended suggests:
pn  texlive-latex-recommended-doc  
pn  texlive-luatex 
pn  texlive-pstricks   

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
pn  debhelper  

Versions of packages texlive-latex-recommended is related to:
ii  tex-common6.12
ii  texlive-binaries  2019.20190605.51237-2

-- no debconf information

-- 
-Karl

Bug#940192: wine-development: msi regression, not installing dotnet35sp1

[Allan M. de Azevedo]

Jens,

I'm really sorry for all the mess that I'm causing with this bug report. But I 
have another unfortunate finding: I'm getting "MSI_OpenDatabaseW unknown flag 
(nil)" trying to install dotnet35sp1 in wine-4.0.2

When I made the bug report, the installer of Office 2007 SP3 was triggering the 
issue. When I saw that dotnet35sp1 was affected to, I changed the focus to this 
installer. At that time, the Office SP3 was installed successfully in 
wine-4.0.2 (Debian). I didn't tested dotnet35sp1.

I"ll try to explain this and summarize all the facts in upstream report.

Bug#924192: Is this fix going to make it into Buster any time soon?

[Rick Thomas]

> On Sep 21, 2019, at 12:13 PM, Richard Laager  wrote:
> 
> On 9/21/19 7:22 AM, Rick Thomas wrote:
>> I’d really like to see this fix make it into Debian Buster!
>> Any chance of that?
> 
> I dropped the ball on this before the Buster release, for lack of time.
> My intention is to try to get this into a point release. I'm intending
> on doing that tomorrow. So hopefully it will land in the next point release.
> 
> -- 
> Richard

Thanks!  I’m looking forward to it.  Will the .deb be available somewhere I can 
pick it up?  So I don’t have to wait for the next point release to install it…

Enjoy!
Rick

Bug#905239: emacs-goodies: color-theme-modern alternative to color-theme

[Nicholas D Steeves]

On Sat, Sep 21, 2019 at 10:20:53AM -0300, David Bremner wrote:
> Nicholas D Steeves  writes:
> 
> > Here is a link to a downstream copy of this bug:
> > https://bugs.launchpad.net/ubuntu/+source/emacs-goodies-el/+bug/1817480
> >
> > By the "heat" indicator there are at least two Ubuntu users who want
> > this package, plus at least one Debian user.
> >
> > David, do you think it would be appropriate to tag this bug as
> > newcomer?  Upstream hasn't made any git commits since 2016, but these
> > are classic themes that are won't need to be modified--assuming no
> > bugs.
> 
> This bug all seems a bit theoretical unless someone is going to package
> color-themes-modern
> 
> d

Fair point.  Oh, it seems I replied to the wrong bug...this was
intended for the RFP one.

At any rate, I decided to not wait for a newcomer and packaged it.
I'm still waiting for the package to show up on mentors :-/ If you'd
like to sponsor from git, here's the remote:

  g...@salsa.debian.org:emacsen-team/color-theme-modern.git


Cheers,
Nicholas

Bug#916614: mkdocs-bootswatch: Incompatible with mkdocs 0.17

[Brian May]

Brian May  writes:

> If it is not needed anymore, and nobody has the time to maintain it,
> might be best to remove it.

Removal request sent, see Bug#940923.
-- 
Brian May 

Bug#921559: MTP broken for number of phones with "LIBMTP PANIC: Unable to initialize device"

[debdebug]

On Thu, 5 Sep 2019 21:49:41 +0200 Eric Van Buggenhaut 
 wrote:

On Sun, 4 Aug 2019 18:59:34 +0300 Vincas Dargis  wrote:
> On Thu, 11 Apr 2019 09:20:01 +0200 Erwan David
 wrote:
> > Same problem with a Huawei P9 Lite (2017)
>
> My problems are fixed now with libmtp 1.1.16 on Sid. Does it work now
for you too?
>
>

I'm experiencing the same problem with libmtp 1.1.16 on Buster:

$ mtp-detect
libmtp version: 1.1.16

Listing raw device(s)
Device 0 (VID=18d1 and PID=4ee2) is a Google Inc Nexus/Pixel (MTP+ADB).
   Found 1 device(s):
   Google Inc: Nexus/Pixel (MTP+ADB) (18d1:4ee2) @ bus 1, dev 38
Attempting to connect device(s)
error returned by libusb_claim_interface() = -6LIBMTP PANIC: Unable to
initialize device
Unable to open raw device 0
OK.





Getting identical problems using libmtp 1.1.16 on Fedora with  Huawei 
Honor 5 ( which is called Ascend P8 according to ProdID )


mtp-detect
libmtp version: 1.1.16

Listing raw device(s)
Device 0 (VID=12d1 and PID=1082) is a Huawei Ascend P8.
   Found 1 device(s):
   Huawei: Ascend P8 (12d1:1082) @ bus 2, dev 9
Attempting to connect device(s)
error returned by libusb_claim_interface() = -6LIBMTP PANIC: Unable to 
initialize device

Unable to open raw device 0
OK.

Bug#940925: freerdp2-x11: Option /gfx or /gfx-264:AVC444 crash when used with /sound Option

[Andreas Schneider]

Package: freerdp2-x11
Version: 2.0.0~git20190204.1.2693389a+dfsg1-1
Severity: important
Tags: patch

Dear Maintainer,

This problem is solved on the latest nighty build

https://github.com/FreeRDP/FreeRDP/wiki/Compilation
->
ln -s packaging/deb/freerdp-nightly debian
dpkg-buildpackage




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

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

Versions of packages freerdp2-x11 depends on:
ii  libc6 2.28-10
ii  libfreerdp-client2-2  2.0.0~git20190204.1.2693389a+dfsg1-1
ii  libfreerdp2-2 2.0.0~git20190204.1.2693389a+dfsg1-1
ii  libwinpr2-2   2.0.0~git20190204.1.2693389a+dfsg1-1
ii  libx11-6  2:1.6.7-1
ii  libxcursor1   1:1.1.15-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.4-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxv12:1.0.11-1

freerdp2-x11 recommends no packages.

freerdp2-x11 suggests no packages.

-- no debconf information

Bug#940924: python3-rope: the license has been changed without the main author's consent

[Salman Mohammadi]

Package: python3-rope
Version: 0.10.5-3
Severity: grave

Dear Maintainer,

As can be seen here[1], the license of this package has been changed 
from GPL to LGPL without

the consent of the main author.

[1] https://github.com/python-rope/rope/pull/266

I don't know, if it is still relevant to keep this orphaned package in
Debian anymore.

Regards,
Salman


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-rope depends on:
ii python3 3.7.3-1

Versions of packages python3-rope recommends:
ii git [git-core] 1:2.23.0-1
ii mercurial 5.1.1-1
ii python3-svn 1.9.9-1+b1

python3-rope suggests no packages.

-- no debconf information

Bug#940923: RM: mkdocs-bootswatch -- ROM; No longer required

[Brian May]

Package: ftp.debian.org
Severity: normal

This package is no longer required, and has no interest.

See #916614.

Bug#940922: perl: iterating hash with "each", no write to hash but references got messed up

[Leszek Dubiel]

Package: perl
Version: 5.24.1-3+deb9u5
Severity: normal

I was trying to make program below as simple as possible, but I don't 
understand where is the bug introduced. 

The task is to make a copy of hash such that keys in new hash are made only out 
of alphanumerics and underscores "_". Hashes are nested. 

Here is the program: 

#!/usr/bin/perl 

use Data::Dumper; 

sub hash_is_okey { 
ref $_[0] eq "HASH" or return 0;  

# for my $k (keys %{$_[0]}) { 
#   my $v = ${$_[0]}{$k}; 

while (my ($k, $v) = each %{$_[0]}) { 
$k =~ /\A[_[:alnum:]]+\z/ or return 0; 
hash_ok_or_scalar($v) or return 0; 
}
return 1;
}

sub hash_ok_or_scalar { return hash_is_okey($_[0]) || ! ref $_[0]; }

sub make_hash_with_good_keys { 
my ($x) = $_[0]; 

hash_ok_or_scalar($x) and return $x; 

ref $x eq "HASH" or die; 

# copy hash "%{$x}" to new hash "%h" but make names good 
my %h; 
for my $k (keys %$x) { 

# copy "$k" to "$n", then make good name of "$n"
my $n = $k =~ s/[^[:alnum:]]/_/gr; 

$h{$n} = make_hash_with_good_keys($$x{$k}); 
} 
return \%h; 
}

my $original = { "top_level" => { "level down" => 123 } }; 
my $with_good_keys = make_hash_with_good_keys($original); 

print Dumper($original, $with_good_keys); 


and here is the result: 

$VAR1 = {
  'top_level' => {
   'level down' => 123
 }
};
$VAR2 = {
  'top_level' => $VAR1->{'top_level'}
};

In program hash "$with_good_keys" is made by:
* initializing new hash "%h", and then asigning to that hash new value
   or 
* plugging reference if "subhash" has good keys. 

But the result is bad, because "VAR2" has bad key "level down" -- contains 
space. 


If I change this part of program: 

# for my $k (keys %{$_[0]}) { 
#   my $v = ${$_[0]}{$k}; 

while (my ($k, $v) = each %{$_[0]}) { 

to look like this (uncomment "for...keys", comment "while...each"): 

for my $k (keys %{$_[0]}) { 
my $v = ${$_[0]}{$k}; 

# while (my ($k, $v) = each %{$_[0]}) { 

then result is: 

$VAR1 = {
  'top_level' => {
   'level down' => 123
 }
};
$VAR2 = {
  'top_level' => {
   'level_down' => 123
 }
};

Now "$VAR2" is a copy with names modified as expected. 

This is extremely strange, because I don't write to hash I am iterating over 
with "while...each". I tried to
resolve this myself for many hours, but I failed. 



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

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

Versions of packages perl depends on:
ii  dpkg   1.18.25
ii  libperl5.245.24.1-3+deb9u5
ii  perl-base  5.24.1-3+deb9u5
ii  perl-modules-5.24  5.24.1-3+deb9u5

Versions of packages perl recommends:
ii  netbase  5.4
pn  rename   

Versions of packages perl suggests:
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
pn  make
pn  perl-doc

-- no debconf information

Bug#940908: slapd: validate_initial_config slapd/domain can fail if LC_COLLATE is set to non-ASCII

[Ryan Tandy]

Control: found -1 2.4.47+dfsg-3
Control: tag -1 pending

Thank you for the report and analysis. Fixed in git for the next upload.

Bug#932246: Re : Bug#932246: Re : Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Brian Potkin]

On Sat 21 Sep 2019 at 22:25:25 +0200, Francesco Poli wrote:

> On Sat, 21 Sep 2019 19:14:07 +0100 Brian Potkin wrote:
> 
> > On Sat 21 Sep 2019 at 17:45:06 +0200, Francesco Poli wrote:
> [...]
> > > Unless I am misinterpreting something, this bug seems to have vanished
> > > or have been fixed in printer-driver-hpcups/3.19.8+dfsg0-1
> > 
> > You are not using printer-driver-hpcups.
> 
> Am I not?!?

Not according to the PPD you used to set up the queue.

 > -m drv:///hpijs.drv/hp-laserjet_1320-hpijs.ppd

An hpijs PPD doesn't use the hpcups filter.
 
> > > I do not understand why other users seem to get different experiences...
> > 
> > Perhaps you could set up a queue with printer-driver-hpcups to gain some
> > understanding.
> 
> I thought that
> 
>   # lpadmin -x lj
>   # lpadmin -p lj -E \
> -v 'usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9' \
> -m drv:///hpijs.drv/hp-laserjet_1320-hpijs.ppd \
> -o pdftops-renderer-default=pdftops \
> -L local -D "HP LaserJet 1320"
>   lpadmin: Printer drivers are deprecated and will stop working in a future 
> version of CUPS.
>   # lpoptions -p lj -o media=A4 -o sides=two-sided-long-edge
>   # lpadmin -d lj
> 
> did set up a queue with printer-driver-hpcups.

The hp-laserjet_1320-hpijs.ppd is not in printer-driver-hpcups.

> At the very least, this was the queue where I originally experienced the
> bug (please remember that I am the original bug report submitter!).
> And the error log said that "/usr/lib/cups/filter/hpcups" had "crashed
> on signal 6".
> And
> 
>   $ dpkg -S /usr/lib/cups/filter/hpcups
>   printer-driver-hpcups: /usr/lib/cups/filter/hpcups
> 
> This is what made me conclude that the bug was in package
> printer-driver-hpcups.

It could be me who is confused.

Cheers,

Brian.

Bug#940679: pandas: random test crashes

[Rebecca N. Palmer]

The ppc64 failure was this bug, specifically the
pandas/tests/indexes/interval/test_astype.py::TestDatetimelikeSubtype::test_astype_category[index3] 
version.  It was retried successfully.  (The hppa failure is something 
else.)


The "Build environment" section of the build log (i.e. the versions of 
all installed packages, both build-essential and explicit dependencies) 
is identical between the failed and successful attempts.


pandas isn't fully reproducible, but the -lib parts (i.e. where one can 
get a segfault as opposed to an exception) are 
(https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/pandas.html), 
so this suggests the randomness is per test run not per build.


And hence that it only happens when running more than just these tests 
(given that it didn't happen in far more attempts of that).


debci has one failure that _might_ be this (it's old enough that the log 
has been deleted) out of ~140 attempts, which suggests the bug is new. 
(Or newly exposed: maybe by locales-all, added as a build/test 
dependency in -5?)

Bug#940192: wine-development: msi regression, not installing dotnet35sp1

[Allan M. de Azevedo]

Hi jre,

First of all: sorry for my delay.

When I sent this bug report, I was using the 4.11-1 Debian package.
The dotnet35sp1 wasn't installing, returning that errors.

The upstream commit 7cd3c9f0734d217e1d08319e72a9df91fe2ef882 [1]
triggered the mingw issue, and this was between wine-4.10 and wine-4.11.

I just tested here with wine-4.16 (Debian 4.16-1) and the dotnet35sp1 install 
was unsuccessful.
$ env WINE=$(which wine-development) winetricks dotnet35sp1

So, it might be that my assumption is wrong for Debian package. When I posted 
my finding upstream, I was building wine from git in Arch Linux, and was able 
to install dotnet35sp1 from 4.15 that was previously failing.

[1] 
https://source.winehq.org/git/wine.git/commit/7cd3c9f0734d217e1d08319e72a9df91fe2ef882

Bug#940907: gimp: Gimp crashes on loading a .png image file.

[Bernhard Übelacker]

Control: forcemerge 939754 940907


Hello Stefan Pietzonke,
this issue is tracked in bug #939754 and should
disappear by installing latest updates
to libgegl-0.4-0 in version 0.4.14-2.

This was caused by gimp 2.10.8-2+b1 being built
against libgegl-0.4-0 in version 0.4.14-1,
but running with version 0.4.12-2 causes a crash.

Kind regards,
Bernhard

Bug#939598: marked as done (libubootenv-tool: trying to overwrite '/usr/bin/fw_printenv', which is also in package u-boot-tools 2019.01+dfsg-7)

[Vagrant Cascadian]

> Preparing to unpack .../15-libubootenv-tool_0.1-1_amd64.deb ...
> Unpacking libubootenv-tool (0.1-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-S5V5yb/15-libubootenv-tool_0.1-1_amd64.deb (--unpack
> ):
>  trying to overwrite '/usr/bin/fw_printenv', which is also in package 
> u-boot-tools 2019.01+dfsg-7
>
> Since the packages are both u-boot related, the new program might have
> the same functionality as the existing one and hence using
> update-alternatives for the two variants maybe an option.
...
>  libubootenv (0.1-2) unstable; urgency=medium
>  .
>* Add u-boot-tools Conflicts of libubootenv-tool (Closes: #939598)

This seems like a rather sub-optimal solution to the problem; now it's
impossible to install u-boot-tools at the same time, which has other
functionality as well. There are also packages that depend or recommend
on u-boot-tools that won't be able to be installed or may have reduced
functionality when libubootenv-tool is installed.

Many of these packages would seem quite reasonable to have installed
with both libubootenv-tool and u-boot-tools installed at the same
time, such as u-boot-sunxi...

Is there anything in the libubootenv's fw_printenv and fw_setenv
implementations that's significantly different from u-boot-tools?

Couldn't libubootenv-tool depend on u-boot-tools instead of conflicting
with it?  Or would it make sense for u-boot-tools to depend on
libubootenv-tool instead? Is this likely to be merged in upstream u-boot
at some point?

Alternately, the original suggestion of using the alternatives system
would at least allow both packages to coexist at the same time, at the
cost of some additional complication in both packages maintainer
scripts.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

# merging this bug with 921178
severity 940914 important
reassign 940914 libreoffice
found 940914 1:6.1.5-3+deb10u4
forcemerge 940914 921178
thanks

On Sat, Sep 21, 2019 at 09:12:36PM +0200, Michel Le Bihan wrote:
> Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
> 0x7f78d70bab32 in cppu::_copyConstructAnyFromData (mapping=0x0, 
> acquire=0x7f78db10c360,
> pTypeDescr=, pType=, 
> pSource=0x7ffcf8b48b50, pDestAny=0x5624f7df75f8)

Just googled for this
(https://www.google.de/search?q=cppu%3A%3A_copyConstructAnyFromData&oq=cppu%3A%3A_copyConstructAnyFromData&aqs=chrome..69i57j69i58j69i61.429j0j7&sourceid=chrome&ie=UTF-8)
 and found

https://bugs.documentfoundation.org/show_bug.cgi?id=106264
(Closed upstream...)

and the old (admittedly no reply)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921178
That backtrace looks similar Merging with this one.

(and Ubuntu had it too without any info:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1055685
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1049931)

Regards,

Rene

Bug#940921: RM: src:turbogears2{,doc} -- RoM; obsolete libs (Python 2), low popcon

[GCS]

Package: ftp.debian.org
Severity: normal

Hi FTP Masters,

Turbogears is not a common web framework anymore. Current packaging is
Python 2 only. Has low popcon due to the former. Please remove it from
the archives.

Thanks,
Laszlo/GCS

Bug#940920: ktouch: unable to rend properly on hidpi displays, fixed in upstream 19.08.1

[Nils Jarle Haugen]

Package: ktouch
Version: 4:18.04.1-1
Severity: minor

Dear Maintainer,

When trying to use the program on hidpi displays & scaling enabled some
ui elements appear broken. The appliction is still fully functionable,
as this only affects the ui. I use a display with resolution of
2560x1440 px with 1.2 as scaling factor. I've uploaded a screenshot of
the situation: https://i.imgur.com/zQslGex.png 

19.08.1 has now been released upstream, and ktouch now supports hidpi
displays.Please see this blog for more information:

https://blog.sebasgo.net/2019/08/15/ktouch-in-kde-sc-19-08-0/

I hope it's possible to pull 19.08 soon to testing (or at least sid).

Thank you !

Best regards,
Nils Jarle Haugen


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

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

Versions of packages ktouch depends on:
ii  ktouch-data   4:18.04.1-1
ii  libc6 2.29-1
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-2
ii  libkf5configgui5  5.54.0-2
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5declarative55.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5itemviews5  5.54.0-1
ii  libkf5kcmutils5   5.54.0-1
ii  libkf5service-bin 5.54.0-1
ii  libkf5service55.54.0-1
ii  libkf5textwidgets55.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5core5a  5.11.3+dfsg1-4
ii  libqt5gui55.11.3+dfsg1-4
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5quickwidgets5   5.11.3-4
ii  libqt5sql55.11.3+dfsg1-4
ii  libqt5widgets55.11.3+dfsg1-4
ii  libqt5x11extras5  5.11.3-2
ii  libqt5xml55.11.3+dfsg1-4
ii  libqt5xmlpatterns55.11.3-2
iu  libstdc++69.2.1-8
ii  libx11-6  2:1.6.7-1
ii  libxcb-xkb1   1.13.1-2
ii  libxcb1   1.13.1-2

ktouch recommends no packages.

ktouch suggests no packages.

-- no debconf information

Bug#938042: Package is apparently abandoned upstream

[Chris Lawrence]

This package has apparently been completely abandoned by the author;
there is no trace of it on the Internet that I can find beyond the
Debian package.

Any existing code should consider using the heapq library in the
standard Python distribution as a substitute.


Chris
-- 
Chris Lawrence  - http://blog.lordsutch.com/

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

On Sat, Sep 21, 2019 at 09:12:36PM +0200, Michel Le Bihan wrote:
> -- System Information:
> Debian Release: 10.1
>   APT prefers stable-debug
>   APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
> 'stable')

Just to see whether it had an affect I upgraded to proposed-updates
included. See [1]. Still works.

Regards,

Rene

[1]
only affected freetype:

$ sudo apt upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete werden aktualisiert (Upgrade):
  freetype2-doc libfreetype6 libfreetype6:i386 libfreetype6-dev
4 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 3.626 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 5.120 B Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 
Holen:1 http://deb.debian.org/debian buster-proposed-updates/main amd64 
freetype2-doc all 2.9.1-3+deb10u1 [2.309 kB]
Holen:2 http://deb.debian.org/debian buster-proposed-updates/main amd64 
libfreetype6-dev amd64 2.9.1-3+deb10u1 [544 kB]
Holen:3 http://deb.debian.org/debian buster-proposed-updates/main i386 
libfreetype6 i386 2.9.1-3+deb10u1 [395 kB]
Holen:4 http://deb.debian.org/debian buster-proposed-updates/main amd64 
libfreetype6 amd64 2.9.1-3+deb10u1 [380 kB]
Es wurden 3.626 kB in 1 s geholt (4.658 kB/s).
Changelogs werden gelesen... Fertig
(Lese Datenbank ... 277706 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../freetype2-doc_2.9.1-3+deb10u1_all.deb ...
Entpacken von freetype2-doc (2.9.1-3+deb10u1) über (2.9.1-3) ...
Vorbereitung zum Entpacken von .../libfreetype6-dev_2.9.1-3+deb10u1_amd64.deb 
...
Entpacken von libfreetype6-dev:amd64 (2.9.1-3+deb10u1) über (2.9.1-3) ...
Vorbereitung zum Entpacken von .../libfreetype6_2.9.1-3+deb10u1_i386.deb ...
libfreetype6:amd64 (2.9.1-3) wird de-konfiguriert ...
Entpacken von libfreetype6:i386 (2.9.1-3+deb10u1) über (2.9.1-3) ...
Vorbereitung zum Entpacken von .../libfreetype6_2.9.1-3+deb10u1_amd64.deb ...
Entpacken von libfreetype6:amd64 (2.9.1-3+deb10u1) über (2.9.1-3) ...
freetype2-doc (2.9.1-3+deb10u1) wird eingerichtet ...
libfreetype6:amd64 (2.9.1-3+deb10u1) wird eingerichtet ...
libfreetype6:i386 (2.9.1-3+deb10u1) wird eingerichtet ...
libfreetype6-dev:amd64 (2.9.1-3+deb10u1) wird eingerichtet ...
Trigger für libc-bin (2.28-10) werden verarbeitet ...
$

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

tag 940914 + moreinfo
tag 940914 + unreproducible
thanks

Hi,

On Sat, Sep 21, 2019 at 09:12:36PM +0200, Michel Le Bihan wrote:
> Package: uno-libs3
> Version: 6.1.5-3+deb10u4
> Severity: grave

Why?

> Justification: renders package unusable

If this was true, yes.

Unfortunately
 a) this version is in security since Sep 8, and no report since then.
 If this was a general problem this would have been reported FAR
 earlier. So I believe it's a local problem.
 b) works here on my debian buster laptop

> Running LibreOffice in an empty home produces the same crash, so it is
> not a configuration issue.

I wouldn't be so sure. You could have broken something else (like custom
apparmor profiles compared to the working (well, in non-enforcing mode)
ones. Yes, that happened.)

In any case, unreproducible and needs more info.

Regards,

Rene

P.S:
A report against uno-libs3 - if it's not a bug in said libraries
themselves which is obvious - is not exactly helpful imho, since a crash
in those can also happen if something in LO itself goes wrong, and LO
stuff and dependencies of LO stuff is not reported when doing
reportbug.

Bug#940919: python3-cxx-dev: removal of python3-cxx-dev makes files disappear from python-cxx-dev

[Andreas Beckmann]

Package: python3-cxx-dev
Version: 7.0.3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install python-cxx-dev/buster
  # (1)
  apt-get install python3-cxx-dev/bullseye
  apt-get remove python3-cxx-dev
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/include/CXX/*
  /usr/src/CXX/*

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The python3-cxx-dev package has the following relationships with python-cxx-dev:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  python-cxx-dev (<< 7.0.3-3)

>From the attached log (scroll to the bottom...):

1m3.9s ERROR: FAIL: After purging files have disappeared:
  /usr/include/CXX/Config.hxxowned by: python3-cxx-dev
  /usr/include/CXX/CxxDebug.hxx  owned by: python3-cxx-dev
  /usr/include/CXX/Exception.hxx owned by: python3-cxx-dev
  /usr/include/CXX/Extensions.hxxowned by: python3-cxx-dev
  /usr/include/CXX/IndirectPythonInterface.hxx   owned by: python3-cxx-dev
  /usr/include/CXX/Objects.hxx   owned by: python3-cxx-dev
  /usr/include/CXX/Version.hxx   owned by: python3-cxx-dev
  /usr/include/CXX/WrapPython.h  owned by: python3-cxx-dev
  /usr/lib/pkgconfig/PyCXX.pcowned by: python3-cxx-dev
  /usr/src/CXX/IndirectPythonInterface.cxx   owned by: python3-cxx-dev
  /usr/src/CXX/cxx_exceptions.cxxowned by: python3-cxx-dev
  /usr/src/CXX/cxx_extensions.cxxowned by: python3-cxx-dev
  /usr/src/CXX/cxxextensions.c   owned by: python3-cxx-dev
  /usr/src/CXX/cxxsupport.cxxowned by: python3-cxx-dev

1m3.9s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/python-cxx-dev.list not owned


cheers,

Andreas


python-cxx-dev=7.0.3-2_python3-cxx-dev=7.0.3-3.log.gz
Description: application/gzip

Bug#940918: RFS: libutempter/1.1.6-3.1 [NMU] -- privileged helper for utmp/wtmp updates (development)

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libutempter"

 * Package name: libutempter
   Version : 1.1.6-3.1
   Upstream Author : Dmitry V. Levin 
 * URL :
http://git.altlinux.org/people/ldv/packages/?p=libutempter.git
 * License : LGPL-2.1
 * Vcs :
https://anonscm.debian.org/cgit/pkg-kde/krap/libutempter.git/
   Section : libs

It builds those binary packages:

  libutempter-dev - privileged helper for utmp/wtmp updates (development)
  libutempter0 - privileged helper for utmp/wtmp updates (runtime)

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

  https://mentors.debian.net/package/libutempter

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libutempter/libutempter_1.1.6-3.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * d/salsa-ci.yml:
 - add standard salsa-ci configuration
 - disable reprotest, cause chown fails
   * d/control: bump to compat level 12
   * d/control: bump to std version 4.4.0 (no further changes)
   * d/rules: enable all hardening options
   * d/not-installed: remove unneeded ignore file for list-missing
   * d/libutempter0.symbols: explicit set Build-Depends-Package
   * d/control: explicit set Rules-Requires-Root to binary-targets
   * d/tests: add autopkg testsuite
   * d/copyright: covert to machine-readable format
   * d/patches:
 - convert to gbp style
 - add: Mark old interfaces as deprecated
 - add: Validate given hostname (Closes: #689562)

Regards,

--
  Christian Göttsche

Bug#932246: Re : Bug#932246: Re : Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Francesco Poli]

On Sat, 21 Sep 2019 19:14:07 +0100 Brian Potkin wrote:

> On Sat 21 Sep 2019 at 17:45:06 +0200, Francesco Poli wrote:
[...]
> > Unless I am misinterpreting something, this bug seems to have vanished
> > or have been fixed in printer-driver-hpcups/3.19.8+dfsg0-1
> 
> You are not using printer-driver-hpcups.

Am I not?!?

> 
> > I do not understand why other users seem to get different experiences...
> 
> Perhaps you could set up a queue with printer-driver-hpcups to gain some
> understanding.

I thought that

  # lpadmin -x lj
  # lpadmin -p lj -E \
-v 'usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9' \
-m drv:///hpijs.drv/hp-laserjet_1320-hpijs.ppd \
-o pdftops-renderer-default=pdftops \
-L local -D "HP LaserJet 1320"
  lpadmin: Printer drivers are deprecated and will stop working in a future 
version of CUPS.
  # lpoptions -p lj -o media=A4 -o sides=two-sided-long-edge
  # lpadmin -d lj

did set up a queue with printer-driver-hpcups.

At the very least, this was the queue where I originally experienced the
bug (please remember that I am the original bug report submitter!).
And the error log said that "/usr/lib/cups/filter/hpcups" had "crashed
on signal 6".
And

  $ dpkg -S /usr/lib/cups/filter/hpcups
  printer-driver-hpcups: /usr/lib/cups/filter/hpcups

This is what made me conclude that the bug was in package
printer-driver-hpcups.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpb_aMIk1HPD.pgp
Description: PGP signature

Bug#940868: ITP: darcula-theme-java -- The official Darcula Look and Feel for programming environments by Konstantin Bulenkov.

[Emmanuel Bourg]

On Sat, 21 Sep 2019 06:36:56 +0200 Felix Natter  wrote:

> * Package name: darcula-theme-java (darcula-lookandfeel-java?)

Since Darcula is a Swing Look and Feel implementation I think
'lookandfeel' would be more appropriate than 'theme'. That said, Darcula
is very well known since it's used by IntelliJ and the other Jetbrains
IDEs, so the package could be simply named 'darcula'.

Emmanuel Bourg

Bug#940917: pylint: removal of pylint makes files disappear from pylint3

[Andreas Beckmann]

Package: pylint
Version: 2.2.2-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install pylint3/buster
  # (1)
  apt-get install pylint/bullseye
  apt-get remove pylint
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  /usr/lib/python3/dist-packages/pylint*

This is a serious bug violating policy 7.6, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
and also see the footnote that describes this incorrect behavior:
https://www.debian.org/doc/debian-policy/ch-relationships.html#id13

The pylint package has the following relationships with pylint3:

  Conflicts: n/a
  Breaks:n/a
  Replaces:  pylint3

>From the attached log (scroll to the bottom...):

2m0.1s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/python3/dist-packages/pylint-2.2.2.egg-info/PKG-INFO  owned by: 
pylint
  /usr/lib/python3/dist-packages/pylint-2.2.2.egg-info/dependency_links.txt 
 owned by: pylint
  /usr/lib/python3/dist-packages/pylint-2.2.2.egg-info/entry_points.txt  owned 
by: pylint
  /usr/lib/python3/dist-packages/pylint-2.2.2.egg-info/requires.txt  owned 
by: pylint
  /usr/lib/python3/dist-packages/pylint-2.2.2.egg-info/top_level.txt owned 
by: pylint
  /usr/lib/python3/dist-packages/pylint/__init__.py  owned by: pylint
  /usr/lib/python3/dist-packages/pylint/__main__.py  owned by: pylint
  /usr/lib/python3/dist-packages/pylint/__pkginfo__.py   owned by: pylint
  /usr/lib/python3/dist-packages/pylint/checkers/__init__.py owned by: 
pylint
  /usr/lib/python3/dist-packages/pylint/checkers/async.pyowned by: 
pylint
  /usr/lib/python3/dist-packages/pylint/checkers/base.py owned by: 
pylint
...
 /usr/lib/python3/dist-packages/pylint/test/unittest_checkers_utils.py  owned 
by: pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_config.py  owned by: 
pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_lint.pyowned by: 
pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_pyreverse_diadefs.py  
 owned by: pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_pyreverse_inspector.py
 owned by: pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_pyreverse_writer.py   
 owned by: pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_reporters_json.py  owned 
by: pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_reporting.py   owned 
by: pylint
  /usr/lib/python3/dist-packages/pylint/test/unittest_utils.py   owned by: 
pylint
  /usr/lib/python3/dist-packages/pylint/testutils.py owned by: pylint
  /usr/lib/python3/dist-packages/pylint/utils.py owned by: pylint

2m0.1s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/pylint3.listnot owned


cheers,

Andreas


pylint3=2.2.2-1_pylint=2.2.2-4.log.gz
Description: application/gzip

Bug#940714: llvm-toolchain-7 7.0.1-8~deb9u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940714 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: llvm-toolchain-7
Version: 7.0.1-8~deb9u3

Explanation: disable the gold linker from s390x; bootstrap with -fno-addrsig, 
stretch's binutils doesn't work with it on mips64el

Bug#940551: Please package version 2.3 of networkx

[Sandro Tosi]

resending, given mails issue earlier today

On Sat, Sep 21, 2019 at 1:28 PM Sandro Tosi  wrote:
>
> On Sat, Sep 21, 2019 at 12:29 PM Thomas Goirand  wrote:
> >
> > On 9/18/19 7:57 PM, Sandro Tosi wrote:
> > >> Please package version >= 2.3 of networkx, which I need for the next 
> > >> version of
> > >> OpenStack (called "train"). python-vitrageclient needs it.
> > >
> > > 2.3 is py3k only, so it will take a bit longer to prepare, upload, and
> > > be available in unstable. I'll work on it soon
> >
> > Sandro,
> >
> > Please don't delay it, and upload it to experimental.
>
> Thomas, I am working on it i've already prepared
> https://salsa.debian.org/python-team/modules/networkx and will start
> on that package once i finished with numpy.
>
> >
> > I have done the work in a local Git already. It looks like all working,
> > but the generation of the docs. My branch also closed a few bugs.
> >
> > For your convenience, I've pushed it as a branch py3rm-2.3 in the
> > python-networkx repository of the DPMT, together with the 2.3 upstream
> > and pristine-tar branches.
>
> this is NOT helpful. at all.
>
> I appreciate your passion, but i would also appreciate if you dont
> push this down my throat like this.
>
> >
> > If you don't have time to have a look why the doc fails to build, can we
>
> Look, i said i will work on it soon, it'd be helpful if you give
> maintainers their time, in particular when already acknowledged and
> work has started.
>
> > upload a version with doc in PDF disabled to debian Experimental, so
> > that I can continue my OpenStack work? FYI, OpenStack train will have
> > his first RC releases next week, and I'd like to be able to release
> > something when it's out, like the other distros do.
> >
> > I really don't think it's a big deal to have something temporarily in
> > experimental. If you don't mind, this helps me a lot. So let me know if
> > you're ok that I upload networkx 2.3 there.


+



On Sat, Sep 21, 2019 at 1:28 PM Sandro Tosi  wrote:
>
> > > I have done the work in a local Git already. It looks like all working,
> > > but the generation of the docs. My branch also closed a few bugs.
> > >
> > > For your convenience, I've pushed it as a branch py3rm-2.3 in the
> > > python-networkx repository of the DPMT, together with the 2.3 upstream
> > > and pristine-tar branches.
> >
> > this is NOT helpful. at all.
> >
> > I appreciate your passion, but i would also appreciate if you dont
> > push this down my throat like this.
>
> actually, please revert all of these changes. thanks.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#940748: lintian: False positives on debug-symbol-migration-possibly-complete

[Guillem Jover]

On Sat, 2019-09-21 at 20:25:50 +0200, Chris Lamb wrote:
> > Was recently introducing an automatic debug symbol package, and got
> > this lintian warning, which seems just wrong. I think the correct way
> > to go about emitting it would be to:

> Thanks for the implementation idea. However, could you give the
> concrete details why you were seeing a false-positive here, especially
> why it was not "possibly complete" and how/wy the date of the
> distribution's release is relevant?

Whether a migration has been complete and can be removed is determined
exclusively by when the migration code got introduced, so it can only
be removed when it has already been part of a stable release. From the
tag's own description:

  ,--- [ lintian-info --tags debug-symbol-migration-possibly-complete ]
  […]
  N:   If this command was added to the debian/rules that was included in the
  N:   current stable release of Debian then it can possibly be removed.
  N:
  N:   However, if the command was added later (and/or the package was not
  N:   included in stretch) please wait until it has been included in a
  N:   stable release before removing it.
  […]
  `---

So, adding the migration code now to a package in unstable will emit
this tag, even if it should not be acted on until the package has been
part of the next release. Adding an override until then would defeat
the purpose of the tag, as then yuo'd need to recall checking them all
after the release. :)

Thanks,
Guillem

Bug#940916: libgtk-3-0: Gtk in wayland does not move windows

[Yuri Teixeira]

Package: libgtk-3-0
Version: 3.24.5-1
Severity: normal

Dear Maintainer,

I'd like to inform that function gtk_window_move() does not work when
using Wayland.

Minimal reproducible codes in C and Python are below.

When using X the windows move again. There are also some other very
minor differences that I won't describe here because I don't know if
they are really bugs and the move is more important.



/* testmove.c */

#include 

void
move_window (GtkButton *button, gpointer window)
{
    gint x, y;
    gtk_window_get_position(GTK_WINDOW(window), &x, &y);
    gtk_window_move(GTK_WINDOW(window), x+50, y+50);
}

void
main (int argc, char *argv[])
{
    gtk_init(&argc, &argv);
    GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    g_signal_connect(GTK_WINDOW(window), "destroy", 
G_CALLBACK(gtk_main_quit), NULL);

    GtkWidget* button = gtk_button_new_with_label("Click to move");
    gtk_container_add(GTK_CONTAINER(window), button);
    g_signal_connect(button, "clicked", G_CALLBACK(move_window), window);
    gtk_widget_show_all(window);
    gtk_main();
}

/* gcc `pkg-config --cflags gtk+-3.0` -o testmove testmove.c `pkg-config 
--libs gtk+-3.0` */




# testmove.py

#! /usr/bin/env python3

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

def move_window(button, window):
    x, y = window.get_position()
    window.move(x+50, y+50)

def main():
    window = Gtk.Window()
    window.connect('destroy', Gtk.main_quit)
    button = Gtk.Button(label='Click to move')
    window.add(button)
    button.connect('clicked', move_window, window)
    window.show_all()
    Gtk.main()

if __name__ == '__main__':
    main()

# python3 -m testmove



Thank you for your attention,

YT

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.30.1-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc6    2.28-10
ii  libcairo-gobject2    1.16.0-4
ii  libcairo2    1.16.0-4
ii  libcolord2   1.4.3-4
ii  libcups2 2.2.10-6+deb10u1
ii  libepoxy0    1.5.3-0.1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u1
ii  libgtk-3-common  3.24.5-1
ii  libharfbuzz0b    2.3.1-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-0    1.42.4-7~deb10u1
ii  librest-0.7-0    0.8.1-1
ii  libsoup2.4-1 2.64.2-2
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon0    0.8.2-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 1.10-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.24.5-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.38.1-5
ii  librsvg2-common  2.44.10-2.1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule    
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule    
pn  ibus-gtk3 
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
pn  libcaribou-gtk3-module    
pn  libgtk3-nocsd0    
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module    
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#940685: buster-pu: libsixel/1.8.2-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2019-09-19 at 09:46 +0900, NOKUBI Takatsugu wrote:
> I'll upload a new version of libsixel for buster.
> It contains many security fix reported by #931311
> 
> fixed package for unstable had already uploaded.
> This is just a backports but almost same.

What environment were the amd64 packages that you uploaded built in?

Compared to the packages currently in buster, they end up with several
new dependencies:

Control files of package libsixel-bin: lines which differ (wdiff
format)
-
---
Depends: libc6 (>= 2.4), [-libsixel1-] {+libjpeg62-turbo (>= 1.3.1),
libpng16-16 (>= 1.6.2-1), libsixel1, zlib1g (>= 1:1.1.4)+}

Control files of package libsixel1: lines which differ (wdiff format)
-
Depends: libc6 (>= [-2.15)-] {+2.15), libjpeg62-turbo (>= 1.3.1),
libpng16-16 (>= 1.6.2-1), zlib1g (>= 1:1.1.4)+}

The package in unstable also does not have any of those dependencies,
nor does a rebuild in a newly-created buster chroot.

Regards,

Adam

Bug#937216: openvswitch: Python2 removal in sid/bullseye

[Thomas Goirand]

On 9/19/19 4:59 PM, Ben Pfaff wrote:
> On Fri, Aug 30, 2019 at 07:29:41AM +, Matthias Klose wrote:
>> 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.
> 
> For what it's worth, we're doing a Python 3-only conversion in the
> upstream repo at the moment:
> 
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362813.html
> 
> However, the code already supported Python 3 almost everywhere before
> this, so it's probably not necessary to backport this series for Debian.

Hi Ben,

What's hard is more to get rid of python2, like shebangs, etc. If you're
doing it upstream, that's great, thanks. When do you think that will be
done, and a new stable release will be done? Can you ping me when that's
the case?

Cheers,

Thomas Goirand (zigo)

Bug#924192: Is this fix going to make it into Buster any time soon?

[Richard Laager]

On 9/21/19 7:22 AM, Rick Thomas wrote:
> I’d really like to see this fix make it into Debian Buster!
> Any chance of that?

I dropped the ball on this before the Buster release, for lack of time.
My intention is to try to get this into a point release. I'm intending
on doing that tomorrow. So hopefully it will land in the next point release.

-- 
Richard

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Michel Le Bihan]

Package: uno-libs3
Version: 6.1.5-3+deb10u4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

LibreOffice is crashing on launch with a segfault.

Fatal exception: Signal 11
Stack:
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x3d523)[0x7f491d642523]
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x3d733)[0x7f491d642733]
/lib/x86_64-linux-gnu/libc.so.6(+0x37840)[0x7f491d455840]
/usr/lib/libreoffice/program/libuno_cppu.so.3(+0x14b32)[0x7f491a873b32]
/usr/lib/libreoffice/program/libuno_cppu.so.3(uno_type_any_assign+0x97)[0x7f491a872f27]
/usr/lib/libreoffice/program/libmergedlo.so(+0x2aac888)[0x7f492010f888]
/usr/lib/libreoffice/program/libmergedlo.so(+0x2aad565)[0x7f4920110565]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN3utl10ConfigItemC2ERKN3rtl8OUStringE14ConfigItemMode+0x7b)[0x7f49201057db]
/usr/lib/libreoffice/program/libmergedlo.so(+0x2b02028)[0x7f4920165028]
/usr/lib/libreoffice/program/libmergedlo.so(_ZN19SvtSysLocaleOptionsC1Ev+0x11f)[0x7f492016651f]
/usr/lib/libreoffice/program/libmergedlo.so(_Z7InitVCLv+0x1a0)[0x7f49204ba4f0]
/usr/lib/libreoffice/program/libmergedlo.so(+0x2e58a8d)[0x7f49204bba8d]
/usr/lib/libreoffice/program/libmergedlo.so(_Z6SVMainv+0x30)[0x7f49204bbae0]
/usr/lib/libreoffice/program/libmergedlo.so(soffice_main+0x91)[0x7f491f58dde1]
/usr/lib/libreoffice/program/soffice.bin(+0x107b)[0x5577eff6e07b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f491d44209b]
/usr/lib/libreoffice/program/soffice.bin(+0x10ba)[0x5577eff6e0ba]
Aborted


Running libreoffice with symbols installed in gdb shows:

michel@service-dyn79 /$ gdb /usr/lib/libreoffice/program/soffice.bin
GNU gdb (Debian 8.2.1-2+b1) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/libreoffice/program/soffice.bin...(no debugging 
symbols found)...done.
(gdb) run
Starting program: /usr/lib/libreoffice/program/soffice.bin
[Detaching after fork from child process 3204]
[New Thread 0x7f78d2cfa700 (LWP 3205)]
[New Thread 0x7f78d1158700 (LWP 3210)]

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x7f78d70bab32 in cppu::_copyConstructAnyFromData (mapping=0x0, 
acquire=0x7f78db10c360,
pTypeDescr=, pType=, pSource=0x7ffcf8b48b50, 
pDestAny=0x5624f7df75f8)
at ./include/typelib/typedescription.h:1016
1016./include/typelib/typedescription.h: No such file or directory.
(gdb) bt
#0  0x7f78d70bab32 in cppu::_copyConstructAnyFromData(_uno_Any*, void*, 
_typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), 
_uno_Mapping*)
(mapping=0x0, acquire=0x7f78db10c360, pTypeDescr=, 
pType=, pSource=0x7ffcf8b48b50, pDestAny=0x5624f7df75f8) at 
./include/typelib/typedescription.h:1016
#1  0x7f78d70bab32 in cppu::_copyConstructAny(_uno_Any*, void*, 
_typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), 
_uno_Mapping*)
(pDestAny=pDestAny@entry=0x5624f7df75f8, 
pSource=pSource@entry=0x7ffcf8b48b50, pType=,
pType@entry=0x5624f7d4d4f0, pTypeDescr=pTypeDescr@entry=0x0, 
acquire=acquire@entry=0x7f78db10c360, mapping=mapping@entry=0x0) at 
./cppu/source/uno/copy.hxx:264
#2  0x7f78d70b9f27 in uno_type_any_assign(uno_Any*, void*, 
typelib_TypeDescriptionReference*, uno_AcquireFunc, uno_ReleaseFunc)
(pDest=0x5624f7df75f8, pSource=0x7ffcf8b48b50, pType=0x5624f7d4d4f0, 
acquire=0x7f78db10c360, release=) at ./cppu/source/uno/any.cxx:39
#3  0x7f78dc956888 in  () at /usr/lib/libreoffice/program/libmergedlo.so
#4  0x7f78dc957565 in  () at /usr/lib/libreoffice/program/libmergedlo.so
#5  0x7f78dc94c7db in utl::ConfigItem::ConfigItem(rtl::OUString const&, 
ConfigItemMode) ()
at /usr/lib/libreoffice/program/libmergedlo.so
#6  0x7f78dc9ac028 in  () at /usr/lib/libreoffice/program/libmergedlo.so
#7  0x7f78dc9ad51f in SvtSysLocaleOptions::SvtSysLocaleOptions() ()
at /usr/lib/libreoffice/program/libmergedlo.so
#8  0x7f78dcd014f0 in InitVCL() () at 
/usr/lib/libreoffice/program/libmergedlo.so
#9  0x7f78dcd02a8d in  () at /usr/lib/libreoffice/program/libmergedlo.so
#10 0x7f78dcd02ae0 in SVMain() () at 
/usr/lib/libreoffice/program/libmergedlo.so
#11 0x7f78dbdd4de1 in soffice_main () at 
/usr/lib/libreoffice/program/libmergedlo.so
#12 0x5624f679207b in  ()
#13 0x7f78d9c8909b in __libc_start_main (main=
0x5624f67

Bug#940802: linux-image-4.19.0-5-amd64: Build of xt_ACCOUNT.ko failed for: 4.19.0-5-amd64 (x86_64)

[Ben Hutchings]

Control: reassign -1 xtables-addons-dkms
Control: forcemerge 872077 -1

This is not a bug in the kernel, it's a bug in xtables-addons.  This
has been fixed but unfortunately it wasn't included in the buster
release.  You'll need to get the fixed version from unstable.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.



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

Bug#940913: freeipa: CVE-2019-14826

[Salvatore Bonaccorso]

Source: freeipa
Version: 4.8.1-2
Severity: important
Tags: security upstream
Control: found -1  4.7.2-3

Hi,

The following vulnerability was published for freeipa.

CVE-2019-14826[0]:
| A flaw was found in FreeIPA versions 4.5.0 and later. Session cookies
| were retained in the cache after logout. An attacker could abuse this
| flaw if they obtain previously valid session cookies and can use this
| to gain access to the session.


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-14826
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14826
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1746944

Regards,
Salvatore

Bug#940912: ITP: compyle -- Execute a subset of Python on HPC platforms

[Antonio Valentino]

Package: wnpp
Severity: wishlist
Owner: Antonio Valentino 

* Package name: compyle
  Version : 0.5
  Upstream Author : Prabhu Ramachandran 
* URL : https://github.com/pypr/compyle
* License : BSD
  Programming Lang: Python
  Description : Execute a subset of Python on HPC platforms

Binary package names: python3-compyle python-compyle
 ComPyle allows users to execute a restricted subset of Python (almost
 similar to C) on a variety of HPC platforms. Currently it supports
 multi-core execution using Cython, and OpenCL and CUDA for GPU devices.
 .
 Users start with code implemented in a very restricted Python syntax,
 this code is then automatically transpiled, compiled and executed to
 run on either one CPU core, or multiple CPU cores (via OpenMP_) or on
 a GPU.
 CPy offers source-to-source transpilation, making it a very convenient
 tool for writing HPC libraries.
 .
 Some simple yet powerful parallel utilities are provided which can
 allow you to solve a remarkably large number of interesting HPC
 problems.
 .
 ComPyle also features JIT transpilation if you wish making it easy to
 use.

--
Antonio Valentino



signature.asc
Description: OpenPGP digital signature

Bug#940660: elpa-elpy: add Suggests: python3-rope to refactor code

[Nicholas D Steeves]

Control: forwarded -1 https://github.com/jorgenschaefer/elpy/issues/1449

Hi Salman and David,

On Wed, Sep 18, 2019 at 01:54:17PM -0300, David Bremner wrote:
> Salman Mohammadi  writes:
> 
> > Package: elpa-elpy
> > Version: 1.31.0-1
> > Severity: normal
> >
> > Dear Nicholas,
> >
> > Adding this entry `Suggests: python3-rope` to debian/control ensures
> > that we can refactor the code without error messages like this:
> >
> > elpy-rpc--default-error-callback: Elpy error: rope not installed, cannot
> > refactor code.
> >
>

Thank you for filing this bug, much appreciated.  I've set the
forwarded URL to the preexisting upstream issue on the removal of
Rope.  If upstream changes its mind about the removal.  The current
upstream maintainer doesn't use this functionality, so it's
effectively unmaintained.  To avoid deprecating your contribution,
would you please update your MR to use Bowler if upstream switches to
it?

> Just for the record, Suggests won't cause it to be installed
> automatically for many (most?) users.

Thanks for the reminder ;-)  Salman initially proposed a Recommends,
which I NACKed, (see above paragraph and URL, esp previous
maintainer's NACK of Rope usage for rationale), and also because IIRC
Antoine (anarcat) said he didn't use it either in his initial RFP.  I
also use Elpy without rope.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#940748: lintian: False positives on debug-symbol-migration-possibly-complete

[Chris Lamb]

tags 940748 + moreinfo
thanks

Hi Guillem,

> Was recently introducing an automatic debug symbol package, and got
> this lintian warning, which seems just wrong. I think the correct way
> to go about emitting it would be to:

[..]

Thanks for the implementation idea. However, could you give the
concrete details why you were seeing a false-positive here, especially
why it was not "possibly complete" and how/wy the date of the
distribution's release is relevant?


Regards,

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

Bug#935607: lintian: classify "Starting $DESC" in init.d scripts

[Chris Lamb]

Hi Guillem,

> Checking for VERBOSE explicitly in the init scripts seems like an
> anti-pattern to me.

Indeed. However, I am unsure whether adding this tag would be very
useful given how many (apparently) true-positives it would raise:

  
https://codesearch.debian.net/search?q=%5C%24VERBOSE+path%3Adebian%2F*init&literal=0

Thoughts? Perhaps this just means we should add this as pedantic for
now?


Regards,

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

Bug#932246: Re : Bug#932246: Re : Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Brian Potkin]

On Sat 21 Sep 2019 at 17:45:06 +0200, Francesco Poli wrote:

> On Sat, 21 Sep 2019 14:07:18 +0200 Didier 'OdyX' Raboud wrote:
> 
> > Le samedi, 21 septembre 2019, 10.53:04 h CEST Francesco Poli a écrit :
> > > Should we suppose that printer-driver-hpcups reads /etc/os-release
> > > (or /etc/issue* or /etc/debian_version) and decides whether it will
> > > crash, based on this?!?
> > 
> > Well. Parts of hplip are in python; and hplip then uses:
> > 
> > import platform
> > dist = platform.dist()
> > 
> > platform.dist() will try to guess the Linux distro from /etc/lsb-release 
> > (should not exist), then /etc/*-{release,version}, hence /etc/os-release.
> 
> Ah. This looks really surprising to me...
> 
> > 
> > hplip uses its own internal list of supported distros, in
> > /usr/share/hplip/installer/distros.dat
> > … shipped from hplip-data.
> [...]
> > I'm not sure it will work, as printer-driver-hpcups doesn't depend on hplip-
> > data anyway; *sigh*.
> 
> And indeed, I do not have hplip-data installed:

This is of no consequence; you do not need it to print. 

[...]

> Well, I retested the setup with the driver that was crashing on my box.
> I am no longer able to reproduce the bug (without even having to
> downgrade base-files!).

Mine is an up-to-date unstable installation. Using the hpijs driver no
longer produces the stack smashing error. That was not the case when the
report was first filed (I tested at the time we received it). Oh, my
testing today was without hplip-data on the box.

[...]

> Unless I am misinterpreting something, this bug seems to have vanished
> or have been fixed in printer-driver-hpcups/3.19.8+dfsg0-1

You are not using printer-driver-hpcups.

> I do not understand why other users seem to get different experiences...

Perhaps you could set up a queue with printer-driver-hpcups to gain some
understanding.

Regards,

Brian.

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Mark Hindley]

On Sat, Sep 21, 2019 at 06:51:16PM +0200, Cristian Ionescu-Idbohrn wrote:
> > Would you, please, start a new bug for this unless you really think 
> > it is the same issue (apt being broken by continuing to uninstall 
> > libsystemd0 after systemd prerm fails) and I will be happy to help.
> 
> I really don't know what to think, but I do really feel this is not 
> related to the systemd installed version.  Any current systemd version 
> should be removed without affecting the state.  Am I wrong?

I have to admit I am not clear exactly what you see is the problem. Is it that
removing systemd is taking lots of other packages with it?

Looking at the list of removals I think it is libpolkit-qt-1 that is taking
everything else out becuase it has not been patched to support the new logind
virtual packages. See #925344.

But I still don't think it is the same as Simon's original bug here.

HTH.

Mark

Bug#873795: calibre: Security risk and possible backdoor when fetching news

[Nicholas D Steeves]

Control: tags = confirmed
Control: severity = important

On Thu, Aug 31, 2017 at 10:07:25AM +0200, Jens Schmidt wrote:
> Package: calibre
> Version: 3.4.0+dfsg-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I'm using cron and /usr/bin/ebook-convert to fetch RSS news daily. Some
> generated ebooks are containing typos. The mistakes are located in a so-called
> "news fetching recipe" in Zip archive /usr/share/calibre/builtin_recipes.zip. 
> I
> tried to edit the recipe code but the mistakes remain in ebooks. I wrote an 
> own
> custom recipe, I edited built-in recipe in ZIP archive - nothing helps. As a
> last try I switched off network and had success. That maked me curious, so I
> repeated the procedures with Wireshark logging network traffic. The result:
> 
> Calibre completely ignores built-in recipes and loads python scripts from a
> server in Mumbai/India: https://code.calibre-ebook.com:443/... ( using self-
> signed wildcard certificate)
> 
> It's a absolute taboo to load scripts in background from an untrusted server
> and execute them on a Linux computer without user permission and without
> informing user. This is a Debian OS not Windows. What if the scripts are
> containing malware or spyware?
> 

Assuming good faith in the upstream, this is still a privacy breach,
so I agree we ought to do something about this.  Here is everywhere
the this website is mentioned in the source code for debian/3.48.0+dfsg-1.

$ ag code.calibre-ebook.com
  setup/linux-installer.py
  644:'https://code.calibre-ebook.com/tarball-info/' + ('x86_64' if 
is64bit else 'i686'))
  666:calibre_version = 
urlopen('http://code.calibre-ebook.com/latest').read()

  setup/linux-installer.sh
  693:'https://code.calibre-ebook.com/tarball-info/' + ('x86_64' if 
is64bit else 'i686'))
  715:calibre_version = 
urlopen('http://code.calibre-ebook.com/latest').read()

  src/calibre/ebooks/metadata/sources/update.py
  95:'https://code.calibre-ebook.com/metadata-sources/hashes.json')
  112:raw = 
get_https_resource_securely('https://code.calibre-ebook.com/metadata-sources/' 
+ name)

  src/calibre/gui2/dialogs/plugin_updater.py
  28:SERVER = 'https://code.calibre-ebook.com/plugins/'

  src/calibre/gui2/store/loader.py
  29:def download_updates(ver_map={}, server='https://code.calibre-ebook.com'):

  src/calibre/gui2/update.py
  24:URL = 'https://code.calibre-ebook.com/latest'

  src/calibre/gui2/icon_theme.py
  48:BASE_URL = 'https://code.calibre-ebook.com/icon-themes/'

  src/calibre/utils/https.py
  217:
print(get_https_resource_securely('https://code.calibre-ebook.com/latest'))

  src/calibre/web/feeds/recipes/collection.py
  224:'https://code.calibre-ebook.com/recipe-compressed/'+urn,
  headers={'CALIBRE-INSTALL-UUID':prefs['installation_uuid']}))

Norbert, do you agree the best thing to do would be to

  1. Provide user confirmation dialogue (for consent)
  2. Disable access (users would need to use backports to get new
 recipes)


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#867949: ebook-viewer crashes with "Illegal instruction"

[Nicholas D Steeves]

Control: tag + unreproducible

Hi Hartmut,

On Sat, Feb 09, 2019 at 08:57:22PM -0700, Nicholas D Steeves wrote:
> On Mon, Jul 10, 2017 at 06:18:31PM +0200, Hartmut Buhrmester wrote:
> > Package: calibre
> > Version: 2.75.1+dfsg-1
> > 
> > Other relevant packages:
> > 
> > calibre-bin2.75.1+dfsg-1
> > python2.7  2.7.13-2
> > libqt5webkit5  5.7.1+dfsg-1
> > python-pyqt5.qtwebkit  5.7+dfsg-5
> > 
[snip]
> > 
> > The ebook-viewer from the package calibre crashes with an "illegal
> > instruction", while reading ebooks of type *.epub. This happens, for
> > example, with the ebooks from Project Gutenberg at
> > https://www.gutenberg.org/wiki/Main_Page .
> > 
> > The crash does not happen immediately; the application starts normally and I
> > can open an ebook of type *.epub. I can also browse through the pages. But
> > when I start reading and stay at two subsequent page for some time, then the
> > ebook-viewer may suddenly quit with an illegal instruction.
> > 
> > It seems, that the ebook-viewer regularly recalculates the current reading
> > position and safes it to a file. The next time it will reopen the file at
> > the same position. But sometimes it seems to crash at this point.
> > 
> > The ebook-viewer may also crash, when the application window is closed. This
> > crash may get unnoticed during normal usage. But in the debugger, I still
> > get the message: "Program terminated with signal SIGILL, Illegal
> > instruction."
> > 
> > I suspect, that the cause is again the recalculation of the reading
> > position, to save it to a file.
> >
> 
> Would you please confirm if this issue also affects calibre from
> stretch-backports (3.31.0+dfsg-1~bpo9+1) or alternatively from sid
> (3.39.1+dfsg-1).
> 
[snip]
> 
> I was not able to reproduce this ebook-viewer failure with 3.39.1+dfsg-1.
> 

Would you please confirm if the bug is reproducible on one of the
following:

On Stretch/Debian 9: with 3.39.1+dfsg-3~bpo9+1
On Buster/Debian 10: with either 3.39.1+dfsg-3 or 3.48.0+dfsg-1~bpo10+1
On Bullseye/Debian 11: with 3.48.0+dfsg-1

I wasn't able to reproduce it with anything newer than 3.39.1+dfsg-1.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#939446: buster-pu: package emacs/1:26.1+1-3.2

[Adam D. Barratt]

Control: tags -1 + confirmed

Hi,

Apologies for not getting back to you on this sooner - the request was
filed just before the 10.1 point release, and things have been a little
busy since.

On Tue, 2019-09-17 at 22:44 -0500, Rob Browning wrote:
> Andreas Beckmann  writes:
> 
> > You probably want to include the fixes for #929567 in case that
> > affects
> > stable, too.
> 
> I'd be happy to if the release managers are amenable -- I was just
> trying to make the minimum change in order to get the key updated
> without potentially raising other questions.

Assuming that we'd be looking at getting the update available via
stable-updates - rather than telling everyone affected to use p-u for
six weeks or so - then I would prefer to keep the changes minimal for
that upload. We can always look at getting the other change into a
later update if desired.

Please feel free to go ahead with the original diff.

Regards,

Adam

Bug#940911: TPM error with Debian Live Testing

[Richard]

Package: GRUB
Version 2.04-3


I first raised the issue on the Debian forums and it was suggested to me
that this appears to be a GRUB issue as TPM support was recently added to
GRUB in testing.

I have an ASUS G752vs laptop running Linux Mint LMDE 3 and Windows 10. I
created three Debian Live Testing USB sticks using the following weekly
live builds (all with a last modified date of 2019-09-16):

  debian-live-testing-amd64-xfce.iso
  debian-live-testing-amd64-cinnamon.iso
  debian-live-testing-amd64-gnome.iso

Unfortunately, I receive the following error messages with all three:

After pressing "Debian GNU/Linus Live (kernel 5.2.0-2-amd64)" I see:
  error: Unknown TPM error.
  error: Unknown TPM error.
  error: You need to load the kernel first

  Press any key to continue...

I'm then returned to the main screen

If I press Debian Live with Localisation Support
I see a full screen of "error: Unknown TPM error.", followed by "Press any
key to continue..."

I'm then sent to a screen to choose my language with GNU GRUB version
2.04-3 at the top.

After choosing English, I receive the first set of error messages noted
above.

To trouble shoot, I have done the following:

  1. Tested the live testing USBs in an older desktop computer without TPM
... They work fine.

  2. Created a USB with debian-live-10.1.0-amd64-cinnamon.iso ... It works
fine on my laptop.

  3. I thought maybe it was a kernel issue. So I created a live USB with
Manjaro xfce 18.1.0 (which has kernel 5.2.11). It ran without any issue on
my laptop.

  4. I disabled secured boot in the bios and that didn't resolve the issue.
The laptop also does not have the option to disable TPM in the bios as it
is running Intel's TPM 2.0 version 11.0.2 1003.  The laptop also does not
have the option to boot in BIOS/legacy mode.

So in summary, the only combination that didn't work was the Debian testing
with my laptop.

Please let me know if you require any additional information.

Richard

Bug#940910: wget: --adjust-extension adds a .z suffix to .svgz files

[Francesco Potortì]

Package: wget
Version: 1.20.3-1+b1
Severity: normal

--adjust-extension should not add a .gz suffix to .svgz files

-- 
IPIN'19 http://ipin2019.isti.cnr.itVoice:  +39.050.621.3058
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it


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

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

Versions of packages wget depends on:
ii  libc6 2.29-1
ii  libgnutls30   3.6.9-5
ii  libidn2-0 2.2.0-2
ii  libnettle63.4.1-1+b1
ii  libpcre2-8-0  10.32-5+b1
ii  libpsl5   0.20.2-2
ii  libuuid1  2.34-0.1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages wget recommends:
ii  ca-certificates  20190110

wget suggests no packages.

-- no debconf information

Bug#940551: Please package version 2.3 of networkx

[Sandro Tosi]

On Sat, Sep 21, 2019 at 12:29 PM Thomas Goirand  wrote:
>
> On 9/18/19 7:57 PM, Sandro Tosi wrote:
> >> Please package version >= 2.3 of networkx, which I need for the next 
> >> version of
> >> OpenStack (called "train"). python-vitrageclient needs it.
> >
> > 2.3 is py3k only, so it will take a bit longer to prepare, upload, and
> > be available in unstable. I'll work on it soon
>
> Sandro,
>
> Please don't delay it, and upload it to experimental.

Thomas, I am working on it i've already prepared
https://salsa.debian.org/python-team/modules/networkx and will start
on that package once i finished with numpy.

>
> I have done the work in a local Git already. It looks like all working,
> but the generation of the docs. My branch also closed a few bugs.
>
> For your convenience, I've pushed it as a branch py3rm-2.3 in the
> python-networkx repository of the DPMT, together with the 2.3 upstream
> and pristine-tar branches.

this is NOT helpful. at all.

I appreciate your passion, but i would also appreciate if you dont
push this down my throat like this.

>
> If you don't have time to have a look why the doc fails to build, can we

Look, i said i will work on it soon, it'd be helpful if you give
maintainers their time, in particular when already acknowledged and
work has started.

> upload a version with doc in PDF disabled to debian Experimental, so
> that I can continue my OpenStack work? FYI, OpenStack train will have
> his first RC releases next week, and I'd like to be able to release
> something when it's out, like the other distros do.
>
> I really don't think it's a big deal to have something temporarily in
> experimental. If you don't mind, this helps me a lot. So let me know if
> you're ok that I upload networkx 2.3 there.
>
> Cheers,
>
> Thomas Goirand (zigo)



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#940551: Please package version 2.3 of networkx

[Sandro Tosi]

> > I have done the work in a local Git already. It looks like all working,
> > but the generation of the docs. My branch also closed a few bugs.
> >
> > For your convenience, I've pushed it as a branch py3rm-2.3 in the
> > python-networkx repository of the DPMT, together with the 2.3 upstream
> > and pristine-tar branches.
>
> this is NOT helpful. at all.
>
> I appreciate your passion, but i would also appreciate if you dont
> push this down my throat like this.

actually, please revert all of these changes. thanks.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#940909: xserver-xorg-video-tdfx: missing dependencies

[Sven Joachim]

Package: xserver-xorg-video-tdfx
Version: 1:1.5.0-1
Severity: serious

In version 1:1.5.0-1 xserver-xorg-video-tdfx no longer depends on
xorg-video-abi-24 and xserver-xorg-core.  The reason is that commit
058dc36806b3 ("Bump debhelper to 12.") inadvertently dropped not only
autoreconf, but also xsf from the list of dh sequences.


-- 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.1-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)

Bug#940899: elpa-fountain-mode: please switch from texlive-generic-recommended to texlive-plain-generic

[Nicholas D Steeves]

Control: tag -1 pending
Hi Norbert!

On Sun, Sep 22, 2019 at 12:02:46AM +0900, Norbert Preining wrote:
> Package: elpa-fountain-mode
> Version: 2.7.3-1
> Severity: normal
> 
> texlive-generic-recommended is a transitional package that will go away
> in this release cycle, please switch to texlive-plain-generic.
> 

Sure thing :-) I was using a "Recommends: texlive-plain-generic |
texlive-generic-recommended" so old-stable users could install the
package, but I'll drop that now.  Fixed in git, and the fix will be in
the archive with the next new upstream release.  I expect this will
happen before November, but if not then I'll upload a new Debian
revision.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#932246: Re : Bug#932246: Re : Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Didier 'OdyX' Raboud]

Le samedi, 21 septembre 2019, 14.07:18 h CEST Didier 'OdyX' Raboud a écrit :
> (It seems this whole "detect the distro and try being smart" should be
> removed completely from Debian's hplip).

With this in mind, I've prepared an hplip version which totally skips the 
guessing parts:

 def validate_distro_version(self):
-if self.validate_disto():
-for vers in self.distros[self.distro_name]['versions']:
-if self.distro_version == vers:
-return True
-
-return False
+# It's shipped in Debian. It's supported.
+return True

 def is_auto_installer_support(self, distro_version=DISTRO_VER_UNKNOWN):
-if not self.distro_name:
-self.get_distro()
- (… etc etc …)
+# No auto install ever.
+return False

It will also forbid the hp-* tools to try to install supposedly missing 
dependencies themselves. Debian has package dependencies for a reason.

That'll be 3.19.8+dfsg0-4, uploaded later tonight. It will also ship 
autopkgtests, to also test hplip printing on fake printers.

Hopefully, that'll help for a better hplip on the long-term!

Cheers,
OdyX

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

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Paul Newall]

All,

I was the author of c2esp. It's hard for me to test it now because I no 
longer have kodak printers.


I'm wondering if other backends also use the gstoraster filter (I'd 
expect there would be others?) and do they also cause this error? Or did 
I do something unusual in c2espC that's contributing to the problem?


Paul Newall

On 21/09/2019 15:24, Brian Potkin wrote:

On Sat 21 Sep 2019 at 10:22:22 +0200, Didier 'OdyX' Raboud wrote:

[...]


Using snapshot.debian.org:

* ghostscript 9.27~dfsg-3.1 works
* ghostscript 9.28~~rc1~dfsg-1 and all the later versions segfault

So…

There's clearly a regression in ghostscript 9.28 that started segfaulting in
the c2esp filter chain. But I can't manage to reproduce it outside of the
"cups + c2esp + cups-filters (gstoraster) + ghostscript" environment.

Brian; Till: any idea?

No ideas from me really. I too get gstoraster stopping when attempting
to print /usr/share/cups/data/form_russian.pdf; but the same is true for
form_english.pdf.

OTOH, /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf and text
files complete successfully.

Regards,

Brian.

Bug#905206: Do you have some spare cycles to have a look at this (Was: profnet is marked for autoremoval from testing)

[Andreas Tille]

Hi Shayan,

On Sat, Sep 21, 2019 at 05:23:49PM +0100, Shayan Doust wrote:
> This is new territory - I have spent some time looking at this and so far I
> could only reproduce all of what was already mentioned above.

It might become time consuming.
 
> I will later go more in-depth and try using mem profiling / debugging and
> some trial and error to try figure out why this gets a segmentation fault
> because this issue is really annoying and needs rectifying.

In any case yes. While I guess the program is not used in really security
relevant context you can never know and this kind of crash is a security
issue (besides the fact that it just does not the job its supposed to do).

Thanks for working at this

  Andreas. 

-- 
http://fam-tille.de

Bug#940908: slapd: validate_initial_config slapd/domain can fail if LC_COLLATE is set to non-ASCII

[Fredrik Roubert]

Package: slapd
Version: 2.4.47+dfsg-3+deb10u1
Severity: normal
Tags: patch

Dear Maintainer,

The config script for slapd (in my installed 2.4.47+dfsg-3+deb10u1 as
well as in current slapd_2.4.48+dfsg-1 from sid) attempts to make sure
the domain name is valid in validate_initial_config() using this test:

  db_get slapd/domain
  if [ -z "$RET" ] || ! echo "$RET" | grep -q '^[a-zA-Z0-9.-]*$'; then
db_fset slapd/domain seen false
invalid=true
  fi

The problem with this is that the character class [a-zA-Z0-9.-] in grep
is influenced by the LC_COLLATE environment variable and the script just
inherits this environment variable, regardless of whether it specifies a
locale that uses ASCII collation or not.

I encountered this using LC_COLLATE=sv_SE.UTF-8 which collates w as v,
therefore failing on any domain name that contains the ASCII letter w.

Before using a character class like this to test ASCII properties,
LC_COLLATE must be explicitly set to a locale that guarantees ASCII
collation, for example "C", the root locale.

Either at the beginning of the config script:

export LC_COLLATE=C

Or before invoking grep with a character class:

LC_COLLATE=C grep -q '^[a-zA-Z0-9.-]*$'

A simple patch for a failure most puzzling for anyone who encounters it.

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

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

Versions of packages slapd depends on:
ii  adduser 3.118
ii  coreutils   8.30-3
ii  debconf [debconf-2.0]   1.5.71
ii  libc6   2.28-10
ii  libdb5.35.3.28+dfsg1-0.5
ii  libgnutls30 3.6.7-4
ii  libldap-2.4-2   2.4.47+dfsg-3+deb10u1
ii  libltdl72.4.6-9
ii  libodbc12.3.6-0.1
ii  libperl5.28 5.28.1-6
ii  libsasl2-2  2.1.27+dfsg-1
ii  libwrap07.6.q-28
ii  lsb-base10.2019051400
ii  perl [libmime-base64-perl]  5.28.1-6
ii  psmisc  23.2-1

Versions of packages slapd recommends:
ii  libsasl2-modules  2.1.27+dfsg-1

Versions of packages slapd suggests:
ii  ldap-utils2.4.47+dfsg-3+deb10u1
pn  libsasl2-modules-gssapi-mit | libsasl2-modules-gssap  

-- debconf information excluded

Bug#940700: dvisvgm: Please link with libgs (not ghostscript)

[Hilmar Preuße]

Control: tags 940700 + pending

Am 19.09.2019 um 09:41 teilte Jonas Smedegaard mit:

> Please instead build-depend on libgs-dev to properly link with libgs9.
> 
Patch is on github, tagging.

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



signature.asc
Description: OpenPGP digital signature

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Cristian Ionescu-Idbohrn]

On Sat, 21 Sep 2019, Mark Hindley wrote:
> On Sat, Sep 21, 2019 at 04:35:39PM +0200, Cristian Ionescu-Idbohrn wrote:
> > I'm interested in this, but my systems (unstable and testing) are 
> > in a slightly different state.  Let's take unstable, for example:
> 
> Thanks for this. However, I really don't see it as relating to 
> Simon's original report.
> 
> Would you, please, start a new bug for this unless you really think 
> it is the same issue (apt being broken by continuing to uninstall 
> libsystemd0 after systemd prerm fails) and I will be happy to help.

I really don't know what to think, but I do really feel this is not 
related to the systemd installed version.  Any current systemd version 
should be removed without affecting the state.  Am I wrong?


Cheers,

-- 
Cristian

Bug#940902: doesn't read the data

[Andreas Tille]

Control: tags -1 help

Dear Ana,

On Sat, Sep 21, 2019 at 05:41:27PM +0200, Ana Guerrero Lopez wrote:
> This new version of cycle, ported to python3, doesn't read the data file
> ( under .cycle) and prompts to create a new user.
> 
> Not creating a new user and downgrading to the version in buster (-14), allows
> to continue using the application with the previous data.

thanks a lot for thorough testing the package!

The situation is as follows:  Upstream is dead so we probably become
upstream in Debian.  I has done my best to port it to Python3 with the
help of Debian Python team.  I personally can not do more.  I can just
hope that someone who is using the program will try to fix it.  If you
feel able to do this it would be great.  If you know somebody who could
do it great as well.  I'd be really happy if we could keep the package
inside Debian and if someone could fix it.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#940907: gimp: Gimp crashes on loading a .png image file.

[Stefan Pietzonke]

Package: gimp
Version: 2.10.8-2+b1
Severity: important

Dear Maintainer,

Gimp crashes if I try to load a .png image file.
I use Parrot OS Linux. This is a Debian based distro.

-- crash log ---
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/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--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-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=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,hsa 
--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 9.2.1 20190827 (Debian 9.2.1-6) 

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
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: Speicherzugriffsfehler

Stack trace:
```
/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7f8319f32f98]
/usr/bin/gimp(+0xd1590)[0x55a91a759590]
/usr/bin/gimp(+0xd19b8)[0x55a91a7599b8]
/usr/bin/gimp(+0xd2029)[0x55a91a75a029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f831942b730]
/usr/bin/gimp(gimp_gegl_mask_is_empty+0x91)[0x55a91ab44411]
/usr/bin/gimp(+0x3b7810)[0x55a91aa3f810]
/usr/bin/gimp(+0x42ec18)[0x55a91aab6c18]
/usr/bin/gimp(+0x3d5b50)[0x55a91aa5db50]
/usr/bin/gimp(+0x42f2aa)[0x55a91aab72aa]
/usr/bin/gimp(gimp_drawable_set_buffer_full+0x1cb)[0x55a91aa5c9bb]
/usr/bin/gimp(gimp_drawable_set_buffer+0x11d)[0x55a91aa5cf9d]
/usr/bin/gimp(gimp_drawable_new+0x106)[0x55a91aa5d296]
/usr/bin/gimp(gimp_layer_new+0x90)[0x55a91aaba4d0]
/usr/bin/gimp(+0x3319cc)[0x55a91a9b99cc]
/usr/bin/gimp(gimp_procedure_execute+0x237)[0x55a91a9f2577]
/usr/bin/gimp(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x55a91a9eba39]
/usr/bin/gimp(gimp_plug_in_handle_message+0x216)[0x55a91a9f6626]
/usr/bin/gimp(+0x36cf91)[0x55a91a9f4f91]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7f8319610898]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7f8319610c88]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f8319610f82]
/usr/bin/gimp(gimp_plug_in_manager_call_run+0x5fc)[0x55a91aa0635c]
/usr/bin/gimp(+0x376dbe)[0x55a91a9fedbe]
/usr/bin/gimp(gimp_procedure_execute+0x237)[0x55a91a9f2577]
/usr/bin/gimp(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x55a91a9eba39]
/usr/bin/gimp(gimp_pdb_execute_procedure_by_name+0x3cd)[0x55a91a9ebefd]
/usr/bin/gimp(file_open_image+0x33d)[0x55a91aaec6fd]
/usr/bin/gimp(file_open_with_proc_and_display+0x29d)[0x55a91aaed64d]
/usr/bin/gimp(+0x113573)[0x55a91a79b573]
/usr/bin/gimp(+0x1138b7)[0x55a91a79b8b7]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f83196f6e8d]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x27555)[0x7f831970a555]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7f83197134ae]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f8319713b6f]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f83196f6e8d]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x27555)[0x7f831970a555]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7f83197134ae]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f8319713b6f]
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8de25)[0x7f831a0dfe25]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f83196f6e8d]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x276a4)[0x7f831970a6a4]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7f83197134ae]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f8319713b6f]
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8cd69)[0x7f831a0ded69]
/lib/x86_64-linux-gnu/libgtk-x1

Bug#933929: python-rtslib-fb: New upstream version available

[Thomas Goirand]

On 8/5/19 9:49 AM, Sebastien Delafond wrote:
> Source: python-rtslib-fb
> Version: 2.1.66-3
> Severity: wishlist
> Control: block 933350 by -1
> 
> 
> Hello,
> 
> 2.1.69 is available upstream, and fixes an issue[1] in
> ceph-isci-cli. We'd need it so that ceph-iscsi, scheduled to enter
> unstable soon[2], can be fully functional.
> 
> Would you consider upgrading the version in unstable ? If the idea
> sounds reasonable, but you don't have enough time, please let me know
> and I'd be happy to do it via NMU.
> 
> Cheers,

Hi,

FYI, every 6 months, I always do it at the same pace: one new upstream
release every 6 months, uploaded at the same time as the rest of
OpenStack. So if you can avoid, just don't send this type of bug,
especially before October and Mars (dates of OpenStack releases).

Cheers,

Thomas Goirand (zigo)

Bug#905206: Do you have some spare cycles to have a look at this (Was: profnet is marked for autoremoval from testing)

[Shayan Doust]

Hello Andreas,

This is new territory - I have spent some time looking at this and so 
far I could only reproduce all of what was already mentioned above.


I will later go more in-depth and try using mem profiling / debugging 
and some trial and error to try figure out why this gets a segmentation 
fault because this issue is really annoying and needs rectifying.


Kind regards,
Shayan Doust

Bug#940551: Please package version 2.3 of networkx

[Thomas Goirand]

On 9/18/19 7:57 PM, Sandro Tosi wrote:
>> Please package version >= 2.3 of networkx, which I need for the next version 
>> of
>> OpenStack (called "train"). python-vitrageclient needs it.
> 
> 2.3 is py3k only, so it will take a bit longer to prepare, upload, and
> be available in unstable. I'll work on it soon

Sandro,

Please don't delay it, and upload it to experimental.

I have done the work in a local Git already. It looks like all working,
but the generation of the docs. My branch also closed a few bugs.

For your convenience, I've pushed it as a branch py3rm-2.3 in the
python-networkx repository of the DPMT, together with the 2.3 upstream
and pristine-tar branches.

If you don't have time to have a look why the doc fails to build, can we
upload a version with doc in PDF disabled to debian Experimental, so
that I can continue my OpenStack work? FYI, OpenStack train will have
his first RC releases next week, and I'd like to be able to release
something when it's out, like the other distros do.

I really don't think it's a big deal to have something temporarily in
experimental. If you don't mind, this helps me a lot. So let me know if
you're ok that I upload networkx 2.3 there.

Cheers,

Thomas Goirand (zigo)

Bug#940904: ITP: libiterator-simple-perl -- Simple iterator and utilities

[Sean Whitton]

Package: wnpp
Owner: Sean Whitton 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libiterator-simple-perl
  Version : 0.07
  Upstream Author : Rintaro Ishizaki 
* URL : https://metacpan.org/release/Iterator-Simple
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Simple iterator and utilities

A simple and straightforward module to build iterators in perl.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940906: glm: autopkgtest regression: CMake Error at CMakeLists.txt:6 (find_package):

[Paul Gevers]

Source: glm
Version: 0.9.9.6-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of glm the autopkgtest of glm fails in testing when
that autopkgtest is run with the binary packages of glm from unstable.
It passes when run with only packages from testing. In tabular form:
   passfail
glmfrom testing0.9.9.6-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? On top of that, next
time don't upload the arch:all package as that isn't allowed to migrate
to testing anymore.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=glm

https://ci.debian.net/data/autopkgtest/testing/amd64/g/glm/3004357/log.gz
autopkgtest [13:15:55]: test glm-tests: [---
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:6 (find_package):
  By not providing "Findglm.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "glm", but
  CMake did not find one.

  Could not find a package configuration file provided by "glm" with any of
  the following names:

glmConfig.cmake
glm-config.cmake

  Add the installation prefix of "glm" to CMAKE_PREFIX_PATH or set "glm_DIR"
  to a directory containing one of the above files.  If "glm" provides a
  separate development package or SDK, be sure it has been installed.


-- Configuring incomplete, errors occurred!
See also
"/tmp/autopkgtest-lxc.dlmtbm_m/downtmp/autopkgtest_tmp/build/CMakeFiles/CMakeOutput.log".
autopkgtest [13:15:57]: test glm-tests: ---]




signature.asc
Description: OpenPGP digital signature

Bug#863118: devscripts configuration

[Nicolas Boulenguez]

> FTR, I'm not part of the devscripts team, the thoughts below are from
> that perspective, I expect the team have a different one.

> On Thu, 2019-09-19 at 17:39 +0200, Nicolas Boulenguez wrote:
> > > The devscripts config loading module got it wrong until recently, is
> --
> A patch has been waiting for 19 months.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863118#65

> One of those patches adds some terrifying code in Confvar.pm that is
> similar to the terrifying code that was in lib/Devscripts/Config.pm
> before I fixed it recently in these two commits:
> https://salsa.debian.org/debian/devscripts/commit/bd287e8f9d7f979c39010da681565fbcab2827f4
> https://salsa.debian.org/debian/devscripts/commit/595d5777a2bca6a7de5fb35a15d39e730253ab5d

When writting Confvar, I have been careful to keep the existing
behaviour. This seemed good separation of concerns.

Confvar only searches in /etc/devscripts.conf and
$HOME/.devscripts.
$HOME is escaped by single quotes when invoking the subshell.

Config introduces a new --conf[-]file option.
It takes its own responsibilities.

Confvar returns the correct value when a configuration file contains
var=bla\ bla\'bla\"bla\$bla\\bla\\nbla
(extract from test/test_confvar_*, which tests both Perl and Shell)

> > The tests submitted alongside Confvar.pm, applied to Config.pm, would
> > have detected the bug with special characters fixed by
> > https://salsa.debian.org/debian/devscripts/commit/bd287e8f9d7f979c39010da681565fbcab2827f4

> That commit was what I referred to as "hacky", but I corrected it here:

> https://salsa.debian.org/debian/devscripts/commit/595d5777a2bca6a7de5fb35a15d39e730253ab5d

I do not understand your point.

> I encourage you to update Confvar to use the style of parsing I have
> implemented in the latest Config commit, it is as safe as is possible
> without removing support for shell.

Could you give an example of unsafety not yet covered by Confvar tests?
I fail to understand what you mean by reading your commits.

> > > [..] still needs migration of many of the scripts from their own
> > > bad config loading implementations to the config loading module.
> > Nice euphemism for "almost all".
> Yeah, I expect the reason is that for many years devscripts didn't have
> any way for scripts to share code between them.

Everyone agrees that the old configuration must go away.
My point was that your sentence suggests
- that several scripts use Config. Actually, only one does.
- that migrating the 24 other scripts is an obvious need.
  Another option is to migrate the 25 scripts to Confvar.
  The work is already done and partially tested.

> > I can tell that Config.pm is not ready yet to cover the needs of all
> > scripts.
> Could you detail some of the needed differences?

Config only targets perl, not shell.
It does not anticipate the needs of
* debuild.pl (DEBUILD_*_HOOKS, DEBUILD_*_OPTS, DEBUILD_SET_ENVVAR)
* rmadison.pl (RMADISON_URL_MAP_*)

I am confident that Confvar does because I have extended its interface
while migrating and testing a script after the other.

> > The longer Confvar.pm is completely ignored, the more efforts will be
> > duplicated for Config.pm.  Maintainers, please decide in favor of
> > Confvar, Config, or a mix of both.
> 
> Unless Confvar is updated to use the fixed parsing I added to Config, I
> don't think it should be used.

Could you detail some of the needed differences?

> Even if it were updated, I think incremental improvements to Config
> would be better than wholesale replacement.

Even if Config brings valuable updates, like parsing of related
command line arguments, I think incremental improvements to Confvar
would have been, and would still be, better than wholesale
replacement.

> > Would a merge request on salsa be more useful than of a bunch of
> > patches in the bug tracker?
> 
> In my experience salsa merge requests are paid attention to more than
> existing BTS patches. BTW, it is also possible to send merge requests
> via email by attaching the output of `git format-patch` to an email:
> 
> https://docs.gitlab.com/ce/user/project/merge_requests/#create-new-merge-requests-by-email

It seemed right to answer a bug requesting help in the bug log,
but let us try a merge request instead.
https://salsa.debian.org/debian/devscripts/merge_requests/162

Bug#940700: dvisvgm: Please link with libgs (not ghostscript)

[Jonas Smedegaard]

Quoting Hilmar Preuße (2019-09-20 11:34:33)
> Am 19.09.2019 um 18:56 teilte Jonas Smedegaard mit:
> > [ sent again - Debian mail servers dislike UTF-8 mail headers from me ]
> > 
> > [ ...and added an additional note at bottom! ]
> > 
> > Quoting Hilmar Preuße (2019-09-19 11:14:03)
> 
> Hi Jonas,
> 
> >> Am 19.09.2019 um 09:41 teilte Jonas Smedegaard mit:
> >> Depends: libbrotli1 (>= 0.6.0), libc6 (>= 2.29), libfreetype6 (>=
> >> 2.3.9), libgcc1 (>= 1:3.4), libgs9 (>= 8.61.dfsg.1), libkpathsea6,
> >> libpotrace0, libssl1.1 (>= 1.1.0), libstdc++6 (>= 9), libwoff1 (>=
> >> 1.0.0), libxxhash0 (>= 0.6.5), zlib1g (>= 1:1.2.0)
> >>
> >> Is that sufficient to close this bug?
> > 
> > Yes. Thanks.
> > 
> > ...but wait: If you _only_ added then I suspect you now have a 
> > superfluous build-dependency on ghostscript.  Not exactly harmful but... 
> > messy.
> > 
> OK, I've replaced the BD on ghostscript by libgs-dev. Now I get an
> lintian error:
> 
> E: dvisvgm: possible-gpl-code-linked-with-openssl
> 
> Is that a false positive and I should override?

The _possibility_ of a licensing problem is real, and you should 
definitely inspect it closer: Ghostscript 9.x is licensed 
AGPL-3-or-newer and anything linked with it must comply with those 
terms.

>From a quick look (only skimming debian/copyright of dvisvgm) it seems 
there is no licensing problem, as it seems relevant code is licensed 
GPL-3-or-newer which in my understanding is upgradeable to 
AGPL-3-or-newer, and I guess there is no obstacles in doing such 
upgrade.

I recommend to do the following:

0) Double-check if you come to same conclusion as me above.

1) add a "Comment:" field to the initial section of debian/copyright 
mentioning that even though dvisvgm is generally licensed 
GPL-3-or-newer, due to linking with libgs9 which is licensed AGPL-3 the 
effective license is AGPL-3-or-newer.

2) override lintian, referencing that AGPL is considered fine and is 
explicilty noted in debian/copyright.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#940905: rexical: CVE-2019-5477

[Salvatore Bonaccorso]

Source: rexical
Version: 1.0.5-2
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for rexical.

CVE-2019-5477[0]:
| A command injection vulnerability in Nokogiri v1.10.3 and earlier
| allows commands to be executed in a subprocess via Ruby's
| `Kernel.open` method. Processes are vulnerable only if the
| undocumented method `Nokogiri::CSS::Tokenizer#load_file` is being
| called with unsafe user input as the filename. This vulnerability
| appears in code generated by the Rexical gem versions v1.0.6 and
| earlier. Rexical is used by Nokogiri to generate lexical scanner code
| for parsing CSS queries. The underlying vulnerability was addressed in
| Rexical v1.0.7 and Nokogiri upgraded to this version of Rexical in
| Nokogiri v1.10.4.


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-5477
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5477

Regards,
Salvatore

Bug#940903: ITP: cubature -- multi-dimensional adaptive integration (cubature) in C

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-as...@lists.debian.org, debian-de...@lists.debian.org, 
debian-scie...@lists.debian.org

* Package name: cubature
  Version : 1.0.3
  Upstream Author : Steven G. Johnson
* URL : https://github.com/stevengj/cubature
* License : GPL-2.0+
  Programming lang: C
  Description : multi-dimensional adaptive integration (cubature) in C

This is a simple C package for adaptive multidimensional integration
(cubature) of vector-valued integrands over hypercubes. Of course, it
can handle scalar integrands as the special case where f is a
one-dimensional vector: the dimensionalities of f and x are independent.
The integrand can be evaluated for an array of points at once to enable
easy parallelization. It will be built as a shared library.

The package is a new dependency of the "purify" radio astronomy package.

The Debian package will be maintained by the Debian Science team. A git
repository will be created at

https://salsa.debian.org/science-team/cubature

Best regards

Ole

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Mark Hindley]

Cristian,

On Sat, Sep 21, 2019 at 04:35:39PM +0200, Cristian Ionescu-Idbohrn wrote:
> I'm interested in this, but my systems (unstable and testing) are in a 
> slightly different state.  Let's take unstable, for example:

Thanks for this. However, I really don't see it as relating to Simon's original
report.

Would you, please, start a new bug for this unless you really think it is the
same issue (apt being broken by continuing to uninstall libsystemd0 after
systemd prerm fails) and I will be happy to help.

Thanks.

Mark

Bug#900253: nslcd: disabling ppolicy breaks authentication

[duck]

Quack,

As I can see this part of the code did not change in 0.9.10.

Any news?

\_o<

--
Marc Dequènes

Bug#940878: lintian: Matches non-supported substvars

[Chris Lamb]

tags 940878 + pending
thanks

... another one that I vaguely remember but it fell through the
cracks. Mea culpa. Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/b8fa1e054df5132f7de9be3df4cd350067cb308e

  checks/debian/version-substvars.pm | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Best wishes,

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

Bug#920900: libicu-dev: icu-config is only deprecated

[GCS]

Hi M Santala,

On Sat, Sep 21, 2019 at 4:45 PM M Santala  wrote:
> The icu-config script has been deprecated, however, it has not yet been made 
> obsolete.
 We may argue on this. It was never a common way to detect ICU. It can
be detected via pkg-config for years I believe, but very few migrated
to that.
Somewhere I understand this, as if it (icu-config) works, why should
the code changed to pkg-config. Meaning they need a reason to update.
As it's easy to migrate, I don't see why icu-config should be carried
over for years.

> Hence, it should should still be included in order not to break legacy code 
> still relying
> on it. As it has been deprecated only recently, only code under active 
> development has had
> time to adapt. Other code will be broken and it is not at all trivial to fix 
> such issues
> when the aim is to only compile a code package.
 As I remember, its deprecation was in the queue since 2014 which mean
five years now. As noted above upstream may not follow under the hood
changes in other sources until their code works with it.

> I stumbled upon the same error as the previous poster while trying to build 
> LTFS support
> using RHEL sources. I got around the issue by building libicu-dev from 
> sources and
> manually tweaking the ./configure rules by adding --enable-icu-config. 
> Nevertheless it did
> not get included in the .deb package so I ended up copying it manually from 
> the build
> directory to /usr/bin. Clearly this is not a proper way to install missing 
> utilities.
 Do you see what are you doing? You spend (more) time to remain in the
past, instead of updating LTFS and send the changes to LTFS.
Meaning keeping this problem open instead of fixing it.

> I would expect deprecated features to remain available as legacy code won't 
> know of anything
> better. It is essential to avoid breaking something that works if at all 
> possible. Only after
> a feature is genuinely obsolete should it be scheduled for removal in a few 
> years time. Maybe
> a utility like icu-config could be ultimately converted into a wrapper 
> running pkg-config
> internally?
 Again. Please tell me why do you want to live in the past? If you
mean this LTFS [1], then it seems all you have to do is some changes
in configure.ac file.
"icu-config --cppflags" should be "pkg-config --cflags",
"icu-config --ldflags" should be "pkg-config --libs icu-i18n" and
"icu-config --version" should be "pkg-config --modversion icu-i18n".
But for any source the migration from icu-config to its pkg-config
detection is such simple. I will definitely _not_ put back icu-config
just because others don't want to make this simple change in their
source.

Regards,
Laszlo/GCS
[1] https://github.com/LinearTapeFileSystem/ltfs/wiki

Bug#938874: yum-metadata-parser: Python2 removal in sid/bullseye

[Kentaro Hayashi]

Hi, 

I'm not familiar with yum-metadata-parser at all, but
I'm not willing to remove createrepo (it depends yum-metadata-parser)
So, I've tried to fix this issue by adding python3 version.

I've added debdiff patch (may be not so good in shape), but I hope 
it will help.

-- 
Regards,
diff -Nru yum-metadata-parser-1.1.4/debian/changelog yum-metadata-parser-1.1.4/debian/changelog
--- yum-metadata-parser-1.1.4/debian/changelog	2013-06-03 00:55:17.0 +0900
+++ yum-metadata-parser-1.1.4/debian/changelog	2019-09-22 00:34:31.0 +0900
@@ -1,3 +1,15 @@
+yum-metadata-parser (1.1.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/fix-python37-setup-error.patch
+- Add patch to fix setup error with Python 3.x
+  * debian/control
+- Support python3-sqlitecachec.
+  * debian/rules
+- Build python2,python3 packages.
+
+ -- Kentaro Hayashi   Sun, 22 Sep 2019 00:34:31 +0900
+
 yum-metadata-parser (1.1.4-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru yum-metadata-parser-1.1.4/debian/control yum-metadata-parser-1.1.4/debian/control
--- yum-metadata-parser-1.1.4/debian/control	2013-06-03 00:55:17.0 +0900
+++ yum-metadata-parser-1.1.4/debian/control	2019-09-22 00:34:31.0 +0900
@@ -1,10 +1,17 @@
 Source: yum-metadata-parser
 Section: python
-Priority: extra
+Priority: optional
 Maintainer: Mike Miller 
-Build-Depends: debhelper (>= 9), python3-all-dev, pkg-config, libglib2.0-dev, libsqlite3-dev, libxml2-dev
+Build-Depends: debhelper (>= 9),
+ python-all-dev (>= 2.6.6-3~),
+ python3-all-dev (>= 3.7.3-1~),
+ pkg-config,
+ libglib2.0-dev,
+ libsqlite3-dev,
+ libxml2-dev
 Standards-Version: 3.9.4
-X-Python-Version: >= 2.4
+X-Python-Version: >= 2.7k.16
+X-Python3-Version: >= 3.7
 Homepage: http://yum.baseurl.org/
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=users/mtmiller-guest/yum-metadata-parser.git
 Vcs-Git: git://anonscm.debian.org/users/mtmiller-guest/yum-metadata-parser.git
@@ -16,4 +23,13 @@
 Description: Fast metadata parser for yum
  Python module providing a fast metadata parser for yum implemented in C.
  The sqlitecachec module is used by createrepo and the yum package manager
+ to update and query local caches of RPM package repositories.
+
+Package: python3-sqlitecachec
+Architecture: any
+Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
+Provides: ${python3:Provides}
+Description: Fast metadata parser for yum
+ Python module providing a fast metadata parser for yum implemented in C.
+ The sqlitecachec module is used by createrepo and the yum package manager
  to update and query local caches of RPM package repositories.
diff -Nru yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch
--- yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch	1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/patches/fix-python37-setup-error.patch	2019-09-22 00:29:26.0 +0900
@@ -0,0 +1,21 @@
+--- a/setup.py
 b/setup.py
+@@ -2,15 +2,15 @@
+ from distutils.core import setup, Extension
+ 
+ pc = os.popen("pkg-config --cflags-only-I glib-2.0 libxml-2.0 sqlite3", "r")
+-includes = map(lambda x:x[2:], string.split(pc.readline()))
++includes = list(map(lambda x:x[2:], pc.readline().split()))
+ pc.close()
+ 
+ pc = os.popen("pkg-config --libs-only-l glib-2.0 libxml-2.0 sqlite3", "r")
+-libs = map(lambda x:x[2:], string.split(pc.readline()))
++libs = list(map(lambda x:x[2:], pc.readline().split()))
+ pc.close()
+ 
+ pc = os.popen("pkg-config --libs-only-L glib-2.0 libxml-2.0 sqlite3", "r")
+-libdirs = map(lambda x:x[2:], string.split(pc.readline()))
++libdirs = list(map(lambda x:x[2:], pc.readline().split()))
+ pc.close()
+ 
+ module = Extension('_sqlitecache',
diff -Nru yum-metadata-parser-1.1.4/debian/patches/series yum-metadata-parser-1.1.4/debian/patches/series
--- yum-metadata-parser-1.1.4/debian/patches/series	1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/patches/series	2019-09-22 00:26:56.0 +0900
@@ -0,0 +1 @@
+fix-python37-setup-error.patch
diff -Nru yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install
--- yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install	1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/python-sqlitecachec.install	2019-09-21 23:13:47.0 +0900
@@ -0,0 +1,3 @@
+usr/lib/python2.*/dist-packages/*.py
+usr/lib/python2.*/dist-packages/*.so
+
diff -Nru yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install
--- yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install	1970-01-01 09:00:00.0 +0900
+++ yum-metadata-parser-1.1.4/debian/python3-sqlitecachec.install	2019-09-21 23:14:13.0 +0900
@@ -0,0 +1,3 @@
+usr/lib/python3.*/dist-packages/*.py
+usr/lib/py

Bug#940877: lintian: Wrongly emits unreleased-changelog-distribution for unreleased suite

[Chris Lamb]

tags 940877 + pending
thanks

> but as one never knows whether salsa is black-holing stuff, and it
> makes it difficult to track this kind of thing… ]

Sorry about this. I think I saw it at the time but didn't bookmark/
save the link. Anyway, fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/cddc69a4d58918387e3773849c8bb0160a751d65

  checks/debian/changelog.pm | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


Best wishes,

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

Bug#940902: doesn't read the data

[Ana Guerrero Lopez]

Package: cycle
Version: 0.3.1-16
Severity: grave

Hi,

This new version of cycle, ported to python3, doesn't read the data file
( under .cycle) and prompts to create a new user.

Not creating a new user and downgrading to the version in buster (-14), allows
to continue using the application with the previous data.

Cheers,
Ana

Bug#932246: Re : Bug#932246: Re : Bug#932246: printer-driver-hpcups: no more printing to a HP LaserJet 1320: stack smashing detected and hpcups crashed on signal 6

[Francesco Poli]

On Sat, 21 Sep 2019 14:07:18 +0200 Didier 'OdyX' Raboud wrote:

> Le samedi, 21 septembre 2019, 10.53:04 h CEST Francesco Poli a écrit :
> > Should we suppose that printer-driver-hpcups reads /etc/os-release
> > (or /etc/issue* or /etc/debian_version) and decides whether it will
> > crash, based on this?!?
> 
> Well. Parts of hplip are in python; and hplip then uses:
> 
>   import platform
>   dist = platform.dist()
> 
> platform.dist() will try to guess the Linux distro from /etc/lsb-release 
> (should not exist), then /etc/*-{release,version}, hence /etc/os-release.

Ah. This looks really surprising to me...

> 
> hplip uses its own internal list of supported distros, in
>   /usr/share/hplip/installer/distros.dat
> … shipped from hplip-data.
[...]
> I'm not sure it will work, as printer-driver-hpcups doesn't depend on hplip-
> data anyway; *sigh*.

And indeed, I do not have hplip-data installed:

  $ apt policy hplip-data
  hplip-data:
Installed: (none)
Candidate: 3.19.8+dfsg0-1
Version table:
   3.19.8+dfsg0-3 500
  500 http://deb.debian.org/debian unstable/main i386 Packages
   3.19.8+dfsg0-1 800
  800 http://deb.debian.org/debian testing/main i386 Packages
  $ apt policy printer-driver-hpcups
  printer-driver-hpcups:
Installed: 3.19.8+dfsg0-1
Candidate: 3.19.8+dfsg0-1
Version table:
   3.19.8+dfsg0-3 500
  500 http://deb.debian.org/debian unstable/main i386 Packages
   *** 3.19.8+dfsg0-1 800
  800 http://deb.debian.org/debian testing/main i386 Packages
  100 /var/lib/dpkg/status

> 
> (It seems this whole "detect the distro and try being smart" should be 
> removed 
> completely from Debian's hplip).

Well, I retested the setup with the driver that was crashing on my box.
I am no longer able to reproduce the bug (without even having to
downgrade base-files!).


  # lpadmin -x lj
  # lpadmin -p lj -E \
  > -v 'usb://HP/LaserJet%201320%20series?serial=00CNFW522KS9' \
  > -m drv:///hpijs.drv/hp-laserjet_1320-hpijs.ppd \
  > -o pdftops-renderer-default=pdftops \
  > -L local -D "HP LaserJet 1320"
  lpadmin: Printer drivers are deprecated and will stop working in a future 
version of CUPS.
  # lpoptions -p lj -o media=A4 -o sides=two-sided-long-edge
  # lpadmin -d lj
  
  $ apt policy base-files
  base-files:
Installed: 11
Candidate: 11
Version table:
   *** 11 800
  800 http://deb.debian.org/debian testing/main i386 Packages
  500 http://deb.debian.org/debian unstable/main i386 Packages
  100 /var/lib/dpkg/status
  $ python
  Python 2.7.16+ (default, Sep  4 2019, 08:19:57) 
  [GCC 9.2.1 20190827] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> dist = platform.dist()
  >>> dist
  ('debian', 'bullseye/sid', '')
  >>> 
  $ python3
  Python 3.7.4+ (default, Sep  4 2019, 08:03:05) 
  [GCC 9.2.1 20190827] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> dist = platform.dist()
  __main__:1: DeprecationWarning: dist() and linux_distribution() functions are 
deprecated in Python 3.5
  >>> dist
  ('debian', 'bullseye/sid', '')
  >>> 

  $ echo hello | lpr
  $ lpq
  lj is ready and printing
  RankOwner   Job File(s) Total Size
  active  USER368 (stdin) 1024 bytes
  $ lpq
  lj is ready
  no entries


It works with no issues: I got a wonderful (well, sort of wonderful...)
page with the "hello" string printed on one of its sides...

Unless I am misinterpreting something, this bug seems to have vanished
or have been fixed in printer-driver-hpcups/3.19.8+dfsg0-1

I do not understand why other users seem to get different experiences...




-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgppizHpEBwk3.pgp
Description: PGP signature

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Didier 'OdyX' Raboud]

Le samedi, 21 septembre 2019, 16.24:30 h CEST Brian Potkin a écrit :
> > There's clearly a regression in ghostscript 9.28 that started segfaulting
> > in the c2esp filter chain. But I can't manage to reproduce it outside of
> > the "cups + c2esp + cups-filters (gstoraster) + ghostscript" environment.
> > 
> > Brian; Till: any idea?
> 
> No ideas from me really. I too get gstoraster stopping when attempting
> to print /usr/share/cups/data/form_russian.pdf; but the same is true for
> form_english.pdf.

Ah, sorry; I formulated my inquiry weakly. Let me try again:

Do you have a hint on how to reproduce the failing ghostscript call (or the 
gstoraster call) directly, without using CUPS in the middle?

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

Bug#940901: python2.7: CVE-2019-16056

[Salvatore Bonaccorso]

Source: python2.7
Version: 2.7.16-4
Severity: important
Tags: security upstream
Forwarded: https://bugs.python.org/issue34155
Control: found -1 2.7.16-2
Control: found -1 2.7.13-2+deb9u3
Control: found -1 2.7.13-2

Hi,

The following vulnerability was published for python2.7.

CVE-2019-16056[0]:
| An issue was discovered in Python through 2.7.16, 3.x through 3.5.7,
| 3.6.x through 3.6.9, and 3.7.x through 3.7.4. The email module wrongly
| parses email addresses that contain multiple @ characters. An
| application that uses the email module and implements some kind of
| checks on the From/To headers of a message could be tricked into
| accepting an email address that should be denied. An attack may be the
| same as in CVE-2019-11340; however, this CVE applies to Python more
| generally.


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-16056
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16056
[1] https://bugs.python.org/issue34155
[2] 
https://github.com/python/cpython/commit/4cbcd2f8c4e12b912e4d21fd892eedf7a3813d8e

Regards,
Salvatore

Bug#913804: python3-hinawa-utils: Please package hinawa-utils command-line tools separately

[Kentaro Hayashi]

Hi,

To fix this issue, I've updated hinawa-utils package to 0.1.0-2 [1]
and it was put into Debian NEW package queue.

Since package has been uploaded into new queue, 8 months has passed. 
I'm still waiting for accepting the hinawa-utils.
(As this package had uploaded before Buster release and point release event has 
happend, ftp-master team members may be too busy, I guess)

[1] https://ftp-master.debian.org/new/hinawa-utils_0.1.0-2.html

Bug#940840: systemctl --no-ask-password restart apt-daily-upgrade.timer hangs indefinetely

[Michael Biebl]

Am 21.09.19 um 08:53 schrieb Marc Haber:
> On Sat, Sep 21, 2019 at 12:06:51AM +0200, Michael Biebl wrote:
>> Ok, thanks. I have a feeling we are getting closer.
>> If you (temporarily) disable ippl (via update-rc.d ippl disable), what
>> do you get on next reboot for
>> systemctl status
>> systemctl list-jobs
> 
> [4/4986]mh@banana:~ $ sudo systemctl status
> [sudo] password for mh on banana: 
> ● banana
> State: starting
>  Jobs: 16 queued
>Failed: 0 units
> Since: Sat 2019-09-21 08:32:11 CEST; 17min ago
>CGroup: /
>├─user.slice
>│ └─user-1001.slice
>│   ├─session-7.scope
>│   │ ├─2477 sshd: mh [priv]
>│   │ ├─2542 sshd: mh@pts/0,pts/1
>│   │ ├─2543 -bash
>│   │ ├─3202 sudo dpkg --configure -a
>│   │ ├─3203 dpkg --configure -a
>│   │ ├─3204 sh -c (test -x /usr/lib/needrestart/dpkg-status && 
> /usr/lib/needrestart/dpkg-status || cat >
>│   │ ├─3205 sh -c (test -x /usr/lib/needrestart/dpkg-status && 
> /usr/lib/needrestart/dpkg-status || cat >
>│   │ ├─3206 /bin/sh /usr/lib/needrestart/dpkg-status
>│   │ ├─3347 /usr/bin/perl -w /usr/share/debconf/frontend 
> /var/lib/dpkg/info/man-db.postinst configure 2>
>│   │ ├─3353 /bin/sh /var/lib/dpkg/info/man-db.postinst configure 
> 2.8.7-1
>│   │ ├─5270 /bin/systemctl start man-db.timer
>│   │ ├─5282 -bash
>│   │ ├─5409 sudo systemctl status
>│   │ ├─5410 systemctl status
>│   │ └─5411 pager
>│   └─user@1001.service
>│ └─init.scope
>│   ├─2480 /lib/systemd/systemd --user
>│   └─2481 (sd-pam)
>├─init.scope
>│ └─1 /sbin/init
>└─system.slice
>  ├─irqbalance.service
>  │ └─277 /usr/sbin/irqbalance --foreground
>  ├─systemd-time-wait-sync.service
>  │ └─190 /lib/systemd/systemd-time-wait-sync
>  ├─dbus.service
>  │ └─292 /usr/bin/dbus-daemon --system --address=systemd: 
> --nofork --nopidfile --systemd-activation --s>
>  ├─avahi-daemon.service
>  │ ├─279 avahi-daemon: running [banana.local]
>  │ └─288 avahi-daemon: chroot helper
>  ├─system-serial\x2dgetty.slice
>  │ └─serial-getty@ttyS0.service
>  │   └─355 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 
> ttyS0 vt220
>  ├─ntp.service
>  │ └─340 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:113
>  ├─system-getty.slice
>  │ └─getty@tty1.service
>  │   └─350 /sbin/agetty -o -p -- \u --noclear tty1 linux
>  ├─smartd.service
>  │ └─282 /usr/sbin/smartd -n
>  ├─systemd-logind.service
>  │ └─287 /lib/systemd/systemd-logind
>  ├─systemd-resolved.service
>  │ └─265 /lib/systemd/systemd-resolved
>  ├─mini-buildd.service
>  │ ├─285 /usr/bin/python2 /usr/sbin/mini-buildd --verbose -W 
> :::8066
>  │ ├─529 gpg-agent --homedir /var/lib/mini-buildd/.gnupg 
> --use-standard-socket --daemon
>  │ └─538 gpg-agent --homedir 
> /var/lib/mini-buildd/var/tmp/tmp4tlVYb --use-standard-socket --daemon
>  ├─cron.service
>  │ └─3338 /usr/sbin/cron -f
>  ├─systemd-udevd.service
>  │ └─202 /lib/systemd/systemd-udevd
>  ├─rsyslog.service
>  │ └─298 /usr/sbin/rsyslogd -n -iNONE
>  ├─atop.service
>  │ └─315 /usr/bin/atop -R -w /var/log/atop/atop_20190921 600
>  ├─atd.service
>  │ └─299 /usr/sbin/atd -f
>  ├─systemd-journald.service
>  │ └─193 /lib/systemd/systemd-journald
>  ├─atopacct.service
>  │ └─291 /usr/sbin/atopacctd
>  ├─haveged.service
>  │ └─266 /usr/sbin/haveged --Foreground --verbose=1 -w 1024
>  └─systemd-networkd.service
>└─208 /lib/systemd/systemd-networkd
> [5/4987]mh@banana:~ $ sudo systemctl list-jobs
> JOB UNIT TYPE  STATE  
>  74 logrotate.timer  start waiting
>  96 anacron.service  start waiting
>  69 fstrim.timer start waiting
>  66 anacron.timerstart waiting
>  72 man-db.timer start waiting
>  24 time-sync.target start waiting
>   2 multi-user.targetstart waiting
>  67 apt-daily.timer  start waiting
>  73 e2scrub_all.timerstart waiting
>  65 timers.targetstart waiting
>  86 systemd-update-utmp-runlevel.service start waiting
>  70 apt-daily-upgrade.timer  start waiting
> 128 exim4.service  

Bug#940900: pspresent: please switch from prosper to texlive-latex-extra in your suggests

[Norbert Preining]

Package: pspresent
Version: 1.3-4+b2
Severity: normal

prosper is a transitional package that will go away
in this release cycle, please switch to texlive-latex-extra.


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

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

Versions of packages pspresent depends on:
ii  ghostscript-x  9.28~~rc3~dfsg-1
ii  libc6  2.29-1
ii  libx11-6   2:1.6.8-1
ii  libxinerama1   2:1.1.4-2

pspresent recommends no packages.

Versions of packages pspresent suggests:
pn  chaksem | prosper | foiltex  

Bug#940899: elpa-fountain-mode: please switch from texlive-generic-recommended to texlive-plain-generic

[Norbert Preining]

Package: elpa-fountain-mode
Version: 2.7.3-1
Severity: normal

texlive-generic-recommended is a transitional package that will go away
in this release cycle, please switch to texlive-plain-generic.


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

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

Bug#940898: clangd and clang-tools conflict

[Jochen Sprickerhof]

Package: clangd
Version: 1:8.0-48.3
Severity: normal

Hi,

in current unstable:

# apt install clang-tools clangd
Reading package lists... Done
Building dependency tree
Reading state information... Done
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:
 clangd : Breaks: clang-tools (< 1:9.0-48) but 1:8.0-48.3 is to be installed
E: Unable to correct problems, you have held broken packages.

The current clang-tools version in unstable is 1:8.0-48.3, so I guess
you want to downgrade the Breaks to clang-tools (< 1:8-48) (the last
version providing clangd), as was the case in 1:8.0-48.2.

Cheers Jochen


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

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

Versions of packages clangd depends on:
ii  clangd-8  1:8.0.1-3+b1

clangd recommends no packages.

clangd suggests no packages.

-- no debconf information

Bug#940896: jupyter-sphinx-theme-doc: please switch from texlive-generic-extra to texlive-plain-generic

[Norbert Preining]

Package: jupyter-sphinx-theme-doc
Version: 0.0.6+ds1-7
Severity: normal

texlive-generic-extra is a transitional package that is not build
from any source anymore, and will be removed in this cycle.
Please switch to texlive-plain-generic instead.

Thanks


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

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

jupyter-sphinx-theme-doc depends on no packages.

Versions of packages jupyter-sphinx-theme-doc recommends:
ii  latexmk   1:4.65-0.2
pn  python3-doc   
ii  python3-entrypoints   0.3-1
pn  python3-jupyter-sphinx-theme  
ii  texinfo   6.6.92.dfsg.1-1
ii  texlive-fonts-recommended 2019.20190830-1
pn  texlive-generic-extra 
ii  texlive-latex-extra   2019.20190830-1
ii  texlive-latex-recommended 2019.20190830-1

jupyter-sphinx-theme-doc suggests no packages.

Bug#940897: sdaps: please switch from texlive-generic-recommended to texlive-plain-generic

[Norbert Preining]

Package: sdaps
Version: 1.9.7-0.1
Severity: normal

texlive-generic-recommended is a transitional package that will go away
in this release cycle, please switch to texlive-plain-generic.


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

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

Versions of packages sdaps depends on:
ii  gir1.2-poppler-0.18  0.71.0-5+b1
ii  libc62.29-1
ii  libcairo21.16.0-4
ii  libglib2.0-0 2.60.6-2
ii  libtiff5 4.0.10+git190903-1
ii  python3  3.7.3-1
ii  python3-cairo1.16.2-1+b1
ii  python3-gi   3.34.0-1
ii  python3-gi-cairo 3.34.0-1
pn  python3-opencv   
pn  python3-zbar 
pn  zbar-tools   

Versions of packages sdaps recommends:
ii  gir1.2-gtk-3.0   3.24.11-1
ii  python3-pil  6.1.0-1
pn  python3-reportlab
ii  texlive  2019.20190830-1
ii  texlive-generic-recommended  2018.20190227-2
ii  texlive-latex-extra  2019.20190830-1
ii  texlive-latex-recommended2019.20190830-1
ii  texlive-science  2019.20190830-1

sdaps suggests no packages.

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Brian Potkin]

On Sat 21 Sep 2019 at 10:22:22 +0200, Didier 'OdyX' Raboud wrote:

[...]

> Using snapshot.debian.org:
> 
> * ghostscript 9.27~dfsg-3.1 works
> * ghostscript 9.28~~rc1~dfsg-1 and all the later versions segfault
> 
> So…
> 
> There's clearly a regression in ghostscript 9.28 that started segfaulting in
> the c2esp filter chain. But I can't manage to reproduce it outside of the
> "cups + c2esp + cups-filters (gstoraster) + ghostscript" environment.
> 
> Brian; Till: any idea?

No ideas from me really. I too get gstoraster stopping when attempting
to print /usr/share/cups/data/form_russian.pdf; but the same is true for
form_english.pdf.

OTOH, /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf and text
files complete successfully.

Regards,

Brian.

Bug#940862: sway: looks like 1.2 has been released

[Rob Browning]

Birger Schacht  writes:

> I'm already working on 1.2- there is another wlroots upload that we have
> to do and then 1.2 should be good to go ;)

Nice -- and thanks much.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Cristian Ionescu-Idbohrn]

On Sat, 21 Sep 2019, Mark Hindley wrote:
> 
> Removing the pending tag as I don't think there is anything for 
> elogind to do to fix this.

Hi,

I'm interested in this, but my systems (unstable and testing) are in a 
slightly different state.  Let's take unstable, for example:

,
| # apt-cache policy systemd-sysv
| systemd-sysv:
|   Installed: (none)
|   Candidate: (none)
`

,
| # apt-cache policy sysvinit-core 
| sysvinit-core:
|   Installed: 2.96~beta-1
|   Candidate: 2.96~beta-1
`

,
| # apt-cache policy systemd
| systemd:
|   Installed: 238-5
|   Candidate: 238-5
`

(that is an older version).  And that's because i have:

,
| # cat /etc/apt/preferences.d/no-systemd 
| Package: systemd systemd-sysv libsystemd0 libpam-systemd 
| Pin: release o=Debian
| Pin-Priority: -1
`

So, pid 1 is already:

,
| -rwxr-xr-x 1 root root 53176 Aug 24 16:46 /sbin/init
`

Systemd stuff was forcibly installed, but systemd is _not_ pid 1.

Attempting to install:

,
| # apt-get install libpam-elogind elogind libelogind0
`

gives me a list of:

,
| 4 upgraded, 3 newly installed, 97 to remove and 146 not upgraded.
`

Most of the packages to be removed are kde-related:

,
| The following packages will be REMOVED:
|   akonadi-server breeze drkonqi ffmpegthumbs frameworkintegration k3b
|   kactivitymanagerd kaffeine kamera kamoso kcachegrind kde-cli-tools
|   kde-config-cddb kde-config-screenlocker kde-runtime kde-style-breeze
|   kdeconnect kdelibs5-plugins kdesudo kinit kio kmahjongg kmenuedit kommander
|   kpat krusader kwin-common kwin-style-breeze libcolorcorrect5 libk3b7
|   libkf5akonadicore5abi2 libkf5akonadiwidgets5abi1 libkf5auth5 libkf5authcore5
|   libkf5bookmarks5 libkf5cddb5 libkf5configwidgets5 libkf5declarative5
|   libkf5iconthemes5 libkf5kcmutils5 libkf5kdegames7 libkf5kdelibs4support5
|   libkf5kdelibs4support5-bin libkf5kiocore5 libkf5kiofilewidgets5
|   libkf5kiogui5 libkf5kiowidgets5 libkf5kmahjongglib5 libkf5newstuff5
|   libkf5newstuffcore5 libkf5notifyconfig5 libkf5parts5 libkf5plasma5
|   libkf5plasmaquick5 libkf5purpose-bin libkf5purpose5 libkf5quickaddons5
|   libkf5runner5 libkf5sane5 libkf5style5 libkf5texteditor-bin
|   libkf5texteditor5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui5
|   libkf5xmlrpcclient5 libkscreenlocker5 libkwin4-effect-builtins1
|   libokular5core8 libpam-systemd libpolkit-backend-1-0 libpolkit-qt-1-1
|   libpolkit-qt5-1-1 libprocessui7 libsystemd0 libtaskmanager6 libweather-ion7
|   milou okular plasma-desktop plasma-framework plasma-integration
|   plasma-workspace polkit-kde-agent-1 qml-module-org-kde-draganddrop
|   qml-module-org-kde-kconfig qml-module-org-kde-kcoreaddons
|   qml-module-org-kde-kquickcontrols qml-module-org-kde-kquickcontrolsaddons
|   qml-module-org-kde-kwindowsystem qml-module-org-kde-purpose
|   qml-module-org-kde-qqc2desktopstyle rasdaemon skanlite skrooge systemd
|   udisks2
`

but not only (some *polkit* among them, I guess kde-related).  Of
course I could let them be removed and later reinstall them.  But
that's not smooth/optimal.

Still:

,
| The following additional packages will be installed:
|   gir1.2-polkit-1.0 libpolkit-agent-1-0 libpolkit-gobject-1-0 policykit-1
`

Looking deeper I notice both libelogind0 and libpam-elogind provide a 
certain version of systemd packages:

,
| Package: libelogind0
| Provides: libsystemd0 (= 241.3)
`

,
| Package: libpam-elogind
| Provides: logind (= 241.3-1+debian1)
`

but can't help wondering if that is necessary/relevant.  Shouldn't 
they provide _any_ current version of libsystemd0 and logind and 
remove _any_ earlier versions?  Isn't installing the current versions 
of systemd-related packages an unnecessary step?


Cheers,

-- 
Cristian

Bug#920900: libicu-dev: icu-config is only deprecated

[M Santala]

Package: libicu-dev
Version: 63.1-6
Followup-For: Bug #920900

Dear Maintainer,

The icu-config script has been deprecated, however, it has not yet been made 
obsolete. 
Hence, it should should still be included in order not to break legacy code 
still relying 
on it. As it has been deprecated only recently, only code under active 
development has had 
time to adapt. Other code will be broken and it is not at all trivial to fix 
such issues 
when the aim is to only compile a code package.

I stumbled upon the same error as the previous poster while trying to build 
LTFS support 
using RHEL sources. I got around the issue by building libicu-dev from sources 
and 
manually tweaking the ./configure rules by adding --enable-icu-config. 
Nevertheless it did 
not get included in the .deb package so I ended up copying it manually from the 
build 
directory to /usr/bin. Clearly this is not a proper way to install missing 
utilities.

I would expect deprecated features to remain available as legacy code won't 
know of anything 
better. It is essential to avoid breaking something that works if at all 
possible. Only after 
a feature is genuinely obsolete should it be scheduled for removal in a few 
years time. Maybe
a utility like icu-config could be ultimately converted into a wrapper running 
pkg-config 
internally?


M Santala


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

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

Versions of packages libicu-dev depends on:
ii  icu-devtools  63.1-6
ii  libc6-dev [libc-dev]  2.28-10
ii  libicu63  63.1-6

libicu-dev recommends no packages.

Versions of packages libicu-dev suggests:
ii  icu-doc  63.1-6

-- no debconf information