Bug#955603: RM: xserver-xorg-input-aiptek -- ROM; unmaintained, obsolete, or both

[Timo Aaltonen]

Package: ftp.debian.org
Severity: normal

Hi,

Debian XSF would like to remove these obsolete input and video drivers
from Debian:

xserver-xorg-input-aiptek
xserver-xorg-input-elographics
xserver-xorg-input-mtrack
xserver-xorg-input-mutouch
xserver-xorg-input-void

xserver-xorg-video-ast
xserver-xorg-video-geode
xserver-xorg-video-mach64
xserver-xorg-video-neomagic
xserver-xorg-video-r128
xserver-xorg-video-savage
xserver-xorg-video-siliconmotion
xserver-xorg-video-sisusb
xserver-xorg-video-tdfx
xserver-xorg-video-trident


They are either unmaintained upstream or provide no value to the
distribution.

Bug#955351: mesa: FTBFS on hurd-i386

[Timo Aaltonen]

On 30.3.2020 14.46, Svante Signell wrote:
> Source: mesa
> Version: 20.0.2-1
> Severity: important
> Tags: ftbfs, patch
> User: debian-h...@lists.debian.org
> Usertags: hurd
> 
> Hello,
> 
> Currently mesa FTBFS on GNU/Hurd due to a new PATH_MAX issue. Version 
> 18.3.6-2 built successfully earlier. The attached patch path_max.diff
> fixes that problem. Also, the symbols file for libglx-mesa0 is
> mismatched, and an architecture-specific file for Hurd, libglx-
> mesa0.symbols.hurd, is attached.

Thanks for these, I'll add them to the next upload. Please send the
patch upstream to gitlab.freedesktop.org.


-- 
t

Bug#953873: Patch is ok, then there is another problem

[Giovanni Mascellani]

Hi,

the patch suggested by upstream fixes the compilation, but then the
Debian-specific installation fails:

> -- Installing: 
> /<>/debian/tmp/usr/share/ompl/plannerarena/www/plannerarena.css
> -- Installing: 
> /<>/debian/tmp/usr/share/ompl/plannerarena/www/plannerarena.js
> -- Installing: 
> /<>/debian/tmp/usr/share/ompl/plannerarena/global.R
> -- Installing: 
> /<>/debian/tmp/usr/share/ompl/plannerarena/plannerarena
> -- Installing: /<>/debian/tmp/usr/share/ompl/plannerarena/ui.R
> -- Installing: 
> /<>/debian/tmp/usr/share/ompl/plannerarena/server.R
> -- Installing: /<>/debian/tmp/usr/bin/plannerarena
> -- Installing: 
> /<>/debian/tmp/usr/share/man/man1/ompl_benchmark_statistics.1
> -- Installing: /<>/debian/tmp/usr/share/man/man1/plannerarena.1
> make[2]: Leaving directory '/<>/build'
> make[1]: Leaving directory '/<>'
>dh_install -O--builddirectory=build -O--buildsystem=cmake
> Failed to copy 'usr/bin/ompl_benchmark_statistics.py': No such file or 
> directory at /usr/share/dh-exec/dh-exec-install-rename line 51, <> line 2.
> dh_install: error: debian/ompl-demos.install (executable config) returned 
> exit code 127
> make: *** [debian/rules:39: binary] Error 25
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
> exit status 2

I don't know what the problem is here.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#955591: libva: Since upgrading from 2.7.0~pre1-1 to 2.7.0-1 Chrome and vivaldi no longer work correctly

[Sebastian Ramacher]

Control: found -1 2.7.0-1

Hi Jon

On 2020-04-02 23:58:48, Jon Westgate wrote:
> Source: libva
> Severity: important
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation? 
>I upgraded
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  So if you try to run vivaldi you get a grey window with no wigets
>  that stays for around 30 seconds.
>  Chrome has window widgets but takes much longer to clear
>  vivaldi-snapshot just doesn't work period.
> 
>  Chrome actually segfaults with the following error:
> 
> [21851:21851:0402/235457.466795:ERROR:vaapi_wrapper.cc(481)] vaInitialize 
> failed: unknown libva error

Did you update mesa recently? If you run vainfo, does it try to open 
iris_drv_video.so?

> Received signal 11 SEGV_MAPERR 
> #0 0x56353631afa9 
> #1 0x563536280ee3 
> #2 0x56353631ab31 
> #3 0x7f7891275110 
> #4 0x56353735d8f7 
> #5 0x5635362cb052 
> #6 0x5635362dafd9 
> #7 0x5635362dad75 
> #8 0x56353629721a 
> #9 0x5635362db889 
> #10 0x5635362b3d04 
> #11 0x5635362ef549 
> #12 0x56353632adce 
> #13 0x7f7891269f27 start_thread
> #14 0x7f788a5482ef clone
>   r8:   r9: 0001 r10: 0001 r11: 
> 0028
>  r12: 56353abf5610 r13: 0004 r14: 7f788465f2e0 r15: 
> 0004
>   di: 7f787c002370  si: 0001  bp: 7f788465f360  bx: 
> 56353b6bc200
>   dx: 0001  ax: f8ab4a8e6276e200  cx: 0001  sp: 
> 7f788465f2b0
>   ip: 56353735d8f7 efl: 00010202 cgf: 002b0033 erf: 
> 0006
>  trp: 000e msk:  cr2: 
> [end of stack trace]
> Calling _exit(1). Core file will not be generated.
> [21915:21915:0402/235517.538631:ERROR:vaapi_wrapper.cc(481)] vaInitialize 
> failed: unknown libva error
> Received signal 11 SEGV_MAPERR 
> #0 0x560246914fa9 
> #1 0x56024687aee3 
> #2 0x560246914b31 
> #3 0x7f1ccc422110 
> #4 0x5602479578f7 
> #5 0x5602468c5052 
> #6 0x5602468d4fd9 
> #7 0x5602468d4d75 
> #8 0x56024689121a 
> #9 0x5602468d5889 
> #10 0x5602468add04 
> #11 0x5602468e9549 
> #12 0x560246924dce 
> #13 0x7f1ccc416f27 start_thread
> #14 0x7f1cc56f52ef clone
>   r8:   r9: 0001 r10: 0001 r11: 
> 0028
>  r12: 56024b1ef610 r13: 0004 r14: 7f1cbf80c2e0 r15: 
> 0004
>   di: 7f1cb8002370  si: 0001  bp: 7f1cbf80c360  bx: 
> 56024c538200
>   dx: 0001  ax: 1d5ffa0f6fb48300  cx: 0001  sp: 
> 7f1cbf80c2b0
>   ip: 5602479578f7 efl: 00010202 cgf: 002b0033 erf: 
> 0006
>  trp: 000e msk:  cr2: 
> [end of stack trace]
> Calling _exit(1). Core file will not be generated.
> [21923:21923:0402/235537.614786:ERROR:vaapi_wrapper.cc(481)] vaInitialize 
> failed: unknown libva error
> Received signal 11 SEGV_MAPERR 
> #0 0x55f4b8d59fa9 
> #1 0x55f4b8cbfee3 
> #2 0x55f4b8d59b31 
> #3 0x7fb374ece110 
> #4 0x55f4b9d9c8f7 
> #5 0x55f4b8d0a052 
> #6 0x55f4b8d19fd9 
> #7 0x55f4b8d19d75 
> #8 0x55f4b8cd621a 
> #9 0x55f4b8d1a889 
> #10 0x55f4b8cf2d04 
> #11 0x55f4b8d2e549 
> #12 0x55f4b8d69dce 
> #13 0x7fb374ec2f27 start_thread
> #14 0x7fb36e1a12ef clone
>   r8:   r9: 0001 r10: 0001 r11: 
> 0028
>  r12: 55f4bd634610 r13: 0004 r14: 7fb3682b82e0 r15: 
> 0004
>   di: 7fb360002370  si: 0001  bp: 7fb3682b8360  bx: 
> 55f4be655200
>   dx: 0001  ax: cbdf8b89d41bd600  cx: 0001  sp: 
> 7fb3682b82b0
>   ip: 55f4b9d9c8f7 efl: 00010202 cgf: 002b0033 erf: 
> 0006
>  trp: 000e msk:  cr2: 
> [end of stack trace]
> Calling _exit(1). Core file will not be generated.
> [21930:21930:0402/235557.692666:ERROR:vaapi_wrapper.cc(481)] vaInitialize 
> failed: unknown libva error
> [21930:21930:0402/235557.695528:ERROR:gpu_channel_manager.cc(459)] 
> ContextResult::kFatalFailure: Failed to create shared context for 
> virtualization.
> [21867:1:0402/235557.842980:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
>  FontService unique font name matching request did not receive a response.
> [21867:1:0402/235557.844046:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
>  FontService unique font name matching request did not receive a response.
> 
> 
> 
>I looked for the old version but couldn't remember the same of the
>snapshot website where you can find older sersions of debian
>packages.

That's https://snapshot.debian.org/

Cheers

> 
>I'm submitting this error because this affects multiple packages
> 
>   
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architectur

Bug#955555: gitlab: uninitialized constant APIGuard

[Pirate Praveen]

On 03/04/20 12:00 pm, Dragos Jarca wrote:
> 
> On 03.04.2020 08:57, Pirate Praveen wrote:
>>
>> On 2020, ഏപ്രിൽ 3 10:58:47 AM IST, Dragos Jarca
>>  wrote:
>>> Hi
>>>
>>> I told you that in amd64
>>>
>>> The problem is that I cannot upgrade to experimental(12.8.8-3) because
>>> there are missing ruby packages on amd64
>>>
>>> You solved https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955202 but
>>>
>>> not https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955197.
>> It happened because ftp masters missed
>> https://ftp-master.debian.org/new/ruby-enumerable-statistics_2.0.1-1.html
>>
>> Both were in NEW at same time. In wiki I mentioned you can get this
>> from https://people.debian.org/~praveen/new
> 
> Ok, already installed from there before you reply. My mistake.
> 
> But now:
> 
> Setting up gitaly (1.86.0+dfsg1-1) ...
> Resolving dependencies
> grpc-1.26.0-x86_64-linux requires ruby version < 2.7.dev, >= 2.3, which
> is incompatible with the current version, ruby 2.7.0p0

It looks like you are not using grpc debian package.

If you look in
/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/specifications/grpc-1.26.0.gemspec

  s.required_ruby_version = Gem::Requirement.new(">= 2.3.0".freeze)

Run "gem which grpc" which should be

/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/grpc-1.26.0/src/ruby/lib/grpc.rb

If you get a path in /var/lib/gems/2.7.0/ then it means you are using
the gem from rubyems.org



signature.asc
Description: OpenPGP digital signature

Bug#885677: liblablgtksourceview2-ocaml: Depends on unmaintained gtksourceview2

[Ralf Treinen]

Hello,

On Fri, Apr 03, 2020 at 07:22:41AM +0200, Stéphane Glondu wrote:
> Le 02/04/2020 à 22:23, Thomas Leonard a écrit :
> > My package (https://tracker.debian.org/pkg/zeroinstall-injector)
> > depends on lablgtk2 and the tracker says it will be removed on 4th Apr
> > due to this issue.

that is, removed from testing.

> > I can't upgrade to lablgtk3 because Debian/unstable only has an old
> > beta release of that (3.0~beta6-2), which is missing some functions.
> 
> There is 3.1.0 in experimental. Does it suit your needs?
> 
> Ralf, what are your plans concerning lablgtk3?

The only blocker for an upload of 3.1 is that the current version
of why3 was not compiling with lablgtk3.1. Now, there is a new
version of why3, which does, but there are a few issues with it
that I wanted to resolve before uploading the new why3 and lablgtk 3.1
to sid. Some more urgent issues with other packages took the
priority in the meantime. Now it is a bit late, as April 4 is tomorrow.

Would it really be a big problem when zeroinstall-injector temporarilly
drops out of testing? 

> Just wait. Either lablgtk2 leaves testing and I will fix it quickly and
> it (and its reverse dependencies such as your package) will migrate back
> to testing. Or lablgtk3 will be updated.

I hope to be able to work on the why3/lablgtk3 issue next week.

-Ralf.

Bug#955301: sympa: archived broken after upgrade to debian 9 - Command /usr/bin/mhonarc failed with exit code 255

[Christophe Moille]

Le lundi 30 mars 2020 à 13:19:14 (+0200), Christophe Moille a écrit :
> 
> Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
> /usr/bin/mhonarc line 39.  

Got some new result tests:

root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
sympa@zat:/home/whilelm$ /usr/bin/mhonarc
Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
/usr/bin/mhonarc line 39.
sympa@zat:/home/whilelm$ cd
sympa@zat:~$ /usr/bin/mhonarc
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
Compilation failed in require at /usr/bin/mhonarc line 39.
sympa@zat:~$ 

If I comment l36 of 
#unshift(@INC, 'lib');  # Should I leave this line in?

I have no more permission denied error

root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
sympa@zat:/home/whilelm$ /usr/bin/mhonarc
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
Compilation failed in require at /usr/bin/mhonarc line 39.
sympa@zat:/home/whilelm$ 

 
Regards

-- 
"Les libertés ne se donnent pas, elles se prennent."
- Kropotkine

Bug#955591: Acknowledgement (libva: Since upgrading from 2.7.0~pre1-1 to 2.7.0-1 Chrome and vivaldi no longer work correctly)

[Jon Westgate]

Ok,
After a reboot everything works :) I withdraw my bug report.
Oh no Linux is turning into windows :P

Jon

On 03/04/2020 00:33, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 955591: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955591.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Multimedia Maintainers 

If you wish to submit further information on this problem, please
send it to 955...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#955603: Geode is still used at Debian; do NOT remove

[Martin-Éric Racine]

Geode is NOT obsolete. The base kernel for i386 in fact is configured
for Geode (686 non-PAE).

Martin-Éric

Bug#905613: jansson dependency needs to be added explcitly

[Guido Günther]

Version: libvirt/6.0.0-1

Hi,
marking as fixed too.
 -- Guido

On Tue, Aug 07, 2018 at 08:13:51AM +0200, Christian Ehrhardt wrote:
> Package: libvirt
> Version: 4.6.0-1
> Severity: normal
> 
> Debian has taken:
>   * [d53b4b1] Use jansson instead of yajl.  The later is no longer supported
> upstream
> Which is following upsteram fine.
> 
> But Upstream: ce3c6ef6 util: avoid symbol clash between json libraries
>   Had:
>   --- a/libvirt.spec.in
>   +++ b/libvirt.spec.in
> @@ -898,6 +898,8 @@ Requires: ncurses
>  Requires: gettext
>  # Needed by virt-pki-validate script.
>  Requires: gnutls-utils
> +# We dlopen(libjansson.so.4), so need an explicit dep
> +Requires: jansson
>  %if %{with_bash_completion}
>  Requires: %{name}-bash-completion = %{version}-%{release}
>  %endif
> 
> This is special since this is intentionally "black dlopen magic" to avoid
> the issues around the symbol collision that was discussed on -rc2.
> 
> Build log [1] and a debian-sid container show it as missing.
> So you could end up with a dlopen to a nonexisting file.
> This will not be found by shlibs and co.
> 
> I tested on sid if there is a hidden
> 
> Fix looks like a normal dependency add.
> I'm slightly unsure where exactly, but the old libyajl2 dependencies were
> on libvirt0, libvirt-daemon and libnss-libvirt which is I think the set we
> should go for.
> 
> [1]:
> https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=amd64&ver=4.6.0-1&stamp=1533592540&raw=0
> 
> -- 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

Bug#955604: gulkan: unsatisfiable Build-Depends on s390x

[Sebastian Ramacher]

Source: gulkan
Version: 0.14.0-1
Severity: serious
Tags: sid bullseye
Justification: fails to build from source (but built successfully in the past)

gulkan previously built on s390x. Since it now build depends on
glslang-tools, it can no longer be built there.

Please build without glslang-tools on s390x (if possible) or make sure
to get gulkan's binaries on s390x removed. The latter will also need
carefull checking with gulkan's reverse dependencies.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#955605: debconf should support custom order for multiselect (or new entry type)

[Julian Andres Klode]

Package: debconf
Version: 1.5.73
Severity: wishlist

While working on adding support for installing grub to multiple ESPs in 
Ubuntu[1],
I noticed that while debconf's multiselect type stores an ordered list, the
selection screen does not provide the user the option to chose a custom order.

Now, in the use case of installing to multiple ESPs, this would be incredibly
useful, as it allows you to specify the order of the ESPs that will be set
in the bootorder (so that you can declare the order it falls back to different
ESPs should some be broken).

I'm sure there are other examples.

Note that we don't really need a new debconf type, as the storage already
is ordered, but like a flag to the frontend that gives the user the option
to re-order entries would be enough (and not break frontends).


[1] https://code.launchpad.net/~juliank/grub/+git/ubuntu/+merge/381462

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

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

Versions of packages debconf depends on:
ii  perl-base  5.30.0-9build1

Versions of packages debconf recommends:
ii  apt-utils 2.0.1+0~202003270844~ubuntu20.04.1
ii  debconf-i18n  1.5.73

Versions of packages debconf suggests:
pn  debconf-doc
pn  debconf-kde-helper 
ii  debconf-utils  1.5.73
ii  dialog 1.3-20190808-1
ii  libgtk3-perl   0.037-1
pn  libnet-ldap-perl   
pn  libterm-readline-gnu-perl  
ii  perl   5.30.0-9build1
ii  whiptail   0.52.21-4ubuntu2

-- debconf information excluded

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

Bug#955490: libvirt-daemon: ERROR internal error: child reported (status=125): Kernel does not provide mount namespace: Permission denied

[Guido Günther]

Hi,
On Wed, Apr 01, 2020 at 04:39:34PM +0200, usuario wrote:
> Package: libvirt-daemon
> Version: 6.0.0-4
> Severity: grave
> Tags: a11y
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> sudo virt-install \
> -n vm1 \
> -r 512 \
> --vcpus=2 \
> --os-variant=debiantesting \
> --disk /var/lib/libvirt/images/vm1.img,size=2 \
> --nographics \
> -l http://ftp.debian.org/debian/dists/testing/main/installer-amd64/ \
> -x console=ttyS0,115200
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Launch above command
> 
>* What was the outcome of this action?
> 
> Below error:
> 
> ERRORinternal error: child reported (status=125): Kernel does not
> provide mount namespace: Permission denied

This indicates a problem with the mount namespace not being
available/accessible. Please check the kernel log and libvirt logs for
details. It also helps to run virt-install in debug mode.
 -- Guido

> 
>* What outcome did you expect instead?
> 
> A success message confirming I'm able to install the Virtual Machine
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libvirt-daemon depends on:
> ii  libblkid1   2.34-0.1
> ii  libc6   2.30-2
> ii  libcap-ng0  0.7.9-2.1+b2
> ii  libdbus-1-3 1.12.16-2
> ii  libdevmapper1.02.1  2:1.02.167-1+b1
> ii  libfuse22.9.9-3
> ii  libgcc-s1   10-20200324-1
> ii  libglib2.0-02.64.1-1
> ii  libnetcf1   1:0.2.8-1+b3
> ii  libparted2  3.3-4
> ii  libpcap0.8  1.9.1-2
> ii  libpciaccess0   0.14-1
> ii  libselinux1 3.0-1+b1
> ii  libudev1244.3-1
> ii  libvirt-daemon-driver-qemu  6.0.0-4
> ii  libvirt06.0.0-4
> ii  libxml2 2.9.10+dfsg-4
> 
> Versions of packages libvirt-daemon recommends:
> ii  libvirt-daemon-driver-lxc   6.0.0-4
> ii  libvirt-daemon-driver-vbox  6.0.0-4
> ii  libvirt-daemon-driver-xen   6.0.0-4
> ii  libxml2-utils   2.9.10+dfsg-4
> ii  netcat-openbsd  1.206-1
> ii  qemu-kvm1:4.2-3
> 
> Versions of packages libvirt-daemon suggests:
> pn  libvirt-daemon-driver-storage-gluster  
> pn  libvirt-daemon-driver-storage-rbd  
> pn  libvirt-daemon-driver-storage-zfs  
> ii  libvirt-daemon-system  6.0.0-4
> pn  numad  
> 
> -- debconf-show failed

Bug#947984: libvirt-daemon-driver-lxc: internal error: Unable to find 'devices' cgroups controller mount in cgroup2 / unified hierarchy

[Guido Günther]

Version: libvirt/6.0.0-1

Hi Ryutaroh,

On Sat, Jan 04, 2020 at 07:40:27AM +0900, Ryutaroh Matsumoto wrote:
> Control: tags -1 + fixed-upstream upstream
> 
> I verified that libvirt 5.10 fixes this problem as
> 
> [root@localhost ~]# lxc-create -n fedora31test -t download -- -d
> fedora -r 31 -a amd64
> 
> [root@localhost ~]# virt-install --memory 2048  --connect lxc:/
> --os-variant fedora31 --filesystem /var/lib/lxc/fedora31test/rootfs,/
> --network none   --transient --import --name fedora31test
> 
> worked just fine.

Thanks, marking as fixed since 6.0.0-1 then!
 -- Guido

Bug#955301: sympa: archived broken after upgrade to debian 9 - Command /usr/bin/mhonarc failed with exit code 255

[Stefan Hornburg (Racke)]

On 4/3/20 9:57 AM, Christophe Moille wrote:
> Le lundi 30 mars 2020 à 13:19:14 (+0200), Christophe Moille a écrit :
>>
>> Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
>> /usr/bin/mhonarc line 39.  
> 
> Got some new result tests:
> 
> root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
> sympa@zat:/home/whilelm$ /usr/bin/mhonarc
> Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
> /usr/bin/mhonarc line 39.
> sympa@zat:/home/whilelm$ cd
> sympa@zat:~$ /usr/bin/mhonarc
> Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
> at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
> Compilation failed in require at /usr/bin/mhonarc line 39.
> sympa@zat:~$ 
> 
> If I comment l36 of 
> #unshift(@INC, 'lib');  # Should I leave this line in?
> 
> I have no more permission denied error
> 
> root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
> sympa@zat:/home/whilelm$ /usr/bin/mhonarc
> Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
> at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
> Compilation failed in require at /usr/bin/mhonarc line 39.
> sympa@zat:/home/whilelm$ 
> 
>  
> Regards
> 

Hello Christophe,

/usr/sbin/mhonarc should use the scripts located in /usr/share/mhonarc, so it 
looks like
your local (Perl) setup causes the problems.

Regards
 Racke

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



signature.asc
Description: OpenPGP digital signature

Bug#955604: gulkan: unsatisfiable Build-Depends on s390x

[Sebastian Ramacher]

On 2020-04-03 10:31:49, Sebastian Ramacher wrote:
> Source: gulkan
> Version: 0.14.0-1
> Severity: serious
> Tags: sid bullseye
> Justification: fails to build from source (but built successfully in the past)
> 
> gulkan previously built on s390x. Since it now build depends on
> glslang-tools, it can no longer be built there.
> 
> Please build without glslang-tools on s390x (if possible) or make sure
> to get gulkan's binaries on s390x removed. The latter will also need
> carefull checking with gulkan's reverse dependencies.

This upload also started a transition which requires sourceful uploads
of all reverse dependencies. Some of these reverse dependencies have to
go through NEW. Please stage transitions in experimental so that all
involved packages can clear NEW before starting the actual transition.

See also https://wiki.debian.org/Teams/ReleaseTeam/Transitions for more
info on transitions.

Cheers
-- 
Sebastian Ramacher

Bug#955606: gxr: FTBFS with gulkan 0.14

[Sebastian Ramacher]

Source: gxr
Version: 0.13.2-2
Severity: serious
Tags: ftbfs sid buster
Justification: fails to build from source (but built successfully in the past)

The gulkan transition started, but gxr fails to build against the new
gulkan version:
| Run-time dependency gulkan-0.13 found: NO (tried pkgconfig)
|
| ../meson.build:64:0: ERROR: Dependency "gulkan-0.13" not found, tried 
pkgconfig
|
| A full log can be found at 
/<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt

Cheers
-- 
Sebastian Ramacher

Bug#955555: gitlab: uninitialized constant APIGuard

[Dragos Jarca]

On 03.04.2020 10:51, Pirate Praveen wrote:

It looks like you are not using grpc debian package.
If you look in
/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/specifications/grpc-1.26.0.gemspec

   s.required_ruby_version = Gem::Requirement.new(">= 2.3.0".freeze)

grep -a required_ruby_version 
/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/specifications/grpc-1.26.0.gemspec

  s.required_ruby_version = Gem::Requirement.new(">= 2.3.0".freeze)

Run "gem which grpc" which should be

/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/grpc-1.26.0/src/ruby/lib/grpc.rb

If you get a path in /var/lib/gems/2.7.0/ then it means you are using
the gem from rubyems.org

gem which grpc

/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/grpc-1.26.0/src/ruby/lib/grpc.rb

root@a:~# dpkg -l ruby-grpc
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  ruby-grpc  1.26.0-2 amd64    GRPC system in Ruby
root@a:~# apt-get install --reinstall ruby-grpc
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not 
upgraded.

2 not fully installed or removed.
Need to get 0 B/1096 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 358794 files and directories currently installed.)
Preparing to unpack .../ruby-grpc_1.26.0-2_amd64.deb ...
Unpacking ruby-grpc (1.26.0-2) over (1.26.0-2) ...
Setting up ruby-grpc (1.26.0-2) ...
Setting up gitlab (12.8.8-4) ...
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
grpc-1.26.0-x86_64-linux requires ruby version < 2.7.dev, >= 2.3, which 
is incompatible with the current version, ruby 2.7.0p0

dpkg: error processing package gitlab (--configure):
 installed gitlab package post-installation script subprocess returned 
error exit status 1

Setting up gitaly (1.86.0+dfsg1-1) ...
Resolving dependencies...
grpc-1.26.0-x86_64-linux requires ruby version < 2.7.dev, >= 2.3, which 
is incompatible with the current version, ruby 2.7.0p0

dpkg: error processing package gitaly (--configure):
 installed gitaly package post-installation script subprocess returned 
error exit status 5

Errors were encountered while processing:
 gitlab
 gitaly
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#955495: ITP: orthanc-python -- Develop plugins for Orthanc using the Python programming language

[Andreas Tille]

Hi Sébastien,

I'm extremely short in time but I stumbled upon this:

On Fri, Apr 03, 2020 at 08:39:12AM +0200, Sébastien Jodogne wrote:
> That being said, I have changed the dependency from Python 3 to Python 2 in
> "d/control",

Whatever you do:  Avoid python and always use python3.

Please excuse my brewity

  Andreas.

-- 
http://fam-tille.de

Bug#955607: xrdesktop: FTBFS against gulkan 0.14

[Sebastian Ramacher]

Source: xrdesktop
Version: 0.13.2-1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source

The gulkan transition started, but xrdesktop fails to build against the
new gulkan version:
| Run-time dependency gxr-0.13 found: NO 
|
| ../meson.build:54:0: ERROR: Could not generate cargs for gxr-0.13:
| Package gulkan-0.13 was not found in the pkg-config search path.
| Perhaps you should add the directory containing `gulkan-0.13.pc'
| to the PKG_CONFIG_PATH environment variable
| Package 'gulkan-0.13', required by 'gxr-0.13', not found

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#955301: sympa: archived broken after upgrade to debian 9 - Command /usr/bin/mhonarc failed with exit code 255

[Christophe Moille]

Le vendredi 03 avril 2020 à 10:50:11 (+0200), Stefan Hornburg (Racke) a écrit :
> On 4/3/20 9:57 AM, Christophe Moille wrote:
> > Le lundi 30 mars 2020 à 13:19:14 (+0200), Christophe Moille a écrit :
> >>
> >> Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
> >> /usr/bin/mhonarc line 39.  
> > 
> > Got some new result tests:
> > 
> > root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
> > sympa@zat:/home/whilelm$ /usr/bin/mhonarc
> > Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
> > /usr/bin/mhonarc line 39.
> > sympa@zat:/home/whilelm$ cd
> > sympa@zat:~$ /usr/bin/mhonarc
> > Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
> > at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
> > Compilation failed in require at /usr/bin/mhonarc line 39.
> > sympa@zat:~$ 
> > 
> > If I comment l36 of 
> > #unshift(@INC, 'lib');  # Should I leave this line in?
> > 
> > I have no more permission denied error
> > 
> > root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
> > sympa@zat:/home/whilelm$ /usr/bin/mhonarc
> > Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
> > at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
> > Compilation failed in require at /usr/bin/mhonarc line 39.
> > sympa@zat:/home/whilelm$ 
> > 
> >  
> > Regards
> > 
> 
> Hello Christophe,
> 
> /usr/sbin/mhonarc should use the scripts located in /usr/share/mhonarc, so it 
> looks like
> your local (Perl) setup causes the problems.
> 
> Regards

I used `/usr/lib/sympa/bin/sympa_wizard.pl --check` on my instance when
it was debian 8, and I have executed again when debian 9.

Maybe that's a contribution to the problem. Is there knowed problems
with this script on debian 9 ?

Regards


-- 
« Gilets jaunes » : « Les élites parlent de fin du monde, quand nous, 
on parle de fin du mois »

Bug#955608: kwin-effect-xrdesktop: FTBFS with gulkan 0.14

[Sebastian Ramacher]

Source: kwin-effect-xrdesktop
Version: 0.13.2-2
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source

The gulkan transition was started, but kwin-effect-xrdesktop fails to
build agains the new version:
| Run-time dependency gxr-0.13 found: NO 
|
| ../meson.build:54:0: ERROR: Could not generate cargs for gxr-0.13:
| Package gulkan-0.13 was not found in the pkg-config search path.
| Perhaps you should add the directory containing `gulkan-0.13.pc'
| to the PKG_CONFIG_PATH environment variable
| Package 'gulkan-0.13', required by 'gxr-0.13', not found

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#955609: ITP: golang-github-valyala-tcplisten -- Customizable TCP net.Listener for Go

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-valyala-tcplisten
  Version : 0.0~git20161114.ceec8f9-1
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/tcplisten
* License : Expat
  Programming Lang: Go
  Description : Customizable TCP net.Listener for Go

 Package tcplisten provides customizable TCP net.Listener with
 various performance-related options.
 .
 This package is needed for valyala/fasthttp

--
Aloïs Micard 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#955610: ITP: libr4d -- Remote For Device-under-test (testlab manager lib)

[Bastian Germann]

Package: wnpp
Severity: wishlist
Owner: Bastian Germann 

* Package name: libr4d
  Version : 1.3
  Upstream Author : Benedikt Spranger 
* URL : https://github.com/ci-rt/libr4d
* License : GPL-2
  Programming Lang: C
  Description : libr4d is a testlab manager lib that controls r4d

The libr4d/r4d software combination is supposed to be run in testing lab
environments to control devices that are targets of automatic test runs.
They can power cycle the devices and grab a serial port.

Bug#955301: sympa: archived broken after upgrade to debian 9 - Command /usr/bin/mhonarc failed with exit code 255

[Stefan Hornburg (Racke)]

On 4/3/20 11:22 AM, Christophe Moille wrote:
> Le vendredi 03 avril 2020 à 10:50:11 (+0200), Stefan Hornburg (Racke) a écrit 
> :
>> On 4/3/20 9:57 AM, Christophe Moille wrote:
>>> Le lundi 30 mars 2020 à 13:19:14 (+0200), Christophe Moille a écrit :

 Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
 /usr/bin/mhonarc line 39.  
>>>
>>> Got some new result tests:
>>>
>>> root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
>>> sympa@zat:/home/whilelm$ /usr/bin/mhonarc
>>> Can't locate mhamain.pl:   lib/mhamain.pl: Permission non accordée at
>>> /usr/bin/mhonarc line 39.
>>> sympa@zat:/home/whilelm$ cd
>>> sympa@zat:~$ /usr/bin/mhonarc
>>> Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
>>> at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
>>> Compilation failed in require at /usr/bin/mhonarc line 39.
>>> sympa@zat:~$ 
>>>
>>> If I comment l36 of 
>>> #unshift(@INC, 'lib');  # Should I leave this line in?
>>>
>>> I have no more permission denied error
>>>
>>> root@zat:/home/whilelm# sudo su  sympa -s/bin/bash
>>> sympa@zat:/home/whilelm$ /usr/bin/mhonarc
>>> Can't use 'defined(%hash)' (Maybe you should just omit the defined()?)
>>> at /usr/local/share/perl/5.24.1/mhamain.pl line 1565.
>>> Compilation failed in require at /usr/bin/mhonarc line 39.
>>> sympa@zat:/home/whilelm$ 
>>>
>>>  
>>> Regards
>>>
>>
>> Hello Christophe,
>>
>> /usr/sbin/mhonarc should use the scripts located in /usr/share/mhonarc, so 
>> it looks like
>> your local (Perl) setup causes the problems.
>>
>> Regards
> 
> I used `/usr/lib/sympa/bin/sympa_wizard.pl --check` on my instance when
> it was debian 8, and I have executed again when debian 9.
> 
> Maybe that's a contribution to the problem. Is there knowed problems
> with this script on debian 9 ?
> 
> Regards
> 
> 

Yes, that sounds like a reasonable explanation for your problem. I suggest to 
remove these Mhonarc scripts
from /usr/local/share/perl/5.24.1.

Regards
Racke


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.



signature.asc
Description: OpenPGP digital signature

Bug#955611: ITP: golang-github-valyala-fasthttp -- Fast HTTP package for Go. Tuned for high performance.

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Alois Micard 

* Package name: golang-github-valyala-fasthttp
  Version : 1.9.0-1
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/fasthttp
* License : Expat
  Programming Lang: Go
  Description : Fast HTTP package for Go. Tuned for high 
performance. Zero memory allocations in hot paths. Up to 10x faster than 
net/http


 Fast HTTP implementation for Go.

--
Aloïs Micard 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#955586: Missing python3-dulwich dependency

[Mattia Rizzolo]

On Thu, Apr 02, 2020 at 11:02:41PM +0300, Mihai Limbasan wrote:
> The new repo / checkpointing feature in Sigil 1.2 depends on the Python 3
> dulwich module, packaged in Debian as python3-dulwich -- preferably 0.19.x

oh, right.
I didn't notice it while testing as I already had it installed in my
system.

> While python3-dulwich could go into the Recommends: section like most other
> py3 dependencies, I'd argue that in this case it should go into Depends:.

I agree :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#955605: debconf should support custom order for multiselect (or new entry type)

[Julian Andres Klode]

On Fri, Apr 03, 2020 at 10:34:07AM +0200, Julian Andres Klode wrote:
> Package: debconf
> Version: 1.5.73
> Severity: wishlist
> 
> While working on adding support for installing grub to multiple ESPs in 
> Ubuntu[1],
> I noticed that while debconf's multiselect type stores an ordered list, the
> selection screen does not provide the user the option to chose a custom order.
> 
> Now, in the use case of installing to multiple ESPs, this would be incredibly
> useful, as it allows you to specify the order of the ESPs that will be set
> in the bootorder (so that you can declare the order it falls back to different
> ESPs should some be broken).
> 
> I'm sure there are other examples.
> 
> Note that we don't really need a new debconf type, as the storage already
> is ordered, but like a flag to the frontend that gives the user the option
> to re-order entries would be enough (and not break frontends).

The easiest implementation for a frontend I guess is to present a list
you can order and a cut off entry, e.g.


option I like
another option I like
 put options you want above this line ---
option I don't want

Then to move the option around (on the TUI):

(1) press enter to select, up/down to move; press enter/esc to release
(2) use pgup/pgdwn to move them around

Something like that would be decent.

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

Bug#955612: python3-pyqt5: Cannot import Qt from QtCore

[mathieu]

Package: python3-pyqt5
Version: 5.11.3+dfsg-1+b3
Severity: normal

Dear Maintainer,

I tried to run this sample code:


#! /usr/bin/python3
from PyQt5.QtCore import Qt
print("Hello")

And I instantly get this error:

Traceback (most recent call last):
  File "./test-1.py", line 5, in 
from PyQt5.QtCore import Qt
ImportError: 
/usr/lib/python3/dist-packages/PyQt5/QtCore.cpython-37m-x86_64-linux-gnu.so: 
symbol _ZN23QOperatingSystemVersion11MacOSMojaveE version Qt_5 not defined in 
file libQt5Core.so.5 with link time reference

Please forgive me if this report is incomplete/rude/useless:

 * it's my first
 * I'm not english fluent
 * I'm not python fluent

Thanks




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

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

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libpython3.7  3.7.3-2+deb10u1
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5   5.11.3+dfsg1-1+deb10u3
ii  libqt5designer5   5.11.3-4
ii  libqt5gui55.11.3+dfsg1-1+deb10u3
ii  libqt5help5   5.11.3-4
ii  libqt5network55.11.3+dfsg1-1+deb10u3
ii  libqt5printsupport5   5.11.3+dfsg1-1+deb10u3
ii  libqt5test5   5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets55.11.3+dfsg1-1+deb10u3
ii  libqt5xml55.11.3+dfsg1-1+deb10u3
ii  libstdc++68.3.0-6
ii  python3   3.7.3-1
ii  python3-sip [sip-py3api-12.5] 4.19.14+dfsg-2

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

-- no debconf information

Bug#955495: ITP: orthanc-python -- Develop plugins for Orthanc using the Python programming language

[Sébastien Jodogne]

Hi Andreas,

Thanks for taking time!

As you recommended, I've switched to Python 3.x:
https://salsa.debian.org/med-team/orthanc-python/-/commit/1411f5bd1fd5002fcffaa810b427f827d83d0b2a

And I won't be considering packaging something like "orthanc-python3":
Python 3.x will be implied by "orthanc-python".

Regards,
Sébastien-


On 3/04/20 11:07, Andreas Tille wrote:
> Hi Sébastien,
> 
> I'm extremely short in time but I stumbled upon this:
> 
> On Fri, Apr 03, 2020 at 08:39:12AM +0200, Sébastien Jodogne wrote:
>> That being said, I have changed the dependency from Python 3 to Python 2 in
>> "d/control",
> 
> Whatever you do:  Avoid python and always use python3.
> 
> Please excuse my brewity
> 
>   Andreas.
> 

Bug#955613: ferm: @resolve stopped working in 2.5.1-1.1

[Jakob Haufe]

Package: ferm
Version: 2.5.1-1.1
Severity: important

With the update to 2.5.1-1.1, @resolve stopped working. Using it
results in the following error:

iptables-restore v1.8.4 (legacy): Bad IP address 
"deferred=ARRAY(0x5579922dacd0)"

Also, running "ferm --shell --remote /etc/ferm/ferm.conf" to test the
configuration, ferm complains:

You need the Perl library Net::DNS::Resolver::Mock to test

Installing libnet-dns-resolver-mock-perl to satisfy this, I end up with
another error:

/etc/ferm/zonefile: No such file or directory at 
/usr/share/perl5/Net/DNS/Resolver/Mock.pm line 54.

Cheers,
sur5r

P.S.: As I ended up with an empty ruleset after the update, this might
even qualify for severity serious.

-- 
ceterum censeo microsoftem esse delendam


pgpr6kD0pDWGB.pgp
Description: OpenPGP digital signature

Bug#955541: Login fails for a user name with non-ascii characters

[Sam Morris]

Package: systemd
Followup-For: Bug #955541
Control: affects -1 + sssd

This also prevents logging in using Active Directory credentials with
sssd. This is because sssd synthesizes an AD user's user name with:

CONCAT(SAM-Account-Name, '@', DNS Domain Name)

This also applies to group names.

It's worth remarking that a user or group SAM-Account-Name can contain
other characters that systemd isn't happy about such as commas and
spaces.

-- Package-specific info:

-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), 
(550, 'testing'), (530, 'unstable-debug'), (530, 'unstable'), (500, 
'stable-updates'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_WARN
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.30-2
ii  libcap2  1:2.25-2
ii  libcrypt11:4.4.15-1
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.12-2
ii  libgpg-error01.35-1
ii  libidn2-02.0.5-1+deb10u1
ii  libip4tc21.8.3-2~bpo10+1
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.3-1
ii  libselinux1  3.0-2.1
ii  libsystemd0  245.2-1.1
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-1

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  libnss-systemd   245.2-1.1
hi  libpam-systemd   245.2-1.1
ii  udev 244.3-1

-- Configuration Files:
/etc/pam.d/systemd-user changed [not included]

-- no debconf information

Bug#954845: poor performance for -g 256x50

[Harald Dunkel]

Sorry for the delay.

The rsnapshot file is just

% wc -c /var/log/rsnapshot
433435 /var/log/rsnapshot

See attachment. The important part seems to be the very long lines in the
text file. "time zcat rsnapshot.log.gz" gave me for a local network
connection

253x50:
real0m0.031s
user0m0.006s
sys 0m0.005s


254x50:
real0m0.031s
user0m0.004s
sys 0m0.007s


255x50:
real0m0.031s
user0m0.012s
sys 0m0.000s


256x50:
real0m0.068s
user0m0.004s
sys 0m0.009s


257x50:
real0m0.063s
user0m0.000s
sys 0m0.012s


258x50:
real0m0.064s
user0m0.004s
sys 0m0.006s


Please note the worse performance for 256x50 and larger.

I verified this for Xorg using intel graphics and for the proprietary
Nvidia graphics.


Regards
Harri


rsnapshot.log.gz
Description: application/gzip

Bug#954078: vulkan-loader: consider using multiple .orig tarball to simplify packaging

[Timo Aaltonen]

On 16.3.2020 14.41, Simon McVittie wrote:
> Source: vulkan-loader
> Version: 1.2.131.2-1
> Severity: wishlist
> 
> I notice that vulkan-loader contains a vendored copy of vulkan-headers,
> in order to keep the library and headers in sync, with the "upstream"
> tarball actually being composed by repacking the combination of
> vulkan-loader and vulkan-headers.
> 
> Since it's a 3.0 (quilt) package already, and the vendored vulkan-headers
> is in the top-level directory, this seems like a perfect fit for multiple
> .orig tarballs:
> 
> - download 
> https://github.com/KhronosGroup/Vulkan-Loader/archive/sdk-1.2.131.2.tar.gz
>   and rename it to vulkan-loader_1.2.131.2.orig.tar.gz
> - download 
> https://github.com/KhronosGroup/Vulkan-Headers/archive/sdk-1.2.131.1.tar.gz
>   and rename it to vulkan-loader_1.2.131.2.orig-vulkan-headers.tar.gz
>   (note the version number mismatch - sorry, I think this is unavoidable
>   with current tools, if your upstream doesn't always keep the version
>   numbers in sync)
> - put both in ../ or wherever else you keep your upstream tarballs, or
>   commit them to pristine-tar with gbp import-orig if you use that
> - import them both into your upstream-unstable git branch, perhaps with
>   gbp import-orig --upstream-vcs-tag=... --component=vulkan-headers
>   to keep it as a descendant of the upstream git history
> 
> This would avoid needing to repack the upstream tarball, which seems likely
> to be problematic if more than one developer imports it independently.

Hmm, well it seems that using multiple tarballs involves more steps than
the current one, if the tags can get out-of-sync as they are now.. so
right now I'd rather keep the current method.

> I'm involved in the maintenance of a derivative (the Steam Runtime) that
> has an interest in having the latest Vulkan library, and it's looking like
> I might need to package the latest release (a development version "v...",
> rather than the stable "sdk-..." versions that you package). Would you
> be interested in receiving a merge request with that version, targeting
> experimental?

sdk-* tags are needed in order to get the full stack to build, v.. tags
don't guarantee that they all fit together. So in that sense, having
only the loader and maybe tools (and not validationlayers) in
experimental, tracking v.. tags is fine by me. But I'd rather have you
then handle those all the way ;)


-- 
t

Bug#955603: RM: xserver-xorg-input-aiptek -- ROM; unmaintained, obsolete, or both

[Timo Aaltonen]

Hi, drop these from the list:

xserver-xorg-input-mtrack: not maintained by XSF :)

xserver-xorg-video-geode: apparently still useful on Debian


-- 
t

Bug#905014: Info received (Bug#936391: Bug#905014: I'm adopting dhcpy6d)

[Henri Wahl]

Hi there,

I want just inform you that the 1.0 release is out now. Maybe this one
makes packaging easier.

Thanks and best regards
Henri

-- 
Henri Wahl

IT Department

Leibniz-Institut für Festkörper- und Werkstoffforschung Dresden e.V.
Helmholtzstr. 20, 01069 Dresden, Germany

tel: +49 (3 51) 46 59 - 797
email: h.w...@ifw-dresden.de
https://www.ifw-dresden.de

Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de

DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de

S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem
PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc




0xFAC1C12483E6CEC2.asc
Description: application/pgp-keys


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#818228: Additional Information

[Rigoletto Eikenberg]

I have the same problem the volume sliders behave odd, and reported this
bug false at cinnamon.

These may be useful to clear/understand the problem:

https://github.com/linuxmint/cinnamon/issues/9213#issuecomment-608365500

Bug#955330: iproute2: corrupted output of "altname"

[Luca Boccassi]

On Tue, 31 Mar 2020 04:12:38 +0200 Adam Borowski 
wrote:
> Control: tags -1 -moreinfo
> 
> On Mon, Mar 30, 2020 at 10:36:03AM +0100, Luca Boccassi wrote:
> > On Mon, 2020-03-30 at 02:55 +0200, Adam Borowski wrote:
> > > On a system with a bridge "ip a" says:
> > > 
> > > 3: br0:  mtu 1500 qdisc noqueue
> > > state UP group default qlen 1000
> > > link/ether 76:29:4f:cd:bd:87 brd ff:ff:ff:ff:ff:ff
> > > altname �
> > >  ��
> > > altname ��!���
> 
> > > Kernel: Linux 5.6.0-00076-gbbfc4289910d (SMP w/4 CPU cores;
PREEMPT)
> 
> > Those strings come from the kernel via netlink, and you seem to
have a
> > custom kernel. Can you reproduce with Debian's kernel?
> 
> Yeah, I've just tried.  With 5.5.0-1 it's:
> 
> 0270  20 20 61 6c 74 6e 61 6d  65 20 c0 4e c2 b0 ff
ff  |  altname .N|
> 0280  0a 20 20 20 20 61 6c 74  6e 61 6d 65 20 d0 29
be  |.altname .).|
> 0290  b9 aa aa 0a 20 20 20 20  69 6e 65 74 20 31 30
2e  |inet 10.|
> 

Ok, I'll have a look once the 5.5 kernel hits backports, as it's
necessary to reproduce it.

-- 
Kind regards,
Luca Boccassi


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

Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM

[Paride Legovini]

On Sat, 8 Sep 2018 17:21:31 +0200 Ludovic Rousseau  
wrote:
> Le 05/09/2018 à 16:34, Nicolas Braud-Santoni a écrit :
> > Package: pcscd
> > Version: 1.8.23-3
> > Severity: normal
> > 
> > Hi,
> > 
> > pcscd fails to detect my Yubikey 4 Nano when resuming from suspend-to-disk,
> > resulting in GnuPG prompting me to insert the device; the problem persists
> > even if I unplug and replug the device, and until I restart pcscd.
> 
> I tried to reproduce the problem but without success.
> 
> Can you generate a pcscd trace as described in 
> https://pcsclite.apdu.fr/#support

Hi,

I'm also hitting this issue, but after trying a few things I'm not
convinced it is strictly a "resume after suspend" problem. But
let's proceed with order.

I normally keep a OpenPGP smartcard in my laptop's smartcard reader and
I use it via scdaemon with disable-ccid. Sometimes when I suspend and
resume my laptop I lose access to the smartcard: gnupg/scdaemon can't
find it anymore. Restarting pcscd helps (systemctl restart pcscd) often
but *not always* helps.

I tried to collect logs running pcscd in foreground in a shell, but
guess what, it *never* happens if I run it like this. The problem seems
to happen only when pcscd is started by systemd, and I found out that I
can reproduce it by restarting pcscd several time with systemctl. So I
modified pcscd.service like this:


[Service]
Environment=LIBCCID_ifdLogLevel=0x000F
ExecStart=/usr/sbin/pcscd --foreground --debug --apdu
#ExecStart=/usr/sbin/pcscd --foreground --auto-exit
#ExecReload=/usr/sbin/pcscd --hotplug


in order to collect the relevant logs. Here they are.

Here I restart pcscd with `systemctl restart pcscd`:

Apr 03 12:51:52 stramonio pcscd[97491]: 08882959 
pcscdaemon.c:193:signal_thread() Received signal: 15
Apr 03 12:51:52 stramonio pcscd[97491]: 0020 
pcscdaemon.c:213:signal_thread() Direct suicide
Apr 03 12:51:52 stramonio pcscd[97491]: 0004 pcscdaemon.c:787:at_exit() 
cleaning /run/pcscd
Apr 03 12:51:52 stramonio systemd[1]: Stopping PC/SC Smart Card Daemon...
Apr 03 12:51:52 stramonio systemd[1]: pcscd.service: Succeeded.
Apr 03 12:51:52 stramonio systemd[1]: Stopped PC/SC Smart Card Daemon.
Apr 03 12:51:52 stramonio systemd[1]: Started PC/SC Smart Card Daemon.
Apr 03 12:51:52 stramonio pcscd[98472]:  
debuglog.c:299:DebugLogSetLevel() debug level=debug
Apr 03 12:51:52 stramonio pcscd[98472]: 0020 
debuglog.c:320:DebugLogSetCategory() Debug options: APDU
Apr 03 12:51:52 stramonio pcscd[98472]: 0032 pcscdaemon.c:451:main() 
Started by systemd
Apr 03 12:51:52 stramonio pcscd[98472]: 0130 
configfile.l:293:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d
Apr 03 12:51:52 stramonio pcscd[98472]: 0020 
configfile.l:369:DBGetReaderList() Parsing conf file: 
/etc/reader.conf.d/libccidtwin
Apr 03 12:51:52 stramonio pcscd[98472]: 0040 
configfile.l:329:DBGetReaderListDir() Skipping non regular file: ..
Apr 03 12:51:52 stramonio pcscd[98472]: 0006 
configfile.l:329:DBGetReaderListDir() Skipping non regular file: .
Apr 03 12:51:52 stramonio pcscd[98472]: 0009 pcscdaemon.c:663:main() 
pcsc-lite 1.8.26 daemon ready.
Apr 03 12:51:52 stramonio pcscd[98472]: 8288 
hotplug_libudev.c:299:get_driver() Looking for a driver for VID: 0x1D6B, PID: 
0x0002, path: /dev/bus/usb/001/001
Apr 03 12:51:52 stramonio pcscd[98472]: 0169 
hotplug_libudev.c:299:get_driver() Looking for a driver for VID: 0x1D6B, PID: 
0x0002, path: /dev/bus/usb/001/001
Apr 03 12:51:52 stramonio pcscd[98472]: 0178 
hotplug_libudev.c:299:get_driver() Looking for a driver for VID: 0x058F, PID: 
0x9540, path: /dev/bus/usb/001/002
Apr 03 12:51:52 stramonio pcscd[98472]: 0115 
hotplug_libudev.c:440:HPAddDevice() Adding USB device: Alcor Micro AU9560
Apr 03 12:51:52 stramonio pcscd[98472]: 0152 
readerfactory.c:1074:RFInitializeReader() Attempting startup of Alcor Micro 
AU9560 00 00 using 
/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so
Apr 03 12:51:52 stramonio pcscd[98472]: 0295 
readerfactory.c:950:RFBindFunctions() Loading IFD Handler 3.0
Apr 03 12:51:52 stramonio pcscd[98472]: 0029 
ifdhandler.c:1961:init_driver() Driver version: 1.4.31
Apr 03 12:51:52 stramonio pcscd[98472]: 0781 
ifdhandler.c:1978:init_driver() LogLevel: 0x0003
Apr 03 12:51:52 stramonio pcscd[98472]: 0016 
ifdhandler.c:1989:init_driver() DriverOptions: 0x
Apr 03 12:51:52 stramonio pcscd[98472]: 0202 
ifdhandler.c:2002:init_driver() LogLevel from LIBCCID_ifdLogLevel: 0x000F
Apr 03 12:51:52 stramonio pcscd[98472]: 0012 
ifdhandler.c:110:CreateChannelByNameOrChannel() Lun: 0, device: 
usb:058f/9540:libudev:0:/dev/bus/usb/001/002
Apr 03 12:51:52 stramonio pcscd[98472]: 0005 ccid_usb.c:237:OpenUSBByName() 
Reader index: 0, Device: usb:058f/9540:libudev:0:/dev/bus/usb/001/002
Apr 03 12:51:52 stramonio pcscd[98472]: 0014 ccid_usb.c:269:OpenUSBByName() 
interface_number: 0
Apr 03 12:51:52 stramonio pcscd[98472]: 0003 ccid_usb.c

Bug#854869: Removing REST API not recommended

[Martin Steigerwald]

Hi.

Craig Small - 03.04.20, 02:18:47 CEST:
> WordPress doesn't recommend that sites disable the REST API[1]
> therefore it would cause more problems doing this by default in the
> Debian package. There are a few ways of adjusting the REST API if
> needed.

Fair enough.

I found this out myself as the new block based editor won't work without 
it.

I use the Disable WP REST API plugin meanwhile.

> 1:
> https://developer.wordpress.org/rest-api/frequently-asked-questions/#c
> an-i-disable-the-rest-api

Thanks,
-- 
Martin

Bug#955614: ITP: python-django-health-check -- Checks for various conditions and provides reports

[Michal Arbet]

Package: wnpp
Severity: wishlist
Owner: Michal Arbet 

* Package name: python-django-health-check
  Version : 3.12.1
  Upstream Author : Kristian Øllegaard 
* URL :
https://github.com/KristianOellegaard/django-health-check
* License : MIT
  Programming Lang: Python
  Description : Checks for various conditions and provides reports

Package is needed as dependency for python-ara which i will package and
will be tracked in different ITP Bug.
I will maintain package under DPMT team.

Bug#943402: [Tts-project] Bug#943402: I have the same issue

[Sergio Oller]

I was able to reproduce the issue and I submitted a merge request here:
https://salsa.debian.org/tts-team/festival-it/-/merge_requests/1
I am facing a technical issue with line endings in the source code and the
patch, so quilt refuses to apply it.
Does anyone know how to fix those?

Bug#943402: [Tts-project] Bug#943402: I have the same issue

[Samuel Thibault]

Hello,

Thanks for the patch!

Sergio Oller, le ven. 03 avril 2020 13:52:35 +0200, a ecrit:
> I was able to reproduce the issue and I submitted a merge request here:
> [1]https://salsa.debian.org/tts-team/festival-it/-/merge_requests/1
> I am facing a technical issue with line endings in the source code and the
> patch, so quilt refuses to apply it.
> Does anyone know how to fix those?

I fixed it. I am however still getting the bug with the patch applied:

$ LANG= dpkg -l \*fest\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--==
ii  festival   1:2.5.0-4 amd64General multi-lingual 
speech synthesis system
ii  festival-freebsoft-utils   0.10-8all  Festival extensions 
and utilities
un  festival-voice(no description 
available)
ii  festlex-cmu2.4-2 all  CMU dictionary for 
Festival
ii  festlex-ifd2.0+debian0-6 all  Italian support for 
Festival
ii  festlex-oald   2.4-3 all  Festival lexicon from 
Oxford Advanced Learners' Dictionary
ii  festlex-poslex 2.4-1 all  Part of speech 
lexicons and ngram from English
ii  festvox-italp16k   2.0+debian0-6 all  Italian female 
speaker for Festival
ii  festvox-itapc16k   2.0+debian0-6 all  Italian male speaker 
for Festival
un  festvox-kallpc16k (no description 
available)
un  pidgin-festival   (no description 
available)
ii  speech-dispatcher-festival 0.9.1-4   amd64Festival support for 
Speech Dispatcher

$ echo text | festival --tts
SIOD ERROR: wrong type of argument to get_c_utt 

Samuel

Bug#955615: D-Bus policy configuration file is missed

[Sergey Alyoshin]

Package: shairport-sync
Version: 3.3.5-1
Priority: minor

D-Bus policy configuration file is missed and the 'journalct -u
shairport-sync' log contains the following message:
Could not acquire a Shairport Sync native D-Bus interface
"org.gnome.ShairportSync.i524" on the system bus

Configuration file can be copied
from scripts/shairport-sync-dbus-policy.conf (in shairport-sync source tree)
to /etc/dbus-1/system.d/shairport-sync-dbus-policy.conf

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

[Oswald Buddenhagen]

Package: qtcreator
Version: 4.11.0-2
Followup-For: Bug #952718

i just wasted about half an hour on researching this, so i'll summarize 
my current understanding:

libclang-N needs to depend on libclang-common-N-dev, as otherwise it's 
dysfunctional.

failing that, qtcreator needs to recommend libclang-common-N-dev. this 
could be upgraded to depends if the clang-related plugins incl.  
libclangsupport are factored out to a separate qtcreator sub-package 
which qtcreator recommends.
alternatively, this approach could be used to isolate the libclang-N 
dependency itself.

that qtcreator's code model technically uses the wrong headers is 
correct, but orthogonal to the issue, and usually not problematic (which 
is why the approach was deemed accepatable in the first place).

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Gilles Filippini]

Hi,

On Wed, 01 Apr 2020 11:47:33 +0800 Drew Parsons  wrote:
> Package: bitshuffle
> Version: 0.3.5-3
> Severity: serious
> Justification: FTBFS
> Control: block 954654 by -1
> 
> bitshuffle fails to build against hdf5: 1.10.6+repack-1, because
> tmp_test_filters.h5 does not exist
> 
> OSError: Unable to open file (unable to open file: name = 
> 'tmp_test_filters.h5', errno = 2, error message = 'No such file or 
> directory', flags = 0, o_flags = 0)
> 
> 
> The test filename 'tmp_test_filters.h5' is hardcoded in l.26 of
> bitshuffle/tests/test_h5filter.py

This is not related to the ongoing hdf5 transition, but to the recent
uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've
checked that bitshuffle builds successfully. It was against h5py
2.10.0-2 by then.

_g.



signature.asc
Description: OpenPGP digital signature

Bug#955545: duplicity: The backup fails with unicode error

[Kenneth Loafman]

Please upgrade to the current version of duplicity.  This will assure that
any bugs fixed since your release are available and may fix your issue.

There are multiple options both stable and daily:


   - Stable tarball install - https://launchpad.net/duplicity/+download
   - Daily duplicity builds -
   https://launchpad.net/~duplicity-team/+archive/ubuntu/daily-dev-trunk
   - Stable snap builds - “sudo snap install duplicity —classic"
   - Latest snap builds - “sudo snap install duplicity —classic —edge"
   - Latest pip builds - “sudo pip install duplicity"


NOTE: UNinstall duplicity first if it was installed via the distribution
repository.  For Ubuntu that would be "sudo apt-get purge duplicity".

On Thu, Apr 2, 2020 at 5:00 AM Mickael Viey  wrote:

> Package: duplicity
> Version: 0.7.18.2-1
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where
> appropriate ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
> Today the backup fails with an unicde error:
>
> Traceback (innermost last):
>   File "/usr/bin/duplicity", line 1567, in 
> with_tempdir(main)
>   File "/usr/bin/duplicity", line 1553, in with_tempdir
> fn()
>   File "/usr/bin/duplicity", line 1405, in main
> do_backup(action)
>   File "/usr/bin/duplicity", line 1535, in do_backup
> incremental_backup(sig_chain)
>   File "/usr/bin/duplicity", line 670, in incremental_backup
> sig_chain.get_fileobjs())
>   File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line
> 539, in get_fileobjs
> return [filename_to_fileobj(f) for f in self.get_filenames(time)]
>   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line
> 676, in get_fileobj_read
> self.get(filename, tdp)
>   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line
> 395, in inner_retry
> % (n, e.__class__.__name__, util.uexc(e)))
>   File "/usr/lib/python2.7/dist-packages/duplicity/util.py", line 79, in
> uexc
> return ufn(unicode(e).encode('utf-8'))
>  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> 35: ordinal not in range(128)
>
> Duplicity has worked as expected until now.
>
> Please let me know if you need some additional information.
>
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.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 duplicity depends on:
> ii  gnupg 2.2.12-1+deb10u1
> ii  libc6 2.28-10
> ii  librsync1 0.9.7-10+b1
> ii  python2.7.16-1
> ii  python-fasteners  0.12.0-3
> ii  python-lockfile   1:0.12.2-2
>
> Versions of packages duplicity recommends:
> ii  python-oauthlib  2.1.0-1
> ii  python-paramiko  2.4.2-0.1
> ii  python-pexpect   4.6.0-1
> ii  python-urllib3   1.24.1-1
> ii  rsync3.1.3-6
>
> Versions of packages duplicity suggests:
> pn  lftp
> pn  ncftp   
> pn  python-boto 
> pn  python-cloudfiles   
> pn  python-gdata
> pn  python-pip  
> pn  python-swiftclient  
> pn  tahoe-lafs  
>
> -- no debconf information
>
>

Bug#955616: ITP: r4d -- Remote For Device-under-test (testlab manager)

[Bastian Germann]

Package: wnpp
Severity: wishlist
Owner: Bastian Germann 

* Package name: r4d
  Version : 1.4
  Upstream Author : Benedikt Spranger 
* URL : https://github.com/ci-rt/libr4d
* License : GPL-3+
  Programming Lang: Python
  Description : r4d is a testlab manager

The r4d contains a daemon that is supposed to be run in testing lab
environments to control devices that are targets of automatic test runs.
It can power cycle the devices and grab a serial port.

It can be controlled by libr4d via a SOAP interface.

Bug#955582: facter: autopkgtest needs update for new version of ruby-defaults: deprecation *warning* on stderr

[Antonio Terceiro]

Control: tag -1 + patch

On Thu, Apr 02, 2020 at 09:27:29PM +0200, Paul Gevers wrote:
> Source: facter
> Version: 3.11.0-3
> Severity: serious
> Tags: sid bullseye
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:ruby-defaults
> 
> [X-Debbugs-CC: debian...@lists.debian.org,
> ruby-defau...@packages.debian.org]
> 
> Dear maintainer(s),
> 
> With a recent upload of ruby-defaults the autopkgtest of facter fails in
> testing when that autopkgtest is run with the binary packages of
> ruby-defaults from unstable. It passes when run with only packages from
> testing. In tabular form:
> 
>passfail
> ruby-defaults  from testing1:2.7
> facter from testing3.11.0-3
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. I think the
> only issue that the autopkgtest is showing is that you're using a
> deprecated method. If you can't fix the code on the short term (best) or
> run the test suite without emitting warnings (a good thing to do
> anyways, autopkgtest isn't meant to catch those), please consider adding
> the allow-stderr restriction for the time being.
> 
> Currently this regression is blocking the migration of ruby-defaults to
> testing [1]. Of course, ruby-defaults shouldn't just break your
> autopkgtest (or even worse, your package), but it seems to me that the
> change in ruby-defaults was intended and your package needs to update to
> the new situation.
> 
> If this is a real problem in your package (and not only in your
> autopkgtest), the right binary package(s) from ruby-defaults should
> really add a versioned Breaks on the unfixed version of (one of your)
> package(s). Note: the Breaks is nice even if the issue is only in the
> autopkgtest as it helps the migration software to figure out the right
> versions to combine in the tests.
> 
> 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=ruby-defaults
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/f/facter/4775724/log.gz
> 
> autopkgtest [07:14:35]: test puppet:  - - - - - - - - - - results - - -
> - - - - - - -
> puppet   FAIL stderr:
> /usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is
> obsolete

Dear maintainer(s),

Please apply the attached patch.
From 479d32ff543cf5a1215f214302566740876c663e Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Fri, 3 Apr 2020 09:42:31 -0300
Subject: [PATCH] autopkgtest: ignore output on stderr

This makes the autopkgtest less fragile as otherwise it will fail if
e.g. any dependency generates a Ruby warning. This is specially annoying
when handling migrations of the Ruby interpreter.

Closes: #955582
---
 debian/tests/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/tests/control b/debian/tests/control
index 4bfefb12..5c181550 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -3,7 +3,9 @@ Restrictions: allow-stderr
 Depends: @
 
 Tests: ruby
+Restrictions: allow-stderr
 Depends: facter, ruby
 
 Tests: puppet
+Restrictions: allow-stderr
 Depends: facter, puppet
-- 
2.26.0



signature.asc
Description: PGP signature

Bug#955206: freeradius: Daemon has write privilege to configuration

[wferi]

"Debian Bug Tracking System"  writes:

> - set ReadOnlyDirectories to the configuration (Closes: #955206)

Well, not very transparent or general, but certainly address my main
concern.  However, the file ownerships still send the wrong message to
me.  Could you please explain why the configuration files are owned by
the freerad user?
-- 
Thanks,
Feri

Bug#955456: FTBFS: test file tmp_test_filters.h5 does not exist

[Drew Parsons]

On 2020-04-03 20:13, Gilles Filippini wrote:


This is not related to the ongoing hdf5 transition, but to the recent
uploads of h5py >= 2.10.0-3. Before triggering the hdf5 transition I've
checked that bitshuffle builds successfully. It was against h5py
2.10.0-2 by then.



The change in behaviour comes from the h5py upstream patches applied in 
h5py 2.10.0-3.


file_default_read_5e71c49.patch in particular is the one that updates 
the API, setting File() to mode='r' by default.  I added the patch to 
deal with the H5pyDeprecationWarning we were getting, since the change 
was flagged as coming in from upstream anyway.  In principle it just 
means mode needs to be added explicitly as h5py.File(filename, mode), if 
the required mode is not 'r'.


But it must be something else from these new h5py upstream patches 
that's leading to any other bitshuffle errors (the ones apart from the 
file-not-found error).


It's a pity the hdf5 transition and new h5py package structure came on 
at the same time, makes it a touch more angst-provoking working through 
the changes than it would otherwise be (h5py was in the NEW queue for a 
while, got accepted at the same time as the HDF5 transition).


Drew

Bug#955617: boinc-client: proxy settings in environment are ignored

[Olaf Zaplinski]

Package: boinc-client
Version: 7.14.2+dfsg-3
Severity: normal

Dear Maintainer,

the environment proxy settings like HTTP_PROXY or http_proxy proxy are being 
ignored

Bug#943402: [Tts-project] Bug#943402: Bug#943402: I have the same issue

[Sergio Oller]

Hello,

Missatge de Samuel Thibault  del dia dv., 3 d’abr.
2020 a les 14:18:

> Hello,
>
> Thanks for the patch!
>
It's the least I can do. I wish I had more time to devote to debian tts.

>
> Sergio Oller, le ven. 03 avril 2020 13:52:35 +0200, a ecrit:
> > I was able to reproduce the issue and I submitted a merge request here:
> > [1]https://salsa.debian.org/tts-team/festival-it/-/merge_requests/1
> > I am facing a technical issue with line endings in the source code and
> the
> > patch, so quilt refuses to apply it.
> > Does anyone know how to fix those?
>
> I fixed it. I am however still getting the bug with the patch applied:
>
> $ LANG= dpkg -l \*fest\*
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version   Architecture Description
>
> +++-==-=--==
> ii  festival   1:2.5.0-4 amd64General
> multi-lingual speech synthesis system
> ii  festival-freebsoft-utils   0.10-8all  Festival
> extensions and utilities
> un  festival-voice(no description
> available)
> ii  festlex-cmu2.4-2 all  CMU dictionary
> for Festival
> ii  festlex-ifd2.0+debian0-6 all  Italian support
> for Festival
> ii  festlex-oald   2.4-3 all  Festival lexicon
> from Oxford Advanced Learners' Dictionary
> ii  festlex-poslex 2.4-1 all  Part of speech
> lexicons and ngram from English
> ii  festvox-italp16k   2.0+debian0-6 all  Italian female
> speaker for Festival
> ii  festvox-itapc16k   2.0+debian0-6 all  Italian male
> speaker for Festival
> un  festvox-kallpc16k (no description
> available)
> un  pidgin-festival   (no description
> available)
> ii  speech-dispatcher-festival 0.9.1-4   amd64Festival support
> for Speech Dispatcher
>
> $ echo text | festival --tts
> SIOD ERROR: wrong type of argument to get_c_utt
>
My mistake. With the line ending issues I missed a function return value. I
pushed one additional commit to the salsa repository.
Just in case anyone wonders, debugging the error became a bit easier once I
added "(set_backtrace t)" to /etc/festival.scm


> Samuel
>
> ___
> Tts-project mailing list
> tts-proj...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/tts-project

Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM

[Ludovic Rousseau]

Hello Paride,

Le 03/04/2020 à 13:20, Paride Legovini a écrit :

Hi,

I'm also hitting this issue, but after trying a few things I'm not
convinced it is strictly a "resume after suspend" problem. But
let's proceed with order.

I normally keep a OpenPGP smartcard in my laptop's smartcard reader and
I use it via scdaemon with disable-ccid. Sometimes when I suspend and
resume my laptop I lose access to the smartcard: gnupg/scdaemon can't
find it anymore. Restarting pcscd helps (systemctl restart pcscd) often
but *not always* helps.

I tried to collect logs running pcscd in foreground in a shell, but
guess what, it *never* happens if I run it like this. The problem seems
to happen only when pcscd is started by systemd, and I found out that I
can reproduce it by restarting pcscd several time with systemctl. So I
modified pcscd.service like this:


[Service]
Environment=LIBCCID_ifdLogLevel=0x000F
ExecStart=/usr/sbin/pcscd --foreground --debug --apdu
#ExecStart=/usr/sbin/pcscd --foreground --auto-exit
#ExecReload=/usr/sbin/pcscd --hotplug


in order to collect the relevant logs. Here they are.


Thanks a lot for your tests and logs.

When you write "trying to access the smartcard doesn't work." what happens 
exactly?
Do you have an error from gpg or scdaemon?
I ask because I don't see any error reported by pcscd.

So maybe the problem is between pcscd and libpcsclite.

When it fails:
- is the socket /var/run/pcscd/pcscd.comm still present?
- what do you get when you run pcsc_scan? (from the pcsc-tools package)

Thanks

PS: maybe you should change your smart card password if it starts with "c".

--
Dr. Ludovic Rousseau

Bug#943402: [Tts-project] Bug#943402: Bug#943402: Bug#943402: I have the same issue

[Samuel Thibault]

Sergio Oller, le ven. 03 avril 2020 15:17:51 +0200, a ecrit:
> I pushed one additional commit to the salsa repository.

Ok, it works here as well, I'll upload that.

Samuel

Bug#955206: freeradius: Daemon has write privilege to configuration

[Bernhard Schmidt]

Am 03.04.20 um 15:10 schrieb wf...@niif.hu:

Hi,

> "Debian Bug Tracking System"  writes:
> 
>> - set ReadOnlyDirectories to the configuration (Closes: #955206)
> 
> Well, not very transparent or general, but certainly address my main
> concern.  However, the file ownerships still send the wrong message to
> me.  Could you please explain why the configuration files are owned by
> the freerad user?

To be honest I have no idea, this was way before my time.

I think it was introduced here in 3.0.12+dfsg-2, shortly before Stretch

https://salsa.debian.org/debian/freeradius/-/commit/42abc545ac8cdf376582ef81701f8db1ab0c3511#bee60e2d25c9ef61ebd4c5d27fecf8ab0a79dd6b

I'm open to changing that, but I currently lack the time to properly
test a migration path. If you have a tested patch, feel free to reopen
and attach it.

Bernhard

Bug#954209: Do we want to add a fork of utls (ITP #954209)?

[Ana Custura]

Hi Ulrike and Cecylia,

Thank you for looking at this!

On 16/03/2020 18:12, Ulrike Uhlig wrote:

> If I understand correctly from a quick look, Yawning distributes his
> changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license
> [https://github.com/refraction-networking/utls/blob/master/LICENSE].
>
> The BSD 3-Clause is in line with the Debian Free Software Guidelines
> (DFSG)[https://wiki.debian.org/DFSGLicenses#The_BSD-3-clause_License].
>
> From my understanding, in Debian packaging, licenses generally apply to
> files but it also seems possible (I never encountered such a case) to
> have several licenses for one file
> [https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax].
> Maybe someone could confirm that this is accepted.
>
> I'm now unsure to what we referred to previously when saying that there
> might be licensing issues with Yawning's fork. It does not look like
> there are. Or am I missing something crucial here? If I don't, then to move 
> forward, one would need to open an RFP or ITP
> (Intent to Package) bug on the Debian bugtracker and then package this
> fork of uTLS.
To sum up the concerns that came from looking at it last time:

golang-yawning-utls-dev is a fork of utls, which is itself a fork of the
golang tls library. This is a hard fork, any improvements cannot be
shipped upstream due to the difference in licensing that you've
identified. The upstream is very active - go has >1500 contributors,
uTLS has >50 contributors. The fork we want to package is maintained by
very few people, if I'm not mistaken, Yawning is the only core contributor.
I think there is a security implication here - if there is a security
advisory for the golang library, the Debian Security team needs to work
with the upstreams to apply security patches to it and all of its forks
in Debian, meaning this one too. If the delta from upstream increases
with every fork this could mean a lot of pain.

However, my understanding of the dynamics could be entirely wrong, so
let me know if I'm off the mark.

Sending this to the Debian Security team, to ask if they see any
problems here. Including the source link:
https://gitlab.com/yawning/utls and ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954209

If we're all good, I'd be very happy to help with packaging or even
sponsoring this (I've recently completed the process to become DD, now
under review!).

>
> → actually that package was uploaded to mentors.debian.org and could go
> to experimental.
Happy to update this to the latest policy and reupload if this is
something we want to do.
>> Hey, I'm new to the debian packaging space but am happy to help out here.
Awesome, thank you for helping with this :)

Thank you all,

Ana



signature.asc
Description: OpenPGP digital signature

Bug#955618: Settings -> Active Sessions gives 500 error

[Pirate Praveen]

Package: gitlab
Version: 12.8.8-5
Severity: important

Thanks to rovonovo_zoro for the report.

Started GET "/profile/active_sessions" for 192.168.122.1 at 2020-04-03 
13:34:10 +

Processing by Profiles::ActiveSessionsController#index as HTML
Completed 500 Internal Server Error in 46ms (ActiveRecord: 2.3ms | 
Elasticsearch: 0.0ms | Allocations: 20615)


ActionView::Template::Error (no implicit conversion of 
Rack::Session::SessionId into String):

   27:
   28: - unless is_current_session
   29: .float-right
   30: = link_to 
profile_active_session_path(active_session.public_id), data: { confirm: 
_('Are you sure? The device will be signed out of GitLab.') }, method: 
:delete, class: "btn btn-danger prepend-left-10" do

   31: %span.sr-only= _('Revoke')
   32: = _('Revoke')

/usr/lib/ruby/vendor_ruby/encryptor.rb:97:in `update'
/usr/lib/ruby/vendor_ruby/encryptor.rb:97:in `crypt'
/usr/lib/ruby/vendor_ruby/encryptor.rb:36:in `encrypt'
lib/gitlab/crypto_helper.rb:19:in `aes256_gcm_encrypt'
app/models/active_session.rb:27:in `public_id'
app/views/profiles/active_sessions/_active_session.html.haml:30
actionview (6.0.2.1) lib/action_view/base.rb:274:in `_run'
actionview (6.0.2.1) lib/action_view/template.rb:185:in `block in 
render'
activesupport (6.0.2.1) lib/active_support/notifications.rb:182:in 
`instrument'

Bug#955619: openjdk-11-jre-headless: failure to install due to non-existant /usr/share/man/man1/ directory

[Yannik Sembritzki]

Package: openjdk-11-jre-headless
Version: 11.0.6+10-1~deb10u1
Severity: important

Dear Maintainer,

installing openjdk-11-jre-headless on the official debian:buster-slim
docker image results in a fatal dpkg installation error: 

update-alternatives: error: error creating symbolic link '/usr/share/man/man1/rm
id.1.gz.dpkg-tmp': No such file or directory
dpkg: error processing package openjdk-11-jre-headless:amd64 (--configure):
 installed openjdk-11-jre-headless:amd64 package post-installation script subpro
cess returned error exit status 2

This can be fixed by manually creating the /usr/share/man/man1/
directory.  

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

Kernel: Linux 5.5.13-200.fc31.x86_64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages openjdk-11-jre-headless depends on:
ii  ca-certificates-java  20190405
ii  java-common   0.71
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libcups2  2.2.10-6+deb10u2
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  libnss3   2:3.42.1-1+deb10u2
ii  libpcsclite1  1.8.24-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxrender1   1:0.9.10-1
ii  libxtst6  2:1.2.3-1
ii  util-linux2.33.1-0.1
ii  zlib1g1:1.2.11.dfsg-1

openjdk-11-jre-headless recommends no packages.

Versions of packages openjdk-11-jre-headless suggests:
pn  fonts-dejavu-extra 
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
pn  libnss-mdns

-- no debconf information

Bug#955583: ruby-defaults breaks ruby-mousetrap-rails autopkgtest: TypeError: no implicit conversion of String into Integer

[Antonio Terceiro]

Hi

On Thu, Apr 02, 2020 at 09:38:26PM +0200, Paul Gevers wrote:
> Source: ruby-defaults, ruby-mousetrap-rails
> Control: found -1 ruby-defaults/1:2.7
> Control: found -1 ruby-mousetrap-rails/1.4.6-6
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of ruby-defaults the autopkgtest of
> ruby-mousetrap-rails fails in testing when that autopkgtest is run with
> the binary packages of ruby-defaults from unstable. It passes when run
> with only packages from testing. In tabular form:
> 
>passfail
> ruby-defaults  from testing1:2.7
> ruby-mousetrap-rails   from testing1.4.6-6
> all others from testingfrom testing
[...]
> Bundle complete! 19 Gemfile dependencies, 77 gems now installed.
> Use `bundle info [gemname]` to see where a bundled gem is installed.
> + bundle exec rake assets:precompile
> rake aborted!
> TypeError: no implicit conversion of String into Integer

I was debugging this, and it turns out this is caused by ruby-bootsnap
from testing. However, ruby-bootsnap is a dependency of rails, which
used in the test, not of the packages being tested.

I went to check the migration status of ruby-bootsnap, but its migration
depends on the migration of src:ruby-defaults itself. So we have a
circular dependency.

I detected at least another packages failing in the exact same way. Is
the fix for this declaring Breaks: in ruby-defaults?


signature.asc
Description: PGP signature

Bug#955413: btrfs-progs: new mount-time checking causes systemd to timeout and boot failure

[Christoph Anton Mitterer]

We see that, too, at the institute... any larger (few TB) filesystems
in /etc/fstab make systemd cause the system to fail at boot... leaving
it a state with no remote resuce (ssh) being possible.

Since such filesystems would mount just fine... I would rather say that
this functionality is a severe bug.


Cheers,
Chris.

Bug#955620: cloud-init - debian/rules clean fails from git repo

[Bastian Blank]

Package: cloud-init
Version: 20.1-X
Severity: important

Currently running debian/rules clean from git repository fails:

|  % ./debian/rules clean
| py3versions: no X-Python3-Version in control file, using supported versions
| dh clean --with python3,systemd --buildsystem pybuild
|dh_auto_clean -O--buildsystem=pybuild
| I: pybuild base:217: python3.7 setup.py clean
| Traceback (most recent call last):
|   File "setup.py", line 293, in 
| version=get_version(),
|   File "setup.py", line 85, in get_version
| (ver, _e) = tiny_p(cmd)
|   File "setup.py", line 50, in tiny_p
| (cmd, ret, out, err))
| RuntimeError: Failed running ['/usr/bin/python3.7', 'tools/read-version'] 
[rc=1] (, git describe version (0.7.9-145-g12042ee9) differs from 
cloudinit.version (20.1)
| Please get the latest upstream tags.
| As an example, this can be done with the following:
| $ git remote add upstream https://git.launchpad.net/cloud-init
| $ git fetch upstream --tags
| )
| E: pybuild pybuild:352: clean: plugin distutils failed with: exit code=1: 
python3.7 setup.py clean
| dh_auto_clean: error: pybuild --clean --test-nose -i python{version} -p "3.7 
3.8" returned exit code 13
| make: *** [debian/rules:7: clean] Error 13

Bastian

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

Kernel: Linux 5.4.0-4-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 cloud-init depends on:
ii  fdisk   2.34-0.1
ii  gdisk   1.0.5-1
pn  ifupdown
ii  locales 2.30-2
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.16-4
ii  python3 3.8.2-2
pn  python3-configobj   
ii  python3-jinja2  2.10.1-2
pn  python3-jsonpatch   
pn  python3-jsonschema  
pn  python3-oauthlib
ii  python3-requests2.22.0-2
ii  python3-six 1.14.0-2
ii  python3-yaml5.3.1-1
ii  util-linux  2.34-0.1

Versions of packages cloud-init recommends:
pn  cloud-guest-utils  
pn  eatmydata  
ii  sudo   1.8.31p1-1

Versions of packages cloud-init suggests:
pn  btrfs-progs  
ii  e2fsprogs1.45.6-1
pn  xfsprogs 

Bug#955191: RFS: bubblemail/0.5-1 [ITP] -- Extensible mail notification service

[Adam Borowski]

On Sat, Mar 28, 2020 at 12:36:40AM -0400, Thomas Ward wrote:
>  * Package name: bubblemail
>Version : 0.5-1

> Changes since the last upload:
> 
>* Initial release. (Closes: #955188)
>* original source package automatically created by stdeb 0.8.5

Hi!
Here are my first findings:

* There's no point including debian/changelog before the initial release.

* Lintian overrides are bad: binary-without-manpage is a real problem
  rather than a false positive (even if in some cases it's one with
  little significance).  If the binaries are never supposed to be run
  by an user directly (not even by users who prefer command-line over
  a GUI menu), they shouldn't live in $PATH, but otherwise, manpages
  are wanted.

* The excuse for those overrides, that the documentation is available
  online, returns "ERREUR 404 - Document non trouvé".

* Recommends: network-manager -- what's the point for a biff service
  to mess with network settings?

* It crashes for me on startup:

[~]$ bubblemail
Traceback (most recent call last):
  File "/usr/bin/bubblemail", line 26, in 
from bubblemail.ui.settingswindow import SettingsWindow  # pylint: 
disable=no-name-in-module
  File "/usr/lib/python3/dist-packages/bubblemail/ui/settingswindow.py", line 
38, in 
from ..account import Account as A, RemoteAccount, LocalAccount
  File "/usr/lib/python3/dist-packages/bubblemail/account.py", line 24, in 

gi.require_version('Secret', '1')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Secret not available


But, the package's description makes me want to see it working.  I'm quite
fed up with keeping Thunderbird running as glorified biff for remote
accounts, and something better for that task would be nice for me.

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#955621: python3-pyqt5 still depends on libpython3.7

[Christian Göttsche]

Package: python3-pyqt5
Version: 5.14.1+dfsg-3

Dear Maintainer,

this package still depends on libpython3.7, although 3.8 is the
default python version in sid.

Best regards
 Christian Göttsche

Bug#955622: release.debian.org: Testing auto removal claims moonshot-ui to be removed for bug it fixesmoonsot

[Sam Hartman]

Package: release.debian.org
Severity: normal

I got a message from testing auto removal saying:

>moonshot-ui 1.1.0+libsecret~2 is marked for autoremoval from testing on 
>2020-04-27

>It is affected by these RC bugs:
>952054: moonshot-ui: FTBFS: libmoonshot.vapi:45.34-45.56: error:
But that bug is *fixed* in moonshot-ui 1.1.0+libsecret2.


I'm guessing that this is probably some race condition between migration and 
removals data sources updating.
But it seems odd that the testing auto removal script knows about the new 
version but doesn't know that the new version  fixes the RC bug in question.

If the removal notice is correct and moonshot-ui is still scheduled for removal 
even though I fixed the bug, I'd like to better understand what's up.

Bug#955622: release.debian.org: Testing auto removal claims moonshot-ui to be removed for bug it fixesmoonsot

[Mattia Rizzolo]

On Fri, Apr 03, 2020 at 10:29:08AM -0400, Sam Hartman wrote:
> >moonshot-ui 1.1.0+libsecret~2 is marked for autoremoval from testing on 
> >2020-04-27
> 
> I'm guessing that this is probably some race condition between migration and 
> removals data sources updating.
> But it seems odd that the testing auto removal script knows about the new 
> version but doesn't know that the new version  fixes the RC bug in question.

It's more likely that the race lies within the BTS.  The BTS only
exports data about whether a bug affects testing or not, without version
information.

> If the removal notice is correct and moonshot-ui is still scheduled for 
> removal even though I fixed the bug, I'd like to better understand what's up.

At this writing, from what I see it's not scheduled for removal anymore.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#955623: RM: rabbyt -- ROM; python2-only; dead upstream; last upstream release in 2009; last upload in 2015; no rdeps (worth keeping this package for); low popcon

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#955624: python3-pip: depend on python3.8 instead of python3.7

[Jörg-Volker Peetz]

Package: python3-pip
Version: 20.0.2-3
Severity: wishlist

Dear Debian Python Modules Team,

this package is one of two on my system which still depends on
python3.7. When is the shift to dependency on python3.8 scheduled?

Regards,
Jörg.


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

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

Versions of packages python3-pip depends on:
ii  ca-certificates 20190110
ii  python-pip-whl  20.0.2-3
ii  python3 3.8.2-2
ii  python3-distutils   3.8.2-2
ii  python3-setuptools  44.0.0-1
ii  python3-wheel   0.34.2-1
ii  python3.7   3.7.7-1+b1

Versions of packages python3-pip recommends:
ii  build-essential  12.8
ii  python3-dev  3.8.2-2

python3-pip suggests no packages.

-- no debconf information

Bug#874176: Please update the package

[Philipp Marek]

This is still broken... please provide a working package!

Thank you so much.

Bug#885914: Fix available to merge

[Robinson Sathaseevan]

Dear s3cmd maintainer,

I have successfully been able to reproduce this issue with a basic setup. I
forked the current source on salsa and committed a working patch [0] based
on the upstream fix [1].

User "jrtc27" #debian-mentors suggested I use the actual patch from [2]
instead of my own. They are absolutely correct and I didn't think of that
earlier unfortunately. I can create a pull request of [0] as is or I can
correct my fork to use upstream's patch. Please let me know which way you
prefer. Also please let me know if there's anything else you want me to
correct in changelog, patch etc.

Hopefully my work here is of some help.

If interested, here were the steps to reproduce the problem:
1. Create empty or use existing cache file i.e. ~/cache/s3.cache
2. Create a test folder with two random text files (i.e. ~/foo/file1.txt
and ~/foo/file2.txt)
3. Create a test bucket i.e.
$ python3 s3cmd mb s3://test.yourdomain.com
4. Put the files there with cache i.e.
python3 3cmd put /home/dev/foo/*.* --cache-file=/home/dev/cache/s3.cache
s3://test.yourdomain.com
5. Delete one of the text files (i.e. file2.txt)
6. Run the put command again

I intentionally put python3 at the beginning of each s3cmd invocation as my
system default is python2.

Thanks for your time to read this.

[0]
https://salsa.debian.org/robysath-guest/s3cmd/-/commit/c9d628626dc35633ecf4e97ca38ad6dda334d0a4
[1]
https://github.com/s3tools/s3cmd/commit/ee5e617c8787d39367f9b66aadee533bad346b43
[2]
https://github.com/s3tools/s3cmd/commit/ee5e617c8787d39367f9b66aadee533bad346b43.patch

Robinson

Bug#955571: spamassassin: NICE option from /etc/default/spamassassin not used by spamd processes

[Harri Suutari]

On Thu, 02 Apr 2020 20:42:49 +0300 Harri Suutari  wrote:
>
> Configuration file /etc/default/spamassassin has
>
> # Set nice level of spamd
> NICE="--nicelevel 15"
>
> but the spamd processes do not use the nice value.


I learned that the nice value actually has to be set via systemd, like
this:


# systemctl edit spamassassin.service

Text editor opens... put there:
[Service]
Nice=15

Save... it is saved to
/etc/systemd/system/spamassassin.service.d/override.conf

Restart service:
# systemctl restart spamassassin.service
or
# service spamassassin restart
or
# /etc/init.d/spamassassin restart


And the priority of the process is now lower (nicer).

--


  Harri

Bug#955527: kernelshark: Crash (SIGSEGV) when pressing the "+" button

[Boyuan Yang]

Hi,

在 2020-04-02星期四的 16:53 +0100，Sudip Mukherjee写道：
> X-Debbugs-CC: by...@debian.org
> 
> I can reproduce the problem when I have kernelshark open without any
> trace file. But the error is not seen if the trace file is opened
> using kernelshark (which is the normal usecase).
> 
> Can  you please confirm if you have seen the problem with or without a
> tracefile opened?

Indeed the issue only happens when no trace file is opened. However crashing
really should not happen in any case so I guess this bug still need to be
fixed.

-- 
Thanks,
Boyuan Yang


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

Bug#955625: ITP: node-prosemirror-markdown -- ProseMirror Markdown integration

[Abraham Raji]

Package: wnpp
Severity: wishlist
Owner: Abraham Raji 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-prosemirror-markdown
  Version : 1.4.4
  Upstream Author : 2015-2017, Marijn Haverbeke  and others
* URL : https://github.com/prosemirror/prosemirror-markdown#readme
* License : Expat
  Programming Lang: JavaScript
  Description : ProseMirror Markdown integration

ProseMirror is a well-behaved rich semantic content editor based on
contentEditable, with support for collaborative editing and custom
document schemas.
.
This module implements a ProseMirror schema that corresponds to the document
schema used by CommonMark, and a parser and serializer to convert between
ProseMirror documents in that schema and CommonMark/Markdown text.
.
This package is a dependency for node modules such as rich-markdown-editor
ngx-prosemirror and more. This is also a matured software and is not in 
alpha or beta release state.
.
I intend to package this myself but I will need sponsorship to upload. 

Bug#955626: gnome-screenshot: --clipboard does not copy into the X clipboard

[Mattia Monga]

Package: gnome-screenshot
Version: 3.36.0-1
Severity: important

I'm using Gnome with X11 and gnome-screenshot --clipboard does not copy anything
into the clipboard. Saving a file instead works fine.

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

Kernel: Linux 5.5.13 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-screenshot depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.64.1-1
ii  libgtk-3-0   3.24.16-1
ii  libx11-6 2:1.6.9-2
ii  libxext6 2:1.3.3-1+b2

gnome-screenshot recommends no packages.

gnome-screenshot suggests no packages.

-- no debconf information

Bug#955483: Alphanumeric ordering of depending sockets breaks restart

[Balint Reczey]

Hi,

On Thu, 2 Apr 2020 13:10:13 +0200 Michael Biebl  wrote:
> Am 02.04.20 um 12:45 schrieb Christian Ehrhardt:
> > On Thu, Apr 2, 2020 at 10:54 AM Michael Biebl  wrote:
> >>
> >> I don't think this is going to work.
> >>
> >> You'll need to restart both the service and socket in the correct order,
> >
> > @Michael:
> > I have tried "systemctl restart service socket socket" before and it works.
> > But I was wondering if it might work just by accident, due to the service 
> > being
> > not yet fully up when the sockets restart. And I was unsure if this
> > could be racy.
> > Are you saying this is "the right order" and this way around systemd
> > will take care
> > that service and sockets won't collide in a bad way?
>
> No, I don't know for sure.

IMO the restart of sockets worked by accident because it was OK to
restart then when the service is not running.
When the service is running systemd can't restart the socket safely
and thus IMO systemd is right denying the operation.

Systemd could implement systemctl restart -r  where it
would find what and in which order should be restarted to have a
restart of the set of units and it would do stops then starts when the
ordering required that. For example it would do stop foo.service ;
restart foo.socket; start foo.service, etc.

I think it would be very complicated or to implement that reliably in
dh_installsystemd or in deb-systemd-invoke partly because local
configuration could also impact the order and set of units to restart.
In the meantime deb-systemd-invoke could fallback to do systemctl stop
...; systemctl start when restarts fail.

Cheers,
Balint

Bug#955627: pflogsumm produces errors on postscreen lines with IPv6 address

[Juri Haberland]

Package: pflogsumm
Version: 1.1.5-5
Tags: patch ipv6

If pflogsumm encounters a postscreen reject line with an IPv6 address,
it produces the following errors:

Use of uninitialized value $domain in string eq at /usr/sbin/pflogsumm
line 1546, <> line 1.
Use of uninitialized value $rejData in hash element at
/usr/sbin/pflogsumm line 1720, <> line 1.
Use of uninitialized value $norm1 in pattern match (m//) at
/usr/sbin/pflogsumm line 1429, <> line 1.
Use of uninitialized value $norm1 in split at /usr/sbin/pflogsumm line
1434, <> line 1.

Example log line:
Apr  3 07:10:43 server postfix/postscreen[5133]: NOQUEUE: reject: RCPT
from [1234:5678::1]:56922: 450 4.3.2 Service currently unavailable;
from=, to=, proto=ESMTP,
helo=
Here is a way to reproduce the problem:
$ echo 'Apr  3 07:10:43 server postfix/postscreen[5133]: NOQUEUE:
reject: RCPT from [1234:5678::1]:56922: 450 4.3.2 Service currently
unavailable; from=, to=,
proto=ESMTP, helo=' > testlog
$ /usr/sbin/pflogsumm testlog >/dev/null


The attached patch fixes these errors.


Cheers,
  Juri
--- pflogsumm.orig	2020-04-03 12:16:50.100865258 +0200
+++ pflogsumm	2020-04-03 12:18:24.283805803 +0200
@@ -1539,7 +1539,7 @@
 unless((($domain, $ipAddr) = /^([^\[]*)\[((?:\d{1,3}\.){3}\d{1,3})\]/) == 2||
(($domain, $ipAddr) = /^([^\/]*)\/([0-9a-f.:]+)/i) == 2) {
 	# more exhaustive method
-($domain, $ipAddr) = /^([^\[\(\/]+)[\[\(\/]([^\]\)]+)[\]\)]?:?\s*$/;
+($domain, $ipAddr) = /^([^\[\(\/]*)[\[\(\/]([^\]\)]+)[\]\)]:?\d*$/;
 }
  
 # "mach.host.dom"/"mach.host.do.co" to "host.dom"/"host.do.co"

Bug#955628: pyinotify: fix the git repo

[Sandro Tosi]

Source: pyinotify
Severity: important

Hello,
pyinotify git repo is in a poor state:

- 0.9.6-1 was uploaded in 2016 but never officially made it into the repo
- there has been 2 NMUs since then, that are not in the repo (another one is
  coming in the next few minutes)
- further changes have been made to master, further diverging from the archive
  state and the git state

in order to function as a team, we need repos that are up-to-date and in sync
with the archive.

Regards,
Sandro

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

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

Bug#955629: transition: pdal

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-pdal.html
Control: block -1 by 955598

PDAL bumped its SONAME requiring a transition.

All packages except python-pdal rebuilt successfully as summarized below.

python-pdal won't be updated for PDAL 2.1, its removal from the archive
has been requested in #955598.

I would like to do this after the hdf5 transition, as soon as the mpich
blocker is resolved.


Transition: pdal

 libpdal-base9 (2.0.1+ds-1+b2) -> libpdal-base10 (2.1.0+ds-1~exp1)
 libpdal-util9 (2.0.1+ds-1+b2) -> libpdal-util10 (2.1.0+ds-1~exp1)

The status of the most recent rebuilds is as follows.

 cloudcompare (2.10.3-4)   OK
 grass(7.8.2-1)OK
 paraview (5.7.0-4)OK
 python-pdal  (2.2.2+ds-1) FTBFS


Kind Regards,

Bas

Bug#955631: dpkg-cross should mangle shlibs

[Helmut Grohne]

Package: dpkg-cross
Version: 2.6.15-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

This is a complex issue. Please take some time to understand it.

When using dpkg-cross to convert a library package it simply copies the
shlibs file. A shlibs file for libc6 for example contains the line:

libc 6 libc6 (>= 2.30)

The part after the second space is a dependency. When the original
package was e.g. libc6:mipsel, the converted package becomes
libc6-mipsel-cross:all. Now when dpkg-shlibdeps encounters a library
from libc6-mipsel-cross:all, it issues the relevant "libc6 (>= 2.30)"
dependency. However libc6-mipsel-cross:all is treated as a native
architecture (usually amd64). The inserted dependency lacks an
architecture qualifier.

The gcc-N packages need this architecture qualifier to convert them into
the usual -$arch-cross suffix. It has a cross_mangle_substvars to do
that:


https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L2203

When that suffix is missing, the issued dependency lacks the
-$arch-cross suffix. The cross-toolchain-base package takes care to
update shlibs files, see:


https://salsa.debian.org/toolchain-team/cross-toolchain-base/-/blob/master/debian/rules#L787

For doing that, cross-toolchain-base repacks the .deb twice. Once using
dpkg-cross and once using its repack target. It would make much more
sense to have this shlibs transformation inside dpkg-cross directly.

What does this mean in practise?

When you perform a toolchain bootstrap without cross-toolchain-base, you
end up without this shlibs fixup and when you build the gcc stage3 cross
compiler, you end up with support libraries with wrong dependencies:

dpkg: dependency problems prevent configuration of 
lib64atomic1-mipsel-cross:
 lib64atomic1-mipsel-cross depends on libc6-mips64 (>= 2.30); however:
  Package libc6-mips64 is not installed.

dpkg: error processing package lib64atomic1-mipsel-cross (--install):
 dependency problems - leaving unconfigured

After applying the attached patch, the generated dependencies in
multilib packages become correct. For non-multilib packages it also
happens to be wrong, but libatomic1-mipsel-cross simply depends on libc6
then. Doing so resolves to the native libc6 and dpkg is happy even when
libc6-mipsel-cross is missing.

The missing arch qualification is not a problem if you build "regular"
packages using dpkg-cross'ed packages. It only is a problem if you
attempt to produce dpkg-cross-style packages such as how gcc does it.
However, gcc nowadays is the main consumer of dpkg-cross'ed packages, so
we should make that experience painless.

So please consider applying the attached patch.

Helmut
diff --minimal -Nru dpkg-cross-2.6.15/debian/changelog 
dpkg-cross-2.6.15/debian/changelog
--- dpkg-cross-2.6.15/debian/changelog  2019-05-26 23:33:37.0 +0200
+++ dpkg-cross-2.6.15/debian/changelog  2020-04-03 15:33:57.0 +0200
@@ -1,3 +1,10 @@
+dpkg-cross (2.6.15-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Arch qualify dependencies in shlibs files. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 Apr 2020 15:33:57 +0200
+
 dpkg-cross (2.6.15-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff --minimal -Nru dpkg-cross-2.6.15/dpkg-cross dpkg-cross-2.6.15/dpkg-cross
--- dpkg-cross-2.6.15/dpkg-cross2017-07-24 17:47:10.0 +0200
+++ dpkg-cross-2.6.15/dpkg-cross2020-04-03 15:33:57.0 +0200
@@ -744,6 +744,35 @@
close(TO);
return 1;
}
+   # Helper: fix shlibs file
+   # - arch-qualify dependencies
+   sub fix_shlibs($$) {
+   my ($from, $to) = @_;
+   ensure_dir($to) or return 0;
+   if (! open(FROM, $from)) {
+   $msg = sprintf(_g("%s: failed to open %s: %s\n"), 
$progname, $from, $!);
+   warn ($msg);
+   return 0;
+   }
+   if (! open(TO, ">$to")) {
+   $msg = sprintf(_g("%s: failed to open %s for writing: 
%s\n"), $progname, $to, $!);
+   warn ($msg);
+   close(FROM);
+   return 0;
+   }
+   while () {
+   if (m/^#/) {
+   print TO;
+   } elsif (m/((?:\S+:\s*)?\S+\s+\S+\s+)(.*)/) {
+   print TO ($1 . join(",", map { s/\S+/$&:$arch/; 
$_; } split(/,/, $2)) . "\n");
+   } else {
+   print TO;
+   }
+   }
+   close(FROM);
+   close(TO);
+   return 1;
+   }
my $config = &get_config;
$crosstype = `CC="" dpkg-architecture -f -a$arch -qDEB_HOST_GNU_TYPE 2> 
/dev/null`;
chomp ($crosstype);
@@ -1089,7 +1118,7 @@
# Link the shlibs file
if (-f "$src/DEBIAN/shlib

Bug#955630: mark x11-apps Multi-Arch: foreign

[Helmut Grohne]

Package: x11-apps
Version: 7.7+8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:sugar-artwork

sugar-artwork fails to cross build from source, because it fails running
xcursorgen with an Exec format error. Usually, this hints that the
relevant package (x11-apps in this case) should be marked Multi-Arch:
foreign. I haven't checked all tools in detail but x11-apps seems to
really only contain utility programs whose descriptions generally hint
that Multi-Arch: foreign should be correct. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru x11-apps-7.7+8/debian/changelog 
x11-apps-7.7+8+nmu1/debian/changelog
--- x11-apps-7.7+8/debian/changelog 2020-02-29 00:10:29.0 +0100
+++ x11-apps-7.7+8+nmu1/debian/changelog2020-04-02 13:11:59.0 
+0200
@@ -1,3 +1,10 @@
+x11-apps (7.7+8+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark x11-apps Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 02 Apr 2020 13:11:59 +0200
+
 x11-apps (7.7+8) unstable; urgency=medium
 
   [ Andreas Henriksson ]
diff --minimal -Nru x11-apps-7.7+8/debian/control 
x11-apps-7.7+8+nmu1/debian/control
--- x11-apps-7.7+8/debian/control   2020-02-28 23:59:49.0 +0100
+++ x11-apps-7.7+8+nmu1/debian/control  2020-04-02 13:08:21.0 +0200
@@ -56,6 +56,7 @@
 
 Package: x11-apps
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}, man-db
 Recommends: xbitmaps
 Suggests: mesa-utils

Bug#955545: duplicity: The backup fails with unicode error

[Mickael Viey]

I report a bug for the last version from the official stable repository 
so I don't understand your answer.

I don't want to install all applications I use from the upstream.
First it would take me a long time to maintain all this, second I risk
getting conflicts .

If I choose to have Debian it is for this reasons. If I want  use last
version of applications I will turn towards a rolling-release
distribution. I thought Debian's goal was to provide stable and coherent
environment.


How will I update deja-dup and duplicity after install it from another
source than official repos ?

Thx


Le 03/04/2020 à 14:24, Kenneth Loafman a écrit :
> Please upgrade to the current version of duplicity.  This will assure
> that any bugs fixed since your release are available and may fix your
> issue.
>
> There are multiple options both stable and daily:
>
>  *
> Stable tarball install - https://launchpad.net/duplicity/+download
>  *
> Daily duplicity builds
> - https://launchpad.net/~duplicity-team/+archive/ubuntu/daily-dev-trunk
>
>  *
> Stable snap builds - “sudo snap install duplicity —classic"
>  *
> Latest snap builds - “sudo snap install duplicity —classic —edge"
>  *
> Latest pip builds - “sudo pip install duplicity"
>
>
> NOTE: UNinstall duplicity first if it was installed via the
> distribution repository.  For Ubuntu that would be "sudo apt-get purge
> duplicity".
>
> On Thu, Apr 2, 2020 at 5:00 AM Mickael Viey  > wrote:
>
> Package: duplicity
> Version: 0.7.18.2-1
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where
> appropriate ***
>
>    * What led up to the situation?
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    * What was the outcome of this action?
>    * What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
> Today the backup fails with an unicde error:
>
> Traceback (innermost last):
>   File "/usr/bin/duplicity", line 1567, in 
>     with_tempdir(main)
>   File "/usr/bin/duplicity", line 1553, in with_tempdir
>     fn()
>   File "/usr/bin/duplicity", line 1405, in main
>     do_backup(action)
>   File "/usr/bin/duplicity", line 1535, in do_backup
>     incremental_backup(sig_chain)
>   File "/usr/bin/duplicity", line 670, in incremental_backup
>     sig_chain.get_fileobjs())
>   File
> "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line
> 539, in get_fileobjs
>     return [filename_to_fileobj(f) for f in self.get_filenames(time)]
>   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line
> 676, in get_fileobj_read
>     self.get(filename, tdp)
>   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line
> 395, in inner_retry
>     % (n, e.__class__.__name__, util.uexc(e)))
>   File "/usr/lib/python2.7/dist-packages/duplicity/util.py", line
> 79, in
> uexc
>     return ufn(unicode(e).encode('utf-8'))
>  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> 35: ordinal not in range(128)
>
> Duplicity has worked as expected until now.
>
> Please let me know if you need some additional information.
>
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.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 duplicity depends on:
> ii  gnupg 2.2.12-1+deb10u1
> ii  libc6 2.28-10
> ii  librsync1 0.9.7-10+b1
> ii  python    2.7.16-1
> ii  python-fasteners  0.12.0-3
> ii  python-lockfile   1:0.12.2-2
>
> Versions of packages duplicity recommends:
> ii  python-oauthlib  2.1.0-1
> ii  python-paramiko  2.4.2-0.1
> ii  python-pexpect   4.6.0-1
> ii  python-urllib3   1.24.1-1
> ii  rsync    3.1.3-6
>
> Versions of packages duplicity suggests:
> pn  lftp    
> pn  ncftp   
> pn  python-boto 
> pn  python-cloudfiles   
> pn  python-gdata    
> pn  python-pip  
> pn  python-swiftclient  
> pn  tahoe-lafs  
>
> -- no debconf information
>


signature.asc
Description: OpenPGP digital signature

Bug#955632: dh-python: Unfortunate entry points processing leads to wrong interpreter dependency

[Scott Kitterman]

Package: dh-python
Version: 4.20200315
Severity: important

Currently (with python3.7 and 3.8 supported and python3.8 as default),
dh_python3 generates a python3.7 dependency for python3-pip.  This is
not needed and actively harmful.

Please see the attached verbose dh_python3 log.  It shows the entry_points.txt
file that makes it into the package is the one from python3.7, which
leads to the python3.7 dependency because of the entry point.

I can work around this by build-depending on python3 instead of
python3-all, but then the package isn't byte compiled against all
supported versions during build, so we may end up hiding problems.

Two related points:

If a version specific entry point is going to make it into the binary,
then it should be the default version.

For an arch:all package we shouldn't have version specific entry points
because that will lead to needing to rebuild the package when the
default version changes.

Currently we get the following entry points (note: we only ship the pip3
entry point):

python3.7 build:

[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.7 = pip._internal.cli.main:main

This is what makes it in the package.

python3.8 build:

[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.8 = pip._internal.cli.main:main

This would be an improvement since at least the version specific depends
would be on the default interpreter.

What I would really like to be able to do is:

[console_scripts]
pip3 = pip._internal.cli.main:main

I don't think this is urgent because I can work around the problem, but
it should be addressed at some point.

Thanks,

Scott K
dh_python3 -v
D: dh_python3 dh_python3:161: version: 4.20200315
D: dh_python3 dh_python3:162: argv: ['/usr/bin/dh_python3', '-v']
D: dh_python3 dh_python3:163: options: {'guess_deps': True, 'skip_private': 
False, 'verbose': True, 'arch': None, 'package': None, 'no_package': None, 
'compile_all': False, 'vrange': None, 'regexpr': None, 
'accept_upstream_versions': False, 'depends': None, 'depends_section': None, 
'recommends': None, 'recommends_section': None, 'suggests': None, 
'suggests_section': None, 'requires': None, 'shebang': None, 'ignore_shebangs': 
False, 'clean_dbg_pkg': True, 'no_ext_rename': False, 'no_shebang_rewrite': 
False, 'O': None}
D: dh_python3 dh_python3:164: args: []
D: dh_python3 dh_python3:165: supported Python versions: 3.7,3.8 (default=3.8)
D: dh_python3 debhelper:107: skipping package: python-pip-whl
D: dh_python3 debhelper:152: source=python-pip, binary packages=['python3-pip']
D: dh_python3 dh_python3:183: processing package python3-pip...
D: dh_python3 fs:49: moving files from 
debian/python3-pip/usr/lib/python3.7/dist-packages to 
debian/python3-pip/usr/lib/python3/dist-packages/
D: dh_python3 tools:232: invoking: /usr/bin/python3.7 -c 'import sysconfig as 
s;print("__SEP__".join(i or "" for i in s.get_config_vars("SOABI", "MULTIARCH", 
"INCLUDEPY", "LIBPL", "LDLIBRARY")))'
D: dh_python3 fs:49: moving files from 
debian/python3-pip/usr/lib/python3.8/dist-packages to 
debian/python3-pip/usr/lib/python3/dist-packages/
W: dh_python3 fs:113: Paths differ: 
debian/python3-pip/usr/lib/python3.8/dist-packages/pip-20.0.2.egg-info/entry_points.txt
 and 
debian/python3-pip/usr/lib/python3/dist-packages/pip-20.0.2.egg-info/entry_points.txt
--- 
debian/python3-pip/usr/lib/python3.8/dist-packages/pip-20.0.2.egg-info/entry_points.txt
+++ 
debian/python3-pip/usr/lib/python3/dist-packages/pip-20.0.2.egg-info/entry_points.txt
@@ -1,5 +1,5 @@
 [console_scripts]
 pip = pip._internal.cli.main:main
 pip3 = pip._internal.cli.main:main
-pip3.8 = pip._internal.cli.main:main
+pip3.7 = pip._internal.cli.main:main
 
D: dh_python3 fs:260: package python3-pip details = {'requires.txt': set(), 
'egg-info': set(), 'nsp.txt': set(), 'shebangs': {/usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3.7, /usr/bin/python3}, 'public_vers': 
{Version('3.8'), Version('3')}, 'private_dirs': {}, 'compile': True, 
'ext_vers': set(), 'ext_no_version': set()}
D: dh_python3 depends:117: generating dependencies for package python3-pip
D: dh_python3 depends:275: D={'python3:any', 'python3.7:any'}; R=[]; S=[]; 
E=[], B=[]; RT=[]
rm -f debian/python3-pip/usr/bin/pip
rm -f debian/python3-pip/usr/bin/pip3.?
rm -rf debian/python3-pip/usr/lib/python3.?

Bug#955624: [Python-modules-team] Bug#955624: python3-pip: depend on python3.8 instead of python3.7

[Scott Kitterman]

On Friday, April 3, 2020 10:57:10 AM EDT Jörg-Volker Peetz wrote:
> Package: python3-pip
> Version: 20.0.2-3
> Severity: wishlist
> 
> Dear Debian Python Modules Team,
> 
> this package is one of two on my system which still depends on
> python3.7. When is the shift to dependency on python3.8 scheduled?

This is due to an oddity in dh_python3.  Details are in Bug #955632.

I have a work-around and will include it in the next upload.

Scott K


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

Bug#937459: pyinotify: diff for NMU version 0.9.6-1.3

[Sandro Tosi]

Control: tags 937459 + patch


Dear maintainer,

I've prepared an NMU for pyinotify (versioned as 0.9.6-1.3). The diff
is attached to this message.

Regards.

diff -Nru pyinotify-0.9.6/debian/changelog pyinotify-0.9.6/debian/changelog
--- pyinotify-0.9.6/debian/changelog	2019-08-07 22:31:14.0 -0400
+++ pyinotify-0.9.6/debian/changelog	2020-04-03 12:15:30.0 -0400
@@ -1,3 +1,10 @@
+pyinotify (0.9.6-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937459
+
+ -- Sandro Tosi   Fri, 03 Apr 2020 12:15:30 -0400
+
 pyinotify (0.9.6-1.2) unstable; urgency=medium
 
   * Replace previous NMU with a new source-only upload.
diff -Nru pyinotify-0.9.6/debian/control pyinotify-0.9.6/debian/control
--- pyinotify-0.9.6/debian/control	2019-08-07 21:12:21.0 -0400
+++ pyinotify-0.9.6/debian/control	2020-04-03 12:13:58.0 -0400
@@ -3,23 +3,12 @@
 Priority: optional
 Maintainer: Mikhail Gusarov 
 Uploaders: Debian Python Modules Team 
-Build-Depends: debhelper (>= 7.0.50~), python (>= 2.6.6-3~), python3-all, dh-python
+Build-Depends: debhelper (>= 7.0.50~), python3-all, dh-python
 Standards-Version: 3.9.3
 Homepage: https://github.com/seb-m/pyinotify
 Vcs-Git: https://salsa.debian.org/python-team/modules/pyinotify.git
 Vcs-Browser: https://salsa.debian.org/python-team/modules/pyinotify
 
-Package: python-pyinotify
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Provides: ${python:Provides}
-Suggests: python-pyinotify-doc
-Description: simple Linux inotify Python bindings
- pyinotify is a simple wrapper for the Linux inotify mechanism.
- .
- inotify is a Linux Kernel feature available since 2.6.13. inotify makes
- it possible for applications to easily be notified of filesystem changes.
-
 Package: python3-pyinotify
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
@@ -37,7 +26,7 @@
 Architecture: all
 Section: doc
 Depends: ${misc:Depends}
-Recommends: python-pyinotify, python3-pyinotify
+Recommends: python3-pyinotify
 Description: simple Linux inotify Python bindings -- documentation
  pyinotify is a simple wrapper for the Linux inotify mechanism.
  .
diff -Nru pyinotify-0.9.6/debian/python3-pyinotify.install pyinotify-0.9.6/debian/python3-pyinotify.install
--- pyinotify-0.9.6/debian/python3-pyinotify.install	2019-08-07 21:12:21.0 -0400
+++ pyinotify-0.9.6/debian/python3-pyinotify.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python3
diff -Nru pyinotify-0.9.6/debian/python-pyinotify.install pyinotify-0.9.6/debian/python-pyinotify.install
--- pyinotify-0.9.6/debian/python-pyinotify.install	2019-08-07 21:12:21.0 -0400
+++ pyinotify-0.9.6/debian/python-pyinotify.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2*
diff -Nru pyinotify-0.9.6/debian/rules pyinotify-0.9.6/debian/rules
--- pyinotify-0.9.6/debian/rules	2019-08-07 21:12:21.0 -0400
+++ pyinotify-0.9.6/debian/rules	2020-04-03 12:14:32.0 -0400
@@ -1,27 +1,6 @@
 #!/usr/bin/make -f
 
-PYTHON3=$(shell py3versions -vr)
+export PYBUILD_NAME=pyinotify
 
 %:
-	dh $@ --with python2,python3
-
-override_dh_auto_clean:
-	dh_auto_clean -- --all
-
-	rm -rf build
-	rm -rf *.egg-info
-	rm -rf html
-	[ ! -e docstrings.orig ] || mv docstrings.orig docstrings
-
-build-python%:
-	python$* setup.py build
-
-override_dh_auto_build: $(PYTHON3:%=build-python%)
-	dh_auto_build
-
-install-python%:
-	python$* setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb
-
-override_dh_auto_install: $(PYTHON3:%=install-python%)
-	dh_auto_install
-	[ ! -e docstrings ] || mv docstrings docstrings.orig
+	dh $@ --with python3 --buildsystem=pybuild

Bug#955527: kernelshark: Crash (SIGSEGV) when pressing the "+" button

[Sudip Mukherjee]

Hi,

On Fri, Apr 3, 2020 at 4:21 PM Boyuan Yang  wrote:
>
> Hi,
>
> 在 2020-04-02星期四的 16:53 +0100，Sudip Mukherjee写道：
> > X-Debbugs-CC: by...@debian.org
> >
> > I can reproduce the problem when I have kernelshark open without any
> > trace file. But the error is not seen if the trace file is opened
> > using kernelshark (which is the normal usecase).
> >
> > Can  you please confirm if you have seen the problem with or without a
> > tracefile opened?
>
> Indeed the issue only happens when no trace file is opened. However crashing
> really should not happen in any case so I guess this bug still need to be
> fixed.

Yes, totally agreed. Its not reproducible on upstream. But since
latest upstream is still in -rc, I dont want to package that yet. I
will find out what has fixed the problem upstream and add it here (for
now). I am also waiting for another fix from upstream for a bug
reported in Ubuntu.

-- 
Regards
Sudip

Bug#917924: nm-tray missing icons

[Sofus Rose]

Package: nm-tray
Version: 0.4.2-1
Release: buster

Cheers,

I'm having the exact same issue, and the tray has no icons - but in my
case, I'm running i3wm (no desktop environment):

% nm-tray
QSystemTrayIcon::setVisible: No Icon set


As suggested, I ran strace and confirmed that missing images in
/usr/share/pixmaps are indeed the issue. I ran the following command:

% strace nm-tray 2>&1 | cat - > output

In this strace, I was able to narrow down exactly what was missing by
searching for "pixmaps":

% sed -n 1861p output

statx(AT_FDCWD, "/usr/share/pixmaps", AT_STATX_SYNC_AS_STAT,
STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0,
stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0

% sed -n 1862,1864p output

access("/usr/share/pixmaps/preferences-system-network.png", F_OK) = -1
ENOENT (No such file or directory)
access("/usr/share/pixmaps/preferences-system-network.xpm", F_OK) = -1
ENOENT (No such file or directory)
access("/usr/share/pixmaps/preferences-system-network.svg", F_OK) = -1
ENOENT (No such file or directory)

% sed -n 2269,2271p output

access("/usr/share/pixmaps/network-transmit.png", F_OK) = -1 ENOENT
(No such file or directory)
access("/usr/share/pixmaps/network-transmit.xpm", F_OK) = -1 ENOENT
(No such file or directory)
access("/usr/share/pixmaps/network-transmit.svg", F_OK) = -1 ENOENT
(No such file or directory)

% sed -n 2914,2919p output

access("/usr/share/pixmaps/network-wireless-signal-good-symbolic.png",
F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/pixmaps/network-wireless-signal-good-symbolic.xpm",
F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/pixmaps/network-wireless-signal-good-symbolic.svg",
F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/pixmaps/network-wireless-connected-75-symbolic.png",
F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/pixmaps/network-wireless-connected-75-symbolic.xpm",
F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/pixmaps/network-wireless-connected-75-symbolic.svg",
F_OK) = -1 ENOENT (No such file or directory)

To summarize, the following icons (other than a cursor icon which
seems perhaps to have been found) were searched for:

- /usr/share/pixmaps/preferences-system-network.(png|xpm|svg)
- /usr/share/pixmaps/network-transmit.(png|xpm|svg)
- /usr/share/pixmaps/network-wireless-signal-good-symbolic.(png|xpm|svg)
- /usr/share/pixmaps/network-wireless-connected-75-symbolic.(png|xpm|svg)

A run of `apt-file find preferences-system-network.png`, just the
first one, yields a lot of icon themes - all of them in
`/usr/share/icons` (as they should be!).

Is this fixed in 0.4.3-2?

Kind Regards,
Sofus Rose

Bug#955633: terminus: Terminals use bash hardcoded instead of user's configured login shell

[Axel Beckert]

Package: terminus
Version: 1.8.0-1

Hi,

if I start up terminus it shows me with a bash prompt i.e. seems to run
/bin/bash instead of the expected zsh prompt by running my login shell
as configured in /etc/passwd.

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages terminus depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libc62.30-4
ii  libcairo21.16.0-4
ii  libgee-0.8-2 0.20.3-1
ii  libglib2.0-0 2.64.1-1
ii  libglib2.0-bin   2.64.1-1
ii  libgtk-3-0   3.24.16-1
ii  libkeybinder-3.0-0   0.3.2-1+b1
ii  libpango-1.0-0   1.44.7-3
ii  libvte-2.91-00.60.1-1

terminus recommends no packages.

terminus suggests no packages.

-- no debconf information

Bug#955634: RM: pygtk -- RoQA; Obsolete, dead upstream, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pygtk. It depends on Python 2 and is dead upstream (last
release in 2011).

All remaining rdeps have been ported to GI/gtk3 or were removed, except
these four, but please force the removal at this point, they are all dropped
from testing for a while as well:

chirp - gi/py3 branch WIP, but not yet ready, Christoph Berg is working
   on it (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885265#49)
coccinelle - Upload pending for this weekend
  (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885267#37)
mirage (Thomas Ross is porting it to gi/py3, but not yet ready to upload)
wicd (WIP port in experimental, but not yet in a usable state)

Cheers,
Moritz

Bug#955635: purple-discord: Crashes in ssl_nss_read

[Samuel Thibault]

Package: purple-discord
Version: 0.9.2020.03.10.git.4e71974-1
Severity: important

Hello,

I have been using purple-discord permanently in the past couple weeks,
and I have been hit by a crash several times:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f94a4dd655b in __GI_abort () at abort.c:79
#2  0x55d5cf6bbe6c in sighandler (sig=) at 
././pidgin/gtkmain.c:179
#3  sighandler (sig=) at ././pidgin/gtkmain.c:162
#4  0x7f94a4dec7e0 in  () at 
/lib/x86_64-linux-gnu/libc.so.6
#5  0x7f949fb2a4a5 in ssl_nss_read (gsc=0x55d5d0d3ae30, 
data=0x55d5d0d3ab40, len=1) at ././libpurple/plugins/ssl/ssl-nss.c:532
#6  0x7f949faf8a33 in discord_socket_got_data (userdata=0x55d5d0d3aad0, 
conn=0x55d5d0d3ae30, cond=) at libdiscord.c:4501
#7  0x55d5cf6a31e2 in pidgin_io_invoke (source=, 
condition=, data=0x55d5d148e6f0) at ././pidgin/gtkeventloop.c:73
#8  0x7f94a52704de in g_main_dispatch (context=0x55d5d066a750) at 
../../../glib/gmain.c:3309
#9  g_main_context_dispatch (context=context@entry=0x55d5d066a750) at 
../../../glib/gmain.c:3974
#10 0x7f94a5270890 in g_main_context_iterate (context=0x55d5d066a750, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4047
#11 0x7f94a5270b63 in g_main_loop_run (loop=0x55d5d0d3b0a0) at 
../../../glib/gmain.c:4241
#12 0x7f94a574c12a in IA__gtk_main () at ../../../../gtk/gtkmain.c:1270
#13 0x55d5cf668970 in main (argc=, argv=) at 
././pidgin/gtkmain.c:939
(gdb) frame 5
#5  0x7f949fb2a4a5 in ssl_nss_read (gsc=0x55d5d0d3ae30, 
data=0x55d5d0d3ab40, len=1) at ././libpurple/plugins/ssl/ssl-nss.c:532
532 ././libpurple/plugins/ssl/ssl-nss.c: Aucun fichier ou dossier de ce 
type.
(gdb) p gsc->private_data
$4 = (void *) 0x0

I have never had such issue in the past years with pidgin, so it very
most probably is due to the discord plugin (and the backtrace suggests
so too)

It seems that somehow discord_socket_got_data passes an improper
connection, I used the attached browntape patch in pidgin to at least
avoid the issue by returning an error instead of crashing my whole
pidgin.

Samuel

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

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

Versions of packages purple-discord depends on:
ii  libc6   2.30-2
ii  libglib2.0-02.64.1-1
ii  libjson-glib-1.0-0  1.4.4-2
hi  libpurple0  2.13.0-2.2+fix

And additionally:

ii  pidgin  2.13.0-2.2+fix amd64graphical multi-protocol in>
ii  pidgin-data 2.13.0-2.2+fix all  multi-protocol instant mess>
ii  pidgin-dbgsym   2.13.0-2.2+fix amd64debug symbols for pidgin

purple-discord recommends no packages.

Versions of packages purple-discord suggests:
pn  python3-harmony  

-- no debconf information
---
 libpurple/plugins/ssl/ssl-nss.c |8 
 1 file changed, 8 insertions(+)

--- a/libpurple/plugins/ssl/ssl-nss.c
+++ b/libpurple/plugins/ssl/ssl-nss.c
@@ -529,10 +529,18 @@ ssl_nss_read(PurpleSslConnection *gsc, v
PRInt32 ret;
PurpleSslNssData *nss_data = PURPLE_SSL_NSS_DATA(gsc);
 
+   if (!nss_data)
+   {
+   ret = -1;
+   errno = EFAULT;
+   }
+   else
+   {
ret = PR_Read(nss_data->in, data, len);
 
if (ret == -1)
set_errno(PR_GetError());
+   }
 
return ret;
 }

Bug#928767: pip regression

[Scott Kitterman]

On Fri, 10 May 2019 19:30:58 +0200 =?UTF-8?Q?Josu=c3=a9_Tille?= 
 wrote:
> Package: python-pip
> 
> Hello,
> 
> 
> 
> Debian version : 9.9
> 
> probable package : python-pip 9.0.1-2+deb9u1
> 
> 
> I detected that since some days the install of package with pip fail
> randomly with this stacktrace:
> 
...
> After some research I found that this patch have been applied to pip :
> https://sources.debian.org/patches/python-pip/9.0.1-2+deb9u1/Properly_catch_
> requests_HTTPError_in_index.py.patch/
> 
> I suspect that this patch break something.
...

I don't believe that was the problem.  It was a backport of an upstream change 
that is still in use.

This problem does not occur with the version in Debian Unstable, so I am going 
to close the bug.

Scott K

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

Bug#892744: python3-pip: breaks with venv --system-site-packages

[Scott Kitterman]

On Mon, 12 Mar 2018 14:53:11 +0100 Bernhard Reiter  
wrote:
> Package: python3-pip
> Version: 9.0.1-2
> Severity: normal
> 
> Hi Maintainers,
> 
> according to `pip help install`::
> 
>   --user
> [..]
>   On Debian systems, this is the default when running outside of a
>   virtual environment and not as root.
> 
> However when using the recommended virtual environment `venv`,
> the detection does not work. Example:
> 
>python3 -m venv --system-site-packages x_env
>. x_env/in/activate.fish
>pip install vdirsyncer
> 
> will end up with installed files
> in .local/bin and .local/lib/python3.5/site-packages/
> While they should have been below x_env.
> 
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876145
> the problems is also mentioned.

Looking at how #876145 was resolved, it should have taken care of this too.  
If you can still reproduce this problem in Debian 10 (Buster), please reopen.

Scott K

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

Bug#955636: build dependency on python-doc

[Matthias Klose]

Package: python-pykka
Severity: serious
Tags: sid bullseye patch
User: debian-pyt...@lists.debian.org
Usertags: py2removal

the package still build-depends on python-doc, while it depends on python3 for
everything else.

patch at
http://launchpadlibrarian.net/472673858/python-pykka_2.0.2-5_2.0.2-5ubuntu1.diff.gz

Bug#955583: ruby-defaults breaks ruby-mousetrap-rails autopkgtest: TypeError: no implicit conversion of String into Integer

[Paul Gevers]

Hi Antonio,

On 03-04-2020 15:38, Antonio Terceiro wrote:
>> Bundle complete! 19 Gemfile dependencies, 77 gems now installed.
>> Use `bundle info [gemname]` to see where a bundled gem is installed.
>> + bundle exec rake assets:precompile
>> rake aborted!
>> TypeError: no implicit conversion of String into Integer
> 
> I was debugging this, and it turns out this is caused by ruby-bootsnap
> from testing. However, ruby-bootsnap is a dependency of rails, which
> used in the test, not of the packages being tested.
> 
> I went to check the migration status of ruby-bootsnap, but its migration
> depends on the migration of src:ruby-defaults itself. So we have a
> circular dependency.

Do I understand correctly that you are saying that ruby-defaults broke
ruby-bootsnap?

> I detected at least another packages failing in the exact same way. Is
> the fix for this declaring Breaks: in ruby-defaults?

Yes, if it indeed ruby-defaults that breaks ruby-bootsnap. However, I
think it's more technically correct that ruby2.7 breaks it, no? I guess
in practice, either is fine.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#954898: bug#954898

[Andrea Corallo]

I experience the same on i386.

Running under valgrind I get an "Invalid read of size 4".  I have
installed libgccjit-10-dev/testing,now 10-20200324-1 i386

Compiling from the vanilla repositiory is working fine for me.

Andrea

-- 
a...@sdf.org

Bug#877464: git-remote-gcrypt: git push always behaves as if --force is given

[montag451]

Hi,

A solution could be the use of --force-with-lease instead of --force. It 
would prevent the behavior observed by the OP.


BR

---

montag451

Bug#955211: release.debian.org: Transition r-base for 4.0.0

[Graham Inggs]

Hi Dirk

On Sat, 28 Mar 2020 at 15:57, Dirk Eddelbuettel  wrote:
> R does change internals every now and then with the annual releases; this is
> a major one which will require rebuilds of all packages.

I've set up a transition tracker [1] where we can see the magnitude of
the transition.
Packages marked [arch:all] will need uploads by the team / maintainer,
the rest can be handled by binNMU.

> R 4.0.0 will be released on April 24. The upstream team always follows a
> well-publicised schedule

>From the schedule [2]:

* Tuesday 2020-03-24: START
* Friday 2020-03-27: GRAND-FEATURE FREEZE (4.0.0 alpha)
* Friday 2020-04-10: FEATURE FREEZE (4.0.0 beta)
* Friday 2020-04-17: CODE FREEZE (4.0.0 RC)
* Tuesday 2020-04-21: PRERELEASE
* Friday 2020-04-24: RELEASE (4.0.0)

I read on the debian-r mailing list that a parallel transition of
Bioconductor will also be needed [3].
Would there be any point to starting the r-base transition much before
the release of Bioconductor (2020-04-28)?
Please keep this bug in replies.

Regards
Graham


[1] https://release.debian.org/transitions/html/r-api-4.0.html
[2] https://developer.r-project.org
[3] https://lists.debian.org/debian-r/2020/04/msg0.html

Bug#955637: ITS: font-manager

[Boyuan Yang]

Source: font-manager
Version: 0.7.7-0.3
Severity: important
X-Debbugs-CC: ales...@debian.org mulev...@gmail.com

Dear package font-manager maintainers in Debian,

After looking into the package you maintain (font-manager, 
https://tracker.debian.org/pkg/font-manager), I found that this package
received no maintainer updates for 3 years and was not in good shape. As a
result, I am filing an ITS (Intent to Salvage) request against your package
according to section 5.12 in Debian's Developers' Reference [1].

Please let me know if you are still willing to maintain this package.
According to the criteria listed at [2], I will upload a Non-maintainer Upload
(NMU) of font-manager onto DELAYED/7 after 21 days (Apr. 24, 2020) to continue
with the package salvaging. If it's necessary to pause the ITS process, please
let me know immediately by replying this bug report.

My current plan is to have this package team-maintained under Debian Fonts
Team (debian-fo...@lists.debian.org). The maintainer will be set to the team
and the uploader field will be set to myself. However, the following solutions
are also available:

* Revert the maintenance information to original form as of 2019
* Keep the maintenance information as-is
* Set the maintainer to be the team and move everyone else into Uploaders
field


If you find it necessary to choose any of the options, please let me know
immediately by replying to this bug report as well as replying me. Thanks!

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#916267: libgtk-3-0: Cannot print to IPP printers from the GTK dialog

[Brian Potkin]

On Thu 02 Apr 2020 at 16:42:08 +0100, Simon McVittie wrote:

> Version: 3.24.13-1
> 
> On Wed, 12 Dec 2018 at 11:20:04 +, Brian Potkin wrote:
> > An IPP printer is allocated the destination "print" in the dialog and
> > is tagged as "Rejecting Jobs". This is irrespective of whether its TXT
> > record pdl key has application/PDF in it or not.
> 
> This appears to have been fixed in GTK3 version 3.24.13 upstream, so it
> should now work in testing/unstable. Debian 10 'buster' is still affected.

With libgtk-3-0:i386 version 3.24.16-1, my printer is now identified as
ENVY4500 on Firefox, Evince and gedit. That's a change but the Status is
"Getting printer information... . There is no progress with being able
to print to the device.
 
> After removing cups-browsed and restarting cups, my printer still shows
> up in the Print dialog for gedit and Firefox.

I have stopped cups-browsed. This prevents any auto-setup of network
queues and printers as *local* queues. Local queues are handled through
CUPS on the client.

I have also stopped the CUPS service; network queues and printers are
dealt with by the GTK print dialog without CUPS and cups-filters. In
the case of queues the job (a PDF) is processed on the remote server.

The same PDF would be sent (or would be attempted to be sent) to an IPP
printer. My ENVY4500 will not accept a PDF as application/pdf is not a
PDL it is capable of processing. Your experience may be different, but
then we would have to know more about your printer. In the case of
successful printing, the output from

 avahi-browse -rt _ipp._tcp

would be of interest.

> > Furthermore, the dialog
> > seems incapable of displaying more than one entry for IPP printers on
> > the network.
> 
> Hopefully this was a side-effect of them all having incomplete information
> (all being named "print" is another symptom of that). If you have access
> to more than one IPP printer, please could you try with a testing/unstable
> system *without* cups-browsed, then retry *with* cups-browsed? I only have
> one IPP printer, so I can't tell what happens with more than one.
> 
> The ideal result is that you get one entry for each IPP printer on your
> network, with or without cups-browsed installed.
> 
> The next best thing is that you get one entry for each IPP printer
> (without cups-browsed) or two entries for each IPP printer (with
> cups-browsed). If you get duplicates with cups-browsed installed, then
> that would indicate that the code that is meant to eliminate duplicates
> isn't working.

I have only one IPP printer too. However, I set up a simulated IPP
printer on a buster machine with ippserver. The dialog displayed it
under the name I gave it.

Cheers,

Bug#955545: Acknowledgement (duplicity: The backup fails with unicode error)

[Mickael Viey]

So I have investigated and I found where the problem comes from. It was
my FTP server which stopped working. I don't know what kind of error
this problem raise in python because the function which try to display
the error fails with the UnicodeDecodeError I show on the original
report. So the malfunction comes from the environment.

Howeverfinding the cause was difficult because the code supposed to
display the error fails on the decoding error making the error message
not very explicit.

I hope duplicity 0.8 will fix the issue as it relies on py3. You can
close this report or keep it open see if the issue is resolved in future
debian version.


Thx,


Regards

Le 02/04/2020 à 12:00, Debian Bug Tracking System a écrit :
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 955545: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955545.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Alexander Zangerl 
>
> If you wish to submit further information on this problem, please
> send it to 955...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>


signature.asc
Description: OpenPGP digital signature

Bug#955583: ruby-defaults breaks ruby-mousetrap-rails autopkgtest: TypeError: no implicit conversion of String into Integer

[Antonio Terceiro]

On Fri, Apr 03, 2020 at 07:58:03PM +0200, Paul Gevers wrote:
> Hi Antonio,
> 
> On 03-04-2020 15:38, Antonio Terceiro wrote:
> >> Bundle complete! 19 Gemfile dependencies, 77 gems now installed.
> >> Use `bundle info [gemname]` to see where a bundled gem is installed.
> >> + bundle exec rake assets:precompile
> >> rake aborted!
> >> TypeError: no implicit conversion of String into Integer
> > 
> > I was debugging this, and it turns out this is caused by ruby-bootsnap
> > from testing. However, ruby-bootsnap is a dependency of rails, which
> > used in the test, not of the packages being tested.
> > 
> > I went to check the migration status of ruby-bootsnap, but its migration
> > depends on the migration of src:ruby-defaults itself. So we have a
> > circular dependency.
> 
> Do I understand correctly that you are saying that ruby-defaults broke
> ruby-bootsnap?
> 
> > I detected at least another packages failing in the exact same way. Is
> > the fix for this declaring Breaks: in ruby-defaults?
> 
> Yes, if it indeed ruby-defaults that breaks ruby-bootsnap. However, I
> think it's more technically correct that ruby2.7 breaks it, no? I guess
> in practice, either is fine.

Yes, that's what I meant

Package: ruby
Breaks: ruby-bootsnap (<< SID)


signature.asc
Description: PGP signature