Bug#955555: gitlab: uninitialized constant APIGuard

[Dragos Jarca]

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.


root@a:~# apt install gitlab/experimental
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '12.8.8-4' (Debian:experimental [all]) for 'gitlab'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gitlab : Depends: ruby-unicode-plot but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@a:~# apt-show-versions -a ruby-unicode-plot
No oldstable version
No stable version
No testing version
No testing-updates version
ruby-unicode-plot:all 0.0.4-1 unstable ftp.debian.org
No experimental version
ruby-unicode-plot:all not installed
root@a:~# apt install ruby-unicode-plot
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ruby-unicode-plot : Depends: ruby-enumerable-statistics (>= 2.0.1) but 
it is not installable

E: Unable to correct problems, you have held broken packages.
root@a:~# apt-show-versions -a ruby-enumerable-statistics
ruby-enumerable-statistics not installed (not available)

More, now redmine is uninstalled because of ruby-actionpack-xml-parser.

Thx,

Dragos Jarca


On 02.04.2020 19:35, Pirate Praveen wrote:


Control: fixed -1 12.8.6-1

On 2020, ഏപ്രിൽ 2 8:05:53 PM IST, Dragos Jarca  
wrote:

Package: gitlab
Version: 12.6.8-3
Severity: grave
Tags: a11y
Justification: renders package unusable

Dear Maintainer,

I upgraded packages:

Start-Date: 2020-04-02  10:00:27
Commandline: apt-get dist-upgrade
Install: libllvm10:amd64 (1:10.0.0-1, automatic), ruby-sync:amd64
(0.5.0-2, automatic)
Upgrade: libpython3.7-minimal:amd64 (3.7.7-1, 3.7.7-1+b1),
python3-werkzeug:amd64 (0.16.1+dfsg1-1, 0.16.1+dfsg1-2),
glib-networking-services:amd64 (2.64.0-1, 2.64.1-1),
libpython3.8-dbg:amd64 (3.8.2-1, 3.8.2-1+b1), libpython3.8-dev:amd64
(3.8.2-1, 3.8.2-1+b1), php-phpseclib:amd64 (2.0.25-1, 2.0.26-1),
libgirepository-1.0-1:amd64 (1.62.0-5+b1, 1.64.0-2),
libpython3.8-minimal:amd64 (3.8.2-1, 3.8.2-1+b1), glib-networking:amd64

(2.64.0-1, 2.64.1-1), dash:amd64 (0.5.10.2-6, 0.5.10.2-7),
ruby-memoist:amd64 (0.16.2-1, 0.16.2-2), ruby-tins:amd64 (1.1.0-1,
1.1.0-2), libhiredis0.14:amd64 (0.14.0-6, 0.14.1-1), libffi-dev:amd64
(3.3-3, 3.3-4), libdbd-pg-perl:amd64 (3.10.4-1, 3.10.5-1),
yarnpkg:amd64
(1.19.1-1, 1.21.1-2), nodejs:amd64 (10.17.0~dfsg-2, 10.19.0~dfsg-3),
libpython3.8:amd64 (3.8.2-1, 3.8.2-1+b1), python3.7:amd64 (3.7.7-1,
3.7.7-1+b1), python3.8:amd64 (3.8.2-1, 3.8.2-1+b1),
ruby-mini-magick:amd64 (4.9.2-1.1, 4.9.5-2), bubblewrap:amd64 (0.4.0-1,

0.4.1-1), node-d3-quadtree:amd64 (1.0.6-2, 1.0.7-1), libpq5:amd64
(12.2-1+b1, 12.2-4), libpython3.7-stdlib:amd64 (3.7.7-1, 3.7.7-1+b1),
glib-networking-common:amd64 (2.64.0-1, 2.64.1-1),
python3.7-minimal:amd64 (3.7.7-1, 3.7.7-1+b1),
ruby-state-machines-activemodel:amd64 (0.5.1-3, 0.7.1-2),
libpq-dev:amd64 (12.2-1+b1, 12.2-4), npm:amd64 (6.14.2+ds-2,
6.14.3+ds-1), python3-future:amd64 (0.18.2-1, 0.18.2-2),
postgresql-12:amd64 (12.2-1+b1, 12.2-4), gir1.2-glib-2.0:amd64
(1.62.0-5+b1, 1.64.0-2), python3.8-minimal:amd64 (3.8.2-1, 3.8.2-1+b1),

python3-acme:amd64 (1.1.0-1, 1.3.0-2), libconfuse-common:amd64
(3.2.2+dfsg-1, 3.2.2+dfsg-2), ruby-omniauth:amd64 (1.9.0-1, 1.9.1-1),
shared-mime-info:amd64 (1.10-1, 1.15-1), libnode-dev:amd64
(10.17.0~dfsg-2, 10.19.0~dfsg-3), libwnck-3-0:amd64 (3.32.0-1,
3.36.0-1), ruby-warden:amd64 (1.2.3-2, 1.2.8-1),
libpython3.8-stdlib:amd64 (3.8.2-1, 3.8.2-1+b1), libnode64:amd64
(10.17.0~dfsg-2, 10.19.0~dfsg-3), libwnck-3-common:amd64 (3.32.0-1,
3.36.0-1), libpcap0.8:amd64 (1.9.1-2, 1.9.1-3), libffi7:amd64 (3.3-3,
3.3-4), python3.8-dbg:amd64 (3.8.2-1, 3.8.2-1+b1), python3.8-dev:amd64
(3.8.2-1, 3.8.2-1+b1), libconfuse2:amd64 (3.2.2+dfsg-1, 3.2.2+dfsg-2),
postgresql-client-12:amd64 (12.2-1+b1, 12.2-4)
End-Date: 2020-04-02  10:05:57

Start-Date: 2020-04-02  10:14:16
Commandline: apt-get -t unstable install gitlab-shell
Upgrade: gitlab-shell:amd64 (10.3.0+debian-3.1, 11.0.0+debian-2)
End-Date: 2020-04-02  10:14:37

After that gitlab stop starting.

The error is:

rake aborted!
NameError: uninitialized constant APIGuard

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

[Stéphane Glondu]

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

> I'm not using the gtksourceview2 part, so dropping that would be OK for me.

I am planning to disable the gtksourceview2 part of lablgtk2 when
lablgtk2 effectively leaves testing. I am waiting, because I already
disabled it once, and gtksourceview2 maintainers changed their mind, and
I had to re-enable it. I don't want to disable/enable it again so I want
to be sure that gtksourceview2 has effectively left testing before doing it.

> What do you recommend?

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.


Cheers,

-- 
Stéphane

Bug#955577: RFP: FFT Spectra -- Tool for visualization of frequency spectra of an audio signal.

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: retitle -1 RFP: fft-spectra -- tool for visualization of frequency 
spectra of an audio signal

On Jo, 02 apr 20, 20:49:52, Ben Tris wrote:
> Package: fft-spectra
> Severity: wishlist
> 
> C   GPL2
> 
> http://fft-spectra.sourceforge.net/
> 
> https://sourceforge.net/projects/fft-spectra/
> 


-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature

Bug#954823: hydrogen: Qt5 version available

[Jaromír Mikeš]

Hi Alexandre,

I am former maintainer of this package but not active any more.

please contact Debian multimedia team to get help with this issue.
https://wiki.debian.org/DebianMultimedia
https://lists.debian.org/debian-multimedia/
Or even join it if you want to work on it.
https://wiki.debian.org/DebianMultimedia/Join

hope this helps

mira



On Thu, Apr 2, 2020, 7:15 PM Alexandre Lymberopoulos 
wrote:

> Package: hydrogen
> Version: 0.9.7-6
> Followup-For: Bug #954823
>
> Dear Maintainer,
>
> Confirming that 1.0.0-beta2 is avaliable at
>
> 
>
> Is any help needed to package this new version. If so, I could help,
> but need some guidance on this.
>
> Thanks is advance,
> Alexandre
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (800, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages hydrogen depends on:
> ii  hydrogen-data 0.9.7-6
> ii  libarchive13  3.4.0-2
> ii  libasound21.2.2-2.1
> ii  libc6 2.30-2
> ii  libgcc-s1 [libgcc1]   10-20200324-1
> ii  libgcc1   1:10-20200324-1
> ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
> ii  libportaudio2 19.6.0-1
> ii  libportmidi0  1:217-6
> ii  libpulse0 13.0-5
> ii  libqt4-network4:4.8.7+dfsg-20
> ii  libqt4-xml4:4.8.7+dfsg-20
> ii  libqt4-xmlpatterns4:4.8.7+dfsg-20
> ii  libqtcore44:4.8.7+dfsg-20
> ii  libqtgui4 4:4.8.7+dfsg-20
> ii  libsndfile1   1.0.28-7
> ii  libstdc++610-20200324-1
> ii  zlib1g1:1.2.11.dfsg-2
>
> Versions of packages hydrogen recommends:
> pn  hydrogen-doc   
> ii  hydrogen-drumkits  2017.09.19~dfsg-1
> pn  rubberband-cli 
>
> Versions of packages hydrogen suggests:
> pn  ladspa-plugin  
>
> -- no debconf information
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#955598: RM: python-pdal -- ROM; Cannot be updated

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove python-pdal from the archive, it cannot be updated for PDAL 2.1.0.

Kind Regards,

Bas

Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>

[Justin Erenkrantz]

On Thu, Apr 2, 2020 at 8:06 AM James McCoy  wrote:

> Just as an FYI, the OpenSSL changes have been partially reverted[1]
> upstream for the 1.1.1f release.  The change will be re-introduced in
> 3.0, so using the ifdef, instead of OpenSSL version, was the prudent
> choice.
>

Thanks for the update.  I'm guessing Debian Sid will just jump to OpenSSL
1.1.1f and we'll all pretend that 1.1.1e never happened.  =)

I think this takes some of the pressing nature to get a 1.3.10 out the
door.  That said, I'm trying to go down the rabbit hole of becoming
friendly with all of the cmake environments...it'll probably take me a fair
bit of time to get comfortable enough to cut a 1.4.x release that uses
cmake as the primary build system.  (I finally got my VS 2019 in a state
tonight where it can now build the dependency chains...)

Cheers.  -- justin

Bug#955597: obs-plugins: [Whishlist] Please provide obs-xdg-portal as a plugin

[Santiago Batista]

Package: obs-plugins
Version: 25.0.3+dfsg1-2
Severity: wishlist

Dear Maintainer,

Within a Wayland session, currently obs-studio is unable to screencast the
screen or native Wayland windows.

The requested plugin provides this feature.

Source: https://gitlab.gnome.org/feaneron/obs-xdg-portal
More info: 
https://feaneron.com/2019/11/21/screencasting-with-obs-studio-on-wayland/

Apparently this feature depends on pipewire 0.3 (which is still not available in
Debian, coming up soon hopefully,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954022).

Thank you for your effort and consideration.

Best regards

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

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

Versions of packages obs-plugins depends on:
ii  libasound21.2.2-2.1
ii  libavcodec58  7:4.2.2-1+b1
ii  libavdevice58 7:4.2.2-1+b1
ii  libavformat58 7:4.2.2-1+b1
ii  libavutil56   7:4.2.2-1+b1
ii  libc6 2.30-4
ii  libcurl3-gnutls   7.68.0-1
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10-20200324-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjansson4   2.12-1
ii  libmbedcrypto32.16.5-1
ii  libmbedtls12  2.16.5-1
ii  libmbedx509-0 2.16.5-1
ii  libobs0   25.0.3+dfsg1-2
ii  libpulse0 13.0-5
ii  libqt5core5a  5.12.5+dfsg-9
ii  libqt5gui55.12.5+dfsg-9
ii  libqt5widgets55.12.5+dfsg-9
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libstdc++610-20200324-1
ii  libswscale5   7:4.2.2-1+b1
ii  libudev1  244.3-1
ii  libv4l-0  1.18.0-2
ii  libx11-6  2:1.6.9-2
ii  libx264-155   2:0.155.2917+git0a84d98-2
ii  libxcb-randr0 1.14-2
ii  libxcb-shm0   1.14-2
ii  libxcb-xfixes01.14-2
ii  libxcb-xinerama0  1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.4-2
ii  libxfixes31:5.0.3-1
ii  python3   3.8.2-2

Versions of packages obs-plugins recommends:
pn  vlc  

obs-plugins suggests no packages.

-- no debconf information

Bug#950994: Discourage package in contrib to install the real program via another package manager

[Olek Wojnar]

Hi,

Sorry for the slow reply, life has been interesting recently...

On Fri, Feb 14, 2020 at 2:26 PM Shengjing Zhu  wrote:

> 
>
> May not answer you question directly.
>
> There's something called software center. Like discover[1] for KDE plasma,
> gnome-software[2] for GNOME.
>
> Users can install either debian package, or flatpak, or snap apps.
>
> [1] https://tracker.debian.org/pkg/plasma-discover
> [2] https://tracker.debian.org/pkg/gnome-software


Ah, yes. That sounds familiar. Maybe this should be the location to
implement that functionality, and implement it upstream. Maybe such a
functionality could be shared and eventually integrated into aptitude and
even apt itself.

My primary concern is to prevent disruption to users. That's a
philosophical issue far beyond the two packages of mine that are currently
impacted. If these software centers were able to smartly suggest a
different source for a software package in a situation where that package
was removed from the source the user was currently using, that would
certainly address my concerns. It would make life easier for me as well
because then I would just outright remove my problem packages from Debian
without fear of negatively impacting users. (I've been on the receiving end
of that impact a couple times and it was unpleasant to suddenly realize
that a system upgrade made me lose a piece of software that I routinely
use.)

-Olek

Bug#955596: python-h5netcdf: h5py.File needs access mode specified

[Drew Parsons]

Source: python-h5netcdf
Version: 0.7.1-1
Severity: serious
Justification: debci

h5py.File opens 'r' by default, so you need to specify other modes
such as 'w' if needed

e.g. test_optional_netcdf4_attrs[testfile.nc]
  with h5.File(tmp_local_or_remote_netcdf, 'w') as f:
instead of
  with h5.File(tmp_local_or_remote_netcdf) as f:
if needed for writing.


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

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

Bug#955549: f2fs-tools: fsck.f2fs segfaults

[Adam Borowski]

On Thu, Apr 02, 2020 at 03:16:58PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Apr 02, 2020 at 02:01:26PM +0200, Adam Borowski wrote:
> >
> > After a lot of output on a damaged filesystem (SD card copied to an image)
> > fsck.f2fs dies with:
> > 
> >  - File name : mkfs.ext3.dpkg-new
> >  - File size : 6 (bytes)
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x93ec in memcpy (__len=18446744073323892736, 
> > __src=0x5560760c, __dest=0x7fffe000) at 
> > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> > 34return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));

> > #0  0x93ec in memcpy (__len=18446744073323892736, 
> > __src=0x5560760c, __dest=0x7fffe000) at 
> > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> > #1  convert_encrypted_name (name=name@entry=0x5560760c " ", 
> > len=-385658880, new=new@entry=0x7fffe000 " ", enc_name=) 
> > at fsck.c:1132
> > #2  0x55562286 in print_inode_info (sbi=0x5557db20 , 
> > node=0x556075b0, name=1) at mount.c:183
> > #3  0x55562a46 in print_node_info (sbi=, 
> > node_block=, verbose=) at mount.c:277
> > #4  0x55560d3f in dump_node (sbi=sbi@entry=0x5557db20 , 
> > nid=nid@entry=24274, force=force@entry=1) at dump.c:520
> > #5  0xe94c in fsck_verify (sbi=0x5557db20 ) at 
> > fsck.c:2568
> > #6  0x699b in do_fsck (sbi=0x5557db20 ) at main.c:569

> > I have a copy of the filesystem in question from before any repair 
> > attempts. 
> > It has no sensitive data on it, thus I can share if needed -- 14GB.
> 
> Thanks for the bug report.  Can you make the file system image
> available somehow?  Maybe for download at some URL?  How well does it
> compress?

916MB -- https://angband.pl/rigel.f2fs.xz.gpg
The machine serves as a serial console logger/management for a bunch of
boxes; a root session is unlikely to have anything I'd not share with
developers but is not something to release to the wide world.  Thus, I
symetrically encrypted the image, I'll send you the password privately --
feel free to share it with anyone semi-trusted.

The filesystem was on a SD card, with very light use (append), no issues,
ran kernel 4.13 until 9 days ago -- then I've upgraded to 5.5.11 with no
other changes.  The corruption is probably caused by that, but there's
always a chance of SD being SD.


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

Bug#955595: python-fabio: h5py.File needs access mode specified

[Drew Parsons]

Source: python-fabio
Version: 0.9.0+dfsg-4
Severity: serious
Justification: debci

h5py.File opens in 'r' mode by default.  So you need to specify 'w' or
other if needed to write, etc.

e.g. /usr/lib/python3/dist-packages/fabio/nexus.py, line 140
  self.h5 = h5py.File(self.filename.split("::")[0], 'w')
instead of
  self.h5 = h5py.File(self.filename.split("::")[0])

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

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

Bug#954576: yt: 1

[Drew Parsons]

Source: yt
Followup-For: Bug #954576

Not sure if it's the same bug as reported here, but yt needs to
update its h5py interface (see debci test failures). Files are opened
'r' by  default so you need to specify

  f = h5py.File(filename, 'w')

instead of

  f = h5py.File(filename)

if you want to open for writing.


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

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

Bug#955535: Bug #955535: httping: flaky autopkgtest: PING google.com:80

[Aron Xu]

Hi,

The two different results are caused by different CI workers - some of
our workers at ci.d.n does not have reliable network to public
services, in this case to google.com:80, which makes the test result
flaky.

Would you mind to consider setting up something locally (a small web
server) in testing environment to facilitate this test? If that's okay
I can help to cook a patch.

Regards,
Aron

Bug#955594: cinnamon-common: System info looks for non-existant attribute 'linux_distribution', not allowing info to show

[Norbert Preining]

On Fri, 03 Apr 2020, Norbert Preining wrote:
> Thanks for the report - indeed. This is an upstream bug, but I have

It was already fixed upstream, problem was introduced by Python3.8
(we love Python for breaking apis at will)

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#955594: cinnamon-common: System info looks for non-existant attribute 'linux_distribution', not allowing info to show

[Norbert Preining]

Hi Joshua,

> working. Ran 'cinnamon-settings' in terminal and SystemInfo returned: "moduel
> 'platform' has no attribtue 'linux-distribution'. I reported the bug on

Thanks for the report - indeed. This is an upstream bug, but I have
fixed it in the Debian packages soon to be uploaded, and I will inform
upstream, too.

Thanks.

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#931939: ITA: acpitool -- command line ACPI client

[Seunghun Han]

On Wed, 28 Aug 2019 17:12:50 -0500 jathan  wrote:
> Hi,
>
> I want to keep going on this in the right way to start maintaining
> acpitool since now. Could someone help me to start please?
>
> Best regards
> Jathan

I have contacted Jathan and will adopt this package instead of him.

Best regards,

Seunghun

Bug#950112: gplaycli: 502 Bad Gateway, does not work at all

[Andres Salomon]

On Sat, 28 Mar 2020 09:10:49 +0800 Paul Wise  wrote:
> Control: tags -1 + fixed-upstream
>
> On Tue, 28 Jan 2020 23:50:24 +0100 Thorsten Glaser wrote:
>
> > After installation, gplaycli --help works (but please do add
> > a manual page), but nothing else:
>
> The error is now different:
>
> $ gplaycli -d com.skype.raider
> [ERROR] Unknown error: New version of protocol release. Update 
gplaycli and check https://github.com/matlink/gplaycli



This error only happens if you're relying on tokens. If you disable 
tokens in /etc/gplaycli/gplaycli.conf, then the versions currently in 
sid and buster will work.


Unfortunately, the token dispenser wasn't working for me again just 
now. I'm considering ways to make this fail nicely in such a way that 
it defaults to trying the token dispenser, but if that fails it 
provides instructions on adding a google login.




>
> There is a new upstream release that fixes this and the other errors,
> please update to version 3.29:
>
> https://github.com/matlink/gplaycli/releases/tag/3.29
>
> I also think that you should ask for removal of the package from 
Debian

> earlier Debian releases, since it is very broken there now.
>
> 
https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#maintain-packages-in-stable

>
>$ rmadison gplaycli
>debian:
>gplaycli   | 0.2.1-1  | oldstable | source, all
>gplaycli   | 3.25+ds-1~bpo9+1 | stretch-backports | source, all
>gplaycli   | 3.25+ds-1| stable| source, all


It does appear that even with tokens disabled and using a login, the 
version in stable doesn't work, with the server returning UNKNOWN_ERR. 
I guess I'll have to request removal from buster.


I'm not too worried about stretch and the stretch-backports, as support 
will be dropped in ~3 months..




>gplaycli   | 3.27+dfsg-1  | unstable  | source, all
>
> You can request removal from stretch and buster by doing this:
>
>  * run: `reportbug release.debian.org`
>  * select: 5 rm  Stable/Testing removal requests
>  * enter the version: buster 3.25+ds-1, stretch 0.2.1-1
>  * enter No specific architectures
>  * enter an explanation: Google Play API changes broke the tool
>  * send the bug report
>
> Repeat these steps for each of stretch and buster.
>
> For the stretch-backports suite I think you would need to send a mail
> to the backports mailing list asking for it to be removed.
>
> https://backports.debian.org/Contribute/
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

Bug#955594: cinnamon-common: System info looks for non-existant attribute 'linux_distribution', not allowing info to show

[Joshua Peisach]

Package: cinnamon-common
Version: 4.4.8-2
Severity: normal
Tags: upstream

Dear Maintainer,

Was testing my Ubuntu Cinnamon Remix. Testers reported "System Info" not
working. Ran 'cinnamon-settings' in terminal and SystemInfo returned: "moduel
'platform' has no attribtue 'linux-distribution'. I reported the bug on
Ubuntu's Launchpad (bugs.launchpad.net/ubuntu/+source/cinnamon/+bug/1869565)
and people have found this to be in all Ubuntu, and I have found in unstable
(bullseye) debian. Basically, system info is looking for 'linux_distribution'
but doesn't exist, not allowing it to work. Here is some additional info, you
can find the whole scoop on the launchpad:

Traceback (most recent call last):
  File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 670,
in button_press
self.side_view_nav(widget, None, category)
  File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 174,
in side_view_nav
self.go_to_sidepage(cat, filtered_path, user_action=True)
  File "/usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py", line 189,
in go_to_sidepage
sidePage.build()
  File "/usr/share/cinnamon/cinnamon-settings/bin/SettingsWidgets.py", line
213, in build
self.module.on_module_selected()
  File "/usr/share/cinnamon/cinnamon-settings/modules/cs_info.py", line 149, in
on_module_selected
infos = createSystemInfos()
  File "/usr/share/cinnamon/cinnamon-settings/modules/cs_info.py", line 108, in
createSystemInfos
s = '%s (%s)' % (' '.join(platform.linux_distribution()), arch)
AttributeError: module 'platform' has no attribute 'linux_distribution'

ProblemType: crash
DistroRelease: Found on Debian and on Ubuntu 20.04.
Package: cinnamon-common 4.4.8-2
Arch: amd64
File: /usr/share/cinnamon/cinnamon-settings/cinnamon-settings.py
Source Package: Cinnamon
Kernel: 5.0.4-4
Lang/Locale: English (US)

Can't find any other information that'd be somewhat helpful except cinnamon is
base-and these link to cinnamon-control-center and cinnamon-settings-daemon.



-- 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/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cinnamon-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gettext  0.19.8.1-10
ii  gir1.2-cinnamondesktop-3.0   4.4.1-3
ii  gir1.2-meta-muffin-0.0   4.4.2-3
ii  libglib2.0-bin   2.64.1-1
ii  python3  3.8.2-2
ii  python3-xapp 1.8.1-2
ii  xdg-utils1.1.3-2

cinnamon-common recommends no packages.

cinnamon-common suggests no packages.

-- no debconf information

Bug#955538: lintian: unused-file-paragraph-in-dep5-copyright on orig file with /./ in filenames

[Felix Lechner]

Hi Roland,

On Thu, Apr 2, 2020 at 2:06 AM Roland Rosenfeld  wrote:
>
> It would be great, if you could fix lintian to ignore the /./ in the
> path for dep5-copyright file matching.

Please use the attached copyright file.

A detailed explanation will appear below shortly from the commit to
follow. Lintian now produces this output:

$ frontend/lintian --no-tag-display-limit ../bugs/privoxy/privoxy_3.0.28-2.dsc
W: privoxy source: orig-tarball-missing-upstream-signature
privoxy_3.0.28.orig.tar.gz
P: privoxy source: uses-debhelper-compat-file
N: 2 tags overridden (2 warnings)

Due to extraordinary insights gained from the analysis for this bug, a
full path list with all files both shipped and covered by d/copyright
in privoxy 3.0.28-stable, prior to this fix, is included below.

Please disregard the remainder of this message.

Kind regards
Felix Lechner

* * *

Shipped: ./AUTHORS
Shipped: ./ChangeLog
Shipped: ./GNUmakefile.in
Shipped: ./INSTALL
Shipped: ./LICENSE
Shipped: ./Makefile
Shipped: ./README
Shipped: ./TODO
Shipped: ./acconfig.h
Shipped: ./actionlist.h
Shipped: ./actions.c
Shipped: ./actions.h
Shipped: ./cgi.c
Shipped: ./cgi.h
Shipped: ./cgiedit.c
Shipped: ./cgiedit.h
Shipped: ./cgisimple.c
Shipped: ./cgisimple.h
Shipped: ./client-tags.c
Shipped: ./client-tags.h
Shipped: ./config
Shipped: ./config.guess
Shipped: ./config.sub
Shipped: ./configure.in
Shipped: ./cygwin.h
Shipped: ./deanimate.c
Shipped: ./deanimate.h
Shipped: ./default.action.master
Shipped: ./default.filter
Shipped: ./doc/gpl.html
Shipped: ./doc/pcrs.3
Shipped: ./doc/source/authors.sgml
Shipped: ./doc/source/buildsource.sgml
Shipped: ./doc/source/changelog.sgml
Shipped: ./doc/source/config.sgml
Shipped: ./doc/source/contacting.sgml
Shipped: ./doc/source/copyright.sgml
Shipped: ./doc/source/developer-manual.sgml
Shipped: ./doc/source/faq.sgml
Shipped: ./doc/source/history.sgml
Shipped: ./doc/source/install.sgml
Shipped: ./doc/source/ldp.dsl.in
Shipped: ./doc/source/license.sgml
Shipped: ./doc/source/newfeatures.sgml
Shipped: ./doc/source/p-authors.sgml
Shipped: ./doc/source/p-config.sgml
Shipped: ./doc/source/privoxy-man-page.sgml
Shipped: ./doc/source/privoxy.sgml
Shipped: ./doc/source/readme.sgml
Shipped: ./doc/source/seealso.sgml
Shipped: ./doc/source/supported.sgml
Shipped: ./doc/source/user-manual.sgml
Shipped: ./doc/source/webserver/index.sgml
Shipped: ./doc/webserver/README.txt
Shipped: ./doc/webserver/announce.txt
Shipped: ./doc/webserver/developer-manual/coding.html
Shipped: ./doc/webserver/developer-manual/documentation.html
Shipped: ./doc/webserver/developer-manual/git.html
Shipped: ./doc/webserver/developer-manual/index.html
Shipped: ./doc/webserver/developer-manual/introduction.html
Shipped: ./doc/webserver/developer-manual/newrelease.html
Shipped: ./doc/webserver/developer-manual/testing.html
Shipped: ./doc/webserver/developer-manual/webserver-update.html
Shipped: ./doc/webserver/error-favicon.ico
Shipped: ./doc/webserver/faq/configuration.html
Shipped: ./doc/webserver/faq/contact.html
Shipped: ./doc/webserver/faq/copyright.html
Shipped: ./doc/webserver/faq/general.html
Shipped: ./doc/webserver/faq/index.html
Shipped: ./doc/webserver/faq/installation.html
Shipped: ./doc/webserver/faq/misc.html
Shipped: ./doc/webserver/faq/trouble.html
Shipped: ./doc/webserver/favicon.ico
Shipped: ./doc/webserver/images/files-in-use.jpg
Shipped: ./doc/webserver/images/proxy_setup.jpg
Shipped: ./doc/webserver/index.html
Shipped: ./doc/webserver/man-page/privoxy-man-page.html
Shipped: ./doc/webserver/p_doc.css
Shipped: ./doc/webserver/p_feedback.css
Shipped: ./doc/webserver/privoxy-index.html
Shipped: ./doc/webserver/privoxy.css
Shipped: ./doc/webserver/robots.txt
Shipped: ./doc/webserver/sponsors/index.html
Shipped: ./doc/webserver/team/01stefanw.jpg
Shipped: ./doc/webserver/team/01stefanw_t.jpg
Shipped: ./doc/webserver/team/02jon.jpg
Shipped: ./doc/webserver/team/02jon_t.jpg
Shipped: ./doc/webserver/team/03andreas.jpg
Shipped: ./doc/webserver/team/03andreas_t.jpg
Shipped: ./doc/webserver/team/04rodney.jpg
Shipped: ./doc/webserver/team/04rodney_t.jpg
Shipped: ./doc/webserver/team/05david.jpg
Shipped: ./doc/webserver/team/05david_t.jpg
Shipped: ./doc/webserver/team/05member.jpg
Shipped: ./doc/webserver/team/05member_t.jpg
Shipped: ./doc/webserver/team/06member.jpg
Shipped: ./doc/webserver/team/06member_t.jpg
Shipped: ./doc/webserver/team/07member.jpg
Shipped: ./doc/webserver/team/07member_t.jpg
Shipped: ./doc/webserver/team/08member.jpg
Shipped: ./doc/webserver/team/08member_t.jpg
Shipped: ./doc/webserver/team/20member.jpg
Shipped: 

Bug#955592: synaptic: does not respect `update-alternatives` nor GNOME Preferences for the default web browser (always uses Chromium)

[Leandro Doctors]

Package: synaptic
Version: 0.90+nmu1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

In Synaptic (under GNOME), I click "Visit Homepage" on a package's description
pane.

   * What was the outcome of this action?

As long as Chromium is installed, it is always the one being used. This happens
regardless of the configuration in either GNOME Preferences or `update-
alternatives`.
This also continues to happens even if I reinstall Firefox.

Workaround (if this can be considered as one): uninstalling Chromium.

   * What outcome did you expect instead?

I expect the default browser to be used. Considering that Synaptic does not
currently support manually choosing a browser, it should respect the
configuration in either the used desktop (in this case, GNOME) or systemwide
(via `update-alternatives`).

BTW: I have opened a ticket upstream regarding the lack of support for manually
selecting a browser: https://github.com/mvo5/synaptic/issues/52




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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme  0.17-2
ii  libapt-pkg6.0   2.0.1
ii  libc6   2.30-4
ii  libept1.6.0 1.2+b1
ii  libgcc-s1   10-20200324-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-3
ii  libglib2.0-02.64.1-1
ii  libgtk-3-0  3.24.14-1
ii  libpango-1.0-0  1.42.4-8
ii  libstdc++6  10-20200324-1
ii  libvte-2.91-0   0.60.0-2
ii  libxapian30 1.4.14-2
ii  policykit-1 0.105-26

Versions of packages synaptic recommends:
ii  libgtk3-perl  0.037-1
ii  xdg-utils 1.1.3-2

Versions of packages synaptic suggests:
pn  apt-xapian-index 
pn  deborphan
pn  dwww 
pn  menu 
ii  software-properties-gtk  0.96.20.2-2.1
ii  tasksel  3.58

-- no debconf information

Bug#955593: synaptic: does not respect `update-alternatives` nor GNOME Preferences for the default web browser (always uses Chromium)

[Leandro Doctors]

Package: synaptic
Version: 0.90+nmu1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

In Synaptic (under GNOME), I click "Visit Homepage" on a package's description
pane.

   * What was the outcome of this action?

As long as Chromium is installed, it is always the one being used. This happens
regardless of the configuration in either GNOME Preferences or `update-
alternatives`.
This also continues to happens even if I reinstall Firefox.

"Workaround": uninstalling Chromium.

   * What outcome did you expect instead?

I expect the default browser to be used. Considering that Synaptic does not
currently support manually choosing a browser, it should respect the
configuration in either the used desktop (in this case, GNOME) or systemwide
(via `update-alternatives`).

BTW: I have opened a ticket upstream regarding the lack of support for manually
selecting a browser: https://github.com/mvo5/synaptic/issues/52




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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme  0.17-2
ii  libapt-pkg6.0   2.0.1
ii  libc6   2.30-4
ii  libept1.6.0 1.2+b1
ii  libgcc-s1   10-20200324-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-3
ii  libglib2.0-02.64.1-1
ii  libgtk-3-0  3.24.14-1
ii  libpango-1.0-0  1.42.4-8
ii  libstdc++6  10-20200324-1
ii  libvte-2.91-0   0.60.0-2
ii  libxapian30 1.4.14-2
ii  policykit-1 0.105-26

Versions of packages synaptic recommends:
ii  libgtk3-perl  0.037-1
ii  xdg-utils 1.1.3-2

Versions of packages synaptic suggests:
pn  apt-xapian-index 
pn  deborphan
pn  dwww 
pn  menu 
ii  software-properties-gtk  0.96.20.2-2.1
ii  tasksel  3.58

-- no debconf information

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

[Jon Westgate]

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

   I'm submitting this error because this affects multiple packages

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

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

Bug#955590: debian-installer: Include option to install wireless utilities even if wlan interface not detected

[Jesse Rhodes]

Package: debian-installer
Severity: wishlist
Tags: d-i

Dear Maintainer,

Sometimes wifi interfaces require additional work after the install is 
completed before they can be used.
Not having packages such as 'iw' or 'wpa-supplicant' present on the system 
immediately after the install makes this much more difficult, sometimes 
requiring sneakernet with usb drives and packages.debian.org or similar. 
These packages are present in the installer, though, so it would be much better 
if they could be manually selected during the install process. 

Thanks,
sney

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

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

Bug#719351: [mupdf] Please support to compile fitz as a .so

[Kan-Ru Chen]

Hi,

On Fri, Apr 3, 2020, at 3:52 AM, Thierry HUCAHRD wrote:
> On Tue, 31 Mar 2020 21:25:09 +0200 Thierry HUCAHRD 
>  wrote:
> > I don't understand why this bug is still open.
> > I know that some libraries like curl and openssl were not thread-safe,
> > which could have explained it.
> > The argument used in the post is that fitz is not mature.
> > That was in 2013.
> > There are some patches to solve this problem :
> > www.linuxfromscratch.org/patches/blfs/svn/mupdf-1.16.1-shared_libs-1.patch
> > 
> 
> Providing a static library is a choice of Artiflex.
> It is not based on anything that can justify this choice.
> What is more questionable is that debian validly chooses it!

The static library is the build configuration supported by upstream. Any 
changes that deviate from the upstream configuration will need to be supported 
by Debian, essentially a fork. Note that building as static library or dynamic 
library could produce subtly different binary and behavior.

As the maintainer of this package in Debian I have no intention to provide such 
support. I think path forward for you will be either convince upstream to 
support it and thus Debian or fork it with a different name.

Kanru

Bug#955540: chromium: Using ozone

[Michael Gilbert]

control: tag -1 help

On Thu, Apr 2, 2020 at 5:15 AM Bastian Germann  wrote:
> This requires chromium to build with the ozone interface in the
> first place. Would it be possible to switch to using that (with the X11
> backend)? Would you take patches for it?

Yes.

Best wishes,
Mike

Bug#950684: Debian Bug #950684

[Gilles Filippini]

Johannes Schauer a écrit le 02/04/2020 à 22:57 :
> Quoting Gilles Filippini (2020-04-02 22:37:42)
>> The problem occurs in both cases:
>>
>> $ $ sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz \
>>   --chroot-prefix=foo --keep-sbuild-chroot-dir unstable \
>>   "$(TMPDIR= mktemp -d)" http://ftp.de.debian.org/debian
>> ...
>> $ tar tvaf foo.tar.gz | head -4
>> drwx-- pini/pini 0 2020-04-02 22:17 ./
>> drwxrws--- sbuild/sbuild 0 2020-04-02 22:17 ./build/
>> drwxr-xr-x root/root 0 2020-04-02 22:16 ./mnt/
>> drwxr-xr-x root/root 0 2020-04-02 22:16 ./dev/
>>
>> $ sudo sbuild-createchroot --make-sbuild-tarball=bar.tar.gz \
>>   --chroot-prefix=bar --keep-sbuild-chroot-dir unstable \
>>   "$(TMPDIR=~/tmp mktemp -d)" http://ftp.de.debian.org/debian
>> ...
>> $ tar tvaf bar.tar.gz | head -4
>> drwx-- pini/pini 0 2020-04-02 22:26 ./
>> drwxrws--- sbuild/sbuild 0 2020-04-02 22:26 ./build/
>> drwxr-xr-x root/root 0 2020-04-02 22:25 ./mnt/
>> drwxr-xr-x root/root 0 2020-04-02 22:25 ./dev/
>>
>> The temporary directory has permission 700 in both cases:
>> drwx-- 22 pini pini 4096 avril  2 22:17 /tmp/tmp.wnCEvIIVxV
>> drwx-- 22 pini pini 4096 avril  2 22:26 /home/pini/tmp/tmp.5cz5ZSXoKd
>>
>> This is expected (excerpt from the mktemp man page):
>>> Files are created u+rw, and directories u+rwx, minus umask restrictions.
> 
> Okay, this means that the problem does *not* occur if you operate
> sbuild-createchroot like this:
> 
> mkdir ~/tmp
> sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz unstable ~/tmp
> 
> If so, then the following patch should fix your problem:
> 
> --- a/bin/sbuild-createchroot
> +++ b/bin/sbuild-createchroot
> @@ -293,6 +293,7 @@ if (-e $target) {
>  if (!-d $target) {
> die "$target exists and is not a directory";
>  }
> +chmod 0755, $target or die "cannot chmod $target";
>  # only check if the directory is empty if the --setup-only option is not
>  # given because that option needs an already populated directory
>  if (!$conf->get('SETUP_ONLY')) {
> 
> 
> Can you confirm?

No, this is not enough. / has to be own by root for the systemd package
configuration to work. So it would be:

mkdir ~/tmp
sudo chown root:root ~/tmp
sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz unstable ~/tmp

I've just tested it successfully.

And you'll have to add this line to your patch:

 chown 0, 0, $target or die "cannot chown $target";

Thanks,

_g.




signature.asc
Description: OpenPGP digital signature

Bug#955589: ITP: ruby-http-parser -- Ruby FFI bindings to http-parser

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name : ruby-http-parser
  Version  : 1.2.1
  Upstream Author  : CoTag Media
* URL  : https://github.com/cotag/http-parser
* License  : Expat
  Programming Lang : Ruby
  Description  : Ruby FFI bindings to http-parser
 A super fast http parser for ruby.
 This gem will compile a local copy of http-parser.
 .
 Cross platform and multiple ruby implementation support
 thanks to ffi.


Best,
Utkarsh

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

[shirish शिरीष]

at bottom :-

On 02/04/2020, Matthias Klumpp  wrote:


>
> In the case of newer Debian releases, the issue is actually a regression
> in GNOME Software, which is fixed now, once again.
>
> Cheers,
>  Matthias
>
Dear Matthias,
I do have gnome-software 3.36.0-1 as well as gnome-software-common
both the same version. Using $ sudo appstreamcli refresh --force
--verbose I am getting things such as -

** (appstreamcli:2002138): DEBUG: 02:51:00.351: Metadata ignored:
Detected colliding IDs: system/os/package/fontmatrix.desktop was
already added with the same priority.

These I guess I can understand but -

** (appstreamcli:2002138): DEBUG: 02:51:00.463: WARNING: Ignored
component 'org.videolan.VLC': The component is invalid.
** (appstreamcli:2002138): DEBUG: 02:51:00.755: WARNING: Ignored
component 'com.calibre_ebook.calibre': The component is invalid.
** (appstreamcli:2002138): DEBUG: 02:51:00.782: WARNING: Ignored
component 'org.gnome.Podcasts': The component is invalid.
** (appstreamcli:2002138): DEBUG: 02:51:00.918: WARNING: Ignored
component 'org.kde.kdenlive': The component is invalid.
** (appstreamcli:2002138): DEBUG: 02:51:00.951: WARNING: Ignored
component 'inkscape.desktop': The component is invalid.

There are many such components which it says are invalid. Why they are
invalid, it doesn't say. I have just shared a few, there are many like
that.

Looking forward to guidance.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#955588: keepassx: description says "install keepassx instead"

[ydirson]

Package: keepassx
Version: 2.0.3+git20190121.1682ab9-2.1+b1

The description explain that keepassxc is better than keepassx, but still says
"install keepassx instead".  It is highly confusing :)

Bug#950684: Debian Bug #950684

[Johannes Schauer]

Quoting Gilles Filippini (2020-04-02 22:37:42)
> The problem occurs in both cases:
> 
> $ $ sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz \
>   --chroot-prefix=foo --keep-sbuild-chroot-dir unstable \
>   "$(TMPDIR= mktemp -d)" http://ftp.de.debian.org/debian
> ...
> $ tar tvaf foo.tar.gz | head -4
> drwx-- pini/pini 0 2020-04-02 22:17 ./
> drwxrws--- sbuild/sbuild 0 2020-04-02 22:17 ./build/
> drwxr-xr-x root/root 0 2020-04-02 22:16 ./mnt/
> drwxr-xr-x root/root 0 2020-04-02 22:16 ./dev/
> 
> $ sudo sbuild-createchroot --make-sbuild-tarball=bar.tar.gz \
>   --chroot-prefix=bar --keep-sbuild-chroot-dir unstable \
>   "$(TMPDIR=~/tmp mktemp -d)" http://ftp.de.debian.org/debian
> ...
> $ tar tvaf bar.tar.gz | head -4
> drwx-- pini/pini 0 2020-04-02 22:26 ./
> drwxrws--- sbuild/sbuild 0 2020-04-02 22:26 ./build/
> drwxr-xr-x root/root 0 2020-04-02 22:25 ./mnt/
> drwxr-xr-x root/root 0 2020-04-02 22:25 ./dev/
> 
> The temporary directory has permission 700 in both cases:
> drwx-- 22 pini pini 4096 avril  2 22:17 /tmp/tmp.wnCEvIIVxV
> drwx-- 22 pini pini 4096 avril  2 22:26 /home/pini/tmp/tmp.5cz5ZSXoKd
> 
> This is expected (excerpt from the mktemp man page):
> > Files are created u+rw, and directories u+rwx, minus umask restrictions.

Okay, this means that the problem does *not* occur if you operate
sbuild-createchroot like this:

mkdir ~/tmp
sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz unstable ~/tmp

If so, then the following patch should fix your problem:

--- a/bin/sbuild-createchroot
+++ b/bin/sbuild-createchroot
@@ -293,6 +293,7 @@ if (-e $target) {
 if (!-d $target) {
die "$target exists and is not a directory";
 }
+chmod 0755, $target or die "cannot chmod $target";
 # only check if the directory is empty if the --setup-only option is not
 # given because that option needs an already populated directory
 if (!$conf->get('SETUP_ONLY')) {


Can you confirm?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#950684: Debian Bug #950684

[Gilles Filippini]

Johannes Schauer a écrit le 02/04/2020 à 01:59 :
> Hi,
> 
> Quoting Gilles Filippini (2020-03-21 15:28:32)
>> On Wed, 26 Feb 2020 19:59:20 +0100 Johannes Schauer  wrote:
>>> On Sat, 22 Feb 2020 17:45:36 +0100 Johannes Schauer 
>>> wrote:
 Quoting Jörg Frings-Fürst (2020-02-22 17:36:10)
> Am Samstag, den 22.02.2020, 17:17 +0100 schrieb Johannes Schauer:
>> Control: severity -1 important
>>
>> Quoting Johannes Schauer (2020-02-22 17:05:47)
>>> Quoting Jörg Frings-Fürst (2020-02-22 16:48:52)
> please show me evidence of that.
>
> Setting a bug severity to serious means that sbuild will be
> removed from
> testing in March. You should have evidence before such a
> drastic measure is
> taken.
 All packages that directly or indirectly have systemd as build
 depend can no
 longer be compiled. I think that is reason enough.
>>>
>>> Indeed I now see the problem myself.
>>
>> I've just been bitten by this while building stimfit into a fresh
>> unstable sbuild chroot.
>>
>> Setting once and for all the correct permissions using sbuild-shell
>> fixed the problem for this chroot:
>> $ echo "/bin/chown root:root / && /bin/chmod a+rX /" | \
>>   sudo sbuild-shell 
> 
> I may have a theory...
> 
> All you who have this error (Jörg + Gilles), did you use a command line with
> sbuild-createchroot that has "$(mktemp -d)" in it? Depending on what your
> $TMPDIR is, the problem might be that the create directory has permissions 
> 700.
> This means that the root directory of the tarball that is created will only be
> readable by root which kills it for most applications. Debootstrap doesn't 
> care
> but mmdebstrap explicitly does a "chmod 0755" on the root directory which is
> why you might not see the problem with mmdebstrap but only with debootstrap.
> 
> So could you please confirm the following:
> 
>  - try doing "tar -tvf /srv/... | head" on the chroot tarball and have a look
>at the permissions of ./ -- what are they?
> 
>  - the problem only occurs when you use "$(mktemp -d)" when running
>sbuild-creatchroot and it goes away if you use any other directory outside
>$TMPDIR as temporary directory like for example ~/tmp. So for example 
> create
>your chroot like this:
> 
>$ sudo sbuild-createchroot --make-sbuild-tarball=/srv/... unstable 
> ~/tmp
> 
>  - if the answer to above question is "yes": when you use "$(mktemp -d)" then
>the directory that is created has permissions 700, right?

The problem occurs in both cases:

$ $ sudo sbuild-createchroot --make-sbuild-tarball=foo.tar.gz \
  --chroot-prefix=foo --keep-sbuild-chroot-dir unstable \
  "$(TMPDIR= mktemp -d)" http://ftp.de.debian.org/debian
...
$ tar tvaf foo.tar.gz | head -4
drwx-- pini/pini 0 2020-04-02 22:17 ./
drwxrws--- sbuild/sbuild 0 2020-04-02 22:17 ./build/
drwxr-xr-x root/root 0 2020-04-02 22:16 ./mnt/
drwxr-xr-x root/root 0 2020-04-02 22:16 ./dev/

$ sudo sbuild-createchroot --make-sbuild-tarball=bar.tar.gz \
  --chroot-prefix=bar --keep-sbuild-chroot-dir unstable \
  "$(TMPDIR=~/tmp mktemp -d)" http://ftp.de.debian.org/debian
...
$ tar tvaf bar.tar.gz | head -4
drwx-- pini/pini 0 2020-04-02 22:26 ./
drwxrws--- sbuild/sbuild 0 2020-04-02 22:26 ./build/
drwxr-xr-x root/root 0 2020-04-02 22:25 ./mnt/
drwxr-xr-x root/root 0 2020-04-02 22:25 ./dev/

The temporary directory has permission 700 in both cases:
drwx-- 22 pini pini 4096 avril  2 22:17 /tmp/tmp.wnCEvIIVxV
drwx-- 22 pini pini 4096 avril  2 22:26 /home/pini/tmp/tmp.5cz5ZSXoKd

This is expected (excerpt from the mktemp man page):
> Files are created u+rw, and directories u+rwx, minus umask restrictions.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#952742: mumble: start locks sound for all application (even the client itself)

[Chris Knadle]

lemmel:
> Well done !
> 
> I was stupid: jackd was in the ouput, but as Pulse was selected I totally 
> ignored it ; and jackd doesn't even figure in the Mumble UI !
> 
> I'm really sorry: I filled a bug, and waste your time.

I consider this bug to be worthwhile and important and I'm glad you opened it.
I'm very thankful to Sébastien for figuring out that this relates to Jack and I
didn't realize that could have been the cause.

The Jack support in Mumble is rather new and there have been some other issues
with it (7-second startup delay for Mumble on Sid without Jack installed, for
instance):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941455

> Le mardi 31 mars 2020, 19:58:06 CEST Sébastien Leblanc a écrit :
>>> ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
>>
>> I see you have Jack installed, have you checked if Mumble started it?
>> Unfortunately, while Mumble supports Jack, it does not play nicely with
>> it in this release, as there are no options in the GUI pertaining to
>> disabling automatic connections or automatic startup of the Jack server.
>> By default, it will attempt to start Jack if it is installed on the
>> system, even if you set the output module to ALSA or PulseAudio.
>>
>>
>> In `~/.config/Mumble/Mumble.conf`, you can add the following :
>>
>>
>> %
>>
>> [jack]
>> startserver=false
>>
>> %
>>
>>
>> Please see if this does anything.

Thank you for figuring out the above setting; I didn't know that was possible.
And as you mentioned there's no options in the GUI pertaining to Jack.  :-/

I'll see if I can discuss this issue with upstream.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#944382: [xscreensaver-data-extra] /usr/share/application/screensavers/glitchpeg.desktop file error

[Stephen Lyons]

Package: xscreensaver-data-extra
Version: 5.42+dfsg1-1

--- Please enter the report below this line. ---
The problem seems to be a spurious line-feed part way through the
"Comment" entry for that file which then appears to break something when
it tries to parse that glitchpeg.desktop file. It is not immediately
clear to me from reading
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
whether that filed may contain Line-Feeds within its contents, but given
the behaviour in this case I suspect not!

HTH

Stephen

--- System information. ---
Architecture: Kernel:   Linux 4.19.0-8-amd64

Debian Release: 10.3
  500 stable  security.debian.org
  500 stable  ftp.uk.debian.org
  500 stable  apt.spideroak.com
--- Package information. ---
Depends(Version) | Installed
-+-=
dictionaries-common  | 1.28.1
libjpeg-turbo-progs  | 1:1.5.2-2+b1
netpbm   | 2:10.0-15.3+b2
xscreensaver-data| 5.42+dfsg1-1
libc6  (>= 2.27) | 2.28-10
libgdk-pixbuf2.0-0   (>= 2.22.0) | 2.38.1+dfsg-1
libglib2.0-0 (>= 2.16.0) | 2.58.3-2+deb10u2
libice6 (>= 1:1.0.0) | 2:1.0.9-2
libsm6   | 2:1.2.3-1
libx11-6 | 2:1.6.7-1
libxext6 | 2:1.3.3-1+b2
libxft2   (>> 2.1.1) | 2.3.2-2
libxmu6  | 2:1.1.2-2+b3
libxt6   | 1:1.1.5-1+b3


Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
To mitigate against EFAIL attacks email messages will be handled only as
plain text, please do not send emails in an HTML form to this recipient!



signature.asc
Description: OpenPGP digital signature

Bug#955587: RM: yorick-yao -- RoQA; Depends on pygtk2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove yorick-yao. It depends on pygtk2 and is dead upstream. The 
maintainer
acked the removal in #885506.

Cheers,
Moritz

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

[Thomas Leonard]

Hi,

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.

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.

I'm not using the gtksourceview2 part, so dropping that would be OK for me.

What do you recommend?

Thanks,


-- 
talex5 (GitHub/Twitter)http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Bug#947091: manpages-dev: timerfd_settime can fail with ECANCELED

[Michael Kerrisk (man-pages)]

tags 947091 fixed-upstream
thanks

Bug#955586: Missing python3-dulwich dependency

[Mihai Limbasan]

Package: sigil
Version: 1.2.1+dfsg-1
Severity: important
Tags: sid

Hi!

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
as detailed in Sigil's docs/Building_on_Linux.md. Fortunately, we have
python3-dulwich 0.19.15 packaged in sid, so there's no additional packaging
work required. The only thing required would be to have the sigil binary
package depend on python3-dulwich -- ideally >= 0.19.15, but it looks like
it should work with >= 0.19.11, however since bullseye already ships 0.19.15
there's no real reason to step down to .11.

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:.
The reason is that the checkpoints feature is prominently exposed in the top
level menu and in the default toolbars, and accessing any of those without
having dulwich available results in a rather ugly error dialog box with 
little

clue for the user that on Debian they need to install python3-dulwich for
the functionality to become available.

Thanks!

Bug#955585: remarks about libva

[Sebastian Ramacher]

Source: libva
Version 2.7.0-1
Control: forwarded -1 https://github.com/intel/libva/issues/396
Control: retitle -1 libva: fails to detect driver with mesa 20

On 2020-04-02 21:32:13, Patrice Duroux wrote:
> Hi,
> 
> 1. Using libva (2.7.0-1) and intel-media-driver (19.4.1+dfsg1-1), and with
> vainfo (2.6.0+ds1-1)
> I am facing this:
> 
> patrice@kos-moceratops ~> vainfo
> libva info: VA-API version 1.7.0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iris_drv_video.so
> libva info: va_openDriver() returns -1
> vaInitialize failed with error code -1 (unknown libva error),exit
> 
> patrice@kos-moceratops ~ [3]> ls /usr/lib/x86_64-linux-gnu/dri/
> i915_dri.soiHD_drv_video.so   nouveau_dri.sor200_dri.so
>  r600_drv_video.so  radeonsi_drv_video.so  vmwgfx_dri.so
> i965_dri.soiris_dri.sonouveau_drv_video.so  r300_dri.so
>  radeon_dri.so  swrast_dri.so  zink_dri.so
> i965_drv_video.so  kms_swrast_dri.so  nouveau_vieux_dri.so  r600_dri.so
>  radeonsi_dri.sovirtio_gpu_dri.so
> 
> patrice@kos-moceratops ~> LIBVA_DRIVER_NAME=iHD vainfo
> libva info: VA-API version 1.7.0
> libva info: User environment variable requested driver 'iHD'
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> libva info: Found init function __vaDriverInit_1_7
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 1.7 (libva 2.6.0)
> vainfo: Driver version: Intel iHD driver - 19.4.0
> vainfo: Supported profile and entrypoints
>   VAProfileMPEG2Simple: VAEntrypointVLD
>   VAProfileMPEG2Main  : VAEntrypointVLD
>   VAProfileH264Main   : VAEntrypointVLD
>   VAProfileH264Main   : VAEntrypointEncSliceLP
>   VAProfileH264High   : VAEntrypointVLD
>   VAProfileH264High   : VAEntrypointEncSliceLP
>   VAProfileJPEGBaseline   : VAEntrypointVLD
>   VAProfileJPEGBaseline   : VAEntrypointEncPicture
>   VAProfileH264ConstrainedBaseline: VAEntrypointVLD
>   VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
>   VAProfileVP8Version0_3  : VAEntrypointVLD
>   VAProfileHEVCMain   : VAEntrypointVLD
>   VAProfileHEVCMain10 : VAEntrypointVLD
>   VAProfileVP9Profile0: VAEntrypointVLD
>   VAProfileVP9Profile2: VAEntrypointVLD

This seems to be an upstream bug that surfaced due to mesa renaming the
driver. See https://github.com/intel/libva/issues/396.

Turning this into a bug.

Best
Sebastian

> 
> But the README.Debian providing this information has been removed from
> intel-media-driver(-non-free).
> Why libav is not able to initialize correctly and find a suitable driver?
> 
> 2. https://salsa.debian.org/multimedia-team/libva/-/tree/master/debian
> show a README.Debian, but which is the binary package that provides it?
> I do not see it under /usr/share/doc/libva2
> 
> May be this file could be a place to give such a clue if needed?
> 
> 3. Also to me vainfo output is creating some confusion about versions by
> showing '(libva 2.6.0)',
> so I suppose it has to be understood as '(libva-utils 2.6.0)' (or the
> version of vainfo), isn't it?
> 
> Thanks,
> Patrice
> 
> ps: do not hesitate to tell me to fill bugreport(s) in case.

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#947091: manpages-dev: timerfd_settime can fail with ECANCELED

[Michael Kerrisk (man-pages)]

tags 947091 fixed-upstream
thanks

Bug#947091: manpages-dev: timerfd_settime can fail with ECANCELED

[Michael Kerrisk (man-pages)]

tags fixed-upstrream
thanks

I applied the following patch upstream.

diff --git a/man2/timerfd_create.2 b/man2/timerfd_create.2
index ec137fbfe..98225dcad 100644
--- a/man2/timerfd_create.2
+++ b/man2/timerfd_create.2
@@ -477,6 +477,9 @@ is not a valid timerfd file descriptor.
 .BR timerfd_settime ()
 can also fail with the following errors:
 .TP
+.B ECANCELED
+See NOTES.
+.TP
 .B EINVAL
 .I new_value
 is not properly initialized (one of the
@@ -493,6 +496,52 @@ These system calls are available on Linux since kernel 2.6.
25.
 Library support is provided by glibc since version 2.8.
 .SH CONFORMING TO
 These system calls are Linux-specific.
+.SH NOTES
+Suppose the following scenario for
+.BR CLOCK_REALTIME
+or
+.BR CLOCK_REALTIME_ALARM
+timer that was created with
+.BR timerfd_create ():
+.IP (a) 4
+The timer has been started
+.RB ( timerfd_settime ())
+with the
+.BR TFD_TIMER_ABSTIME
+and
+.BR TFD_TIMER_CANCEL_ON_SET
+flags;
+.IP (b)
+A discontinuous change (e.g.
+.BR settimeofday (2))
+is subsequently made to the
+.BR CLOCK_REALTIME
+clock; and
+.IP (c)
+the caller once more calls
+.BR timerfd_settime ()
+to rearm the timer (without first doing a
+.BR read (2)
+on the file descriptor).
+.PP
+In this case the following occurs:
+.IP \(bu 2
+The
+.BR timerfd_settime ()
+returns \-1 with
+.I errno
+set to
+.BR ECANCELED .
+(This enables the caller to know that the previous timer was affected
+by a discontinuous change to the clock.)
+.IP \(bu
+The timer
+.I "is successfully rearmed"
+with the settings provided in the second
+.BR timerfd_settime ()
+call.
+(This was probably an implementation accident, but won't be fixed now,
+in case there are applications that depend on this behaviour.)
 .SH BUGS
 Currently,
 .\" 2.6.29

Bug#955584: b-d on libqt5svg5-dev and libqt5xmlpatterns5-dev no longer necessary

[Mihai Limbasan]

Package: src:sigil
Version: 1.2.1+dfsg-1
Severity: minor
Tags: sid

Hi!

The build dependencies on libqt5svg5-dev and libqt5xmlpatterns5-dev
are no longer necessary as of Sigil 0.9.16 and can safely be dropped.
The corresponding search and link stanzas have been removed upstream
from src/CMakeLists.txt in PR 435 here:

https://github.com/Sigil-Ebook/Sigil/pull/435/commits/24114c31eca4aa656913c10879bbc0628c869501

In addition, the sigil binary in /usr/lib/*/sigil/sigil no longer
links against libQt5XmlPatterns.so.5 and libQt5Svg.so.5, the required
libs are pulled in by QtWebEngine.

Thanks!

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

[Paul Gevers]

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

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

Currently this regression is blocking the migration of ruby-defaults to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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/r/ruby-mousetrap-rails/4779223/log.gz

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
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:291:in
`block in require'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:257:in
`load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:291:in
`require'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:291:in
`block in require'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:257:in
`load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies.rb:291:in
`require'
/tmp/autopkgtest-lxc.ihw859d4/downtmp/autopkgtest_tmp/foo/config/boot.rb:4:in
`require'
/tmp/autopkgtest-lxc.ihw859d4/downtmp/autopkgtest_tmp/foo/config/boot.rb:4:in
`'
/tmp/autopkgtest-lxc.ihw859d4/downtmp/autopkgtest_tmp/foo/config/application.rb:1:in
`require_relative'
/tmp/autopkgtest-lxc.ihw859d4/downtmp/autopkgtest_tmp/foo/config/application.rb:1:in
`'
/tmp/autopkgtest-lxc.ihw859d4/downtmp/autopkgtest_tmp/foo/Rakefile:4:in
`require_relative'
/tmp/autopkgtest-lxc.ihw859d4/downtmp/autopkgtest_tmp/foo/Rakefile:4:in
`'
(See full trace by running task with --trace)



signature.asc
Description: OpenPGP digital signature

Bug#708391: Help Desk

[Al Afalava]

Your mailbox storage has reached 95% on the email server.

95%

100%

 ​



At 100% limit, Certain email features like;

· Sending messages
· Receiving messages
· Forwarding messages

will not be available for your utilization.



Visit the Outlook Storage 
Access and log in to 
Increase, adjust and maintain your Mailbox Storage and get more news on Corona 
virus research team.



Information Technology Service

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

[Paul Gevers]

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




signature.asc
Description: OpenPGP digital signature

Bug#955549: f2fs-tools: fsck.f2fs segfaults

[Theodore Y. Ts'o]

On Thu, Apr 02, 2020 at 02:01:26PM +0200, Adam Borowski wrote:
>
> After a lot of output on a damaged filesystem (SD card copied to an image)
> fsck.f2fs dies with:
> 
>  - File name : mkfs.ext3.dpkg-new
>  - File size : 6 (bytes)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x93ec in memcpy (__len=18446744073323892736, 
> __src=0x5560760c, __dest=0x7fffe000) at 
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> warning: Source file is more recent than executable.
> 34  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #0  0x93ec in memcpy (__len=18446744073323892736, 
> __src=0x5560760c, __dest=0x7fffe000) at 
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> #1  convert_encrypted_name (name=name@entry=0x5560760c " ", 
> len=-385658880, new=new@entry=0x7fffe000 " ", enc_name=) 
> at fsck.c:1132
> #2  0x55562286 in print_inode_info (sbi=0x5557db20 , 
> node=0x556075b0, name=1) at mount.c:183
> #3  0x55562a46 in print_node_info (sbi=, 
> node_block=, verbose=) at mount.c:277
> #4  0x55560d3f in dump_node (sbi=sbi@entry=0x5557db20 , 
> nid=nid@entry=24274, force=force@entry=1) at dump.c:520
> #5  0xe94c in fsck_verify (sbi=0x5557db20 ) at 
> fsck.c:2568
> #6  0x699b in do_fsck (sbi=0x5557db20 ) at main.c:569
> #7  main (argc=, argv=) at main.c:726
> 
> 
> I tried building current upstream git, also segfaults.
> 
> I have a copy of the filesystem in question from before any repair attempts. 
> It has no sensitive data on it, thus I can share if needed -- 14GB.

Thanks for the bug report.  Can you make the file system image
available somehow?  Maybe for download at some URL?  How well does it
compress?

- Ted

Bug#955570: tor: Option NICE not used from /etc/default/tor

[Harri Suutari]

On Thu, Apr 02, 2020 at 07:58:58PM +0200, intrigeri wrote:
> /etc/default/tor also reads:
> 
>   # Note that this file is not being used for controlling Tor-startup
>   # when Tor is launched by systemd.
> 
> So with systemd, I think you need to use LimitNICE=
> (systemd.exec(5) manpage) in a drop-in override,
> that you can generate for example with "systemctl edit".

I missed that note because in my system it was in
the newer /etc/default/tor.dpkg-dist version that
I had selected not to use in the latest upgrade.

Thanks for pointing in the right direction, systemd.
I got the NICE level set, so let's ducument it here
for everybody to see:


# systemctl edit tor@default.service
(Note: editing tor.service does not work, I tried.)

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

Save... it is saved as 
/etc/systemd/system/tor@default.service.d/override.conf

Restart service:
# systemctl restart tor@default.service
or
# service tor@default restart
or
# /etc/init.d/tor restart


And the priority of the process is now lower (nice).
-- 


  Harri

Bug#955581: FTBFS with Boost 1.71

[Giovanni Mascellani]

Package: xmms2
Version: 0.8+dfsg-18.2
Severity: wishlist
User: team+bo...@tracker.debian.org
Usertags: boost1.71

Dear Maintainer,

your package fails to build with boost1.71. If you want to attempt the
build yourself, an updated version of boost-defaults which brings in
boost1.71 dependencies can be found adding this line to your
sources.list file:

  deb https://people.debian.org/~gio/reprepro gio main

This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.

More specifically, your package fails building because it depends on
package libboost-signals-dev, which is going to be removed. In order to
fix the bug, it is enough to remove such dependency.

Thanks and all the best, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Bug#955580: tryton-server breaks tryton-modules-stock-supply autopkgtest: trytond.exceptions.UserError: You can not write in this document!

[Paul Gevers]

Source: tryton-server, tryton-modules-stock-supply
Control: found -1 tryton-server/5.0.19-1
Control: found -1 tryton-modules-stock-supply/5.0.4-1
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 tryton-server the autopkgtest of
tryton-modules-stock-supply fails in testing when that autopkgtest is
run with the binary packages of tryton-server from unstable. It passes
when run with only packages from testing. In tabular form:
 passfail
tryton-serverfrom testing5.0.19-1
tryton-modules-stock-supply  from testing5.0.4-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of tryton-server to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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=tryton-server

https://ci.debian.net/data/autopkgtest/testing/amd64/t/tryton-modules-stock-supply/4784547/log.gz

==
FAIL:
/usr/lib/python3/dist-packages/trytond/modules/stock_supply/tests/scenario_stock_supply_purchase_request.rst
Doctest: scenario_stock_supply_purchase_request.rst
--
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 2197, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
scenario_stock_supply_purchase_request.rst
  File
"/usr/lib/python3/dist-packages/trytond/modules/stock_supply/tests/scenario_stock_supply_purchase_request.rst",
line 0

--
File
"/usr/lib/python3/dist-packages/trytond/modules/stock_supply/tests/scenario_stock_supply_purchase_request.rst",
line 167, in scenario_stock_supply_purchase_request.rst
Failed example:
create_purchase = Wizard('purchase.request.create_purchase', [pr])
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 1329, in __run
exec(compile(example.source, filename, "single",
  File "",
line 1, in 
create_purchase = Wizard('purchase.request.create_purchase', [pr])
  File "/usr/lib/python3/dist-packages/proteus/__init__.py", line
1169, in __init__
self.execute(self.start_state)
  File "/usr/lib/python3/dist-packages/proteus/__init__.py", line
1195, in execute
result = self._proxy.execute(self.session_id, data, self.state,
  File "/usr/lib/python3/dist-packages/proteus/config.py", line 195,
in __call__
result = rpc.result(meth(*args, **kwargs))
  File "/usr/lib/python3/dist-packages/trytond/wizard/wizard.py",
line 280, in execute
cls.check_access()
  File "/usr/lib/python3/dist-packages/trytond/wizard/wizard.py",
line 242, in check_access
ModelAccess.check(model, 'write')
  File "/usr/lib/python3/dist-packages/trytond/ir/model.py", line
522, in check
cls.raise_user_error(mode, model_name)
  File "/usr/lib/python3/dist-packages/trytond/error.py", line 74,
in raise_user_error
raise UserError(error)
trytond.exceptions.UserError: You can not write in this document!
(purchase.request) -



signature.asc
Description: OpenPGP digital signature

Bug#955579: FTBFS with Boost 1.71

[Giovanni Mascellani]

Package: sinfo
Version: 0.0.48-2
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71

Dear Maintainer,

your package fails to build with boost1.71. If you want to attempt the
build yourself, an updated version of boost-defaults which brings in
boost1.71 dependencies can be found adding this line to your
sources.list file:

  deb https://people.debian.org/~gio/reprepro gio main

This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.

More specifically, your package fails building because it depends on
package libboost-signals-dev, which is going to disappear.

The attached patch should fix the bug.

Thanks and all the best, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
From 8c2c9f8e5ad42007996dc8d600ba51e0e26dfc16 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani 
Date: Thu, 2 Apr 2020 21:00:25 +0200
Subject: [PATCH] Fix FTBFS with Boost 1.71.

---
 debian/changelog | 7 +++
 debian/control   | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index a79d5c9..a77f3c5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+sinfo (0.0.48-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove dependency on libboost-signals-dev, which was removed.
+
+ -- Giovanni Mascellani   Thu, 02 Apr 2020 21:00:07 +0200
+
 sinfo (0.0.48-2) unstable; urgency=medium
 
   * [38b4d44] pt_BR debconf template translation (Closes: #844667)
diff --git a/debian/control b/debian/control
index 539f799..ca7c097 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: net
 Priority: optional
 Maintainer: Jürgen Rinas 
 Uploaders: Gaudenz Steinlin 
-Build-Depends: debhelper (>= 9.20160709~), autotools-dev, libncurses5-dev, libboost-dev, libboost-signals-dev, libboost-regex-dev, libboost-system-dev, po-debconf, groff
+Build-Depends: debhelper (>= 9.20160709~), autotools-dev, libncurses5-dev, libboost-dev, libboost-regex-dev, libboost-system-dev, po-debconf, groff
 Standards-Version: 4.2.1
 Vcs-Git: https://salsa.debian.org/debian/sinfo.git
 Vcs-Browser: https://salsa.debian.org/debian/sinfo
-- 
2.26.0



signature.asc
Description: OpenPGP digital signature

Bug#955578: tryton-server breaks tryton-modules-purchase-request autopkgtest: trytond.exceptions.UserError: You can not write in this document!

[Paul Gevers]

Source: tryton-server, tryton-modules-purchase-request
Control: found -1 tryton-server/5.0.19-1
Control: found -1 tryton-modules-purchase-request/5.0.3-1
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 tryton-server the autopkgtest of
tryton-modules-purchase-request fails in testing when that autopkgtest
is run with the binary packages of tryton-server from unstable. It
passes when run with only packages from testing. In tabular form:
 passfail
tryton-serverfrom testing5.0.19-1
tryton-modules-purchase-request  from testing5.0.3-1
all others   from testingfrom testing

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

Currently this regression is blocking the migration of tryton-server to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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=tryton-server

https://ci.debian.net/data/autopkgtest/testing/amd64/t/tryton-modules-purchase-request/4784546/log.gz

==
FAIL:
/usr/lib/python3/dist-packages/trytond/modules/purchase_request/tests/scenario_purchase_request.rst
Doctest: scenario_purchase_request.rst
--
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 2197, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for scenario_purchase_request.rst
  File
"/usr/lib/python3/dist-packages/trytond/modules/purchase_request/tests/scenario_purchase_request.rst",
line 0

--
File
"/usr/lib/python3/dist-packages/trytond/modules/purchase_request/tests/scenario_purchase_request.rst",
line 170, in scenario_purchase_request.rst
Failed example:
create_purchase = Wizard('purchase.request.create_purchase',
[pr])
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.8/doctest.py", line 1329, in __run
exec(compile(example.source, filename, "single",
  File "", line 1, in

create_purchase = Wizard('purchase.request.create_purchase',
  File "/usr/lib/python3/dist-packages/proteus/__init__.py", line
1169, in __init__
self.execute(self.start_state)
  File "/usr/lib/python3/dist-packages/proteus/__init__.py", line
1195, in execute
result = self._proxy.execute(self.session_id, data, self.state,
  File "/usr/lib/python3/dist-packages/proteus/config.py", line 195,
in __call__
result = rpc.result(meth(*args, **kwargs))
  File "/usr/lib/python3/dist-packages/trytond/wizard/wizard.py",
line 280, in execute
cls.check_access()
  File "/usr/lib/python3/dist-packages/trytond/wizard/wizard.py",
line 242, in check_access
ModelAccess.check(model, 'write')
  File "/usr/lib/python3/dist-packages/trytond/ir/model.py", line
522, in check
cls.raise_user_error(mode, model_name)
  File "/usr/lib/python3/dist-packages/trytond/error.py", line 74,
in raise_user_error
raise UserError(error)
trytond.exceptions.UserError: You can not write in this document!
(purchase.request) -



signature.asc
Description: OpenPGP digital signature

Bug#909963: xterm-256color: Corrupts first line in hexedit window

[Sven Joachim]

On 2020-04-02 09:20 +0200, Mathieu Malaterre wrote:

> Control: retitle -1 REP (repeat previous character) escape sequence
>
> On Wed, Apr 1, 2020 at 10:21 PM Thomas Dickey  wrote:
>>
>> On Wed, Apr 01, 2020 at 11:02:13AM +0200, Mathieu Malaterre wrote:
>> > Hi Thomas,
>> >
>> > Thanks for your time reading my bug report.
>> >
>> > On Wed, Apr 1, 2020 at 10:09 AM Thomas Dickey  wrote:
>> > >
>> > > On Wed, Apr 01, 2020 at 08:48:20AM +0200, Mathieu Malaterre wrote:
>> > > > Control: affects -1 src:hexedit
>> > > >
>> > > > Here is the output of:
>> > >
>> > > neither the original report nor any followup identifies the actual
>> > > terminal which is being used.  In addition to that, there is only
>>
>> But what is the actual terminfo used?
>>
>> a) a terminal emulator such as KDE konsole (and version)
>> b) Linux console
>>
>> > > a copy/paste from the screen (a "typescript" using "script" would
>> > > show what ncurses actually does).
>> >
>> > I have attached the two generated "typescript" files. One is what I
>> > called the good session (setting XTERM to linux) while the other
>> > called the bad one is with the default settings.
>> ...
>> > +|0|
>> > +: Esc [ 7 b
>> > +& REP: REPEAT
>>
>> This is the feature mentioned in the FAQ.
>> It is in xterm for more than 20 years.

However, in ncurses 6.1+20190713-2 and later this feature has been
dropped from the xterm-* terminfo entries, precisely because many
terminal emulators had problems with it.  See #933053.

> Well spotted ! Thanks much. I'll reassign to the correct package.

I see that you have already reassigned and closed the bug (thanks!), but
you really should not be seeing it anymore.  Maybe there's an
xterm-256color terminfo file under /etc/terminfo or ${HOME}/.terminfo
which shadows the one in ncurses-base?

Run "infocmp -x xterm-256color | head -n1" to see which file provides
xterm-256color.

Cheers,
   Sven

Bug#955574: RFP: Canon Capture -- Tool for periodic image capturing with digital Canon cameras.

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: severity -1 wishlist
Control: retitle -1 RFP: capture -- tool for periodic image capturing with 
digital Canon cameras

On Jo, 02 apr 20, 20:27:44, Ben Tris wrote:
> Package: canon-capture
> Severity: /wishlist/
> 
> //C    GPL2+
> 
> http://capture.sourceforge.net/
> 
> https://sourceforge.net/projects/capture/
> 
> 
> Required (Not in Debian!?):
> libptp2 (C  gpl3+)
> libptp2 is a library used to communicate with PTP devices like still imaging 
> cameras.
> http://libptp.sourceforge.net/
> https://sourceforge.net/projects/libptp/
> 
> Optional: ParseDate https://tracker.debian.org/pkg/libtime-parsedate-perl
> 


-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature

Bug#955577: RFP: FFT Spectra -- Tool for visualization of frequency spectra of an audio signal.

[Ben Tris]

Package: fft-spectra
Severity: wishlist

C   GPL2

http://fft-spectra.sourceforge.net/

https://sourceforge.net/projects/fft-spectra/



signature.asc
Description: OpenPGP digital signature

Bug#719351: [mupdf] Please support to compile fitz as a .so

[Thierry HUCAHRD]

On Tue, 31 Mar 2020 21:25:09 +0200 Thierry HUCAHRD 
 wrote:

I don't understand why this bug is still open.
I know that some libraries like curl and openssl were not thread-safe,
which could have explained it.
The argument used in the post is that fitz is not mature.
That was in 2013.
There are some patches to solve this problem :
www.linuxfromscratch.org/patches/blfs/svn/mupdf-1.16.1-shared_libs-1.patch



Providing a static library is a choice of Artiflex.
It is not based on anything that can justify this choice.
What is more questionable is that debian validly chooses it!

Bug#955576: src:praat: fails to migrate to testing for too long: ftbfs mips64el

[Paul Gevers]

Source: praat
Version: 6.1.08-1
Severity: serious
Control: fixed -1 6.1.09-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:praat in its
current version in unstable has been trying to migrate for 62 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have marked the version in unstable as fixing this bug, so if that
version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=praat




signature.asc
Description: OpenPGP digital signature

Bug#955575: src:securefs: fails to migrate to testing for too long

[Paul Gevers]

Source: securefs
Version: 0.8.3+ds-1
Severity: serious
Control: fixed -1 0.9.0+ds-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:securefs in
its current version in unstable has been trying to migrate for 63 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have marked the version in unstable as fixing this bug, so if that
version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=securefs




signature.asc
Description: OpenPGP digital signature

Bug#955574: RFP: Canon Capture -- Tool for periodic image capturing with digital Canon cameras.

[Ben Tris]

Package: canon-capture
Severity: /wishlist/

//C    GPL2+

http://capture.sourceforge.net/

https://sourceforge.net/projects/capture/


Required (Not in Debian!?):
libptp2 (C  gpl3+)
libptp2 is a library used to communicate with PTP devices like still imaging 
cameras.
http://libptp.sourceforge.net/
https://sourceforge.net/projects/libptp/

Optional: ParseDate https://tracker.debian.org/pkg/libtime-parsedate-perl



signature.asc
Description: OpenPGP digital signature

Bug#955573: RM: python3-ffcx -- ROM; experimental not ready for unstable

[Drew Parsons]

Package: ftp.debian.org
Severity: normal

ffcx is part of the new FEniCS-X suite alongside dolfinx.  These
packages are still experimental, not yet ready for unstable.

ffcx 2019.2.0~git20200127.702a93e-1 slipped accidentally into unstable
(sorry) and is getting in the way of building the experimental
packages.

So please remove python3-ffcx 2019.2.0~git20200127.702a93e-1 from
unstable

(keep python3-ffcx 2019.2.0~git20200321.9ba5e24-1 in experimental)

Drew

Bug#955557: jemalloc: Please make autopkgtests cross-test-friendly

[Faidon Liambotis]

Hi Steve,

On Thu, Apr 02, 2020 at 07:58:05AM -0700, Steve Langasek wrote:
> In Ubuntu, we are in the process of moving the i386 architecture to a
> compatibility-only layer on amd64, and therefore we are also moving our
> autopkgtest infrastructure to test i386 binaries in a cross-environment.
> 
> This requires changes to some tests so that they are cross-aware and can do
> the right thing.
> 
> The jemalloc tests currently fail in this environment, because they include
> build tests that do not invoke the toolchain in a cross-aware manner, and do
> not declare their test dependencies in a cross-friendly matter.  I've
> verified that the attached patch lets the tests successfully build (and run)
> i386 tests on an amd64 host.

Thanks for the report and the associated patch. It looks simple enough,
so I'll make sure to include it in the next jemalloc upload.

Take care and stay safe!

Best,
Faidon

Bug#955551: openmsx ftbfs on ppc64el and s390x

[Matthias Klose]

On 4/2/20 6:43 PM, Wouter Vermaelen wrote:
> Hi,
> 
> I think the problem occurred on big-endian systems. Are ppc64el and s390x
> indeed big-endian? (IOW does the openMSX build system correctly detects
> this?)

no, ppc64el is little endian, s390x and ppc64 are big endian.

> I pushed a fix upstream:
> 
> https://github.com/openMSX/openMSX/commit/0c259566e5f7a9597369b66c03d957ba7d37e5d1
> This patch makes the big- and little-endian code paths more similar (it
> only keeps the essential differences).
> 
> I think this will fix the problem. But I have not been able to test-compile
> this myself.

both build still ftbfs:
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+sourcepub/11161164/+listing-archive-extra

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+build/19114396/+files/buildlog_ubuntu-focal-ppc64el.openmsx_0.15.0-2ubuntu1.1_BUILDING.txt.gz
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+build/19114397/+files/buildlog_ubuntu-focal-s390x.openmsx_0.15.0-2ubuntu1.1_BUILDING.txt.gz

Bug#955572: evolution: Gnome Online Account calendar not shown

[wargreen]

Package: evolution
Version: 3.36.1-1
Severity: normal

Dear Maintainer,


After upgrade to 3.36.1-1, the caldav calendars provided by Gnome Online
Account are not shown.
The GOA account seem correctly setup and is shown in the account window.

Remove / add the GOA account don't change anything.
Add the caldav account manualy work well.

Thank you for the work,
Wargreen



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

Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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 evolution depends on:
ii  dbus   1.12.16-2
ii  evolution-common   3.36.1-1
ii  evolution-data-server  3.36.1-1
ii  libc6  2.30-4
ii  libcamel-1.2-623.36.1-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.36.1-1
ii  libedataserver-1.2-24  3.36.1-1
ii  libevolution   3.36.1-1
ii  libglib2.0-0   2.64.1-1
ii  libgtk-3-0 3.24.14-1
ii  libical3   3.0.8-1
ii  libnotify4 0.7.9-1
ii  libsoup2.4-1   2.70.0-1
ii  libwebkit2gtk-4.0-37   2.28.0-2
ii  libxml22.9.10+dfsg-4
ii  psmisc 23.3-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.36.1-1
ii  evolution-plugin-pstimport   3.36.1-1
ii  evolution-plugins3.36.1-1
ii  yelp 3.34.0-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.20-1
ii  network-manager 1.22.10-1

-- no debconf information

Bug#955570: tor: Option NICE not used from /etc/default/tor

[intrigeri]

Hi,

Harri Suutari (2020-04-02):
> set, but the nicelevel is not used by the tor process.

/etc/default/tor also reads:

  # Note that this file is not being used for controlling Tor-startup
  # when Tor is launched by systemd.

So with systemd, I think you need to use LimitNICE=
(systemd.exec(5) manpage) in a drop-in override,
that you can generate for example with "systemctl edit".

Cheers!

Bug#955542: dh_installsystemd: Modifies maintainer scripts for units not listed

[Niels Thykier]

Guido Günther:
> Hi,
> [...]
>>
>> Hi,
>>
>> Is this considerably different from #841095?
> 
> No, i merged these already.
>  -- Guido
> 

Ok, thanks for confirming and apologies for overlooking the merge. :)

~Niels

Bug#955532: Deprecation warning in Ruby 2.7: URI.escape is obsolete

[Louis-Philippe Véronneau]

tag -1 patch

Hi,

I've made a stupid patch to fix this. I've tested it and it seems to
work fine.

I'm not a ruby dev though, so please review it :)

https://salsa.debian.org/puppet-team/puppet/-/merge_requests/2

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

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

[Harri Suutari]

Package: spamassassin
Version: 3.4.2-1+deb10u2
Severity: normal

Configuration file /etc/default/spamassassin has

# Set nice level of spamd
NICE="--nicelevel 15"

but the spamd processes do not use the nice value.





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

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

Versions of packages spamassassin depends on:
ii  adduser 3.118
ii  curl7.64.0-4+deb10u1
ii  init-system-helpers 1.56+nmu1
ii  libhtml-parser-perl 3.72-3+b3
ii  libhttp-date-perl   6.02-1
ii  libmail-dkim-perl   0.54-1
ii  libnet-dns-perl 1.19-1
ii  libnetaddr-ip-perl  4.079+dfsg-1+b3
ii  libsocket6-perl 0.29-1+b1
ii  libsys-hostname-long-perl   1.5-1
ii  libwww-perl 6.36-2
ii  lsb-base10.2019051400
ii  perl [libarchive-tar-perl]  5.28.1-6

Versions of packages spamassassin recommends:
ii  gnupg  2.2.12-1+deb10u1
ii  libio-socket-inet6-perl2.72-2
ii  libmail-spf-perl   2.9.0-4
ii  perl [libsys-syslog-perl]  5.28.1-6
pn  sa-compile 
ii  spamc  3.4.2-1+deb10u2

Versions of packages spamassassin suggests:
ii  libdbi-perl   1.642-1+b1
pn  libencode-detect-perl 
pn  libgeo-ip-perl
ii  libio-socket-ssl-perl 2.060-3
pn  libnet-patricia-perl  
ii  perl [libcompress-zlib-perl]  5.28.1-6
ii  pyzor 1:1.0.0-3
ii  razor 1:2.85-4.2+b5

-- Configuration Files:
/etc/default/spamassassin changed [not included]
/etc/spamassassin/local.cf changed [not included]
/etc/spamassassin/v320.pre changed [not included]

-- debconf information:
  spamassassin/upgrade/cancel: Continue
  spamassassin/upgrade/2.42u: No
  spamassassin/upgrade/2.42m: No
  spamassassin/upgrade/2.40:
  spamassassin/upgrade/2.40w:

Bug#955570: tor: Option NICE not used from /etc/default/tor

[Harri Suutari]

Package: tor
Version: 0.3.5.10-1
Severity: normal

File /etc/default/tor has

# If tor is seriously hogging your CPU, taking away too much cycles from
# other system resources, then you can renice tor.  See nice(1) for a
# bit more information.  Another way to limit the CPU usage of an Onion
# Router is to set a lower BandwidthRate, as CPU usage is mostly a function
# of the amount of traffic flowing through your node.  Consult the torrc(5)
# manual page for more information on setting BandwidthRate.
#
NICE="--nicelevel 17"

set, but the nicelevel is not used by the tor process.




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

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

Versions of packages tor depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libevent-2.1-6  2.1.8-stable-4
ii  liblzma55.2.4-1
ii  libseccomp2 2.3.3-4
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libsystemd0 241-7~deb10u3
ii  libzstd11.3.8+dfsg-3
ii  lsb-base10.2019051400
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.14.0-4
ii  tor-geoipdb  0.3.5.10-1
ii  torsocks 2.3.0-2

Versions of packages tor suggests:
ii  apparmor-utils   2.13.2-10
pn  mixmaster
pn  obfs4proxy   
ii  socat1.7.3.2-2
ii  tor-arm  2.1.0-2
ii  torbrowser-launcher  0.3.2-7~bpo10+1

-- Configuration Files:
/etc/default/tor changed [not included]
/etc/tor/torrc changed [not included]

Bug#955100: (no subject)

[Rene Engelhard]

Bcc: cont...@bugs.debian.org
Subject: Re: liborcus: FTBFS with Sphinx 2.4: TypeError: parse_declaration() 
missing 1 required positional argumeint: 'directiveType'
Reply-To: 
In-Reply-To: <20200327142619.ga4...@xanadu.blop.info>

tag 955111 - ftbfs
tag 955100 - ftbfs
clone 955111 -1
severity -1 wishlist
retitle -1 add Breaks against breathe << 4.13
reassign -1 src:sphinx
reassign 955111 src:breathe
reassign 955100 src:breathe
forcemerge 955111 955100  
retitle 955111 breathe needs updates for sphinx 2.0
affects 955111 liborcus,libixion
close 955111 4.14.1-1

Hi,

On Fri, Mar 27, 2020 at 03:26:19PM +0100, Lucas Nussbaum wrote:
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 276, in 
> > build_main
> > app.build(args.force_all, filenames)
> >   File "/usr/lib/python3/dist-packages/sphinx/application.py", line 337, in 
> > build
> > self.builder.build_all()
> >   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> > 260, in build_all
> > self.build(None, summary=__('all source files'), method='all')
> >   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> > 311, in build
> > updated_docnames = set(self.read())
> >   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> > 418, in read
> > self._read_serial(docnames)
> >   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> > 439, in _read_serial
> > self.read_doc(docname)
> >   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> > 479, in read_doc
> > doctree = read_doc(self.app, self.env, self.env.doc2path(docname))
> >   File "/usr/lib/python3/dist-packages/sphinx/io.py", line 316, in read_doc
> > pub.publish()
> >   File "/usr/lib/python3/dist-packages/docutils/core.py", line 217, in 
> > publish
> > self.document = self.reader.read(self.source, self.parser,
> >   File "/usr/lib/python3/dist-packages/sphinx/io.py", line 130, in read
> > self.parse()
> >   File "/usr/lib/python3/dist-packages/docutils/readers/__init__.py", line 
> > 77, in parse
> > self.parser.parse(self.input, document)
> >   File "/usr/lib/python3/dist-packages/sphinx/parsers.py", line 93, in parse
> > self.statemachine.run(inputlines, document, inliner=self.inliner)
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 171, in run
> > results = StateMachineWS.run(self, input_lines, input_offset,
> >   File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 241, 
> > in run
> > context, next_state, result = self.check_line(
> >   File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 459, 
> > in check_line
> > return method(match, context, next_state)
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 2770, in underline
> > self.section(title, source, style, lineno - 1, messages)
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 328, in section
> > self.new_subsection(title, lineno, messages)
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 394, in new_subsection
> > newabsoffset = self.nested_parse(
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 282, in nested_parse
> > state_machine.run(block, input_offset, memo=self.memo,
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 197, in run
> > results = StateMachineWS.run(self, input_lines, input_offset)
> >   File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 241, 
> > in run
> > context, next_state, result = self.check_line(
> >   File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 459, 
> > in check_line
> > return method(match, context, next_state)
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 2770, in underline
> > self.section(title, source, style, lineno - 1, messages)
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 328, in section
> > self.new_subsection(title, lineno, messages)
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 394, in new_subsection
> > newabsoffset = self.nested_parse(
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 282, in nested_parse
> > state_machine.run(block, input_offset, memo=self.memo,
> >   File "/usr/lib/python3/dist-packages/docutils/parsers/rst/states.py", 
> > line 197, in run
> > results = StateMachineWS.run(self, input_lines, input_offset)
> >   File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 241, 
> > in run
> > context, next_state, result = self.check_line(
> >   File "/usr/lib/python3/dist-packages/docutils/statemachine.py", line 459, 
> > in check_line
> > return 

Bug#955111: your mail

[Rene Engelhard]

Hi,

forcemerge 955087 955111 955100
thanks

On Thu, Apr 02, 2020 at 07:28:32PM +0200, Rene Engelhard wrote:
> reassign 955111 src:breathe
> reassign 955100 src:breathe
> forcemerge 955111 955100  
> retitle 955111 breathe needs updates for sphinx 2.0

Sorry, didn't see 955087 until now when looking for other bugs filed
against the "FTBFS"ing package whereeas one just needs the matching
breathe.

Merging.

Regards,

Rene

Bug#955543: Freeradius - Not working sysvinit script

[Jan Korbel]

Thanks for info, i found it now: #940608.

I think start-stop-daemon is cleaner but ok. We have freeradius in
production only, so we will test with Deb11 later ;-)

J.K.

On Thu, 2 Apr 2020 16:16:24 +0200
Bernhard Schmidt  wrote:

> Control: fixed -1 3.0.20+dfsg-1
> 
> Am 02.04.20 um 11:44 schrieb Jan Korbel:
> 
> Hi Jan,
> 
> > We have a problem with freeradius init script after upgrade to
> > up-to-date Deb10 with sysvinit. It is not possible to reload
> > configuration or stop daemon.  
> 
> Thanks for the report. This has already been fixed in unstable. You
> can pull in that version via buster-backports as well.
> 
> I'll have a look at fixing it with an upload to stable, but right now
> I don't have a Radius server on stable so I can't really test.
> 
> Bernhard

Bug#955568: dh_install (and friends?) doesn't(/don't) remove source dirs ending in slash

[Mihai Moldovan]

Package: debhelper
Version: 12.10

dh_install* takes a --sourcedir parameter which can be leveraged to pick data
from a specific destroot, which is very handy when building a package multiple
times with different features and creating conflicting binary packages.


Short example (pseudo-Makefile-code):

dh_auto_install --destdir=debian/destroot/variant1/
dh_auto_install --destdir=debian/destroot/variant2/

dh_install -ppkgvar1 --sourcedir=debian/destroot/variant1/
dh_install -ppkgvar2 --sourcedir=debian/destroot/variant2/


This example will fail to work correctly at the moment. It will pick files from
debian/destroot/variant{1,2} alright, but stage them into debian/pkgvar{1,2}/
WITH the specified destroot, creating paths such as
/debian/destroot/variant1/usr/bin/binary.

The compute_dest sub is supposed to remove the source dir part (either default
or user-specified), but won't handle paths ending in a slash correctly, or for
that matter remove anything at all.

Hence, passing --sourcedir=debian/destroot/variant{1,2} will work as expected.

The sourcedir input should probably be sanitized/canonicalized (not talking
about full pathname-and-symlink-canonicalization, which is a whole different
beast) so that the prefix is actually removed from the destination directory,
whether it ends in a slash, a hundred slashes or no slash at all.


This is applicable to at least dh_install, other helplets might also need such
fixes, though I haven't gone through the full dh_install* range to determine
which are broken and which aren't. dh_installexamples, for instance, is fine as
far as I can tell.



Mihai



signature.asc
Description: OpenPGP digital signature

Bug#785314: libjs-prototype: debian/control file needs updating to support multiarch dependencies

[Andreas Beckmann]

Followup-For: Bug #785314
Control: reopen -1

This issue is still reproducible and seems to require updates in more
packages.

In an up-to-date sid i386 + foreign amd64 chroot:

# apt-get install darktable:amd64
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 darktable:amd64 : Depends: libjs-prototype:amd64 but it is not installable
   Depends: libjs-scriptaculous:amd64 but it is not installable
E: Unable to correct problems, you have held broken packages.


Andreas

Bug#954823: hydrogen: Qt5 version available

[Alexandre Lymberopoulos]

Package: hydrogen
Version: 0.9.7-6
Followup-For: Bug #954823

Dear Maintainer,

Confirming that 1.0.0-beta2 is avaliable at



Is any help needed to package this new version. If so, I could help,
but need some guidance on this.

Thanks is advance,
Alexandre

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

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

Versions of packages hydrogen depends on:
ii  hydrogen-data 0.9.7-6
ii  libarchive13  3.4.0-2
ii  libasound21.2.2-2.1
ii  libc6 2.30-2
ii  libgcc-s1 [libgcc1]   10-20200324-1
ii  libgcc1   1:10-20200324-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libportaudio2 19.6.0-1
ii  libportmidi0  1:217-6
ii  libpulse0 13.0-5
ii  libqt4-network4:4.8.7+dfsg-20
ii  libqt4-xml4:4.8.7+dfsg-20
ii  libqt4-xmlpatterns4:4.8.7+dfsg-20
ii  libqtcore44:4.8.7+dfsg-20
ii  libqtgui4 4:4.8.7+dfsg-20
ii  libsndfile1   1.0.28-7
ii  libstdc++610-20200324-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages hydrogen recommends:
pn  hydrogen-doc   
ii  hydrogen-drumkits  2017.09.19~dfsg-1
pn  rubberband-cli 

Versions of packages hydrogen suggests:
pn  ladspa-plugin  

-- no debconf information

Bug#955567: kalgebra: Output is always blank

[Charles Samuels]

Package: kalgebra
Version: 4:17.08.3-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

KAlgebra shows nothing in its output screen. This only applies
to the algebraic displays, the graphs and dictionary tabs seem
to work fine.

Reproduce: Enter any equation into the input text box and press enter.

Expected: The result of the equation and the equation inputted should be 
visible.

Actual: Nothing appears. Even the border of the frame appears missing.

Also: Right clicking on the empty area causes a context menu to appear
in the wrong place. I'm not sure if that's related.


-- 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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kalgebra depends on:
ii  kalgebra-common  4:17.08.3-2
ii  kio  5.54.1-1
ii  libanalitza8 4:17.08.3-2+b3
ii  libanalitzagui8  4:17.08.3-2+b3
ii  libanalitzaplot8 4:17.08.3-2+b3
ii  libanalitzawidgets8  4:17.08.3-2+b3
ii  libc62.28-10
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5   5.11.3+dfsg1-1+deb10u3
ii  libqt5webenginewidgets5  5.11.3+dfsg-2+deb10u1
ii  libqt5widgets5   5.11.3+dfsg1-1+deb10u3
ii  libreadline7 7.0-5
ii  libstdc++6   8.3.0-6

kalgebra recommends no packages.

kalgebra suggests no packages.

-- no debconf information

Bug#955566: khmer: autopkgtest regression: undefined references

[Paul Gevers]

Source: khmer
Version: 2.1.2+dfsg-6
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Since 2019-11 the autopkgtest of khmer is failing. I copied some of the
output at the bottom of this report.

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

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/k/khmer/4760829/log.gz

+ pkg=khmer
+ [ /tmp/autopkgtest-lxc.zxrjb5bi/downtmp/autopkgtest_tmp =  ]
+ cd /tmp/autopkgtest-lxc.zxrjb5bi/downtmp/autopkgtest_tmp
+ pkg-config oxli --static --cflags
+ pkg-config oxli --static --libs
+ c++ -o test-prog-static -static -std=c++11 -I/usr/local/include
-I/usr/include/oxli/smhasher /usr/share/doc/khmer-common/test-compile.cc
-L/usr/local/lib -loxli -lbz2 -lz
+ ./test-prog-static
+ pkg-config oxli --cflags
+ pkg-config oxli --libs
+ c++ -o test-prog-dynamic -std=c++11 -I/usr/local/include
-I/usr/include/oxli/smhasher /usr/share/doc/khmer-common/test-compile.cc
-L/usr/local/lib -loxli
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzerror'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `deflateInit2_'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzeof'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `deflate'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `deflateEnd'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `crc32'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `inflate'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `inflateInit2_'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzclearerr'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `inflateEnd'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzopen64'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzwrite'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzopen'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `BZ2_bzWriteClose'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `BZ2_bzReadOpen'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `BZ2_bzRead'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzdirect'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzclose'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzdopen'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gzread'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `BZ2_bzWriteOpen'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `BZ2_bzReadClose'
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/liboxli.so:
undefined reference to `gztell64'
collect2: error: ld returned 1 exit status



signature.asc
Description: OpenPGP digital signature

Bug#955565: python3-b2sdk should depend on python3-arrow

[Thomas Ross]

Package: python3-b2sdk
Version: 1.0.2-1
Severity: important

The upstream b2sdk package depends on arrow[1], but the debian package does
not. This results in failure to import parts of the b2sdk:

$ python3
Python 3.7.6 (default, Jan 19 2020, 22:34:52)
[GCC 9.2.1 20200117] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from b2sdk.api import B2Api
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/b2sdk/api.py", line 13, in 
from .account_info.sqlite_account_info import SqliteAccountInfo
  File "/usr/lib/python3/dist-packages/b2sdk/account_info/__init__.py", line 
11, in 
from .in_memory import InMemoryAccountInfo
  File "/usr/lib/python3/dist-packages/b2sdk/account_info/in_memory.py", line 
12, in 
from .upload_url_pool import UrlPoolAccountInfo
  File "/usr/lib/python3/dist-packages/b2sdk/account_info/upload_url_pool.py", 
line 15, in 
from .abstract import AbstractAccountInfo
  File "/usr/lib/python3/dist-packages/b2sdk/account_info/abstract.py", line 
15, in 
from b2sdk.raw_api import ALL_CAPABILITIES
  File "/usr/lib/python3/dist-packages/b2sdk/raw_api.py", line 25, in 
from .b2http import B2Http
  File "/usr/lib/python3/dist-packages/b2sdk/b2http.py", line 13, in 
import arrow
ModuleNotFoundError: No module named 'arrow'

Installing the python3-arrow package fixes this issue.

[1]: 
https://github.com/Backblaze/b2-sdk-python/blob/1707190972a5d6807c7d928dd5d295dce6920915/requirements.txt#L1-L2

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

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

Versions of packages python3-b2sdk depends on:
ii  python33.7.5-3
ii  python3-logfury0.1.2-3
ii  python3-pkg-resources  44.0.0-1
ii  python3-requests   2.22.0-2
ii  python3-six1.14.0-2
ii  python3-tqdm   4.43.0-1

python3-b2sdk recommends no packages.

python3-b2sdk suggests no packages.

-- no debconf information

Bug#955564: img2pdf: arm64 autopktest fails: ./test.sh: 84: j: parameter not set

[Paul Gevers]

Source: img2pdf
Version: 0.3.3-1
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: always-fail

Dear maintainer(s),

The img2pdf autopkgtest fails on arm64 with the output I copied below

Please investigate and fix the test to pass on arm64.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/i/img2pdf/4689537/log.gz

+ set -eu
+ mktemp --directory --tmpdir img2pdf.XX
+ tempdir=/tmp/img2pdf.oAbGzOLTss
+ trap error EXIT
+ convert -size 60x60 ( xc:none -fill red -draw circle 30,21 30,3
-gaussian-blur 0x3 ) ( ( xc:none -fill lime -draw circle 39,39 36,57
-gaussian-blur 0x3 ) ( xc:none -fill blue -draw circle 21,39 24,57
-gaussian-blur 0x3 ) -compose plus -composite ) -compose plus -composite
-strip /tmp/img2pdf.oAbGzOLTss/alpha.png
+ convert /tmp/img2pdf.oAbGzOLTss/alpha.png -background black -alpha
remove -alpha off -strip /tmp/img2pdf.oAbGzOLTss/normal16.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal16.png -depth 8 -strip
/tmp/img2pdf.oAbGzOLTss/normal.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal.png -negate -strip
/tmp/img2pdf.oAbGzOLTss/inverse.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal16.png -colorspace Gray -depth
16 -strip /tmp/img2pdf.oAbGzOLTss/gray16.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal16.png -colorspace Gray -dither
FloydSteinberg -colors 256 -depth 8 -strip /tmp/img2pdf.oAbGzOLTss/gray8.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal16.png -colorspace Gray -dither
FloydSteinberg -colors 16 -depth 4 -strip /tmp/img2pdf.oAbGzOLTss/gray4.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal16.png -colorspace Gray -dither
FloydSteinberg -colors 4 -depth 2 -strip /tmp/img2pdf.oAbGzOLTss/gray2.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal16.png -colorspace Gray -dither
FloydSteinberg -colors 2 -depth 1 -strip /tmp/img2pdf.oAbGzOLTss/gray1.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal.png -dither FloydSteinberg
-colors 2 -define png:exclude-chunk=bkgd -strip
/tmp/img2pdf.oAbGzOLTss/palette1.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal.png -dither FloydSteinberg
-colors 4 -define png:exclude-chunk=bkgd -strip
/tmp/img2pdf.oAbGzOLTss/palette2.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal.png -dither FloydSteinberg
-colors 16 -define png:exclude-chunk=bkgd -strip
/tmp/img2pdf.oAbGzOLTss/palette4.png
+ convert /tmp/img2pdf.oAbGzOLTss/normal.png -dither FloydSteinberg
-colors 256 -define png:exclude-chunk=bkgd -strip
/tmp/img2pdf.oAbGzOLTss/palette8.png
+ cd /tmp/img2pdf.oAbGzOLTss
+ md5sum --check --status -
+ cat
+ error
./test.sh: 84: j: parameter not set



signature.asc
Description: OpenPGP digital signature

Bug#955551: openmsx ftbfs on ppc64el and s390x

[Wouter Vermaelen]

Hi,

I think the problem occurred on big-endian systems. Are ppc64el and s390x
indeed big-endian? (IOW does the openMSX build system correctly detects
this?)

I pushed a fix upstream:

https://github.com/openMSX/openMSX/commit/0c259566e5f7a9597369b66c03d957ba7d37e5d1
This patch makes the big- and little-endian code paths more similar (it
only keeps the essential differences).

I think this will fix the problem. But I have not been able to test-compile
this myself.

Thanks for reporting.


Wouter



On Thu, Apr 2, 2020 at 3:09 PM Matthias Klose  wrote:

> Package: src:openmsx
> Version:
> Severity: serious
> Tags: sid bullseye
>
> openmsx ftbfs at least on ppc64el and s390x with
>
> src/utils/small_compare.hh: In instantiation of ‘struct ScValBe int,
> '\357', '\273', '\277'>’:
> src/utils/small_compare.hh:88:41:   required from ‘struct ScVal int,
> '\357', '\273', '\277'>’
> src/utils/small_compare.hh:100:37:   required from ‘const type
> SmallCompare<'\357', '\273', '\277'>::mask’
> src/utils/small_compare.hh:110:20:   required from ‘bool
> small_compare(const
> char*) [with char ...Ns = {'\357', '\273', '\277'}]’
> src/utils/rapidsax.hh:208:34:   required from ‘bool
> rapidsax::internal::next(const char*) [with char C0 = '\357'; char C1 =
> '\273';
> char C2 = '\277']’
> src/utils/rapidsax.hh:353:51:   required from here
> src/utils/small_compare.hh:84:41: error: narrowing conversion of ‘-1’ from
> ‘int’
> to ‘unsigned int’ [-Wnarrowing]
>84 | template struct ScValBe : ScValBeImpl 0, -1,
> Ns...> {};
>   | ^~~
> src/utils/small_compare.hh: In instantiation of ‘const type
> SmallCompare<'\357',
> '\273', '\277'>::mask’:
>
> and
>
> src/utils/small_compare.hh: In instantiation of ‘const type
> SmallCompare<'t',
> ';'>::value’:
> src/utils/small_compare.hh:110:32:   required from ‘bool
> small_compare(const
> char*) [with char ...Ns = {'t', ';'}]’
> src/utils/rapidsax.hh:204:30:   required from ‘bool
> rapidsax::internal::next(const char*) [with char C0 = 't'; char C1 = ';']’
> src/utils/rapidsax.hh:281:22:   required from ‘char*
> rapidsax::internal::skipAndExpand(char*&) [with StopPred =
> rapidsax::internal::AttPred1; StopPredPure =
> rapidsax::internal::AttPurePred1;
> int FLAGS = 2]’
> src/utils/rapidsax.hh:704:52:   required from ‘void
> rapidsax::internal::Parser::parseAttributes(char*&, bool)
> [with
> int FLAGS = 2; HANDLER = openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:387:3:   required from ‘void
> rapidsax::internal::Parser::parseDeclaration(char*&) [with
> int
> FLAGS = 2; HANDLER = openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:575:5:   required from ‘void
> rapidsax::internal::Parser::parseNode(char*&) [with int
> FLAGS =
> 2; HANDLER = openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:377:4:   required from
> ‘rapidsax::internal::Parser HANDLER>::Parser(HANDLER&, char*) [with int FLAGS = 2; HANDLER =
> openmsx::XMLLoader::XMLElementParser]’
> src/utils/rapidsax.hh:731:35:   required from ‘void
> rapidsax::parse(HANDLER&,
> char*) [with int FLAGS = 2; HANDLER =
> openmsx::XMLLoader::XMLElementParser]’
> src/config/XMLLoader.cc:46:64:   required from here
> src/utils/small_compare.hh:99:37: error: ‘value’ is not a member of
> ‘SmallCompare<'t', ';'>::C’ {aka ‘ScVal’}
>99 |  static const typename Loader::type value = C::value;
>   | ^
> make[2]: *** [build/main.mk:531:
> derived/s390-linux-debian/obj/config/XMLLoader.o] Error 1
>
>

Bug#955555: gitlab: uninitialized constant APIGuard

[Pirate Praveen]

Control: fixed -1 12.8.6-1

On 2020, ഏപ്രിൽ 2 8:05:53 PM IST, Dragos Jarca  
wrote:
>Package: gitlab
>Version: 12.6.8-3
>Severity: grave
>Tags: a11y
>Justification: renders package unusable
>
>Dear Maintainer,
>
>I upgraded packages:
>
>Start-Date: 2020-04-02  10:00:27
>Commandline: apt-get dist-upgrade
>Install: libllvm10:amd64 (1:10.0.0-1, automatic), ruby-sync:amd64 
>(0.5.0-2, automatic)
>Upgrade: libpython3.7-minimal:amd64 (3.7.7-1, 3.7.7-1+b1), 
>python3-werkzeug:amd64 (0.16.1+dfsg1-1, 0.16.1+dfsg1-2), 
>glib-networking-services:amd64 (2.64.0-1, 2.64.1-1), 
>libpython3.8-dbg:amd64 (3.8.2-1, 3.8.2-1+b1), libpython3.8-dev:amd64 
>(3.8.2-1, 3.8.2-1+b1), php-phpseclib:amd64 (2.0.25-1, 2.0.26-1), 
>libgirepository-1.0-1:amd64 (1.62.0-5+b1, 1.64.0-2), 
>libpython3.8-minimal:amd64 (3.8.2-1, 3.8.2-1+b1), glib-networking:amd64
>
>(2.64.0-1, 2.64.1-1), dash:amd64 (0.5.10.2-6, 0.5.10.2-7), 
>ruby-memoist:amd64 (0.16.2-1, 0.16.2-2), ruby-tins:amd64 (1.1.0-1, 
>1.1.0-2), libhiredis0.14:amd64 (0.14.0-6, 0.14.1-1), libffi-dev:amd64 
>(3.3-3, 3.3-4), libdbd-pg-perl:amd64 (3.10.4-1, 3.10.5-1),
>yarnpkg:amd64 
>(1.19.1-1, 1.21.1-2), nodejs:amd64 (10.17.0~dfsg-2, 10.19.0~dfsg-3), 
>libpython3.8:amd64 (3.8.2-1, 3.8.2-1+b1), python3.7:amd64 (3.7.7-1, 
>3.7.7-1+b1), python3.8:amd64 (3.8.2-1, 3.8.2-1+b1), 
>ruby-mini-magick:amd64 (4.9.2-1.1, 4.9.5-2), bubblewrap:amd64 (0.4.0-1,
>
>0.4.1-1), node-d3-quadtree:amd64 (1.0.6-2, 1.0.7-1), libpq5:amd64 
>(12.2-1+b1, 12.2-4), libpython3.7-stdlib:amd64 (3.7.7-1, 3.7.7-1+b1), 
>glib-networking-common:amd64 (2.64.0-1, 2.64.1-1), 
>python3.7-minimal:amd64 (3.7.7-1, 3.7.7-1+b1), 
>ruby-state-machines-activemodel:amd64 (0.5.1-3, 0.7.1-2), 
>libpq-dev:amd64 (12.2-1+b1, 12.2-4), npm:amd64 (6.14.2+ds-2, 
>6.14.3+ds-1), python3-future:amd64 (0.18.2-1, 0.18.2-2), 
>postgresql-12:amd64 (12.2-1+b1, 12.2-4), gir1.2-glib-2.0:amd64 
>(1.62.0-5+b1, 1.64.0-2), python3.8-minimal:amd64 (3.8.2-1, 3.8.2-1+b1),
>
>python3-acme:amd64 (1.1.0-1, 1.3.0-2), libconfuse-common:amd64 
>(3.2.2+dfsg-1, 3.2.2+dfsg-2), ruby-omniauth:amd64 (1.9.0-1, 1.9.1-1), 
>shared-mime-info:amd64 (1.10-1, 1.15-1), libnode-dev:amd64 
>(10.17.0~dfsg-2, 10.19.0~dfsg-3), libwnck-3-0:amd64 (3.32.0-1, 
>3.36.0-1), ruby-warden:amd64 (1.2.3-2, 1.2.8-1), 
>libpython3.8-stdlib:amd64 (3.8.2-1, 3.8.2-1+b1), libnode64:amd64 
>(10.17.0~dfsg-2, 10.19.0~dfsg-3), libwnck-3-common:amd64 (3.32.0-1, 
>3.36.0-1), libpcap0.8:amd64 (1.9.1-2, 1.9.1-3), libffi7:amd64 (3.3-3, 
>3.3-4), python3.8-dbg:amd64 (3.8.2-1, 3.8.2-1+b1), python3.8-dev:amd64 
>(3.8.2-1, 3.8.2-1+b1), libconfuse2:amd64 (3.2.2+dfsg-1, 3.2.2+dfsg-2), 
>postgresql-client-12:amd64 (12.2-1+b1, 12.2-4)
>End-Date: 2020-04-02  10:05:57
>
>Start-Date: 2020-04-02  10:14:16
>Commandline: apt-get -t unstable install gitlab-shell
>Upgrade: gitlab-shell:amd64 (10.3.0+debian-3.1, 11.0.0+debian-2)
>End-Date: 2020-04-02  10:14:37
>
>After that gitlab stop starting.
>
>The error is:
>
>rake aborted!
>NameError: uninitialized constant APIGuard

Please use gitlab from experimental. Its a lot of work to backport patches to 
get grape 1.3 working with 12.6.x.

Also please always check wiki.debian.org/gitlab for any work arounds.

>/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:32:in `instance_eval'
>/usr/share/gitlab/lib/api/api.rb:5:in `'
>/usr/share/gitlab/lib/api/api.rb:4:in `'
>/usr/share/gitlab/lib/api/api.rb:3:in `'
>/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies/interlock.rb:14:in
>
>`block in loading'
>/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/concurrency/share_lock.rb:151:in
>
>`exclusive'
>/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies/interlock.rb:13:in
>
>`loading'
>(eval):4:in `draw_route'
>/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:32:in `instance_eval'
>/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:32:in `draw_route'
>/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:19:in `draw_ce'
>/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:13:in `draw'
>/usr/share/gitlab/config/routes.rb:171:in `block in '
>/usr/share/rubygems-integration/all/gems/actionpack-5.2.4.1/lib/action_dispatch/routing/route_set.rb:432:in
>
>`instance_exec'
>/usr/share/rubygems-integration/all/gems/actionpack-5.2.4.1/lib/action_dispatch/routing/route_set.rb:432:in
>
>`eval_block'
>/usr/share/rubygems-integration/all/gems/actionpack-5.2.4.1/lib/action_dispatch/routing/route_set.rb:414:in
>
>`draw'
>/usr/share/gitlab/config/routes.rb:4:in `'
>/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application/routes_reloader.rb:41:in
>
>`block in load_paths'
>/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application/routes_reloader.rb:41:in
>
>`each'
>/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application/routes_reloader.rb:41:in
>
>`load_paths'

Bug#955563: RM: libpbihdf libpbdata -- RoQA; NBS; cruft

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

please remove the libpbihdf libpbdata cruft packages from sid.

 libpbdata | 5.3.1+dfsg-2.1+b1 | amd64, arm64, mips64el, ppc64el
 libpbihdf | 5.3.1+dfsg-2.1+b1 | amd64, arm64, mips64el, ppc64el

sid is now at src:pbseqlib 5.3.3+dfsg-4

This is a false positive:

  Checking reverse dependencies...
  # Broken Depends:
  pbseqlib: libpbseq

since the old arch:all libpbseq is still around ...


Andreas

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

[Matthias Klumpp]

On Mon, 22 Jul 2019 19:39:10 +0200 Jo Drexl  wrote:

[...]
I've seen this error being persistent on some machines, while others
were thrown off repeatedly. A popular suggestion on the internet is to
comment out the test statement and proceed without a refreshed appstream
cache, which seems to work, so I suggest this being rolled out at least
to Debian Stretch.


This is a pretty terrible suggestion, because doing so will break every 
software center application on the system, possibly in subtle ways.
A much better solution is to actually find the culprit and fix it - 
usually the issue is a PPA or 3rd-party repository injecting invalid 
metadata, or some other application on the system installing invalid data.
Try `sudo appstreamcli refresh --force --verbose` to get information on 
what's going on (or attach the log to a bug report in case you are 
experiencing this issue again).


In the case of newer Debian releases, the issue is actually a regression 
in GNOME Software, which is fixed now, once again.


Cheers,
Matthias

Bug#955562: RM: cylc/experimental -- RoQA; NVIU; switched from arch:any to arch:all

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

please remove the cruft src:cylc from experimental:

cylc | 8.0~a1-1  | experimental | source, all
cylc | 8.0~a1-3  | unstable | source
cylc-flow| 8.0~a1-3  | unstable | all
python3-cylc | 8.0~a1-1  | experimental | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x
python3-cylc | 8.0~a1-3  | unstable | all


Andreas

Bug#955561: src:r-cran-rmarkdown: fails to migrate to testing for too long

[Paul Gevers]

Source: r-cran-rmarkdown
Version: 1.15+dfsg-1
Severity: serious
Control: fixed -1 2.1+dfsg-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:r-cran-rmarkdown in its current version in unstable has been trying
to migrate for 66 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have marked the version in unstable as fixing this bug, so if that
version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=r-cran-rmarkdown




signature.asc
Description: OpenPGP digital signature

Bug#952062: openjfx: Patch to use -Wno-error=deprecated-declarations

[Bas Couwenberg]

Source: openjfx
Version: 11.0.2+1-1
Tags: patch
Followup-For: Bug #952062

Dear Maintainer,

Using -Werror is great for CI, not so much for unstable where compiler
updates tend cause breakage like this.

The attached patch adds -Wno-error=deprecated-declarations to fix the
FTBFS.

Kind Regards,

Bas
diff -Nru openjfx-11.0.2+1/debian/changelog openjfx-11.0.2+1/debian/changelog
--- openjfx-11.0.2+1/debian/changelog   2019-01-20 16:25:28.0 +0100
+++ openjfx-11.0.2+1/debian/changelog   2020-04-02 16:56:59.0 +0200
@@ -1,3 +1,11 @@
+openjfx (11.0.2+1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix FTBFS due to -Werror=deprecated-declarations.
+(closes: #952062)
+
+ -- Bas Couwenberg   Thu, 02 Apr 2020 16:56:59 +0200
+
 openjfx (11.0.2+1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
openjfx-11.0.2+1/debian/patches/no-error_deprecated-declarations.patch 
openjfx-11.0.2+1/debian/patches/no-error_deprecated-declarations.patch
--- openjfx-11.0.2+1/debian/patches/no-error_deprecated-declarations.patch  
1970-01-01 01:00:00.0 +0100
+++ openjfx-11.0.2+1/debian/patches/no-error_deprecated-declarations.patch  
2020-04-02 16:53:26.0 +0200
@@ -0,0 +1,14 @@
+Description: Fix FTBFS due to -Werror=deprecated-declarations.
+Author: Bas Couwenberg 
+Bug-Debian: https://bugs.debian.org/952062
+
+--- a/buildSrc/linux.gradle
 b/buildSrc/linux.gradle
+@@ -45,6 +45,7 @@ def commonFlags = [
+ "-fno-strict-aliasing", "-fPIC", "-fno-omit-frame-pointer", // 
optimization flags
+ "-fstack-protector",
+ "-Wno-error=cast-function-type",
++"-Wno-error=deprecated-declarations",
+ "-Wextra", "-Wall", "-Wformat-security", "-Wno-unused", 
"-Wno-parentheses", "-Werror=implicit-function-declaration"] // warning flags
+ 
+ commonFlags.addAll("dpkg-buildflags --get CPPFLAGS  
".execute().text.trim().split(" "))
diff -Nru openjfx-11.0.2+1/debian/patches/series 
openjfx-11.0.2+1/debian/patches/series
--- openjfx-11.0.2+1/debian/patches/series  2019-01-20 00:35:49.0 
+0100
+++ openjfx-11.0.2+1/debian/patches/series  2020-04-02 16:50:51.0 
+0200
@@ -15,3 +15,4 @@
 26-disable-webkit-jit-for-armv4.patch
 29-glibc-compatibility.patch
 disable-jit-for-non-x86.patch
+no-error_deprecated-declarations.patch

Bug#955560: ITP: minetest-mod-throwing-arrows -- Minetest mod - Throwables

[Julien Puydt]

Package: wnpp
Severity: wishlist

* Package name: minetest-mod-throwing-arrows
  Version : 1.1
  Upstream Author : Eurythmia team
* URL : https://github.com/minetest-mods/throwing_arrows
* License : MPL-2.0
  Programming Lang: lua
  Description : Minetest mod - Throwables
 This minetest extension provides basic bows and arrows.
 .
 It is based on the framework of the minetest-mod-throwing package.


In fact, what is now the minetest-mod-throwing package contains both a
framework and an implementation, and upstream split it in two
repositories.

So the minetest-mod-throwing 1.1-1 will only contain the framework, and
the new package minetest-mod-throwing-arrows 1.1-1 will be the
implementation.

I plan to maintain it within the Debian Games team like the other
minetest-mod-* packages I contribute to.

Cheers,

J.Puydt

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

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


-- 
Regards
Sudip

Bug#955542: dh_installsystemd: Modifies maintainer scripts for units not listed

[Guido Günther]

Hi,
On Thu, Apr 02, 2020 at 04:25:27PM +0200, Niels Thykier wrote:
> Guido Günther:
> > Hi,
> > On Thu, Apr 02, 2020 at 12:15:34PM +0200, Guido Günther wrote:
> >> control: affects -1 libvirtd-daemon-system
> >>
> >> Hi,
> >> On Thu, Apr 02, 2020 at 11:42:55AM +0200, Guido Günther wrote:
> >>> Package: debhelper
> >>> Version: 12.10
> >>> Severity: normal
> >>>
> >>> ```
> >>> [...]
> >>> ```
> >>>
> >>> But it generates
> >>>
> >>> ```
> >>> [...]
> >>> ```
> >>>
> >>> although it should only do so for libvirtd.service itself.
> >>
> >> I tried to exclude these using '-X' but that did not work either. They
> >> seem to mostly match what libvird has listed in Wants/Requires:
> >>
> >> Requires=virtlogd.socket
> >> Requires=virtlockd.socket
> >> # Use Wants instead of Requires so that users
> >> # can disable these three .socket units to revert
> >> # to a traditional non-activation deployment setup
> >> Wants=libvirtd.socket
> >> Wants=libvirtd-ro.socket
> >> Wants=libvirtd-admin.socket
> >>
> >> but libvirtd-admin.socket is missing. The reason i came across this is
> >> #955483 where i'd like to avoid that the socket units are restarted at
> >> all.
> > 
> > It's not Wants/Require but the ones listed in 'Also=' - this is
> > preblemati since the ordering is wrong  (see 955483)
> > Cheers
> >  -- Guido
> > 
> 
> Hi,
> 
> Is this considerably different from #841095?

No, i merged these already.
 -- Guido

Bug#955559: Fix util-linux/hwclock for glibc 2.31

[Mauricio Oliveira]

Package: src/util-linux
Version: 2.34-0.1

There's an upstream fix needed in util-linux/hwclock for glibc
2.31/settimeofday() (currently in experimental.)

Older glibc:

$ sudo hwclock -s
$ echo $?
0

Newer glibc:

$ sudo hwclock -s
hwclock: settimeofday() failed: Invalid argument
$ echo $?
1

With patch [1]:

$ sudo ./hwclock -s
$ echo $?
0

commit cd781c405be82540484da3bfe3d3f17a39b8eb5c
Author: J William Piggott 
Date: Fri Feb 21 20:03:47 2020 -0500

hwclock: make glibc 2.31 compatible

Currently not yet tagged, v2.35+.

[1] 
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=cd781c405be82540484da3bfe3d3f17a39b8eb5c

Hope this helps,

-- 
Mauricio Faria de Oliveira

Bug#955471: theano: test failures

[Rebecca N. Palmer]

Control: severity -1 normal
Control: tags -1 upstream patch pending
Control: forwarded -1 https://github.com/Theano/theano/pull/6749

On closer inspection, this isn't a "silently wrong answer" bug after 
all, so lowering the severity.  Some parts of it appear to be caused by 
numpy 1.17 and some parts by scipy 1.3.

Bug#955558: npmjs.com version is using embedded copy of jquery at 1.9.0

[Pirate Praveen]

This may need to be adapted to our node-jquery version which is at 3.4.0

Bug#955558: node-jquery.waitforimages broken Uncaught TypeError: Cannot read property 'dataset' of null

[Pirate Praveen]

Package: node-jquery.waitforimages
Version: 2.4.0+ds-5
Severity: grave
Justification: breaks its only reverse dependency gitlab

gitlab's web ui does not show list of files and web console has this 
error,


index.js?d252:17 Uncaught TypeError: Cannot read property 'dataset' of 
null

   at jQuery.fn.init.eval (index.js?d252:17)
   at jQuery.fn.init.$.fn.waitForImages 
(jquery.waitforimages.js?d87d:180)

   at HTMLDocument.eval (index.js?d252:17)

More details https://gitlab.com/gitlab-org/gitlab/-/issues/213120

Switching to jquery.waitforimages from npmjs.com fixes the problem.

Bug#955554: vpnc-scripts: mark as Multi-Arch: foreign

[Luca Boccassi]

Control: tags -1 patch

On Thu, 2020-04-02 at 15:09 +0100, Luca Boccassi wrote:
> Package: vpnc-scripts
> Version: 0.1~git20190117-1
> Severity: normal
> 
> Dear Maintainer,
> 
> vpnc-scripts is arch: all and the maintainers confirm it doesn't have
> any architecture-specific bits. Its binary dependency is iproute2,
> which also doesn't have any architecture-specific interfaces.
> 
> Therefore, it can be marked as Multi-Arch: foreign. The use case was
> requested by one of the maintainers, and it's to be able to easily
> test
> openconnect:i386 on an amd64 image - i386 images are becoming rarer
> and
> rarer.
> 
> I have tested it in a chroot and it seems to behave as expected.

Mike, if it's OK with you, I'd like to offer help and join as an
uploader for vpnc-scripts too, as it comes from openconnect as well.

MR to do that, new version and a few other cleanups:

https://salsa.debian.org/debian/vpnc-scripts/-/merge_requests/4

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#955557: jemalloc: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: jemalloc
Version: 5.2.1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Faidon,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The jemalloc tests currently fail in this environment, because they include
build tests that do not invoke the toolchain in a cross-aware manner, and do
not declare their test dependencies in a cross-friendly matter.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru jemalloc-5.2.1/debian/tests/01.compile-and-run-test-program.t 
jemalloc-5.2.1/debian/tests/01.compile-and-run-test-program.t
--- jemalloc-5.2.1/debian/tests/01.compile-and-run-test-program.t   
2019-01-07 18:37:43.0 -0800
+++ jemalloc-5.2.1/debian/tests/01.compile-and-run-test-program.t   
2020-04-02 00:05:25.0 -0700
@@ -4,8 +4,14 @@
 
 . /usr/share/sharness/sharness.sh
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+  CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+  CROSS_COMPILE=
+fi
+
 test_expect_success "compile test program against libjemalloc" "
-  gcc ../ex_stats_print.c -o ex_stats_print -ljemalloc
+  ${CROSS_COMPILE}gcc ../ex_stats_print.c -o ex_stats_print -ljemalloc
 "
 test_expect_success "run test program" "
  ./ex_stats_print
diff -Nru jemalloc-5.2.1/debian/tests/control 
jemalloc-5.2.1/debian/tests/control
--- jemalloc-5.2.1/debian/tests/control 2019-01-07 18:37:43.0 -0800
+++ jemalloc-5.2.1/debian/tests/control 2020-04-02 00:06:07.0 -0700
@@ -1,2 +1,2 @@
 Tests: run-tests
-Depends: @,gcc,perl,libc6-dev,sharness
+Depends: @, build-essential, perl:native, sharness:native

Bug#955555: gitlab: uninitialized constant APIGuard

[Dragos Jarca]

Package: gitlab
Version: 12.6.8-3
Severity: grave
Tags: a11y
Justification: renders package unusable

Dear Maintainer,

I upgraded packages:

Start-Date: 2020-04-02  10:00:27
Commandline: apt-get dist-upgrade
Install: libllvm10:amd64 (1:10.0.0-1, automatic), ruby-sync:amd64 
(0.5.0-2, automatic)
Upgrade: libpython3.7-minimal:amd64 (3.7.7-1, 3.7.7-1+b1), 
python3-werkzeug:amd64 (0.16.1+dfsg1-1, 0.16.1+dfsg1-2), 
glib-networking-services:amd64 (2.64.0-1, 2.64.1-1), 
libpython3.8-dbg:amd64 (3.8.2-1, 3.8.2-1+b1), libpython3.8-dev:amd64 
(3.8.2-1, 3.8.2-1+b1), php-phpseclib:amd64 (2.0.25-1, 2.0.26-1), 
libgirepository-1.0-1:amd64 (1.62.0-5+b1, 1.64.0-2), 
libpython3.8-minimal:amd64 (3.8.2-1, 3.8.2-1+b1), glib-networking:amd64 
(2.64.0-1, 2.64.1-1), dash:amd64 (0.5.10.2-6, 0.5.10.2-7), 
ruby-memoist:amd64 (0.16.2-1, 0.16.2-2), ruby-tins:amd64 (1.1.0-1, 
1.1.0-2), libhiredis0.14:amd64 (0.14.0-6, 0.14.1-1), libffi-dev:amd64 
(3.3-3, 3.3-4), libdbd-pg-perl:amd64 (3.10.4-1, 3.10.5-1), yarnpkg:amd64 
(1.19.1-1, 1.21.1-2), nodejs:amd64 (10.17.0~dfsg-2, 10.19.0~dfsg-3), 
libpython3.8:amd64 (3.8.2-1, 3.8.2-1+b1), python3.7:amd64 (3.7.7-1, 
3.7.7-1+b1), python3.8:amd64 (3.8.2-1, 3.8.2-1+b1), 
ruby-mini-magick:amd64 (4.9.2-1.1, 4.9.5-2), bubblewrap:amd64 (0.4.0-1, 
0.4.1-1), node-d3-quadtree:amd64 (1.0.6-2, 1.0.7-1), libpq5:amd64 
(12.2-1+b1, 12.2-4), libpython3.7-stdlib:amd64 (3.7.7-1, 3.7.7-1+b1), 
glib-networking-common:amd64 (2.64.0-1, 2.64.1-1), 
python3.7-minimal:amd64 (3.7.7-1, 3.7.7-1+b1), 
ruby-state-machines-activemodel:amd64 (0.5.1-3, 0.7.1-2), 
libpq-dev:amd64 (12.2-1+b1, 12.2-4), npm:amd64 (6.14.2+ds-2, 
6.14.3+ds-1), python3-future:amd64 (0.18.2-1, 0.18.2-2), 
postgresql-12:amd64 (12.2-1+b1, 12.2-4), gir1.2-glib-2.0:amd64 
(1.62.0-5+b1, 1.64.0-2), python3.8-minimal:amd64 (3.8.2-1, 3.8.2-1+b1), 
python3-acme:amd64 (1.1.0-1, 1.3.0-2), libconfuse-common:amd64 
(3.2.2+dfsg-1, 3.2.2+dfsg-2), ruby-omniauth:amd64 (1.9.0-1, 1.9.1-1), 
shared-mime-info:amd64 (1.10-1, 1.15-1), libnode-dev:amd64 
(10.17.0~dfsg-2, 10.19.0~dfsg-3), libwnck-3-0:amd64 (3.32.0-1, 
3.36.0-1), ruby-warden:amd64 (1.2.3-2, 1.2.8-1), 
libpython3.8-stdlib:amd64 (3.8.2-1, 3.8.2-1+b1), libnode64:amd64 
(10.17.0~dfsg-2, 10.19.0~dfsg-3), libwnck-3-common:amd64 (3.32.0-1, 
3.36.0-1), libpcap0.8:amd64 (1.9.1-2, 1.9.1-3), libffi7:amd64 (3.3-3, 
3.3-4), python3.8-dbg:amd64 (3.8.2-1, 3.8.2-1+b1), python3.8-dev:amd64 
(3.8.2-1, 3.8.2-1+b1), libconfuse2:amd64 (3.2.2+dfsg-1, 3.2.2+dfsg-2), 
postgresql-client-12:amd64 (12.2-1+b1, 12.2-4)

End-Date: 2020-04-02  10:05:57

Start-Date: 2020-04-02  10:14:16
Commandline: apt-get -t unstable install gitlab-shell
Upgrade: gitlab-shell:amd64 (10.3.0+debian-3.1, 11.0.0+debian-2)
End-Date: 2020-04-02  10:14:37

After that gitlab stop starting.

The error is:

rake aborted!
NameError: uninitialized constant APIGuard
/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:32:in `instance_eval'
/usr/share/gitlab/lib/api/api.rb:5:in `'
/usr/share/gitlab/lib/api/api.rb:4:in `'
/usr/share/gitlab/lib/api/api.rb:3:in `'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies/interlock.rb:14:in 
`block in loading'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/concurrency/share_lock.rb:151:in 
`exclusive'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/dependencies/interlock.rb:13:in 
`loading'

(eval):4:in `draw_route'
/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:32:in `instance_eval'
/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:32:in `draw_route'
/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:19:in `draw_ce'
/usr/share/gitlab/lib/gitlab/patch/draw_route.rb:13:in `draw'
/usr/share/gitlab/config/routes.rb:171:in `block in '
/usr/share/rubygems-integration/all/gems/actionpack-5.2.4.1/lib/action_dispatch/routing/route_set.rb:432:in 
`instance_exec'
/usr/share/rubygems-integration/all/gems/actionpack-5.2.4.1/lib/action_dispatch/routing/route_set.rb:432:in 
`eval_block'
/usr/share/rubygems-integration/all/gems/actionpack-5.2.4.1/lib/action_dispatch/routing/route_set.rb:414:in 
`draw'

/usr/share/gitlab/config/routes.rb:4:in `'
/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application/routes_reloader.rb:41:in 
`block in load_paths'
/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application/routes_reloader.rb:41:in 
`each'
/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application/routes_reloader.rb:41:in 
`load_paths'
/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application/routes_reloader.rb:20:in 
`reload!'
/usr/share/rubygems-integration/all/gems/railties-5.2.4.1/lib/rails/application.rb:168:in 
`reload_routes!'
/usr/share/gitlab/config/application.rb:283:in `block in 
'
/usr/share/rubygems-integration/all/gems/activesupport-5.2.4.1/lib/active_support/lazy_load_hooks.rb:69:in 
`block in execute_hook'

Bug#955556: libgnutls30: DTLS client hello contains a random value of all zeroes

[Luca Boccassi]

Package: libgnutls30
Version: 3.6.3-1
Severity: important
X-Debbugs-CC: secur...@debian.org
Tags: security patch buster bullseye

Dear Maintainer(s),

A security issue has been identified in GnuTLS:

https://gitlab.com/gnutls/gnutls/-/issues/960
https://www.gnutls.org/security-new.html#GNUTLS-SA-2020-03-31

It was reported in the open, so opening a bug here. There will probably
be a CVE soon-ish, as upstream requested one.

The DTLS client implementation is supposed so send a random 32 bytes
token, but it sends all zeros between versions 3.6.3 and 3.6.12
included, so Buster is affected, but Stretch and earlier are not.

Upstream commit that fixes the issue:

https://gitlab.com/gnutls/gnutls/-/commit/c01011c2d8533dbbbe754e49e256c109cb848d0d

-- 
Kind regards,
Luca Boccassi


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

Bug#937565: pytest-runner: diff for NMU version 2.11.1-1.2

[Sandro Tosi]

Control: tags 937565 + patch


Dear maintainer,

I've prepared an NMU for pytest-runner (versioned as 2.11.1-1.2). The diff
is attached to this message.

Regards.

diff -Nru pytest-runner-2.11.1/debian/changelog pytest-runner-2.11.1/debian/changelog
--- pytest-runner-2.11.1/debian/changelog	2018-09-27 13:35:32.0 -0400
+++ pytest-runner-2.11.1/debian/changelog	2020-04-02 10:40:58.0 -0400
@@ -1,3 +1,10 @@
+pytest-runner (2.11.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937565
+
+ -- Sandro Tosi   Thu, 02 Apr 2020 10:40:58 -0400
+
 pytest-runner (2.11.1-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru pytest-runner-2.11.1/debian/control pytest-runner-2.11.1/debian/control
--- pytest-runner-2.11.1/debian/control	2018-09-27 13:35:32.0 -0400
+++ pytest-runner-2.11.1/debian/control	2020-04-02 10:40:38.0 -0400
@@ -5,10 +5,6 @@
 Uploaders: Brian May ,
 Build-Depends: debhelper (>= 9),
dh-python (>= 2.20160609~),
-   python-all,
-   python-pytest,
-   python-setuptools,
-   python-setuptools-scm,
python3-all,
python3-pytest,
python3-setuptools,
@@ -18,18 +14,6 @@
 Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/pytest-runner.git
 Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/pytest-runner.git
 
-Package: python-pytest-runner
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
- python-pkg-resources,
- python-setuptools,
-Description: Invoke py.test as distutils command with dependency resolution - Python 2.x
- Setup scripts can use pytest-runner to add setup.py test support for pytest
- runner.
- .
- This package contains the Python 2 module.
-
 Package: python3-pytest-runner
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru pytest-runner-2.11.1/debian/rules pytest-runner-2.11.1/debian/rules
--- pytest-runner-2.11.1/debian/rules	2017-07-11 03:56:07.0 -0400
+++ pytest-runner-2.11.1/debian/rules	2020-04-02 10:40:47.0 -0400
@@ -4,7 +4,7 @@
 export PYBUILD_NAME=pytest-runner
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installchangelogs:
 	dh_installchangelogs CHANGES.rst

Bug#955542: dh_installsystemd: Modifies maintainer scripts for units not listed

[Niels Thykier]

Guido Günther:
> Hi,
> On Thu, Apr 02, 2020 at 12:15:34PM +0200, Guido Günther wrote:
>> control: affects -1 libvirtd-daemon-system
>>
>> Hi,
>> On Thu, Apr 02, 2020 at 11:42:55AM +0200, Guido Günther wrote:
>>> Package: debhelper
>>> Version: 12.10
>>> Severity: normal
>>>
>>> ```
>>> [...]
>>> ```
>>>
>>> But it generates
>>>
>>> ```
>>> [...]
>>> ```
>>>
>>> although it should only do so for libvirtd.service itself.
>>
>> I tried to exclude these using '-X' but that did not work either. They
>> seem to mostly match what libvird has listed in Wants/Requires:
>>
>> Requires=virtlogd.socket
>> Requires=virtlockd.socket
>> # Use Wants instead of Requires so that users
>> # can disable these three .socket units to revert
>> # to a traditional non-activation deployment setup
>> Wants=libvirtd.socket
>> Wants=libvirtd-ro.socket
>> Wants=libvirtd-admin.socket
>>
>> but libvirtd-admin.socket is missing. The reason i came across this is
>> #955483 where i'd like to avoid that the socket units are restarted at
>> all.
> 
> It's not Wants/Require but the ones listed in 'Also=' - this is
> preblemati since the ordering is wrong  (see 955483)
> Cheers
>  -- Guido
> 

Hi,

Is this considerably different from #841095?

~Niels

Bug#795244: ca-certificates-java.jar - String index out of range: -1

[Luca Capello]

tags 795244 + patch
thanks

Hi there,

On Thu, 12 Apr 2018 16:11:08 +0200, Raphael Hertzog wrote:
> On Wed, 12 Aug 2015, Christian Hammers wrote:
> > It does not work though:
> > 
> > # java -Xmx64m -jar 
> > /usr/share/ca-certificates-java/ca-certificates-java.jar -storepass changeit
> 
> That's because the program expects data on standard input. A list of
> certificates to add (prefixed with "+") or remove (prefixed with "-").
> 
> I'm not sure that there's a real issue here.

Thus, what is the purpose of the same command in
/etc/ca-certificates/update.d/jks-keystore?  As the reporter said the
command line was taken from that file.  Disclaimer: I am not a Java
expert...

While the /usr/share/doc/ca-certificates-java/README.Debian says that
the package "doesn't automagically handle local certificates" (as
Michael Shuler noted[1]), the solution is quite simple and can be
directly taken from postinst:
```
diff --git a/ca-certificates/update.d/jks-keystore 
b/ca-certificates/update.d/jks-keystore
index e0c3445..b5744ce 100755
--- a/ca-certificates/update.d/jks-keystore
+++ b/ca-certificates/update.d/jks-keystore
@@ -79,7 +79,19 @@ do_cleanup()
 fi
 }
 
-if java -Xmx64m -jar $JAR -storepass "$storepass"; then
+## 
+find /etc/ssl/certs -name \*.pem | \
+while read filename; do
+alias=$(basename $filename .pem | tr A-Z a-z | tr -cs a-z0-9 _)
+alias=${alias%*_}
+if [ -n "$FIXOLD" ]; then
+echo "-${alias}"
+echo "-${alias}_pem"
+fi
+echo "+${filename}"
+ done | \
+ java -Xmx64m -jar $JAR -storepass "$storepass"
+if [ $? -eq 0 ]; then
 do_cleanup
 else
 do_cleanup
```

[1] 

The only drawback is that the cacerts default keystore will be updated
at every invocation of update-ca-certificates.

I am aware that the very same README advises to uses
`update-ca-certificates -f` for a full re-import, but IMHO the patch
proposed is more consistent with the "normal" update-ca-certificates
behavior.

Thx, bye,
Luca

-- 
Dr. Luca Capello
Ingénieur HPC
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour
Tél +41 22 379 72 42 | Bureau 151
https://hpc-community.unige.ch
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#955543: Freeradius - Not working sysvinit script

[Bernhard Schmidt]

Control: fixed -1 3.0.20+dfsg-1

Am 02.04.20 um 11:44 schrieb Jan Korbel:

Hi Jan,

> We have a problem with freeradius init script after upgrade to
> up-to-date Deb10 with sysvinit. It is not possible to reload
> configuration or stop daemon.

Thanks for the report. This has already been fixed in unstable. You can
pull in that version via buster-backports as well.

I'll have a look at fixing it with an upload to stable, but right now I
don't have a Radius server on stable so I can't really test.

Bernhard

Bug#787277: [ca-certificates] error on upgrade

[Luca Capello]

Hi Paride,.

On Sat, 30 May 2015 20:12:54 +, Paride Desimone wrote:
> today, I have upgraded sid.
> ca-certificates it has report:
> 
> Elaborazione dei trigger per ca-certificates (20150426)...
> Updating certificates in /etc/ssl/certs...
> 13 added, 6 removed; done.
> Running hooks in /etc/ca-certificates/update.d...
> 
> org.debian.security.InvalidKeystorePasswordException: Cannot open
> Java keystore. Is the password correct?

The output above is the expected behavior when changing the keystore
password without storing it in the "storepass" variable in
/etc/default/cacerts:

  

If you have not modified the default password, 20150426 is quite old,
I had not installed it on any of my machines, so I can not check old
logs.  However, I have successfully upgraded from 20170929~deb9u1 to
20170929~deb9u3 (thus within stretch) and from 20170929~deb9u3 to
20190405 (stretch to buster), thus I would say that this bug could be
closed.

Thx, bye,
Luca

-- 
Dr. Luca Capello
Ingénieur HPC
Division du Système et des Technologies de l'Information et de la Communication
Université de Genève | 24 rue Général-Dufour
Tél +41 22 379 72 42 | Bureau 151
https://hpc-community.unige.ch
mailto:luca.cape...@unige.ch


signature.asc
Description: PGP signature

Bug#955554: vpnc-scripts: mark as Multi-Arch: foreign

[Luca Boccassi]

Package: vpnc-scripts
Version: 0.1~git20190117-1
Severity: normal

Dear Maintainer,

vpnc-scripts is arch: all and the maintainers confirm it doesn't have
any architecture-specific bits. Its binary dependency is iproute2,
which also doesn't have any architecture-specific interfaces.

Therefore, it can be marked as Multi-Arch: foreign. The use case was
requested by one of the maintainers, and it's to be able to easily test
openconnect:i386 on an amd64 image - i386 images are becoming rarer and
rarer.

I have tested it in a chroot and it seems to behave as expected.

-- 
Kind regards,
Luca Boccassi


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