Bug#926409: lintian: autopkgtest takes very long to finish

[Iain Lane]

On Wed, Jun 03, 2020 at 02:50:04AM +0200, Mattia Rizzolo wrote:
> On Wed, 3 Jun 2020, 1:09 am Felix Lechner, 
> ...
> > On Fri, Apr 5, 2019 at 4:33 AM Iain Lane  wrote:
> > >
> > > We do similar in some pkg-gnome packages, for example glib2.0 ships a
> > > -tests package that contains "installed tests" which are compiled as
> > > part of the package build and then executed during the autopkgtests.
> >
> > Should we ship all built test packages as part of our releases? I
> > can't think of a better way to close this bug.
> 
> 
> Now lintian autopkgtests take approximately 1 hour everywhere I checked.
> Honestly, I believe 1 hour to be acceptable.

It is broadly acceptable, but if you can reduce the time by assembling
artifacts in advance, I think that it is still worth doing to save time
and not repeat computation that doesn't need to be repeated.

As a bonus you're then not also testing the package build toolchain with
each Lintian CI run - you are (mostly) only testing Lintian itself.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#962096: debian/do-dfsg-tarball: use Version changlog field instead of grepping Changes field

[Paul Wise]

Source: fritzing
Version: 0.9.3b+dfsg-9
Severity: minor
Control: clone -1 -2
Control: reassign -2 src:fritzing-parts 0.9.3b-3

fritzing and fritzing-parts currently contain this line:

DFSG_NUM=$(dpkg-parsechangelog --show-field Changes --from ${VERSION} | grep 
^${NAME} | head -n 1 | grep -o "${VERSION}.*-" | grep -E -o "dfsg[[:digit:]]*" 
| sed 's/dfsg//')

A shorter way to write this is:

DFSG_NUM=$(dpkg-parsechangelog -S Version --from ${VERSION} | sed -n 
's/.*dfsg\([[:digit:]]*\).*/\1/p')

https://codesearch.debian.net/search?q=parsechangelog.*%28--show-field%7C-S%29.*Changes=0

In addition you could also make this simplification:

-NAME=$(dpkg-parsechangelog | sed -n 's/^Source: //p')
+NAME=$(dpkg-parsechangelog -S Source)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962105: znc: CVE-2020-13775

[Salvatore Bonaccorso]

Source: znc
Version: 1.8.0-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for znc.

CVE-2020-13775[0]:
| ZNC before 1.8.1-rc1 allows attackers to trigger an application crash
| (with a NULL pointer dereference) if echo-message is not enabled and
| there is no network.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13775
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13775
[1] https://github.com/znc/znc/commit/2390ad111bde16a78c98ac44572090b33c3bd2d8

Please adjust the affected versions in the BTS as needed, if my
understandig of the isuse is correctly then this was only introduced
in 1.8.0 while fixing another bug related to echo-messages, please
double check though.

Regards,
Salvatore

Bug#962105: znc: CVE-2020-13775

[Alexey Sokolov]

03.06.2020 11:25, Salvatore Bonaccorso пишет:
> Source: znc
> Version: 1.8.0-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerability was published for znc.
> 
> CVE-2020-13775[0]:
> | ZNC before 1.8.1-rc1 allows attackers to trigger an application crash
> | (with a NULL pointer dereference) if echo-message is not enabled and
> | there is no network.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2020-13775
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13775
> [1] https://github.com/znc/znc/commit/2390ad111bde16a78c98ac44572090b33c3bd2d8
> 
> Please adjust the affected versions in the BTS as needed, if my
> understandig of the isuse is correctly then this was only introduced
> in 1.8.0 while fixing another bug related to echo-messages, please
> double check though.

Correct. MITRE changed the suggested description and left that and a few
more details out. https://wiki.znc.in/ChangeLog/1.8.1 has a better text.

> 
> Regards,
> Salvatore
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Bug#960984: ITP: google-http-client-java -- Google HTTP Client Library for Java

[Sudip Mukherjee]

Hi Olek,

On Wed, Jun 3, 2020 at 8:30 AM Olek Wojnar  wrote:
>
> Hi Sudip,
>
> Thanks for taking a look!
>
> On Tue, Jun 2, 2020 at 11:03 AM Sudip Mukherjee  
> wrote:
>>
>>

>
>>
>> From a quick look at bazel
>> (https://github.com/bazelbuild/bazel/tree/master/third_party/api_client)
>> , it seems only "google-http-client" and "google-http-client-jackson2"
>> is needed. So, another quick look at the source code and it seems we
>> don't have "com.google.j2objc" and "io.opencensus". I think
>> com.google.j2objc can be ignored but we will need io.opencensus. And
>> you already have ITP for that. #959838. imho, "io.opencensus" needs to
>> be packaged before "google-http-client-java", and from that you will
>> mostly need "io.opencensus.common, io.opencensus.contrib and
>> io.opencensus.trace".
>
>
> Correct, those are the only two artifacts we need. The problem with the 
> dependencies is that opencensus depends on google-auth which in turn depends 
> on http-client-java. ;) Yay dependencies! :) So we need to figure out how to 
> either build http-client without opencensus or the other way around. Ideas 
> are very welcome!

Do you know which modules from google-auth you will need? I think thats #959830.


-- 
Regards
Sudip

Bug#962089: a shared library should not depend on a -dev package

[Matthias Klose]

Package: libspdlog1
Version: 1:1.5.0+ds-3ubuntu2
Severity: important

A shared library should not depend on a -dev package, however libspdlog1 depends
on libfmt-dev.

Bug#961053: transition: mumps petsc slepc

[Drew Parsons]

On 2020-05-30 16:58, Drew Parsons wrote:

On 2020-05-30 15:13, Sebastian Ramacher wrote:


Please go ahead with the uploads to unstable.

Cheers



Thanks Sebastian.  I'll proceed, starting with mumps.



Transition is all done (apart from siconos).

Drew

Bug#962123: roundcube: Cross-Site Scripting (XSS) vulnerability in template object 'username'

[Guilhem Moulin]

Source: roundcube
Severity: important
Tags: security

AFAICT no CVE was assigned for this yet.  1.2.x, 1.3.x and 1.4.x
branches are affected.  Upstream fix:

1.4.x 
https://github.com/roundcube/roundcubemail/commit/4beec65d40c5e5b1f2bace935c110baf05e10ae5
1.3.x 
https://github.com/roundcube/roundcubemail/commit/37e2bc745723ef6322f0f785aefd0b9313a40f19

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#962124: roundcube: Cross-Site Scripting (XSS) vulnerability via malicious XML messages

[Guilhem Moulin]

Source: roundcube
Severity: important
Tags: security

AFAICT no CVE was assigned for this yet.  1.2.x, 1.3.x and 1.4.x
branches are affected.  Upstream fix:

1.4.x 
https://github.com/roundcube/roundcubemail/commit/ccaccae6653031b809b4347a60021951e19a0e43
1.3.x 
https://github.com/roundcube/roundcubemail/commit/884eb611627ef2bd5a2e20e02009ebb1eceecdc3

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#868220: ifupdown should support vlan-aware bridges

[Santiago Garcia Mantinan]

Hi!

On Xuñ 02 2020, Gianluigi Tiesi wrote:
> Looks like bridge-utils already does it in:
> /lib/bridge-utils/ifupdown.sh
> 
> # Activate VLAN filtering on VLAN aware bridges   
>  
>   if [ "$IF_BRIDGE_VLAN_AWARE" = "yes" ]; then
> ip link set dev $IFACE type bridge vlan_filtering 1   
>  
>   else
> ip link set dev $IFACE type bridge vlan_filtering 0   
>  
>   fi
> 
> 
> the problem is I get operation not supported when setting vlan_filtering 0
> on my bridge, does the else really make sense here?

Well, this was added due to bugs.debian.org/950879 reported by Benedikt who
kindly supplied the patch, the patch didn't cause any trouble on the tests I
did and that's why I applied it like he sent it.

I have added Benedikt to my reply for him to comment on this.

As I understand it, Gianluigi, if we remove the else there we won't set vlan
filtering to 0 and thus you won't get the error, right?

We have two options here, one is to remove it and the other to send the
possible errors on the setting to 0 case to /dev/null.

As I see it, maybe the second option is better, as if one has set this to
yes and then sets it to no without rebooting, he wouldn't get the expected
behaviour.

Benedikt and Gianluigi, what do you think?

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#962091: RFS: xine-ui/0.99.12-1 [QA] -- xine video player, user interface

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xine-ui"

 * Package name: xine-ui
   Version : 0.99.12-1
   Upstream Author : xine-de...@lists.sf.net
 * URL : https://xine-project.org/
 * License : GPL-2+
 * Vcs : None
   Section : video

It builds those binary packages:

  xine-ui - xine video player, user interface (X11 gui)
  xine-console - xine video player, user interface

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

  https://mentors.debian.net/package/xine-ui

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

  dget -x
https://mentors.debian.net/debian/pool/main/x/xine-ui/xine-ui_0.99.12-1.dsc

Changes since the last upload:

   * QA upload.
   * New upstream release.
   * Orphan the package see: #881516
   * Update d/watch
   * d/copyright: rewrite using copyright-format 1.0 and add
 some missing attributions
   * d/rules
 - Change to dh-sequence
 - Add hardening options
 - Fix FTCBFS, original patch by Helmut Grohne Closes: #881790
   * d/control
 - Change to debhelper-compat
 - Bump debhelper to 13
 - Update Standards-Version to 4.5.0
 - Change to secure URI on homepage
 - Remove Vcs-* fields
 - Add Rules-Requires-Root: no
 - Update short description.
 - Remove unnecessary Depends field
   * Remove unused entry debian/source/include-binaries
   * Split xine-ui.mime into two files.
   * Remove whitespace from d/changelog
   * Add fix_macro_in_manpage.patch
   * Add fix_spelling_error.patch

I'm unsure about the invocation of the postinst script, though the end
result should be correct.

Regards,
Håvard

Bug#962083: pgloader: Please package the newest version

[Cyril Chaboisseau]

Package: pgloader
Version: 3.6.1-1.pgdg+1
Severity: wishlist
Tags: upstream

A newest version (3.6.2) is available, which corrects a lot of
issues/bugs, including the compatibility with PostgreSQL 12
(for the moment, pgloader 3.6.1 doesn't work with pg v11)


Thank you

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

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

Versions of packages pgloader depends on:
ii  freetds-dev  1.1.6-1.1
ii  libc62.30-8
ii  libssl1.11.1.1g-1
ii  zlib1g   1:1.2.11.dfsg-2

pgloader recommends no packages.

pgloader suggests no packages.

-- no debconf information

Bug#960301: cannot reproduce issue anymore

[Andreas B. Mundt]

Hi Mike,

I reported problems with webRTC above (related or not with the
'microphone'-issue at hand).  However, somehow the problem has
disappeared here after one of the many upgrades (not the firefox-esr
package).  I tried to figure out the package that made the difference,
but there where to many changes.  So for me, anything works fine
again.

Thank you for your work,

  Andi

Bug#962086: freecard: FTBFS with boost 1.71

[Sebastian Ramacher]

Source: freecad
Version: 0.8.14+dfsg2-3
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)
User: team+bo...@tracker.debian.org
Usertags: boost1.71
Control: block 961995 by -1

libboost-signals-dev was dropped in 1.71 and so freecad no longer
builds.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962085: bcalm,kissplice: both ship /usr/bin/bcalm

[Andreas Beckmann]

Package: bcalm,kissplice
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 bcalm/2.2.2-1.1
Control: found -1 kissplice/2.5.1-1

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package kissplice.
  Preparing to unpack .../kissplice_2.5.1-1_amd64.deb ...
  Unpacking kissplice (2.5.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/kissplice_2.5.1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/bcalm', which is also in package bcalm 
2.2.2-1.1
  Errors were encountered while processing:
   /var/cache/apt/archives/kissplice_2.5.1-1_amd64.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/bin/bcalm

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

Possible solution:
 * kissplice stops shipping /usr/bin/bcalm
 * bcalm adds Breaks+Replaces: kissplice (<< 2.5.1-2~) (assuming the
   fixing upload of kissplice is 2.5.1-2)

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html


bcalm=2.2.2-1.1_kissplice=2.5.1-1.log.gz
Description: application/gzip

Bug#962088: miniupnpd: stronger sandbox is possible in systemd service file

[Ryutaroh Matsumoto]

Package: miniupnpd
Version: 2.1-6.1
Severity: wishlist
Tags: patch

Dear Maintainers,

I am using the latest git version of miniupnpd,
with nftables backend instead of iptables used in the Debian package.
A much stronger sandboxing in miniupnpd.service works for me, shown below.
Systemd service file in the Debian package can also use a stronger sandbox.

Also, "Type=exec" seems better than "Type=simple" used in the Debian package.

[Unit]
Description=UPnP Internet Gateway Device Daemon
Documentation=man:miniupnpd(8)
After=network-online.target minissdpd.service

[Service]
TasksMax=2 #for /etc/miniupnpd/nft_removeall.sh. miniupnpd alone needs only 1.
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BROADCAST CAP_NET_RAW CAP_SYSLOG
MountAPIVFS=yes
NoNewPrivileges=yes
PrivateMounts=yes
PrivateDevices=yes
PrivateTmp=yes
MemoryDenyWriteExecute=yes
ProtectSystem=full
ProtectHome=yes
ProtectHostname=yes
ProtectClock=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
ProtectControlGroups=yes
LockPersonality=yes
RestrictRealtime=yes
RestrictNamespaces=yes
RestrictSUIDSGID=yes

Type=exec
ExecStartPre=/etc/miniupnpd/nft_init.sh -i ip6tnl1
ExecStart=/usr/sbin/miniupnpd -d -f /etc/miniupnpd/miniupnpd.conf
ExecStopPost=/etc/miniupnpd/nft_removeall.sh -i ip6tnl1

[Install]
WantedBy=multi-user.target


Best regards, Ryutaroh Matsumoto

Bug#962087: fmtlib should build a shared library

[Matthias Klose]

Package: src:fmtlib
Version: 6.1.2+ds-2
Severity: important
Tags: sid bullseye

fmtlib should build a shared library. Or else every package linking against this
library needs a Built-Using attribute to track the static linking.

Bug#911415: Related items

[Philipp Klaus Krause]

Related items:

Upstream flex change:
https://github.com/westes/flex/commit/f863c9490e6912ffcaeb12965fb3a567a10745ff

Upstream flex issue:
https://github.com/westes/flex/issues/448

SDCC bug:
https://sourceforge.net/p/sdcc/bugs/3012/

libguestfs also was affected:
https://www.redhat.com/archives/libguestfs/2016-July/msg00252.html

Bug#959558: this fix breaks things

[Dmitry Shachnev]

Hi Rebecca!

On Sat, May 30, 2020 at 10:37:02PM +0100, Rebecca N. Palmer wrote:
> This fix causes Sphinx to fail if documenting an object whose __getattr__
> fails, e.g. flask.request.  This causes at least snakemake to FTBFS.
>
> Details and fix:
> https://github.com/sphinx-doc/sphinx/pull/7520
>
> A workaround in failing packages is to add
> autodoc_default_options = {'exclude-members': 'request'}
> (or whatever object triggers the error) to conf.py, but if there are more
> than just snakemake, I suggest instead fixing sphinx itself.

Thanks for the heads up, fixed in 2.4.3-4:

https://tracker.debian.org/news/1150253/accepted-sphinx-243-4-source-into-unstable/

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#962099: patchutils: espdiff is placed under /usr/games, which doesn't show any relationship with any game

[Xingyou Chen]

Package: patchutils
Version: 0.3.4-2+b1
Severity: minor

Dear Maintainer,

patchutils is for general use, and not game specific,
been placed in /usr/games makes espdiff somehow odd.



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

Kernel: Linux 5.7.0-rockwork+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages patchutils depends on:
ii  debianutils  4.11
ii  libc62.30-8
ii  patch2.7.6-6
ii  perl 5.30.2-1

patchutils recommends no packages.

patchutils suggests no packages.

-- no debconf information

Bug#962104: python-pweave fails it's autopkg tests

[Matthias Klose]

Package: src:python-pweave
Version: 0.25-2
Severity: serious
Tags: sid bullseye

python-pweave fails it's autopkg tests

[...]
Reading state information...
E: Unable to locate package texlive-generic-extra
command1 FAIL badpkg
blame: python-pweave
badpkg: Test dependencies are unsatisfiable. A common reason is that your
testbed is out of date with respect to the archive, and you need to use a
current testbed or run apt-get update or use -U.
autopkgtest [19:18:27]:  summary
command1 FAIL badpkg
blame: python-pweave

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Anthony Perkins]

On 03/06/2020 11:10, Geert Stappers wrote:
> You have a sponsor, me.
> However June is already booked.
> Poke me end of this month.
>
> If you need a git repository at Salsa, let me know.

Thank you Geert, for the sponsorship offer. It is most appreciated.


On 03/06/2020 11:00, Andrej Shadura wrote:
> I’m wondering in what ways is it better than Solaar already in Debian?
> Do we need to have both?
>
> https://pwr-solaar.github.io/Solaar/

Andrej, apologies, I hadn't found Solaar before your email --
instructions I'd seen online suggested ltunify and I saw it wasn't packaged.

Solaar does seem to be more regularly maintained than ltunify, so maybe
ltunify isn't needed in Debian after all.


Kind regards,
Anthony

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Geert Stappers]

On Wed, Jun 03, 2020 at 11:43:24AM +0100, Anthony Perkins wrote:
> On 03/06/2020 11:00, Andrej Shadura wrote:
> > I’m wondering in what ways is it better than Solaar already in Debian?
> > Do we need to have both?
> >
> > https://pwr-solaar.github.io/Solaar/

https://packages.debian.org/bullseye/solaar
 

> Andrej, apologies, I hadn't found Solaar before your email --
> instructions I'd seen online suggested ltunify and I saw it wasn't packaged.
> 
> Solaar does seem to be more regularly maintained than ltunify,
> so maybe ltunify isn't needed in Debian after all.

You  decide.


Groeten
Geert Stappers
-- 
} Do we need both?
clang/llvm   did  improve  gcc


signature.asc
Description: PGP signature

Bug#962121: ITP: bbhash -- bloom-filter based minimal perfect hash function library

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: bbhash -- bloom-filter based minimal perfect hash function library
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: bbhash
  Version : 1.0.0
  Upstream Author : Guillaume Rizk
* URL : https://github.com/rizkg/BBHash
* License : MIT
  Programming Lang: C
  Description : bloom-filter based minimal perfect hash function library
 BBHash is a simple library for building minimal perfect hash
 function. It is designed to handle large scale datasets. The function
 is just a little bit larger than other state-of-the-art libraries, it
 takes approximately 3 bits / elements (compared to 2.62 bits/elem for
 the emphf lib), but construction is faster and does not require
 additional memory.

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

Bug#962084: Adding buster-backport to apt sources on install seems wrong

[Christian Ehrhardt]

Package: plinth
Version: 20.10
severity: serious

Hi,
running into issues today I realized that the new freedombox 20.10 places
this file on disk:
$ cat /etc/apt/sources.list.d/freedombox2.list
  # This file is managed by FreedomBox, do not edit.
  # Allow carefully selected updates to 'freedombox' from backports.
  deb http://deb.debian.org/debian buster-backports main
  deb-src http://deb.debian.org/debian buster-backports main

IMHO a package should not on-install mess with apt sources. Users just
don't expect this or the follow on consequences that can happen.
For example you are pinning python packages from backports which I'd expect
might lead to quite some dependency hell with other things installed.

I was facing this in Ubuntu where it is even more wrong and essentially
breaking `apt update`, but IMHO it is even wrong if not outright forbidden
by some policy in Debian. I mean adding 'buster-backports' and pinning to
them in e.g. 'sid' - to me that sounds like calling for trouble.

I'd ask you to reconsider and remove this behavior. If you want/need to
keep it then maybe at least consider adding a skip if `dpkg-vendor
--derives-from Ubuntu` is true. Would that work better for you?

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#962093: Gimp fails to start

[Vitaliyi]

Package: gimp
Version: 2.10.18-1


gimp: /usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0: no version information
available (required by gimp)
gimp: /usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0: no version information
available (required by /usr/lib/libgimpwidgets-2.0.so.0)
gimp: /usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0: no version information
available (required by /usr/lib/libgimpcolor-2.0.so.0)
gimp: symbol lookup error: gimp: undefined symbol: gegl_rectangle_subtract

Bug#956734: gnucobol FTCBFS: lots of AC_RUN_IFELSE

[Petter Reinholdtsen]

Dear Helmut,

Do you have time to test version 3.0~rc1-2 to see if it is easier to
cross-build?

-- 
Happy hacking
Petter Reinholdtsen

Bug#962095: qosmic ftbfs with ICU 67

[Matthias Klose]

Package: src:qosmic
Version: 1.6.0-2
Severity: serious
Tags: sid bullseye

qosmic ftbfs with ICU 67:

[...]
In file included from /usr/include/unicode/uenum.h:23,
 from /usr/include/unicode/ucnv.h:53,
 from /usr/include/libxml2/libxml/encoding.h:31,
 from /usr/include/libxml2/libxml/parser.h:810,
 from /usr/include/flam3.h:24,
 from src/flam3util.h:27,
 from src/genomevector.h:24,
 from src/xfedit.h:32,
 from src/xfedit.cpp:26:
/usr/include/unicode/ucnv.h:585:1: error: conflicting declaration of C function
‘void icu_67::swap(icu_67::LocalUConverterPointer&,
icu_67::LocalUConverterPointer&)’
  585 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUConverterPointer, UConverter, 
ucnv_close);
  | ^~~
/usr/include/unicode/uenum.h:68:1: note: previous declaration ‘void
icu_67::swap(icu_67::LocalUEnumerationPointer&, 
icu_67::LocalUEnumerationPointer&)’
   68 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUEnumerationPointer, UEnumeration,
uenum_close);
  | ^~~
make[1]: *** [Makefile:1764: .obj/triangle.o] Error 1
make[1]: *** [Makefile:1854: .obj/renderthread.o] Error 1
make[1]: *** [Makefile:1866: .obj/genomecolorselector.o] Error 1
make[1]: *** [Makefile:1731: .obj/xfedit.o] Error 1
make[1]: Leaving directory '/packages/tmp/qosmic-1.6.0'
dh_auto_build: error: make -j8 returned exit code 2

Bug#943981: Proposal: Switch to cgroupv2 by default

[Ryutaroh Matsumoto]

Hi Michael,

I am replying to your email on April.

From: Michael Biebl 
Subject: Re: Bug#943981: Proposal: Switch to cgroupv2 by default
Date: Thu, 23 Apr 2020 12:52:48 +0200
> (once lxc v4 enters testing)? For me lxc is the main blocker and we
> probably can't wait for docker (I would document that in the release
> notes / NEWS entry instead what docker users can do)

lxc 4 is blocked to migrate to testing,  because lxc 4 does not work well under
docker
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961584

According to 961584, Salsa CI uses Docker.
If change to pure cgroup2 of systemd breaks docker in Salsa CI
(I think it will), change to pure cgroup2 does not seem to be accepted.

Best regards, Ryutaroh

Bug#962085: [Debian-med-packaging] Bug#962085: bcalm, kissplice: both ship /usr/bin/bcalm

[David Parsons]

Dear Andreas,

I know I am usually not very involved and I'm sorry about that.

I am however exchanging e-mails with upstream regarding all these issues 
right now, I will keep in touch


Best,
David

Le 03/06/2020 à 11:20, Andreas Tille a écrit :

Hi Andreas,

thanks for spotting this.

On Wed, Jun 03, 2020 at 09:41:12AM +0200, Andreas Beckmann wrote:

Package: bcalm,kissplice
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 bcalm/2.2.2-1.1
Control: found -1 kissplice/2.5.1-1
...
Possible solution:
  * kissplice stops shipping /usr/bin/bcalm
  * bcalm adds Breaks+Replaces: kissplice (<< 2.5.1-2~) (assuming the
fixing upload of kissplice is 2.5.1-2)

Seems since last version of kissplice it seems to include bcalm.
@Nilesh: Would you mind sorting out with upstream which bcalm
version is the one that will be actively supported?  Or is it
just a code copy included into kissplice?  We also should remove
the code copy of gatb-core and rather link against the Debian
packaged lib.

Kind regards

Andreas.


--
logo inria

*David Parsons* 
Service d'Expérimentation et de Développement

Antenne Inria Lyon - La Doua
Bâtiment CEI-2
56 Boulevard Niels Bohr
CS 52132
69603 Villeurbanne
Tel : +33 (0)4 72 43 74 97

*www.inria.fr *

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Anthony Perkins]

Package: wnpp
Severity: wishlist
Owner: Anthony Perkins 

* Package name: ltunify
  Version : 0.2
  Upstream Author : Peter Wu 
* URL : https://lekensteyn.nl/logitech-unifying.html
* License : GPL-3.0+
  Programming Lang: C
  Description : Pair and manage Logitech devices that use the unifying 
receiver

Logitech wireless peripherals use a 'Unifying' receiver. This
utility manages the receiver, allowing the user to pair new
devices and remove unwanted ones.

I require a sponsor, but intend to maintain the package myself.

It had a release v0.2 roughly six years ago, and had a few
additional patches in the following year but no new release. I
will include a few of these patches as they fix bugs in the
application.

Bug#962101: akonadi fully rescans after each activity

[Lars Dölle]

Package: kmail
Version: 4:20.04.1-1
Severity: important

Hi,

since a few days i experience quite some problems with kmail.

The symptom is, that after each activity (sending, receiving, deleting?, 
etc.), akonadi apparently completely rescans the contents of the mail folder. 
This takes a minute or two and i sometimes even need to reboot the machine to 
get kmail back on the feet again.

The related process is:

| /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_0

This might well be an upgrade problem. I tried

| $ akonadictl fsck

But this did not improve matters.

If anyone knows a workaround or fix, please let me know.

Kind regards, thanks

  Lars

Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package

[Lev Lamberov]

Hi Jonas,

Пн 25 мая 2020 @ 12:32 Jonas Smedegaard :

> Quoting Lev Lamberov (2020-05-25 12:19:07)
>> I've just got some news from Jan Wielemaker. The next stable release 
>> of swi-prolog, branch 8.2, is almost ready. How are your experiments 
>> with depending on swi-prolog virtual packages going? I would like to 
>> package the current latest version and upload it into unstable for 
>> testing it with more installations, just to make sure there are no 
>> serious bugs and blockers for the release of 8.2 branch.
>
> Sorry, I have not played with it at all, yet.
>
> Hope to find/make time for it later today.  Will let you know when I do!

A couple days ago I uploaded new stable release of swi-prolog, 8.2.0,
into unstable. This branch of swi-prolog will stay for a long period of
time. Quite possible that it will be in Debian stable, since I don't
think we'll see another stable release of swi-prolog before the coming
freeze.

Could you please upload eye rebuilt against swi-prolog 8.2.0? Currently
swi-prolog are going to be removed from testing on June 22 because of RC
bug in 8.1.29, and there are some other packages depending on swi-prolog
which are going to be removed too.

Also, it would be nice if you can switch dependency on swi-prolog to one
of its virtual packages. There are swi-prolog-abi-2-67-4369f15b-de23899e
and swi-prolog-abi-foreign-2 provided by swi-prolog-core. You may find
more information about ABI versions in its NEWS.Debian and mentioned
there upstream documentation.

Cheers!
Lev

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Geert Stappers]

On Wed, Jun 03, 2020 at 10:50:32AM +0100, Anthony Perkins wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Anthony Perkins 
> 
> * Package name: ltunify
>   Version : 0.2
>   Upstream Author : Peter Wu 
> * URL : https://lekensteyn.nl/logitech-unifying.html
> * License : GPL-3.0+
>   Programming Lang: C
>   Description : Pair and manage Logitech devices that use the unifying 
> receiver
> 
> Logitech wireless peripherals use a 'Unifying' receiver. This
> utility manages the receiver, allowing the user to pair new
> devices and remove unwanted ones.
> 
> I require a sponsor, but intend to maintain the package myself.

You have a sponsor, me.
However June is already booked.
Poke me end of this month.
 
> It had a release v0.2 roughly six years ago, and had a few
> additional patches in the following year but no new release. I
> will include a few of these patches as they fix bugs in the
> application.
 
If you need a git repository at Salsa, let me know.

 
Groeten
Geert Stappers
DD

P.S.
Hey Lekensteyn
-- 
Silence is hard to parse

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Anthony Perkins]

On 03/06/2020 12:06, Geert Stappers wrote:
> On Wed, Jun 03, 2020 at 11:43:24AM +0100, Anthony Perkins wrote:
>> On 03/06/2020 11:00, Andrej Shadura wrote:
>>> I’m wondering in what ways is it better than Solaar already in Debian?
>>> Do we need to have both?
>>>
>>> https://pwr-solaar.github.io/Solaar/
> 
> https://packages.debian.org/bullseye/solaar
>  
> 
>> Andrej, apologies, I hadn't found Solaar before your email --
>> instructions I'd seen online suggested ltunify and I saw it wasn't packaged.
>>
>> Solaar does seem to be more regularly maintained than ltunify,
>> so maybe ltunify isn't needed in Debian after all.
> 
> You  decide.

Having looked into Solaar, I like the look of it, and it does have more
features. However, it is a Python Gtk application and requires Gtk to build.

I therefore believe there might still be a use for ltunify, as it is a
very small (35 kB) console application that has almost no build
dependencies.

I believe this might be a good argument for including both. I have done
the packaging work already in my personal Gitea repo. I can push this to
Salsa for review if that would be useful.

Kind regards,
Anthony

Bug#948706: Polite ping

[Benedikt Spranger]

Hi,

are there any updates or is more help needed?

Regards
Benedikt Spranger

Bug#652465: apt: --fix-policy not documented in man page

[Baptiste BEAUPLAT]

Hi David,

Thank you for taking the time to reply. I now that must be a low
priority bug on apt's list.

On 6/2/20 4:48 PM, David Kalnischkies wrote:
> Hi,
> 
> On Sun, May 31, 2020 at 11:45:23AM +0200, Baptiste BEAUPLAT wrote:
>> On Sat, 17 Dec 2011 15:56:22 +0200 =?utf-8?q?Martin-=C3=89ric_Racine?=
>>  wrote:
>>> The --fix-policy option is not documented in the apt-get man page.
>>
>> Please consider applying the following patch that documents the
>> --fix-policy option.
> 
> The problem with this option and hence the documentation is that
> "policy" is a very bad word here. I said on IRC then I mentioned
> & explained that option that it is 'apt-speak', but I meant that this is
> something only the code & debug messages use – and even those aren't
> uniformly using it as the code calls these dependencies also "important"
> (vs. "critical"). In the code this makes sort of sense, but I wouldn't
> like to expose a user to the notion of "important" as we use that word
> for yet more other confusing things (which is probably why the code
> isn't using it all the time either).
> 
> From a user point of view "policy" refers to apt_preferences, at least
> that is what we have taught them via "apt{-cache,} policy" for years and
> the code happily uses it in that sense everywhere as well.
> 
> A --fix-policy suggests hence it does something with apt_preferences
> which it doesn't as the "configured policy" there is not at all about
> Recommends/Suggests.

I feel like I understand a bit better the issue here. Basically user and
technical (in-code) definition of policy is different. That option
should not be called like that.

> So, instead of documenting, I would like to "remove" this option:
> The functionality as-is is not that great as it is all-or-nothing which
> is rarely useful. I would prefer a command which will act on given
> packages instead (and only if non are given on all) with a more sensible
> name.

I do think there is a use case here. I'm sure some of Debian
contributors run sid and end-up in the same situation I ran into, where
you have a couple recommends that got removed and you wish to fix that.

That feature specifically reminds me of fsck commands where it allows
you to get back to a coherent system.

I do agree that having the option to specify the package would be very
nice, but I think removing the possibility to do that on all packages
would be a loss.

> Sadly I have no idea how to call it.
> I would have called it 'reinstall' as that is sort-of what the code
> does… but that should make it obvious that I shouldn't be naming things.
> 
> (Famous last words: On the upside, the code for that shouldn't be hard)

Here is a couple of idea on the option naming:

--restore, I like this one as the option effectively restore the
packages in the state that they should be.
--ensure, same idea as behind restore.
--check or --verify, Not so sure about that one, it implies that no
action is done which is not the case.

> Sidenote: "configured policy" suggests there is something you can
> configure far above "install recommends". More like "install recommends
> if they are related to bluetooth, not related to gnome and included in
> the last stable release" – that would be a handy policy sometimes, but
> I don't see us getting there any time soon. And even then --fix-policy
> would need a few changes….
> 
> 
> Beste regards
> 
> David Kalnischkies

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#962115: Updating the sibsim4 Uploaders list

[Tobias Frost]

Source: sibsim4
Version: 0.20-4
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the sibsim4 package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962111: Updating the pngcrush Uploaders list

[Tobias Frost]

Source: pngcrush
Version: 1.8.13-0.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the pngcrush package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962112: Updating the optipng Uploaders list

[Tobias Frost]

Source: optipng
Version: 0.7.7-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the optipng package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962107: Updating the gff2ps Uploaders list

[Tobias Frost]

Source: gff2ps
Version: 0.98l-2 0.98l-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the gff2ps package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962110: Updating the imagemagick Uploaders list

[Tobias Frost]

Source: imagemagick
Version: 8:6.9.10.23+dfsg-2.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the imagemagick package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962108: Updating the gdpc Uploaders list

[Tobias Frost]

Source: gdpc
Version: 2.2.5-9 2.2.5-10
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the gdpc package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962114: Updating the pngquant Uploaders list

[Tobias Frost]

Source: pngquant
Version: 2.12.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the pngquant package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962116: Updating the emboss Uploaders list

[Tobias Frost]

Source: emboss
Version: 6.6.0+dfsg-7
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the emboss package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962113: Updating the gff2aplot Uploaders list

[Tobias Frost]

Source: gff2aplot
Version: 2.0-11
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the gff2aplot package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962109: Updating the autodocksuite Uploaders list

[Tobias Frost]

Source: autodocksuite
Version: 4.2.6-6 4.2.6-7
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the autodocksuite package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#962117: Updating the sim4 Uploaders list

[Tobias Frost]

Source: sim4
Version: 0.0.20121010-5
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the sim4 package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#961317: issue very rare or triggered by network scaners?

[Andreas B. Mundt]

Control: severity -1 normal

Hi,

since opening this bug we have monitoring in place and the issue has
not been observed again yet.  Right now we have vacancies and little
traffic.  However, I downgrade the severity to normal.

I could imagine the issue has been triggered by some kind of strange
port scanning, as it happend on several machines around the same time.
I follow up on this bug if we see it again.

Regards,

  Andi

Bug#953686: Add support for list-table :widths: and :header-rows: to rst2html?

[Dmitry Shachnev]

On Wed, Jun 03, 2020 at 07:45:06AM +0200, Petter Reinholdtsen wrote:
> [Dmitry Shachnev]
> > I think the problem here is the indentation. The example in documentation 
> > [1]
> > has the same indent level for directive options and for the content.
>
> Aha.  But as far as I can tell from the specification in 
>  https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#field-lists
>  >
> and
>  https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#directives 
> >
> there is no requirement on how much indentation is used for directive
> options, but perhaps I am reading it wrong.  Do you know why the
> rst2html tool believe there is, while pandoc and xmlto do not?  Perhaps
> they all should be made to agree on the syntax...

The specification also says [1]:

| Several constructs begin with a marker, and the body of the construct
| **must** be indented relative to the marker.

(emphasis mine)

| For constructs using simple markers (bullet lists, enumerated lists,
| footnotes, citations, hyperlink targets, directives, and comments), the
| level of indentation of the body is determined by the position of the
| first line of text, which begins on the same line as the marker.

If I read it correctly, this means that if your directive starts with
".. list-table::", the content should be aligned under the "l" letter,
i.e. indented with three spaces.

The directives syntax section [2] also has the following diagram:

+---+---+
| ".. " | directive type "::" directive |
+---+ block |
|   |
+---+

which confirms my hypothesis. By chance, your table indented with two spaces
does not cause syntax errors, but you should not rely on that.

In any case, docutils/rst2html is the reference implementation, so I would
say a valid markup is markup that is correctly parsed by docutils.

Please close this bug if you agree with me.

[1]: 
https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#indentation
[2]: https://docutils.sourceforge.io/docs/ref/rst/directives.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#962098: RM: python3.7, superseded by python3.8

[Matthias Klose]

Package: ftp.debian.org

Please remove python3.7, superseded by python3.8, and not a supported python3
version anymore.

Bug#942915: ca-certificates: Python2 removal in sid/bullseye

[Gianfranco Costamagna]

control: tags -1 patch

Since the Ubuntu patch is really trivial, I don't see any reason for delaying 
this more, specially because this is a core-component

diff -pruN 20190110/debian/changelog 20190110ubuntu1/debian/changelog
--- 20190110/debian/changelog   2019-01-11 01:31:31.0 +
+++ 20190110ubuntu1/debian/changelog2020-03-30 10:09:50.0 +
@@ -1,3 +1,9 @@
+ca-certificates (20190110ubuntu1) focal; urgency=medium
+
+  * Build using python3.
+
+ -- Matthias Klose   Mon, 30 Mar 2020 12:09:50 +0200
+
 ca-certificates (20190110) unstable; urgency=high
 
   * debian/control:
diff -pruN 20190110/debian/control 20190110ubuntu1/debian/control
--- 20190110/debian/control 2019-01-11 01:31:31.0 +
+++ 20190110ubuntu1/debian/control  2020-03-30 10:09:42.0 +
@@ -5,7 +5,7 @@ Maintainer: Michael Shuler ,
Thijs Kinkhorst 
 Build-Depends: debhelper-compat (= 12), po-debconf
-Build-Depends-Indep: python, openssl
+Build-Depends-Indep: python3, openssl
 Standards-Version: 4.3.0.1
 Vcs-Git: https://salsa.debian.org/debian/ca-certificates.git
 Vcs-Browser: https://salsa.debian.org/debian/ca-certificates
diff -pruN 20190110/mozilla/certdata2pem.py 
20190110ubuntu1/mozilla/certdata2pem.py
--- 20190110/mozilla/certdata2pem.py2019-01-11 01:31:31.0 +
+++ 20190110ubuntu1/mozilla/certdata2pem.py 2020-03-30 10:09:28.0 
+
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 # vim:set et sw=4:
 #
 # certdata2pem.py - splits certdata.txt into multiple files
diff -pruN 20190110/mozilla/Makefile 20190110ubuntu1/mozilla/Makefile
--- 20190110/mozilla/Makefile   2018-10-13 14:07:11.0 +
+++ 20190110ubuntu1/mozilla/Makefile2020-03-30 10:09:50.0 +
@@ -3,7 +3,7 @@
 #
 
 all:
-   python certdata2pem.py
+   python3 certdata2pem.py
 
 clean:
-rm -f *.crt

On Wed, 23 Oct 2019 02:33:19 + mo...@debian.org wrote:
> Source: ca-certificates
> Version: 20190110
> 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
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests (the specific reason can be found searching this
> source package in
> https://people.debian.org/~morph/mass-bug-py2removal_take2.txt ).
> Please stop using Python2, and fix this issue by one of the following
> actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.
> 
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
> 
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.
> 
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
> 
> 
> 

Bug#962090: libtorrent-rasterbar: Can't exec "pyversions": No such file or directory at /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 124.

[Sebastian Ramacher]

Source: libtorrent-rasterbar
Version: 1.2.5-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

libtorrent-rasterbar currently fails to build with:
| Can't exec "pyversions": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 124.
| dh_auto_clean: error: failed to run pyversions
| make[1]: *** [debian/rules:56: override_dh_auto_clean] Error 25

See
https://buildd.debian.org/status/fetch.php?pkg=libtorrent-rasterbar=amd64=1.2.5-1%2Bb2=1591121318=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962092: meson: Link with static lib instead of shared one with boost 1.71

[Christian Marillat]

Package: meson
Version: 0.54.2-1
Severity: normal

Dear Maintainer,

I'm not sure if meson is the guilty but,
when i try to build packages with boost 1.71 and meson
the build fail with :

c++  -o libeedi3m.so 'eedi3m@sha/EEDI3_EEDI3.cpp.o' 
'eedi3m@sha/EEDI3_vectorclass_instrset_detect.cpp.o' 
'eedi3m@sha/EEDI3_EEDI3_SSE2.cpp.o' 'eedi3m@sha/EEDI3_EEDI3CL.cpp.o' 
'eedi3m@sha/EEDI3_EEDI3CL_SSE2.cpp.o' -Wl,--as-needed 
-Wl,--allow-shlib-undefined -shared -fPIC -Wl,--start-group 
-Wl,-soname,libeedi3m.so -g -O2 -fdebug-prefix-map=/src/vapoursynth-eedid3-4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
libsse4.a libavx.a libavx512.a /usr/lib/x86_64-linux-gnu/libOpenCL.so 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.a 
/usr/lib/x86_64-linux-gnu/libboost_system.a -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/' 
-Wl,-rpath-link,/src/vapoursynth-eedid3-4/obj-x86_64-linux-gnu/
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_filesystem.a(operations.o): 
relocation R_X86_64_PC32 against symbol 
`_ZN5boost6system6detail10cat_holderIvE24system_category_instanceE' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

Normally the build should be :

[12/12] c++  -o libeedi3m.so 'eedi3m@sha/EEDI3_EEDI3.cpp.o' 
'eedi3m@sha/EEDI3_vectorclass_instrset_detect.cpp.o' 
'eedi3m@sha/EEDI3_EEDI3_SSE2.cpp.o' 'eedi3m@sha/EEDI3_EEDI3CL.cpp.o' 
'eedi3m@sha/EEDI3_EEDI3CL_SSE2.cpp.o' -Wl,--as-needed -shared -fPIC 
-Wl,--start-group -Wl,-soname,libeedi3m.so -g -O2 
-fdebug-prefix-map=/build/vapoursynth-eedid3-dmo-4=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z,relro libsse4.a libavx.a libavx512.a 
/usr/lib/x86_64-linux-gnu/libOpenCL.so -lboost_filesystem -lboost_system 
-Wl,--end-group '-Wl,-rpath,$ORIGIN/' 
-Wl,-rpath-link,/build/vapoursynth-eedid3-dmo-4/obj-x86_64-linux-gnu/

Link against -lboost_filesystem -lboost_system in the correct build versus
/usr/lib/x86_64-linux-gnu/libboost_filesystem.a and
/usr/lib/x86_64-linux-gnu/libboost_system.a

Packaging source is here :

https://www.deb-multimedia.org/pool/main/v/vapoursynth-eedid3-dmo/vapoursynth-eedid3-dmo_4-dmo1.debian.tar.xz
https://www.deb-multimedia.org/pool/main/v/vapoursynth-eedid3-dmo/vapoursynth-eedid3-dmo_4-dmo1.dsc
https://www.deb-multimedia.org/pool/main/v/vapoursynth-eedid3-dmo/vapoursynth-eedid3-dmo_4.orig.tar.xz

Christian

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

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

Versions of packages meson depends on:
ii  ninja-build  1.10.0-1
ii  python3  3.8.2-3

meson recommends no packages.

meson suggests no packages.

-- no debconf information

Bug#962045: patch

[di dit]

Here are 2 upstream fixes for the 2 issues:

https://github.com/gramps-project/gramps/pull/1052
https://github.com/gramps-project/gramps/pull/1031

Regards

Bug#962094: diploma: missing dirs in examples

[alberto]

Package: diploma
Version: 1.2.15+nmu1
Severity: normal

Dear Maintainer,

in diploma_1 tar some directories necessary to run 'make' are missing:
- fig
- bin
- res


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

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

diploma depends on no packages.

diploma recommends no packages.

Versions of packages diploma suggests:
ii  clang-6.0 [c-compiler]   1:6.0.1-14.1
ii  clang-7 [c-compiler] 1:7.0.1-12
ii  gcc [c-compiler] 4:9.2.1-3.1
ii  gcc-9 [c-compiler]   9.3.0-13
ii  gv   1:3.7.4-2+b1
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  plotutils2.6-10
ii  texlive-latex-base   2020.20200522-1
ii  wzip 1.1.5+b1

-- no debconf information

Bug#962085: bcalm, kissplice: both ship /usr/bin/bcalm

[Andreas Tille]

Hi Andreas,

thanks for spotting this.

On Wed, Jun 03, 2020 at 09:41:12AM +0200, Andreas Beckmann wrote:
> Package: bcalm,kissplice
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> Control: found -1 bcalm/2.2.2-1.1
> Control: found -1 kissplice/2.5.1-1
> ...
> Possible solution:
>  * kissplice stops shipping /usr/bin/bcalm
>  * bcalm adds Breaks+Replaces: kissplice (<< 2.5.1-2~) (assuming the
>fixing upload of kissplice is 2.5.1-2)

Seems since last version of kissplice it seems to include bcalm.
@Nilesh: Would you mind sorting out with upstream which bcalm
version is the one that will be actively supported?  Or is it
just a code copy included into kissplice?  We also should remove
the code copy of gatb-core and rather link against the Debian
packaged lib.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#947589: wicd-gtk: [experimental] wicd-gtk probably broken: no GTK dependency, still uses 'import gtk'

[Guido Maria Serra]

guys, quick heads up... I could not progress on this topic due to lack
of experience on GTK
anyone willing to help? 
https://git.launchpad.net/wicd/log/?h=gtk_Debian_Bug%23947589
best,GMS
Il giorno mar, 31/03/2020 alle 23.01 +0200, Guido Maria Serra ha
scritto:
> Hi Moritz,I followed your recommendation and I got up to here
> https://git.launchpad.net/wicd/commit/?h=gtk_Debian_Bug%23947589=358f5f11c64ed09838c607bf5c64d35b74c0ca75
> Though I do now have a problem of testing now, as there are neither
> gtk based tests, neither a way to test without involving my os...I've
> tried some symlinking inside  /usr/share/wicd/gtk/ as wicd.ui gets
> copied from the data/ folder within the source code there.
> Now, if anybody has an idea or a system that he/she is fine to break
> for testing... get in contact with me
>   Stacktrace follows... I already did substitute GtkProgressBar
> with GtkProgressBarWindow 
> best,GMS
> $ python gtk/wicd-client.py py Importing pynotify failed,
> notifications disabled.('Has notifications support',
> False)Loading...Connecting to daemon...Connected.gtk/wicd-
> client.py:535: DeprecationWarning: Gtk.UIManager.get_widget is
> deprecated  self.menu =
> (self.manager.get_widget('/Menubar/Menu/Quit').gtk/wicd-
> client.py:944: DeprecationWarning: Gtk.StatusIcon.set_visible is
> deprecated  self.set_visible(True)gtk/wicd-client.py:960:
> DeprecationWarning: Gtk.StatusIcon.set_from_icon_name is deprecated 
> gtk.StatusIcon.set_from_icon_name(self, name)gtk/wicd-client.py:948:
> DeprecationWarning: Gtk.StatusIcon.set_tooltip_text is deprecated 
> self.set_tooltip_text("Initializing wicd...")Traceback (most recent
> call last):  File "gtk/wicd-client.py", line 1204, in
> main(sys.argv)  File "gtk/wicd-client.py", line 103, in
> wrapperreturn func(*args, **kwargs)  File "gtk/wicd-client.py",
> line 1172, in maintray_icon = TrayIcon(animate,
> displaytray=use_tray, displayapp=display_app)  File "gtk/wicd-
> client.py", line 162, in __init__self.tr.toggle_wicd_gui()  File
> "gtk/wicd-client.py", line 864, in toggle_wicd_guiself.gui_win =
> gui.appGui(tray=self)  File "/home/gms/tmp/wicd/gtk/gui.py", line
> 193, in
> __init__self.wTree.add_from_file(gladefile)gi.repository.GLib.Err
> or: gtk-builder-error-quark: /usr/share/wicd/gtk/wicd.ui:224:49
> Invalid property: GtkProgressBar.activity_mode (11)
> 

Bug#962100: python-memprof fails it's autopkg tests both in testing and unstable

[Matthias Klose]

Package: src:python-memprof
Version: 0.3.6-2
Severity: serious
Tags: sid bullseye

python-memprof fails it's autopkg tests both in testing and unstable:

[...]
autopkgtest [05:36:17]: test python3-testsuite: [---
E
==
ERROR: test_demo (test1.Test)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.w_y9am08/downtmp/build.xvE/src/testsuite/test1.py",
line 29, in test_demo
import demo  # noqa
  File "/tmp/autopkgtest-lxc.w_y9am08/downtmp/build.xvE/src/examples/demo.py",
line 19, in 
from memprof import memprof
  File
"/tmp/autopkgtest-lxc.w_y9am08/downtmp/build.xvE/src/memprof/__init__.py", line
17, in 
from .memprof import *
  File "/tmp/autopkgtest-lxc.w_y9am08/downtmp/build.xvE/src/memprof/memprof.py",
line 25, in 
from .getsize import getSize, isInteresting
ModuleNotFoundError: No module named 'memprof.getsize'

--
Ran 1 test in 0.447s

FAILED (errors=1)

Bug#962085: bcalm, kissplice: both ship /usr/bin/bcalm

[Nilesh Patra]

Hi,

On Wed, 3 Jun 2020, 14:50 Andreas Tille,  wrote:

> Hi Andreas,
>
> thanks for spotting this.
>
> On Wed, Jun 03, 2020 at 09:41:12AM +0200, Andreas Beckmann wrote:
> > Package: bcalm,kissplice
> > Severity: serious
> > User: trei...@debian.org
> > Usertags: edos-file-overwrite
> > Control: found -1 bcalm/2.2.2-1.1
> > Control: found -1 kissplice/2.5.1-1
> > ...
> > Possible solution:
> >  * kissplice stops shipping /usr/bin/bcalm
> >  * bcalm adds Breaks+Replaces: kissplice (<< 2.5.1-2~) (assuming the
> >fixing upload of kissplice is 2.5.1-2)
>
> Seems since last version of kissplice it seems to include bcalm.
> @Nilesh: Would you mind sorting out with upstream which bcalm
> version is the one that will be actively supported?


When I was just drafting the mail regarding this, David replied to this
bug. I suppose they are already on this.
Thanks David!

Or is it
> just a code copy included into kissplice?  We also should remove
> the code copy of gatb-core and rather link against the Debian
> packaged lib.
>

Yep, probably we should remove gatb-core and symlink it/tweak the build
system if need be.
I simply fixed the autopkgtest and called it a day, assuming everything
else is in place.

Looks like my assumption was wrong, and I apologize for not checking rest
of the stuff, I really should have.

Kind Regards,
Nilesh

>

Bug#959606: Headless inkscape

[Jeremy Lainé]

The -z option for inkscape used to allow running inkscape in a headless
mode, but it seems to have been removed. I'm not sure what the equivalent
is now to be able to render SVG to raster formats using inkscape..

Jeremy

Bug#962106: Updating the qsf Uploaders list

[Tobias Frost]

Source: qsf
Version: 1.2.7-1.3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Nelson A. de Oliveira  has retired, so can't work on
the qsf package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.


signature.asc
Description: PGP signature

Bug#942915: ca-certificates: Python2 removal in sid/bullseye

[Gianfranco Costamagna]

Hello,

the patch is now committed on the shared git, but I don't plan to upload it.
(I don't like to touch native packages when possible)

G.

Bug#962120: ITP: fontedit -- edit fonts as byte arrays for use in embedded systems

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: fontedit
  Version : 1.1.0
  Upstream Authors: Dominik Kapusta
* URL : https://github.com/ayoy/fontedit
* License : GPL-3+
  Description : edit fonts as byte arrays for use in embedded systems
 This is a desktop application that allows you to convert general-purpose
 fixed-width desktop fonts to byte array representation that's suitable for
 use in embedded systems displays.

Package will be available at http://phd-sid.ethz.ch/debian/fontedit/

It will probably be team maintained with the Fonts team

Bug#958888: ITP: pytorch -- Tensors and Dynamic neural networks in Python with strong GPU acceleration

[Petter Reinholdtsen]

[Mo Zhou]
> I've uploaded all the necessary build dependencies to the NEW queue.
> Now I'm waiting for the upstream to merge my pull requests.
> 
> will be maintained under Debian Deep Learning Team

Hi.  Any news on this?  See there are two versions pending in NEW.

-- 
Happy hacking
Petter Reinholdtsen

Bug#911415: The change breaks sdcc

[Philipp Klaus Krause]

> Why should a writer of a C scanner care?

The input() function they use is the same as yyinout(), just using a
different name.

This change broke e.g. the Small Device C Compiler (SDCC, in the sdcc
Debian package):

When compiling a file containing an unterminated string literal, SDCC
compiled using flex 2.5.4 gives an error mesagge. SDCC compiled using
SDCC 2.6.4 hangs (it gets into an endless loop looking for the end of
the string literal, as it never gets an " or EOF from input()).

Philipp

Bug#960301: cannot reproduce issue anymore

[Javier Cantero]

On Wed, Jun 03, 2020 at 09:20:14AM +0200, Andreas B. Mundt wrote:
> Hi Mike,
> 
> I reported problems with webRTC above (related or not with the
> 'microphone'-issue at hand).

For the record, it's the same bug, and it's related to a change in
libnss3:

 - upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1636632
 - Firefox 76 bug (already closed): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959971

By the way, bug #961762 "firefox-esr: WebRTC broken"[1] should have been
merged with this one.

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


> However, somehow the problem has
> disappeared here after one of the many upgrades (not the firefox-esr
> package).  I tried to figure out the package that made the difference,
> but there where to many changes.

The "culprit" is libnss3, which unstable has a new version of it since
saturday[2]. You can check it by downgrading to the 2:3.49.1-1 version
from testing and see if that undoes the fix.

 [2]: https://tracker.debian.org/pkg/nss


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#945527: cachefilesd: if statement nr_in_(ready|build)_table underflow causes segfault

[Daniel Scharon]

Dear Maintainer,

are you willing to accept this patch?

@Dan: Is your patch or at least the bug itself reported to upstream?

Thank you and kind regards,
Daniel


smime.p7s
Description: S/MIME cryptographic signature

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Andrej Shadura]

Hi

On Wed, 3 Jun 2020 at 11:50, Anthony Perkins  wrote:
> * Package name: ltunify
>   Version : 0.2
>   Upstream Author : Peter Wu 
> * URL : https://lekensteyn.nl/logitech-unifying.html
> * License : GPL-3.0+
>   Programming Lang: C
>   Description : Pair and manage Logitech devices that use the unifying 
> receiver
>
> Logitech wireless peripherals use a 'Unifying' receiver. This
> utility manages the receiver, allowing the user to pair new
> devices and remove unwanted ones.

I’m wondering in what ways is it better than Solaar already in Debian?
Do we need to have both?

https://pwr-solaar.github.io/Solaar/

> I require a sponsor, but intend to maintain the package myself.
>
> It had a release v0.2 roughly six years ago, and had a few
> additional patches in the following year but no new release. I
> will include a few of these patches as they fix bugs in the
> application.

-- 
Cheers,
  Andrej

Bug#962118: screenkey: Produces invalid config file, throwing an exception at startup

[Martin Quinson]

Package: screenkey
Version: 1:0.10~rc1-1
Severity: normal

Dear maintainer,

I launched screenkey a few times, but now when I try to do so, I get the
following output in my terminal:

---
Traceback (most recent call last):
  File "/usr/bin/screenkey", line 104, in 
main()
  File "/usr/bin/screenkey", line 96, in main
app = sc.Screenkey(logger=logger, options=options,
show_settings=args.show_settings)
  File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 108, in
__init__
self.set_active_monitor(self.options.screen)
  File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 173, in
set_active_monitor
self.update_geometry()
  File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 230, in
update_geometry
inverse_offset_x = g[4]
IndexError: list index out of range
---

I straced the program, and it seems to read from
/home/mquinson/.config/screenkey.json, which content follows (I did not change
it myself):
---
{"no_systray": false, "timeout": 1.0, "recent_thr": 0.1, "compr_cnt": 3,
"ignore": [], "position": "fixed", "persist": false, "font_desc": "Sans Bold",
"font_size": "medium", "font_color": "white", "bg_color": "black", "opacity":
0.8, "key_mode": "composed", "bak_mode": "baked", "mods_mode": "normal",
"mods_only": false, "multiline": false, "vis_shift": false, "vis_space": true,
"geometry": [589, 877, 503, 120], "screen": 0, "window": null}
---

When I remove this file from my disk, screenkey starts properly again. I'm
surprised because, like I said, I never modified this file myself. I remember
playing with the settings using the graphical tool that appeared in my tool
tray, but I cannot remember of what I modified, sorry.

Thanks for maintaining this package,
Mt



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

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

Versions of packages screenkey depends on:
ii  libx11-6   2:1.6.9-2+b1
ii  python33.8.2-3
ii  python3-cairo  1.16.2-3
ii  python3-gi 3.36.0-3

screenkey recommends no packages.

screenkey suggests no packages.

-- no debconf information

-- 
Strong reject, for obvious reasons. -- Bastard Reviewer From Hell


signature.asc
Description: PGP signature

Bug#962119: ITP: python-imgviz -- Image Visualization Tools (Python 3)

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: python-imgviz
  Version : 1.1.0
  Upstream Authors: Kentaro Wada
* URL : https://github.com/wkentaro/imgviz
* License : GPL-3+
  Description : Image Visualization Tools (Python 3)
 These are tools for object detection, semantic and instance segmentation.
 .
 This package installs the library for Python 3.

Package will be available at http://phd-sid.ethz.ch/debian/python3-imgviz/

It will probably be team maintained, once I get access to the right team
(this can also be done at any later time, with any later update)

This package is needed for labelme be updatable to the latest version.

Bug#962140: ITP: bdebstrap -- YAML config based multi-mirror Debian chroot creation tool

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: bdebstrap
  Version : 0.1
  Upstream Author : Benjamin Drung 
* URL : https://github.com/bdrung/bdebstrap
* License : MIT
  Programming Lang: Python
  Description : YAML config based multi-mirror Debian chroot creation tool

bdebstrap is an alternative to debootstrap and a wrapper around
mmdebstrap to support YAML based configuration files. It inherits all
benefits from mmdebstrap. The support for configuration allows storing
all customization in a YAML file instead of having to use a very long
one-liner call to mmdebstrap. It also layering multiple customizations
on top of each other, e.g. to support flavors of an image.

I developed this tool and plan to maintain it in Debian. We use this tool
in-house to build our Debian live images.

-- 
Benjamin Drung

DevOps Engineer and Debian & Ubuntu Developer
Platform Integration (IONOS Cloud)

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß, Hans-Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke

Member of United Internet

Bug#961594: Connection failed [IP: 151.101.112.204 80]

[Christoph Berg]

> > I wonder if turning on apt's Debug::Acquire::http would give more of a
> > clue on where things go wrong?  OTOH given this is highly intermittent
> > it'd be quite noisy...  Christoph, would you be able to give that a try?
> 
> I'll do that now. The first two retries with that setting didn't
> reproduce the problem, though.

20:20:00 Get: 31 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:22:05 GET 
/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44%2bdfsg-5%2bdeb9u4_amd64.deb
 HTTP/1.1
20:22:05 Host: security.debian.org
20:22:05 User-Agent: Debian APT-HTTP/1.3 (1.4.10)
20:22:05
20:22:05
20:22:05 Answer for: 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44+dfsg-5+deb9u4_amd64.deb
20:22:05 HTTP/1.1 200 OK
20:22:05 Server: Apache
20:22:05 X-Content-Type-Options: nosniff
20:22:05 X-Frame-Options: sameorigin
20:22:05 Referrer-Policy: no-referrer
20:22:05 X-Xss-Protection: 1
20:22:05 Last-Modified: Thu, 23 Apr 2020 05:40:59 GMT
20:22:05 ETag: "35840-5a3eeb18b3cf9"
20:22:05 Cache-Control: public, max-age=2592000
20:22:05 Expires: Tue, 28 Apr 2020 19:09:10 GMT
20:22:05 X-Clacks-Overhead: GNU Terry Pratchett
20:22:05 Content-Type: application/x-debian-package
20:22:05 Via: 1.1 varnish
20:22:05 Content-Length: 219200
20:22:05 Accept-Ranges: bytes
20:22:05 Date: Wed, 03 Jun 2020 18:22:05 GMT
20:22:05 Via: 1.1 varnish
20:22:05 Age: 515696
20:22:05 Connection: keep-alive
20:22:05 X-Served-By: cache-fra19137-FRA, cache-hhn4026-HHN
20:22:05 X-Cache: HIT, HIT
20:22:05 X-Cache-Hits: 1, 1
20:22:05 X-Timer: S1591208526.784738,VS0,VE0
20:22:05
20:22:05 Get: 32 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:24:10 GET 
/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44%2bdfsg-5%2bdeb9u4_amd64.deb
 HTTP/1.1
20:24:10 Host: security.debian.org
20:24:10 User-Agent: Debian APT-HTTP/1.3 (1.4.10)
20:24:10
20:24:10
20:24:10 Answer for: 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-2.4-2_2.4.44+dfsg-5+deb9u4_amd64.deb
20:24:10 HTTP/1.1 200 OK
20:24:10 Server: Apache
20:24:10 X-Content-Type-Options: nosniff
20:24:10 X-Frame-Options: sameorigin
20:24:10 Referrer-Policy: no-referrer
20:24:10 X-Xss-Protection: 1
20:24:10 Last-Modified: Thu, 23 Apr 2020 05:40:59 GMT
20:24:10 ETag: "35840-5a3eeb18b3cf9"
20:24:10 Cache-Control: public, max-age=2592000
20:24:10 Expires: Tue, 28 Apr 2020 19:09:10 GMT
20:24:10 X-Clacks-Overhead: GNU Terry Pratchett
20:24:10 Content-Type: application/x-debian-package
20:24:10 Via: 1.1 varnish
20:24:10 Content-Length: 219200
20:24:10 Accept-Ranges: bytes
20:24:10 Date: Wed, 03 Jun 2020 18:24:10 GMT
20:24:10 Via: 1.1 varnish
20:24:10 Age: 515821
20:24:10 Connection: keep-alive
20:24:10 X-Served-By: cache-fra19137-FRA, cache-hhn4074-HHN
20:24:10 X-Cache: HIT, HIT
20:24:10 X-Cache-Hits: 1, 2
20:24:10 X-Timer: S1591208651.836599,VS0,VE0
20:24:10
20:24:10 Get: 33 http://security.debian.org/debian-security 
stretch/updates/main amd64 libldap-2.4-2 amd64 2.4.44+dfsg-5+deb9u4 [219 kB]
20:24:10 Fetched 16.6 MB in 8min 30s (32.4 kB/s)
20:24:10 E: Failed to fetch 
http://security.debian.org/debian-security/pool/updates/main/o/openldap/libldap-common_2.4.44+dfsg-5+deb9u4_all.deb:
 Connection failed [IP: 151.101.112.204 80]
20:24:10 E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' 
to continue with missing packages
20:24:11 Reading package lists...

I wonder if the 2min delay before the 2nd last package points at
something. Possibly the transfer was ok for that .deb, but then apt
tries http keepalive but that's already closed?

It could be that the NAT layer in the build chroots here have bad
iptables rules that break this (they have isolated network namespaces
using newpid/newnet). But then, why does it only happen for
security.d.o only, and only for jessie+stretch when buster has also
security? It's also restricted to a set of VMs at Hetzner, while other
machines are fine.

Also, the phenomenon is new (~3 months old or so), while the (buster)
buildhosts are much older and the config hasn't been touched except
for kernel updates.

Christoph

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Gabriele]

Hi Paul

Ok mystery solved :). Once I have this fixed, what should I do? Push
the new tarball with the same version (1.0.1-1) or should I bump
something in the version? I'd expect that perhaps that -1 should
become a -2? If so, what's the correct way of doing this?

Cheers,
Gabriele

On Wed, 3 Jun 2020 at 16:36, Paul Gevers  wrote:
>
> Hi Gabriele,
>
> On 02-06-2020 23:37, Gabriele wrote:
> > Many thanks for your reply. I have had a look at the logs linked on this 
> > page
> >
> > https://ci.debian.net/packages/a/austin/testing/amd64/
> >
> > The only version that passes is v1.0.0 and by looking at the logs of
> > v0.7.0 and v1.0.1, which fail, it's a miracle that v1.0.0 even passes.
> > Indeed v0.7.0 and v1.0.1 fail for the very same reason: the binary
> > used for the tests, src/austin, is simply not there. Why it is there
> > for the v1.0.0 I don't know, so it looks like the problem is with
> > v1.0.0 paradoxically.
>
> It's funny, the first tries of 1.0.0 also failed. And I believe they
> they only starting passing when python3.7 was not the default Python3
> anymore.
>
> > This is the diff inside the debian/ folder between v1.0.0 and v1.0.1
> > (TLDR: only debian/austin.1, debian/changelog and debian/copyright
> > have changed)
>
> Instead, I diffed the source and this struck my eye:
>
> diff -Nru austin-1.0.0/test/test_fork.bats austin-1.0.1/test/test_fork.bats
> --- austin-1.0.0/test/test_fork.bats2019-10-19 10:37:23.0 +
> +++ austin-1.0.1/test/test_fork.bats2020-02-21 19:27:02.0 +
> @@ -56,6 +56,12 @@
>then
>  skip "Test failed but marked as 'Ignore'"
>else
> +echo
> +echo "Collected Output"
> +echo ""
> +echo
> +echo "$output"
> +echo
>  false
>fi
>  }
> @@ -109,6 +115,6 @@
>invoke_austin "3.7"
>  }
>
> -# @test "Test Austin with Python 3.8" {
> -#   invoke_austin "3.8"
> -# }
> +@test "Test Austin with Python 3.8" {
> +  invoke_austin "3.8"
> +}
>
> So, with 1.0.0 your tests were passing because all tests were skipped,
> and only with 1.0.1 your tests started testing the code again and failed
> because the required binary couldn't be found.
>
>
> > Hence, to the best of my knowledge, there are no changes in the
> > debian/ area that would cause the binary in src/ to be there unless it
> > accidentally ended up, say, in the source tarball.
>
> I think I've showed an alternative explanation.
>
> > My next question to you is then: where is the binary supposed to be
> > found during autopkgtest? Can I assume it will be on the PATH during
> > testing, so that I can invoke it simply with "austin"? Or do I need to
> > specify a precise path?
>
> The testbed is a clean Debian installation, created with debbootstrap
> and only your test dependencies installed. Everything is in it's regular
> location, so if austin is on the regular path for users, it on the
> regular path for the debci user in the testbed. Not specifying the
> precise path makes sure your testing that it's on the path for your
> users too, so better without path.
>
> Paul
>


-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#962138: perl-base: libperl5.30 version skew can break essential functionality

[Niko Tyni]

Package: perl-base
Version: 5.30.2-1
Severity: serious

Our Perl package dependencies and search path arrangements allow
for a suitably versioned libperl5.30 package to break perl-base
functionality. This is bad as perl-base is Essential:yes and is therefore
required to stay functional at all times.

The specific version skew that triggers this is between minor upstream
versions, so for instance 5.30.2-1 -> 5.30.3-1, which are the current
version in testing and unstable.

The transcript at the end, from a current bullseye chroot with perl-base
and libperl5.30 but no perl installed, shows how perl-base can be
upgraded from sid without touching the other packages. After this, the
standard library in libperl5.30 is different version from perl-base but
has preference on the search path, causing version check bailouts and
breaking perl-base.

This works in the other direction too: if a newer version of libperl5.30
is unpacked, perl-base stops working in the same way. However,
the versioned dependency chain libperl5.30 -> perl-modules-5.30 (>=
${source:Version}) -> perl-base (>= ${Upstream-Version}-1) means that
libperl5.30 can't be configured in this combination.

The initial FTBFS of 5.30.3-1 on an arch:all sid buildd briefly resulted
in ideal conditions for this bug to trigger: unstable/amd64 then had
perl-modules-5.30 at version 5.30.2-1, but libperl5.30 and perl-base
at 5.30.3-1. Systems without the perl binary package were at that point
prone to upgrade to the newer perl-base while keeping perl-modules-5.30
and libperl5.30 at the old version. The autopkgtest checks of hkgerman
hit this when /usr/sbin/update-dictcommon-aspell (in dictionaries-common)
broke.

  https://ci.debian.net/data/autopkgtest/testing/arm64/h/hkgerman/5736806/log.gz

It's not clear to me what the practical effects of this issue are.
Pretty much all real systems have the perl binary package installed,
which seems to make apt unpack libperl5.30 and perl-base very close to
each other. We haven't had any upgrade failure reports from the recent
5.30.0 -> 5.30.1 upgrade FWIW.

Minor upstream version upgrades in testing/unstable have been relatively
rare in the past, and oldstable -> stable upgrades have always
incorporated a major version bump since the 5.10 times (squeeze), when
the dependencies and the package set were very different.

In any case, I think this needs to be fixed and should probably be
considered release critical.

I'm afraid this also means that a minor upstream version upgrade
in stable has a higher risk of breaking things, so maybe we should
reconsider #961443.

I see two ways of fixing this (but happy to entertain other suggestions too).

A) Move /usr/lib//perl-base up on the @INC search path. This is
   shipped in perl-base and includes the parts of the standard library
   we consider part of Essential:yes functionality. It's currently last
   on @INC. The libperl5.30 and perl-modules-5.30 packages include copies
   of these files, shipped in /usr/{lib,share}//perl/5.30,
   so that they can be used "standalone" for different architectures or
   major versions. The position of these copies higher on @INC makes this
   bug possible.

   IIRC I put /usr/lib//perl-base last because it's a nonstandard
   divergence from the upstream way of doing things, and I wanted it not
   to have an effect in the "normal" case when all the related packages
   are installed and configured. So it was only supposed to be a safeguard
   during upgrades and such. Clearly the safeguard is incomplete.

B) Do away with the /usr/{share,lib/x86_64-linux-gnu}/perl/5.30 -> 5.30.x
   symlinks currently shipped in libperl5.30 and perl-modules-5.30,
   and have the perl search path include the full upstream version. We
   tried this with the multiarch changes in 5.22 but reverted it with
   #787158 .  As I noted in that bug, this would mean that long running
   Perl programs could have @INC changed underneath them during version
   upgrades. This is not a showstopper by any means; we already have the
   'perl-major-upgrade' trigger for similar situations during major
   version upgrades, with at least some buy-in from packages like
   spamassassin IIRC.

I think A) is currently my preferred way of fixing this, and I think
the upstream "divergence" issue it creates is not very important. I
can envision some corner case regressions where standard library
modules expect other modules to be in the same directory, but those
seem improbable.

The main reason why I prefer option A is that it seems conceptually more
correct (improving the standalone properties of perl-base). Also, option
B may be harder to implement while keeping upgrade paths robust. But I
haven't really thought this through yet.

On a brighter note, either of these options would close #798626 :)

Apologies for my verbosity and thanks for reading through; ideas and
comments are naturally welcome. Despite the severity I don't think this
is particularly urgent, except with the possibly 

Bug#962084: Adding buster-backport to apt sources on install seems wrong

[Joseph Nuthalapati]

This is also being discussed on a Debian Salsa issue. Cross-linking.
https://salsa.debian.org/freedombox-team/freedombox/-/issues/1855

On 03/06/20 1:05 pm, Christian Ehrhardt wrote:
> Package: plinth
> Version: 20.10
> severity: serious
> 
> Hi,
> running into issues today I realized that the new freedombox 20.10
> places this file on disk:
> $ cat /etc/apt/sources.list.d/freedombox2.list
>   # This file is managed by FreedomBox, do not edit.
>   # Allow carefully selected updates to 'freedombox' from backports.
>   deb http://deb.debian.org/debian buster-backports main
>   deb-src http://deb.debian.org/debian buster-backports main
> 
> IMHO a package should not on-install mess with apt sources. Users just
> don't expect this or the follow on consequences that can happen.
> For example you are pinning python packages from backports which I'd
> expect might lead to quite some dependency hell with other things installed.
> 
> I was facing this in Ubuntu where it is even more wrong and essentially
> breaking `apt update`, but IMHO it is even wrong if not outright
> forbidden by some policy in Debian. I mean adding 'buster-backports' and
> pinning to them in e.g. 'sid' - to me that sounds like calling for trouble.
> 
> I'd ask you to reconsider and remove this behavior. If you want/need to
> keep it then maybe at least consider adding a skip if `dpkg-vendor
> --derives-from Ubuntu` is true. Would that work better for you?
> 
> -- 
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd

-- 
Regards,
Joseph Nuthalapati



signature.asc
Description: OpenPGP digital signature

Bug#960149: kmod: Enable support for gzip compressed kernel modules

[Vagrant Cascadian]

On 2020-06-02, Vagrant Cascadian wrote:
> On 2020-06-02, Marco d'Itri wrote:
>> On May 10, Vagrant Cascadian  wrote:
>>
>>> I see xz-compressed modules are supported, which is definitely useful,
>>> but gzip compressed modules are also widely used, and have different CPU
>>> vs. storage space tradeoffs.
>> No. This was already discussed in #952590, I do not want to add another 
>> dependency to the initramfs.
>
> And as said in that bug report as well, libz and numerous other
> compression libraries are already added with a default initramfs-tools.
>
> $ lsinitramfs /boot/initrd.img-5.6.0-2-arm64 | grep -E 'libz|liblz'
> usr/lib/aarch64-linux-gnu/liblz4.so.1
...
> usr/lib/aarch64-linux-gnu/libz.so.1
> usr/lib/aarch64-linux-gnu/libz.so.1.2.11
...
> Your argument that only if it uses plymouth doesn't appear to be
> correct:
>
> $ dpkg -l '*plymouth*'
> dpkg-query: no packages found matching *plymouth*

Though after checking on a more minimal system, something other than
plymouth was probably pulling those in... hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#962133: patch for bugs 962133 and 962135

[Vincent Lefevre]

Control: tags 962133 patch
Control: tags 962135 patch

I've attached a patch for Debian bugs 962133 ("dpkg -s" completion)
and 962135 ("dpkg -l" completion), which also fixes "dpkg --remove"
and "dpkg --purge" completions. I've added a note about that:

# Note: Packages may be marked as "deinstall" or "purge", i.e. selected
# for deinstallation or to be purged (see dpkg(1) man page); this means
# that the operation has not been completed yet. In the meantime, such
# packages may still be installed (if marked as purge, one is not sure,
# though, as the package could have been uninstalled but not purged yet),
# so that purge and remove operations remain valid.

Basically, the fix consists of the _dpkg change.

My patch also removes "deinstalled" from _deb_packages as it does not
seem to be used (and should be useless).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -aurd compl-debian-deb/_deb_packages compl-debian-fix/_deb_packages
--- compl-debian-deb/_deb_packages  2020-03-22 15:12:25.0 +
+++ compl-debian-fix/_deb_packages  2020-06-03 17:09:43.704256786 +
@@ -1,6 +1,6 @@
 #autoload
 
-# Usage: _deb_packages expl...  
(installed|deinstalled|xinstalled|held|uninstalled|avail|available|source)
+# Usage: _deb_packages expl...  
(installed|xinstalled|held|uninstalled|avail|available|source)
 
 _deb_packages_update_avail () {
   if ( [[ ${+_deb_packages_cache_avail} -eq 0 ]] ||
@@ -41,19 +41,6 @@
   cachevar=_deb_packages_cache_held
 }
 
-_deb_packages_update_deinstalled () {
-  if ( [[ ${+_deb_packages_cache_deinstalled} -eq 0 ]] ||
-  _cache_invalid DEBS_deinstalled ) && ! _retrieve_cache DEBS_deinstalled;
-  then
-_deb_packages_cache_deinstalled=()
-dpkg --get-selections | while read package state ; do
-[[ $state = deinstall ]] && _deb_packages_cache_deinstalled+=$package
-done
-_store_cache DEBS_deinstalled _deb_packages_cache_deinstalled
-  fi
-  cachevar=_deb_packages_cache_deinstalled
-}
-
 _deb_packages_update_xinstalled () {
   if ( [[ ${+_deb_packages_cache_xinstalled} -eq 0 ]] ||
   _cache_invalid DEBS_xinstalled ) && ! _retrieve_cache DEBS_xinstalled;
@@ -103,14 +90,14 @@
 zstyle ":completion:*:*:$service:*" cache-policy _debs_caching_policy
   fi
 
-  [[ "$command" = 
(installed|deinstalled|xinstalled|held|uninstalled|avail|available|source) ]] 
|| {
+  [[ "$command" = 
(installed|xinstalled|held|uninstalled|avail|available|source) ]] || {
 _message "unknown command: $command"
 return
   }
 
   zstyle -s ":completion:${curcontext}:" packageset pkgset
 
-  [[ "$pkgset" = 
(installed|deinstalled|xinstalled|held|uninstalled|avail|available|source) ]] 
|| {
+  [[ "$pkgset" = 
(installed|xinstalled|held|uninstalled|avail|available|source) ]] || {
 pkgset="$command"
   }
 
diff -aurd compl-debian-deb/_dpkg compl-debian-fix/_dpkg
--- compl-debian-deb/_dpkg  2020-03-22 15:12:25.0 +
+++ compl-debian-fix/_dpkg  2020-06-03 17:24:33.866990607 +
@@ -149,21 +149,17 @@
   - nonrecur \
'*: :_deb_files'
   ;;
-  remove|status|listfiles)
-_call_function ret _dpkg_$state && return ret
-_arguments -C -A "-*" -s "$_dpkg_options[@]" \
-   '*:package:_deb_packages installed'
-  ;;
-  purge)
+# Note: Packages may be marked as "deinstall" or "purge", i.e. selected
+# for deinstallation or to be purged (see dpkg(1) man page); this means
+# that the operation has not been completed yet. In the meantime, such
+# packages may still be installed (if marked as purge, one is not sure,
+# though, as the package could have been uninstalled but not purged yet),
+# so that purge and remove operations remain valid.
+  list|listfiles|purge|remove|status)
 _call_function ret _dpkg_$state && return ret
 _arguments -C -A "-*" -s "$_dpkg_options[@]" \
'*:package:_deb_packages xinstalled'
   ;;
-  list)
-_call_function ret _dpkg_$state && return ret
-_arguments -C -A "-*" -s "$_dpkg_options[@]" \
-   '*:packages:_deb_packages avail'
-  ;;
   compare_versions)
 _call_function ret _dpkg_$state && return ret
 _arguments -C -A "-*" -s \

Bug#962141: docker.io: CVE-2020-13401

[Salvatore Bonaccorso]

Source: docker.io
Version: 19.03.7+dfsg1-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for docker.io.

CVE-2020-13401[0]:
| An issue was discovered in Docker Engine before 19.03.11. An attacker
| in a container, with the CAP_NET_RAW capability, can craft IPv6 router
| advertisements, and consequently spoof external IPv6 hosts, obtain
| sensitive information, or cause a denial of service.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13401
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13401
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1833233
[2] 
https://github.com/moby/libnetwork/commit/153d0769a1181bf591a9637fd487a541ec7db1e6

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#962093: Gimp fails to start

[Simon McVittie]

Control: tags -1 + moreinfo

On Wed, 03 Jun 2020 at 11:45:01 +0300, Vitaliyi wrote:
> gimp: /usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0: no version information
> available (required by gimp)
> gimp: /usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0: no version information
> available (required by /usr/lib/libgimpwidgets-2.0.so.0)
> gimp: /usr/lib/x86_64-linux-gnu/libbabl-0.1.so.0: no version information
> available (required by /usr/lib/libgimpcolor-2.0.so.0)
> gimp: symbol lookup error: gimp: undefined symbol: gegl_rectangle_subtract

I would guess that you have libbabl/libgegl from deb-multimedia.org, similar
to #961993 (and many other bug reports in the past).

These third-party packages are incorrectly packaged: their version
numbers are set in a way that makes them pretend to be a higher version
than anything in Debian, even though they are actually older, leading
to broken installations.

We cannot support third-party packages, particularly ones that are
wrongly packaged like this. Please install libbabl/libgegl from Debian,
and if possible do not use deb-multimedia.org at all.

If you are not using deb-multimedia.org packages, please use
`reportbug --template gimp` to get more information about gimp and
its dependencies, and send the result to this bug report's address.

smcv

Bug#962060: josm: java.lang.NoClassDefFoundError: Could not initialize class org.openstreetmap.josm.data.cache.JCSCacheManager

[Johannes Visintini]

Package: josm
Version: 0.0.svn16538+dfsg-2
Followup-For: Bug #962060

Dear Maintainer,

I updated to this JOSM version with `apt install -t unstable josm` and
all the time when I want to do anything (e.g. close JOSM, load data from
OSM) I get the reported error. I can't even close JOSM without killing
it.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_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 josm depends on:
ii  default-jre [java9-runtime] 2:1.11-72
ii  fonts-noto  20200323-1
ii  jmapviewer  2.14+dfsg-1
ii  libcommons-compress-java1.20-1
ii  libgettext-commons-java 0.9.6-6
ii  liboauth-signpost-java  1.2.1.2-3
ii  openjdk-11-jre [java9-runtime]  11.0.7+9-1
ii  openjfx 11.0.7+0-2
ii  proj-data   7.0.1-1

Versions of packages josm recommends:
ii  josm-l10n  0.0.svn16538+dfsg-2

josm suggests no packages.

-- no debconf information

-- JOSM bug information
{{{
Revision:16538
Is-Local-Build:false
Build-Date:1970-01-23 23:34:59
Debian-Release:0.0.svn16538+dfsg-2
Build-Name:Debian

Identification: JOSM/1.5 (16538 Debian en_GB) Linux Debian GNU/Linux 
bullseye/sid
Memory Usage: 411 MB / 3962 MB (222 MB allocated, but free)
Java version: 11.0.7-ea+9-post-Debian-1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 2560x1440
Maximum Screen Size: 2560x1440
Java package: openjdk-11-jre:amd64-11.0.7+9-1
Java ATK Wrapper package: libatk-wrapper-java:all-0.38.0-1
libcommons-compress-java: libcommons-compress-java:all-1.20-1
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:all-20200323-1
liboauth-signpost-java: liboauth-signpost-java:all-1.2.1.2-3
VM arguments: [-Djosm.restart=true, -Djava.net.useSystemProxies=true]

Plugins:
+ PicLayer (35405)
+ apache-commons (35362)
+ ejml (35313)
+ geotools (35169)
+ jaxb (35092)
+ jts (35122)
+ log4j (35092)
+ opendata (35405)
+ openqa (0.1.9)
+ reverter (35474)
+ utilsplugin2 (35476)

Map paint styles:
+ https://www.openrailwaymap.org/styles/josm-additional.zip
+ https://www.openrailwaymap.org/styles/electrified.zip
+ https://www.openrailwaymap.org/styles/standard.zip
- https://www.openrailwaymap.org/styles/maxspeed.zip
+ https://www.openrailwaymap.org/styles/signals.zip

Validator rules:
+ https://www.openrailwaymap.org/validator/de-openrailwaymap.validator.mapcss
+ https://www.openrailwaymap.org/validator/openrailwaymap.validator.mapcss

Last errors/warnings:
- E: Handled by bug report queue: java.lang.NoClassDefFoundError: Could not 
initialize class org.openstreetmap.josm.data.cache.JCSCacheManager


=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.

Warning issued by: BugReportExceptionHandler#handleException

=== STACK TRACE ===
Thread: AWT-EventQueue-0 (20) of main
java.lang.NoClassDefFoundError: Could not initialize class 
org.openstreetmap.josm.data.cache.JCSCacheManager
at 
org.openstreetmap.josm.gui.layer.AbstractCachedTileSourceLayer.getCache(AbstractCachedTileSourceLayer.java:118)
at 
org.openstreetmap.josm.gui.layer.AbstractCachedTileSourceLayer.getTileLoaderFactory(AbstractCachedTileSourceLayer.java:106)
at 
org.openstreetmap.josm.gui.bbox.JosmMapViewer.(JosmMapViewer.java:148)
at 
org.openstreetmap.josm.gui.bbox.SlippyMapBBoxChooser.(SlippyMapBBoxChooser.java:87)
at 
org.openstreetmap.josm.gui.download.SlippyMapChooser.(SlippyMapChooser.java:35)
at 
org.openstreetmap.josm.gui.download.DownloadDialog.buildMainPanel(DownloadDialog.java:128)
at 
org.openstreetmap.josm.gui.download.DownloadDialog.(DownloadDialog.java:230)
at 
org.openstreetmap.josm.gui.download.DownloadDialog.(DownloadDialog.java:218)
at 
org.openstreetmap.josm.gui.download.DownloadDialog.getInstance(DownloadDialog.java:84)
at 
org.openstreetmap.josm.actions.DownloadAction.actionPerformed(DownloadAction.java:35)
at 
java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
at 
java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
at 
java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
at 
java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
at 

Bug#960984: ITP: google-http-client-java -- Google HTTP Client Library for Java

[Olek Wojnar]

Hi Sudip,

On Wed, Jun 3, 2020 at 7:43 AM Sudip Mukherjee 
wrote:

>
> Do you know which modules from google-auth you will need? I think thats
> #959830.
>

Yes, I do: google-auth-library-credentials.jar,
google-auth-library-oauth2-http.jar. Take a look at [1], we've got lots of
good info there. Please let me know if anything is missing or you have any
other questions. We appreciate any assistance!

-Olek

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#868220: ifupdown should support vlan-aware bridges

[Benedikt Spranger]

On Wed, 3 Jun 2020 13:50:56 +0200
Santiago Garcia Mantinan  wrote:

Hi,

sorry for the trouble.
> > the problem is I get operation not supported when setting
> > vlan_filtering 0 on my bridge, does the else really make sense
> > here?  
Unfortunately yes.
The brigde is configured at runtime and can be reconfigured. Without the
else part a user is forced to unset the filtering by hand if set by
try/error/accident.

> Well, this was added due to bugs.debian.org/950879 reported by
> Benedikt who kindly supplied the patch, the patch didn't cause any
> trouble on the tests I did and that's why I applied it like he sent
> it.
> 
> I have added Benedikt to my reply for him to comment on this.
OK.
 
> As I understand it, Gianluigi, if we remove the else there we won't
> set vlan filtering to 0 and thus you won't get the error, right?
>
> We have two options here, one is to remove it and the other to send
> the possible errors on the setting to 0 case to /dev/null.
May I introduce a third option?
I am not shure, if that pseudo file exists on every supported kernel,
but you got the idea. If that is prefered, i can dig through the kernel
sources and provide a patch.

NOTE: untested!
---8<---
# Activate VLAN filtering on VLAN aware bridges
   
if [ "$IF_BRIDGE_VLAN_AWARE" = "yes" ]; then
  ip link set dev $IFACE type bridge vlan_filtering 1   
else
  if [ -f /sys/devices/virtual/net/$IFACE/bridge/vlan_filtering ]; then
ip link set dev $IFACE type bridge vlan_filtering 0
  fi
fi
---8<---

I do not like to paper over errors like sending them to /dev/null.
But I prefer that option over droping the else part.

Regards
Benedikt Spranger

Bug#962009: Bug#962008: RFS: ca-certificates/20200601 [RC] -- Common CA certificates

[Adrian Bunk]

On Wed, Jun 03, 2020 at 08:40:02AM -0500, Michael Shuler wrote:
>...
> Generally, expiry date has not been an issue remaining in the bundle until
> removal upstream, since the certification authorities have managed migration
> to new roots well and openssl>=1.1.1 handles this gracefully. This appears
> to have not been the case with AddTrust and older openssl<1.1.1 bug, as that
> fix was not backported, to the best of my understanding.

gnutls has the same problem (#961889).

But you do have a point that libraries are supposed to handle this 
situation gracefully.

>...
> Re: security uploads:
> 
> I have received no reply from the security team, as of this message, so
> awaiting their OK/advice. Copy of email sent to team@security, since there
> is no secret info in here:
>...

Please wait for an ACK from the security team before making uploads
to -security or asking others to do so.

While maintainers are allowed to update their packages quite freely
in unstable (with some exceptions like library transitions ot the
freeze before a release), uploads to *-security and stable distributions 
need an ACK first.

> Kind regards,
> Michael

cu
Adrian

Bug#962134: add Sound Open Firmware

[Moritz Mühlenhoff]

On Wed, Jun 03, 2020 at 05:25:21PM +0200, Marek Straka wrote:
> Package: firmware-linux-nonfree
> Version: 20190717-2
> Severity: normal
> 
> 
> Add Sound Open Firmware:
> https://github.com/thesofproject/sof-bin
> https://www.sofproject.org/

This is free software and could go into main or am I missing something?

Cheers,
Moritz

Bug#962133: [Pkg-zsh-devel] Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Vincent Lefevre]

On 2020-06-03 17:45:11 +0200, Axel Beckert wrote:
> Vincent Lefevre wrote:
> > Actually there's another one:
> > 
> > zira:~> dpkg -l | grep '^rc'
> > rc  openntpd   1:6.0p1-1
> >amd64OpenBSD NTP daemon
> 
> All packages shown as "rc" by dpkg on my system seem _not_ to be
> installed but are usually removed, but not purged. Example:

They are not installed, but are valid candidates for "dpkg -s"
arguments.

> From the design of the current implementation (only show installed
> packages for "dpkg -s" completion)

Currently this is: installed and not marked to be uninstalled
(or to be purged).

> it is correct that "dpkg -s" doesn't complete these packages.

This is not correct. "dpkg -s" should complete to any valid
argument, i.e. for which package information is available
(thus this excludes purged packages). This is a real bug.

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

Bug#961994: src:libcatmandu-perl: fails to migrate to testing for too long: causes autopkgtest regression

[Niko Tyni]

On Mon, Jun 01, 2020 at 07:54:29PM +0200, Paul Gevers wrote:
> Source: libcatmandu-perl
> Version: 1.2012-1
> Severity: serious
> Control: close -1 1.2012-1
> Tags: sid bullseye
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
 
> As recently announced [1], the Release Team now considers packages that
> are out-of-sync between testing and unstable for more than 60 days as
> having a Release Critical bug in testing. Your package
> src:libcatmandu-perl in unstable has been trying to migrate for 60 days
> [2]. Hence, I am filing this bug.

So if I read this correctly, libcatmandu-perl cannot migrate because it
breaks the test suite of libcatmandu-sru-perl in testing. The version of
libcatmandu-sru-perl in unstable fixes this, but cannot migrate because
it has a versioned dependency on libcatmandu-perl that is only satisfied
in unstable.

I believe the preferred way to get these to migrate together is to declare
that libcatmandu-perl Breaks the older libcatmandu-sru-perl versions.

Alternatively, just waiting it out will probably work too: once testing
removal happens, the newer packages can migrate on their own. However,
if the test suite breakage is not just a technicality, the missing
Breaks makes it possible for users to partially upgrade their systems
to a broken combination.

Paul, please correct me if I'm mistaken above :)
-- 
Niko Tyni   nt...@debian.org

Bug#958090: Diamond-aligner keeps on failing its build time test on s390x

[Andreas Tille]

Hi,

despite upstream has tried hard to make diamond-aligner portable for all
64bit architectures the build time test keeps on failing for s390x[1]:

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
cd debian/tests && 
PATH=/<>/obj-s390x-linux-gnu:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 sh diamond-calls
+ mktemp -d
+ TESTDIR=/tmp/tmp.b7aBbuLXHF
+ diamond blastp --threads 1 --db test/C.faa.diamond --query test/E.faa --out 
/tmp/tmp.b7aBbuLXHF/E.faa.vs.C.faa.diamond -e 1e-05 --outfmt 6 --quiet 
--sensitive
make[1]: *** [debian/rules:33: override_dh_auto_test] Error 1


Upstream says[2] despite the --quiet option there should be some error
output.  I have removed the --quiet option in Git but did not uploaded
yet.  May be some s390 porter could have a look and provide some gdb or
strace output?

Kind regards

  Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=diamond-aligner=s390x=0.9.33-1=1591090725=0
[2] https://github.com/bbuchfink/diamond/issues/348#issuecomment-638285523

-- 
http://fam-tille.de

Bug#962139: [btrfs-progs] initramfs hooks failed with on libgcc_s.so.1

[Daniel Schröter]

Package: btrfs-progs
Version: 5.6-1
Severity: normal

Dear Maintainer,

if I do an
update-initramfs -v -c -k 5.6.0-2-amd64
it failed. I add
set -x
to
/usr/share/initramfs-tools/hooks/btrfs
so I get an better output:
[]
Adding binary /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4
+ cp -pP /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4
/var/tmp/mkinitramfs_PP4oJD//usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4
+ echo /lib/x86_64-linux-gnu/libpthread.so.0
+ sed -e 
s#/lib/\([^/]*/\)\?\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#/lib/\1\3#
+ nonoptlib=/lib/x86_64-linux-gnu/libpthread.so.0
+ echo /lib/x86_64-linux-gnu/libpthread.so.0
+ sed -e s#-linux-gnu/\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#-linux-gnu/\2#
+ nonoptlib=/lib/x86_64-linux-gnu/libpthread.so.0
+ [ -e /lib/x86_64-linux-gnu/libpthread.so.0 ]
+ x=/lib/x86_64-linux-gnu/libpthread.so.0
+ copy_exec /lib/x86_64-linux-gnu/libgcc_s.so.1
+ local src target x nonoptlib ret
+ src=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ target=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ copy_file binary /lib/x86_64-linux-gnu/libgcc_s.so.1 
/lib/x86_64-linux-gnu/libgcc_s.so.1
+ local type src target link_target
+ type=binary
+ src=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ target=/lib/x86_64-linux-gnu/libgcc_s.so.1
+ [ -f /lib/x86_64-linux-gnu/libgcc_s.so.1 ]
+ return 2
+ return 1
+ return


It failed on /lib/x86_64-linux-gnu/libgcc_s.so.1. It's not available
# ll /lib/x86_64-linux-gnu/libgcc_s.so.1
ls: cannot access '/lib/x86_64-linux-gnu/libgcc_s.so.1': No such file or 
directory


In #950254 they mentioned that libgcc_s gets copied by initramfs-tools. Does it 
break the
workaround in /usr/share/initramfs-tools/hooks/btrfs?

Thanks for you work!

Bye



--- System information. ---
Architecture: Kernel:   Linux 5.5.0-2-amd64

Debian Release: bullseye/sid
  990 unstablemirror.1und1.de   500 stable  
packages.microsoft.com   500
stable  dl.google.com 1 experimentalmirror.1und1.de
--- Package information. ---
Depends(Version) | Installed
-+-=
libblkid1(>= 2.17.2) | 2.35.2-2
libc6   (>= 2.8) | 2.30-8
libcom-err2  (>= 1.43.9) | 1.45.6-1
libext2fs2 (>= 1.42) | 1.45.6-1
liblzo2-2  (>= 2.02) | 2.10-2
libuuid1   (>= 2.16) | 2.35.2-2
libzstd1  (>= 1.3.2) | 1.4.4+dfsg-3
zlib1g  (>= 1:1.2.0) | 1:1.2.11.dfsg-2


Package's Recommends field is empty.

Suggests(Version) | Installed
=-+-===
duperemove|

Bug#944538: buster-pu: package ganeti-instance-debootstrap/0.16-6.1

[Antoine Beaupré]

On 2020-04-26 10:46:41, Antoine Beaupré wrote:

[...]

> I will also mention that this has landed in buster ages ago, and no ill
> effects were found there.

I meant bullseye here, sorry.

Any news? :)

a.

-- 
Striving for social justice is the most valuable thing to do in life
   - Albert Einstein

Bug#962136: FTBFS on i386 because of .la files

[Daniel Baumann]

Package: nghttp2
Version: 1.41.0-1
Severity: serious

Hi,

when building nghttp2 on i386 it fails to build at dh_missing because
debian/tmp/usr/lib/*/*.la is not included in any package (which is correct).

I suggest to add a 'rm -f debian/tmp/usr/lib/*/*.la' after the
dh_auto_install in rules.

Regards,
Daniel

Bug#962133: [Pkg-zsh-devel] Bug#962133: zsh-common: missing package in "dpkg -s" completion

[Vincent Lefevre]

The issue is that
/usr/share/zsh/functions/Completion/Debian/_deb_packages
just considers packages in states install and hold:

_deb_packages_update_installed () {
  if ( [[ ${+_deb_packages_cache_installed} -eq 0 ]] ||
  _cache_invalid DEBS_installed ) && ! _retrieve_cache DEBS_installed;
  then
_deb_packages_cache_installed=()
dpkg --get-selections | while read package state ; do
[[ $state = (install|hold) ]] && _deb_packages_cache_installed+=$package
done
_store_cache DEBS_installed _deb_packages_cache_installed
  fi
  cachevar=_deb_packages_cache_installed
}

Instead, any state should be valid for "dpkg -s" completion.
It seems that this is what _deb_packages_update_xinstalled does:

xinstalled () {
  if ( [[ ${+_deb_packages_cache_xinstalled} -eq 0 ]] ||
  _cache_invalid DEBS_xinstalled ) && ! _retrieve_cache DEBS_xinstalled;
  then
_deb_packages_cache_xinstalled=()
dpkg --get-selections | while read package state ; do
_deb_packages_cache_xinstalled+=$package
done
_store_cache DEBS_xinstalled _deb_packages_cache_xinstalled
  fi
  cachevar=_deb_packages_cache_xinstalled
}

So the fix should be easy: in
/usr/share/zsh/functions/Completion/Debian/_dpkg

  remove|status|listfiles)
_call_function ret _dpkg_$state && return ret
_arguments -C -A "-*" -s "$_dpkg_options[@]" \
   '*:package:_deb_packages installed'
  ;;
  purge)
_call_function ret _dpkg_$state && return ret
_arguments -C -A "-*" -s "$_dpkg_options[@]" \
   '*:package:_deb_packages xinstalled'
  ;;

move "status" and "listfiles" to "purge" (which uses xinstalled).

Still, "remove" and "purge" would remain inconsistent, which
is another bug...

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

Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock

[Dirk Eddelbuettel]

Conrad (of Armadillo fame) sent me this (and ok'ed passing it on):

  According to an Intel report back from 2011, -Bsymbolic-functions "is
  a dangerous option which can often result in some non-intuitive side
  effects".
  The report explicitly shows various problems with the option.
  
https://software.intel.com/content/www/us/en/develop/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects.html

  In the light of the above, it's a real wonder that Ubuntu uses the
  option at all.

  Perhaps Ubuntu developers meant well, but are not aware of the side effects ?

Graham do you think you can get it turned off for at least openblas?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#962134: add Sound Open Firmware

[Mark Pearson]

Hi,

Don't know if it helps but I raised #960788 on the same topic.
It has a few details on how other distro's have packaged it 
which might be helpful.

Once this is available I'm happy to do some testing.

Thanks
Mark

Bug#961013: diamond-aligner: Diamond faill with the error: Assertion `index >= 0 && index < size()' failed.

[Pranav Ballaney]

Hi,

I've narrowed the issue down to one (or a few) sequences. Basically this
error occurs whenever a query sequence is less than five nucleotides (and
is independent of the length of sequences in the database file). Besides,
it's not specific to the Debian package. I encountered the same error when
I compiled from the upstream source, but it went away when I downloaded the
compiled binary, so it's probably something to do with the way it is
compiled.

I've reported this on the Github issue page here
 along with the smallest
dataset that can be used to reproduce this issue. Maybe now we wait for
upstream to take a look?

Regards,
Pranav
ᐧ

On Fri, May 22, 2020 at 3:37 AM Andreas Tille  wrote:

> On Thu, May 21, 2020 at 06:33:05PM +0530, Pranav Ballaney wrote:
> > Yes, I've been able to reproduce and roughly pin point the issue, but it
> > needs some more work before it's solved.
>
> That's pretty good news.  Just take the time you need.
>
> Thanks for your effort
>
>   Andreas.
>
> --
> http://fam-tille.de
>

Bug#810865: parking infinoted.service

[Geert Stappers]

Parking this infinoted.service  in this issue. 

[Unit]
Description=infinoted server for Gobby collaborative text editor
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/infinoted-0.7
;At boot the service does not sart
;Adding --daemonize does not work either
;ExecStart=/usr/bin/infinoted-0.7 --daemonize

[Install]
WantedBy=multi-user.target


To be continued
Geert Stappers
-- 
Silence is hard to parse

Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong

[Petter Reinholdtsen]

[Al Stone]
> Hrm.  So write access seems to be more constrained than this led
> me to believe; I'll try these patches out and rebuild tonight.  I
> did think about using AUTOPKGTEST_TMP but had not convinced myself
> it was absolutely required.

Note, I am not convinced this will help, as I am flying blind without
the error messages, but thought it best to play it safe and use
AUTOPKGTEST_TMP just in case.  After all the 'hello' test seem to work,
and it would try to save directly to cwd which should be the top of the
source tree. :/

> Thank you for all the help, Petter!

Just glad to be of assistance. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#962142: python-rsa: CVE-2020-13757

[Salvatore Bonaccorso]

Source: python-rsa
Version: 4.0-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/sybrenstuvel/python-rsa/issues/146
Control: found -1 4.0-2

Hi,

The following vulnerability was published for python-rsa.

CVE-2020-13757[0]:
| Python-RSA 4.0 ignores leading '\0' bytes during decryption of
| ciphertext. This could conceivably have a security-relevant impact,
| e.g., by helping an attacker to infer that an application uses Python-
| RSA, or if the length of accepted ciphertext affects application
| behavior (such as by causing excessive memory allocation).


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13757
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13757
[1] https://github.com/sybrenstuvel/python-rsa/issues/146

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#962137: FTBFS when building architecture independent packages only

[Daniel Baumann]

Package: nghttp2
Version: 1.41.0-1
Severity: normal

Hi,

when building nghttp2 arch-indep packages only (aka dpkg-buildpackage
-A), it currently fails:

---snip---
   dh_prep -i
   debian/rules override_dh_auto_install-indep
make[1]: Entering directory '/build/nghttp2-1.41.0-1'
mkdir -p "debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"
cp -pr doc/manual/html/*
"debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"
rm "debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"/objects.inv
ln -sf /usr/share/javascript/jquery/jquery.js
"debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"/_static/jquery.js
ln -sf /usr/share/javascript/underscore/underscore.js
"debian/libnghttp2-doc/usr/share/doc/libnghttp2-doc"/_static/underscore.js
dh override_dh_auto_install-indep
make[1]: Leaving directory '/build/nghttp2-1.41.0-1'
   dh_install -i
   dh_installdocs -i
dh_installdocs: Cannot find (any matches for)
"usr/share/doc/nghttp2/README.rst" (tried in ., debian/tmp)

make: *** [debian/rules:68: binary-indep] Error 9
---snap

Regards,
Daniel

Bug#962135: [Pkg-zsh-devel] Bug#962135: patch for bugs 962133 and 962135

[Vincent Lefevre]

Hi Axel,

On 2020-06-03 20:28:11 +0200, Axel Beckert wrote:
> Daniel: Would you review it for upstream inclusion?
> 
> > I've added a note about that:
> > 
> > # Note: Packages may be marked as "deinstall" or "purge", i.e. selected
> > # for deinstallation or to be purged (see dpkg(1) man page); this means
> > # that the operation has not been completed yet. In the meantime, such
> > # packages may still be installed (if marked as purge, one is not sure,
> > # though, as the package could have been uninstalled but not purged yet),
> > # so that purge and remove operations remain valid.
> 
> *sigh* IMHO this is highly misleading.
> 
> The difference between dpkg "states" (i.e. the current state) and
> "selection states" (i.e. the wanted state) only matters if you use
> dselect, which nearly nobody does nowadays.
> 
> So please do _not_ refer to "selection states" in such places since
> "selected for deinstallation" always sounds as if deinstallation is
> imminent while it in 99.9% of all cases already has happened, possibly
> even years ago.

Well, the dpkg(1) man page says "selection states" and
"selected for deinstallation":

  Package selection states
install
   The package is selected for installation.

hold   A  package  marked  to be on hold is not handled by dpkg, unless
   forced to do that with option --force-hold.

deinstall
   The package is selected for  deinstallation  (i.e.  we  want  to
   remove all files, except configuration files).

purge  The  package  is  selected  to be purged (i.e. we want to remove
   everything from system directories, even configuration files).

unknown
   The package selection is unknown.  A package that is also  in  a
   not-installed  state,  and  with an ok flag will be forgotten in
   the next database store.

Do you mean that this man page should be modified?

> > My patch also removes "deinstalled" from _deb_packages as it does not
> > seem to be used (and should be useless).
> 
> Not sure if this is wanted. That code might have been made "complete"
> on purpose for 3rd-party (or future internal) usage. I'd not remove it.

Perhaps, but why aren't there equivalent functions for the "install"
and "purge" states, then?

Note that this is not documented, so I thought that this was just
internal, and 3rd party code should have its own functions.

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