Bug#964253: libbluray: Include list_titles and bdsplice utilities

[Jean-Baptiste Kempf]

And the request is here 
https://code.videolan.org/videolan/libbluray/-/merge_requests/21

On Mon, Jul 6, 2020, at 08:58, Jean-Baptiste Kempf wrote:
> Hello,
> 
> I don't really get it, to be honest, since list_titles is noinst_PROGRAMS, a 
> contrario from bd_info, because it is not really useful.
> 
> But, if you care, of course this is fine. I don't mind.
> 
> BEst,
> 
> On Sun, Jul 5, 2020, at 12:12, Vasyl Gello wrote:
>> Sebastian,
>> 
>> Maybe it is good idea to rename that tool upstream to bd_list_titles.
>> 
>> Jean-Baptiste, what do you think of it? If you are fine with it, please make 
>> a new tag as usual :)
>> -- 
>> Vasyl GelloCertified SolidWorks Expert
>> 
>> Mob.:+380 (98) 465 66 77
>> 
>> E-Mail: vasek.ge...@gmail.com
>> 
>> Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
>> 
>> July 5, 2020 9:39:12 AM UTC, sramac...@debian.org написав(-ла):
>>> Hi Nils, Vasyl,
>>> 
>>> On 2020-07-05 09:30:26 +, Vasyl Gello wrote:
 Control: block -1 by 964242
 Control: owner -1 !
 
 Hi Nils,
 
 I am building the fix locally, however please note that ANY clean-room 
 build
 (be it pbuilder / cowbuilder / sbuild) targeting unstable will end up 
 failing to
 resolve a broken dependency of bsdmainutils on bsdextrautils (Bug #964242).
 
 To work around it, I had to create a custom base tarball and pin 
 bsdmainutils
 against testing in it (12.1.2+b1).
 
 If the fixed libbluray build passes, I will do a team upload to Salsa Git.
 After that, Sebastian might upload a new Debian package version to the 
 queue.
>>> 
>>> I'm fine with bdsplice, but I think that the binary name of list_titles
>>> is too generic to be installed globally.
>>> 
>>> Cheers
>>> 
 
 On Sat, 4 Jul 2020 16:04:45 +0200 Oneric  wrote:
> Package: libbluray-bin
> Version: 1:1.1.0-1
> Severity: wishlist
> 
> Hi,
> 
> I think it might be worth including the `list_titles` and `bdsplice` 
> utilities 
> in libbluray-bin (curretnly only `bd_info`).
> list_titles gives some more information about titles/playlists on the BD 
> and 
> bdsplice allows to extract single titles/playlists or just some chapters.
> 
> Just like `bd_info` the source of these utilities is already present in 
> libbluray in src/examples and also already built – but not yet included 
> in 
> libbluray-bin.
> 
> Regards
> Nils König
> 
 
 -- 
 Vasyl GelloCertified SolidWorks Expert
 
 Mob.:+380 (98) 465 66 77
 
 E-Mail: vasek.ge...@gmail.com
 
 Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
>>> 
>> 
>> *Attachments:*
>>  * signature.asc
> 
> --
> Jean-Baptiste Kempf - President
> +33 672 704 734
> 
> 
> 

--
Jean-Baptiste Kempf - President
+33 672 704 734

Bug#964253: libbluray: Include list_titles and bdsplice utilities

[Jean-Baptiste Kempf]

Hello,

I don't really get it, to be honest, since list_titles is noinst_PROGRAMS, a 
contrario from bd_info, because it is not really useful.

But, if you care, of course this is fine. I don't mind.

BEst,

On Sun, Jul 5, 2020, at 12:12, Vasyl Gello wrote:
> Sebastian,
> 
> Maybe it is good idea to rename that tool upstream to bd_list_titles.
> 
> Jean-Baptiste, what do you think of it? If you are fine with it, please make 
> a new tag as usual :)
> -- 
> Vasyl GelloCertified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
> 
> July 5, 2020 9:39:12 AM UTC, sramac...@debian.org написав(-ла):
>> Hi Nils, Vasyl,
>> 
>> On 2020-07-05 09:30:26 +, Vasyl Gello wrote:
>>> Control: block -1 by 964242
>>> Control: owner -1 !
>>> 
>>> Hi Nils,
>>> 
>>> I am building the fix locally, however please note that ANY clean-room build
>>> (be it pbuilder / cowbuilder / sbuild) targeting unstable will end up 
>>> failing to
>>> resolve a broken dependency of bsdmainutils on bsdextrautils (Bug #964242).
>>> 
>>> To work around it, I had to create a custom base tarball and pin 
>>> bsdmainutils
>>> against testing in it (12.1.2+b1).
>>> 
>>> If the fixed libbluray build passes, I will do a team upload to Salsa Git.
>>> After that, Sebastian might upload a new Debian package version to the 
>>> queue.
>> 
>> I'm fine with bdsplice, but I think that the binary name of list_titles
>> is too generic to be installed globally.
>> 
>> Cheers
>> 
>>> 
>>> On Sat, 4 Jul 2020 16:04:45 +0200 Oneric  wrote:
 Package: libbluray-bin
 Version: 1:1.1.0-1
 Severity: wishlist
 
 Hi,
 
 I think it might be worth including the `list_titles` and `bdsplice` 
 utilities 
 in libbluray-bin (curretnly only `bd_info`).
 list_titles gives some more information about titles/playlists on the BD 
 and 
 bdsplice allows to extract single titles/playlists or just some chapters.
 
 Just like `bd_info` the source of these utilities is already present in 
 libbluray in src/examples and also already built – but not yet included in 
 libbluray-bin.
 
 Regards
 Nils König
 
>>> 
>>> -- 
>>> Vasyl GelloCertified SolidWorks Expert
>>> 
>>> Mob.:+380 (98) 465 66 77
>>> 
>>> E-Mail: vasek.ge...@gmail.com
>>> 
>>> Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
>> 
> 
> *Attachments:*
>  * signature.asc

--
Jean-Baptiste Kempf - President
+33 672 704 734

Bug#964253: libbluray: Include list_titles and bdsplice utilities

[Vasyl Gello]

Hi Jean-Baptiste!

As usual, great work! Mind adding also bdsplice to installed programs?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

July 6, 2020 7:01:37 AM UTC, Jean-Baptiste Kempf  
написав(-ла):
>And the request is here 
>https://code.videolan.org/videolan/libbluray/-/merge_requests/21
>
>On Mon, Jul 6, 2020, at 08:58, Jean-Baptiste Kempf wrote:
>> Hello,
>> 
>> I don't really get it, to be honest, since list_titles is noinst_PROGRAMS, a 
>> contrario from bd_info, because it is not really useful.
>> 
>> But, if you care, of course this is fine. I don't mind.
>> 
>> BEst,
>> 
>> On Sun, Jul 5, 2020, at 12:12, Vasyl Gello wrote:
>>> Sebastian,
>>> 
>>> Maybe it is good idea to rename that tool upstream to bd_list_titles.
>>> 
>>> Jean-Baptiste, what do you think of it? If you are fine with it, please 
>>> make a new tag as usual :)
>>> -- 
>>> Vasyl GelloCertified SolidWorks Expert
>>> 
>>> Mob.:+380 (98) 465 66 77
>>> 
>>> E-Mail: vasek.ge...@gmail.com
>>> 
>>> Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
>>> 
>>> July 5, 2020 9:39:12 AM UTC, sramac...@debian.org написав(-ла):
 Hi Nils, Vasyl,
 
 On 2020-07-05 09:30:26 +, Vasyl Gello wrote:
> Control: block -1 by 964242
> Control: owner -1 !
> 
> Hi Nils,
> 
> I am building the fix locally, however please note that ANY clean-room 
> build
> (be it pbuilder / cowbuilder / sbuild) targeting unstable will end up 
> failing to
> resolve a broken dependency of bsdmainutils on bsdextrautils (Bug 
> #964242).
> 
> To work around it, I had to create a custom base tarball and pin 
> bsdmainutils
> against testing in it (12.1.2+b1).
> 
> If the fixed libbluray build passes, I will do a team upload to Salsa Git.
> After that, Sebastian might upload a new Debian package version to the 
> queue.
 
 I'm fine with bdsplice, but I think that the binary name of list_titles
 is too generic to be installed globally.
 
 Cheers
 
> 
> On Sat, 4 Jul 2020 16:04:45 +0200 Oneric  wrote:
>> Package: libbluray-bin
>> Version: 1:1.1.0-1
>> Severity: wishlist
>> 
>> Hi,
>> 
>> I think it might be worth including the `list_titles` and `bdsplice` 
>> utilities 
>> in libbluray-bin (curretnly only `bd_info`).
>> list_titles gives some more information about titles/playlists on the BD 
>> and 
>> bdsplice allows to extract single titles/playlists or just some chapters.
>> 
>> Just like `bd_info` the source of these utilities is already present in 
>> libbluray in src/examples and also already built – but not yet included 
>> in 
>> libbluray-bin.
>> 
>> Regards
>> Nils König
>> 
> 
> -- 
> Vasyl GelloCertified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
 
>>> 
>>> *Attachments:*
>>>  * signature.asc
>> 
>> --
>> Jean-Baptiste Kempf - President
>> +33 672 704 734
>> 
>> 
>> 
>
>--
>Jean-Baptiste Kempf - President
>+33 672 704 734
>


signature.asc
Description: PGP signature

Bug#964291: stretch-pu: package mariadb-10.1 10.1.45-0+deb9u1

[Otto Kekäläinen]

Hi!

su 5. heinäk. 2020 klo 14.24 Adam D. Barratt 
kirjoitti:

> On Sun, 2020-07-05 at 11:00 +0300, Otto Kekäläinen wrote:
> > For unstable the plan is to upload MariaDB 10.5 soon, and therefore
> > uploads of MariaDB 10.3 are already discontinued.
>
> How soon is "soon"?
>


Depends on how much i have Debian time, but getting 10.5 is my top priority
for Debian work. Maybe a month.

> Since we already
> > have MariaDB 10.4 in Debian experimental, it is not even possible to
> > do any uploads of MariaDB 10.3 because of triggering the NEW queue
> > and version conflicts/downgrades.
>
> I'm not sure I understand this comment.
>
> mariadb 10.3 is still in unstable and, as far as I can see, no other
> version of mariadb is. Therefore, uploading a new revision there should
> neither trigger NEW, nor any version issues.
>
> Yes, unstable and experimental share overrides, but that simply means
> that an upload of 10.4 to unstable wouldn't hit NEW, it doesn't imply
> anything about uploads of 10.3 in the meantime.
>

I was under the impression that the NEW queue was universal for
experimental->unstable->testing->stable, but indeed, I was able to upload
mariadb-10.3 to unstable this morning.

Bug#964345: RFS Fwd: Bug#964345: Acknowledgement (ITP: nanoplot -- plotting scripts for long read sequencing data)

[Andreas Tille]

Control: blocked -1 by 959381

Hi Steffen,

On Sun, Jul 05, 2020 at 10:39:01PM +0200, Steffen Möller wrote:
> This package of yours was waiting for an ITP but was otherwise mostly
> fine. Upstream had a new version in the meantime that eliminated the
> patch, but I then added another one  :o)
> 
> A missing runtime dependency (already on new) is nanoget. I think you
> should upload anyway since this is not a build dependency - there are no
> tests as it seems?

I did not yet uploaded myself since the package needs

https://github.com/plotly/orca

(see RFP #959381).
 
> Should we possibly add a line to the NEW-request wiki like "the packages
> below depend on a package above"?

May be that's a good idea since we have some packages accepted that need
other packages remaining in new.  But I'm scared about checking the
whole list ...

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#964365: diffoscope: comparing squashfs filesystems: Could not open foo.squashfs, because No such file or directory

[Chris Lamb]

forwarded 964365 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/189
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/189


Regards,

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

Bug#964367: blender: Doesn't show any text in UI

[Alex Hermann]

Package: blender
Version: 2.83.1+dfsg-2
Severity: important

Dear Maintainer,

I installed blender and upon first launch, the UI doesn't show any text.
No text in menus, toolbars and dialogs, nowhere.

This makes blender totally useless.

Upon launch, blender prints this to the console:

Can't find font: /home/alex/.config/blender/2.83/datafiles/fonts/droidsans.ttf
Can't find font: 
/home/alex/.config/blender/2.83/datafiles/fonts/bmonofont-i18n.ttf
Can't find font: 
/home/alex/.config/blender/2.83/datafiles/fonts/bmonofont-i18n.ttf
/run/user/1000/gvfs/ non-existent directory



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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages blender depends on:
ii  blender-data  2.83.1+dfsg-2
ii  fonts-dejavu  2.37-2
ii  libavcodec58  7:4.3-3
ii  libavdevice58 7:4.3-3
ii  libavformat58 7:4.3-3
ii  libavutil56   7:4.3-3
ii  libboost-locale1.71.0 1.71.0-6+b2
ii  libc6 2.30-8
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.2+dfsg-2
ii  libgcc-s1 10.1.0-4
ii  libgl11.3.1-1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10.1.0-4
ii  libilmbase24  2.3.0-6
ii  libjack0 [libjack-0.125]  1:0.125.0-3+b1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:2.0.5-1
ii  libopenal11:1.19.1-1+b1
ii  libopencolorio1v5 1.1.1~dfsg0-6+b1
ii  libopenexr24  2.3.0-6
ii  libopenimageio2.1 2.1.17.0~dfsg0-1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb7.0 7.0.0-3+b1
ii  libosdcpu3.4.33.4.3-3
ii  libosdgpu3.4.33.4.3-3
ii  libpcre3  2:8.39-13
ii  libpng16-16   1.6.37-2
ii  libpython3.8  3.8.4~rc1-1
ii  libsdl2-2.0-0 2.0.12+dfsg1-1
ii  libsndfile1   1.0.28-8
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610.1.0-4
ii  libswscale5   7:4.3-3
ii  libtbb2   2020.2-2
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.9-2+b1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxml2   2.9.10+dfsg-5+b1
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#964369: nmap: please make the obfuscated nmap_service.exe file reproducible

[Chris Lamb]

Source: nmap
Version: 7.80+dfsg1-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
the newly-obfuscated nmap_service.exe file was not being obfuscated
reproducibly and varied on the current build time.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2020-07-06 09:21:59.792062190 +0100
--- b/debian/rules  2020-07-06 09:22:23.796248703 +0100
@@ -31,7 +31,7 @@
cd nselib/data/jdwp-class && /usr/lib/jvm/default-java/bin/javac *.java
cd nselib/data/psexec && \
i686-w64-mingw32-gcc ${CPPFLAGS} ${CFLAGS} -o nmap_service.exe 
nmap_service.c && \
-   gzip -c -9 nmap_service.exe | base64 | tac > nmap_service.ex_
+   gzip -c -n9 nmap_service.exe | base64 | tac > nmap_service.ex_
 
 override_dh_auto_test:
dh_auto_test --sourcedir=ndiff --buildsystem=pybuild

Bug#763321: ITP kiwix

[Kunal Mehta]

owner 763321 !
retitle 763321 ITP: kiwix -- An offline Wikipedia reader
thanks

Now that libzim and libkiwix are up to date, I'm going to start
packaging the Kiwix desktop client.

I have a local build working, but there's one licensing issue that I'm
working with upstream on:
.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#925749: omit the problematic test to fix this bug

[zhao feng]

I have opened a merge request
https://salsa.debian.org/med-team/liblemon/-/merge_requests/3
to fix this bug.

I think it is acceptable to omit the lgf_reader_writer_test. This test
deals with IO part of the library. and it had minor influence on the
whole.

This merge request can be successfully run:
https://salsa.debian.org/zhaofeng-shu33-guest/liblemon/-/jobs/849082

Bug#962275: snort: Failed to start LSB

[Javier Fernandez-Sanguino]

Dear Thorsten,

Indeed I have found two issues in the Snort package related to this bug
report:

1.- The location of the libraries in /etc/snort.conf is not correct for
different architectures. I need to find a way to ammend this value when the
package gets compiled (or find a way to locate this libraries in a common
place for all architectures)
2.- There are some symbols missing in
/usr/lib/x86_64-linux-gnu/libsfbpf.so.0

I have not yet found a way to fix either 1 or 2, and will continue
investigating.

Best regards

Javier

Bug#964370: dino-im-common: dino-im_0.1.0-5~bpo10+1 removes dino-im on upgrade

[Bernhard Reiter]

Package: dino-im-common
Version: 0.1.0-5~bpo10+1
Severity: important

Dear Martin,

today the system upgrade on Buster with a backported dino-im
brought me dino-im_0.1.0-5~bpo10+1 which removed dino-im
completely. So something is wrong.

LANG=C apt-get install dino-im/buster-backports
Selected version '0.1.0-5~bpo10+1' (Debian Backports:buster-backports [amd64]) 
for 'dino-im'
[..]
The following packages have unmet dependencies:
 dino-im : Depends: dino-im-common (= 0.1.0-5~bpo10+1) but it is not going to 
be installed
E: Unable to correct problems, you have held broken packages.

dpkg -l dino-im-common | tail -1
ii  dino-im-common 0.1.0-5~bpo10+1 all  modern XMPP client - common 
files

Regards,
Bernhard

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

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

-- no debconf information

Bug#964371: dh-r: generate wrong dependencies for source package with multiple binary packages

[Dylan Aïssi]

Package: dh-r

We have more and more source packages generating more than a unique R
binary package (i.e. they also generate python, library, ...) like
isospec, rosa and r-bioc-mofa.

Currently, dh-r assigns substvars to the first binary package from
d/control. If this package is not the R package but a python or
whatever, then dependencies of the generated R binary package will be
wrong (empty).

dh-r should assign substvars to the first **R** binary package in d/control.

See: https://lists.debian.org/debian-med/2020/07/msg00045.html

Bug#964372: FTBFS: qemu-5.0 needs --enable-tools config option on hppa (softmmu)

[Helge Deller]

Package: qemu
Version: 5.0-6
Severity: normal
Tags: ftbfs patch

qemu-5.0 fails to build from source, because when the debian package is 
packaged,
some executables were not built. Here is an example:

dh_install: warning: Cannot find (any matches for) 
"debian/tmp/usr/bin/qemu-img" (tried in ., debian/tmp)
dh_install: warning: Cannot find (any matches for) 
"debian/tmp/usr/bin/qemu-nbd" (tried in ., debian/tmp)
dh_install: warning: Cannot find (any matches for) "debian/tmp/usr/bin/qemu-ga" 
(tried in ., debian/tmp)
...

Adding "--enable-tools" to the hppa specific configure line
enables building of the tools on hppa:

+++ ./debian/rules  2020-07-06 08:24:40.642426829 +
@@ -65,7 +65,7 @@ endif
 ifeq ($(DEB_TARGET_ARCH), hppa)
 # allow configure to run on unsupported arches to build qemu-utils and the like
-common_configure_opts += --enable-tcg-interpreter
+common_configure_opts += --enable-tcg-interpreter --enable-tools


Sucessfully build-tested on a hppa machine.
Patch is attached.
Please appy before next upload.

THANKS!
Helge
diff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org	2020-07-06 08:34:58.870813670 +
+++ ./debian/rules	2020-07-06 08:24:40.642426829 +
@@ -65,7 +65,7 @@ endif

 ifeq ($(DEB_TARGET_ARCH), hppa)
 # allow configure to run on unsupported arches to build qemu-utils and the like
-common_configure_opts += --enable-tcg-interpreter
+common_configure_opts += --enable-tcg-interpreter --enable-tools
 endif

 ifeq (${enable_system},enable)

Bug#641812: Packaging qtsingleapplication?

[Kunal Mehta]

Hi Qt maintainers,

I'm currently packaging kiwix (#763321) and came across
qtsingleapplication. It has had an open RFP (#641812) since 2011.

Currently upstream kiwix bundles a copy of qtsingleapplication in its
Git repo/tarballs, as there is no packaged version.

However, the Fedora kiwix packager has asked
() for
qtsingleapplication to be unbundled as they have it packaged.

I noticed via codesearch that there are other packages that also bundle
qtsingleapplication:
.

Is this something current Qt maintainers would be interested in
providing a package for? Or should I recommend to upstream to continue
bundling it?

Thanks,
-- Kunal

(please cc, not subscribed)



signature.asc
Description: OpenPGP digital signature

Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)

[Ansgar]

Andrei POPESCU writes:
> On Mi, 10 iul 19, 13:16:27, Ansgar Burchardt wrote:
>> People should probably use something like
>>
>>   deb http://security.debian.org/debian-security bullseye-security main
>>
>> (adding /debian-security was proposed in [1]).
>
> Could this be /debian instead, to be consistent with the other suites?

I think that would be a bad idea as they are different archives.
/debian and /debian-security contain different things, giving them the
same name would be confusing.  Also deb.d.o needs different names.

Ansgar

Bug#964372: (FTBFS: qemu-5.0 needs --enable-tools config option on hppa (softmmu))

[Helge Deller]

According to the build logs:
https://buildd.debian.org/status/package.php?p=qemu&suite=sid
qemu-5.0 fails on ia64, m68k, sh4 and sparc (and maybe alpha) similar as
hppa did in the past.

Maybe by applying the same config options (--enable-tcg-interpreter 
--enable-tools)
to those architectures as it's done for hppa here would fix them?

+++ ./debian/rules  2020-07-06 08:24:40.642426829 +
@@ -65,7 +65,7 @@ endif
 ifeq ($(DEB_TARGET_ARCH), hppa) # ADD ia64, m68k, sh4 and sparc (and maybe 
alpha) HERE?
 # allow configure to run on unsupported arches to build qemu-utils and the like
-common_configure_opts += --enable-tcg-interpreter
+common_configure_opts += --enable-tcg-interpreter --enable-tools

Bug#964242: bsdmainutils: depends on non-existing version of bsdextrautils

[Markus Koschany]

affects 964242 javahelper
thanks

This also affects javahelper which depends on bsdmainutils and breaks a
lot of Java packages in Debian currently.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#962553: gffread: autopkgtest needs update for new version of gff2aplot: warning on stderr

[Adrian Bunk]

Control: reopen -1

On Mon, Jul 06, 2020 at 01:07:22AM +0200, Graham Inggs wrote:
> Hi Adrian
> 
> On Sun, 5 Jul 2020 at 19:02, Adrian Bunk  wrote:
> > This is #962550.
> 
> Are you sure?
> 
> The failing test was with ligclib1 0.11.8-1 from testing and gff2aplot
> 2.0-13 from unstable.

Right you are, thanks for noticing my mistake.

The actual problem is:
Due to the dh compat bump in gff2aplot the gffread autopkgtest runs
additional tests, and on two of these gffread is segfaulting.

> Regards
> Graham

cu
Adrian

Bug#964372: (FTBFS: qemu-5.0 needs --enable-tools config option on hppa (softmmu))

[John Paul Adrian Glaubitz]

On 7/6/20 10:54 AM, Helge Deller wrote:
> According to the build logs:
> https://buildd.debian.org/status/package.php?p=qemu&suite=sid
> qemu-5.0 fails on ia64, m68k, sh4 and sparc (and maybe alpha) similar as
> hppa did in the past.

FWIW, sparc64 is still officially supported by upstream as a host architecture
as they have access to SPARC machines for development and testing.

Adrian

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

Bug#964373: libf2c2-dev: mark libf2c2-dev Multi-Arch: foreign

[Helmut Grohne]

Package: libf2c2-dev
Version: 20130926-3
Tags: patch

libf2c2-dev is not presently coinstallable with itself on multiple
architectures. Doing so is useful for developping applications on
multiple architectures at the same time. It is not required for cross
building packages. As it happens, the multiarch hinter already says that
coinstallation would be safe, all we have to do here is add the
"Multi-Arch: same" tag to libf2c2-dev. Please consider applying the
attached patch.

Helmut
diff -Nru libf2c2-20130926/debian/changelog libf2c2-20130926/debian/changelog
--- libf2c2-20130926/debian/changelog   2018-02-22 13:36:24.0 +0100
+++ libf2c2-20130926/debian/changelog   2020-07-06 11:05:03.0 +0200
@@ -1,3 +1,10 @@
+libf2c2 (20130926-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Also mark libf2c2-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 06 Jul 2020 11:05:03 +0200
+
 libf2c2 (20130926-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru libf2c2-20130926/debian/control libf2c2-20130926/debian/control
--- libf2c2-20130926/debian/control 2018-02-22 13:36:24.0 +0100
+++ libf2c2-20130926/debian/control 2020-07-06 11:05:01.0 +0200
@@ -24,6 +24,7 @@
 
 Package: libf2c2-dev
 Architecture: any
+Multi-Arch: same
 Section: libdevel
 Depends: libf2c2 (= ${binary:Version}),
  libc6-dev,

Bug#959150: [Pkg-clamav-devel] Bug#959150: Add support for Prelude

[Thomas Andrejak]

Hello

How can I help you to go forward on this ?

Enabling prelude support should be easy

Regards

Thomas

Le jeu. 30 avr. 2020 à 09:09, Thomas Andrejak  a
écrit :

> Hello
>
> Thanks for your reply.
>
> The performance you pointed out is about the database inserts, not the
> libprelude used by ClamAV. So, for an security tool, there is no
> performance issue. For a Prelude end user, if he gets too many alerts per
> seconds, there are mechanisms to filter this and do not fall into
> performance issues.
>
> For your information, Suricata already enable prelude support in it's
> packages and there is no issue.
>
> Regards
>
> On Wed, 29 Apr 2020 23:31:34 + Scott Kitterman 
> wrote:
> > According to the prelude web site:
> >
> > Prelude OSS is the open source edition of Prelude SIEM . Prelude OSS is
> aimed for evaluation, research and test purpose on very small environments.
> Please note that Prelude OSS performances are way lower than the Prelude
> SIEM edition.
>
> >
> > What testing have you done to determine the performance implications of
> the proposed change?
> >
> > Scott K
> >
> > On April 29, 2020 11:15:43 PM UTC, Thomas Andrejak <
> thomas.andre...@gmail.com> wrote:
> > >Package: clamav
> > >
> > >Version: 0.102.2
> > >
> > >Please enable Prelude support:
> > >
> > >* d/control: Add libprelude-dev Build-Depends
> > >
> > >* d/rule: Add --enable-prelude to the ./configure
> > >
> > >Thanks
> > >
> > >Regards
> > >
> > >Thomas
> >
> >
>

Bug#964139: network-manager: Please restore removed init script.

[Dimitris]

same here,
i don't think this is "wishlist". "grave" severity is more accurate.
please consider @ll debian users, when making such changes.

regards,
d.



signature.asc
Description: OpenPGP digital signature

Bug#964374: libf2c2 FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: libf2c2
Version: 20130926-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libf2c2 fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build - is
insufficient here. debian/make_lib hard codes the build architecture C
compiler and makefile.u hard codes the build architecture ld. Both need
to be made substitutable. Since dh_auto_build does not pass an LD
variable, we must pass it explicitly. The attached patch makes libf2c2
cross buildable. Please consider applying it.

Helmut
diff -Nru libf2c2-20130926/debian/changelog libf2c2-20130926/debian/changelog
--- libf2c2-20130926/debian/changelog   2018-02-22 13:36:24.0 +0100
+++ libf2c2-20130926/debian/changelog   2020-07-06 11:12:17.0 +0200
@@ -1,3 +1,14 @@
+libf2c2 (20130926-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make debian/make_lib use the passed cross compiler.
++ Pass a cross ld from dpkg's buildtools.mk to make.
++ cross.patch: Make ld substitutable in makefile.u.
+
+ -- Helmut Grohne   Mon, 06 Jul 2020 11:12:17 +0200
+
 libf2c2 (20130926-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru libf2c2-20130926/debian/make_lib libf2c2-20130926/debian/make_lib
--- libf2c2-20130926/debian/make_lib2018-02-22 13:36:24.0 +0100
+++ libf2c2-20130926/debian/make_lib2020-07-06 11:12:17.0 +0200
@@ -4,7 +4,7 @@
$(MAKE) -f makefile.u CFLAGS="$(CFLAGS) $(GCCOPT) -fPIC \
 -I ../ -DNON_UNIX_STDIO -D$(INTSIZE)" 
 
-   gcc -shared -Wl,-soname,lib$(INTSIZE).so.2 $(LDFLAGS) \
+   $(CC) -shared -Wl,-soname,lib$(INTSIZE).so.2 $(LDFLAGS) \
 -o lib$(INTSIZE).so.2.1 *.o -lc -lm
 
ar r lib$(INTSIZE).a *.o
diff -Nru libf2c2-20130926/debian/patches/cross.patch 
libf2c2-20130926/debian/patches/cross.patch
--- libf2c2-20130926/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ libf2c2-20130926/debian/patches/cross.patch 2020-07-06 11:12:17.0 
+0200
@@ -0,0 +1,20 @@
+Index: libf2c2-20130926/makefile.u
+===
+--- libf2c2-20130926.orig/makefile.u
 libf2c2-20130926/makefile.u
+@@ -14,13 +14,14 @@
+ 
+ .SUFFIXES: .c .o
+ CC = cc
++LD ?= ld
+ SHELL = /bin/sh
+ CFLAGS = -O
+ 
+ # compile, then strip unnecessary symbols
+ .c.o:
+   $(CC) -c -DSkip_f2c_Undefs $(CFLAGS) $*.c
+-  ld -r -x -o $*.xxx $*.o
++  $(LD) -r -x -o $*.xxx $*.o
+   mv $*.xxx $*.o
+ ## Under Solaris (and other systems that do not understand ld -x),
+ ## omit -x in the ld line above.
diff -Nru libf2c2-20130926/debian/patches/series 
libf2c2-20130926/debian/patches/series
--- libf2c2-20130926/debian/patches/series  2018-02-22 13:36:24.0 
+0100
+++ libf2c2-20130926/debian/patches/series  2020-07-06 11:12:17.0 
+0200
@@ -4,3 +4,4 @@
 0004-add-clapack-files.patch
 0005-format-security.patch
 0006-weak-MAIN__.patch
+cross.patch
diff -Nru libf2c2-20130926/debian/rules libf2c2-20130926/debian/rules
--- libf2c2-20130926/debian/rules   2018-02-22 13:36:24.0 +0100
+++ libf2c2-20130926/debian/rules   2020-07-06 11:12:17.0 +0200
@@ -11,7 +11,9 @@
 # prefix-dev=debian/libf2c2-dev
 # prefix=debian/libf2c2
 
-DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+LD ?= ld
 
 dir=$(package)-$(version)
 file=$(package)_$(version)-$(debian)
@@ -30,16 +32,18 @@
GCCOPT=$(GCCOP1)
 endif
 
+MAKE_LIB=dh_auto_build --buildsystem=makefile -- -f ./debian/make_lib 
'LD=$(LD)'
+
 override_dh_auto_build:
if [ $(DEB_HOST_ARCH) = "i386" ] ;\
then echo "Building for i386" ;\
 fi
 
 ## These take gcc options from GCCOPT 
-   $(MAKE) -f ./debian/make_lib INTSIZE=f2c GCCOPT="$(GCCOPT)"
+   $(MAKE_LIB) INTSIZE=f2c GCCOPT="$(GCCOPT)"
 ## Make sure everything rebuilt for -I2 lib
-   $(MAKE) -f ./debian/make_lib clean
-   $(MAKE) -f ./debian/make_lib INTSIZE=f2c_i2 GCCOPT="$(GCCOPT)"
+   $(MAKE_LIB) clean
+   $(MAKE_LIB) INTSIZE=f2c_i2 GCCOPT="$(GCCOPT)"
 
ln -s libf2c.so.$(flibver) libf2c.so.$(flibmajorver)
ln -s libf2c_i2.so.$(flibver) libf2c_i2.so.$(flibmajorver)

Bug#962653: [DAViCal-devel] Bug#962653: davical: diff for NMU version 1.1.9.3-1.1

[Adrian Bunk]

On Mon, Jul 06, 2020 at 08:34:12AM +0200, Florian Schlichting wrote:
> On Sun, Jul 05, 2020 at 12:46:52PM +0300, Adrian Bunk wrote:
> > I've prepared an NMU for davical (versioned as 1.1.9.3-1.1) and uploaded 
> > it to DELAYED/3. Please feel free to tell me if I should cancel it.
> 
> ACK
> 
> I've been waiting for the pdfrw maintainer to say something about the
> expected future of his package, but I guess no answer is also an answer,
> and rst2pdf has no bearing at all on the functioning of davical. So
> thanks for going ahead with this.

Thanks, rescheduled for immediate upload.

> Florian

cu
Adrian

Bug#964375: RM: slice -- NVIU, RoM: Superseeded by slice binary package built from wml source package

[Axel Beckert]

Package: ftp.debian.org
Severity: normal

Hi,

yesterday I uploaded wml 2.28.0~ds1-1 which also builds the slice
binary package.

WML upstream continued slice upstream developement and entangled it
closer with WML: wml is now only using its library calls — which are
not usable outside slice in the old standalone version of slice from
the (technically dead) original upstream.

Hence the slice source package (version 1.3.8-14) and the binary
package built from it (and only it, not the one built from the wml
source package) should be removed from unstable.

(Not sure if this should better wait until the new wml and hence slice
version reached testing.)

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

Bug#957297: should be fixed by 2.8 release

[Aliaksey Kandratsenka]

hi. I just tagged 2.8 that has a couple fixes for test failures in gcc 10.
So should be fixed now.

Bug#964318: gosa login broken with PHP 7.4

[Wolfgang Schweer]

On Sun, Jul 05, 2020 at 10:34:43PM +, Holger Levsen wrote:
> this pretty much sounds like a 'serious' bug ( = unsuitable for a stable 
> release as per https://www.debian.org/Bugs/Developer#severities and not
> just important ("major impact,  without rendering it completely unusable
> to everyone") or less, though I will follow Wolfgang's example and opt 
> for the lesser severity. (maybe it still works with new accounts?)

It doesn't. Also, setting up LDAP from scratch fails as well, i.e. 
installation of a new Debian Edu main server is broken.

Error message:

info: Creating first user  'jdoe'.
To initialize a brand new LDAP+KDC: 
rm /var/lib/ldap/__db* /var/lib/ldap/*.bdb
rm /etc/krb5kdc/stash /etc/krb5.keytab*
LDAP passwords cleared from debconf database.
The provided LDAP password is valid.

PHP Fatal error:  Uncaught Error: Length must be greater than 0 in 
/usr/sbin/gosa-encrypt-passwords:7
Stack trace:
#0 /usr/sbin/gosa-encrypt-passwords(7): openssl_random_pseudo_bytes()
#1 /usr/sbin/gosa-encrypt-passwords(74): cred_encrypt()
#2 {main}
  thrown in /usr/sbin/gosa-encrypt-passwords on line 7

Related code in /usr/sbin/gosa-encrypt-passwords causing the error:

function cred_encrypt($input, $password, $cipher = "aes-256-ecb") {
  if (in_array($cipher, openssl_get_cipher_methods())) {
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes($ivlen);
return bin2hex(openssl_encrypt($input, $cipher, $password, 
OPENSSL_RAW_DATA, $iv));
  }

  return null;
}

Similar GOSa² web interface related code in /usr/share/gosa/functions.inc:

function cred_encrypt($input, $password, $cipher = "aes-256-ecb") {
  if (in_array($cipher, openssl_get_cipher_methods())) {
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes($ivlen);
return bin2hex(openssl_encrypt($input, $cipher, $password, 
OPENSSL_RAW_DATA, $iv));
  }

  return null;
}

function cred_decrypt($input, $password, $cipher = "aes-256-ecb") {
  if (in_array($cipher, openssl_get_cipher_methods())) {
$ivlen = openssl_cipher_iv_length($cipher);
$iv = openssl_random_pseudo_bytes(64);
return rtrim(openssl_decrypt(pack("H*", $input), $cipher, $password, 
OPENSSL_RAW_DATA, $iv ), "\0\3\4\n");
  }

  return null;
}

In both encrypt and decrypt cases, the chosen cipher method seems to return 0.
 
The severity is rather 'grave', I figure.

@Mike: Also, src:fusiondirectory might be affected.
 
Wolfgang


signature.asc
Description: PGP signature

Bug#959579: adapta-gtk-theme: FTBFS: make[2]: *** [Makefile:1040: all] Error 1

[Samuel Henrique]

Hello Sudip,

Just a quick update, I spoke to Franciscarlos (he will reply back here
soon) and he intends to keep the package, so your patch will be
accepted, he just wants to confirm that the package is working fine
with the latest version of gnome.

Meanwhile, can you push your changes to the git repo?

Thanks,

-- 
Samuel Henrique 

Bug#891008: grml-debootstrap: cannot setup stretch images

[Holger Levsen]

control: retitle -1 'grml-debootstrap: provide predictable network device names'
control: severity -1 wishlist

On Wed, Feb 21, 2018 at 02:58:18PM +0100, Holger Levsen wrote:
> i'm trying to setup stretch images, and while the same commandline works
> for jessie, it fails with stretch like this:
[...]
> cat > /etc/network/interfaces <<- FOE
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> auto eth0
> iface eth0 inet static
> address $2
> netmask $NETMASK
> gateway $GATEWAY
>   $POINTOPOINT
> FOE

long story short, this ^ is the cause for what I have seen, using stretch
and buster the network interface is 'ens3' and not 'eth0', thus the network
didnt come up as it should...

Now that I know this, I'm using 'ens3' for these systems but I'd rather like
grml-debootstrap to (optionally) append 'net.ifnames=0' to the kernel
commandline, thus forcing the interface name to be 'eth0'. I've changed the
bug meta-data accordingly.

Thank you for maintaining grml-debootstrap!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#941587: New upstream version available

[xiscu]

Package: jami
Version: Please update the sid package to the latest upstream version
Followup-For: Bug #941587

Dear Maintainer,
the current upstream jami version to date seems to be (2020.07.06):
https://www.virustotal.com/gui/file/987c1e0480e2d1765b71004b5c1f24f5c9b8ee8533ef75b050907b1f39ff8790/details

Thanks in advance!
xiscu



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

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

Versions of packages jami depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
pn  jami-daemon  
ii  libayatana-appindicator3-1   0.5.4-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libclutter-1.0-0 1.26.4+dfsg-1
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libgcc-s1 [libgcc1]  10.1.0-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.3-2
ii  libgtk-3-0   3.24.20-1
ii  libnm0   1.24.2-1
ii  libnotify4   0.7.9-1
ii  libpango-1.0-0   1.44.7-4
pn  libqrencode4 
ii  libqt5core5a 5.14.2+dfsg-4
ii  libqt5dbus5  5.14.2+dfsg-4
ii  libqt5gui5   5.14.2+dfsg-4
ii  libqt5sql5   5.14.2+dfsg-4
pn  libqt5sql5-sqlite
ii  libstdc++6   10.1.0-4
ii  libwebkit2gtk-4.0-37 2.28.2-2+b1
ii  libx11-6 2:1.6.9-2+b1

jami recommends no packages.

jami suggests no packages.

Bug#964376: tracker: New upstream prerelease 2.99.2

[Simon McVittie]

Source: tracker
Severity: wishlist

Tracker 3 is a new major version of Tracker, "currently planned to
release as part of GNOME 3.38" according to upstream. GTK 4 has it as an
optional dependency.

If you would like Tracker search support in the GTK 4 file chooser,
please package this in experimental or as a new tracker3 source package.

Thanks,
smcv

Bug#959579: adapta-gtk-theme: FTBFS: make[2]: *** [Makefile:1040: all] Error 1

[Sudip Mukherjee]

On Mon, Jul 6, 2020 at 11:19 AM Samuel Henrique  wrote:
>
> Hello Sudip,
>
> Just a quick update, I spoke to Franciscarlos (he will reply back here
> soon) and he intends to keep the package, so your patch will be
> accepted, he just wants to confirm that the package is working fine
> with the latest version of gnome.

thats great.

>
> Meanwhile, can you push your changes to the git repo?

Sure, I have raised a merge request after changing the release to
"UNRELEASED", so that you can accept it after Franciscarlos has tested
it.
Kept it UNRELEASED as I assumed you might want to update the
Standards-Version and debhelper also (which I should not do as part of
NMU).


-- 
Regards
Sudip

Bug#964377: bumblebee: please runtime depend on pciutils

[Gianfranco Costamagna]

Source: bumblebee
Version: 3.2.1-23
Severity: serious

Hello, bumblebee and bumblebee-nvidia (in Ubuntu) use lspci in their postinst 
files, without
a dependency on it

./debian/bumblebee.postinst:busid=$(lspci -d10de: -nn | grep 
'\[030[02]\]' | cut -d' ' -f1 | tr . : | head -1)
./debian/bumblebee-nvidia.postinst.Ubuntu:  busid=$(lspci -d10de: -nn | 
grep '\[030[02]\]' | cut -d' ' -f1 | tr . : | head -1)

I think depending on pciutils might be a sane thing to do!
(I think the severity is RC, but feel free to downgrade, I don't know what is 
the severity for this bug)

cheers,

Gianfranco

Bug#964378: libpod: Please upgrade to new upstream version 2.0

[Reinhard Tartler]

Source: libpod
Severity: wishlist

Podman 2.0 is going to be supported in RHEL 8.3 long term and is thus a
great candidate for inclusion into Debian bullseye. Let's try to get it 
packaged for debian.

I've looked at https://github.com/containers/libpod/blob/v2.0/go.mod to
understand what packages in Debian needs work for this new upstream.

These packages needs packaging.  In some cases, it might make sense to
keep the package vendored in the libpod source package. I would suggest
to prioritize working on these packages:

  github.com/hpcloud/tail v1.0.0 (NOT PACKAGED?)
  github.com/gorilla/schema v1.1.0 (NOT PACKAGED?)
  github.com/containers/common v0.14.3 (stuck in NEW)

  github.com/cri-o/ocicni v0.2.0 (NOT PACKAGED?)
  github.com/opencontainers/runtime-spec 
v1.0.3-0.20200520003142-237cc4f519e2 (NOT PACKAGED?)
  github.com/uber/jaeger-client-go v2.24.0+incompatible (NOT PACKAGED)
  github.com/uber/jaeger-lib v2.2.0+incompatible // indirect (NOT 
PACKAGED)


These are dependencies that we have in debian but in an older
version. This may or may not be required for podman 2.0, but updating
them might be a good idea anyways:

  github.com/containers/image/v5 v5.5.1 (have: 5.0.0)
  github.com/containers/storage v1.20.2 (have: 1.15)
  github.com/containers/buildah v1.15.0 (have 1.11.6)

  github.com/containernetworking/cni 
v0.7.2-0.20200304161608-4fae32b84921 (have 0.7.1)
  github.com/containers/conmon v2.0.18+incompatible (have 2.0.9)
  github.com/containers/psgo v1.5.1 (have 1.4.0)
  github.com/coreos/go-systemd/v22 v22.1.0 (have 22.0)
  github.com/google/shlex v0.0.0-20181106134648-c34317bd91bf (have 
0.0~git20150127)
  github.com/gorilla/mux v1.7.4 (have 1.7.3)
  github.com/onsi/ginkgo v1.13.0 (have 1.12.0)
  github.com/onsi/gomega v1.10.1 (have 1.9.0)
  github.com/opencontainers/image-spec 
v1.0.2-0.20190823105129-775207bd45b6 (have 1.0.1)

  github.com/opencontainers/selinux v1.5.2 (have 1.3.1)
  github.com/openshift/imagebuilder v1.1.6 // indirect (have 1.1.4)
  github.com/opentracing/opentracing-go v1.1.0 (have 1.0.2)
  github.com/seccomp/containers-golang v0.5.0 (have 0.3.2)
  github.com/sirupsen/logrus v1.6.0 (have 1.3.0)
  github.com/spf13/cobra v0.0.7 (have 0.0.5)
  github.com/stretchr/testify v1.6.1 (have 1.4.0)
  go.etcd.io/bbolt v1.3.5 (have 1.3.3)
  gopkg.in/yaml.v2 v2.3.0 (have 2.2.2)

These packages are already uptodate, no further action needed:

  github.com/cyphar/filepath-securejoin v0.2.2 (have 0.2.2)
  github.com/davecgh/go-spew v1.1.1 (have 1.1.1)
  github.com/docker/distribution v2.7.1+incompatible (have 2.7.1)
  github.com/docker/go-connections v0.4.0 (have 0.4.0)
  github.com/docker/go-units v0.4.0 (have 0.4.0)
  github.com/fsnotify/fsnotify v1.4.9 (have 1.4.9)
  github.com/ghodss/yaml v1.0.0 (have 1.0.0)
  github.com/godbus/dbus/v5 v5.0.3 (have: 5.0.3)
  github.com/google/uuid v1.1.1 (have 1.1.1)
  github.com/hashicorp/go-multierror v1.0.0 (have: 1.0.0)
  github.com/json-iterator/go v1.1.10 (have 1.1.10)
  github.com/mrunalp/fileutils v0.0.0-20171103030105-7d4729fb3618 (have 
0.0~git20200504)
  github.com/opencontainers/go-digest v1.0.0 (have 1.0.0)
  github.com/opencontainers/runtime-tools v0.9.0 (have 0.9.0)
  github.com/pkg/errors v0.9.1 (have 0.9.1)
  github.com/pmezard/go-difflib v1.0.0 (have 1.0.0)
  github.com/rootless-containers/rootlesskit v0.9.5 (have 0.9.5)
  github.com/spf13/pflag v1.0.5 (have 1.0.5)
  github.com/syndtr/gocapability v0.0.0-20180916011248-d98352740cb2 
(have 0.0+git20180916)
  github.com/varlink/go v0.0.0-20190502142041-0f1d566d194b (have 0.3.0)
  github.com/vishvananda/netlink v1.1.0 (have 1.1.0)


These packages may need special handling, I'm not sure in what other
category these fall into. Dmitry, golang team, can you please share your
opinion how we should proceed with these:

  github.com/opencontainers/runc v1.0.0-rc90 (have: 0.0~git20190911)
  github.com/docker/docker v1.4.2-0.20191219165747-a9416c67da9f (have 
19.03)

  golang.org/x/crypto v0.0.0-20200423211502-4bdfaf469ed5
  golang.org/x/net v0.0.0-20200520004742-59133d7f0dd7
  golang.org/x/sync v0.0.0-20200317015054-43a5402ce75a
  golang.org/x/sys v0.0.0-20200519105757-fe76b779f299

  k8s.io/api v0.18.4
  k8s.io/apimachinery v0.18.4
  k8s.io/client-go v0.0.0-20190620085101-78d2af792bab


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAIN

Bug#960577: python-sievelib: diff for NMU version 1.1.1-3.2

[Adrian Bunk]

Control: tags 960577 + patch
Control: tags 960577 + pending

Dear maintainer,

I've prepared an NMU for python-sievelib (versioned as 1.1.1-3.2) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru python-sievelib-1.1.1/debian/changelog python-sievelib-1.1.1/debian/changelog
--- python-sievelib-1.1.1/debian/changelog	2020-03-07 20:52:38.0 +0200
+++ python-sievelib-1.1.1/debian/changelog	2020-07-06 14:47:15.0 +0300
@@ -1,3 +1,10 @@
+python-sievelib (1.1.1-3.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Backport upstream build fixes. (Closes: #960577)
+
+ -- Adrian Bunk   Mon, 06 Jul 2020 14:47:15 +0300
+
 python-sievelib (1.1.1-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-sievelib-1.1.1/debian/patches/0001-Fix-import-of-req-module-from-pip-10.patch python-sievelib-1.1.1/debian/patches/0001-Fix-import-of-req-module-from-pip-10.patch
--- python-sievelib-1.1.1/debian/patches/0001-Fix-import-of-req-module-from-pip-10.patch	2020-03-07 20:52:38.0 +0200
+++ python-sievelib-1.1.1/debian/patches/0001-Fix-import-of-req-module-from-pip-10.patch	2020-07-06 14:44:06.0 +0300
@@ -1,28 +1,33 @@
-From: Michael Fladischer 
-Date: Thu, 7 Feb 2019 10:47:07 +0100
-Subject: Fix import of req module from pip (>= 10).
+From 1deef0e2bf039a0e817ea6f19aaf1947dc9fafbc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Fernando=20Tricas=20Garc=C3=ADa?=
+ 
+Date: Fri, 31 Aug 2018 17:11:58 +0200
+Subject: Problems with pip >=10 and pip.req (#72)
 
+Hello,
+
+it seems that pip 10 does not allow the use of pip.req (https://stackoverflow.com/questions/25192794/no-module-named-pip-req).
+I've tested with this workaround and it seems to work well.
 ---
- setup.py | 7 ++-
- 1 file changed, 6 insertions(+), 1 deletion(-)
+ setup.py | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/setup.py b/setup.py
-index 0d28fed..4fb9794 100644
+index 0d28fed..784608d 100644
 --- a/setup.py
 +++ b/setup.py
-@@ -12,9 +12,14 @@ from __future__ import unicode_literals
+@@ -12,7 +12,10 @@ from __future__ import unicode_literals
  
  import io
  from os import path
 -from pip.req import parse_requirements
- from setuptools import setup, find_packages
- 
-+# From https://stackoverflow.com/a/49867265
-+try: # for pip >= 10
++try: # for pip >= 10 (From: https://stackoverflow.com/questions/25192794/no-module-named-pip-req)
 +from pip._internal.req import parse_requirements
 +except ImportError: # for pip <= 9.0.3
 +from pip.req import parse_requirements
-+
+ from setuptools import setup, find_packages
+ 
  
- def get_requirements(requirements_file):
- """Use pip to parse requirements file."""
+-- 
+2.20.1
+
diff -Nru python-sievelib-1.1.1/debian/patches/0001-Put-the-list-of-requirements-in-setup.py.patch python-sievelib-1.1.1/debian/patches/0001-Put-the-list-of-requirements-in-setup.py.patch
--- python-sievelib-1.1.1/debian/patches/0001-Put-the-list-of-requirements-in-setup.py.patch	1970-01-01 02:00:00.0 +0200
+++ python-sievelib-1.1.1/debian/patches/0001-Put-the-list-of-requirements-in-setup.py.patch	2020-07-06 14:42:50.0 +0300
@@ -0,0 +1,63 @@
+From 91f40ec226ea288e98379da01672a46dabd89fc9 Mon Sep 17 00:00:00 2001
+From: Petr Viktorin 
+Date: Fri, 12 Oct 2018 14:32:18 +0200
+Subject: Put the list of requirements in setup.py
+
+Pip's internal API is unstable and might actually change more often
+than the list of requirements.
+
+Put the requirements in setup.py, and refer there from requirements.txt
+---
+ requirements.txt |  5 +++--
+ setup.py | 19 +--
+ 2 files changed, 4 insertions(+), 20 deletions(-)
+
+diff --git a/requirements.txt b/requirements.txt
+index dd68eb2..a10e857 100644
+--- a/requirements.txt
 b/requirements.txt
+@@ -1,2 +1,3 @@
+-future
+-six
++# Requirements are listed in setup.py. The dot on the next line refers to
++# the current directory, instructing installers to use this package's setup.py
++.
+diff --git a/setup.py b/setup.py
+index 784608d..e266fcb 100644
+--- a/setup.py
 b/setup.py
+@@ -12,30 +12,13 @@ from __future__ import unicode_literals
+ 
+ import io
+ from os import path
+-try: # for pip >= 10 (From: https://stackoverflow.com/questions/25192794/no-module-named-pip-req)
+-from pip._internal.req import parse_requirements
+-except ImportError: # for pip <= 9.0.3
+-from pip.req import parse_requirements
+ from setuptools import setup, find_packages
+ 
+ 
+-def get_requirements(requirements_file):
+-"""Use pip to parse requirements file."""
+-requirements = []
+-if path.isfile(requirements_file):
+-for req in parse_requirements(requirements_file, session="hack"):
+-# check markers, such as
+-#
+-# rope_py3k; python_version >= '3.0'
+-#
+-if req.match_markers():
+-requirements.append(str(req.req))
+-return requirement

Bug#964370: dino-im-common: dino-im_0.1.0-5~bpo10+1 removes dino-im on upgrade

[Martin]

Quoting Bernhard Reiter :

today the system upgrade on Buster with a backported dino-im
brought me dino-im_0.1.0-5~bpo10+1 which removed dino-im
completely. So something is wrong.


Yes, I forgot trailings tildes at three places in the control file.
Thanks for noticing! I'll fix that ASAP.

Bug#964368: deepin-icon-theme: gtk-update-icon-cache: The generated cache was invalid.

[Laurent Bonnaud]

Package: deepin-icon-theme
Version: 2020.06.30-1
Severity: normal


Dear Maintainer,

here is the problem:

# apt install deepin-icon-theme
[...]
Unpacking deepin-icon-theme (2020.06.30-1) ...
Setting up deepin-icon-theme (2020.06.30-1) ...
gtk-update-icon-cache: The generated cache was invalid.
WARNING: icon cache generation failed for /usr/share/icons/bloom-classic


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

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

Versions of packages deepin-icon-theme depends on:
ii  papirus-icon-theme  20200702-1

deepin-icon-theme recommends no packages.

deepin-icon-theme suggests no packages.

-- no debconf information

-- 
Laurent.

Bug#964379: xonix: incorrect name in .desktop file

[Martin]

Package: xonix
Version: 1.4-32
Severity: minor

Dear Maintainer,

   * What led up to the situation?
   => Using the application menu
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   => Change the .desktop file. Diff below.

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

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

Versions of packages xonix depends on:
ii  libc6 2.28-10
ii  libx11-6  2:1.6.7-1
ii  libxaw7   2:1.0.13-1+b2
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1+b3

xonix recommends no packages.

xonix suggests no packages.

-- no debconf information

diff --git a/debian/xonix.desktop b/debian/xonix.desktop
--- a/debian/xonix.desktop
+++ b/debian/xonix.desktop
@@ -1,8 +1,8 @@
 [Desktop Entry]
 Type=Application
-Name=Game to carve up the screen whilst dodging monsters
+Name=Xonix
 GenericName=
-Comment=
+Comment=Game to carve up the screen whilst dodging monsters
 Icon=xonix
 Exec=/usr/games/xonix
 Terminal=false

Bug#964253: libbluray: Include list_titles and bdsplice utilities

[Jean-Baptiste Kempf]

Done on the same merge request.

On Mon, Jul 6, 2020, at 09:19, Vasyl Gello wrote:
> Hi Jean-Baptiste!
> 
> As usual, great work! Mind adding also bdsplice to installed programs?
> -- 
> Vasyl GelloCertified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
> 
> July 6, 2020 7:01:37 AM UTC, Jean-Baptiste Kempf  
> написав(-ла):
>> And the request is here 
>> https://code.videolan.org/videolan/libbluray/-/merge_requests/21
>> 
>> On Mon, Jul 6, 2020, at 08:58, Jean-Baptiste Kempf wrote:
>>> Hello,
>>> 
>>> I don't really get it, to be honest, since list_titles is noinst_PROGRAMS, 
>>> a contrario from bd_info, because it is not really useful.
>>> 
>>> But, if you care, of course this is fine. I don't mind.
>>> 
>>> BEst,
>>> 
>>> On Sun, Jul 5, 2020, at 12:12, Vasyl Gello wrote:
 Sebastian,
 
 Maybe it is good idea to rename that tool upstream to bd_list_titles.
 
 Jean-Baptiste, what do you think of it? If you are fine with it, please 
 make a new tag as usual :)
 -- 
 Vasyl GelloCertified SolidWorks Expert
 
 Mob.:+380 (98) 465 66 77
 
 E-Mail: vasek.ge...@gmail.com
 
 Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
 
 July 5, 2020 9:39:12 AM UTC, sramac...@debian.org написав(-ла):
> Hi Nils, Vasyl,
> 
> On 2020-07-05 09:30:26 +, Vasyl Gello wrote:
>> Control: block -1 by 964242
>> Control: owner -1 !
>> 
>> Hi Nils,
>> 
>> I am building the fix locally, however please note that ANY clean-room 
>> build
>> (be it pbuilder / cowbuilder / sbuild) targeting unstable will end up 
>> failing to
>> resolve a broken dependency of bsdmainutils on bsdextrautils (Bug 
>> #964242).
>> 
>> To work around it, I had to create a custom base tarball and pin 
>> bsdmainutils
>> against testing in it (12.1.2+b1).
>> 
>> If the fixed libbluray build passes, I will do a team upload to Salsa 
>> Git.
>> After that, Sebastian might upload a new Debian package version to the 
>> queue.
> 
> I'm fine with bdsplice, but I think that the binary name of list_titles
> is too generic to be installed globally.
> 
> Cheers
> 
>> 
>> On Sat, 4 Jul 2020 16:04:45 +0200 Oneric  wrote:
>>> Package: libbluray-bin
>>> Version: 1:1.1.0-1
>>> Severity: wishlist
>>> 
>>> Hi,
>>> 
>>> I think it might be worth including the `list_titles` and `bdsplice` 
>>> utilities 
>>> in libbluray-bin (curretnly only `bd_info`).
>>> list_titles gives some more information about titles/playlists on the 
>>> BD and 
>>> bdsplice allows to extract single titles/playlists or just some 
>>> chapters.
>>> 
>>> Just like `bd_info` the source of these utilities is already present in 
>>> libbluray in src/examples and also already built – but not yet included 
>>> in 
>>> libbluray-bin.
>>> 
>>> Regards
>>> Nils König
>>> 
>> 
>> -- 
>> Vasyl GelloCertified SolidWorks Expert
>> 
>> Mob.:+380 (98) 465 66 77
>> 
>> E-Mail: vasek.ge...@gmail.com
>> 
>> Skype: vasek.gello호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
> 
 
 *Attachments:*
  * signature.asc
>>> 
>>> --
>>> Jean-Baptiste Kempf - President
>>> +33 672 704 734
>>> 
>>> 
>>> 
>> 
>> --
>> Jean-Baptiste Kempf - President
>> +33 672 704 734
>> 
>> 
> 
> *Attachments:*
>  * signature.asc

--
Jean-Baptiste Kempf - President
+33 672 704 734

Bug#961218: ipp-usb Packaging some more remarks

[Till Kamppeter]

[ CCed debian-printing and Alexander Pevzner ]

Hi,

I have worked a lot with Alexander Pevzner on making ipp-usb what it is 
now and I also have succeeded to get localhost support into Avahi.


Most was already told in the initial report, but I have some additional 
remarks:


- IPP-over-USB is a very important standard to allow printing and 
scanning without hardware-model-specific drivers when the device is 
connected via USB. There is no way for driverless USB access to such 
devices without using IPP-over-USB, Practically all modern 
printer/scanner-multi-function devices support driverless IPP operation 
including IPP-over-USB. This way we get thousands of printers and 
scanners (and even sending fax) working, without needing to develop 
drivers. ipp-usb is currently the only way to get this working reliably.


- The upstream source repository https://github.com/OpenPrinting/ipp-usb 
(Note: it has moved to OpenPrinting) contains also the debian packaging 
in its debian/ subdiectory, so packaging for Debian probably needs only 
some simple corrections. The work load needed is very low. Also 
maintaining would be easy as Alexander would probably help.


- I also want to introduce ipp-usb in Ubuntu, in 20.10 (Groovy Gorilla) 
which has Feature Freeze Aug 27. It would be great if I could sync from 
Debian.


No one interested? OdyX, could you package/upload it?

   Till

Bug#964377: bumblebee: please runtime depend on pciutils

[Andreas Beckmann]

On 7/6/20 1:14 PM, Gianfranco Costamagna wrote:

Hello, bumblebee and bumblebee-nvidia (in Ubuntu) use lspci in their postinst 
files, without
a dependency on it


Good catch!
Should there be a lintian test for it? I remember fixing the same thing 
in firmware-b43-installer recently.



Andreas

Bug#964380: pango1.0: New upstream development branch 1.45.x, required by GTK 4

[Simon McVittie]

Source: pango1.0
Version: 1.44.7-4
Severity: wishlist

GTK 3.98.5 (GTK 4 prerelease) requires Pango 1.45.0+. This is a development
branch, so should probably go to experimental first.

Bug#907253: terminator: [terminator] crash and hang when opening new window

[0...@caiway.net]

Same here in daily updated debian buster, in fluxbox window manager.

Thanks!

Bug#964382: pulseeffects: Broken equalizer with PE 4.7.1 and lsp-plugins >=1.1.14

[damian01w]

Package: pulseeffects
Version: 4.7.1-2+b3
Severity: important

Dear Maintainer,

   * PulseEffects 4.7.1 equalizer plugin not working.
   * The upstream bug report [0] suggest that since LSP Plugins 1.1.14 onwards,
you need at least PE 4.7.2. This was the main reason why 4.7.2 was released.
   * On debian PE is at 4.7.1, and there is also another related bug #956255,
which prevent the upgrade to PE>= 4.7.2.

[0]: https://github.com/wwmm/pulseeffects/issues/646



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

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

Versions of packages pulseeffects depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gir1.2-gst-plugins-bad-1.0   1.16.2-2.1+b1
ii  gstreamer1.0-adapter-pulseeffects4.7.1-2+b3
ii  gstreamer1.0-plugins-bad 1.16.2-2.1+b1
ii  gstreamer1.0-plugins-good1.16.2-3
ii  gstreamer1.0-pulseaudio  1.16.2-3
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libboost-filesystem1.71.01.71.0-6+b2
ii  libc62.30-8
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libgcc-s110.1.0-4
ii  libglib2.0-0 2.64.3-2
ii  libglibmm-2.4-1v52.64.2-2
ii  libgstreamer-plugins-base1.0-0   1.16.2-4
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.20-1
ii  libgtkmm-3.0-1v5 3.24.2-1
ii  libpangomm-1.4-1v5   2.42.1-1
ii  libpulse013.0-5
ii  libsigc++-2.0-0v52.10.2-1
ii  libsndfile1  1.0.28-8
ii  libstdc++6   10.1.0-4
ii  pulseaudio   13.0-5

Versions of packages pulseeffects recommends:
ii  calf-plugins   0.90.3-1+b1
ii  gstreamer1.0-autogain-pulseeffects 4.7.1-2+b3
ii  gstreamer1.0-convolver-pulseeffects4.7.1-2+b3
ii  gstreamer1.0-crystalizer-pulseeffects  4.7.1-2+b3
ii  liblilv-0-00.24.8~dfsg0-1
ii  mda-lv21.2.4-1
ii  rubberband-ladspa  1.8.2-1
ii  zam-plugins3.9~repack3-1+b1

pulseeffects suggests no packages.

-- no debconf information

Bug#786614: nano: launching in existing terminal after 2.4.1 upgrade fails with "No such file or directory"

[Benno Schulenberg]

[Sorry.  I was sending it to the wrong bug number.]


Jordi, I think Andrew has a small point here.  Even now, if someone
would upgrade from jessie to bullseye (nano-2.2.6 to nano-4.9.3) on
a system with an unmerged /usr, they will get the "No such file or
directory" when trying to run nano in an existing shell.  So, why
not apply the patch that Marco posted?

However, Andrew, it is a very tiny bug.  When you encounter it, the
solution is to tell the shell to forget the paths it cached, with:
hash -r.  It does not require restarting the terminal or the shell.

Benno



signature.asc
Description: OpenPGP digital signature

Bug#954604: Mailman 3.3.1

[Wilfried Klaebe]

Hi,

on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954604 I read that
Mailman 3.3.1 should enter debian as soon as it is released.

Mailman 3.3.1 has been released on 19 Apr 2020, according to
https://list.org/

Are there any problems left to be solved?

Regards,

Wilfried

Bug#964383: Issues in init-system-helpers man pages

[Helge Kreutzmann]

Package: init-system-helpers
Severity: normal

Dear init-system-helpers maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including init-system-helpers) 
as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know.

Man page: deb-systemd-invoke.1p
Issue: Groff code broken?

"\\&B start|stop|restart IÂ\\ ..."
--
Man page: deb-systemd-invoke.1p
Issue: 206 → 2006?

"Jan 206"
--
Man page: deb-systemd-invoke.1p
Issue: s/it to/to/

"The I

Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892

[Sergio Durigan Junior]

On Monday, June 29 2020, Craig Small wrote:

> Hi All
>   There's a few goes of the required patches but I think I've got them all.
> There was the v3doublefree2.patch, a format patch and then the first git
> reference in the tracker where they have re-arranged the free function so
> it tracks the reference count.
>
> The result does compile and build packages and it is not too terrible about
> the lintian warnings, but  I haven't installed or tested it yet; that's a
> job for tomorrow (which is only an hour away, but it will be much longer
> than that). If anyone is keen in the meantime go ahead and see if it works
> for you.

Hey Craig,

Thanks for the work on the patches; I've had to do the same for Ubuntu,
so I understand the complexity...  :-)

I'd like to propose an improvement on the current fix.  While doing the
backports on Ubuntu, I noticed a few other patches that were needed in
order to guarantee that the existing memory leaks were addressed.
Unfortunately, the very first upstream commit that tried to fix the CVE
ended up introducing some leaks, and in the end it was necessary to
reorganize the code a little bit to solve them all.  The commits are
scattered over the history, sometimes without much context, so it takes
a little time until we have a proper set of them to be backported.

Anyway, I took the liberty to open an MR here:

  https://salsa.debian.org/debian/net-snmp/-/merge_requests/3

This MR adds the extra patches from upstream, performs some renames, and
brings the Debian package closer to the Ubuntu version.

Let me know what you think.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#964291: stretch-pu: package mariadb-10.1 10.1.45-0+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2020-07-06 at 10:47 +0300, Otto Kekäläinen wrote:
> Hi!
> 
> su 5. heinäk. 2020 klo 14.24 Adam D. Barratt <
> a...@adam-barratt.org.uk> kirjoitti:
> > On Sun, 2020-07-05 at 11:00 +0300, Otto Kekäläinen wrote:
> > > Since we already have MariaDB 10.4 in Debian experimental, it is
> > not even possible to do any uploads of MariaDB 10.3 because of
> > triggering the NEW queue and version conflicts/downgrades.
> > 
> > I'm not sure I understand this comment.
> > 
> > mariadb 10.3 is still in unstable and, as far as I can see, no
> > other version of mariadb is. Therefore, uploading a new revision
> > there should neither trigger NEW, nor any version issues.
> > 
> > Yes, unstable and experimental share overrides, but that simply
> > means that an upload of 10.4 to unstable wouldn't hit NEW, it
> > doesn't imply anything about uploads of 10.3 in the meantime.
> 
> I was under the impression that the NEW queue was universal for
> experimental->unstable->testing->stable,

Ah, I see. In general, while there is one "queue", the decision as to
whether a package is NEW is per-suite - with the exception that as
experimental is intended to overlay unstable, rather than be a complete
suite in its own right, they share overrides.

> but indeed, I was able to upload mariadb-10.3 to unstable this
> morning.

Great! Please feel free to go ahead with the upload, bearing in mind
that the window for the (final) stretch point release closes this
weekend.

Regards,

Adam

Bug#964384: ulfius: FTBFS with recent libmicrohttpd

[Gianfranco Costamagna]

Source: ulfius
Version: 2.6.7-4
Severity: serious
tags: patch

Hello, can you please apply the two patches below to fix the build failure with 
new libmicrohttpd and to give a more useful error message in case curl fails?
(I don't know yet why, but the autopkgtest is failing in Ubuntu)



https://github.com/babelouest/ulfius/pull/168

and

https://github.com/babelouest/ulfius/commit/fa157b1bf14fd1aa0bf998f1f3f9c55d15a13a3b
(updating to 2.6.8 grabs automagically this commit, while my pull request is 
not yet merged)

thanks!

also, help to track down the ubuntu failure is appreciated
http://autopkgtest.ubuntu.com/packages/u/ulfius/groovy/amd64


Gianfranco

Bug#964245: (no subject)

[Edward Shornock]

It looks like this was fixed in https://github.com/beetbox/beets/pull/3621

Bug#964385: fish: __fish_is_first_arg function is missing

[David Adam]

Package: fish
Version: 3.1.0-1
Severity: normal

Dear maintainers,

Due to the flags passed to dh_install, the fish-common package is
missing the "__fish_is_first_arg" function.

This breaks some tab-completions, as reported upstream at
https://github.com/fish-shell/fish-shell/issues/7176 .

Instead of "-Xrg.fish" in the debian/rules file, the full path could be
given as "-Xshare/fish/completions/rg.fish".

Hope that is helpful.

Many thanks,

David Adam
fish committer
zanc...@ucc.gu.uwa.edu.au

Bug#964386: Issues in cron man pages

[Helge Kreutzmann]

Package: cron
Severity: normal

Dear Debian cron maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including cron) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know. I tried to mail upstream, 
but the e-mail adress given in the sources no longer work.

Man page: cron.8
Issue: Odd formatting of »mail command«

"B [B<-c> | B<-h> | B<-i> | B<-n> | B<-p> | B<-P> | B<-s> | B<-"
"m>Imail>B>]"

--
Man page: cron.8
Issue: B(8) → B(8).

"This option allows you to specify a shell command to use for sending I "
"mail output instead of using B(8)  This command must accept a "
"fully formatted mail message (with headers) on standard input and send it as "
"a mail message to the recipients specified in the mail headers.  Specifying "
"the string I (i.e., crond -m off)  will disable the sending of mail."
--
Man page: cron.8
Issue 1: out of → outside of
Issue 2: is needed to change pam → it is needed to change a PAM

"Tells the daemon to run in the foreground.  This can be useful when starting "
"it out of init. With this option is needed to change pam setting.  I must not enable I module."
--
Man page: cronnext.1
Issue: montly → monthly

"Do not consider the system crontab, usually the I file.  The "
"system crontab usually contains the hourly, daily, weekly and montly "
"crontabs, which might be better dealt with B(8)."
Man page: crontab.1
Issue: use B → use B.

"Scheduling cron jobs with B can be allowed or disallowed for "
"different users.  For this purpose, use the I and I "
"files.  If the I file exists, a user must be listed in it to be "
"allowed to use B.  If the I file does not exist but the "
"I file does exist, then a user must I be listed in the "
"I file in order to use B If neither of these files "
"exist, then only the super user is allowed to use B."
--
Man page: crontab.1
Issue: to use the crontab → to use B

"If both files exist then I takes precedence.  Which means "
"that I is not considered and your user must be listed in I in order to be able to use the crontab."
--
Man page: crontab.1
Issue: if, they exist, →  , if they exist,

"The files I and I if, they exist, must be "
"either world-readable, or readable by group ``crontab''. If they are not, "
"then cron will deny access to all users until the permissions are fixed."
--
Man page: crontab.5
Issue: pound-sign → hash sign

"Blank lines, leading spaces, and tabs are ignored.  Lines whose first non-"
"white space character is a pound-sign (#) are comments, and are not "
"processed.  Note that comments are not allowed on the same line as cron "
"commands, since they are considered a part of the command.  Similarly, "
"comments are not allowed on the same line as environment variable settings."
--
Man page: crontab.5
Issue: LOGNAME → I

"Several environment variables are set up automatically by the B(8)  "
"daemon.  I is set to /bin/sh, and I and I are set from "
"the /etc/passwd line of the crontab\\'s owner.  I and I can be "
"overridden by settings in the crontab; LOGNAME can not."

-- 
  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#964383: Issues in init-system-helpers man pages

[Michael Biebl]

Hi Helge

Am 06.07.20 um 15:41 schrieb Helge Kreutzmann:
> I'm now reporting the errors for your project. If future reports
> should use another channel, please let me know.

Ideally such a change request is submitted via salsa as merge request.
This makes it much easier to comment on the individual changes.

https://salsa.debian.org/debian/init-system-helpers/

> Man page: deb-systemd-invoke.1p
> Issue: Groff code broken?
> 
> "\\&B start|stop|restart IÂ\\ ..."

Can't really comment on that one. The resulting man page looks fine to me?
That man pages is generated via pod2man, could this be a toolchain issue?

> --
> Man page: deb-systemd-invoke.1p
> Issue: 206 → 2006?
> 
> "Jan 206"


I can't find any reference to "Jan 206" in the deb-systemd-invoke man
page. Can you point the source location?
Did you by chance confuse that with the service(8) man page which was
fixed just recently:
https://salsa.debian.org/debian/init-system-helpers/-/commit/f1b835dcb2d6198addfab045676351d70d2930e9

> --
> Man page: deb-systemd-invoke.1p
> Issue: s/it to/to/
> 
> "The I

Bug#964245: patch from pull request

[Edward Shornock]

>From dab0c1f9abda5b17cc7488f89a6fe08be7bc56a0 Mon Sep 17 00:00:00 2001
From: wisp3rwind <17089248+wisp3rw...@users.noreply.github.com>
Date: Tue, 9 Jun 2020 19:34:31 +0200
Subject: [PATCH] compatibility with breaking changes to the ast module

new in 3.10, also backported to 3.8 and 3.9: https://github.com/python/cpython/pull/20649
In fact, our generation of some Literals has been invalid since Python
3.4, fix that too.
---
 beets/util/functemplate.py | 29 -
 1 files changed, 20 insertions(+), 9 deletions(-)

Index: beets-1.4.9/beets/util/functemplate.py
===
--- beets-1.4.9.orig/beets/util/functemplate.py
+++ beets-1.4.9/beets/util/functemplate.py
@@ -73,15 +73,26 @@ def ex_literal(val):
 """An int, float, long, bool, string, or None literal with the given
 value.
 """
-if val is None:
-return ast.Name('None', ast.Load())
-elif isinstance(val, six.integer_types):
-return ast.Num(val)
-elif isinstance(val, bool):
-return ast.Name(bytes(val), ast.Load())
-elif isinstance(val, six.string_types):
-return ast.Str(val)
-raise TypeError(u'no literal for {0}'.format(type(val)))
+if sys.version_info[:2] < (3, 4):
+if val is None:
+return ast.Name('None', ast.Load())
+elif isinstance(val, six.integer_types):
+return ast.Num(val)
+elif isinstance(val, bool):
+return ast.Name(bytes(val), ast.Load())
+elif isinstance(val, six.string_types):
+return ast.Str(val)
+raise TypeError(u'no literal for {0}'.format(type(val)))
+elif sys.version_info[:2] < (3, 6):
+if val in [None, True, False]:
+return ast.NameConstant(val)
+elif isinstance(val, six.integer_types):
+return ast.Num(val)
+elif isinstance(val, six.string_types):
+return ast.Str(val)
+raise TypeError(u'no literal for {0}'.format(type(val)))
+else:
+return ast.Constant(val)
 
 
 def ex_varassign(name, expr):

Bug#964383: Issues in init-system-helpers man pages

[Helge Kreutzmann]

Hello Michael,
On Mon, Jul 06, 2020 at 04:18:22PM +0200, Michael Biebl wrote:
> Am 06.07.20 um 15:41 schrieb Helge Kreutzmann:
> > I'm now reporting the errors for your project. If future reports
> > should use another channel, please let me know.
> 
> Ideally such a change request is submitted via salsa as merge request.

As stated in my introduction, this is not (easily) possible, sorry. 

> This makes it much easier to comment on the individual changes.

I can send each change individually, some other projects (like
man-pages itself) request this. Do you want this in future reports (if
any)?

> https://salsa.debian.org/debian/init-system-helpers/
> 
> > Man page: deb-systemd-invoke.1p
> > Issue: Groff code broken?
> > 
> > "\\&B start|stop|restart IÂ\\ ..."
> 
> Can't really comment on that one. The resulting man page looks fine to me?
> That man pages is generated via pod2man, could this be a toolchain issue?

Probably.

> > --
> > Man page: deb-systemd-invoke.1p
> > Issue: 206 → 2006?
> > 
> > "Jan 206"
> 
> 
> I can't find any reference to "Jan 206" in the deb-systemd-invoke man
> page. Can you point the source location?
> Did you by chance confuse that with the service(8) man page which was
> fixed just recently:
> https://salsa.debian.org/debian/init-system-helpers/-/commit/f1b835dcb2d6198addfab045676351d70d2930e9

Yes, my fault, it was service(8). 

> > --
> > Man page: deb-systemd-invoke.1p
> > Issue: s/it to/to/
> > 
> > "The I

Bug#964387: python-aiosqlite: Update the package to the latest upstream version 0.13.0

[Sophie Brun]

Source: python-aiosqlite
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

Hello,

It would be great to have the latest version in Debian. We need a newer
version for a package in Kali (Debian's derivative).

Please consider to update the Debian package.

Thanks,
Sophie Brun

Bug#836343: mutt: macro interpretation is really fragile

[Samuel Hym]

Hi Antonio,

> since many things changed in teh most recent version (including the fact that
> we are not using neomutt anymore), are you still experiencing this issue in
> 1.14.4-2? 

I’ve just tested using mutt package 1.14.5-1 using the small muttrc
from the mail that opened this bug report, the main bug reported is
still there. Namely "" in a macro sequence is
interpreted as a call to the function if the function is available in
the current context and but otherwise as a sequence of the keys '<',
'f', etc. So this bug is still present.

I cannot reproduce the other, tiny, bug, about some part of the
sequence not being interpreted after a , though.

Best regards,
Samuel

Bug#964384: [Debian-iot-maintainers] Bug#964384: ulfius: FTBFS with recent libmicrohttpd

[Nicolas Mora]

> Hello, can you please apply the two patches below to fix the build failure 
> with new libmicrohttpd and to give a more useful error message in case curl 
> fails?
> (I don't know yet why, but the autopkgtest is failing in Ubuntu)
> 
Since I'm also the upstream author, I'll fix the ftbfs in the next
release, very soon. But I must package new releases orcania and yder
first. This should be done in a few days.

> 
> also, help to track down the ubuntu failure is appreciated
> http://autopkgtest.ubuntu.com/packages/u/ulfius/groovy/amd64
> 
In the log, the first error tells us that:
framework.c:667:F:test_ulfius_framework:test_ulfius_net_type_endpoint:0:
Assertion 'response.status == 200' failed: response.status == 503, 200
== 200
This test fails while getting "http://[::1]:8080/empty";, maybe there's
an ipv6 issue in ubuntu autopkgtest environment?

The last 2 errors will probably tell us more after the release since the
error message will be fixed in ulfius_send_smtp_rich_email, thanks to you!

/Nicolas



signature.asc
Description: OpenPGP digital signature

Bug#964389: bsdmainutils: leftover config files

[Chris Hofstaedtler]

Package: bsdmainutils
Version: 12.1.3

Hi Michael,

It appears there is some gap in the necessary cleanups in
bsdmainutils. My "unstable" system has these files listed as owned
by bsdmainutils:

# dpkg -L bsdmainutils
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/bsdmainutils
/usr/share/doc/bsdmainutils/NEWS.Debian.gz
/usr/share/doc/bsdmainutils/changelog.gz
/usr/share/doc/bsdmainutils/copyright
/etc/default/bsdmainutils
/etc/cron.daily/bsdmainutils

Note the /etc/default and /etc/cron.daily files.

I'm unsure how this has happened, but maybe you can review the
preinst(?) scripts.

Thanks,
Chris

Bug#964388: 'replicated server' entries with CIFS don't work

[Sam Morris]

Source: autofs
Version: 5.1.6-2
Severity: normal

I'm trying to make DFS-replicated CIFS file shares available. In
auto.master I have:

/dfsfile:/etc/auto.dfs   browse

and in auto.dfs I have:

   /dfs/HD-fstype=cifs,sec=krb5i,cruid=$UID,multiuser
://server1.domain.example/HD ://server2.domain.example/HD

but autofs interprets the entire server list as a single location:

Jul 06 16:31:14 kernel: CIFS: Attempting to mount 
//server1.domain.example/HD ://server2.domain.example/HD
Jul 06 16:31:14 kernel: CIFS VFS:  BAD_NETWORK_NAME: 
\\server1.domain.example\HD :
Jul 06 16:31:14 kernel: CIFS VFS: cifs_mount failed w/return code = -2

autofs(5) states:

A mount location can specify multiple hosts for a location,
portentially with a different export path for the same file system.
Historically these different locations  are  read- only and provide
the same replicated file system.

and gives the example of:

Multiple replicated hosts, different (potentially) paths:
 host1:/path/pathA host2:/path/pathB

which I think is the closest matching syntax. But I guess to automount,
CIFS shares don't have a host element, and the server name is given as
the first element to the path, which maybe means that this syntax is
only available for NFS entries...

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (535, 'stable-updates'), (535, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#715226: worms not cleaned on new game

[Arnaud Bonatti]

Hi! New upstream co-maintainer here.

I’ll assume this bug is not anymore present in current releases of the
game. If you encounter something like that again with a more recent
release, please report them to the GNOME Gitlab instance[1]. Thanks!

[1] https://gitlab.gnome.org/GNOME/gnome-nibbles/issues

-- 
Arnaud Bonatti

courriel : arnaud.bona...@gmail.com

Bug#961370: pv: ETA is wildly off when transfer rate changes

[lemonsqueeze]

updated patch at https://github.com/lemonsqueeze/pv :

- renamed --rate-window option to --eta-window
- fixed crash when rate is zero

Bug#964390: inkscape: Inkscape does not start: symbol lookup error

[jesusda]

Package: inkscape
Version: 1.0-2
Severity: important

Dear Maintainer,

Inkscape 1.0-2 does not start.

inkscape: symbol lookup error: /usr/bin/../lib/x86_64-linux-
gnu/inkscape/libinkscape_base.so: undefined symbol:
_ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE

Thanks.



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

Kernel: Linux 4.18.0-20.3-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages inkscape depends on:
ii  libatkmm-1.6-1v5   2.24.2-3
ii  libc6  2.29-7
ii  libcairo2  1.16.0-4
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.3-3
ii  libdbus-glib-1-2   0.110-4
ii  libdouble-conversion3  3.1.5-2
ii  libfontconfig1 2.13.0-4
ii  libfreetype6   2.10.1-2
ii  libgc1c2   1:7.4.2-8
ii  libgcc-s1  10-20200211-1
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-2
ii  libgdl-3-5 3.28.0-1
ii  libglib2.0-0   2.64.3-1
ii  libglibmm-2.4-1v5  2.54.1-3
ii  libgomp1   9.2.1-8
ii  libgsl25   2.6+dfsg-2
ii  libgtk-3-0 3.24.13-1
ii  libgtkmm-3.0-1v5   3.24.0-2
ii  libgtkspell3-3-0   3.0.9-3
ii  libharfbuzz0b  2.6.2-1
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-1
ii  libmagick++-6.q16-88:6.9.9.34+dfsg-3
ii  libpango-1.0-0 1.44.7-4
ii  libpangocairo-1.0-01.44.7-4
ii  libpangoft2-1.0-0  1.44.7-4
ii  libpangomm-1.4-1v5 2.42.0-2
ii  libpng16-161.6.36-6
ii  libpoppler-glib8   0.71.0-6
ii  libpoppler82   0.71.0-6
ii  libpotrace01.16-2
ii  librevenge-0.0-0   0.0.4-6
ii  libsigc++-2.0-0v5  2.10.0-1
ii  libsoup2.4-1   2.68.2-1
ii  libstdc++6 9.2.1-8
ii  libvisio-0.1-1 0.1.5-4
ii  libwpg-0.3-3   0.3.1-3
ii  libx11-6   2:1.6.6-1
ii  libxml22.9.4+dfsg1-6.1
ii  libxslt1.1 1.1.32-2
ii  python33.8.2-3
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages inkscape recommends:
ii  aspell   0.60.8-1
ii  fig2dev  1:3.2.7b-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b1
ii  libimage-magick-perl 8:6.9.10.23+dfsg-2.1
ii  libwmf-bin   0.2.8.4-10.6
ii  python3-lxml 4.5.0-1.1
ii  python3-numpy1:1.18.4-1
ii  python3-scour0.37-4

Versions of packages inkscape suggests:
ii  dia   0.97.3+git20160930-8.2
pn  inkscape-tutorials
pn  libsvg-perl   
pn  libxml-xql-perl   
ii  pstoedit  3.74-1+b1
pn  python3-uniconvertor  
ii  ruby  1:2.5.1

-- no debconf information

Bug#964391: alot: Fix utf8 encoding with a text/plain mailcap entry.

[Johannes 'josch' Schauer]

Package: alot
Version: 0.9.1-1
Severity: normal

Hi,

currently, alot is unable to handle emails with:

Content-Type: text/plain; charset="utf-8"; format="flowed"

Example:

"Mit freundlichen Gr��en" gets rendered where it should say "Mit
freundlichen Grüßen"

Luckily there is a patch that fixes this problem:

https://github.com/pazz/alot/commit/37395809db473fb9a4157084a5b1ea3165914556

Can we backport this patch?

If you don't have time in the next few days, then I can also do an NMU,
just tell me what works for you. :)

Thanks!

cheers, josch

Bug#963933: glib2.0: autopkgtext: ld: cannot find -lcryptsetup

[Chris Hofstaedtler]

Hi Simon,

src:util-linux will drop most static libraries in the 2.35.2-8 upload.
Please change the glib2.0 autopkgtest (by dropping the static test)
to allow this.

Many thanks,
Chris

Bug#964328: [wxmaxima] GLib-GIO-CRITICAL : g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

[Scott Talbert]

On Sun, 5 Jul 2020, Gunter Königsmann wrote:


How does one reassign bugs? I second the argumentation but wxMaxima
doesn't use the dbus, nor can it show nor suppress these warnings. It is
libwxWidgets, who does.

On July 5, 2020 8:05:47 PM GMT+02:00, kamar...@gmail.com wrote:

Package: wxmaxima
Version: 19.01.2-1
Severity: minor
Launching wxmaxima from the command line gives the following warnings.
GLib-GIO-CRITICAL **: 13:59:04.632: g_dbus_proxy_new: assertion
'G_IS_DBUS_CONNECTION (connection)' failed
The application starts and works fine though. If the warning is
important, the underlying code should be fixed. If it is not
important, wxmaxima should suppress it. It is distracting and reduces
the usability of the application.


wxWidgets doesn't use dbus either, except for WebView.  wxMaxima doesn't 
use WebView does it?


In any case, I can't reproduce this in unstable.  So it's either been 
fixed or there is something else required to reproduce.


Can someone who can reproduce this run it under gdb and get a stack trace 
to see where that g_dbus_proxy_new() call is coming from?


See, e.g.:
https://stackoverflow.com/questions/5785902/how-do-i-get-gdb-to-break-on-a-glib-assertion-failure

Thanks,
Scott

Bug#964384: [Debian-iot-maintainers] Bug#964384: ulfius: FTBFS with recent libmicrohttpd

[Gianfranco Costamagna]

Hello,
> This test fails while getting "http://[::1]:8080/empty";, maybe there's
> an ipv6 issue in ubuntu autopkgtest environment?
> 

they might not have ipv6 capability, or that port being already allocated? not 
sure.

> The last 2 errors will probably tell us more after the release since the
> error message will be fixed in ulfius_send_smtp_rich_email, thanks to you!
> 

thanks!

the error now with that patch is:
2020-07-06T15:19:23Z - Ulfius ERROR: Ulfius - Error sending smtp message, error 
message Couldn't connect to server
2020-07-06T15:19:23Z - Ulfius ERROR: Ulfius - Error sending smtp message, error 
message Couldn't connect to server
2020-07-06T15:19:23Z - Ulfius ERROR: Ulfius - Error sending smtp message, error 
message Couldn't connect to server

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/u/ulfius/20200706_151935_d3556@/log.gz

I honestly don't think using 8080 is a nice thing to do, probably such ports 
might be already opened

let me know if you need some more testing!

G.

Bug#963810: RFS: mcu8051ide/1.4.9-2 [QA] -- Graphical Integrated Development Environment for 8051

[Andrej Shadura]

Hi,

On Sat, 27 Jun 2020, at 21:50, Andrej Shadura wrote:
> On Sat, 27 Jun 2020 at 21:35, Carlos Henrique Lima Melara
>  wrote:
> > I am looking for a sponsor for my package "mcu8051ide"
> >
> >  * Package name: mcu8051ide
> >Version : 1.4.9-2
> >Upstream Author : Martin Ošmera  >  * URL : https://sourceforge.net/projects/mcu8051ide/
> >  * License : GPL-2+
> >  * Vcs : https://browse.dgit.debian.org/mcu8051ide.git/
> >Section : electronics

> I’ll upload this tomorrow unless someone beats me to it.

Just to make it clear, I have not forgotten about it; in fact, I will upload it 
later today, but I’m finishing some last touches to the package.

-- 
Cheers,
 Andrej

Bug#861850: add pause shortcuts to GNOME Nibbles

[Arnaud Bonatti]

Hi! New upstream co-maintainer here.

This functionality is currently being worked on (both the “Pause” and
the “Ctrl-P” shortcuts will be added), and will appear in the 3.38
stable release, planned for September. Thanks for the issue report!
and please use the GNOME Gitlab instance[1] for that kind of bugs,
it’s more easy to check for us developers. ;·)

[1] https://gitlab.gnome.org/GNOME/gnome-nibbles/issues

Regards,
Arnaud

-- 
Arnaud Bonatti

courriel : arnaud.bona...@gmail.com

Bug#964377: bumblebee: please runtime depend on pciutils

[Gianfranco Costamagna]

Hello,

> Good catch!
> Should there be a lintian test for it? I remember fixing the same thing 
> in firmware-b43-installer recently.
> 
it would probably help a lot, yes :)

but a quick and incomplete look shows...
https://codesearch.debian.net/search?q=lspci+path%3Apostinst%24&literal=0

only two packages affected?

G.

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-06 02:34:56 +0200, Guilhem Moulin wrote:
> On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote:
> > If you let the user run a script that controls the timeout, that
> > would be better. For instance, a typical setting when dropbear is
> > used to unlock the disk(s) would be to set the timeout so that the
> > following conditions are *both* satisfied:
> > 
> > 1. Some lower bound has been reached (say 10 seconds).
> > 
> > 2. The passphrase has been validated.
> > 
> > This makes sense because in this case, it is useless to abort
> > wait_for_dropbear() while the passphrase has not been validated
> > yet.
> 
> wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices
> have been mapped (if cryptsetup-initramfs is installed and the crypttab
> is not empty, that is).  So you're essentially asking to set the timeout
> to 10s.

OK, so that's even simpler. A configurable timeout would be
sufficient.

> > BTW, I've just noticed that the timeout introduces a second annoying
> > regression: If there is a temporary issue with the DHCP server just
> > after the machine has been restarted, so that the timeout is reached,
> > the user will not be able to unlock the disk until he can go back in
> > front of his machine!
> 
> You mean the timeout from configure_networking() it init-premout stage?
[...]

Please forget that. I meant wait_for_dropbear(), but since it runs
after dm-crypt devices have been mapped, there is no issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#963267: buster-pu: package multipath-tools/0.7.9-3+deb10u1

[Chris Hofstaedtler]

* Adam D. Barratt  [200706 17:17]:
> Control: tags -1 + confirmed d-i
> 
> On Sun, 2020-06-21 at 16:53 +, Chris Hofstaedtler wrote:
> > I'd like to push a fix for #959727 to buster. The bug causes us some
> > trouble with block devices that are -sometimes- missing. I've tested
> > the fix a while ago (on buster), and it seemed to help.
> > 
> 
> I'd be OK with that, but as multipath-tools creates a udeb, this will
> need a KiBi-ack.

Uploaded, as KiBi-ack was given.

Thanks,
Chris

Bug#963713: [Pkg-net-snmp-devel] Bug#963713: net-snmp: CVE-2019-20892

[Sylvain Beucler]

Hi,

Do we have definite info on what versions are affected?

I cannot reproduce the issue in jessie/stretch/buster (5.7.x).

Incidentally Salvatore's test now yields an error in bullseye
(5.8dfsg-3), though I suspect the issue is at the client's level:
# snmpbulkget -v3 -Cn1 -Cr1472 -l authPriv -u testuser -a SHA -A
testpass -x AES -X testpass 127.0.0.1 1.3.6.1.2.1.1.5 1.3.6.1.2.1.1.7
Error in packet.
Reason: (genError) A general failure occured

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#936783: kcachegrind: Python2 removal in sid/bullseye

[John Scott]

Python 3 doesn't include hotshot, so the hotshot2calltree script should be 
dropped. Upstream still includes it but it doesn't appear to have seen any 
maintenance:
https://invent.kde.org/sdk/kcachegrind/-/tree/master/converters

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

Bug#964392: ITP: tao-json -- multifunctional and zero-dependency C++ header-only JSON library

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: tao-json -- multifunctional and zero-dependency C++ header-only 
JSON library
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: tao-json
  Version : 1.0.0~beta.11
  Upstream Author : Dr. Colin Hirsch
* URL : https://github.com/taocpp/json
* License : Expat
  Programming Lang: C++
  Description : multifunctional and zero-dependency C++ header-only JSON 
library
 taoJSON is a zero-dependency C++ header-only JSON library that provides
 a generic Value Class, uses Type Traits to interoperate with C++ types,
 uses an Events Interface to convert to and from JSON, JAXN, CBOR,
 MsgPack and UBJSON, and much, much more.

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

Bug#964393: util-linux: FTBFS on non-linux: missing write

[Samuel Thibault]

Package: util-linux
Version: 2.35.2-6
Severity: important
Tags: ftbfs, patch

Hello,

I addition to the issue #963625, util-linux currently FTBFS on non-linux
because write is not getting enabled. The attached patch fixes this.

Samuel

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

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

Versions of packages util-linux depends on:
ii  libaudit1  1:2.8.5-3+b1
ii  libblkid1  2.35.2-6
ii  libc6  2.30-8
ii  libcap-ng0 0.7.9-2.2
ii  libcrypt1  1:4.4.16-1
ii  libmount1  2.35.2-6
ii  libpam0g   1.3.1-5
ii  libselinux13.0-1+b3
ii  libsmartcols1  2.35.2-6
ii  libsystemd0245.6-1
ii  libtinfo6  6.2-1
ii  libudev1   245.6-1
ii  libuuid1   2.35.2-6
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-4
ii  util-linux-locales  2.35.2-6

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

-- no debconf information

-- 
Samuel
 ça gaze ?
 prout
 -+- #ens-mim - ouvrez les fenêtres ! -+-
--- debian/rules.original   2020-07-06 17:29:34.0 +
+++ debian/rules2020-07-06 17:29:38.0 +
@@ -8,7 +8,6 @@
 CONFOPTS += --with-selinux
 CONFOPTS += --with-smack
 CONFOPTS += --enable-partx
-CONFOPTS += --enable-write
 ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
CONFOPTS += --without-systemd --without-udev --without-audit
 else
@@ -16,6 +15,8 @@
 endif
 endif
 
+CONFOPTS += --enable-write
+
 # build static versions of programs used in fdisk-udeb and util-linux-udeb
 CONFOPTS += --enable-static-programs=fdisk,sfdisk,blkid
 

Bug#964395: Does CVE-2020-13817 affect ntpsec?

[Moritz Muehlenhoff]

Source: ntpsec
Severity: important
Tags: security

This was assigned CVE-2020-13817 for ntp.org:
  http://support.ntp.org/bin/view/Main/NtpBug3596
  https://bugs.ntp.org/show_bug.cgi?id=3596
  http://bk.ntp.org/ntp-stable/?PAGE=patch&REV=5e312021VVVkyioYBR_aeIP1LqMCVg
  http://bk.ntp.org/ntp-stable/?PAGE=patch&REV=5e4a536dzxRWAzMw-KsKjm04l6joNA

Does this affect ntpsec?

Cheers,
Moritz

Bug#964396: RM: purity-ng -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove purity-ng. It depends on Python 2, is dead upstream (last commit
from 2011) and the last maintainer upload was in 2012.

Cheers,
Moritz

Bug#937378: purity-ng: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Sun, Jun 07, 2020 at 01:03:15AM +0200, Moritz Mühlenhoff wrote:
> On Fri, Aug 30, 2019 at 07:32:38AM +, Matthias Klose wrote:
> > Package: src:purity-ng
> > Version: 0.2.0-2.1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Hi Luke/Simon,
> the last commits for purity-ng are from 2011, are you still interested
> in this? Let's remove?

I filed an RM bug now.

Cheers,
Moritz

Bug#964398: stretch-pu: package libembperl-perl/2.5.0-10+deb9u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

As part of a security fix the changed Apache output was backported,
the #941926 fix for libembperl-perl is needed to fix the resulting
FTBFS due to test failure.
diff -Nru libembperl-perl-2.5.0/debian/changelog 
libembperl-perl-2.5.0/debian/changelog
--- libembperl-perl-2.5.0/debian/changelog  2016-10-26 06:51:02.0 
+0300
+++ libembperl-perl-2.5.0/debian/changelog  2020-07-06 16:04:21.0 
+0300
@@ -1,3 +1,11 @@
+libembperl-perl (2.5.0-10+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Update debian/patches/apache2.4-compat.patch to work with Apache
+2.4.40+ error pages. (Closes: #941926)
+
+ -- Adrian Bunk   Mon, 06 Jul 2020 16:04:21 +0300
+
 libembperl-perl (2.5.0-10) unstable; urgency=medium
 
   * Team upload.
diff -Nru libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch 
libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch
--- libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch 2016-10-26 
06:51:02.0 +0300
+++ libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch 2020-07-06 
16:04:15.0 +0300
@@ -1,7 +1,7 @@
 From bcce23a15de55a39478f83a7923d8a89f681cc19 Mon Sep 17 00:00:00 2001
 From: Niko Tyni 
 Date: Tue, 29 Jul 2014 14:34:35 +0300
-Subject: [PATCH] Adapt to an Apache 2.4.10 error page change
+Subject: [PATCH] Adapt to an Apache 2.4.10 + 2.4.40 error page change
 
 The "Forbidden" error page was slightly changed by Apache commit
 
@@ -10,22 +10,34 @@
 
 breaking the EmbperlObject/epobase.htm test. The fix works
 with both the old and the new page format.
+
+Some years and versions later:
+Apache changed the output again (in 2.4.40):
+ 
https://github.com/apache/httpd/commit/c0ce3a729218279a6b4b03aab7a71bb8ae9d6259
+
+Update the patch to hopefully work with all versions.
+
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/756382
+ https://bugs.debian.org/941926
+Reviewed-by: gregor herrmann 
+Last-Update: 2019-10-07
+
 ---
  test/cmp/epobase.htm | 1 +
  1 file changed, 1 insertion(+)
 
-diff --git a/test/cmp/epobase.htm b/test/cmp/epobase.htm
-index ba29386..9d0269c 100644
 --- a/test/cmp/epobase.htm
 +++ b/test/cmp/epobase.htm
-@@ -5,6 +5,7 @@
+@@ -3,8 +3,9 @@
+ 403 Forbidden
+ 
  Forbidden
- ^.*?You don't have permission to access /embperl/EmbperlObject/epobase.htm
- ^on this server
+-^.*?You don't have permission to access /embperl/EmbperlObject/epobase.htm
+-^on this server
++^.*?You don't have permission to access 
(/embperl/EmbperlObject/epobase.htm|this resource)
++^-on this server
 +^-
  
  
  
--- 
-2.0.1
-

Bug#964397: buster-pu: package libembperl-perl/2.5.0-12+deb10u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

As part of a security fix the changed Apache output was backported,
the #941926 fix for libembperl-perl is needed to fix the resulting
FTBFS due to test failure.
diff -Nru libembperl-perl-2.5.0/debian/changelog 
libembperl-perl-2.5.0/debian/changelog
--- libembperl-perl-2.5.0/debian/changelog  2018-06-28 03:08:58.0 
+0300
+++ libembperl-perl-2.5.0/debian/changelog  2020-07-06 19:58:46.0 
+0300
@@ -1,3 +1,11 @@
+libembperl-perl (2.5.0-12+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Update debian/patches/apache2.4-compat.patch to work with Apache
+2.4.40+ error pages. (Closes: #941926)
+
+ -- Adrian Bunk   Mon, 06 Jul 2020 19:58:46 +0300
+
 libembperl-perl (2.5.0-12) unstable; urgency=medium
 
   [ Damyan Ivanov ]
diff -Nru libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch 
libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch
--- libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch 2016-05-09 
19:51:58.0 +0300
+++ libembperl-perl-2.5.0/debian/patches/apache2.4-compat.patch 2020-07-06 
19:58:43.0 +0300
@@ -1,7 +1,7 @@
 From bcce23a15de55a39478f83a7923d8a89f681cc19 Mon Sep 17 00:00:00 2001
 From: Niko Tyni 
 Date: Tue, 29 Jul 2014 14:34:35 +0300
-Subject: [PATCH] Adapt to an Apache 2.4.10 error page change
+Subject: [PATCH] Adapt to an Apache 2.4.10 + 2.4.40 error page change
 
 The "Forbidden" error page was slightly changed by Apache commit
 
@@ -10,22 +10,34 @@
 
 breaking the EmbperlObject/epobase.htm test. The fix works
 with both the old and the new page format.
+
+Some years and versions later:
+Apache changed the output again (in 2.4.40):
+ 
https://github.com/apache/httpd/commit/c0ce3a729218279a6b4b03aab7a71bb8ae9d6259
+
+Update the patch to hopefully work with all versions.
+
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/756382
+ https://bugs.debian.org/941926
+Reviewed-by: gregor herrmann 
+Last-Update: 2019-10-07
+
 ---
  test/cmp/epobase.htm | 1 +
  1 file changed, 1 insertion(+)
 
-diff --git a/test/cmp/epobase.htm b/test/cmp/epobase.htm
-index ba29386..9d0269c 100644
 --- a/test/cmp/epobase.htm
 +++ b/test/cmp/epobase.htm
-@@ -5,6 +5,7 @@
+@@ -3,8 +3,9 @@
+ 403 Forbidden
+ 
  Forbidden
- ^.*?You don't have permission to access /embperl/EmbperlObject/epobase.htm
- ^on this server
+-^.*?You don't have permission to access /embperl/EmbperlObject/epobase.htm
+-^on this server
++^.*?You don't have permission to access 
(/embperl/EmbperlObject/epobase.htm|this resource)
++^-on this server
 +^-
  
  
  
--- 
-2.0.1
-

Bug#963267: buster-pu: package multipath-tools/0.7.9-3+deb10u1

[R hertoric]

Control: tags -1 + confirmed d-i

On Sun, Jun 21, 2020, 11:57 AM Chris Hofstaedtler  wrote:

> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
> Dear Stable Release Managers,
>
> I'd like to push a fix for #959727 to buster. The bug causes us some
> trouble with block devices that are -sometimes- missing. I've tested
> the fix a while ago (on buster), and it seemed to help.
>
> Please consider this.
>
> Thanks,
> Chris
>
> diff -Nru multipath-tools-0.7.9/debian/changelog
> multipath-tools-0.7.9/debian/changelog
> --- multipath-tools-0.7.9/debian/changelog  2019-03-18
> 15:26:38.0 +
> +++ multipath-tools-0.7.9/debian/changelog  2020-06-21
> 16:41:48.0 +
> @@ -1,3 +1,9 @@
> +multipath-tools (0.7.9-3+deb10u1) buster; urgency=medium
> +
> +  * [775fe68] kpartx: use correct path to partx in udev rule (Closes:
> #959727)
> +
> + -- Chris Hofstaedtler   Sun, 21 Jun 2020 16:41:48 +
> +
>  multipath-tools (0.7.9-3) unstable; urgency=medium
>
>* [51a7724] Reliably extract the running systemd version
> diff -Nru multipath-tools-0.7.9/debian/patches/partx-path.patch
> multipath-tools-0.7.9/debian/patches/partx-path.patch
> --- multipath-tools-0.7.9/debian/patches/partx-path.patch   1970-01-01
> 00:00:00.0 +
> +++ multipath-tools-0.7.9/debian/patches/partx-path.patch   2020-06-21
> 16:41:48.0 +
> @@ -0,0 +1,14 @@
> +Use Debian-specific path for partx (from util-linux).
> +
> +Index: multipath-tools/kpartx/del-part-nodes.rules
> +===
> +--- multipath-tools.orig/kpartx/del-part-nodes.rules
>  multipath-tools/kpartx/del-part-nodes.rules
> +@@ -28,6 +28,6 @@ GOTO="end_del_part_nodes"
> + LABEL="del_part_nodes"
> + IMPORT{db}="DM_DEL_PART_NODES"
> + ENV{DM_DEL_PART_NODES}!="1", ENV{DM_DEL_PART_NODES}="1", \
> +-  RUN+="/usr/sbin/partx -d --nr 1-1024 $env{DEVNAME}"
> ++  RUN+="/usr/bin/partx -d --nr 1-1024 $env{DEVNAME}"
> +
> + LABEL="end_del_part_nodes"
> diff -Nru multipath-tools-0.7.9/debian/patches/series
> multipath-tools-0.7.9/debian/patches/series
> --- multipath-tools-0.7.9/debian/patches/series 2019-02-08
> 13:38:26.0 +
> +++ multipath-tools-0.7.9/debian/patches/series 2020-06-21
> 16:41:48.0 +
> @@ -6,3 +6,4 @@
>  fix-usrmerge-paths.patch
>  11-dm-mpath-fix-DM_UDEV_RULES_VSN-check.patch
>  enable-cross-build.patch
> +partx-path.patch
>
>

Bug#964399: Should ganglia be removed?

[Moritz Muehlenhoff]

Source: ganglia
Severity: serious

Should ganglia be removed? It's dead upstream (last commits from over three 
years ago,
last release from 2015), is now orphaned (last active maintainer is no longer a 
DD, but
wasn't very actively maintained to begin with, the current packaged version is 
from 2013),
most of the plugins depend on Python 2, there's unfixed security issues dating 
back to
2013 and doesn't even support ipv6 (730257).

Unless anyone steps up for maintenance (and partly becomes upstream), it should 
better
be removed.

Cheers,
Moritz

Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)

[Andrei POPESCU]

On Lu, 06 iul 20, 10:55:22, Ansgar wrote:
> Andrei POPESCU writes:
> > On Mi, 10 iul 19, 13:16:27, Ansgar Burchardt wrote:
> >> People should probably use something like
> >>
> >>   deb http://security.debian.org/debian-security bullseye-security main
> >>
> >> (adding /debian-security was proposed in [1]).
> >
> > Could this be /debian instead, to be consistent with the other suites?
> 
> I think that would be a bad idea as they are different archives.
> /debian and /debian-security contain different things, giving them the
> same name would be confusing.  Also deb.d.o needs different names.

Ok.

I was hoping this was possible, considering that -updates and 
-proposed-updates are also under /debian ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#964400: haskell-yesod-core: build fails on IPv6-only buildds

[Adrian Bunk]

Source: haskell-yesod-core
Version: 1.6.18-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=haskell-yesod-core&arch=i386&ver=1.6.18-1&stamp=1593282031&raw=0

...
Failures:

  test/YesodCoreTest/RawResponse.hs:63:9: 
  1) RawResponse works
   uncaught exception: IOException of type NoSuchThing
   Network.Socket.getAddrInfo (called with preferred socket type/protocol: 
AddrInfo {addrFlags = [AI_PASSIVE,AI_ADDRCONFIG], addrFamily = AF_UNSPEC, 
addrSocketType = Stream, addrProtocol = 0, addrAddress = , addrCanonName = }, host name: Just 
"127.0.0.1", service name: Just "0"): does not exist (Address family for 
hostname not supported)

  To rerun use: --match "/RawResponse/works/"

  test/YesodCoreTest/RawResponse.hs:89:5: 
  2) sendWaiResponse + responseStream
   uncaught exception: IOException of type NoSuchThing
   Network.Socket.getAddrInfo (called with preferred socket type/protocol: 
AddrInfo {addrFlags = [AI_PASSIVE,AI_ADDRCONFIG], addrFamily = AF_UNSPEC, 
addrSocketType = Stream, addrProtocol = 0, addrAddress = , addrCanonName = }, host name: Just 
"127.0.0.1", service name: Just "0"): does not exist (Address family for 
hostname not supported)

  To rerun use: --match "/sendWaiResponse + responseStream/"

  test/YesodCoreTest/RawResponse.hs:91:5: 
  3) sendWaiApplication + responseStream
   uncaught exception: IOException of type NoSuchThing
   Network.Socket.getAddrInfo (called with preferred socket type/protocol: 
AddrInfo {addrFlags = [AI_PASSIVE,AI_ADDRCONFIG], addrFamily = AF_UNSPEC, 
addrSocketType = Stream, addrProtocol = 0, addrAddress = , addrCanonName = }, host name: Just 
"127.0.0.1", service name: Just "0"): does not exist (Address family for 
hostname not supported)

  To rerun use: --match "/sendWaiApplication + responseStream/"

Randomized with seed 920512437

Finished in 0.0724 seconds
157 examples, 3 failures
Test suite tests: FAIL
Test suite logged to: dist-ghc/test/yesod-core-1.6.18-tests.log
1 of 2 test suites (1 of 2 test cases) passed.
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:154: check-ghc-stamp] Error 1


See #962019 for a discussion of a similar bug.

Bug#964401: sight FTBFS on i386: error: conversion from ‘long long unsigned int’ to ‘size_t’ {aka ‘unsigned int’} may change value

[Adrian Bunk]

Source: sight
Version: 20.0.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=sight&arch=i386&ver=20.0.0-1&stamp=1593349313&raw=0

...
/<>/libs/core/fwData/src/fwData/Mesh.cpp: In member function 
‘size_t fwData::Mesh::getDataSizeInBytes() const’:
/<>/libs/core/fwData/src/fwData/Mesh.cpp:470:61: error: conversion 
from ‘long long unsigned int’ to ‘size_t’ {aka ‘unsigned int’} may change value 
[-Werror=conversion]
  470 | m_points&& (size += m_points->getElementSizeInBytes() * m_nbPoints);
  | ^~
/<>/libs/core/fwData/src/fwData/Mesh.cpp:471:67: error: conversion 
from ‘long long unsigned int’ to ‘size_t’ {aka ‘unsigned int’} may change value 
[-Werror=conversion]
  471 | m_cellTypes&& (size += m_cellTypes->getElementSizeInBytes() * 
m_nbCells );
  |   
^
/<>/libs/core/fwData/src/fwData/Mesh.cpp:472:65: error: conversion 
from ‘long long unsigned int’ to ‘size_t’ {aka ‘unsigned int’} may change value 
[-Werror=conversion]
  472 | m_cellData&& (size += m_cellData->getElementSizeInBytes() * 
m_cellsDataSize);
  | 
^~~
...

Bug#964390: inkscape: Inkscape does not start: symbol lookup error

[Mattia Rizzolo]

On Mon, Jul 06, 2020 at 06:23:39PM +0200, jesusda wrote:
> Inkscape 1.0-2 does not start.
> 
> inkscape: symbol lookup error: /usr/bin/../lib/x86_64-linux-
> gnu/inkscape/libinkscape_base.so: undefined symbol:
> _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE

This is the same of https://bugs.debian.org/961216

>   APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable')

please beware of mixing up releases.

> ii  libglib2.0-0   2.64.3-1
> ii  libglibmm-2.4-1v5  2.54.1-3

I really wonder how you mange to mix up these.  Obviously there is a
missing versioned dependency, but your system is not fully up-to-date,
so please run apt upgrade.

Now that glibmm2.4 is fixed to generate the proper versioned dependency,
I'm going to rebuild inkscape to pick up the new dependency, fixing
this… but really, your system can be considered broken.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#936268: caldav-tester: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:12:44AM +, Matthias Klose wrote:
> Package: src:caldav-tester
> Version: 7.0-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Hi,
caldav-tester is related to calendarserver, which was removed three
months ago. Is caldav-tester by itself still useful (and if so, are
you planning to port it to Python 3), or should it be removed as well?

Cheers,
Moritz

Bug#964381: lintian: Detecting bogus email address

[Felix Lechner]

Hi Hugh,

On Mon, Jul 6, 2020 at 6:24 AM Hugh McMaster  wrote:
>
> lintian has detected two identical entries in yaz's debian/changelog
> as bogus.

Thank you for filing this report. The address is indeed bogus,
although we tried to turn off TLD validation. That issue is being
addressed separately. [1]

% whois flurry.index
No whois server is known for this kind of object

[1] https://lists.debian.org/debian-perl/2020/07/msg7.html

> The entries are adam@flurry.index.

I wrote to another email address from your changelog that was used
recently in the Debian BTS and pointed Adam to this bug.

> I'm not sure how to address this.

Unless Adam objects, I would replace the bogus address with the one
recently used in Bug#955501.

Kind regards
Felix Lechner

Bug#964377: bumblebee: please runtime depend on pciutils

[Adrian Bunk]

Control: severity -1 important

On Mon, Jul 06, 2020 at 02:40:37PM +0200, Andreas Beckmann wrote:
> On 7/6/20 1:14 PM, Gianfranco Costamagna wrote:
> > Hello, bumblebee and bumblebee-nvidia (in Ubuntu) use lspci in their 
> > postinst files, without
> > a dependency on it
> 
> Good catch!
> Should there be a lintian test for it? I remember fixing the same thing in
> firmware-b43-installer recently.

In bumblebee this seems to be an Ubuntu-only problem:

debian/bumblebee-nvidia.postinst.Ubuntu:
  busid=$(lspci -d10de: -nn | grep '\[030[02]\]' | cut -d' ' -f1 | tr . : | 
head -1)

debian/bumblebee.postinst:
# Raring specific issue
# Also, do not rely solely on dpkg-vendor (see LP: #1061769)
if (which dpkg-vendor >/dev/null && dpkg-vendor --derives-from Ubuntu) || \
  [ -e /etc/dpkg/origins/ubuntu ]; then
# assume first device to be discrete in nvidia/nvidia
busid=$(lspci -d10de: -nn | grep '\[030[02]\]' | cut -d' ' -f1 | tr . : 
| head -1)


> Andreas

cu
Adrian

Bug#964389: bsdmainutils: leftover config files

[Michael Meskes]

On Mon, Jul 06, 2020 at 05:40:24PM +0200, Chris Hofstaedtler wrote:
> It appears there is some gap in the necessary cleanups in
> bsdmainutils. My "unstable" system has these files listed as owned
> by bsdmainutils:
> ... 

Gheez, I should have done a hard dependency from the get go. I guess this comes
from one update that didn't bring in calendar. Anyway, could you please verify
for me that there are no config files in your calendar package? 

Thanks,

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#964403: goxel FTBFS on armel: Must be linked with libatomic

[Adrian Bunk]

Source: goxel
Version: 0.10.6-1
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/fetch.php?pkg=goxel&arch=armel&ver=0.10.6-1&stamp=1592688053&raw=0

...
g++ -o goxel -fsanitize=address -fsanitize=undefined -pthread -Wl,-z,relro 
src/yocto.o src/xxhash.o src/utils.o src/tools.o src/theme.o src/tests.o 
src/system.o src/shape.o src/shader_cache.o src/script.o src/render.o 
src/quantization.o src/procedural.o src/pathtracer.o src/palette.o 
src/model3d.o src/meta.o src/mesh_utils.o src/mesh_to_vertices.o src/mesh.o 
src/material.o src/marchingcube.o src/main.o src/luagoxel.o src/layer.o 
src/imgui.o src/image.o src/gui.o src/goxel.o src/gesture3d.o src/gesture.o 
src/camera.o src/box_edit.o src/assets.o src/action.o src/utils/vec.o 
src/utils/texture.o src/utils/sound.o src/utils/mustache.o src/utils/json.o 
src/utils/ini.o src/utils/img.o src/utils/gl.o src/utils/color.o 
src/utils/cache.o src/utils/box.o src/utils/b64.o src/tools/shape.o 
src/tools/selection.o src/tools/procedural.o src/tools/plane.o src/tools/move.o 
src/tools/line.o src/tools/laser.o src/tools/fuzzy_select.o src/tools/extrude.o 
src/tools/color_picker.o src/tools/brush.o src/gui/view_panel.o 
src/gui/topbar.o src/gui/tools_panel.o src/gui/settings.o 
src/gui/render_panel.o src/gui/palette_panel.o src/gui/menu.o 
src/gui/material_panel.o src/gui/light_panel.o src/gui/layers_panel.o 
src/gui/image_panel.o src/gui/export_panel.o src/gui/debug_panel.o 
src/gui/cameras_panel.o src/gui/app.o src/gui/about.o src/formats/wavefront.o 
src/formats/vxl.o src/formats/voxlap.o src/formats/vox.o src/formats/txt.o 
src/formats/qubicle.o src/formats/povray.o src/formats/png_slices.o 
src/formats/png.o src/formats/gox.o src/formats/gltf.o src/formats/dicom.o 
-lasan -lubsan -lpng -lGL -lm -lglfw -lgtk-3 -lgdk-3 -lpangocairo-1.0 
-lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 
-lgio-2.0 -lgobject-2.0 -lglib-2.0
/usr/bin/ld: src/yocto.o: in function `std::__atomic_base::operator+=(unsigned long long)':
/usr/include/c++/9/bits/atomic_base.h:335: undefined reference to 
`__atomic_fetch_add_8'
/usr/bin/ld: src/yocto.o: in function `std::__atomic_base::store(unsigned long long, std::memory_order)':
/usr/include/c++/9/bits/atomic_base.h:397: undefined reference to 
`__atomic_store_8'
/usr/bin/ld: src/yocto.o: in function `std::__atomic_base::load(std::memory_order) const':
/usr/include/c++/9/bits/atomic_base.h:419: undefined reference to 
`__atomic_load_8'
collect2: error: ld returned 1 exit status
scons: *** [goxel] Error 1


Fix/Workaround:

--- debian/rules.old2020-07-05 21:59:58.246217695 +
+++ debian/rules2020-07-05 22:00:26.841963922 +
@@ -2,6 +2,11 @@
 export DH_VERBOSE = 1
 NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel mipsel))
+  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
+
+
 include /usr/share/dpkg/default.mk  # provides DEB_VERSION
 
 %:

Bug#964402: netmask: manpage mentions out of date software

[Martin Zobel-Helas]

Package: netmask
Version: 2.4.4-2
Severity: minor

Hiho,

the manpage of netmask still mentions software like ipchains, which is
not part of any Debian release any more. AFAIR ipchains was Linux kernel
2.2, which latest version was released in 2005, and it's successor
iptables introduced with kernel 2.4 in 2001 is now going to be replaced
by nftables. Maybe it is time to remove this old piece of software from
the manpage.

Best regards,
Martin

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

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

Versions of packages netmask depends on:
ii  libc6  2.30-8

netmask recommends no packages.

netmask suggests no packages.

-- no debconf information

-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


signature.asc
Description: PGP signature

Bug#964328: [wxmaxima] GLib-GIO-CRITICAL : g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

[Gunter Königsmann]

wxMaxima until about 2 months ago for showing thechelp system used 
wxHtmlHelpCtrl from wxWidgets. And that control used wxWebView. So you might be 
right about what control triggered the warning. The current wxMaxima master has 
a performance issue. Once that is resolved I will try to upload a new release 
to Debian-testing.

On July 6, 2020 6:51:09 PM GMT+02:00, Scott Talbert  wrote:
>On Sun, 5 Jul 2020, Gunter Königsmann wrote:
>
>> How does one reassign bugs? I second the argumentation but wxMaxima
>> doesn't use the dbus, nor can it show nor suppress these warnings. It is
>> libwxWidgets, who does.
>> 
>> On July 5, 2020 8:05:47 PM GMT+02:00, kamar...@gmail.com wrote:
>> 
>> Package: wxmaxima
>> Version: 19.01.2-1
>> Severity: minor
>> Launching wxmaxima from the command line gives the following warnings.
>> GLib-GIO-CRITICAL **: 13:59:04.632: g_dbus_proxy_new: assertion
>> 'G_IS_DBUS_CONNECTION (connection)' failed
>> The application starts and works fine though. If the warning is
>> important, the underlying code should be fixed. If it is not
>> important, wxmaxima should suppress it. It is distracting and reduces
>> the usability of the application.
>
>wxWidgets doesn't use dbus either, except for WebView.  wxMaxima doesn't 
>use WebView does it?
>
>In any case, I can't reproduce this in unstable.  So it's either been 
>fixed or there is something else required to reproduce.
>
>Can someone who can reproduce this run it under gdb and get a stack trace 
>to see where that g_dbus_proxy_new() call is coming from?
>
>See, e.g.:
>https://stackoverflow.com/questions/5785902/how-do-i-get-gdb-to-break-on-a-glib-assertion-failure
>
>Thanks,
>Scott
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#962221: Fixes for CVE-2020-13696 (#962221)

[Mattia Rizzolo]

On Mon, Jul 06, 2020 at 05:10:30AM +, Vasyl Gello wrote:
> Thanks for contributing the security release! I checked your changes and 
> pushed them to the team repo.
> I do not have an upload rights, so CCing Sebastian and Mattia.

Sure,

but could either of you do a bunch of housekeeping work as well, like:
 * bumping dh compat
 * drop --dbgsym-migration
 * drop the .menu files
 * would be awesome to have the copyright file rewrote using dep-5
 * 

Also, the commit adding the CVE patch mentions "partial fix", as does
the sec-tracker page.  Can anybody explain shortly what's with that,
where is the full fix (if there is), and how come the LTS upload claims
this to be fully fixed instead (CCing the LTS team and the uploader for
this).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#963583: sysdig: sysdig segfaults on start

[Adrian Bunk]

Control: reassign -1 libgrpc++1 1.26.0-3
Control: retitle -1 libgrpc++1 changes ABI without changing soname
Control: forwarded -1 https://github.com/grpc/grpc/issues/23205
Control: affects -1 src:sysdig

On Tue, Jun 23, 2020 at 06:59:25PM -0700, Dima Kogan wrote:
>...
>   $ sudo sysdig ...
>   sysdig: symbol lookup error: sysdig: undefined symbol: 
> _ZN9grpc_impl23CreateCustomChannelImplERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt10shared_ptrINS_18ChannelCredentialsEERKNS_16ChannelArgumentsE
> 
> This sounds like #955279, but even if it is, there should be a
> Conflicts, or something, to prevent me from getting into that state.
>...

The root problem is that libgrpc++ changes ABI without changing soname.

sysdig in unstable/testing is the only package in Debian that currently 
uses libgrpc++, which explains why the problem is not reported more often.

Anyone compiling own code against libgrpc++ in buster will run into
the same problem when upgrading to bullseye.

cu
Adrian

Bug#962221: Fixes for CVE-2020-13696 (#962221)

[Vasyl Gello]

Hi Mattia!

By partial I understood that upstream fixed the core part but the Debian patch 
sjould have been adapted to reflect new changes.
Jeremy, can you please correct me if I am wrong?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

July 6, 2020 6:58:05 PM UTC, Mattia Rizzolo  написав(-ла):
>On Mon, Jul 06, 2020 at 05:10:30AM +, Vasyl Gello wrote:
>> Thanks for contributing the security release! I checked your changes and 
>> pushed them to the team repo.
>> I do not have an upload rights, so CCing Sebastian and Mattia.
>
>Sure,
>
>but could either of you do a bunch of housekeeping work as well, like:
> * bumping dh compat
> * drop --dbgsym-migration
> * drop the .menu files
> * would be awesome to have the copyright file rewrote using dep-5
> * 
>
>Also, the commit adding the CVE patch mentions "partial fix", as does
>the sec-tracker page.  Can anybody explain shortly what's with that,
>where is the full fix (if there is), and how come the LTS upload claims
>this to be fully fixed instead (CCing the LTS team and the uploader for
>this).
>
>-- 
>regards,
>Mattia Rizzolo
>
>GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
>More about me:  https://mapreri.org : :'  :
>Launchpad user: https://launchpad.net/~mapreri  `. `'`
>Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#964404: quagga is replaced by frr

[Adrian Bunk]

Source: quagga
Version: 1.2.4-4
Severity: serious

The maintained fork from quagga that continues the zebra codebase is frr,
which is already in buster:
https://tracker.debian.org/pkg/frr

Additionally shipping quagga in bullseye might bring more confusion
than benefits.