Bug#982802: libio-html-perl: autopkgtest failure

[Adrian Bunk]

Source: libio-html-perl
Version: 1.004-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/libi/libio-html-perl/10422807/log.gz

...
t/00-all_prereqs.t .. 
not ok 1 - opened META.json
1..1
Failed 1/1 subtests 
...
Test Summary Report
---
t/00-all_prereqs.t (Wstat: 0 Tests: 1 Failed: 1)
  Failed test:  1
Files=5, Tests=141,  1 wallclock secs ( 0.05 usr  0.01 sys +  0.33 cusr  0.03 
csys =  0.42 CPU)
Result: FAIL
autopkgtest [15:04:02]: test autodep8-perl-build-deps: ---]
autopkgtest [15:04:02]: test autodep8-perl-build-deps:  - - - - - - - - - - 
results - - - - - - - - - -
autodep8-perl-build-deps FAIL non-zero exit status 1
...

Bug#979764: nfs-common: NFSv4 with mit kerberos sec. mounts fail after kernel update 5.9 to 5.10

[Tobias Jachowski]

I observe the same behavior when upgrading the kernel from 5.9 to 5.10 
((server: buster amd64, clients: bullseye amd64). However, probably 
interesting to note that even when upgrading the server to bullseye and 
subsequently the kernel to 5.10 I'm also not able to mount kerberized 
NFS shares. The error I see on the server is:


rpc.svcgssd[17476]: ERROR: GSS-API: error in handle_nullreq: 
gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure.  Minor 
code may provide more information) - Encryption type arcfour-hmac not 
permitted




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Jérémy Lal]

Le dim. 14 févr. 2021 à 17:33, Leopold Palomo-Avellaneda 
a écrit :

> Hi Mechtilde,
>
>
> El 14/2/21 a les 14:41, Mechtilde Stehmann ha escrit:
> > Hello Leopold,
> > hello all,
> >
> > does it also build at buildd after a source only upload.
>
> ok
>
> > At the official build machines it is n't allowed to install a package
> > which isn't called in debian/control beside the essential build packages.
>
> yes, you are right.
>
> > You have to call *all needed* packages for building in debian/control.
> > Otherwise it can't be build at the official build machines.
>
> Yes, it's true. But, this is not the case. It call all the dependencies
> to build the package. But it fails *before* you call pbuilder in a clean
> env.
>
> > This should be ensured by pbuilder. You have to be able to build in a
> > clean pbuilder chroot.
>
> I have a pbuilder installation to build packages. I'm using pbuilder,
> and I built a lot of backports to myself. The server where I run
> pbuilder is a Debian stable with several packages installed, nothing
> important. Without sphinx-common, when I try to build paperwork, from
> salsa I got:
>
> $ pdebuild
> W: /root/.pbuilderrc does not exist
> dpkg-checkbuilddeps: error: Unmet build dependencies: python3-sphinx
> python3-sphinxcontrib.plantuml sphinx-doc
> W: Unmet build-dependency in source
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying
> 0001-Search-for-data-files-in-system-folders.patch
> dpkg-source: info: applying
> 0002-Show-all-page-at-once-until-python3-getkey-gets-pack.patch
> dpkg-source: info: applying
> 0003-Disable-potentially-dangerous-plugins.patch
> dh clean --with python3,sphinxdoc --buildsystem=pybuild
> dh: error: unable to load addon sphinxdoc: Can't locate
> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install
> the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains:
> /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
> /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28
> /usr/share/perl/5.28 /usr/local/lib/site_perl
> /usr/lib/x86_64-linux-gnu/perl-base) at (eval 15) line 1.
> BEGIN failed--compilation aborted at (eval 15) line 1.
>
> make: *** [debian/rules:38: clean] Error 25
>
> Before, pbuilder is call. However, if I install sphinx-common and run
> again pbuilder paperwork is built.
>
> Another thing is if you really need to call:
>
>  dh $@ --with python3,sphinxdoc --buildsystem=pybuild
>
> with sphinxdoc.
>
> In any case, salsa C-I is passed and doesn't fail, and AFAIK they use a
> similar env as build machines. Please, DD, push this package. It would
> be a pity that we don't have this version in Bullseye.
>
> Best regards,
>
> Leopold
>
>
> > Kind regards
> >
> > Mechtilde
> >
> > Am 14.02.21 um 14:15 schrieb Leopold Palomo-Avellaneda:
> >> Mechtilde,
> >>
> >>
> >> El 14/2/21 a les 14:04, Mechtilde Stehmann ha escrit:
> >>
> >> [...]
> >>
> >>> dh clean --with python3,sphinxdoc --buildsystem=pybuild
> >>> dh: error: unable to load addon sphinxdoc: Can't locate
> >>> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to
> install
> >>> the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains:
> >>> /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1
> >>> /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32
> >>> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base
> >>> /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32
> >>> /usr/local/lib/site_perl) at (eval 14) line 1.
> >>> BEGIN failed--compilation aborted at (eval 14) line 1.
> >>
> >> [...]
> >>
> >>
> >> IMHO the problem that you have here is that you have not installed in
> >> the box where you run pbuilder or gbp the package sphinx-common.
> >>
> >> That package contains the file
> >> sphinx-common: /usr/share/perl5/Debian/Debhelper/Sequence/sphinxdoc.pm
> >>
> >> that needs Debhelper to prepare the package to be built.
> >>
> >> I have backported paperwork without any problem.
> >>
> >> Best regards,
> >>
> >> Leopold
>

Hello,

i'll go ahead. However there is a high chance it won't migrate to testing,
due to soft freeze policy as Thomas pointed out. Let's see.

Jérémy

Bug#982803: procps: broken alternative for /usr/bin/w left on the system

[Sven Joachim]

Package: procps
Version: 2:3.3.17-3

This version of procps no longer installs an alternative for /usr/bin/w,
but the existing alternative is not cleaned up:

,
| $ LANG=C update-alternatives --display w
| update-alternatives: warning: alternative /usr/bin/w.procps (part of link 
group w) doesn't exist; removing from list of alternatives
| w - auto mode
|   link best version not available
|   link currently points to /usr/bin/w.procps
|   link w is /usr/bin/w
|   slave w.1.gz is /usr/share/man/man1/w.1.gz
| $ dpkg -S /usr/bin/w
| procps: /usr/bin/w
`

Removing the broken alternative in the prerm script does not work,
because dpkg runs the old version's prerm on upgrades, not the new one.
This should be done in the postinst instead.


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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libncurses6  6.2+20201114-2
ii  libncursesw6 6.2+20201114-2
ii  libprocps8   2:3.3.17-3
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0

Versions of packages procps recommends:
ii  psmisc  23.4-2

procps suggests no packages.

-- no debconf information

Bug#981338: self signed ssl cert unusuable after upgrade

[Joey Hess]

Sudip Mukherjee wrote:
> I was looking into this error and this has been caused by an upstream
> commit which is supposed to be an improvement for new users. More
> details at 
> https://github.com/OfflineIMAP/offlineimap3/issues/41#issuecomment-778798223.
> 
> The attached patch should fix this.
> 
> @Joey Hess It will be great if you test the patch and confirm if it
> fixes your problem.

It does, but only after I fixed an unrelated problem:

OfflineIMAP 7.3.0
  Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception)
imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i  8 Dec 2020
Account sync joey:
 *** Processing account joey
 Establishing connection to kitenet.net:993 (kite)
 ERROR: While attempting to sync account 'joey'
  sequence item 2: expected str instance, bytes found
 *** Finished account 'joey' in 0:03
ERROR: Exceptions occurred during the run!
ERROR: While attempting to sync account 'joey'
  sequence item 2: expected str instance, bytes found

Traceback:
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in 
syncrunner
self.__sync()
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in __sync
remoterepos.getfolders()
  File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line 646, in 
getfolders
imapobj = self.imapserver.acquireconnection()
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 592, in 
acquireconnection
self.__authn_helper(imapobj)
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 449, in 
__authn_helper
if func(imapobj):
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 375, in 
__authn_plain
imapobj.authenticate('PLAIN', self.__plainhandler)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 691, in authenticate
typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 1684, in 
_simple_command
return self._command_complete(self._command(name, *args), kw)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 1404, in _command
literal = literator(data, rqb)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 2247, in process
ret = self.mech(self.decode(data))
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 217, in 
__plainhandler
retval = NULL.join((authz, authc, passwd))

Which seems to be caused by remotepassfile being set, pointing at a file
that contained a password in plain text. I unset that and it prompted
for the password and worked.

(Also I remember seeing this "expected str instance" failure before,
when I was trying lots of config file changes to work around the ssl cert
problem, so one of those changes must have worked at the time. I don't 
remember what change it was.)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#982559: xscorch Build-Depends on libreadline-gplv2-dev which has been removed

[Chris Hofstaedtler]

* peter green  [210214 17:52]:
> I would thus propose simply dropping the build-dependency, a debdiff doing 
> that is
> attached, I may or may not NMU it later.

I'd suggest you do the NMU (soon), as Jacob apparently hasn't been
active for a while.

Thanks,
Chris

Bug#982804: libvirt_node_get_cpu_stats segmentation fault

[Lorenzo Vanoni]

Package: php-libvirt-php
Version: 0.5.4-3

When I use libvirt_node_get_cpu_stats it results in a segmentation fault.:

$ tail /var/log/apache2/error.log
[...]
[Sun Feb 14 18:32:36.232927 2021] [core:notice] [pid 14362] AH00052:
child pid 16391 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:36.233078 2021] [core:notice] [pid 14362] AH00052:
child pid 16393 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:36.233112 2021] [core:notice] [pid 14362] AH00052:
child pid 16394 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:37.235464 2021] [core:notice] [pid 14362] AH00052:
child pid 16395 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:37.235580 2021] [core:notice] [pid 14362] AH00052:
child pid 16396 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:37.235612 2021] [core:notice] [pid 14362] AH00052:
child pid 16397 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:37.235642 2021] [core:notice] [pid 14362] AH00052:
child pid 16398 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:37.235674 2021] [core:notice] [pid 14362] AH00052:
child pid 16399 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:37.235704 2021] [core:notice] [pid 14362] AH00052:
child pid 16400 exit signal Segmentation fault (11)
[Sun Feb 14 18:32:37.235732 2021] [core:notice] [pid 14362] AH00052:
child pid 16401 exit signal Segmentation fault (11)

To recreate, insert the following line of code:


I also tried with libvirt_node_get_cpu_stats($conn, 1), but with the
same result.

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Leopold Palomo-Avellaneda]

El 14/2/21 a les 18:07, Jérémy Lal ha escrit:
[...]
> 
> 
> Hello,
> 
> i'll go ahead. However there is a high chance it won't migrate to testing,
> due to soft freeze policy as Thomas pointed out. Let's see.

Release Team has sent and email explaining the sate of bullseye. There's
a part that says:

--
General
===

As always, talk to us, preferably via the bts, if you experience issues
that we need to be aware of or where you need help. Please be aware it's
now a very busy time for us, so bear with us.

--


So, Thomas Perret, as maintainer, please follow that advice and put in
contact with Release Team and explain the situation.

Leopold


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Bug#982809: ITP: dodge-the-creeps -- Dodge the Creeps! tutorial game for the Godot engine

[beuc]

Package: wnpp
Owner: pkg-games-de...@lists.alioth.debian.org
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: dodge-the-creeps
  Version : 3.2
  Upstream Author : http://kidscancode.org/contact.html
* URL : 
http://docs.godotengine.org/en/latest/getting_started/step_by_step/your_first_game.html
* License : MIT
  Programming Lang: GDScript
  Description : Dodge the Creeps! tutorial game for the Godot engine

This game is a companion to the Godot Engine Getting Started Guide.
It is a game intended to demonstrate the following fundamental
concepts of Godot development:
 * Node and scene structure
 * Instancing scenes
 * Input
 * Signals
 * UI
This package serves as a sample Debian packaging for Godot games.

Package development happens at:
https://salsa.debian.org/games-team/dodge-the-creeps

Bug#982810: prometheus-homeplug-exporter: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: prometheus-homeplug-exporter
Version: 0.3.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for prometheus-homeplug-exporter's debconf 
messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-

prometheus-homeplug-exporter_0.3.0-2_pt.po.gz
Description: application/gzip

Bug#982811: prometheus-smokeping-prober: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: prometheus-smokeping-prober
Version: 0.4.1-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for prometheus-smokeping-prober's debconf 
messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


prometheus-smokeping-prober_0.4.1-2_pt.po.gz
Description: application/gzip

Bug#980899: [pkg-php-pear] Bug#980899: php-illuminate-database: CVE-2021-21263 Query Binding Exploitation

[David Prévot]

Control: reassign -1 src:php-illuminate-database

I filled the bug against the binary package, that has been superseded by
src:php-laravel-framework and thus missed the expected audience, sorry
about that.

Le Tue, Feb 02, 2021 at 11:20:06AM -0400, David Prévot a écrit :
> Le 23/01/2021 à 18:49, David Prévot a écrit :
> > Package: php-illuminate-database
> > Version: 5.7.27-1
> […]
> > A quick look at the php-illuminate-database code, as shipped in stable,
> > makes me think that it is probably vulnerable to CVE-2021-21263 as fixed
> > in 6.20.11
> 
> Also, since the CVE-2021-21263 fix was incomplete, upstream released another
> security update as 6.20.14.
> 
> https://github.com/laravel/framework/security/advisories/GHSA-x7p5-p2c9-phvg
> 
> Regards
> 
> David


signature.asc
Description: PGP signature

Bug#982803: procps: broken alternative for /usr/bin/w left on the system

[Craig Small]

On Mon, 15 Feb 2021 at 04:27, Sven Joachim  wrote:

> This version of procps no longer installs an alternative for /usr/bin/w,
> but the existing alternative is not cleaned up:
>
Unless you install it twice (like I did) which is why it looked fine for me.


> Removing the broken alternative in the prerm script does not work,
> because dpkg runs the old version's prerm on upgrades, not the new one.
> This should be done in the postinst instead.
>
Yep, makes sense.

 - Craig

Bug#975207: ping!

[Louis-Philippe Véronneau]

Ping!

This bug has been fixed, but the package won't make it in testing before
it is autoremoved.

This should reset the autoremoval timer.

Cheers,

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982816: src:bats: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: bats
Version: 1.1.0+git104-g1c83a1b-1.1
Severity: serious
Control: close -1 1.2.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 980967

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:bats has been
trying to migrate for 59 days [2]. Hence, I am filing this bug, albeit
one day early.

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 immediately closed this bug with the version in unstable, 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=bats




OpenPGP_signature
Description: OpenPGP digital signature

Bug#982823: debian-faq: [INTL:pt] Partial Portuguese translation

[Américo Monteiro]

Package: debian-faq
Version: 
Tags: l10n, patch
Severity: wishlist

Hi
I was working on this translation when it was removed from po4a translation 
requests... 

I don't know were this translation was moved to, but as I got half work done 
here, you might want 
to merge my strings (half work) into the package and somebody else can finish 
it...

or you can put the package back in po4a so I can finish my work

Feel free to use this file.


-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


debian-faq_9.0_debian-faq.pt.po.gz
Description: application/gzip

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

[Thomas Goirand]

On 2/14/21 8:48 AM, Evgeni Golov wrote:
> On Sat, Feb 13, 2021 at 11:57:52PM +0100, Thomas Lange wrote:
>> IMO we cannot know which device name is used  by the users virtualisation 
>> environment.
>> So, what is the be setting without knowing the device name?
>>
>> Or is /dev/sda used in most enviroments?
> 
> For VirtualBox sda is a pretty safe bet, for libvirt it'd be either sda
> or vda (and I think we could set both in debconf, as that's a
> multiselect)

If you select multiple devices, it's going to fail on all the devices
which aren't present.

> AWS has another one, vxda I think? But this explicit bug
> is about vagrant (so virtualbox and libvirt) only anyways.

No, this but isn't specifically about vagrant. On top of this, libvirt
or AWS aren't virtualization environment, and even more, this depends on
the *driver*, not on the virtualization environment. Indeed, for a
single virtualization environment (for example KVM), you may have more
than one driver available (for example with kvm: virtio-blk or virtio-scsi).

> The only thing to consider with this approach: it should only be done
> when preparing images, not installing "real" systems. So in the
> cloud.d.o context that's safe, but probably not as a generic default in
> FAI and other tools.

Unfortunately, the image *must* be able to work with multiple drivers
(see my example with virtio-blk and virtio-scsi). The safest approach
was to have no default device set, though now it fails...

Cheers,

Thomas Goirand (zigo)

Bug#982253: netkit telnetd: ship with bullseye with open security problems?

[Andreas Henriksson]

Hello,

On Sun, Feb 07, 2021 at 09:06:28PM +0100, Salvatore Bonaccorso wrote:
[...]
> > 2) possibly unpatched exploit here: 
> > https://www.exploit-db.com/exploits/48170
> 
> JFTR, this one was CVE-2020-10188 and in Debian was fixed in earlier
> times.
> 
> Replacing telnetd package with an empy package and depending on
> inetutils-telnetd: is it possible to basically interchangably replace
> those two? If so this might be an option but I'm not sure if at this
> stage of the preparations for bullseye it might be too late.

It's not like inetutils is a shining example of perfectness either.

#945861 inetutils: CVE-2019-0053

The inetutils also doesn't ship all tools and recommends
using existing ones including netkit (eg. in #672295).

It also seems to lack features compared to netkit alternatives
(eg. SSL).

... "pest eller kolera" ...

It seems like Christoph Biedl who did the last NMU has considered
adopting the package. Hopefully if that happened the situation around
netkit could improve.

> 
> > 1) open bug #974428, causes telnetd to crash, remotely triggerable
> 
> The first issue, if there a verified patch might be good to fix in
> time for bullseye.

I've pondered uploading the posted patch and since the last maintainer
upload was in 2016 I'd orphan the package while doing so but I'll
consider hijacking it on Christoph Biedl's behalf if he's interested
in maintaining it still.

Unless there's a conclusion about this bug report I don't really see
much point in proceeding though.

Regards,
Andreas Henriksson

Bug#982692: gemma: FTBFS: dh_auto_test: error: make -j1 check returned exit code 2

[Andreas Tille]

Control: severity -1 important
Control: tags -1 moreinfo
Control: tags -1 unreproducible


On Sat, Feb 13, 2021 at 06:12:12PM +0100, Lucas Nussbaum wrote:
> Source: gemma
> Version: 0.98.4+dfsg-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210213 ftbfs-bullseye
> 
> > ...
> > Ran 13 tests.
> > 
> > FAILED (failures=4)

Neither Nilesh nor I can reproduce this.  Any more info?

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#982059: Bug#982372: Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de

[Helge Kreutzmann]

Hello Craig,
On Sun, Feb 14, 2021 at 09:29:12PM +1100, Craig Small wrote:
> OK, found a minor problem.  The procps version needs an epoch to correctly
> match. Not 3.3.17-1 but 2:3.3.17-1

First things first: manpages-l10n passed NEW!

To minimize the impact, I suggest that I prepare and upload 4.9.1-3, 
with just the corrected epoch for procps.

If you have any (further) comments on this, then please let me know
asap, otherwise I perform the upload latest tomorrow evening. I'll
update the unblock request accordingly.

I suggest that manpages-l10n 4.9.2 is not shipped, I also did not have
the time to investigate the build failure.

Thanks for spotting and feedback.

Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#982740: pulseaudio: FTBFS on ppc64el

[Andres Salomon]

On Sun, 14 Feb 2021 19:27:03 +0200
Adrian Bunk  wrote:
> > 
> > FAIL: cpu-volume-test
> > =
> > 
> > Running suite(s): CPU
> > 0%: Checks: 1, Failures: 1, Errors: 0
> > tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
> > FAIL cpu-volume-test (exit status: 1)
> > 
> > 
> > 
> > It's worth noting that 14.1-1 built just fine on ppc64el, and the
> > only non-debian change between 14.1 and 14.2 is this:
> >...  
> 
> Both versions fail for me the same way on plummer.
> 
> Adding debian-powerpc so that a porter can check.
> 
> cu
> Adrian

Thanks for verifying. Building (either version) with an older version of
the 'check' package would be the next step, so we can narrow down
what's breaking it.

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

[mh]

Am Sun, 14 Feb 2021 17:35:47 +
schrieb Brian Potkin :

> On Sun 14 Feb 2021 at 17:44:20 +0100, mh wrote:
> 
> > Am Sun, 14 Feb 2021 15:39:51 +
> > schrieb Brian Potkin :
> >   
> > > The whole point is that the printer installion is done via
> > > ipp-usb, which you have shown is active on your machine. There is
> > > no need for you to select a PPD or a vendor driver.  
> > 
> > If I could have all features my printer offers available this way,
> > then yes. OTOH the whole problem does not seam to be the protocol
> > used, but cups administration not seeing the printer. 
> > 
> > Is there a way to completly resett systemd/udev/avahi/whatever?
> > Month ago I tried "apt install --reinstall systemd udev" as an
> > attempt to exclude any malfunction.  
> 
> Is avahi-daemon active?
> 
>   systemctl status avahi-daemon

Yes.

# systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
 Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled;
vendor preset: enabled) Active: active (running) since Sun 2021-02-14
14:01:53 CET; 4h 38min ago TriggeredBy: ● avahi-daemon.socket
   Main PID: 711 (avahi-daemon)
 Status: "avahi-daemon 0.8 starting up."
  Tasks: 2 (limit: 4634)
 Memory: 1.7M
CPU: 402ms
 CGroup: /system.slice/avahi-daemon.service
 ├─711 avahi-daemon: running [neutower.local]
 └─749 avahi-daemon: chroot helper

Feb 14 14:01:51 neutower avahi-daemon[711]: Found user 'avahi' (UID
106) and group 'avahi' (GID 114). Feb 14 14:01:51 neutower
avahi-daemon[711]: Successfully dropped root privileges. Feb 14
14:01:51 neutower avahi-daemon[711]: avahi-daemon 0.8 starting up. Feb
14 14:01:53 neutower avahi-daemon[711]: Successfully called chroot().
Feb 14 14:01:53 neutower avahi-daemon[711]: Successfully dropped
remaining capabilities. Feb 14 14:01:53 neutower avahi-daemon[711]:
Loading service file /services/apt-cacher-ng.service. Feb 14 14:01:53
neutower avahi-daemon[711]: Network interface enumeration completed.
Feb 14 14:01:53 neutower avahi-daemon[711]: Server startup complete.
Host name is neutower.local. Local service cookie is 294> Feb 14
14:01:53 neutower avahi-daemon[711]: Service "apt-cacher-ng proxy on
neutower" (/services/apt-cacher-ng.service) succe> Feb 14 14:01:53
neutower systemd[1]: Started Avahi mDNS/DNS-SD Stack. lines 1-23/23
(END)


> 
> Do you have a firewall?

No.

> 
> Regards,
> 
> Brian.

Greetings

Michael

Bug#982805: mate-desktop-environment: black boxes around title bar letters

[Tad Whiteside]

Package: mate-desktop-environment
Version: 1.20.0+5
Severity: normal

Dear Maintainer,

   * What led up to the situation?  Create a window with large number of 
letters in  title bar
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Resize window horizontally
   * What was the outcome of this action? black boxes appear around letters
   * What outcome did you expect instead? normal color background around letters


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

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

Versions of packages mate-desktop-environment depends on:
ii  mate-desktop-environment-core  1.20.0+5

Versions of packages mate-desktop-environment recommends:
ii  atril 1.20.3-1+deb10u1
ii  desktop-base  10.0.2
ii  engrampa  1.20.2-1
ii  eom   1.20.2-2
ii  ffmpegthumbnailer 2.1.1-0.2+b1
ii  mate-applet-brisk-menu0.5.0-9
ii  mate-applets  1.20.3-2
ii  mate-backgrounds  1.20.0-2
ii  mate-calc 1.20.3-1
ii  mate-icon-theme-faenza1.20.0+dfsg1-2
ii  mate-media1.20.2-1
ii  mate-notification-daemon  1.20.2-1
ii  mate-power-manager1.20.3-2
ii  mate-screensaver  1.20.3-3
ii  mate-system-monitor   1.20.2-1
ii  mate-user-guide   1.20.2-1
ii  mate-utils1.20.2-3
ii  pluma 1.20.4-1

Versions of packages mate-desktop-environment suggests:
ii  emacs-nox [mail-reader]  1:26.1+1-3.2+deb10u1
ii  mailutils [mail-reader]  1:3.5-4
pn  mate-desktop-environment-extras  
ii  network-manager-gnome1.8.20-1.1
ii  thunderbird [mail-reader]1:78.6.0-1~deb10u1
pn  x-www-browser | firefox  

-- no debconf information

Bug#982808: linux-image-5.10.0-3-amd64: Please configure kernel with CONFIG_PWM_CRC=y

[Kai]

Package: src:linux
Version: 5.10.13-1
Severity: normal
Tags: patch
X-Debbugs-Cc: kai.harr...@posteo.de

Dear Maintainer,

Please consider to set the Linux kernel option "CONFIG_PWM_CRC=y",
without that option it is not possible to control the brightness of
the display of the Asus T100Chi.

Many thanks

Regards Kai

-- Package-specific info:
** Kernel log: boot messages should be attached


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

Kernel: Linux 5.10.13.kai (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-3-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.139
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-3-amd64 recommends:
ii  apparmor 2.13.6-9
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-3-amd64 suggests:
pn  debian-kernel-handbook   
pn  grub-pc | grub-efi-amd64 | extlinux  
pn  linux-doc-5.10   

Versions of packages linux-image-5.10.0-3-amd64 is related to:
ii  firmware-amd-graphics 20201218-3
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120201218-3
pn  firmware-cavium   
ii  firmware-intel-sound  20201218-3
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20201218-3
pn  firmware-libertas 
ii  firmware-linux-nonfree20201218-3
ii  firmware-misc-nonfree 20201218-3
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)

[Ivo De Decker]

Control: tags 978521 pending

Hi Steve,

On Fri, Feb 12, 2021 at 01:35:52AM +, Steve McIntyre wrote:
> On Tue, Feb 09, 2021 at 04:26:02PM +0100, Ivo De Decker wrote:
> >Hi Steve,
> >
> >On Sun, Sep 27, 2020 at 08:39:53PM +0200, Lucas Nussbaum wrote:
> >> During a rebuild of all packages in sid, your package failed to build
> >> on amd64.
> >
> >[...]
> >
> >> > The following packages have unmet dependencies:
> >> >  sbuild-build-depends-main-dummy : Depends: shim-unsigned (= 
> >> > 15+1533136590.3beb971-7) but it is not going to be installed
> >
> >What is the status of shim(-signed) for bullseye?
> >
> >shim-unsigned has been changed, but there is no corresponding shim-signed
> >(yet). I assume a new signature from microsoft is needed. Or are there more
> >changes to shim-unsigned needed first?
> 
> There are some other changes coming, not least switching compiler to
> gcc-10 now we've stabilised.

I'm tagging #978521 ("shim: non-standard gcc/g++ used for build (gcc-9)") as
pending to indicate that you're planning to switch to gcc-10.

> I'm working on new shim uploads at the
> moment, but there's a couple of upstream patches we'll need to take as
> well yet I think. It'll be coming soon, I promise.

Could you clarify the timing for this, especially the timeline for getting the
signature from Microsoft (as far as that can be predicted)? I'm trying to
assess if this could become a blocker wrt the actual release. Is it an option
to release with the current version of shim-signed (ie the one that's also in
buster) if we don't get the signature in time?

Cheers,

Ivo

Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

[Dennis Filder]

Control: tag -1 moreinfo confirmed

I could reproduce this, but only in a bullseye chroot build
environment with a running buster (4.19) kernel.  I haven't tried with
a bullseye kernel + bullseye chroot.

The build log in the bug report states similarly:

 Kernel: Linux 4.19.0-6-cloud-amd64 #1 SMP Debian 4.19.67-2+deb10u2 
(2019-11-11) amd64 (x86_64)

I'd also like to point out this snippet from the ERRORS section of the
manpage for unshare(2):

   EPERM (since Linux 3.9)
  CLONE_NEWUSER was specified in flags and the caller is
  in a chroot environment (i.e., the caller's root direc‐
  tory does not match the root directory of the mount
  namespace in which it resides).

This is important because the test suite executes /bin/unshare with -r
in firehol-3.1.6+ds/tests/tools/newns which then calls
unshare(CLONE_NEWUSER):

  $ strace -e trace=unshare unshare -r unshare -n -m /bin/date
  unshare(CLONE_NEWUSER)  = 0
  unshare(CLONE_NEWNS|CLONE_NEWNET)   = 0

In fact under all kernels I've tried (4.19, 5.10) this command even
when run as root always fails with "Operation not permitted":

  chroot /chrootenvdir /bin/unshare -r /bin/date

My understanding of the interaction of chroot and
unshare(2)/namespaces in general is incomplete, but this to me
indicates the test suite of firehol in its current form simply cannot
be run in a chroot environment (at least on 4.19 kernels, but probably
also later ones) and should be disabled until the unshare backend for
sbuild has matured enough to be used on the build servers.

@Jerome: Could you try to get someone from either the Debian Kernel
Team or the sbuild maintainers to take a look at this?  If you get no
answer there then make sure notify the release team as they may have
to waive this one.

Regards,
Dennis.

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

[Brian Potkin]

On Sun 14 Feb 2021 at 18:47:18 +0100, mh wrote:

> Am Sun, 14 Feb 2021 17:35:47 +
> schrieb Brian Potkin :
> 
> > Is avahi-daemon active?
> > 
> >   systemctl status avahi-daemon
> 
> Yes.
> 
> # systemctl status avahi-daemon
> ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
>  Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled;
> vendor preset: enabled) Active: active (running) since Sun 2021-02-14
> 14:01:53 CET; 4h 38min ago TriggeredBy: ● avahi-daemon.socket
>Main PID: 711 (avahi-daemon)
>  Status: "avahi-daemon 0.8 starting up."
>   Tasks: 2 (limit: 4634)
>  Memory: 1.7M
> CPU: 402ms
>  CGroup: /system.slice/avahi-daemon.service
>  ├─711 avahi-daemon: running [neutower.local]
>  └─749 avahi-daemon: chroot helper
> 
> Feb 14 14:01:51 neutower avahi-daemon[711]: Found user 'avahi' (UID
> 106) and group 'avahi' (GID 114). Feb 14 14:01:51 neutower
> avahi-daemon[711]: Successfully dropped root privileges. Feb 14
> 14:01:51 neutower avahi-daemon[711]: avahi-daemon 0.8 starting up. Feb
> 14 14:01:53 neutower avahi-daemon[711]: Successfully called chroot().
> Feb 14 14:01:53 neutower avahi-daemon[711]: Successfully dropped
> remaining capabilities. Feb 14 14:01:53 neutower avahi-daemon[711]:
> Loading service file /services/apt-cacher-ng.service. Feb 14 14:01:53
> neutower avahi-daemon[711]: Network interface enumeration completed.
> Feb 14 14:01:53 neutower avahi-daemon[711]: Server startup complete.
> Host name is neutower.local. Local service cookie is 294> Feb 14
> 14:01:53 neutower avahi-daemon[711]: Service "apt-cacher-ng proxy on
> neutower" (/services/apt-cacher-ng.service) succe> Feb 14 14:01:53
> neutower systemd[1]: Started Avahi mDNS/DNS-SD Stack. lines 1-23/23
> (END)
> 
> 
> > 
> > Do you have a firewall?
> 
> No.

I am running out of ideas. Please try

  lpinfo -v

and

  ippfind -T 5

Cheers,

Brian.

Bug#982817: yash FTBFS on mips*el because test silently times out

[Paul Gevers]

Source: yash
Version: 2.51-1
Severity: serious
Tags: ftbfs

Hi Maintainer,

Your last upload of yash FTBFS on mipsel and mips64el.

Paul

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

E: Build killed with signal TERM after 150 minutes of inactivity



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982677: FTBFS - required network connection

[Louis-Philippe Véronneau]

tags 982677 = moreinfo unreproducible
severity 982677 normal
thanks

Holger reports no problem in building this package using pbuilder
without a network connection:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rbac-client-clojure.html

I'm thus tagging this bug as requiring more info (how are you building
it exactly?) and as unreproducible. For now, I'm also decreasing the
severity to normal.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982819: mark golang-github-fsnotify-fsnotify-dev Multi-Arch: foreign

[Helmut Grohne]

Package: golang-github-fsnotify-fsnotify-dev
Version: 1.4.9-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:acbuild src:aerc src:aptly src:badger src:balboa 
src:burrow src:consul src:containerd src:crowdsec src:deck src:delve 
src:dh-make-golang src:docker-registry src:docker.io src:etcd src:fever 
src:flannel src:garagemq src:gdu src:git-lfs src:gitbatch 
src:gitlab-ci-multi-runner src:gitlab-workhorse src:go-cve-dictionary 
src:go-exploitdb src:gobgp src:golang-ginkgo src:golang-github-appc-docker2aci 
src:golang-github-canonical-go-dqlite 
src:golang-github-containernetworking-plugins 
src:golang-github-containers-buildah src:golang-github-containers-dnsname 
src:golang-github-coreos-discovery-etcd-io src:golang-github-influxdata-tail 
src:golang-github-openshift-imagebuilder src:golang-github-spf13-cobra 
src:golang-github-sylabs-sif src:golang-github-tdewolff-minify 
src:golang-github-xordataexchange-crypt src:golang-v2ray-core src:gost 
src:goval-dictionary src:hcloud-cli src:hugo src:libpod src:mender-cli 
src:mtail src:nomad src:nomad-driver-lxc src:nomad-driver-podman src:notary 
src:prometheus src:prometheus-hacluster-exporter src:prometheus-mailexporter 
src:prometheus-postfix-exporter src:rclone src:reflex src:restic src:rkt 
src:seqkit src:shadowsocks-v2ray-plugin src:sia src:singularity-container 
src:skopeo src:slinkwatch src:syncthing src:termshark src:vip-manager src:vuls 
src:webhook

The affected packages cannot satisfy their cross build depends, because
their transitive dependency on golang-github-fsnotify-fsnotify-dev is
not satisfiable. In general, Architecture: all packages can never
satisfy cross Build-Depends unless marked Multi-Arch: foreign or
annotated :native. In this case, the foreign marking is reasonable, as
golang-github-fsnotify-fsnotify-dev is a pure go library entirely
lacking maintainer scripts and all of its dependencies are already
marked Multi-Arch: foreign. Please consider applying the attached patch.

Helmut
diff --minimal -Nru golang-fsnotify-1.4.9/debian/changelog 
golang-fsnotify-1.4.9/debian/changelog
--- golang-fsnotify-1.4.9/debian/changelog  2020-04-19 14:36:17.0 
+0200
+++ golang-fsnotify-1.4.9/debian/changelog  2021-02-14 10:44:08.0 
+0100
@@ -1,3 +1,11 @@
+golang-fsnotify (1.4.9-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-fsnotify-fsnotify-dev Multi-Arch: foreign. (Closes:
+#-1)
+
+ -- Helmut Grohne   Sun, 14 Feb 2021 10:44:08 +0100
+
 golang-fsnotify (1.4.9-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru golang-fsnotify-1.4.9/debian/control 
golang-fsnotify-1.4.9/debian/control
--- golang-fsnotify-1.4.9/debian/control2020-04-19 14:36:17.0 
+0200
+++ golang-fsnotify-1.4.9/debian/control2021-02-14 10:44:07.0 
+0100
@@ -19,6 +19,7 @@
 
 Package: golang-github-fsnotify-fsnotify-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: golang-golang-x-sys-dev,
  ${misc:Depends},
 Description: File system notifications for Go

Bug#982818: borgbackup: annotate test dependencies

[Helmut Grohne]

Source: borgbackup
Version: 1.1.15-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

borgbackup cannot be cross built from source, because its Build-Depends
are not satisfiable. Instead of looking into such a difficult problem, I
looked for easily droppable dependencies and noticed that the pytest
dependencies are only used for (surprise!) testing. As such, they can be
annotated . A nocheck build with them dropped results in the
exact same binary artifacts as a regular build as borgbackup is normally
reproducible. Please consider applying the attached patch.

Helmut
diff --minimal -Nru borgbackup-1.1.15/debian/changelog 
borgbackup-1.1.15/debian/changelog
--- borgbackup-1.1.15/debian/changelog  2021-01-21 09:31:35.0 +0100
+++ borgbackup-1.1.15/debian/changelog  2021-02-14 13:42:09.0 +0100
@@ -1,3 +1,10 @@
+borgbackup (1.1.15-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate test dependencies . (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 14 Feb 2021 13:42:09 +0100
+
 borgbackup (1.1.15-3) unstable; urgency=medium
 
   * Tighteen xxhash dependency to make sure a recent enough
diff --minimal -Nru borgbackup-1.1.15/debian/control 
borgbackup-1.1.15/debian/control
--- borgbackup-1.1.15/debian/control2021-01-21 09:31:04.0 +0100
+++ borgbackup-1.1.15/debian/control2021-02-14 13:42:08.0 +0100
@@ -20,8 +20,8 @@
python3-guzzle-sphinx-theme,
python3-llfuse (<< 2.0) [!hurd-any],
 #   python3-msgpack,
-   python3-pytest,
-   python3-pytest-cov,
+   python3-pytest ,
+   python3-pytest-cov ,
python3-setuptools,
python3-setuptools-scm (>= 1.7),
python3-sphinx (>= 1.0.7),

Bug#977679: [debsums] Kindly consider uploading the updated (German) translation

[Axel Beckert]

Hi Helge,

Helge Kreutzmann wrote:
> the freeze has begun and the German man page translation for debsums
> is not yet included.
> 
> Could you kindly consider performing another upload with the
> translation?

Thanks for the kind reminder! Much appreciated! Will do. :-)

> You will need to ask for a freeze exception,

Not yet — during the softfreeze just 10 days of migration delay are
actually enforced, even for key packages.

According to https://release.debian.org/bullseye/freeze_policy.html
and https://release.debian.org/britney/hints/freeze only from the
hardfreeze onwards (as it is a key package since piuparts depends on
it according to https://udd.debian.org/cgi-bin/key_packages.yaml.cgi).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#612019: [gimp] fails to load modules "canberra-gtk-module" without libcanberra-gtk-module

[Tassia Camoes Araujo]

reopen 612019 tas...@debian.org
found 612019 2.24.33-1
tag 612019 + bullseye
thanks

Same issue described before with libgtk2.0-0.

I would get the following when running applications from a terminal
(gimp, hexchat, xsane, ...):
Gtk-Message: 16:08:13.676: Failed to load module
"libcanberra-gtk-module"

Installing libcanberra-gtk-module solved the issue.

BTW, the problem was not found with filezilla, which depends on
libgtk-3-0, probably because libcanberra-gtk3-module was already
installed on my system.

Thanks!

Tassia.

Bug#982791: mit-scheme FTBFS on i386: out of memory

[Adrian Bunk]

On Sun, Feb 14, 2021 at 03:08:16PM +, Barak A. Pearlmutter wrote:
> Thanks for the report. I've been looking at the issue already.
> 
> Adding a new arch requires a bit of work, because there's a circular
> build dependency so you have to build manually. And I don't have an
> arm64 to hand, so I'll have to use a porter machine. Will get around
> to it.
>...

Yes, I saw that a manual bootstrap is necessary.

It's easier when the architecture is already in Architecture.

cu
Adrian

Bug#982824: apt-listchanges: [INTL:pt] Update on Portuguese translation of MANPAGE

[Américo Monteiro]

Package: apt-listchanges
Version: 3.23
Tags: l10n, patch-
Severity: wishlist

Updated Portuguese translation for  apt-listchanges's manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro



apt-listchanges_3.23_pt.po.gz
Description: application/gzip

Bug#914315: libwebp-1.2.0 release (and security concerns)

[Laurence Parry]

Dear Maintainer,

It might be too late for bullseye(?), but libwebp-1.2.0 is now out - as before:
https://chromium.googlesource.com/webm/libwebp/+/refs/heads/master/NEWS

I'm concerned about the state of WebP. The upstream code
Debian/Ubuntu's distribution is based on is now over four years old.
Since then (and shortly after the last update of this package on 1
March 2018), oss-fuzz was implemented, which led to the discovery of
several issues and resulting security hardening fixes as mentioned in
the release notes, which are now public - and have been for a year.

A few examples:
https://bugs.chromium.org/p/webp/issues/detail?id=383
[multi-byte-write-heap-buffer-overflow]
https://bugs.chromium.org/p/webp/issues/detail?id=385
[multi-byte-write-heap-use-after-free, thread race]
https://bugs.chromium.org/p/webp/issues/detail?id=386
[1-byte-read-heap-buffer-overflow]
https://bugs.chromium.org/p/webp/issues/detail?id=387 [chunk_size
overflows in SizeWithPadding, allocates 4GB]
https://bugs.chromium.org/p/webp/issues/detail?id=388 [multi-byte-read
(4GB) - same as above]
https://bugs.chromium.org/p/webp/issues/detail?id=391 [found in GraphicsMagick]

None appear to have CVEs, but they appear to be real issues. Some were
subject to multi-year security holds and only revealed in February
2020.
Some would not have applied to Chromium (it did not use threaded
mode), but could impact other users, e.g.:
https://bugs.chromium.org/p/chromium/issues/detail?id=917029

This software is liable to be used on files with arbitrary inputs,
both on client and web-accessible server machines, so DoS issues are a
concern. It's in PHP 7.x (via GD) python-pil, imagemagick, chromium,
libqt5webkit5, libavcodec58, etc. I don't know enough about their use
of this library to know if any of the bugs found are issues for them,
but it seems at least possible that some of them are.

I'm considering use of WebP on my own art hosting site, as it has
become widely usable in browsers, but I'm nervous about the idea of
integrating this version of the library into our image handling
pipeline. Is an update to a newer version feasible? I'm OK using sid
for this, though others might not be. Alternatively, is there a way as
an end-user to easily modify the package to use newer versions?

Best regards,
-- 
Laurence "GreenReaper" Parry
https://www.greenreaper.co.uk/

Bug#982825: netcfg: FTBFS with current bullseye version

[Holger Wansing]

Package: netcfg
Severity: critical
Version: 1.169

While trying to upload a new version of netcfg, I found that current testing
version of netcfg fails to build from source, in a stable sbuild environment
as well as in an unstable one.

The sbuild output (from a stable environment) is attached.

I assume this is not a problem in netcfg itself, however I feel somewhat 
helpless 
in finding the real course.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on t520

+==+
| netcfg 1.169 (amd64) Sun, 14 Feb 2021 22:53:03 + |
+==+

Package: netcfg
Version: 1.169
Source Version: 1.169
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-b9f0d463-46de-4f19-92ab-2dfa5cf97d07' with '<>'
I: NOTICE: Log filtering will replace 'build/netcfg-WJf5nS/resolver-s1BpYp' with '<>'

+--+
| Update chroot|
+--+

Get:1 http://deb.debian.org/debian unstable InRelease [153 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Sources T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [19.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Sources T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [19.6 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [34.7 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages T-2021-02-14-2000.12-F-2021-02-14-2000.12.pdiff [34.7 kB]
Fetched 335 kB in 5s (69.7 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  libgcrypt20
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 563 kB of archives.
After this operation, 1024 B of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 libgcrypt20 amd64 1.8.7-3 [563 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 563 kB in 0s (2381 kB/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 15717 files and directories currently installed.)
Preparing to unpack .../libgcrypt20_1.8.7-3_amd64.deb ...
Unpacking libgcrypt20:amd64 (1.8.7-3) over (1.8.7-2) ...
Setting up libgcrypt20:amd64 (1.8.7-3) ...
Processing triggers for libc-bin (2.31-9) ...

+--+
| Fetch source files   |
+--+


Local sources
-

/home/holgerw/test/netcfg-1.169/netcfg_1.169.dsc exists in /home/holgerw/test/netcfg-1.169; copying to chroot
I: NOTICE: Log filtering will replace 'build/netcfg-WJf5nS/netcfg-1.169' with '<>'
I: NOTICE: Log filtering will replace 'build/netcfg-WJf5nS' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libdebconfclient0-dev (>= 0.46), libdebian-installer4-dev (>= 0.41), po-debconf (>= 0.5.0), libiw-dev (>= 27+28pre9), check, libsubunit-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libdebconfclient0-dev (>= 0.46), libdebian-installer4-dev (>= 0.41), po-debconf (>= 0.5.0), libiw-dev (>= 27+28pre9), check, libsubunit-dev, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 

Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

El vie, 12 feb 2021 a las 23:05, Alen Zekulic () escribió:
>
> On Fri, Feb 12, 2021 at 13:25:23 +0100, Agustin Martin wrote:
>
> > Alen, I plan to upload a NMU with this changes and may be some minor
> > issues. Even if I have not written rexx for years I think it would be
> > a pity to have this package with this open bug.
>
> I agree, please go ahead!

Uploaded.

> > Also, one issue with this package is that Debian build system is
> > ancient, even pre-debhelper. This makes everything a nightmare. I
> > have been playing with a migration to traditional (no dh sequencer)
> > debhelper. This should fix another bug report about build
> > reproduciibility. I am aware that this is a rather invasive change,
> > but I think is required to make contributors life easier, let me know
> > your POV.
>
> I planed to migrate my debian/rules to debhelper too.

When I was playing with this there were still some issues. Once I find
time to continue and consider things in good shape, I will let you
know. Another thing I think may be interesting is to split the a-z
patch into smaller chunks for better handling.

> > Other thing I noticed is that this package has no repo under
> > salsa. I can prepare a git repo with regina history and put it under
> > salsa/debian group. Alen, please tell me if you object to this, I
> > consider it important and will proceed unless you object explicitly.
>
> Any help is greatly appreciated, I have no objection, quite the
> contrary!

When I was creating the repo I noticed that there was already a repo
created under debian salsa group by Boyuan Yang, with commits for a
NMU that was never uploaded, so I used it. Reverted one thing, no need
to B-D on debhelper just to pull autotools-dev, debhelper is currently
unused.

> > By the way, upstream is active and there are new versions available,
> > although I will focus on current upstream version in Debian.
>
> Mark and I are in contact. We plan to roll out the latest releases of
> Regina REXX (3.9.4) and The Hessling Editor (3.3) as soon as possible.

Nice to know,

Regards,

-- 
Agustin

Bug#982283: override: bsdmainutils:oldlibs/optional

[Chris Hofstaedtler]

* Chris Hofstaedtler  [210214 23:12]:
> Maybe bsdextrautils should be prio standard then?
> (I don't know exactly how d-i decides what to install for
> "standard system".)

I just installed a new system with the daily d-i image, and
bsdextrautils gets installed - transitively via man-db.

For now there's nothing left to do, IMO.

Chris

Bug#982825: netcfg: FTBFS with current bullseye version

[John Paul Adrian Glaubitz]

Hello Holger!

On 2/15/21 12:02 AM, Holger Wansing wrote:
> While trying to upload a new version of netcfg, I found that current testing
> version of netcfg fails to build from source, in a stable sbuild environment
> as well as in an unstable one.

Did you see #980607 [1]?

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980607

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

Bug#982826: neovim: leaves cursor changed after exiting

[Chris Hofstaedtler]

Package: neovim
Version: 0.4.4-1

Hi,

I've just installed neovim to try it out; no changes from the
defaults have been made on a freshly installed bullseye arm64
install.

After starting neovim (with no file), and immediately exiting with
:q, the terminals cursor stays as a box. Before starting neovim, the
cursor was a blinking underline.

The terminal is actually the linux framebuffer console.

Chris

Bug#975282: RFP: obs-v4l2sink -- OBS Studio plugin providing output capabilities to a Video4Linux2 device

[Martin]

The plugin is not needed anymore.
obs-studio 26.1.2+dfsg1-1+b1 has the function out of the box.
Nice!

Bug#982827: RFS: gatos/0.0.5-19.1 [NMU] [RC]-- ATI All-in-Wonder TV capture software

[João Paulo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name    : gatos
   Version : 0.0.5-19.1
   Upstream Author : Oyvind Aabling 
 Octavian PURDILA 
 Christian Lupien 
 Vladimir Dergachev 
 Stea Greene 

 * URL : http://gatos.sourceforge.net/
 * License : GPL-2+
 * Vcs : https://sourceforge.net/projects/gatos/files/
   Section : misc

It builds those binary packages:

  libgatos0 - The General ATI TV and Overlay Software(GATOS): Runtime 
Libraries
  libgatos-dev - The General ATI TV and Overlay Software(GATOS): Dev
Lib and Headers
  gatos - ATI All-in-Wonder TV capture software

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/g/gatos/gatos_0.0.5-
19.1.dsc

Changes since the last upload:

 gatos (0.0.5-19.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * FTBFS solution with GCC 10 by adding -fcommon to CFLAGS
    (close #982379), thanks to Adrian Bunk.

Regards,

Bug#982828: gimp: xsane plugin with a full menu path is deprecated

[Tassia Camoes Araujo]

Subject: gimp: xsane plugin with a full menu path is deprecated
Package: gimp
Version: 2.10.22-2
Severity: normal
Tags: upstream

Dear Maintainer,

Running gimp from a terminal, I got the following:

Plug-in "xsane"
(/usr/lib/gimp/2.0/plug-ins/xsane/xsane) is installing procedure "xsane"
with a
full menu path "/File/Acquire/XSane/Device dialog..." as menu
label,
this deprecated and will be an error in GIMP 3.0

The same issue with a different plugin is described here:
https://gitlab.gnome.org/GNOME/gimp/-/issues/3604

Apparently gimp has changed syntax about 10 years ago, but the plugin is
still
being shipped like that.

Thanks for taking a look!

Tassia.



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

Kernel: Linux 5.10.0-2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gimp depends on:
ii  gimp-data2.10.22-2
ii  libaa1   1.4p5-48
ii  libbabl-0.1-01:0.1.82-1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libgegl-0.4-01:0.4.26-2
ii  libgexiv2-2  0.12.1-1
ii  libgimp2.0   2.10.22-2
ii  libglib2.0-0 2.66.4-1
ii  libgs9   9.53.3~dfsg-6
ii  libgtk2.0-0  2.24.33-1
ii  libgudev-1.0-0   234-1
ii  libharfbuzz0b2.7.4-1
ii  libheif1 1.10.0-2
ii  libilmbase25 2.5.4-1
ii  libjpeg62-turbo  1:2.0.5-2
ii  libjson-glib-1.0-0   1.6.0-2
ii  liblcms2-2   2.12~rc1-2
ii  liblzma5 5.2.5-1.0
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr25 2.5.4-1
ii  libopenjp2-7 2.3.1-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpoppler-glib8 20.09.0-3.1
ii  librsvg2-2   2.50.2+dfsg-1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-17
ii  libx11-6 2:1.7.0-2
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-2
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages gimp recommends:
ii  ghostscript  9.53.3~dfsg-6

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gvfs-backends 1.46.2-1
ii  libasound21.2.4-1.1

-- no debconf information

Bug#981847: ArgumentError: invalid byte sequence in US-ASCII

[Daniel Leidert]

Am Donnerstag, dem 04.02.2021 um 20:56 +0530 schrieb Ritesh Raj Sarraf:
> 
> During a rebuild of the package on Bullseye, the package fails in one of
> the tests. Below is the failure snippet. The same is also seen in the
> Reproducible Builds reports.
> 
> ```
> [  194s] 
> ---
> [  194s] 107 tests, 152 assertions, 0 failures, 1 errors, 0 pendings, 0 
> omissions, 0 notifications
> [  194s] 99.0654% passed
> [  194s] 
> ---
> [  194s] 23.20 tests/s, 32.95 assertions/s
> [  194s] rake aborted!
> [  194s] Command failed with status (1): [ruby -w -I"test"  
> "/usr/share/rubygems-integration/all/gems/rake-13.0.1/lib/rake/rake_test_loader.rb"
>  "test/block_test.rb" "test/dyna_symbol_key_test.rb" "test/parser_test.rb" 
> "test/safe_op_test.rb" "test/trace_test.rb" "test/test_core_ext_helper.rb" 
> "test/test_helper.rb" -v]
> [  194s] /usr/share/rubygems-integration/all/gems/rake-13.0.1/exe/rake:27:in 
> `'
> [  194s] Tasks: TOP => default
> [  194s] (See full trace by running task with --trace)
> [  194s] ERROR: Test "ruby2.7" failed. Exiting.
> [  194s] dh_auto_install: error: dh_ruby --install 
> /usr/src/packages/BUILD/debian/ruby-power-assert returned exit code 1
> [  194s] make: *** [debian/rules:6: binary] Error 25
> [  194s] dpkg-buildpackage: error: debian/rules binary subprocess returned 
> exit status 2
> ```

Can you please provide the log file? The error mentioned in the subject
actually doesn't appear in the log snippet.

Reading the subject it might be a LANG-related issue and maybe we need to set
the environment to C.UTF-8 for the tests. Can you check if setting

ENV['LANG'] = 'C.UTF-8'

in debian/ruby-tests.rake fixes the issue?

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#982829: offlineimap3: local variable 'msg' referenced before assignment

[Noah Meyerhans]

Package: offlineimap3
Version: 0.0~git20210105.00d395b+dfsg-2
Severity: normal

Dear Maintainer,

In a situation where the IMAP server is unreachable for some reason,
offlineimap attempts to log a message describing the problem, but instead
seems to encounter a coding error in offlineimap itself.

The logs involved are:

 *** Processing account example
 Establishing connection to imap.example.com:993 (Remote)
 ERROR: While attempting to sync account 'example'
  local variable 'msg' referenced before assignment
 *** Finished account 'example' in 2:09

I have not investigated further, but will try when I get time. 

Thanks for maintaining offlineimap!

noah

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

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

Versions of packages offlineimap3 depends on:
ii  python3   3.9.1-1
ii  python3-distro1.5.0-1
ii  python3-imaplib2  2.57-5.2

offlineimap3 recommends no packages.

offlineimap3 suggests no packages.

-- no debconf information

Bug#982759: vrms does not recognise zoom as nonfree.

[Rogério Theodoro de Brito]

Em 13 de fevereiro de 2021 21:42:56 BRT, c01d  escreveu:
>Package: vrms
>Version: 1.27
>Severity: normal
>
>Dear Maintainer :)
>
>   * What led up to the situation?
>
>   I checked my system with vrms. I have zoom installed
>   (.deb-file from their server).
>
>   While my skypeforlinux-version is correctly shown as non-free,
>   zoom is not:
>
>% dpkg -l | grep zoom
>  ii  zoom 5.4.57862.0110 amd64 Zoom, blabla
>
>   but for example:
>
>% vrms
>Non-free packages installed on main
>  [lots of stuff, not zoom]
>  skypeforlinux
>  [more stuff]
>
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
>   * What was the outcome of this action?
>   * What outcome did you expect instead?
>
>I expected zoom to be shown by vrms.
>
>Thank you!
>
>-- System Information:
>Debian Release: bullseye/sid
>  APT prefers unstable
>APT policy: (999, 'unstable'), (990, 'testing'), (500,
>'stable-updates'), (500, 'stable')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU threads)
>Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
>LANGUAGE=en_GB:en
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>-- no debconf information

What does dpkg -s zoom (or whatever the package is called) outputs?

If it doesn't claim the section to be non-free/something, then vrms won't know 
that it should be counted as non-free.

If the package doesn't have a non-free mark in the section, then that is a bug 
in the zoom package and should be reported there.

Regards,

Rogério Brito.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#972936: libgcc-s1 buster -> bullseye upgrade issues

[Simon McVittie]

On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote:
> [The release team are] pretty concerned about a couple of known RC bugs
> which need the proper attention of people familiar with upgrade paths
> as there's potential to leave upgrading systems unbootable and/or
> without a working apt.
...
> https://bugs.debian.org/972936 / libgcc-s1

I wanted to provide some signal boost for this and related upgrade issues.
Ryan Pavlik, one of my colleagues at Collabora, ran into a similar upgrade
failure involving libgcc-s1 and has made a self-contained reproducer
for it: . This uses
Docker, but apt should behave the same in a chroot or VM.

He reports that at least the issue he originally experienced, and perhaps
others, can be fixed by adding transitional binary packages like these:
https://salsa.debian.org/rpavlik/gcc-10-compat

His gcc-10-compat package's README also has a fairly comprehensive list
of other upgrade bugs around libgcc_s.so.1 that might well have the same
root cause. #972936 is currently the only one marked as RC, but some of
the others should maybe be considered RC too.

Obviously, the transitional packages would ideally be built by src:gcc-10
rather than being a separate source package, and Ryan only prototyped them
as a separate source package to be able to iterate on them without having
to rebuild all of gcc.

smcv

Bug#982740: pulseaudio: FTBFS on ppc64el

[Adrian Bunk]

Control: found -1 14.1-1

On Sat, Feb 13, 2021 at 02:53:58PM -0500, Andres Salomon wrote:
> Package: pulseaudio
> Version: 14.2-1
> Severity: serious
> 
> Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
> bullseye suffers from a pretty serious usability bug (see #980836)
> which should arguably be a higher severity, but let's focus on getting
> 14.2-1 built properly.
> 
> https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el
> 
> Here's where the ppc64el build fails:
> 
> 
> FAIL: cpu-volume-test
> =
> 
> Running suite(s): CPU
> 0%: Checks: 1, Failures: 1, Errors: 0
> tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
> FAIL cpu-volume-test (exit status: 1)
> 
> 
> 
> It's worth noting that 14.1-1 built just fine on ppc64el, and the only
> non-debian change between 14.1 and 14.2 is this:
>...

Both versions fail for me the same way on plummer.

Adding debian-powerpc so that a porter can check.

cu
Adrian

Bug#982813: Select All does not select all text any more

[richard newton]

Package: gnome-terminal
Version: 3.38.2-1

'Select All' menu option does not select all text as it used to.
It only selects the text shown in the window not the scrollback buffer,
without any warning, or change in menu option name.

This change in long-standing behaviour is not mentioned in the changelog

See also: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/288

Bug#811087: closed by Michael Tokarev (Re: Bug#811087: qemu-user-static: qemu-arm-static segfaults in armhf chroot on 'aptitude -u')

[Andreas Beckmann]

Version: 1:5.2+dfsg-3~bpo10+1

On 2/14/21 4:46 PM, Michael Tokarev wrote:
> Before I was able to hit this issue with almost any invocation of aptitude.
> But in 5.0 or current 5.2 I can't reproduce this issue anymore, now matter
> how I try.

a simple 'aptitude -u' does the job for me :-(

The core file I get inside the chroot is actually from the qemu binary on the 
host,
perhaps this backtrace helps:

Reading symbols from /usr/bin/qemu-aarch64-static...Reading symbols from 
/usr/lib/debug/.build-id/30/efd3930fb9519b21470b113679376f2ffbb41a.debug...done.
done.

warning: core file may not match specified executable file.
[New LWP 23784]
[New LWP 23772]
[New LWP 23774]
[New LWP 23777]
[New LWP 23776]
[New LWP 23775]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/qemu-aarch64-static /usr/bin/aptitude -u'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0059a1eb in getgroups (__list=0x7f867be79cc0, __size=65536) at 
/usr/include/x86_64-linux-gnu/bits/unistd.h:275

warning: Source file is more recent than executable.
275   return __getgroups_alias (__size, __list);
[Current thread is 1 (Thread 0x7f867bebb700 (LWP 23784))]
(gdb) bt
#0  0x0059a1eb in getgroups (__list=0x7f867be79cc0, __size=65536) at 
/usr/include/x86_64-linux-gnu/bits/unistd.h:275
#1  do_syscall1 (cpu_env=cpu_env@entry=0x1c8d540, num=num@entry=158, 
arg1=arg1@entry=65536, arg2=arg2@entry=365688737808, 
arg3=arg3@entry=365112983552, arg4=arg4@entry=0, arg5=-1, arg6=0, arg8=0, 
arg7=0) at ../../linux-user/syscall.c:11262
#2  0x005a4c73 in do_syscall (cpu_env=cpu_env@entry=0x1c8d540, num=158, 
arg1=65536, arg2=365688737808, arg3=365112983552, arg4=0, arg5=-1, arg6=0, 
arg7=0, arg8=0) at ../../linux-user/syscall.c:13104
#3  0x00421f98 in cpu_loop (env=env@entry=0x1c8d540) at 
../../linux-user/aarch64/cpu_loop.c:90
#4  0x00590073 in clone_func (arg=0x7ffee38be2b0) at 
../../linux-user/syscall.c:6372
#5  0x00728cb7 in start_thread (arg=) at 
pthread_create.c:477
#6  0x007aad0f in clone ()
(gdb) info threads
  Id   Target Id Frame
* 1Thread 0x7f867bebb700 (LWP 23784) 0x0059a1eb in getgroups 
(__list=0x7f867be79cc0, __size=65536) at 
/usr/include/x86_64-linux-gnu/bits/unistd.h:275
  2Thread 0x19c63c0 (LWP 23772)  tc_ptr_to_region_tree 
(p=0x7f867c6c3240 ) at ../../tcg/tcg.c:418
  3Thread 0x7f8688812700 (LWP 23774) 0x007a9429 in syscall ()
  4Thread 0x7f867befc700 (LWP 23777) safe_syscall_base () at 
../../linux-user/host/x86_64/safe-syscall.inc.S:75
  5Thread 0x7f867bf3d700 (LWP 23776) safe_syscall_base () at 
../../linux-user/host/x86_64/safe-syscall.inc.S:75
  6Thread 0x7f867bf7e700 (LWP 23775) safe_syscall_base () at 
../../linux-user/host/x86_64/safe-syscall.inc.S:75

Bug#981338: self signed ssl cert unusuable after upgrade

[Sudip Mukherjee]

Hi Joey,

On Sun, Feb 14, 2021 at 5:24 PM Joey Hess  wrote:
>
> Sudip Mukherjee wrote:
> > I was looking into this error and this has been caused by an upstream
> > commit which is supposed to be an improvement for new users. More
> > details at 
> > https://github.com/OfflineIMAP/offlineimap3/issues/41#issuecomment-778798223.
> >
> > The attached patch should fix this.
> >
> > @Joey Hess It will be great if you test the patch and confirm if it
> > fixes your problem.
>
> It does, but only after I fixed an unrelated problem:

Yes, sorry I should have said you will face that.
Its known issue. #/981063 and #981385

And I have raised an upstream PR for this at
https://github.com/OfflineIMAP/offlineimap3/pull/51



-- 
Regards
Sudip

Bug#981600: nghttp2: util_localtime_date test fails in arch-only build

[Ivo De Decker]

Control: severity -1 important

Hi,

On Sun, Feb 07, 2021 at 09:12:53PM +0100, Helmut Grohne wrote:
> On Sun, Feb 07, 2021 at 08:51:36PM +0100, Chris Hofstaedtler wrote:
> > I'm just passing by, but a local rebuild with `sbuild -d unstable
> > -j8 --no-arch-all` did not show this problem (on amd64). There has
> > to be more to it.
> 
> Thank you. I retried it to day (sbuild -d unstable --no-arch-all
> nghttp2 on amd64) and it failed in the same way. I'm left puzzled what
> could be different here. One aspect that certainly is not entirely usual
> is that my chroot lives on a large tmpfs. Could that pose any problems?
> 
> Any other details I could add to help better understand the issue?

There was an upload of nghttp2 yesterday, which built fine on the buildds, so
I'm downgrading this bug.

Cheers,

Ivo

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

[mh]

Am Sun, 14 Feb 2021 19:04:48 +
schrieb Brian Potkin :

> On Sun 14 Feb 2021 at 18:47:18 +0100, mh wrote:
> 
> > Am Sun, 14 Feb 2021 17:35:47 +
> > schrieb Brian Potkin :
> >   
> > > Is avahi-daemon active?
> > > 
> > >   systemctl status avahi-daemon  
> > 
> > Yes.
> > 
> > # systemctl status avahi-daemon
> > ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
> >  Loaded: loaded (/lib/systemd/system/avahi-daemon.service;
> > enabled; vendor preset: enabled) Active: active (running) since Sun
> > 2021-02-14 14:01:53 CET; 4h 38min ago TriggeredBy: ●
> > avahi-daemon.socket Main PID: 711 (avahi-daemon)
> >  Status: "avahi-daemon 0.8 starting up."
> >   Tasks: 2 (limit: 4634)
> >  Memory: 1.7M
> > CPU: 402ms
> >  CGroup: /system.slice/avahi-daemon.service
> >  ├─711 avahi-daemon: running [neutower.local]
> >  └─749 avahi-daemon: chroot helper
> > 
> > Feb 14 14:01:51 neutower avahi-daemon[711]: Found user 'avahi' (UID
> > 106) and group 'avahi' (GID 114). Feb 14 14:01:51 neutower
> > avahi-daemon[711]: Successfully dropped root privileges. Feb 14
> > 14:01:51 neutower avahi-daemon[711]: avahi-daemon 0.8 starting up.
> > Feb 14 14:01:53 neutower avahi-daemon[711]: Successfully called
> > chroot(). Feb 14 14:01:53 neutower avahi-daemon[711]: Successfully
> > dropped remaining capabilities. Feb 14 14:01:53 neutower
> > avahi-daemon[711]: Loading service file
> > /services/apt-cacher-ng.service. Feb 14 14:01:53 neutower
> > avahi-daemon[711]: Network interface enumeration completed. Feb 14
> > 14:01:53 neutower avahi-daemon[711]: Server startup complete. Host
> > name is neutower.local. Local service cookie is 294> Feb 14
> > 14:01:53 neutower avahi-daemon[711]: Service "apt-cacher-ng proxy
> > on neutower" (/services/apt-cacher-ng.service) succe> Feb 14
> > 14:01:53 neutower systemd[1]: Started Avahi mDNS/DNS-SD Stack.
> > lines 1-23/23 (END)
> > 
> >   
> > > 
> > > Do you have a firewall?  
> > 
> > No.  
> 
> I am running out of ideas. Please try
> 
>   lpinfo -v

# lpinfo -v
file cups-brf:/
network beh
serial serial:/dev/ttyS0?baud=115200
network ipp
network https
network socket
network ipps
network lpd
network http
network smb

> 
> and
> 
>   ippfind -T 5

# ippfind -T 5
~# 

> 
> Cheers,
> 
> Brian.

Greetings

Michael

Bug#982812: youtube-dl: Usage of deprecated /usr/bin/python symlink

[Vangelis Skarmoutsos]

Package: youtube-dl
Version: 2021.02.04.1-1
Severity: important

Dear Maintainer,

the usage of the youtube-dl command is producing:
/usr/bin/env: «python»: Δεν υπάρχει τέτοιο αρχείο ή κατάλογος (<- Greek for "no
such file or folder")


A note at https://wiki.debian.org/Python mentions:
"Debian testing (bullseye) has removed the "python" package and the
'/usr/bin/python' symlink due to the deprecation of Python 2. No packaged
scripts should depend on the existence of '/usr/bin/python': if they do, that
is a bug that should be reported to Debian. You can use the 'python-is-python3'
or 'python-is-python2' packages to restore an appropriate '/usr/bin/python'
symlink for third-party or legacy scripts. "


When python-is-python3 package was installed, youtube-dl command worked as
expected.




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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages youtube-dl depends on:
ii  python33.9.1-1
ii  python3-pkg-resources  52.0.0-1

Versions of packages youtube-dl recommends:
ii  ca-certificates  20210119
ii  curl 7.74.0-1
ii  ffmpeg   7:4.3.1-8
ii  mplayer  2:1.4+ds1-1
ii  python3-pyxattr  0.7.2-1+b1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b2
ii  wget 1.21-1+b1

Versions of packages youtube-dl suggests:
ii  libfribidi-bin  1.0.8-2
pn  phantomjs   

-- no debconf information

Bug#976045: marked as done (bind9: flaky autopkgtest on ci.debian.net)

[Willy nilly]

close #976045

On Sun, Feb 14, 2021 at 8:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 14 Feb 2021 20:17:38 +
> with message-id 
> and subject line Bug#976045: fixed in bind9 1:9.16.11-3
> has caused the Debian Bug report #976045,
> regarding bind9: flaky autopkgtest on ci.debian.net
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 976045: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976045
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Paul Gevers 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 28 Nov 2020 21:04:16 +0100
> Subject: bind9: flaky autopkgtest on ci.debian.net
> Source: bind9
> Version: 1:9.11.5.P4+dfsg-5.1+deb10u2
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky
> Control: found -1 1:9.16.8-1
>
> Dear maintainer(s),
>
> bind9 has an autopkgtest, great. However, your test (correctly) has the
> restriction needs-internet, but it doesn't retry the part where it uses
> the internet.  On ci.debian.net, we're seeing (e.g. [1]) regular
> failures in the internet based test. Can you please make the test more
> robust against network issues? E.g. a couple of retries with some time
> in between before failing?
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
>
> I copied the output at the bottom of this report.
>
> Please do get in touch if we need to dive into this together.
>
> Paul
>
> [1] https://ci.debian.net/packages/b/bind9/testing/amd64/
>
> https://ci.debian.net/data/autopkgtest/stable/armhf/b/bind9/8471318/log.gz
>
> autopkgtest [21:59:15]: test simpletest: [---
>
> ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> -x 127.0.0.1 @127.0.0.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53032
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 20d019dc324ffa05fbfc9b425fc176b5e6f0b962dccc8e3c (good)
> ;; QUESTION SECTION:
> ;1.0.0.127.in-addr.arpa.IN  PTR
>
> ;; ANSWER SECTION:
> 1.0.0.127.in-addr.arpa. 604800  IN  PTR localhost.
>
> ;; AUTHORITY SECTION:
> 127.in-addr.arpa.   604800  IN  NS  localhost.
>
> ;; ADDITIONAL SECTION:
> localhost.  604800  IN  A   127.0.0.1
> localhost.  604800  IN  ::1
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Nov 27 21:59:17 UTC 2020
> ;; MSG SIZE  rcvd: 160
>
> Checking for DNSSEC validation status of internetsociety.org
> autopkgtest [21:59:17]: test simpletest: ---]
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 976045-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 14 Feb 2021 20:17:38 +
> Subject: Bug#976045: fixed in bind9 1:9.16.11-3
> Source: bind9
> Source-Version: 1:9.16.11-3
> Done: Ondřej Surý 
>
> We believe that the bug you reported is fixed in the latest version of
> bind9, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 976...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Ondřej Surý  (supplier of updated bind9 package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sun, 14 Feb 2021 20:04:39 +0100
> Source: bind9
> Architecture: source
> Version: 1:9.16.11-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian DNS Team 
> Changed-By: Ondřej Surý 
> Closes: 976045
> Changes:
>  bind9 (1:9.16.11-3) unstable; urgency=medium
>  .
>* Split the simple validation test to separate file and mark it as flaky
>  (Closes: #976045)
> Checksums-Sha1:
>  f47b6581c02134952c9066405daa09b69bb84e95 2992 bind9_9.16.11-3.dsc
>  

Bug#982035: marked as done (tasksel depends on man-pages-it which has been removed)

[Willy nilly]

close #982035

On Sun, Feb 14, 2021 at 5:45 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 14 Feb 2021 17:40:03 +
> with message-id 
> and subject line Bug#982035: fixed in tasksel 3.64
> has caused the Debian Bug report #982035,
> regarding tasksel depends on man-pages-it which has been removed
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982035: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982035
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Paul Gevers 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 5 Feb 2021 21:02:04 +0100
> Subject: tasksel depends on man-pages-it which has been removed
> Package: tasksel
> Version: 3.63
> Severity: serious
> Justification: not installable
>
> Hi,
>
> man-pages-it has been removed from unstable. Don't ask me how that is
> possible as your package still depends on it, but it happened. Please
> drop the dependency. The RM bug #979034 suggests the data now lives
> elsewhere, albeit I don't know where.
>
> Paul
>
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 982035-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 14 Feb 2021 17:40:03 +
> Subject: Bug#982035: fixed in tasksel 3.64
> Source: tasksel
> Source-Version: 3.64
> Done: Holger Wansing 
>
> We believe that the bug you reported is fixed in the latest version of
> tasksel, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 982...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Holger Wansing  (supplier of updated tasksel
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sun, 14 Feb 2021 18:03:39 +0100
> Source: tasksel
> Architecture: source
> Version: 3.64
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Install System Team 
> Changed-By: Holger Wansing 
> Closes: 981478 982035
> Changes:
>  tasksel (3.64) unstable; urgency=medium
>  .
>* Team upload.
>  .
>[ Holger Wansing ]
>* Remove manpages-it from task-italian task (package has been removed
> from
>  unstable). Closes: #982035.
>  .
>[ Updated debconf translations ]
>* Spanish (es.po) by Javier Fernandez-Sanguino. Closes: #981478
> Checksums-Sha1:
>  81145d080b419335c257fb66cc85167ecb4e6560 17065 tasksel_3.64.dsc
>  daebb2ca502fbf4bae44c1469cfbc03644eb11ec 295008 tasksel_3.64.tar.xz
>  aa46a43a049f7774e5711dfc268750d859329ac3 65617
> tasksel_3.64_amd64.buildinfo
> Checksums-Sha256:
>  8c4d7fac094276078d7680978f147a1a162e2ae9ecd04289f5fd6a6c71716d3b 17065
> tasksel_3.64.dsc
>  b346f617b3b8c58aba8d9196b6c0538569572ab20c70b0f8c1ebb34e4ce01db0 295008
> tasksel_3.64.tar.xz
>  4df987f5097190b164b28e91d43027ff1b6205e9a7ed8e565a8e2460e84cddca 65617
> tasksel_3.64_amd64.buildinfo
> Files:
>  c7b9df296de293a39092ddfc2c801c35 17065 tasks optional tasksel_3.64.dsc
>  7bf4c6469a6b36b5d8484e57745f46c4 295008 tasks optional tasksel_3.64.tar.xz
>  e939d356a1fdbe6f0bb90b57f9921e38 65617 tasks optional
> tasksel_3.64_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQJJBAEBCgAzFiEESWrG6BRCSzSFCDUpWfGHyhVusHYFAmApWfQVHGh3YW5zaW5n
> QG1haWxib3gub3JnAAoJEFnxh8oVbrB2q9kQAMD3VRMCv8sGwvkuOf7j+kE7v3BH
> SLllehh1ZHhmtfeU6IVQUPcAjIOq+ZJdJQIre/O7PT32migDrG9+vZTuFF8CXm3y
> Gnv3iIEwsHmR82OFZyNf7zd22ZQ553HTQOX8jc5eOx3ZoxyuAF0L/teS1trso0bE
> isJ8ZX9AXJG64vnNV1v+2GQmp8nq/N594dYtnl53VI8IF59Hd7ROovlD/byjeQ07
> iR6KLxwpH18wwyfKvZSBziwVg8h7PgDYDsIwYCQAzgecGzVRRI9sGsebZKVE2B9k
> VDNkyEJe/QNGGUJo2tfqgdYci/fR0HGQzWlLKk4ZSKigrTsqqV+xHqK19UDPM8mF
> A9Af4j3tBlgMX32gDSnzT9xu4R4871AAonR5G1UI2Ib7ofegIwYolybwYLJdBXow
> oZyd+02XatXYzD6wBjig9aHs4DDBCYYlNE8fjZKKct0bsioSl99H0kKBEIK72Tm1
> k6cD/N8YGVCqC9QiZtjS9zOceeovpI1YapzyUA/6fM6KrjClvp7i/kC//3qtfaAH
> UdhZZG2Nfwjx2JvcXJA9m+dELpcUA5a2BYNBVhlr7TdDMbrZ7r7dfyIPvA0Uv+OQ
> z0+ctAqukuxDGMLKzn31pWTR5gamgBZpbw8HrdTCAVVmj5fn2/RM7zCQL69Mdcnh
> rpEan0iPbDmOzEFR
> =nkgk
> -END PGP SIGNATURE-

Bug#982802: marked as done (libio-html-perl: autopkgtest failure)

[Willy nilly]

close #982802

On Sun, Feb 14, 2021 at 5:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 14 Feb 2021 17:50:29 +
> with message-id 
> and subject line Bug#982802: fixed in libio-html-perl 1.004-2
> has caused the Debian Bug report #982802,
> regarding libio-html-perl: autopkgtest failure
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982802: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982802
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Adrian Bunk 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 14 Feb 2021 18:33:42 +0200
> Subject: libio-html-perl: autopkgtest failure
> Source: libio-html-perl
> Version: 1.004-1
> Severity: serious
>
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/libi/libio-html-perl/10422807/log.gz
>
> ...
> t/00-all_prereqs.t ..
> not ok 1 - opened META.json
> 1..1
> Failed 1/1 subtests
> ...
> Test Summary Report
> ---
> t/00-all_prereqs.t (Wstat: 0 Tests: 1 Failed: 1)
>   Failed test:  1
> Files=5, Tests=141,  1 wallclock secs ( 0.05 usr  0.01 sys +  0.33 cusr
> 0.03 csys =  0.42 CPU)
> Result: FAIL
> autopkgtest [15:04:02]: test autodep8-perl-build-deps:
> ---]
> autopkgtest [15:04:02]: test autodep8-perl-build-deps:  - - - - - - - - -
> - results - - - - - - - - - -
> autodep8-perl-build-deps FAIL non-zero exit status 1
> ...
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 982802-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 14 Feb 2021 17:50:29 +
> Subject: Bug#982802: fixed in libio-html-perl 1.004-2
> Source: libio-html-perl
> Source-Version: 1.004-2
> Done: gregor herrmann 
>
> We believe that the bug you reported is fixed in the latest version of
> libio-html-perl, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 982...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> gregor herrmann  (supplier of updated libio-html-perl
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sun, 14 Feb 2021 18:19:15 +0100
> Source: libio-html-perl
> Architecture: source
> Version: 1.004-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Perl Group <
> pkg-perl-maintain...@lists.alioth.debian.org>
> Changed-By: gregor herrmann 
> Closes: 982802
> Changes:
>  libio-html-perl (1.004-2) unstable; urgency=medium
>  .
>* Team upload.
>* Fix autopkgtests. Add META.json to test directory.
>  Thanks to Adrian Bunk for the bug report. (Closes: #982802)
> Checksums-Sha1:
>  01f8a956b356baa55dc0c0598696b7b965ef2eea 2299 libio-html-perl_1.004-2.dsc
>  64634ad2f483ef19dfca6498816186afaff7a98b 3500
> libio-html-perl_1.004-2.debian.tar.xz
> Checksums-Sha256:
>  8c3010ac70bddc95aac974925975309cce591b07639a0b8ce173caec05575bb5 2299
> libio-html-perl_1.004-2.dsc
>  f37ea11d8cca48238364480d3beedc3c3576d869f52ae14fc071f1cef95d9f24 3500
> libio-html-perl_1.004-2.debian.tar.xz
> Files:
>  be755439289aa1ca0b8002ed6ae10df2 2299 perl optional
> libio-html-perl_1.004-2.dsc
>  065e920631aeef20f5640d69e6d4cc08 3500 perl optional
> libio-html-perl_1.004-2.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
>
> iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmApXAxfFIAALgAo
> aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
> RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
> qganlQ/+MU+5V1OdSn7lur1vQ9iVcOzrhXyNslfnIfZk9/GlFRGTk+JDpYiWSgNS
> hKaSy43tNVfZ6a7MW/pSIJEnMlk2y8+7l/eIJSHniObs3PmUYcN4hv7hpE1PbFsv
> CT9XzDOmZDVXe/VwdDZxsC7dVLTlatcEOMzr5hgqXIXljpMa1rFQJLmgDugD7icM
> LSM8swScjl0Z7m7814OZjXNvHOW2fYsbxpWQRIc77ckj3wjkdGxlC5iCwrI0n2Ly
> /vDj42GFBE/+iNFU9gwVI8A/scjAwAO5drmvopjJX1/7AzbHNinqFA0CCBT5EZkB
> 0BRg3b0ZYtjL2qqUC9Ahy6z130ynMOsaZPAxVoBSnIdSweAa6cFZHdx01v36KOIV
> oTpKPqoQpWQkkOfc2aGjJ9ddQARRv3MJ9Brwo2qNGt8fXLpmAe7dMO7kAITwVWj5
> L2CJEPH1q3P4xW9U91nUU6r6gskjqwV/YyoGG/ntWqQI2TP3ptGwhshYoB/AKuDo
> bgqzG3dQDdoWrCTzCVdVVI3ofIOVqoyBRkP9mXBAQx+GzXZeo4D28P2UQlhzv0Nz
> 

Bug#763824: (no subject)

[jaydenjuan08eya22]

Sent from vivo smartphone

Bug#976045: bind9: flaky autopkgtest on ci.debian.net

[Ondřej Surý]

Hi Ivo,

thanks for the testing.

I split the test into two - simpletest and validation, marked the
validation test as flaky and then I also added a simple repetition around
the validation command to allow `named` to bootstrap the validation chain
first and only fail if the `dig` fails for 10th time.

This should fix the autopkgtest for now. Any test that requires DNS is
flaky by definition.

Cheers,
Ondrej

On Tue, 9 Feb 2021 at 19:11, Ivo De Decker  wrote:

> Hi,
>
> On Mon, Dec 07, 2020 at 09:12:25AM +0100, Ondřej Surý wrote:
> >Hi Paul,
> >I am pretty sure the culprit is this upstream
> >issue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2305
> >So, the bug should resolve itself when BIND 9.16.10 is uploaded to the
> >archive.  If not, I'll modify the autopkgtest.
> >Ondrej
>
> Testing now has 1:9.16.11-2. I retriggered the tests a number of times
> earlier
> today, and one of them failed:
>
> https://ci.debian.net/packages/b/bind9/testing/amd64/
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/b/bind9/10370897/log.gz
>
> Cheers,
>
> Ivo
>
>

Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

[Jerome BENOIT]

Hi Dennis, thanks for confirming.
May I simply neutralize the involved test temporarily ?
Cheers, Jerome 

Bug#977990: os-autoinst: FTBFS on i386: 3/3 Test #3: test-perl-testsuite ..............***Failed 332.81 sec

[Paul Gevers]

Hi,

On Thu, 24 Dec 2020 00:05:30 +0100 Sebastian Ramacher
 wrote:
> Source: os-autoinst
> Version: 4.6.1604525166.912dfbd-0.2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> os-autoinst FTBFS on i386:
> | 3: ./29-backend-generalhw.t . ok
> | 3: 
> | 3: #   Failed test 'Result in testresults/result-reload_needles.json is ok'
> | 3: #   at ./99-full-stack.t line 86.
> | 3: #  got: 'fail'
> | 3: # expected: 'ok'
> | 3: Bailout called.  Further testing stopped:  
> testresults/result-reload_needles.json failed
> | 3: FAILED--Further testing stopped: testresults/result-reload_needles.json 
> failed
> | 3/3 Test #3: test-perl-testsuite ..***Failed  332.81 sec
> 
> See
> https://buildd.debian.org/status/fetch.php?pkg=os-autoinst=i386=4.6.1604525166.912dfbd-0.2=1608714762=0

I don't know if anything changed, but the FORTH build was successful.
Could be that the test is flaky.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982820: RFS: lebiniou-data/3.54.1-1 -- datafiles for Le Biniou

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

 * Package name: lebiniou-data
   Version : 3.54.1-1
   Upstream Author : Olivier Girondel 
 * URL : https://biniou.net
 * License : GPL-2+
   Section : graphics

It builds this binary package:

lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

  https://mentors.debian.net/package/lebiniou-data


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

  dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.54.1-1.dsc

Changes since the last upload:

  * New upstream release 3.54.1.
  * debian/tests/control: Bump lebiniou minimal version.

Regards,

--
Olivier Girondel

Bug#982821: RFS: lebiniou/3.54.0-1 -- user-friendly, powerful music visualization / VJing tool

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: lebiniou
   Version : 3.54.0-1
   Upstream Author : Olivier Girondel 
 * URL : https://biniou.net
 * License : GPL-2+
   Section : graphics

It builds this binary package:

  lebiniou - user-friendly, powerful music visualization / VJing tool

The package appears to be lintian-clean.

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.54.0-1.dsc

Changes since the last upload:

  * New upstream release 3.54.0.
  * debian/control: Depends: Update lebiniou-data (>= 3.54.1).
  * debian/control: Build-Depends: Add uglifyjs, cleancss.
  * debian/lebiniou.lintian-overrides: Updated.
  * debian/source/lintian-overrides: Updated.
  * debian/lebiniou.examples: Removed.
  * debian/tests/control: Bump lebiniou-data minimal version.

Regards,

--
Olivier Girondel

Bug#981864: libinih: Please provide libinih1-udeb

[Jessica Clarke]

On Thu, Feb 11, 2021 at 10:50:47PM +0100, Bastian Germann wrote:
> On Wed, 10 Feb 2021 17:10:30 +0800 Yangfl  wrote:
> > 在 2021年2月9日星期二，Bastian Germann  写道：
> > 
> > > On Mon, 8 Feb 2021 15:36:31 +0100 Cyril Brulebois  wrote:
> > >
> > >> We would be happy to have this merged soon, since xfs support in the
> > >> installer is currently broken:
> > >>
> > >>   https://bugs.debian.org/981662
> > >>
> > >> I'm happy to upload the package and talk to the ftp team (a little
> > >> trip to NEW will happen) myself if that helps.
> > >>
> > >
> > > Yes, please upload. I think, the timeline justifies a NMU.
> > >
> > 
> > Hi, please upload the latest version from git repo, I have some troubles
> > finding sponsor, thanks.
> 
> Hi Cyril,
> 
> will you sponsor the new version?

Hi,
I've uploaded the package after discussions with Cyril on IRC.

NB: You should look at addressing the following lintian checks in future:

I: libinih1: hardening-no-fortify-functions 
usr/lib/x86_64-linux-gnu/libinih.so.1
I: libinih1-udeb udeb: hardening-no-fortify-functions usr/lib/libinih.so.1
I: libinih source: override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS (line 
23)

Jess

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Bernhard Übelacker]

Am 14.02.21 um 11:37 schrieb Drew Parsons:
The dolfinx comments go on to say you might want to set 64 for 
user-compilation on AVX-512 systems. Would that AVX comment apply to 
your specific system?



Hello Drew,
my specific system is an amd64 kvm/qemu VM running at a AMD Ryzen 1700.
So as far as I see there is no avx512, just avx and avx 2 from lscpu.

But by using dpkg-buildpackage I was under the impression that the produced
binaries are for Debian baseline and not optimized for my CPU.
Also there is no -march visible when building with dpkg-buildpackage.


So from python side the abort happens here:
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/lib/python3/dist-packages/gmsh.py", line 2256, in 
getElementProperties
api_wantedOrientations_, api_wantedOrientations_n_,
  File "/usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py", line 39, in 
name, dim, order, num_nodes, local_coords, num_first_order_nodes = 
model.mesh.getElementProperties(element_types[0])


I tested also to build libgmsh4 with this change:
-DEIGEN_INC:STRING="/usr/include/eigen3" \
-DEIGEN_MAX_ALIGN_BYTES=32

Then demo_gmsh.py gets over line 39 but still gives later
another python backtrace in line 62.


So from my limited point of view (as I don't really know much about these 
packages),
I still guess either all (might not just affect gmsh and dolphinx?)
have to build with the same alignment or
somehow allocation and deallocation have to take place
at the same side of the shared library boundary.

Kind regards,
Bernhard

Bug#579491: error: quo is zero

[greenfreedom10]

On 2021-02-14 06:02, Phil Morrell wrote:

I don't think this was ever reported upstream directly, but I cannot
reproduce it on buster gtk:

log(tan((pi/4)+(x*pi)/360))*6371000=0
x ≈ 360n + 0


Hi,

It also works now for me, so I think this bug can be closed.

$ qalc -v
2.8.2

$ qalc "log(tan((pi/4)+(x*pi)/360))*6371000=0"
((log(tan(((pi / 4) + ((x * pi) / 360)) * radian), e) * 6371000) = 0) = 
approx. (x = 360n)


Thank you

Bug#982814: manpages-it-dev: missing Breaks+Replaces: manpages-it (<< 4.9.1)

[Andreas Beckmann]

Package: manpages-it-dev
Version: 4.9.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../manpages-it-dev_4.9.1-2_all.deb ...
  Unpacking manpages-it-dev (4.9.1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-it-dev_4.9.1-2_all.deb (--unpack):
   trying to overwrite '/usr/share/man/it/man2/_syscall.2.gz', which is also in 
package manpages-it 3.73-2.1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-it-dev_4.9.1-2_all.deb

The following manpages were moved to the new -it-dev package:

usr/share/man/it/man2/_syscall.2.gz
usr/share/man/it/man2/adjtimex.2.gz
usr/share/man/it/man2/fork.2.gz
usr/share/man/it/man2/mount.2.gz
usr/share/man/it/man2/readv.2.gz
usr/share/man/it/man2/swapoff.2.gz
usr/share/man/it/man2/swapon.2.gz
usr/share/man/it/man2/symlink.2.gz
usr/share/man/it/man2/symlinkat.2.gz
usr/share/man/it/man2/sync.2.gz
usr/share/man/it/man2/sysfs.2.gz
usr/share/man/it/man2/sysinfo.2.gz
usr/share/man/it/man2/umask.2.gz
usr/share/man/it/man2/umount.2.gz
usr/share/man/it/man2/umount2.2.gz
usr/share/man/it/man2/uname.2.gz
usr/share/man/it/man2/unimplemented.2.gz
usr/share/man/it/man2/unlink.2.gz
usr/share/man/it/man2/unlinkat.2.gz
usr/share/man/it/man2/uselib.2.gz
usr/share/man/it/man2/ustat.2.gz
usr/share/man/it/man2/utime.2.gz
usr/share/man/it/man2/utimes.2.gz
usr/share/man/it/man2/vfork.2.gz
usr/share/man/it/man2/vhangup.2.gz
usr/share/man/it/man2/vm86.2.gz
usr/share/man/it/man2/wait.2.gz
usr/share/man/it/man2/wait3.2.gz
usr/share/man/it/man2/wait4.2.gz
usr/share/man/it/man2/waitpid.2.gz
usr/share/man/it/man2/write.2.gz
usr/share/man/it/man2/writev.2.gz
usr/share/man/it/man3/adjtime.3.gz
usr/share/man/it/man3/daemon.3.gz
usr/share/man/it/man3/err.3.gz
usr/share/man/it/man3/exit.3.gz
usr/share/man/it/man3/undocumented.3.gz


cheers,

Andreas


manpages-it=3.73-2.1_manpages-it-dev=4.9.1-2.log.gz
Description: application/gzip

Bug#980183: Kindly consider uploading the updated (German) translation

[Helge Kreutzmann]

Dear Anibal,
the freeze has begun and the German man page translation for sensible-utils 
is not yet included.

Could you kindly consider performing another upload with the
translation? If you need help packaging the update, please contact me.

You will need to ask for a freeze exception, but by experience those
are granted for l10n (only) changes.

Thanks!

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#982629: Kindly consider uploading the updated (German) translation

[Helge Kreutzmann]

Dear prometheus-smokeping-prober maintainers,
the freeze has begun and the German Debconf translation is not yet
included. 

Could you kindly consider performing another upload with the
translation? If you need help packaging the update, please contact me.

You will need to ask for a freeze exception, but by experience those
are granted for l10n (only) changes.

Thanks!

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#982637: Kindly consider uploading the updated (German) translation

[Helge Kreutzmann]

Dear QA group,
the freeze has begun and the German man page translation for
apt-listchanges is not yet included.

Could you kindly consider performing another upload with the
translation? If you need help packaging the update, please contact me.
I can provide the updated package, but since I'm a DM only I cannot
upload, hence would need a sponsor.

You will need to ask for a freeze exception, but by experience those
are granted for l10n (only) changes.

Thanks!

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#977854: Kindly consider uploading the updated (German) translation

[Helge Kreutzmann]

Dear Clint,
the freeze has begun and the German man page translation for fakeroot
is not yet included.

Could you kindly consider performing another upload with the
translation? If you need help packaging the update, please contact me.

You will need to ask for a freeze exception, but by experience those
are granted for l10n (only) changes.

Thanks!

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#977679: Kindly consider uploading the updated (German) translation

[Helge Kreutzmann]

Dear Debian Perl Group,
dear Axel,
the freeze has begun and the German man page translation for debsums
is not yet included.

Could you kindly consider performing another upload with the
translation? If you need help packaging the update, please contact me.

You will need to ask for a freeze exception, but by experience those
are granted for l10n (only) changes.

Thanks!

Greetings

 Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#977678: Kindly consider uploading the updated (German) translation

[Helge Kreutzmann]

Dear Adduser-Developers,
dear Marc,
the freeze has begun and the German man page translation for adduser
is not yet included. (And other l10n bugs are open as well).

Could you kindly consider performing another upload with the
translation? If you need help packaging the update, please contact me.

You will need to ask for a freeze exception, but by experience those
are granted for l10n (only) changes.

Thanks!

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#977939: Kindly consider uploading the updated (German) translation

[Helge Kreutzmann]

Dear Ben,
the freeze has begun and the German man page translation for linux-base
is not yet included.

Could you kindly consider performing another upload with the
translation? If you need help packaging the update, please contact me.

You will need to ask for a freeze exception, but by experience those
are granted for l10n (only) changes.

Thanks!

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#982786: growlight: autopkgtest regression

[Nick Black]

Thanks for the heads-up; glad I've got those autopkgtests. Looking into this 
now with the hope of fixing it ASAP.

Bug#982830: golang-code.gitea-git: unmaintained go library - keep out of testing

[Chris Hofstaedtler]

Source: golang-code.gitea-git
Version: 0.0~git20190411.63b74d4+ds-1
Severity: serious

Upstream (Gitea) appears to have moved on to another solution, so
this is dead code (upstream repo is marked as archived).

Lets not have it in bullseye, especially as nothing else depends on
it, and its orphaned in Debian.

Chris

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

[mh]

Am Sun, 14 Feb 2021 15:39:51 +
schrieb Brian Potkin :

> On Sun 14 Feb 2021 at 16:17:34 +0100, mh wrote:
> 
> > Am Sun, 14 Feb 2021 14:35:53 +
> > schrieb Brian Potkin :
> >   
> > > On Sun 14 Feb 2021 at 14:47:42 +0100, mh wrote:
> > >   
> 
> [...]
> 
> > > > # systemctl start ipp-usb
> > > > ~#
> > > > 
> > > > # systemctl status ipp-usb
> > > > ● ipp-usb.service - Daemon for IPP over USB printer support
> > > >  Loaded: loaded (/lib/systemd/system/ipp-usb.service;
> > > > static) Active: active (running) since Sun 2021-02-14 14:01:53
> > > > CET; 32min ago Docs: man:ipp-usb(8)
> > > >Main PID: 854 (ipp-usb)
> > > >   Tasks: 10 (limit: 4634)
> > > >  Memory: 7.9M
> > > > CPU: 52ms
> > > >  CGroup: /system.slice/ipp-usb.service
> > > >  └─854 /sbin/ipp-usb udev
> > > > 
> > > > Feb 14 14:01:53 neutower systemd[1]: Started Daemon for IPP
> > > > over USB printer support
> > > 
> > > That's exactly what should happen. cups-browsed should now
> > > install a queue. Anything from 'lpstat -t' now?   
> > 
> > Nothing
> >   
> > > How about 'lpstat -l -e' and  
> > 
> > Nothing
> >   
> > > 'avahi-browse -rt _ipp._tcp'?  
> > 
> > Nothing  
> 
> Inexplicable, especially not getting any outputs from the last two
> commands. I hope you did not type the apostrophes ('   ').

I did not ;-)

> 
> > But to be clear: Currently there is *no printer installed* here in
> > this system. It has been, but as I could not print I purged cups*
> > entierly and than reinstalled it as described in my initial report.
> > And now in the cups admin webpanel no Oki or USB printer is visible
> > to select a PPD file for (whereas it works fine and reliably in a
> > live ISO system).  
> 
> The whole point is that the printer installion is done via ipp-usb,
> which you have shown is active on your machine. There is no need for
> you to select a PPD or a vendor driver.

If I could have all features my printer offers available this way, then
yes. OTOH the whole problem does not seam to be the protocol used,
but cups administration not seeing the printer. 

Is there a way to completly resett systemd/udev/avahi/whatever? Month
ago I tried "apt install --reinstall systemd udev" as an attempt to
exclude any malfunction.

thanks


Michael 

> 
> Regards,
> 
> Brian.

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

[Brian Potkin]

On Sun 14 Feb 2021 at 17:44:20 +0100, mh wrote:

> Am Sun, 14 Feb 2021 15:39:51 +
> schrieb Brian Potkin :
> 
> > The whole point is that the printer installion is done via ipp-usb,
> > which you have shown is active on your machine. There is no need for
> > you to select a PPD or a vendor driver.
> 
> If I could have all features my printer offers available this way, then
> yes. OTOH the whole problem does not seam to be the protocol used,
> but cups administration not seeing the printer. 
> 
> Is there a way to completly resett systemd/udev/avahi/whatever? Month
> ago I tried "apt install --reinstall systemd udev" as an attempt to
> exclude any malfunction.

Is avahi-daemon active?

  systemctl status avahi-daemon

Do you have a firewall?

Regards,

Brian.

Bug#982805: screenshot of bug

[Tad Whiteside]

screenshot

Bug#982806: sshfs: SIGSEGV when using max_conns > 1

[Peter Gerber]

Package: sshfs
Version: 3.7.1+repack-1
Severity: important

Dear Maintainer,

the following steps crash sshfs with SIGSEGV when a file is open while
the folder containing it is renamed.

Steps to reproduce:

#!/usr/bin/python3
import os

os.mkdir('old_name')
f = open('old_name/f', 'w')
os.rename('old_name', 'new_name')
f.close()  # crashes here


Output from gdb:

user@media:~/sshfs/sshfs-fuse-3.7.1+repack/build$ gdb -ex r --args sshfs
mia.arbitrary.ch:/ /home/user/b -f -d -o max_conns=2
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from sshfs...
Reading symbols from
/usr/lib/debug/.build-id/0c/1ef7b947ed8cfbdddaa25f2bf189b9bf14347e.debug...
Starting program: /usr/bin/sshfs mia.arbitrary.ch:/ /home/user/b -f -d
-o max_conns=2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
SSHFS version 3.7.1
[Detaching after fork from child process 15132]
[Detaching after fork from child process 15134]
executing  <-x> <-a> <-oClearAllForwardings=yes> <-2>
 <-s> 
Server version: 3
Extension: posix-ren...@openssh.com <1>
Extension: stat...@openssh.com <2>
Extension: fstat...@openssh.com <2>
Extension: hardl...@openssh.com <1>
Extension: fs...@openssh.com <1>
Extension: lsets...@openssh.com <1>
[New Thread 0x77be1700 (LWP 15136)]
[New Thread 0x772de700 (LWP 15137)]
[New Thread 0x769db700 (LWP 15138)]
[1] LSTAT
  [1]  ATTRS   41bytes (3ms)
[2] LSTAT
  [2]  ATTRS   41bytes (2ms)
[3] LSTAT
  [3]  ATTRS   41bytes (1ms)
[4] LSTAT
  [4]  ATTRS   41bytes (1ms)
[5] LSTAT
  [5] STATUS   33bytes (3ms)
[6] LSTAT
  [6] STATUS   33bytes (3ms)
[7] MKDIR
  [7] STATUS   28bytes (2ms)
[8] LSTAT
  [8]  ATTRS   41bytes (2ms)
[9] LSTAT
  [9] STATUS   33bytes (1ms)
[00010] OPEN
[00011] LSTAT
  [00010] HANDLE   17bytes (1ms)
  [00011]  ATTRS   41bytes (1ms)
[00012] FSTAT
  [00012]  ATTRS   41bytes (1ms)
[Detaching after fork from child process 15140]
executing  <-x> <-a> <-oClearAllForwardings=yes> <-2>
 <-s> 
Server version: 3
Extension: posix-ren...@openssh.com <1>
Extension: stat...@openssh.com <2>
Extension: fstat...@openssh.com <2>
Extension: hardl...@openssh.com <1>
Extension: fs...@openssh.com <1>
Extension: lsets...@openssh.com <1>
[New Thread 0x761da700 (LWP 15142)]
[00013] LSTAT
  [00013] STATUS   33bytes (1ms)
[00014] EXTENDED
  [00014] STATUS   28bytes (1ms)
[New Thread 0x759d9700 (LWP 15143)]
[00015] CLOSE

Thread 2 "sshfs" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77be1700 (LWP 15136)]
--Type  for more, q to quit, c to continue without paging--c
0x55560423 in sshfs_release (path=0x7f60
"/media/_unsorted/_in/new_name/f", fi=0x77be0d30) at ../sshfs.c:2890
2890ce->refcount--;
(gdb) t 2
[Switching to thread 2 (Thread 0x77be1700 (LWP 15136))]
#0  0x55560423 in sshfs_release (path=0x7f60
"/media/_unsorted/_in/new_name/f",
fi=0x77be0d30) at ../sshfs.c:2890
2890ce->refcount--;
(gdb) bt
#0  0x55560423 in sshfs_release (path=0x7f60
"/media/_unsorted/_in/new_name/f",
fi=0x77be0d30) at ../sshfs.c:2890
#1  0x77f82cba in fuse_do_release (f=0x55571080, ino=6,
path=0x7f60 "/media/_unsorted/_in/new_name/f", fi=) at ../lib/fuse.c:3142
#2  0x77f85cb6 in fuse_lib_release (req=0x70001fb0, ino=6,
fi=0x77be0d30) at ../lib/fuse.c:4121
#3  0x77f8c8c6 in do_release (req=,
nodeid=, inarg=)
at ../lib/fuse_lowlevel.c:1455
#4  0x77f8ea73 in fuse_session_process_buf_int
(se=0x55571460, buf=buf@entry=0x55591bb0,
ch=) at ../lib/fuse_lowlevel.c:2666
#5  0x77f8a383 in fuse_do_work (data=0x55591b90) at
../lib/fuse_loop_mt.c:163
#6  0x77f5cea7 in start_thread (arg=) at
pthread_create.c:477
#7  0x77d5ddef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) print ce
$1 = 
(gdb) print ce->refcount
value has been optimized out
(gdb) list
2885chunk_put_locked(sf->readahead);
2886   

Bug#982807: datovka: version too old to be useful

[Ondřej Surý]

Package: datovka
Version: 4.9.3-2.1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The version in testing / unstable is too old to be really usable.

It's better to not have it in next stable Debian.

Ondrej

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU threads)
Kernel taint flags: 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
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages datovka depends on:
ii  libc6 2.31-9
ii  libgcc-s1 [libgcc1]   11-20210130-1
pn  libisds5  
ii  libqt5core5a  5.15.2+dfsg-4
ii  libqt5gui55.15.2+dfsg-4
ii  libqt5network55.15.2+dfsg-4
ii  libqt5printsupport5   5.15.2+dfsg-4
ii  libqt5sql55.15.2+dfsg-4
ii  libqt5sql5-sqlite 5.15.2+dfsg-4
ii  libqt5svg55.15.2-2
ii  libqt5widgets55.15.2+dfsg-4
ii  libssl1.1 1.1.1i-3
ii  libstdc++610.2.1-6
pn  qttranslations5-l10n  

datovka recommends no packages.

datovka suggests no packages.

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmApcOVfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKSrQ//dOlvoJf6+mbqUDS1PIz9cLna3atd55yjCUaLUwuvtGHb9RrBjuS9jzDt
+8WzjhT8VPbjmnRTlsJsVPq6pJa9E4BpFLWbR/A1PGOoYJxSOw9FNTg01ykqtFOd
8q/pXyXVNtI7TGs29VhRLGuzLoVZR5vQeKT3Q3FKvYZtf4wy4ZBV/untY8yzErqd
AsAK451M6SQ8S1X3uB2R20qFyes/Fpsa2XGcocBdG2gPDS9fLySyBLgis4EwlcWO
c5LrnWWMhDmKzqjYDdHk1SrzmdUZeb0MZtJD50dnop4Gh4L0m2DG7Do5UKWnJOjM
PC00eAbJBqQz2O57ILU/9ciy5mow0Lzib+eqCRtiQT8KUGc9d68yQy14hc0Uk/NR
Se1DlHOewwKx6i+cRyxdnkL1k+5WrwxzbyQPHr94S5p51t7bhG4qZf7l13d/hlXr
7TN4mnSTLtfXRKUAKdiVqizEo5UFA9DneINYtRR/IGDzFN91hmgD8tzxqqHxvMjJ
cUAPq3J1hdVBIbeoYYEfhP+mgyTSQMrS4uFvEikQSvj5Z84AM8FYOYXOTAmKER7W
RsAM49LTpBfZF21lL9FsOXDdRRK0YW0fiMY1b5PdxK6M+HEhOUrhn7OMcovILg20
+fW1h8tOoAkYd/gZa3S28mrQbSnDvyjM0uRntKnsYTXbsIolaT8=
=ppTl
-END PGP SIGNATURE-

Bug#979866: marked as done (knxd FTBFS everywhere: autoconf issues)

[Willy nilly]

close #979866

On Sun, Feb 14, 2021 at 8:00 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 14 Feb 2021 21:57:11 +0200
> with message-id <20210214195710.GA20085@localhost>
> and subject line Re: Bug#979866: knxd FTBFS everywhere: autoconf issues
> has caused the Debian Bug report #979866,
> regarding knxd FTBFS everywhere: autoconf issues
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 979866: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979866
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Helmut Grohne 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Mon, 11 Jan 2021 06:56:32 +0100
> Subject: knxd FTBFS everywhere: autoconf issues
> Source: knxd
> Version: 0.14.41-1
> Severity: serious
> Tags: ftbfs
>
> knxd fails to build from source for all attempted architectures on the
> buildds. A build log usually ends with:
>
> |dh_autoreconf -a
> |  find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*'
> -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f
> -exec md5sum {} + -o -type l -printf "symlink  %p
> | " > debian/autoreconf.before
> |  grep -q ^XDT_ configure.ac
> |  autoreconf -f -i
> | configure.ac:30: error: AC_INIT should be called with package and
> version arguments
> | /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
> | configure.ac:30: the top level
> | autom4te: /usr/bin/m4 failed with exit status: 1
> | aclocal: error: /usr/bin/autom4te failed with exit status: 1
> | autoreconf: aclocal failed with exit status: 1
> |  find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*'
> -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f
> -exec md5sum {} + -o -type l -printf "symlink  %p
> | " > debian/autoreconf.after
> | dh_autoreconf: error: autoreconf -f -i returned exit code 1
> | make: *** [debian/rules:14: build-arch] Error 25
>
> Could this be related to autoconf 2.70?
>
> Helmut
>
>
>
> -- Forwarded message --
> From: Adrian Bunk 
> To: Helmut Grohne , 979866-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 14 Feb 2021 21:57:11 +0200
> Subject: Re: Bug#979866: knxd FTBFS everywhere: autoconf issues
> Version: 0.14.46-1
>
> On Mon, Jan 11, 2021 at 06:56:32AM +0100, Helmut Grohne wrote:
> > Source: knxd
> > Version: 0.14.41-1
> > Severity: serious
> > Tags: ftbfs
> >
> > knxd fails to build from source for all attempted architectures on the
> > buildds. A build log usually ends with:
> >
> > |dh_autoreconf -a
> > |  find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path
> '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a
> -type f -exec md5sum {} + -o -type l -printf "symlink  %p
> > | " > debian/autoreconf.before
> > |  grep -q ^XDT_ configure.ac
> > |  autoreconf -f -i
> > | configure.ac:30: error: AC_INIT should be called with package and
> version arguments
> > | /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded
> from...
> > | configure.ac:30: the top level
> > | autom4te: /usr/bin/m4 failed with exit status: 1
> > | aclocal: error: /usr/bin/autom4te failed with exit status: 1
> > | autoreconf: aclocal failed with exit status: 1
> > |  find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path
> '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a
> -type f -exec md5sum {} + -o -type l -printf "symlink  %p
> > | " > debian/autoreconf.after
> > | dh_autoreconf: error: autoreconf -f -i returned exit code 1
> > | make: *** [debian/rules:14: build-arch] Error 25
> >...
>
> This seems fixed in 0.14.46-1:
> https://buildd.debian.org/status/logs.php?pkg=knxd=0.14.46-1
>
> > Helmut
>
> cu
> Adrian

Bug#982802: Info received (Bug#982802: marked as done (libio-html-perl: autopkgtest failure))

[Willy nilly]

close #982802

On Sun, Feb 14, 2021 at 8:24 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Perl Group 
>
> If you wish to submit further information on this problem, please
> send it to 982...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 982802: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982802
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#982374: xcwcp: using the mouse to emulate a paddle doesn't work

[Federico Grau]

Control: forcemerge 979113 -1 

On Sun, Feb 14, 2021 at 09:26:58AM +, Ottavio Caruso wrote:
> On Sat, 13 Feb 2021 at 22:33, Federico Grau  wrote:
> >
> > Hello Ottavio Caruso,
> >
> > Your bug description reads like a dup of #979113 "xcwcp: should dlopen
> > SO-versioned libpulse-simple", which is resolved for the next Debian stable
> > release (with xcwcp v3.5.1-4).
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979113
> >
> >
> > Could you try the following workaround, and install "libpulse-dev", then
> > report if the problem is corrected?
> >
> > apt-get install libpulse-dev
> >
> 
> This fixes it for me. Thanks.
> 
> -- 
> Ottavio Caruso

-- 
I choose information and knowledge over profit.

Bug#982707: marked as done (ruby-redis-activesupport: FTBFS: ERROR: Test "ruby2.7" failed: ArgumentError: unknown keywords: :pool_size, :pool_timeout)

[Willy nilly]

close #982707

On Sun, Feb 14, 2021 at 9:57 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 14 Feb 2021 21:53:57 +
> with message-id 
> and subject line Bug#982707: fixed in ruby-redis-store 1.9.0-1
> has caused the Debian Bug report #982707,
> regarding ruby-redis-activesupport: FTBFS: ERROR: Test "ruby2.7" failed:
> ArgumentError: unknown keywords: :pool_size, :pool_timeout
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982707: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982707
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Lucas Nussbaum 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 13 Feb 2021 18:10:07 +0100
> Subject: ruby-redis-activesupport: FTBFS: ERROR: Test "ruby2.7" failed:
> ArgumentError: unknown keywords: :pool_size, :pool_timeout
> Source: ruby-redis-activesupport
> Version: 5.2.0-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210213 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > ArgumentError: unknown keywords: :pool_size, :pool_timeout
> >
>  /usr/share/rubygems-integration/all/gems/redis-4.2.5/lib/redis.rb:836:in
> `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/interface.rb:9:in `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/ttl.rb:8:in `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/serialization.rb:5:in `block
> in set'
> > /usr/lib/ruby/vendor_ruby/redis/store/serialization.rb:39:in
> `_marshal'
> > /usr/lib/ruby/vendor_ruby/redis/store/serialization.rb:5:in `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/namespace.rb:7:in `block in
> set'
> > /usr/lib/ruby/vendor_ruby/redis/store/namespace.rb:84:in `namespace'
> > /usr/lib/ruby/vendor_ruby/redis/store/namespace.rb:7:in `set'
> > /<>/lib/active_support/cache/redis_store.rb:282:in
> `block (2 levels) in write_entry'
> > /usr/lib/ruby/vendor_ruby/connection_pool.rb:65:in `block (2 levels)
> in with'
> > /usr/lib/ruby/vendor_ruby/connection_pool.rb:64:in `handle_interrupt'
> > /usr/lib/ruby/vendor_ruby/connection_pool.rb:64:in `block in with'
> > /usr/lib/ruby/vendor_ruby/connection_pool.rb:61:in `handle_interrupt'
> > /usr/lib/ruby/vendor_ruby/connection_pool.rb:61:in `with'
> > /<>/lib/active_support/cache/redis_store.rb:268:in
> `with'
> > /<>/lib/active_support/cache/redis_store.rb:282:in
> `block in write_entry'
> > /<>/lib/active_support/cache/redis_store.rb:340:in
> `failsafe'
> > /<>/lib/active_support/cache/redis_store.rb:280:in
> `write_entry'
> > /<>/lib/active_support/cache/redis_store.rb:86:in
> `block in write'
> >
>  
> /usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/cache.rb:686:in
> `block in instrument'
> >
>  
> /usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/notifications.rb:182:in
> `instrument'
> >
>  
> /usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/cache.rb:686:in
> `instrument'
> > /<>/lib/active_support/cache/redis_store.rb:81:in
> `write'
> > /<>/test/active_support/cache/redis_store_test.rb:22:in
> `block in setup'
> >
>  /<>/test/active_support/cache/redis_store_test.rb:762:in
> `with_store_management'
> > /<>/test/active_support/cache/redis_store_test.rb:21:in
> `setup'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:96:in `block (3 levels)
> in run'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in
> `capture_exceptions'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels)
> in run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in
> run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'

Bug#982715: marked as done (ruby-redis-rack: FTBFS: ERROR: Test "ruby2.7" failed: ArgumentError: unknown keywords: :path, :domain, :expire_after, :secure, :httponly, :defer, :renew, :sidbits, :secure_

[Willy nilly]

close #982715

On Sun, Feb 14, 2021 at 9:57 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sun, 14 Feb 2021 21:53:57 +
> with message-id 
> and subject line Bug#982715: fixed in ruby-redis-store 1.9.0-1
> has caused the Debian Bug report #982715,
> regarding ruby-redis-rack: FTBFS: ERROR: Test "ruby2.7" failed:
> ArgumentError: unknown keywords: :path, :domain, :expire_after, :secure,
> :httponly, :defer, :renew, :sidbits, :secure_random, :redis_server
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982715: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982715
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Lucas Nussbaum 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 13 Feb 2021 18:10:10 +0100
> Subject: ruby-redis-rack: FTBFS: ERROR: Test "ruby2.7" failed:
> ArgumentError: unknown keywords: :path, :domain, :expire_after, :secure,
> :httponly, :defer, :renew, :sidbits, :secure_random, :redis_server
> Source: ruby-redis-rack
> Version: 2.1.2-4
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210213 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > ArgumentError: unknown keywords: :path, :domain, :expire_after, :secure,
> :httponly, :defer, :renew, :sidbits, :secure_random, :redis_server
> >
>  /usr/share/rubygems-integration/all/gems/redis-4.2.5/lib/redis.rb:836:in
> `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/interface.rb:9:in `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/ttl.rb:8:in `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/serialization.rb:5:in `block
> in set'
> > /usr/lib/ruby/vendor_ruby/redis/store/serialization.rb:39:in
> `_marshal'
> > /usr/lib/ruby/vendor_ruby/redis/store/serialization.rb:5:in `set'
> > /usr/lib/ruby/vendor_ruby/redis/store/namespace.rb:7:in `block in
> set'
> > /usr/lib/ruby/vendor_ruby/redis/store/namespace.rb:84:in `namespace'
> > /usr/lib/ruby/vendor_ruby/redis/store/namespace.rb:7:in `set'
> > /<>/lib/rack/session/redis.rb:49:in `block (2 levels)
> in write_session'
> > /<>/lib/redis/rack/connection.rb:22:in `with'
> > /<>/lib/rack/session/redis.rb:82:in `with'
> > /<>/lib/rack/session/redis.rb:49:in `block in
> write_session'
> > /<>/lib/rack/session/redis.rb:70:in `with_lock'
> > /<>/lib/rack/session/redis.rb:48:in `write_session'
> > /usr/lib/ruby/vendor_ruby/rack/session/abstract/id.rb:391:in
> `commit_session'
> > /usr/lib/ruby/vendor_ruby/rack/session/abstract/id.rb:271:in
> `context'
> > /usr/lib/ruby/vendor_ruby/rack/session/abstract/id.rb:263:in `call'
> > /usr/lib/ruby/vendor_ruby/rack/mock.rb:77:in `request'
> > /usr/lib/ruby/vendor_ruby/rack/mock.rb:59:in `get'
> > /<>/test/rack/session/redis_test.rb:153:in `block (3
> levels) in '
> > /<>/test/rack/session/redis_test.rb:396:in
> `with_pool_management'
> > /<>/test/rack/session/redis_test.rb:151:in `block (2
> levels) in '
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels)
> in run'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in
> `capture_exceptions'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels)
> in run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> > /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in
> run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
> > /usr/lib/ruby/vendor_ruby/minitest.rb:68:in 

Bug#982812: youtube-dl: Usage of deprecated /usr/bin/python symlink

[Rogério Theodoro de Brito]

Em 14 de fevereiro de 2021 16:30:40 BRT, Vangelis Skarmoutsos 
 escreveu:
>Package: youtube-dl
>Version: 2021.02.04.1-1
>Severity: important
>
>Dear Maintainer,
>
>the usage of the youtube-dl command is producing:
>/usr/bin/env: «python»: Δεν υπάρχει τέτοιο αρχείο ή κατάλογος (<- Greek
>for "no
>such file or folder")
>
>
>A note at https://wiki.debian.org/Python mentions:
>"Debian testing (bullseye) has removed the "python" package and the
>'/usr/bin/python' symlink due to the deprecation of Python 2. No
>packaged
>scripts should depend on the existence of '/usr/bin/python': if they
>do, that
>is a bug that should be reported to Debian. You can use the
>'python-is-python3'
>or 'python-is-python2' packages to restore an appropriate
>'/usr/bin/python'
>symlink for third-party or legacy scripts. "
>
>
>When python-is-python3 package was installed, youtube-dl command worked
>as
>expected.
>
>
>
>
>-- System Information:
>Debian Release: bullseye/sid
>  APT prefers testing
>  APT policy: (500, 'testing')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
>Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8),
>LANGUAGE not set
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages youtube-dl depends on:
>ii  python33.9.1-1
>ii  python3-pkg-resources  52.0.0-1
>
>Versions of packages youtube-dl recommends:
>ii  ca-certificates  20210119
>ii  curl 7.74.0-1
>ii  ffmpeg   7:4.3.1-8
>ii  mplayer  2:1.4+ds1-1
>ii  python3-pyxattr  0.7.2-1+b1
>ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b2
>ii  wget 1.21-1+b1
>
>Versions of packages youtube-dl suggests:
>ii  libfribidi-bin  1.0.8-2
>pn  phantomjs   
>
>-- no debconf information

Something is utterly wrong here.

I just checked the package and the shebang line is produced automatically by 
the tools in Debian that produce the majority of Python packages.

Please, provide the output of youtube-dl with the --verbose option. Make sure 
that you don't have any locally installed youtube-dl.

Regards,

Rogério Brito.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)

[Steve McIntyre]

Hey Ivo,

On Sun, Feb 14, 2021 at 07:56:20PM +0100, Ivo De Decker wrote:
>On Fri, Feb 12, 2021 at 01:35:52AM +, Steve McIntyre wrote:
>> On Tue, Feb 09, 2021 at 04:26:02PM +0100, Ivo De Decker wrote:
>> >Hi Steve,
>> >
>> >On Sun, Sep 27, 2020 at 08:39:53PM +0200, Lucas Nussbaum wrote:
>> >> During a rebuild of all packages in sid, your package failed to build
>> >> on amd64.
>> >
>> >[...]
>> >
>> >> > The following packages have unmet dependencies:
>> >> >  sbuild-build-depends-main-dummy : Depends: shim-unsigned (= 
>> >> > 15+1533136590.3beb971-7) but it is not going to be installed
>> >
>> >What is the status of shim(-signed) for bullseye?
>> >
>> >shim-unsigned has been changed, but there is no corresponding shim-signed
>> >(yet). I assume a new signature from microsoft is needed. Or are there more
>> >changes to shim-unsigned needed first?
>> 
>> There are some other changes coming, not least switching compiler to
>> gcc-10 now we've stabilised.
>
>I'm tagging #978521 ("shim: non-standard gcc/g++ used for build (gcc-9)") as
>pending to indicate that you're planning to switch to gcc-10.

Thanks. Sorry, I forgot to do that myself.

>> I'm working on new shim uploads at the
>> moment, but there's a couple of upstream patches we'll need to take as
>> well yet I think. It'll be coming soon, I promise.
>
>Could you clarify the timing for this, especially the timeline for getting the
>signature from Microsoft (as far as that can be predicted)? I'm trying to
>assess if this could become a blocker wrt the actual release. Is it an option
>to release with the current version of shim-signed (ie the one that's also in
>buster) if we don't get the signature in time?

It's not really an option to release with the old shim at this point,
I'm afraid. But there are newer processes in place around getting new
builds signed, so I'm not worrying too much here about delaying the
release. I expect to have things sorted soon.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

Bug#978727: bpfcc: Provide separate package for libbpf-tools?

[Salvatore Bonaccorso]

Hi Mika,

On Sat, Feb 13, 2021 at 09:42:53AM +0100, Michael Prokop wrote:
> * Michael Prokop [Wed Dec 30, 2020 at 11:11:32PM +0100]:
> 
> > With the ongoing efforts around BTF and CO-RE (see
> > http://www.brendangregg.com/blog/2020-11-04/bpf-co-re-btf-libbpf.html),
> > it would be nice to have a decent and working toolchain for it with
> > our upcoming bullseye release.
> 
> [...]
> 
> > So IMO it would be great, if it's possible to ship libbpf-tools on
> > Debian/bullseye systems without giving it much thoughts due to
> > dependencies and disk space requirements.
> 
> The train for bullseye has left AFAICT, but there are ongoing efforts
> regarding the packaging for other distributions at
> https://github.com/iovisor/bcc/pull/3263 and it might make sense to
> jump onto it.

Yupp, that is the case, from this point on one cannt introduce new
binary packages even built from an existing source, cf.
https://lists.debian.org/debian-devel-announce/2021/02/msg2.html . 

That said would have been nice to have it in bullseye, but let's aim
for bookworm :).

Ritesh thanks for your work on bpfcc!

Regards,
Salvatore

Bug#982772: haskell-tagsoup: Wrong homepage

[Davide Prina]

Source: haskell-tagsoup
Version: 0.14.8-2
Severity: normal

I have see that the project homepage do not respond anymore:
community.haskell.org/~ndm/tagsoup/

I think that the homepage is now:
https://github.com/ndmitchell/tagsoup
https://hackage.haskell.org/package/tagsoup

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982773: haskell-uniplate: Wrong homepage + new version

[Davide Prina]

Source: haskell-uniplate
Version: 1.6.12-9
Severity: normal

I have see that the project homepage do not respond anymore:
community.haskell.org/~ndm/uniplate/

I think that the homepage is now:
https://github.com/ndmitchell/uniplate
https://hackage.haskell.org/package/uniplate

I think here there is a new version: 1.6.13

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#982702: qrouter: FTBFS: graphics.c:9:10: fatal error: X11/Intrinsic.h: No such file or directory

[Juhani Numminen]

Control: tags -1 patch

Hi,

On Sat, 13 Feb 2021 18:04:39 +0100 Lucas Nussbaum  wrote:

Source: qrouter



During a rebuild of all packages in sid, your package failed to build
on amd64.



> graphics.c:9:10: fatal error: X11/Intrinsic.h: No such file or directory


It looks like the simple fix of build-depending on libxt-dev works.
I've sent a MR for your consideration.

https://salsa.debian.org/science-team/qrouter/-/merge_requests/1

--
Juhani Numminen

Bug#982760: gcc-11: ftbfs on mips64el due to ada problem

[Matthias Klose]

Control: tags -1 + moreinfo

thanks for providing a local patch.

please see https://gcc.gnu.org/contribute.html#patches
how to submit patches upstream.

Sorry to say, but it's not the first time you don't follow these procedures.

Matthias

Bug#982778: libglib2.0-0: GHSL-2021-045: Integer overflow in g_memdup()/g_bytes_new() on 64-bit platforms

[Simon McVittie]

Package: libglib2.0-0
Version: 2.31.8-1
Severity: important
Tags: security fixed-upstream
X-Debbugs-Cc: t...@security.debian.org, debian-...@lists.debian.org
Control: close -1 2.66.6-1

Kevin Backhouse of the GitHub Security Lab found an integer overflow in
GLib: . I've requested a
CVE ID. Until then, it's tracked as GHSL-2021-045, or within Debian as
TEMP-000-300CAD.

This was accidentally disclosed before a fix existed, and the fixes are not
completely straightforward, leading to the initial fixes in 2.66.6
containing regressions. All of the regressions *that we know of* were fixed
in 2.66.7, but there might be more.

I would recommend that any backports to stable or oldstable are reviewed
carefully before release, preferably by an upstream or downstream GLib
maintainer (which is why I'm cc'ing the LTS team as a request to not
immediately rush into backporting this).

There is a separate integer overflow fixed in 2.66.7 for which I will
report a separate bug.

smcv

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Thomas Perret]

Hi Jérémy,



I improved the packages descriptions and added 'Suggests: paperwork-gtk' 
to openpaperwork-gtk and 'Suggests: paperwork-shell, paperwork-gtk' to 
paperwork-backend.


Can you check this is enough and what you had in mind?



Well bullseye is in soft freeze.  Let's try to upload it asap to unstable,
(along with fixing the packages long descriptions and Suggests: as
described above).



From what I read from the release team[1], the soft freeze doesn't 
allow  NEW packages or to add new binaries to existing packages:


> Dropping or adding binary packages to a source package, moving
> binaries between source packages or renaming source or binary packages
> is no longer allowed. Packages with these changes will not be allowed
> to migrate to testing. These changes are also no longer appropriate in
> unstable.



Also i noticed autopkgtests are failing with lots of these (see below).
This needs to be fixed.



I can't reproduce the autopkgtest error you get. I'm running it using a 
schroot.


The errors you get seems to be due to permission error to the $HOME 
directory of the user running tests. As paperwork needs read/write 
access to this folder (at least $HOME/.config or $XDG_CONFIG_HOME) by 
default, I'm not sure this should be considered an error on paperwork side.

You can also check the autopkgtest job on salsa[2] which doesn't fail

Regards,
Thomas

[1]: https://release.debian.org/bullseye/freeze_policy.html#soft
[2]: https://salsa.debian.org/openpaperwork-team/paperwork/-/jobs/1442120

Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’

[Andreas Henriksson]

Control: tags -1 + patch

Hi again,

Attached is a possibly upstreamable patch that solves our problem
(but the base problem still exists in the code for anyone wishing to
build with openssl disabled).

See description in patch itself.

Regards,
Andreas Henriksson
Description: sk-usbhid.c: Only include sha2.h if building without openssl
Author: Andreas Henriksson 
Bug-Debian: https://bugs.debian.org/982705

There are many sha2.h and including both the openbsd-compat/sha2.h and
the (libmd) /usr/include/sha2.h causes build problems.

Other files like hash.c etc only includes the sha2.h if building
without openssl. It seems like the code in sk-usbhid.c also doesn't
really need to include it since it prefers using openssl already,
so just reorder the includes similar to hash.c and others to avoid
hitting this problem. (The underlying problem likely still needs to be
resolved for anyone who wishes to actually build without openssl
though.)

Forwarded: TODO
Last-Update: 2021-02-14

--- openssh-8.4p1.orig/sk-usbhid.c
+++ openssh-8.4p1/sk-usbhid.c
@@ -26,9 +26,6 @@
 #include 
 #include 
 #include 
-#ifdef HAVE_SHA2_H
-#include 
-#endif
 
 #ifdef WITH_OPENSSL
 #include 
@@ -37,6 +34,10 @@
 #include 
 #include 
 #include 
+#else
+# ifdef HAVE_SHA2_H
+#  include 
+# endif
 #endif /* WITH_OPENSSL */
 
 #include 

Bug#982719: firehol: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

[Jerome BENOIT]

Dear Lucas, thanks for your report.

I can not reproduce the issue on a Sid schroot a the time of writing.

Please, can you confirm the issue on your side ?

Best wishes, Jerome 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

Bug#982767: Thunderbird - Kerberos/GSSAPI ticket was not accepted

[Wolfgang Schweer]

Hi Mark, hi Andrei,

[ Andrei POPESCU, 2021-02-14 ]
> Control: reassign -1 debian-edu-config
> 
> On Du, 14 feb 21, 08:21:21, Mark Richards wrote:
> > package: debian-edu-{config}
> > severity: {normal}
> > version: {buster,latest with all updates}
> > 
> > I've got Debian Edu (Debian 10) setup with a main server, a thin client and
> > a few users connecting successfully. I've also setup Thunderbird as per the
> > instructions here:
> > https://wiki.debian.org/DebianEdu/Documentation/Buster/HowTo/Users#Using_email
> > but although I get the welcome e-mail, I cannot send. When I try to send, I
> > get the error: "The Kerberos/GSSAPI ticket was not accepted by the Outgoing
> > server (SMTP) postoffice.intern. Please check that you are logged in to the
> > Kerberos/GSSAPI realm.
[..]
> Reassigning to correct package.

This is a known issue. The Debian Edu status page contains instructions 
how to fix it, see:

https://wiki.debian.org/DebianEdu/Status/Buster#Known_problems_that_can_be_fixed_locally

Please consider to bookmark the status page. The page will be updated if 
needed.

Wolfgang


signature.asc
Description: PGP signature

Bug#982720: snapd: FTBFS: dh_auto_test fails

[Shengjing Zhu]

Control: reassign -1 src:golang-1.15 1.15.8-3
Control: affects -1 src:snapd

On Sat, Feb 13, 2021 at 06:08:57PM +0100, Lucas Nussbaum wrote:
> > --
> > FAIL: buildid_test.go:131: buildIDSuite.TestReadBuildGo
> > 
> > buildid_test.go:142:
> > c.Assert(string(output), Equals, "")
> > ... obtained string = "" +
> > ... "# command-line-arguments\n" +
> > ... "loadinternal: cannot find runtime/cgo\n"
> > ... expected string = ""
> > 
> > OOPS: 295 passed, 1 FAILED
> > --- FAIL: Test (1.23s)
> > FAIL
> > FAILgithub.com/snapcore/snapd/osutil1.237s

One more FTBFS caused by golang-1.15/1.15.8-3