Bug#875305: Support for finding changelog.Debian.gz in perl-base

[Stuart Prescott]

I've rolled the patches attached to this bug into a merge request on salsa 
(with some minor updates as debfile.py itself has changed slightly since they 
were submitted).

https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/32

However, looking carefully at Policy §12.7, searching in /usr/share/doc/
$source/ would be the wrong thing to do. 

https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes

Non-native packages are required to have /usr/share/doc/$package/
changelog.Debian.gz but the directory (or perhaps the file) can be a symlink; 
this is the case for perl-base that is cited in the bug report.

$ dpkg -S /usr/share/doc/perl-base
perl-base: /usr/share/doc/perl-base

$ ls -l /usr/share/doc/perl-base
lrwxrwxrwx 1 root root 4 Nov 10  2017 /usr/share/doc/perl-base -> perl/

$ dpkg -L perl-base | grep changelog
/usr/share/doc/perl/changelog.Debian.gz

and therefore "/usr/share/doc/perl-base/changelog.Debian.gz" exists, but only 
via a symlink.

The correct approach to finding the changelog is probably not to look at source 
package names, but to try to follow symlinks within the .deb

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Rafael Laboissière]

Control: tags -1 - wontfix
Control: tags -1 + fixed-in-experimental

* Brendon Higgins  [2020-12-04 18:06]:


On Friday, November 27, 2020 3:06:12 P.M. EST Rafael Laboissière wrote:

Control: tags -1 + wontfix


I'm getting bitten by this bug on my workstation. I also tried it from within 
a fresh user account: same issue there, so it's not a user configuration 
mistake. From a user perspective, wontfix is not a particularly satisfying 
conclusion.


As Michael Miller pointed out, this problem is fixed in version 6.1.0-1 
of the octave package, which is now in experimental.  There is an ongoing 
transition octave 5 ⇒ 6 (or liboctave 7 ⇒ 8, or octave-abi 53 ⇒ 55) [1]. 
Hopefully this will be done before the bullseye freeze.


Best,

Rafael Laboissière

Bug#966395: Any plans on doing this for Bullseye?

[Amos Jeffries]

On 2/12/20 10:36 pm, Santiago Garcia Mantinan wrote:

I'd like to know if there are any plans on having Bullseye version compiled
with --with-openssl,



I am leaving the decision to Luigi for libssl1 builds.


For my part I will only add it for libssl3 or later where we do not have 
to rely on a technicality. The upstream work still needs some help 
testing changes against libssl 1.1.



Amos

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

[Graham Inggs]

Hi tony

On Sat, 5 Dec 2020 at 01:25, tony mancill  wrote:
> I'd like to kick the debci job again to confirm
> before I mark the bug as closed in 0.12.1-1, but I don't know how to do
> that.

You can retry the migration tests from gffread's tracker page [1], by
clicking on the recycle icon next to the failed test.

> According to [2], the job will retried once a month, but I don't
> see any attempts since 2020-08-23.

That's for packages that are in testing.

I have retried gffread's autopkgtests against testing and unstable,
and I still see failures on amd64 [2][3].

Regards
Graham


[1] https://tracker.debian.org/pkg/gffread
[2] https://ci.debian.net/packages/g/gffread/testing/amd64/
[3] https://ci.debian.net/packages/g/gffread/unstable/amd64/

Bug#976366: Upgrade to 247 broke keyboard input on Wayland session

[duck]

Quack,

On 2020-12-05 05:00, Michael Biebl wrote:

hidepid is known to cause problems and no longer a supported 
configuration:

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#hidepid-unsupported


Thanks for pointing this out, I did not know it was officially 
unsupported.


I was already using the workaround for logind for quite a while and it 
is working fine.


As for the polkit workaround it requires polkit from experimental. I 
tried (with systemd 246.6-5) but it seems the client also do things of 
its own and that is not sufficient.


I then disabled hidepid and polkit is now working with 246.6-5.

Switching back to 247.1-3 I'm hitting the same problem. If a polkit 
agent is absolutely necessary then I'm not sure how it's supposed to 
work since it is launched (in the recommended sway config) after a 
graphical session is created by sway and it's already too late (the 
error messages came from sway initializing inputs). I cannot run the 
polkit agent before because it complains there is no display and quit.


I have no idea how desktop environments handle this. I could not find 
anyone using sway doing differently but 247 is fairly recent.


Would you have any idea? Anything to experiment?

Regards.
\_o<

--
Marc Dequènes

Bug#976120: finalizing qabc package (Bug#976120)

[Benoît Rouits]

Dear mentors,

Thanks to the comments from some of you on bug Bug#976120 (RFS: 
qabc/2.0-1 [ITP]), I finalized at last a neat packaging (i think) of 
QAbc: minimal GUI for ABC music notation.


I am now looking for a mentor and I would be grateful, if some of you 
are interested, to let qabc be included into Debian repository.


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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/q/qabc/qabc_2.0.1-2.dsc


The source contains also a heavy modified code from abcm2ps source code 
as an embedded library wich won't be merged to upstream abcm2ps for some 
good reason ( see https://github.com/leesavide/abcm2ps/issues/80 ).


As Paul Wise told me, I will get the embedded "copy" of abcm2ps code to 
be recorded in the security team's repository if it is included into 
Debian. I will also try to backport security fixes from abcm2ps to my 
library code, despite code divergence is growing with time.


Thank you for your support,
 Benoît

Bug#976436: octave-ltfat-common,octave-ltfat: both ship /usr/share/octave/packages/ltfat-2.3.1/*

[Andreas Beckmann]

Package: octave-ltfat-common,octave-ltfat
Version: 2.3.1+dfsg-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Preparing to unpack .../octave-ltfat_2.3.1+dfsg-5_amd64.deb ...
  Unpacking octave-ltfat (2.3.1+dfsg-5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/octave-ltfat_2.3.1+dfsg-5_amd64.deb (--unpack):
   trying to overwrite '/usr/share/octave/packages/ltfat-2.3.1/AUTHORS', which 
is also in package octave-ltfat-common 2.3.1+dfsg-5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/octave-ltfat_2.3.1+dfsg-5_amd64.deb
 

execute_before_dh_installdeb-indep is supposed to move stuff around from
debian/octave-ltfat, but that target is not being run during a separate
binary-arch build.


cheers,

Andreas


octave-ltfat-common=2.3.1+dfsg-5_octave-ltfat=2.3.1+dfsg-5.log.gz
Description: application/gzip

Bug#976435: ITP: eutl -- The European Union Trust List is a collection of CA certificates of Trust Service Providers compiled by member states within the framework of the eIDAS regulation for purposes

[Bert Van de Poel]

Package: wnpp
Severity: wishlist
Owner: Bert Van de Poel 

* Package name : eutl
Version : date based?
Upstream Author : The European Union
* URL : https://ec.europa.eu/digital-single-market/en/eu-trusted-lists
* License : NA
Programming Lang: NA
Description : The European Union Trust List is a collection of CA 
certificates of Trust Service Providers compiled by member states within 
the framework of the eIDAS regulation for purposes which includes the 
verification and validation of eSignatures and eSeals


With the ongoing pandemic, a student organization I'm part of has been 
required to rely more on electronic signatures for its sponsor contracts 
with local open source companies. It has however been difficult to 
explain to those companies that a scan of a signature isn't legally 
binding. While we've signed PDF documents with PKCS#7 signatures based 
on the signing certificates on our ID cards for years, tooling around 
this procedure has been somewhat lacking. Because of our renewed 
interest, we've decided to investigate further and found out that it's 
currently easily possible to read signature information with tools such 
as poppler's pdfsig. However, it currently relies on NSS to establish 
the trust chain. This is quite problematic as the EU regulations have 
specifically stipulated the use of CAs that are ideally not used for any 
other purpose than signing ID certificates (we're not sure if it's a 
strict requirement, but it seems to be applied that way). Therefore, the 
chain of trust can't be established.
Beyond this specific use case, the EUTL is in general useful for 
establishing the chain of trust for any kind of eIDAS based eSignature 
or eSeal, on PDFs (PAdES), XML (XAdES) or other formats (CAdES). For 
tools within the FOSS ecosystem, it's now not clear how these kinds of 
signatures should be verified and validated, as the relevant CAs are not 
available for any distro. This is solved on the proprietary operating 
systems for PDFs through Adobe including the EUTL within Adobe Reader. 
I'm suggesting packaging the EUTL separately so the CAs are not just 
available to those applications who wish to verify PDF signatures (PAdES 
or common PKCS#7), but also other types of signatures based on the same 
eIDAS concepts.


I hope that this shows from both a practical and a more ideological 
point of view why the inclusion of the EUTL within Debian is relevant. I 
would suggest the CAs would be save separate from existing certificate 
locations, so they are isolated from those used within browsers and 
other applications, but the path can then be included (or even 
pre-compiled) within tools such as pdfsig.


Some useful links:
- https://ec.europa.eu/digital-single-market/en/eu-trusted-lists
- https://webgate.ec.europa.eu/tl-browser/#/
- https://tsl.belgium.be/
- https://en.wikipedia.org/wiki/Trust_service_provider
- 
https://ec.europa.eu/digital-single-market/en/policies/trust-services-and-eidentification


If any further information is required, I will try to help as much as I 
can. I'm however not a specialist within eIDAS or eSignatures (and not a 
lawyer either), but happen to think eSignatures are a safer options with 
the ongoing pandemic and a good way to save a tree by using less paper.

Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

[gregor herrmann]

On Thu, 03 Dec 2020 21:42:33 -0800, Felix Lechner wrote:

> Please have a look at this commit. It explains how to mitigate
> expected upcoming breakage in your package.
> 
>
> https://salsa.debian.org/lintian/lintian/-/commit/d2f692f564ac725a0eb58a7d62abe57f66cdc753
> 
> Please load the policy data with:
> 
> my $data = $profile->load_data(...);
> 
> instead of
> 
> my $data = Lintian::Data->new(...);

This doesn't work in a current sid chroot.
Probably because the change in lintian isn't uploaded yet.
This means we can't make this change (as in: uploading a change)
right now.

If you want us to make this change please provide a tested and
working MR, including required changes in d/control (aka minimum
required lintian version, which actually is in the archive).
 
> That is a temporary fix; the interface is scheduled to change again in
> the near future. Thank you!

Ehm, sorry, this sounds quite unattractive. My personal motivation to
play catchup with lintian changes is, hm, limited. Could we maybe
wait for a fix for #968154 in debian-policy?

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Mark Knopfler: The Ceilidh And The Northern L


signature.asc
Description: Digital Signature

Bug#976434: [cargo] please update to v1.44+

[Lyndon Brown]

Package: cargo
Version: 0.43.1-4

Please can cargo be updated to v1.44 (0.46). It would be nice to be
able to make use of `cargo tree`.

Thanks for getting rustc updated the other day to 1.48 which means I
can play with intra-doc-links. :D

Bug#976433: debian-crossgrader: Please include Vcs-* fields in debian/control

[Stuart Prescott]

Source: debian-crossgrader
Version: 0.0.3
Severity: minor

Dear Maintainer,

The Debian package, via debian/control, can declare where the package is
maintained, for example Vcs-Git and Vcs-Browser for this package should
indicate that it is maintained on salsa. It's nice to do this so that people
can help out, find the most recent versions etc.

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-vcs-fields

https://wiki.debian.org/Salsa/Doc#Canonical_URLs

(it's also unusual for the VCS on salsa to have a different name to the source
package itself: debian-crossgrader vs debian-crossgrading)

Thanks for maintaining this interesting package!

regards
Stuart

Bug#976432: buster-pu: package python-certbot/0.31.0-1

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: hlieber...@debian.org, team+letsencr...@tracker.debian.org

Hello Release Team!

As part of the deprecation of the Let's Encrypt v1 endpoint beginning in
January, they are going to begin causing intermittant failures increasing to a
complete shutdown June 2021.

To prevent users from being affected by this transition, I've prepared a
backport of the piece of code that switches renewals automatically to v2. In
this version of the code, new certificates were already being issued through the
v2 URL.

A debdiff is attached.

Sincerely,

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-certbot-0.31.0/debian/changelog 
python-certbot-0.31.0/debian/changelog
--- python-certbot-0.31.0/debian/changelog  2019-02-09 19:39:59.0 
-0500
+++ python-certbot-0.31.0/debian/changelog  2020-12-04 21:33:11.0 
-0500
@@ -1,3 +1,15 @@
+python-certbot (0.31.0-1~deb10u1) buster; urgency=high
+
+  * Switch to use of ACMEv2 API to prevent renewal failures. (Closes: #971045)
+
+Let's Encrypt's ACMEv1 API is deprecated and in the process of being
+shut down. Beginning with brownouts in January 2021, and ending with a
+total shutdown in June 2021, the Let's Encrypt APIs will become
+unavailable. To prevent users having disruptions to their certificate
+renewals, this update backports the switch over to the ACMEv2 API.
+
+ -- Harlan Lieberman-Berg   Fri, 04 Dec 2020 21:33:11 
-0500
+
 python-certbot (0.31.0-1) unstable; urgency=medium
 
   * New upstream version 0.31.0
diff -Nru python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch 
python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch
--- python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch  1969-12-31 
19:00:00.0 -0500
+++ python-certbot-0.31.0/debian/patches/0002-acmev2-api.patch  2020-12-04 
21:30:36.0 -0500
@@ -0,0 +1,88 @@
+From 8a15bd7927e2b8956bb1f4d062423e471e473ccf Mon Sep 17 00:00:00 2001
+From: Alex Zorin 
+Date: Thu, 21 May 2020 22:58:40 +1000
+Subject: [PATCH 1/2] renewal: disregard acme-v01 in renewal configs
+
+Fixes #7979
+---
+ certbot/_internal/constants.py |  2 ++
+ certbot/_internal/renewal.py   | 17 +++--
+ certbot/tests/renewal_test.py  |  8 
+ 3 files changed, 25 insertions(+), 2 deletions(-)
+
+Index: python-certbot/certbot/constants.py
+===
+--- python-certbot.orig/certbot/constants.py
 python-certbot/certbot/constants.py
+@@ -120,6 +120,8 @@ CLI_DEFAULTS = dict(
+ )
+ STAGING_URI = "https://acme-staging-v02.api.letsencrypt.org/directory;
+ 
++V1_URI = "https://acme-v01.api.letsencrypt.org/directory;
++
+ # The set of reasons for revoking a certificate is defined in RFC 5280 in
+ # section 5.3.1. The reasons that users are allowed to submit are restricted 
to
+ # those accepted by the ACME server implementation. They are listed in
+Index: python-certbot/certbot/renewal.py
+===
+--- python-certbot.orig/certbot/renewal.py
 python-certbot/certbot/renewal.py
+@@ -17,6 +17,7 @@ import OpenSSL
+ from acme.magic_typing import List  # pylint: disable=unused-import, 
no-name-in-module
+ 
+ from certbot import cli
++from certbot import constants
+ from certbot import crypto_util
+ from certbot import errors
+ from certbot import interfaces
+@@ -247,16 +248,28 @@ def _restore_int(name, value):
+ raise errors.Error("Expected a numeric value for {0}".format(name))
+ 
+ 
+-def _restore_str(unused_name, value):
++def _restore_str(name, value):
+ """Restores an string key-value pair from a renewal config file.
+ 
+-:param str unused_name: option name
++:param str name: option name
+ :param str value: option value
+ 
+ :returns: converted option value to be stored in the runtime config
+ :rtype: str or None
+ 
+ """
++# Previous to v0.5.0, Certbot always stored the `server` URL in the 
renewal config,
++# resulting in configs which explicitly use the deprecated ACMEv1 URL, 
today
++# preventing an automatic transition to the default modern ACME URL.
++# (https://github.com/certbot/certbot/issues/7978#issuecomment-625442870)
++# As a mitigation, this function reinterprets the value of the `server` 
parameter if
++# necessary, replacing the ACMEv1 URL with the default ACME URL. It is 
still possible
++# to override this choice with the 

Bug#976431: lld: missing wasm-ld symlink

[Jonas Smedegaard]

Package: lld
Version: 1:11.0-51
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

lld-11 includes wasm-ld-11, but lld is missing symlink wasm-ld.
Emscripten expects to find unversioned wasm-ld.

Please have lld include that symlink.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/K8K0ACgkQLHwxRsGg
ASECHg/9EFxrpeiS517AamcaDKzIqBjBQKV5uR772yDQHUELfdpE5X/R+KUQNdPR
XYSHQmoudrt+mdSZ8d5VTX/xHUl30FDhzbfeNR6m6lE5DIPzKg0II4XWGm4VM33T
40PooBrxUk7NpWoCnVu3ahlKFqXQlT/6xaz5XPBY7VkPZZDo7wt162SmecUjPhw8
26M7UM2YYxJIQtiE7Zu5KjETf8s1CoIAgdbOkjwJ2sftDUJw0e8fKPPw99f2TUTw
VuDSMgnGKpfoKlb+VQ27iklqdhApgmtEJsXRCAgGceT9Z42JOj+AWjywpCayCbC6
N1S1Hy+0vwKuVL9Dn5hhdffrJUT+MZiaBq8hEKIvpRHshfAnd7gRdVoM7296M+AQ
uvGcWhqmNdqJY7lMMJzg65eIKx85dKzrcHVFR6D8ymtQJEUYujY2E9cqa/AfXrn5
T61lziOkkZ//9SqSLj5JgTvDaywY3ibtdmTK2ZcghhfIoi2Iy/OpsfDEgkCDEPjd
A/8wsRmN8jsa3IHpQ19Hjr9DINJJF5CQt6A7pGx2rw0kXmGCU/RVg3hWmRLuExRH
Nc0Ekrp8FXh74stOZPEJd63p386aofHJ/JBobyfofgLtx+GX2QPe+6f4TsjGZhm3
uN2nuNtbnBTlA4MoHZ/ydrUblTiaOTTH/U7kEdVY34TnxQu4vlw=
=1Gl9
-END PGP SIGNATURE-

Bug#976260: RFS: opentype-sanitizer/8.1.0-1 [ITP] -- tools to validate and sanitize OTF/TTF/WOFF/WOFF2 font files

[Paul Wise]

On Fri, 2020-12-04 at 16:16 +0100, Romain Porte wrote:

> Version opentype-sanitizer_8.1.1+dfsg.1-1 uploaded to mentors.

Uploaded to NEW.

For future uploads please file an RFS again and I will get to it when I
am able to do so.

> Done, two warnings remain with `lintian -EviIL +pedantic`:

lintian 2.104.0 also shows this one:

I: opentype-sanitizer source: out-of-date-standards-version 4.5.0 (released 
2020-01-20) (current is 4.5.1)

> This is intentional, to introduce the most used tool first for other
> packages to advance. Adding libfreetype2 will provide additional
> binaries which I do not intent to write man pages at the moment, as
> these tools are less used and not depended on by other packages. This
> can be fixed in a later 8.1.1+dfsg.1-2 release.

It is perfectly acceptable to have binaries without manual pages,
especially if they print usage information from --help or similar.
Agreed that this can be fixed later though.

One additional thing to fix for the next upload:

The BSD license text you have adopted is not quite the same as the
upstream one, so in theory they should be the BSD-3-Clause-Google and
the BSD-3-Clause-Debian licenses rather than both BSD-3-Clause.

If you were to adopt the exact same license text for both then you
could deduplicate the licenses in debian/copyright like this:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#examples

   Files: *
   Copyright: 2009-2017 The OTS Authors.
   License: BSD-3-Clause
   
   Files: debian/*
   Copyright: 2020 Romain Porte
   License: BSD-3-Clause
   
   License: BSD-3-Clause


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Witold Baryluk]

Yes, we can close it.

If I ever find the reason why, or it happens again, I will simply reopen and
post updates.

Thanks for your patience and work on Libreoffice in Debian, Rene.

Regards,
Witold



On Fri, 4 Dec 2020 at 08:13,  wrote:
>
> Hi,
>
> Am 4. Dezember 2020 04:25:42 MEZ schrieb Witold Baryluk 
> :
> >Hi Rene and others,
> >
> >Libreoffice started working again for me, no more segfaults or apparmor
> >issues.
> >
> >I can't reproduce the original issue anymore.
> >
> >linux-image-5.9.0-3-amd64 5.9.9-1
> >libreoffice 1:7.0.3-4+b1
> >apparmor 2.13.5-1+b1
>
> Interesting.
>
> Can we close this then or do you still want to debug what it was (and whether 
> there is a chance of coming it back)?
>
> Regards
>
> René
>

Bug#976430: libfreecad-python3-0.19: missing Breaks+Replaces: libfreecad-python3-0.18

[Andreas Beckmann]

Package: libfreecad-python3-0.19
Version: 0.19~pre1+git20201123.8d73c8f0+dfsg1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package libfreecad-python3-0.19.
  Preparing to unpack 
.../5-libfreecad-python3-0.19_0.19~pre1+git20201123.8d73c8f0+dfsg1-1_amd64.deb 
...
  Unpacking libfreecad-python3-0.19 (0.19~pre1+git20201123.8d73c8f0+dfsg1-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-ZRBq6k/5-libfreecad-python3-0.19_0.19~pre1+git20201123.8d73c8f0+dfsg1-1_amd64.deb
 (--unpack):
   trying to overwrite '/usr/lib/freecad-python3/lib/DraftUtils.so', which is 
also in package libfreecad-python3-0.18 0.18.4+dfsg2-6
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-ZRBq6k/5-libfreecad-python3-0.19_0.19~pre1+git20201123.8d73c8f0+dfsg1-1_amd64.deb


cheers,

Andreas


libfreecad-python3-0.18=0.18.4+dfsg2-6_libfreecad-python3-0.19=0.19~pre1+git20201123.8d73c8f0+dfsg1-1.log.gz
Description: application/gzip

Bug#976429: jellyfish: missing Breaks+Replaces: jellyfish-examples (<< 2.3.0-7)

[Andreas Beckmann]

Package: jellyfish
Version: 2.3.0-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../jellyfish_2.3.0-7_amd64.deb ...
  Unpacking jellyfish (2.3.0-7) over (2.3.0-6+b2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/jellyfish_2.3.0-7_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/jellyfish/bin/fastq2sam', which is also in 
package jellyfish-examples 2.3.0-6
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/jellyfish_2.3.0-7_amd64.deb
 

cheers,

Andreas


jellyfish-examples=2.3.0-6_jellyfish=2.3.0-7.log.gz
Description: application/gzip

Bug#929530: libsis-base-java: unaligned access on armhf

[tony mancill]

On Wed, Dec 02, 2020 at 08:59:16PM +0100, Andreas Tille wrote:
> Control: tags -1 help
> 
> I wonder whether some Java expert might be able to clarify the
> situation in bug #929530.

Hi Andreas,

There is good news and bad news... :)  The good news is that the
unaligned access error is no longer an issue on armhf.  I am able
to compile without JVM crashing on the amdahl porter box:

Java VM: OpenJDK 64-Bit Server VM (v11.0.9.1+1-post-Debian-1)
CPU Architecture: aarch64
OS: Linux (v4.19.0-12-arm64)

I've run the build at least 6 times by now and not observed any issues
with the JVM.

The bad news is that tests are consistently failing.  Specifically, the
code [1] that runs after this test [2] fails consistently while trying
to clean up after the test with the error below:

[1] 
https://salsa.debian.org/med-team/libsis-base-java/-/blob/master/source/java/ch/systemsx/cisd/base/tests/AbstractFileSystemTestCase.java#L139
[2] 
https://salsa.debian.org/med-team/libsis-base-java/-/blob/master/sourceTest/java/ch/systemsx/cisd/base/unix/UnixTests.java#L121


Running testTouchSymLinkAndFileRealtimeTimer
Could not delete the directory 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 
exceptions: [java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink]
Could not delete the directory 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests in second try 
because: 1 exceptions: [java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink]
Exception in thread "main" org.apache.commons.io.IOExceptionList: 1 exceptions: 
[java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink]
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:345)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1206)
at 
ch.systemsx.cisd.base.tests.AbstractFileSystemTestCase.afterClass(AbstractFileSystemTestCase.java:139)
at ch.systemsx.cisd.base.unix.UnixTests.main(UnixTests.java:495)
at ch.systemsx.cisd.base.AllTests.main(AllTests.java:56)
Caused by: java.io.IOException: Unable to delete file: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1425)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:338)
... 4 more
Caused by: java.nio.file.NoSuchFileException: 
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someLink
at 
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at 
java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at 
java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:149)
at 
java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.base/java.nio.file.Files.readAttributes(Files.java:1763)
at java.base/java.nio.file.Files.size(Files.java:2380)
at org.apache.commons.io.file.PathUtils.deleteFile(PathUtils.java:361)
at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:304)
at org.apache.commons.io.file.PathUtils.delete(PathUtils.java:280)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1423)
... 5 more

However the symlink *is* present after the build (I have to remove it from
the build tree manually), so I don't know yet whether this is an issue
with the code on this architecture or something about how I'm using the
schroot on the porterbox.

In any event, my inclination is to close the unaligned access bug and
open a new bug for the test failure on this architecture.  I can't
reproduce it on amd64.

Cheers,
tony

Bug#976227: O: breathe -- Sphinx autodox support for languages with doxygen support

[Chris Knadle]

Melvin Vermeeren:

Hi,

I am the current maintainer of Breathe upstream[1] and also a Debian user
since a few years after having switched distribution. If I possible I would
like to also (help?) maintain Breathe in Debian in some way.

Currently I'm not an official Debian maintainer, though I do have a around a
year experience by now in maintaining an unofficial Debian repository[2],
mainly for additional backports. Said repo is currently undergoing some rework
to improve correctness and automation. On Salsa[3] I open up MRs for buster
bugfixes if I find anything cumbersome as I'm used to the GitLab workflow.

[1] https://github.com/michaeljones/breathe
[2] https://mel.vin/debian/
[3] https://salsa.debian.org/vermeeren

In some form of sponsorship or helping out possible? I could for example do
some maintaining in a fork on Salsa and submit MRs to the real Salsa repo for
a final check by someone with proper maintainer permissions. It has been a
while since I read the specifics of sponsorship etc so I am not entirely sure
what the options are.

Had a very nice exchange of emails with Chris Knadle, the maintainer of
Mumble, quite a while ago. Adding in the CC both for general interest and
perhaps for some ideas. Looking forward to hearing what can be done!

Thanks,


Hello Melvin.

I looked up the bug CCed in the email and see that the Breathe package was 
marked as Orphaned via the BTS; however the package still has a listed 
maintainer instead of Debian QA Group , meaning the full 
orphaning of the package hasn't been completed yet. More explanation here:


https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package

At the moment all this means is that the Breathe package in Debian will have no 
official maintainer -- it doesn't necessarily mean that the package will be 
removed from the archive soon. Package removals happen sometimes for packages 
that go out of maintenance for an extended period, but this package was only 
_just_ been (partially) orphaned, so as far as I know, the situation is not 
"alarming". Breathe has now joined 1175 other packages that have been orphaned 
-- you can see a list of them here, many of which have been orphaned for several 
years:


  https://www.debian.org/devel/wnpp/orphaned

In terms of the Breathe package itself, I'm unfamiliar with it... and to date 
I've never used Doxygen or Sphinx, I'm not (yet) familiar with reStructuredText, 
and at the moment I'm only doing sporadic Python3 programming. Debian Developers 
are encouraged to be familiar with the packages that they upload or in 
sponsoring for uploads in case there are bugs in the package that require 
familiarity to fix. I'm probably not the right maintainer to sponsor uploads 
directly, but I /am/ interested in helping guide you through the process of 
getting you what you need to take care of the package. I'd likely be comfortable 
helping do NMUs (non-maintainer uploads) for targeted bug fixes, and I would 
also be comfortable helping with preparing and/or reviewing package uploads to 
mentors.debian.net to help get a sponsor for uploads.


   https://mentors.debian.net/sponsors/

And assuming you'd like to take over for maintenance of the breathe Debian 
package yourself and have sponsored uploads, the next step for that would be to 
file an "ITA" (Intent To Adopt) bug, I believe. It seems you've got some Debian 
package development experience already, so this seems quite fitting. There's 
some additional explanation of the "ITA:" bug subject here:


   https://wiki.debian.org/how-can-i-help

Strangely I don't see the "ITA:" bug explained in the Debian Developer's 
Reference guide under "Adopting a package", which I would like to see updated 
for that.


https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package

mel.vin Debian repo
=-=-=-=-=-=-=-=-=-=

I had a quick look at your Debian repository at the [2] link from your email and 
wonder how the package list is being updated -- if the package list being 
automatically generated I would be interested in knowing how to do that. ;-)


The other thing I noticed in the list of packages is that there's a mumble 
backport package. The maintainer for the Mumble backport in Debian hasn't done 
an upload for 2 years, so if you'd be interested in seeing your backport 
uploaded to Debian backports directly, that would be something I'd be interested 
in talking about.


Thanks and talk to you soon.
   -- Chris

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976144: Re[2]: Bug#976144: librttopo1: buggy/missing geojson support

[Roman K]

Hi, 
>Понедельник, 30 ноября 2020, 15:56 +03:00 от Sebastiaan Couwenberg 
>:
> 
>reassign 976144 src:librttopo
>found 976144 librttopo/1.1.0-2
>thanks
>
>Hi Roman,
>
>On 11/30/20 1:31 PM, Roman Kurakin wrote:
>> Since librttopo is suggested as a replacement for liblwgeom, and the part of 
>> it
>> functionality is missing (switched off by ifdef) the bug becomes critical.
>>
>> Functionality is switched off due to missing code in configure. Looks like it
>> was lost while fork from original liblwgeom (part of postgis project).
>>
>> All of the versions currently in debian are affected by this problem.
>Thanks for the patch, but I'm hesitant to apply it as it's a little
>invasive.
>
>Currently libspatialite is the only user of librttopo, and it likely
>doesn't need the geojson support.
But what should do packages that are not part of debian?
liblwgeom is removed from postgis 3.0...
>
>Please forward your changes upstream:
>
>  https://git.osgeo.org/gitea/rttopo/librttopo
>
>Once the changes are applied upstream we can consider included them in
>the Debian package.
Already done, but project doesn’t look as actively maintained, the bug was 
described three years ago,
but bug reporter was unable to provide a patch.
https://git.osgeo.org/gitea/rttopo/librttopo/issues/21#issuecomment-8877
>
>Kind Regards,
>
>Bas
>
>--
> GPG Key ID: 4096R/6750F10AE88D4AF1
>Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 
 
 
--
Best regards,
rikbsd
 

Bug#913062: Re-enable laptop display output

[Drake Diedrich]

I have a similar bug on a laptop with both Intel UHD graphics and an NVidia
GPU.  Without Nvidia loaded, behavior on unlock is as expected.  With
nvidia modules loaded, even though not used for display, something is
disabling the display _after_ I unlock the screen (screen comes up from
sleep and is enabled until I unlock.   So not a driver issue I think.  I
don't think it's a black window either, because

chvt 7 && sleep 3 && xrandr -d :0 --output eDP-1 --auto

works to recover from it (from a console terminal). Something chooses to
disable output to the display, on _restore_.  I haven't found what it is
though.
(sleep 3 isn't necessary, just for my own sanity to see the pause and avoid
other races if chvt returns a bit early.)

-Drake

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

On Fri, Dec 4, 2020 at 6:39 PM Bill Allombert  wrote:

> On Fri, Dec 04, 2020 at 06:23:44PM -0500, David Steele wrote:
> > On Fri, Dec 4, 2020 at 6:21 PM David Steele  wrote:
> >
> > >
> > > On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert 
> wrote:
> > >
> > >>
> > >> Are people using /usr/bin/todo in script or Makefile ?
> > >> Are they likely to still work with the alternatives ?
> > >>
> > >
> > > I'd say no. It is an interactive end-user command.
> > >
> > > This gives flexibility in what they are interacting with.
> > >
> >
> > This is no more of a stretch than "vi" implementing "editor".
>
> Note that even in this case there is a minimal common interface required
> so that programms can call '/usr/bin/editor file' to let the user edit
> 'file'.
>

With devtodo added to the providers, the core "todo" capability will always
give you a
list of current tasks. Devtodo uses different endpoints to go beyond that
capability.

https://www.mankier.com/1/devtodo

Bug#976428: kubernetes: vendored parts usefull for other packages

[Thorsten Alteholz]

Source: kubernetes
Version: 1.19.4-2
Severity: wishlist
X-Debbugs-Cc: deb...@alteholz.de

I am in a similar situation as Reinhard mentioned in #970331

In my case I would like to package terraform for Debian, which 
among others depends on:

 Build-Dependency "k8s.io/utils"
 Build-Dependency "k8s.io/api"
 Build-Dependency "k8s.io/client-go"
 Build-Dependency "k8s.io/apimachinery"

Those seem to be part of the kubernetes package already and I would be 
very glad if I could just use them instead of maintaining my own copies.


  Thorsten

Bug#974075: ugene: FTBFS with Qt 5.15

[tony mancill]

On Fri, Dec 04, 2020 at 11:01:59PM +0100, Andreas Tille wrote:
> On Fri, Dec 04, 2020 at 12:52:07PM -0800, tony mancill wrote:
> > Hi Debian-Med, hi Steffen:
> > 
> > I grabbed this bug to fix the QPainterPath include and noticed that
> > packaging of 36.0 is underway on the master branch.  I have updated the
> > debian/patches to apply against this new upstream version and the
> > package is building for me locally.  That commit has been pushed.
> > 
> > However, I noticed that Steffen listed a TODO in the changelog:
> > 
> > > * TODO: package new runtime dependencies: clark, wevote
> > 
> > Should I also create a branch for 34.0 to fix the FTBFS bug and upload?  Or
> > will that just create noise - i.e., should I wait on the new runtime
> > deps for 36.0?
> 
> I think fixing the FTBFS is valuable in any case.  However, may be
> chacking the effort the new packages clark and wevote might make is
> sensible since we would love to deliver the latest version of our
> packages at freeze time so the goal to provide those new dependencies is
> set anyway.

Since it was quick enough to fix the Qt issuse, I went ahead and built
a 34.0+dfsg-2 package and pushed a 34.0+dfsg branch and the
corresponding debian/34.0+dfsg-2 tag to the Salsa repo.

Cheers,
tony

Bug#976427: plocate: Please keep cron script for use without systemd

[Steinar H. Gunderson]

On Sat, Dec 05, 2020 at 12:18:26AM +0100, GSR wrote:
> Last update removed cron script, which was working OK. Not everyone
> uses systemd timers, so please keep the script.

Hi,

The cron script did the wrong thing from 1.1.0:

 - It depended on mlocate's database.
 - It would do double-work on top of the systemd timer.

I'm happy taking a patch to add back a script that fixes both of these
issues, ie., runs updatedb.plocate instead of plocate-build, and does not run
if the systemd timer would run instead. Would you like to contribute one?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#976377: RM: sqlite/2.8.17-15, golang-gosqlite-dev/0.0~hg20130601-1

[Adrian Bunk]

On Fri, Dec 04, 2020 at 08:01:03PM +0100, Paul Gevers wrote:
>...
> On 04-12-2020 11:10, Simon McVittie wrote:
> > Please mark golang-gosqlite-dev and sqlite for removal from testing.
> > sqlite version 2 has been unsupported since 2005 and its removal from
> > Debian was first proposed in 2010; golang-gosqlite-dev is the last
> > remaining reverse-dependency in testing, and has no rdeps itself.
> > See https://bugs.debian.org/607969 for more information.
> 
> Any reason why you don't request this from unstable? That's the normal
> route that packages are removed from testing.

The normal route are actually autoremovals,
not immediate removals from unstable.

The problem here is that popcon makes src:sqlite a key package due
to past rdeps.

> Paul

cu
Adrian

Bug#974168: [Debian-med-packaging] Bug#974168: Bug #974168: bioperl-run: autopkgtest issue fixed, now different build time error

[Étienne Mollier]

Hi again,

I pushed a couple of changes on salsa[0] to unlock the situation
with BEDtools integration in bioperl-run.  Now the vast majority
of tests are passing.  :)

[0] https://salsa.debian.org/med-team/bioperl-run

One of the datasets in use by the bedtools related functions is
not available in the archive, so I had to change for another
dataset which seemed to do the job as well.  However, this
impeded the reference results of 7 tests (out of more 423, which
is a really good score).  For ulterior reference, the failing
tests with the alternate dataset were returning:

#   Failed test ' - number of lines'
#   at t/BEDTools.t line 331.
#  got: '87'
# expected: '38'

#   Failed test 'correct number of features for command 'intersect''
#   at t/BEDTools.t line 361.
#  got: '1305'
# expected: '72534'

#   Failed test 'correct number of features for command 'closest''
#   at t/BEDTools.t line 361.
#  got: '2121'
# expected: '845'

#   Failed test 'correct number of features for command 'complement''
#   at t/BEDTools.t line 361.
#  got: '292'
# expected: '291'

#   Failed test 'correct number of features for command 'subtract''
#   at t/BEDTools.t line 361.
#  got: '1802'
# expected: '57959'

#   Failed test 'correct number of features for command 'coverage''
#   at t/BEDTools.t line 361.
#  got: '828'
# expected: '57261'

#   Failed test 'correct number of features for command 'window''
#   at t/BEDTools.t line 361.
#  got: '1331'
# expected: '74998'
# Looks like you failed 7 tests of 423.

After a couple of changes to smoothen the execution of test
suites and autopkgtest, I think the package is in an adequate
state to move forward.

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#976235: enlightenment: e switches off screen|monitor

[enno]

Hello Ross,

No change so gvfs doesn't seem to be responsible BUT 1 new finding:  I had the 
meanwile usual procedure, starting enlightenment via my ~/.xsession, the 
aforementioned switching off of the screen/monitor/display (I mean it just 
turns BLACK), the blind switch to a console VT already being logged in, waiting 
about 20 seconds, VT comes up again to life, further 20 seconds without any 
interference by me, and the screen goes black again.  I'm just resistant to the 
idea it might be a hardware error, because with flwm there's no problem at all!

Wondering.  Please let me know it there's anything I haven't worded 
sufficiently clear.

Brgds, e.

--
  //   enno@gmx.net
/\\\   Mag. Enno Deimel
  .\o
 \\  \ _  \Wisely and slow; they stumble that run fast.
\\\ \_/
gpg-fp: eefe b049 6fe6 fc0b 0ec4  f39e af6a c178 eb98 909a

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 06:23:44PM -0500, David Steele wrote:
> On Fri, Dec 4, 2020 at 6:21 PM David Steele  wrote:
> 
> >
> > On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert  wrote:
> >
> >>
> >> Are people using /usr/bin/todo in script or Makefile ?
> >> Are they likely to still work with the alternatives ?
> >>
> >
> > I'd say no. It is an interactive end-user command.
> >
> > This gives flexibility in what they are interacting with.
> >
> 
> This is no more of a stretch than "vi" implementing "editor".

Note that even in this case there is a minimal common interface required
so that programms can call '/usr/bin/editor file' to let the user edit
'file'.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976377: RM: sqlite/2.8.17-15, golang-gosqlite-dev/0.0~hg20130601-1

[Simon McVittie]

On Fri, 04 Dec 2020 at 20:01:03 +0100, Paul Gevers wrote:
> On 04-12-2020 11:10, Simon McVittie wrote:
> > Please mark golang-gosqlite-dev and sqlite for removal from testing.
> > sqlite version 2 has been unsupported since 2005 and its removal from
> > Debian was first proposed in 2010; golang-gosqlite-dev is the last
> > remaining reverse-dependency in testing, and has no rdeps itself.
> > See https://bugs.debian.org/607969 for more information.
> 
> Any reason why you don't request this from unstable? That's the normal
> route that packages are removed from testing.

There are two rdeps in unstable (golang-gosqlite-dev and kannel-sqlbox)
and I didn't want to force them to be removed from Debian entirely if
people think their maintainers haven't had enough opportunity to notice.

smcv

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

On Fri, Dec 4, 2020 at 6:21 PM David Steele  wrote:

>
> On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert  wrote:
>
>>
>> Are people using /usr/bin/todo in script or Makefile ?
>> Are they likely to still work with the alternatives ?
>>
>
> I'd say no. It is an interactive end-user command.
>
> This gives flexibility in what they are interacting with.
>

This is no more of a stretch than "vi" implementing "editor".

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#976235: enlightenment: e switches off screen|monitor

[enno]

> "Ross" == Ross Vandegrift  writes:
> enlightenment_system implements privileged actions so
> enlightnement doesn't need root to e.g. shutdown the system.
>
> enlightenment_fm implements the file manager.

I see, thx.

>> If it is of help, here's the .xsession-errors from the most
>> recent "crashed" e-launch:
>
> This is usually the most useful info.
>
> [...]
> This output shows that X has detected five outputs, and only one
> (LVDS) is connected.

I guessed so.

> Do you have the lid closed on your laptop?  I wonder if it's
> running on the closed laptop screen.  The later output about
> screen configuration only shows actions for LVDS.

I haven't investigated recent X things before this, so I just presumed that 
LVDS is my "Visual", how shall I say, well, my monitor.  And of course I 
haven't closed the lid.  BTW closing of the lid perfectly switched my laptop to 
suspend mode before this mess now--without me having configured anything (apart 
from having installed pm-utils).

> 1) From a VT run `startx xterm` (or whatever terminal you use).
> 2) Assuming X starts correctly, you should see a terminal in the
> top left.  3) Move the mouse in the term and run
> `enlightenment_start`.

Works well, opens a new Xserver (Xorg) on the chosen VT with an uxterm, then 
typing `enlightenment_start' leads to something coming up which looks like e... 
and after about 2 seconds the monitor is switched off, the hardware I'd say, as 
all VTs are included.  And again, waiting on a (console) VT for about 20" it 
switches back on.  I'm baffled.  O BTW just for info it is a HP Elitebook 
8460P, so not quite something exotic.  Was Windows7 and I installed Debian from 
USB.

As the last thing being called after my `enlightenment_start' seems to be 
gvfsd, I'll try to update gvfs-daemons to see if that might make any 
difference.  Will let you know.

Brgds, e.

--
  //   enno@gmx.net
/\\\   Mag. Enno Deimel
  .\o
 \\  \ _  \Wisely and slow; they stumble that run fast.
\\\ \_/
gpg-fp: eefe b049 6fe6 fc0b 0ec4  f39e af6a c178 eb98 909a

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Mike Miller]

On Fri, Dec 04, 2020 at 18:06:22 -0500, Brendon Higgins wrote:
> The culprit is libreadline8 (and/or readline-common). Octave GUI has no 
> complaints with the prior version 8.0-4, but after upgrading to version 
> 8.1~rc3-1, Octave GUI now complains about "undecodable token: \001b(hex)[?
> 2004h" and messes-up the command interface, as per the original report.
> 
> So, does libreadline8 cause this "bracketed paste mode" to be enabled by 
> default, now? Or perhaps something else is going on - like, perhaps /etc/
> inputrc should have been updated along with readline-common, in which case 
> we're actually getting bitten by bug #504793?

Yes, Readline version 8 enables this setting by default without any
inputrc changes.

If you only use Octave in GUI mode, you might want to use the ~/.inputrc
snippet that Rafael mentioned earlier.

Octave version 6 has modified the GUI command window to silently ignore
these escapes to suppress the "undecodable token" messages.

-- 
mike

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

[tony mancill]

On Wed, Jul 29, 2020 at 09:58:55AM +0200, Graham Inggs wrote:
> Control: reassign -1 src:gffread 0.11.8-1
> Control: severity -1 serious
> Control: tags -1 - moreinfo unreproducible
> 
> Hi
> 
> gff2aplot 2.0-13 migrated to testing and now causes gffread's
> autopkgtests to fail there [1].
> I'm reassigning this bug accordingly.
> 
> Please see the results of the recent migration-reference/0 run, dated
> 2020-07-28 18:10:16 UTC.
> I've copied what I hope is the relevant part below.

Hi Graham,

I am not able to reproduce this with the current state of the archive,
neither in unstable nor in testing:

autopkgtest gffread_0.12.1-1.dsc -- schroot sid-amd64-sbuild
autopkgtest gffread_0.12.1-1.dsc -- schroot bullseye-amd64-sbuild

Looking at the CI logs [1], I see that 0.12.1-1 failed when it was
tested right after upload, so I'm not sure what could have changed that
debci wouldn't notice.  I'd like to kick the debci job again to confirm
before I mark the bug as closed in 0.12.1-1, but I don't know how to do
that.  According to [2], the job will retried once a month, but I don't
see any attempts since 2020-08-23.

Thanks,
tony
 
[1] https://ci.debian.net/packages/g/gffread/testing/amd64/
[2] 
https://ci.debian.net/doc/file.MAINTAINERS.html#label-How+often+are+test+suites+executed-3F


signature.asc
Description: PGP signature

Bug#948244: aseprite is not in stable

[Phil Morrell]

Ah, I'm glad this has been reported already, because I was very confused
by this other example:

https://tracker.debian.org/pkg/aseprite

oldstable: 1.0.5+ds-2
stable: 1.1.6+ds-1

aseprite  |  1.0.5+ds-2|  oldoldstable |  source
aseprite  |  1.1.6+ds-1|  oldstable|  source


signature.asc
Description: PGP signature

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert  wrote:

>
> Are people using /usr/bin/todo in script or Makefile ?
> Are they likely to still work with the alternatives ?
>

I'd say no. It is an interactive end-user command.

This gives flexibility in what they are interacting with.

Bug#976427: plocate: Please keep cron script for use without systemd

[GSR]

Package: plocate
Version: 1.1.0-4
Severity: normal

Dear Maintainer,

Last update removed cron script, which was working OK. Not everyone
uses systemd timers, so please keep the script.

Thank you,
GSR
 

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages plocate depends on:
ii  libc6   2.31-5
ii  libgcc-s1   10.2.0-23
ii  libstdc++6  10.2.0-23
ii  liburing1   0.7-1
ii  libzstd11.4.5+dfsg-2

plocate recommends no packages.

plocate suggests no packages.

-- no debconf information

Bug#976426: RFS: ucommon/7.0.0-16.1 [NMU] [RC] -- lightweight C++ threading and sockets - documentation

[Bastian Germann]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "ucommon".
It was removed from testing and keeps other packages from migrating to 
testing.


 * Package name: ucommon
   Version : 7.0.0-16.1
 * URL : http://www.gnu.org/software/commoncpp/
 * License : GPL-3+ with GNU-Common-C++ exception
 * Vcs : https://salsa.debian.org/pkg-voip-team/ucommon
   Section : net

It builds those binary packages:

  ucommon-doc - lightweight C++ threading and sockets - documentation
  ucommon-utils - lightweight C++ threading and sockets - utilities
  libucommon8 - lightweight C++ threading and sockets - shared libraries
  libucommon-dev - lightweight C++ threading and sockets - development 
files


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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/ucommon/ucommon_7.0.0-16.1.dsc


Changes since the last upload:

 ucommon (7.0.0-16.1) unstable; urgency=medium
 .
   * Non-maintainer upload
   * Add missing symbol (Closes: #957895)
 .
   [ Matthias Klose ]
   * Mark one more symbol optional, not present when built with -O3
 (Closes: #923639)

Regards,

Bug#976425: ITP: libtracefs -- API to access the kernel tracefs directory

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 

* Package name: libtracefs
  Version : 0
  Upstream Author : Steven Rostedt 
* URL : https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git
* License : LGPL-2.1
  Programming Lang: C
  Description : API to access the kernel tracefs directory

It had been part of tracecmd but has been split into its own repo.
The announcement mail was at 
https://lore.kernel.org/lkml/20201120200314.21efa...@oasis.local.home/

Note: This is not needed for Bullseye and so I am only planning to upload to 
experimental for now.

--
Regards
Sudip

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Brendon Higgins]

On Friday, November 27, 2020 3:06:12 P.M. EST Rafael Laboissière wrote:
> Control: tags -1 + wontfix

I'm getting bitten by this bug on my workstation. I also tried it from within 
a fresh user account: same issue there, so it's not a user configuration 
mistake. From a user perspective, wontfix is not a particularly satisfying 
conclusion.

I noticed my laptop does not have the issue, but hasn't been updated in a 
while. So I (painstakingly) upgraded packages piecemeal, and observed Octave 
GUI's behaviour as I did...

The culprit is libreadline8 (and/or readline-common). Octave GUI has no 
complaints with the prior version 8.0-4, but after upgrading to version 
8.1~rc3-1, Octave GUI now complains about "undecodable token: \001b(hex)[?
2004h" and messes-up the command interface, as per the original report.

So, does libreadline8 cause this "bracketed paste mode" to be enabled by 
default, now? Or perhaps something else is going on - like, perhaps /etc/
inputrc should have been updated along with readline-common, in which case 
we're actually getting bitten by bug #504793?

Cheers,
Brendon

Bug#976424: vtk6: FTBFS in sid

[Gianfranco Costamagna]

Source: vtk6
Version: 6.3.0+dfsg2-5
Severity: serious
tags: patch

Hello, looks like vtk6 started FTBFS in sid, not sure if this is just a matter 
of including QtPainterPath or something else is needed

This patch seems to fix the issue, however, vtk7 and vtk9 have the very same 
code and they looks not failing...

--- vtk6-6.3.0+dfsg2.orig/Rendering/Qt/vtkQtLabelRenderStrategy.cxx
+++ vtk6-6.3.0+dfsg2/Rendering/Qt/vtkQtLabelRenderStrategy.cxx
@@ -34,6 +34,7 @@
 #include "vtkTextureMapToPlane.h"
 #include "vtkTimerLog.h"

+#include 
 #include 
 #include 
 #include 
--- vtk6-6.3.0+dfsg2.orig/Rendering/Qt/vtkQtStringToImage.cxx
+++ vtk6-6.3.0+dfsg2/Rendering/Qt/vtkQtStringToImage.cxx
@@ -25,6 +25,7 @@
 #include "vtkObjectFactory.h"

 // Qt classes
+#include 
 #include 
 #include 
 #include 



This is an example of failure log
libvtkCommonMath-6.3.so.6.3.0 ../../lib/libvtkCommonSystem-6.3.so.6.3.0 
../../lib/libvtkCommonCore-6.3.so.6.3.0 
-Wl,-rpath-link,/<>/debian/build/lib 
/<>/Rendering/Qt/vtkQtStringToImage.cxx: In member function 
‘virtual vtkVector2i vtkQtStringToImage::GetBounds(vtkTextProperty*, const 
vtkUnicodeString&, int)’:
/<>/Rendering/Qt/vtkQtStringToImage.cxx:109:16: error: aggregate 
‘QPainterPath path’ has incomplete type and cannot be defined
  109 |   QPainterPath path;
  |^~~~
/<>/Rendering/Qt/vtkQtStringToImage.cxx: In member function 
‘virtual vtkVector2i vtkQtStringToImage::GetBounds(vtkTextProperty*, const 
vtkStdString&, int)’:
/<>/Rendering/Qt/vtkQtStringToImage.cxx:140:16: error: aggregate 
‘QPainterPath path’ has incomplete type and cannot be defined
  140 |   QPainterPath path;
  |^~~~
/<>/Rendering/Qt/vtkQtStringToImage.cxx: In member function 
‘virtual int vtkQtStringToImage::RenderString(vtkTextProperty*, const 
vtkUnicodeString&, int, vtkImageData*, int*)’:
/<>/Rendering/Qt/vtkQtStringToImage.cxx:187:16: error: aggregate 
‘QPainterPath path’ has incomplete type and cannot be defined
  187 |   QPainterPath path;
  |^~~~
make[3]: *** [Rendering/Qt/CMakeFiles/vtkRenderingQt.dir/build.make:124: 
Rendering/Qt/CMakeFiles/vtkRenderingQt.dir/vtkQtStringToImage.cxx.o] Error 1
make[3]: *** Waiting for unfinished jobs
/<>/Rendering/Qt/vtkQtLabelRenderStrategy.cxx: In member function 
‘virtual void vtkQtLabelRenderStrategy::ComputeLabelBounds(vtkTextProperty*, 
vtkUnicodeString, double*)’:
/<>/Rendering/Qt/vtkQtLabelRenderStrategy.cxx:271:18: error: 
aggregate ‘QPainterPath path’ has incomplete type and cannot be defined
  271 | QPainterPath path;
  |  ^~~~
/<>/Rendering/Qt/vtkQtLabelRenderStrategy.cxx: In member function 
‘virtual void vtkQtLabelRenderStrategy::RenderLabel(int*, vtkTextProperty*, 
vtkUnicodeString, int)’:
/<>/Rendering/Qt/vtkQtLabelRenderStrategy.cxx:373:16: error: 
aggregate ‘QPainterPath path’ has incomplete type and cannot be defined
  373 |   QPainterPath path;
  |^~~~
/<>/Rendering/Qt/vtkQtLabelRenderStrategy.cxx: In member function 
‘virtual void vtkQtLabelRenderStrategy::RenderLabel(int*, vtkTextProperty*, 
vtkUnicodeString)’:
/<>/Rendering/Qt/vtkQtLabelRenderStrategy.cxx:484:18: error: 
aggregate ‘QPainterPath path’ has incomplete type and cannot be defined
  484 | QPainterPath path;
  |  ^~~~
make[3]: *** [Rendering/Qt/CMakeFiles/vtkRenderingQt.dir/build.make:111: 
Rendering/Qt/CMakeFiles/vtkRenderingQt.dir/vtkQtLabelRenderStrategy.cxx.o] 
Error 1
cd /<>/debian/build/Interaction/Widgets && /usr/bin/cmake -E 
cmake_symlink_library ../../lib/libvtkInteractionWidgets-6.3.so.6.3.0 
../../lib/libvtkInteractionWidgets-6.3.so.6.3 
../../lib/libvtkInteractionWidgets-6.3.so
make[3]: Leaving directory '/<>/debian/build'
[ 96%] Built target vtkInteractionWidgets
make  -f Views/Core/CMakeFiles/vtkViewsCore.dir/build.make 
Views/Core/CMakeFiles/vtkViewsCore.dir/depend

Can you please have a look?

G.

Bug#934167: #934167: workaround for buster users

[Robert McQueen]

I was facing the error described at
https://github.com/cweiske/grauphel/issues/72#issuecomment-519173520

In case anyone finds themselves here, and is running Debian buster, I
was able to fix relatively easily.

The latest version of php-oauth in bullseye (currently 2.0.5+1.2.3-
1+b1) depends on PHP 7.4 so isn't trivially installable on buster via
apt pinning etc.

However, the previous version (2.0.5+1.2.3-1, I guess before a mass
rebuild) is still binary compatible with buster and PHP 7.3, so I was
able to fetch the binary from snapshot and install directly:

http://snapshot.debian.org/package/php-oauth/2.0.5%2B1.2.3-1/#php-oauth_2.0.5:2b:1.2.3-1

Cheers,
Rob

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 05:12:13PM -0500, David Steele wrote:
> On Fri, Dec 4, 2020 at 4:42 PM Bill Allombert  wrote:
> 
> > On Fri, Dec 04, 2020 at 01:34:44PM -0500, David Steele wrote:
> > > On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert 
> > wrote:
> > >
> > > > Do you envision to have packages depending on todo and then use the
> > > > todo binary ?
> > > >
> > >
> > > No. This is a means to allow topydo and todotxt-cli to use "todo" without
> > > crowding devtodo. I believe this meets the definition of a virtual
> > package
> > > in the Policy.
> >
> > I am not use I understand. Do you plan for /usr/bin/todo to be managed by
> > update-alternatives ? That would require all alternatives to share a common
> > interface.
> >
> 
> The guidance in the Policy is that alternatives "offer more-or-less the same
> functionality". I believe this standard is met.

Are people using /usr/bin/todo in script or Makefile ?
Are they likely to still work with the alternatives ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#974168: Bug#974168: Bug #974168: bioperl-run: autopkgtest issue fixed, now different build time error

[Andreas Tille]

Hi Étienne,

On Fri, Dec 04, 2020 at 09:56:20PM +0100, Étienne Mollier wrote:
> I think I'm on a trail with bioperl-run, and could fix a couple
> of issues already.  I'm however unsure it might make it for the
> 4th of the advent calendar: fixing the initial issue pulls in
> gradually more tests, which in turn may fail to run for all
> sorts of reasons.

I think for today several bugs are closed - so no need to hurry up for
this bug.  Just do what you think needs to be done.

Thanks to all who contributed to our Advent calendar

  Andreas.

-- 
http://fam-tille.de

Bug#892325: Bug#925638: closed by Debian FTP Masters (reply to Bernhard Schmidt ) (Bug#925638: fixed in belle-sip 4.3.1+dfsg-1)

[Bernhard Schmidt]

Hi,


Am 04.12.20 um 19:23 schrieb Bernhard Schmidt:
> Dear Mika,
> 
>> belle-sip is currently missing in Debian/testing AKA bullseye
>> because of this issue (which is only fixed in experimental yet):
>>
>> | Migration status for belle-sip (- to 1.6.3-5): BLOCKED: Rejected/violates 
>> migration policy/introduces a regression
>> | Issues preventing migration:
>> | Updating belle-sip introduces new bugs: #925638.
>>
>> I'm aware that "This package will soon be part of the auto-belle-sip
>> transition", but given that the bullseye freeze is coming closer,
>> I'm just wondering if there are any plans to upload belle-sip
>> v4.3.1+dfsg-1 towards unstable and whether we might see it in
>> bullseye?
> 
> yes, I have been dragging this far too long, sorry :-(
> 
> The problem is, the whole linphone library stack is ready, but I did not
> manage yet to build a package for linphone(-desktop), the Qt successor
> of the old Gtk client in src:linphone. The build system is weird, with a
> lot of fiddling I can get it to build something, but it is installed in
> weird paths relative to the buildpath and I cannot figure out why. Nor
> have I managed to workaround this.

I have sat down and did another stab at it. The repositories for
OpenSuSE and Arch Linux were very helpful to find the necessary
settings, but it still looks messy.

The code is at
https://salsa.debian.org/pkg-voip-team/linphone-stack/linphone-desktop .
Together with the packages already in experimental this COULD work. I
can't test right now because I'm running out of time and I am sitting in
front of a stable system, so no easy way to run experimental.

Anyone willing to take a look?

Bernhard

Bug#851472: Advent calendar: Help for autopkgtest of librostlab-blast

[Andreas Tille]

Control: tags -1 help

Hi,

I upgraded librostlab-blast in Git[1] but the autopkgtest fails with:



autopkgtest [22:31:34]: test installation-test: [---
Compile and run...
In file included from parseblast.cpp:2:
/usr/include/rostlab/blast-parser-driver.h:61:12: error: ‘enum 
rostlab::blast::parser::token::token_kind_type’ is not a class or namespace
   61 | friend YY_DECL_FRIEND;
  |^~
autopkgtest [22:31:35]: test installation-test: ---]
autopkgtest [22:31:35]: test installation-test:  - - - - - - - - - - results - 
- - - - - - - - -
installation-testFAIL non-zero exit status 1
autopkgtest [22:31:35]: test installation-test:  - - - - - - - - - - stderr - - 
- - - - - - - -
In file included from parseblast.cpp:2:
/usr/include/rostlab/blast-parser-driver.h:61:12: error: ‘enum 
rostlab::blast::parser::token::token_kind_type’ is not a class or namespace
   61 | friend YY_DECL_FRIEND;
  |^~
autopkgtest [22:31:35]:  summary
installation-testFAIL non-zero exit status 1


Any help would be welcome

 Andreas.


[1] https://salsa.debian.org/med-team/librostlab-blast

-- 
http://fam-tille.de

Bug#976405: texlive-latex-base: pdflatex command fails while building doxygen

[Norbert Preining]

Hi Paolo,

>   /usr/bin/pdflatex: Not writing to 
> ../html/examples/group/latex//group__group2.aux (openout_any = p).
>   make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:81: 
> doc/CMakeFiles/doxygen_pdf] Error 1

Is this new? This should have happened already since long time ago.

LaTeX etc now ensures to not write out of the current directory and its
sub-directories, so writing to ../html is a no go, this is the setting
openout_any = p
>From /usr/share/texlive/texmf-dist/web2c/texmf.cnf

**
% Do we allow TeX \input or \openin (openin_any), or \openout
% (openout_any) on filenames starting with `.' (e.g., .rhosts) or
% outside the current tree (e.g., /etc/passwd)?
% a (any): any file can be opened.
% r (restricted) : disallow opening dot files
% p (paranoid)   : as `r' and disallow going to parent directories, and
%  restrict absolute paths to be under $TEXMFOUTPUT.
openin_any = a
openout_any = p
**

This is not a new change, at least ... at least ... I can't remember,
years?

So I am very surprised that it would show up only now.

Options are:
- don't write to ..
- use
pdflatex -cnf-line="openout_any = r" 
  (never tried it though)
- temporarily set in /usr/local/share/texmf/web2c/texmf.cnf by 
  adding the same openout definition

Hope that helps

Norbert

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

Bug#976423: buster-pu: package pngcheck/2.3.0-7

[David da Silva Polverari]

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

Hi,

A global buffer overflow vulnerability was found by Red Hat on
pngcheck-2.4.0 [1]. It was found and reported by the Debian Security
Team that the vulnerability also affects the versions found on the
Debian archive [2].

The bug was already fixed on unstable [2]. I have prepared a revision
for buster-security for pngcheck/2.3.0-7 with the backported changes
from unstable. The proposed update builds correctly on a minimal
up-to-date buster chroot.

I didn't coordinate with the security team, as the vulnerability is
marked "no-dsa" in the Debian Security Tracker [3].

If the update is deemed correct, I can make it available on mentors, and
open an RFS as I don't have uploading rights.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1902011
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976350
[3] https://security-tracker.debian.org/tracker/CVE-2020-27818

Regards,
Polverari
diff -Nru pngcheck-2.3.0/debian/changelog pngcheck-2.3.0/debian/changelog
--- pngcheck-2.3.0/debian/changelog 2013-06-26 09:28:27.0 +
+++ pngcheck-2.3.0/debian/changelog 2020-12-04 21:22:18.0 +
@@ -1,3 +1,10 @@
+pngcheck (2.3.0-7+deb10u1) buster-security; urgency=high
+
+  * debian/patches/60-fix-buffer-overflow.patch: added to fix CVE-2020-27818.
+Thanks to Salvatore Bonaccorso . (Closes: #976350)
+
+ -- David da Silva Polverari   Fri, 04 Dec 2020 
21:22:18 +
+
 pngcheck (2.3.0-7) unstable; urgency=low
 
   * debian/control
diff -Nru pngcheck-2.3.0/debian/patches/60-fix-buffer-overflow.patch 
pngcheck-2.3.0/debian/patches/60-fix-buffer-overflow.patch
--- pngcheck-2.3.0/debian/patches/60-fix-buffer-overflow.patch  1970-01-01 
00:00:00.0 +
+++ pngcheck-2.3.0/debian/patches/60-fix-buffer-overflow.patch  2020-12-04 
21:22:18.0 +
@@ -0,0 +1,26 @@
+Description: Fix buffer overflow reported in RHBZ #1897485.
+ When char is signed, casting to a (signed) int directly could produce a
+ negative offset into the ASCII lookup table; adding an intermediate cast to
+ uch (a typedef for unsigned char) ensures a nonnegative offset no greater than
+ 255, which always corresponds to a valid table index.
+Origin: vendor, 
https://src.fedoraproject.org/rpms/pngcheck/blob/cc48791e34201caf7b686084b735d06cef66c974/f/pngcheck-2.4.0-overflow-bz1897485.patch
+Bug-Debian: https://bugs.debian.org/976350
+Forwarded: no
+Reviewed-By: David da Silva Polverari 
+Last-Update: 2020-12-04
+
+--- a/pngcheck.c
 b/pngcheck.c
+@@ -4895,8 +4895,10 @@
+ /* GRR 20061203:  now EBCDIC-safe */
+ int check_chunk_name(char *chunk_name, char *fname)
+ {
+-  if (isASCIIalpha((int)chunk_name[0]) && isASCIIalpha((int)chunk_name[1]) &&
+-  isASCIIalpha((int)chunk_name[2]) && isASCIIalpha((int)chunk_name[3]))
++  if (isASCIIalpha((int)(uch)chunk_name[0]) &&
++  isASCIIalpha((int)(uch)chunk_name[1]) &&
++  isASCIIalpha((int)(uch)chunk_name[2]) &&
++  isASCIIalpha((int)(uch)chunk_name[3]))
+ return 0;
+ 
+   printf("%s%s  invalid chunk name \"%.*s\" (%02x %02x %02x %02x)\n",
diff -Nru pngcheck-2.3.0/debian/patches/series 
pngcheck-2.3.0/debian/patches/series
--- pngcheck-2.3.0/debian/patches/series2013-06-26 09:28:27.0 
+
+++ pngcheck-2.3.0/debian/patches/series2020-12-04 21:22:18.0 
+
@@ -1,2 +1,3 @@
 10-pngsplit-format-strings.patch
 20-pngsplit-long-options.patch
+60-fix-buffer-overflow.patch

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

On Fri, Dec 4, 2020 at 4:42 PM Bill Allombert  wrote:

> On Fri, Dec 04, 2020 at 01:34:44PM -0500, David Steele wrote:
> > On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert 
> wrote:
> >
> > > Do you envision to have packages depending on todo and then use the
> > > todo binary ?
> > >
> >
> > No. This is a means to allow topydo and todotxt-cli to use "todo" without
> > crowding devtodo. I believe this meets the definition of a virtual
> package
> > in the Policy.
>
> I am not use I understand. Do you plan for /usr/bin/todo to be managed by
> update-alternatives ? That would require all alternatives to share a common
> interface.
>

The guidance in the Policy is that alternatives "offer more-or-less the same
functionality". I believe this standard is met.

Bug#900837: update on mass-rebuild of packages for reproducible builds

[Adrian Bunk]

On Thu, Dec 03, 2020 at 06:46:18PM -0800, Vagrant Cascadian wrote:
> On 2019-03-05, Holger Levsen wrote:
> > I ran Chris's script again on coccia, with the result that currently
> > 6084 source packages in the archive need a rebuild for reproducible
> > builds, as they were built with an old dpkg version not producing
> > .buildinfo files.
>
> I ran it just now, and we're down to 3433! Still a ways to go, but
> getting there...
>
> Updated list attached.

>From a quick look the majority seem to build binary-all,
which is not binNMU-able.

> live well,
>   vagrant

cu
Adrian

Bug#974075: ugene: FTBFS with Qt 5.15

[Andreas Tille]

Hi Tony,

On Fri, Dec 04, 2020 at 12:52:07PM -0800, tony mancill wrote:
> Hi Debian-Med, hi Steffen:
> 
> I grabbed this bug to fix the QPainterPath include and noticed that
> packaging of 36.0 is underway on the master branch.  I have updated the
> debian/patches to apply against this new upstream version and the
> package is building for me locally.  That commit has been pushed.
> 
> However, I noticed that Steffen listed a TODO in the changelog:
> 
> > * TODO: package new runtime dependencies: clark, wevote
> 
> Should I also create a branch for 34.0 to fix the FTBFS bug and upload?  Or
> will that just create noise - i.e., should I wait on the new runtime
> deps for 36.0?

I think fixing the FTBFS is valuable in any case.  However, may be
chacking the effort the new packages clark and wevote might make is
sensible since we would love to deliver the latest version of our
packages at freeze time so the goal to provide those new dependencies is
set anyway.

Not sure if this answer is really helpful for you. ;-)

Kind regards and thanks a lot for stepping in for this bug in any case
 Andreas.

-- 
http://fam-tille.de

Bug#975833: The FTBFS is reproducable by me.

[Geert Stappers]

Control: tags -1 confirmed


Now reproducable by me


Regards
Geert Stappers
No time to find out why my build was succesfull.
-- 
Silence is hard to parse

Bug#976422: RM: insighttoolkit4-python [amd64 i386] -- NBS; cruft package

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal

As if version 4.13.2-dfsg1-3, insighttoolkit4 no longer builds
insighttoolkit4-python. I am not sure why it hasn't been picked up by
the cruft removal automatically, so please remove it manually.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Bill Allombert]

On Fri, Dec 04, 2020 at 01:34:44PM -0500, David Steele wrote:
> On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert  wrote:
> 
> > What about devtodo ?
> >
> > Reading your summary, it seems that the todo.txt virtual package
> > is well specified, but the todo one is not.
> >
> > Do you envision to have packages depending on todo and then use the
> > todo binary ?
> >
> 
> No. This is a means to allow topydo and todotxt-cli to use "todo" without
> crowding devtodo. I believe this meets the definition of a virtual package
> in the Policy.

I am not use I understand. Do you plan for /usr/bin/todo to be managed by
update-alternatives ? That would require all alternatives to share a common
interface.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#974168: [Debian-med-packaging] Bug#974168: Bug #974168: bioperl-run: autopkgtest issue fixed, now different build time error

[Étienne Mollier]

Hi Andreas,

I think I'm on a trail with bioperl-run, and could fix a couple
of issues already.  I'm however unsure it might make it for the
4th of the advent calendar: fixing the initial issue pulls in
gradually more tests, which in turn may fail to run for all
sorts of reasons.

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#976421: Debian 11 successfully installed at AMD-K10 desktop PC

[Bernhard]

Package: installation-reports

Boot method: USB-CDROM
Image version: Self-made ISO image with current installer from testing (Alpha3?)
Date: 2020-12-04

Machine: Self-made Desktop PC
Processor: AMD A10-5700 APU with Radeon(tm) HD Graphics
Memory: 4GB
Partitions: 

> DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   1905512   0   19055120% /dev
> tmpfs  tmpfs   384696 9123837841% /run
> /dev/sda1  ext4 113871044 8601812  994418568% /
> tmpfs  tmpfs  1923472   12332   19111401% /dev/shm
> tmpfs  tmpfs 5120   4  51161% /run/lock
> tmpfs  tmpfs 4096   0  40960% /sys/fs/cgroup
> tmpfs  tmpfs   384692 1163845761% /run/user/1000

Output of lspci -knn (or lspci -nn):

> 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Root Complex [1022:1410]
>   Subsystem: ASUSTeK Computer Inc. Family 15h (Models 10h-1fh) Processor 
> Root Complex [1043:8526]
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901]
>   Subsystem: ASUSTeK Computer Inc. Trinity [Radeon HD 7660D] [1043:8526]
>   Kernel driver in use: radeon
>   Kernel modules: radeon
> 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 
> HDMI Audio Controller [1002:9902]
>   Subsystem: ASUSTeK Computer Inc. Trinity HDMI Audio Controller 
> [1043:8526]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> XHCI Controller [1022:7812] (rev 03)
>   Subsystem: ASUSTeK Computer Inc. FCH USB XHCI Controller [1043:8527]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA 
> Controller [AHCI mode] [1022:7801] (rev 40)
>   Subsystem: ASUSTeK Computer Inc. FCH SATA Controller [AHCI mode] 
> [1043:8527]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> OHCI Controller [1022:7807] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB OHCI Controller [1043:8527]
>   Kernel driver in use: ohci-pci
>   Kernel modules: ohci_pci
> 00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB 
> EHCI Controller [1022:7808] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH USB EHCI Controller [1043:8527]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
> [1022:780b] (rev 14)
>   Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8527]
>   Kernel driver in use: piix4_smbus
>   Kernel modules: i2c_piix4, sp5100_tco
> 00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia 
> Controller [1022:780d] (rev 01)
>   Subsystem: ASUSTeK Computer Inc. F2A85-M Series [1043:8444]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
> [1022:780e] (rev 11)
>   Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge [1043:8527]
> 00:14.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge 
> [1022:780f] (rev 40)
> 00:15.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 0) [1022:43a0]
>   Kernel driver in use: pcieport
> 00:15.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Hudson PCI to 
> PCI bridge (PCIE port 1) [1022:43a1]
>   Kernel driver in use: pcieport
> 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 0 [1022:1400]
> 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor Function 1 [1022:1401]
> 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h 
> (Models 10h-1fh) Processor 

Bug#974584: inspectrum FTBFS: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[tony mancill]

On Fri, Dec 04, 2020 at 05:36:29PM +0100, Christoph Berg wrote:
> Control: tags -1 fixed-upstream
> Control: forwarded -1 
> https://github.com/miek/inspectrum/commit/1f2b4587ec2c6d1a1945eee8bbf361dbdf3dc8af
> 
> Re: Helmut Grohne
> > | /<>/traceplot.cpp:120:18: error: aggregate ‘QPainterPath 
> > path’ has incomplete type and cannot be defined
> > |   120 | QPainterPath path;
> > |   |  ^~~~
> > 
> > This seems to be a fairly recent regression induced by one of the
> > dependencies.
> 
> Hi,
> 
> thanks for spotting. This has been fixed upstream, I'm asking them if
> we can get a new release, otherwise we need to cherry-pick the fix.

Thanks Christoph!  That made it very easy to update - I just uploaded
0.2.3.

Cheers,
tony

Bug#976409: glibc breaks node-iconv autopkgtest: AssertionError [ERR_ASSERTION]: Missing expected exception

[Aurelien Jarno]

On 2020-12-04 21:54, Aurelien Jarno wrote:
> On 2020-12-04 21:38, Xavier wrote:
> > Control: tags -1 + ftbfs
> > 
> > Le 04/12/2020 à 20:46, Paul Gevers a écrit :
> > > Source: glibc, node-iconv
> > > Control: found -1 glibc/2.31-5
> > > Control: found -1 node-iconv/2.3.5-4
> > > Severity: serious
> > > Tags: sid bullseye
> > > X-Debbugs-CC: debian...@lists.debian.org
> > > User: debian...@lists.debian.org
> > > Usertags: breaks needs-update
> > > 
> > > Dear maintainer(s),
> > > 
> > > With a recent upload of glibc the autopkgtest of node-iconv fails in
> > > testing on all architectures when that autopkgtest is run with the
> > > binary packages of glibc from unstable. It passes when run with only
> > > packages from testing. In tabular form:
> > > 
> > >passfail
> > > glibc  from testing2.31-5
> > > node-iconv from testing2.3.5-4
> > > all others from testingfrom testing
> > > 
> > > I copied some of the output at the bottom of this report.
> > > 
> > > Currently this regression is blocking the migration of glibc to testing
> > > [1]. Due to the nature of this issue, I filed this bug report against
> > > both packages. Can you please investigate the situation and reassign the
> > > bug to the right package?
> > > 
> > > More information about this bug and the reason for filing it can be found 
> > > on
> > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> > > 
> > > Paul
> > Hi,
> > 
> > I rebuild node-iconv (nocheck) and rebuild/autopkgtest reverse
> > dependencies of node-iconv, all passed:
> >  * rebuild: node-body-parser, node-encoding, node-expat,
> > node-iconv-lite, node-raw-body
> >  * autopkgtest: node-body-parser, node-d3-dsv, node-raw-body
> > 
> > So maybe we can just ignore 2 failing tests for now (a "should throw"
> > which doesn't throw).
> > 
> 
> I gave a quick look at the node-iconv code, and looking at
> debian/patches/use-glibc-iconv.patch the issue might be related to the
> changes in the C.UTF-8 locale that does a bit more transliteration than
> before.

The problem is that the 'が' wasn't considered as valid UTF-8 in glibc
2.31-4:

| $ echo 'ça va が' | LC_ALL=C.UTF-8 iconv -f utf-8 -t ascii//translit
| ca va iconv: illegal input sequence at position 7

With glibc 2.31-5 it is considered as valid, although not
transliterable:

| $ echo 'ça va が' | LC_ALL=C.UTF-8 iconv -f utf-8 -t ascii//translit
| ca va ?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#976420: mrpt: ftbfs with libjsoncpp/experimental

[Gianfranco Costamagna]

Source: mrpt
Version: 1:12.1.4-1
Forwarded: https://github.com/MRPT/mrpt/issues/1118
Severity: important

Hello, the package ftbfs with the new libjsoncpp in experimental.
Unfortunately, even if the patch might be just trivial as removing that line of 
code, I'm not confident in providing a patch,
this is why I opened an upstream ticket.

Thanks for having a look

Gianfranco

Bug#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault

[Paul Gevers]

Hi Jonas,

On Fri, 23 Oct 2020 12:07:27 +0200 Jonas Smedegaard  wrote:
> > Of course, I'm biased since I'm the maintainer of doc-rfc, but I think 
> > it's a fair assesment.
> 
> For the record it is not a PDF file but a (quite large and allegedly) 
> PostScript file that causes Ghostscript to segfault.

doc-rfc got a new upload and removed the offending file. So, there's no
no autopkgtest regression reported anymore. Unless you think this
segfault case is severe enough (I could really see that point) I also
like ghostscript to just migrate. It's your call. If you want
ghostscript to migrate, just lower this bug's severity.

> I do agree that Ghostscript shouldn't segfault.

Indeed.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976120: (QAbc packaging) debhelper version question

[Andrey Rahmatullin]

On Fri, Dec 04, 2020 at 10:08:29PM +0100, Benoît Rouits wrote:
> Thank you for your reply.
> 
> I used to put this line:
> Build-Depends: debhelper-compat (= 12), ...
> 
> Should I then remove "-compat" like this ?
> Build-Depends: debhelper (= 13), ...
No. Build-Depends: debhelper is a normal build-depends while
Build-Depends: debhelper-compat is both a build-depends on debhelper (with
a >=) and a declaration of the compat level.
Please read the "COMPATIBILITY LEVELS" section in debhelper(7) for more
information.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#971571: transition: libgit2

[Utkarsh Gupta]

Hi,

On Sat, Dec 5, 2020 at 1:41 AM Sebastian Ramacher  wrote:
> Scheduled the binNMUs except for horizon-eda (involved in python3.9-defaults).

Great, thank you!
I've, meanwhile, uploaded python-pygit2 and libgit-raw-perl! Will
hopefully get on to ruby-rugged, as well! \o/


- u

Bug#976120: (QAbc packaging) debhelper version question

[Benoît Rouits]

Thank you for your reply.

I used to put this line:
Build-Depends: debhelper-compat (= 12), ...

Should I then remove "-compat" like this ?
Build-Depends: debhelper (= 13), ...

Le 04/12/2020 à 21:29, Andrey Rahmatullin a écrit :

On Fri, Dec 04, 2020 at 08:39:26PM +0100, Benoît Rouits wrote:

I use debhelper but I don't use specific features
of debhelper 13.
Anyway, should I set debhelper = 13 as build dependency

Yes.


or can I set debhelper >= 12 to be more flexible
for transition from sid to testing and to stable ?

It won't help "for transition from sid to testing" and there is no
"transition to stable".

Bug#976419: src:liquidsoap: fails to migrate to testing for too long: FTBFS on armel, and mips(64)el

[Paul Gevers]

Source: liquidsoap
Version: 1.4.2-1
Severity: serious
Control: close -1 1.4.3-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 972272 976355

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#362052: [t...@lyx.org: Re: #4370: Please implement a check-in and re-checkout in one step menu item]

[Pavel Sanda]

On Tue, 2 Nov 2010 20:59:57 +0100 Sven Hoexter  wrote:
> Status update ...

The second reported issue is fixed since lyx 1.6, the first one is wontfix
for 12 years already.
As such I would close this bug.

Pavel

Bug#976416: jars are not install in maven-repo

[Louis-Philippe Véronneau]

Package: src:clj-time-clojure
Version: 0.14.0-2
Severity: important
Owner: po...@debian.org

It seems only pom files are installed in maven-repo, and not jar files.
This means we can't currently use this package as a dependency when
building with leiningen.

$ tree maven-repo/clj-time/

maven-repo/clj-time/
`-- clj-time
|-- 0.14.0
|   `-- clj-time-0.14.0.pom
`-- debian
`-- clj-time-debian.pom

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976310: marked as pending in node-css-loader

[Pirate Praveen]

Control: reopen -1

On Fri, Dec 4, 2020 at 19:52, Xavier Guimard  
wrote:

Control: tag -1 pending

Hello,

Bug #976310 in node-css-loader reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/js-team/node-css-loader/-/commit/130e5ef8425bb78f300953766d003f32392cbd1d


Fix schema-utils version in package.json

Closes: #976310


No, this does not fix the issue. The previous one did not either. Yarn 
does not see this package.json at all.


See 
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/patches/0740-use-packaged-modules.patch


Only the modules that are not packaged will be installed via yarn. This 
was working fine till node-schema-utils/node-mkdirp updates.


With these updates, we can't mix packaged modules and yarn installed 
modules. We have to use the work around I mentioned earlier add 
node_modules/schema-utils link in all packaged modules or use packaged 
versions of all modules that depend on schema-utils/mkdirp (another 
possibility is to update the versions in package.json which uses newer 
schema-utils/mkdirp which will need adapting gitlab itself).

Bug#975129: qwt: FTBFS: qwt_painter_command.h:85:22: error: field ‘clipPath’ has incomplete type ‘QPainterPath’

[tony mancill]

On Wed, Nov 25, 2020 at 08:35:48AM +0100, Gudjon I. Gudjonsson wrote:
> This requires a quite simple fix. I will fix this before the weekend and then 
> start looking into version 6.1.5.

Hi Gudjon,

Do you mind if I upload an NMU of 6.1.4 for the simple fix?  There are a
number of r-deps that are going to be removed from testing soon.

Cheers,
tony

Bug#976417: src:imbalanced-learn: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: imbalanced-learn
Version: 0.7.0-4
Severity: serious
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 974088

Dear maintainer(s),

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

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

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

I have tagged this bug to only affect sid and bullseye, so it doesn't
affect (old-)stable.

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#976418: raynes-fs-clojure: jars are not installed in maven-repo

[Louis-Philippe Véronneau]

Package: src:raynes-fs-clojure
Version: 1.5.1-1
Severity: important
Owner: po...@debian.org

It seems only pom files are installed in maven-repo, and not jar files.
This means we can't currently use this package as a dependency when
building with leiningen.

$ tree maven-repo/clj-commons/fs/

maven-repo/clj-commons/fs/
|-- 1.5.1
|   `-- fs-1.5.1.pom
`-- debian
`-- fs-debian.pom

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976415: jars installed in /usr/share/maven-repo/ are broken

[Louis-Philippe Véronneau]

Package: src:core-async-clojure
Version: 1.3.610-1
Severity: important
Owner: po...@debian.org

It appears that the jars installed in /usr/share/maven-repo/ are broken,
as they don't link back to the actual jars installed in /usr/share/java.

|   |-- clojure
|   |   |-- clojure
|   |   |   |-- 1.10.1
|   |   |   |   |-- clojure-1.10.1.jar ->
../../../../../java/clojure-1.10.1.jar
|   |   |   |   `-- clojure-1.10.1.pom
|   |   |   `-- 1.10.x
|   |   |   |-- clojure-1.10.x.jar ->
../../../../../java/clojure-1.10.1.jar
|   |   |   `-- clojure-1.10.x.pom
|   |   |-- core.async
|   |   |   |-- 1.3.610
|   |   |   |   |-- core.async-1.3.610.jar -> /core.async.jar
|   |   |   |   `-- core.async-1.3.610.pom
|   |   |   `-- debian
|   |   |   |-- core.async-debian.jar -> /core.async.jar
|   |   |   `-- core.async-debian.pom

This breaks packages depending on core-async-clojure and building with
leiningen.

I'm the one who last updated this package, so whoops! I'll rebuild the
package using leiningen in a revision nex week.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976409: glibc breaks node-iconv autopkgtest: AssertionError [ERR_ASSERTION]: Missing expected exception

[Aurelien Jarno]

On 2020-12-04 21:38, Xavier wrote:
> Control: tags -1 + ftbfs
> 
> Le 04/12/2020 à 20:46, Paul Gevers a écrit :
> > Source: glibc, node-iconv
> > Control: found -1 glibc/2.31-5
> > Control: found -1 node-iconv/2.3.5-4
> > Severity: serious
> > Tags: sid bullseye
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: breaks needs-update
> > 
> > Dear maintainer(s),
> > 
> > With a recent upload of glibc the autopkgtest of node-iconv fails in
> > testing on all architectures when that autopkgtest is run with the
> > binary packages of glibc from unstable. It passes when run with only
> > packages from testing. In tabular form:
> > 
> >passfail
> > glibc  from testing2.31-5
> > node-iconv from testing2.3.5-4
> > all others from testingfrom testing
> > 
> > I copied some of the output at the bottom of this report.
> > 
> > Currently this regression is blocking the migration of glibc to testing
> > [1]. Due to the nature of this issue, I filed this bug report against
> > both packages. Can you please investigate the situation and reassign the
> > bug to the right package?
> > 
> > More information about this bug and the reason for filing it can be found on
> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> > 
> > Paul
> Hi,
> 
> I rebuild node-iconv (nocheck) and rebuild/autopkgtest reverse
> dependencies of node-iconv, all passed:
>  * rebuild: node-body-parser, node-encoding, node-expat,
> node-iconv-lite, node-raw-body
>  * autopkgtest: node-body-parser, node-d3-dsv, node-raw-body
> 
> So maybe we can just ignore 2 failing tests for now (a "should throw"
> which doesn't throw).
> 

I gave a quick look at the node-iconv code, and looking at
debian/patches/use-glibc-iconv.patch the issue might be related to the
changes in the C.UTF-8 locale that does a bit more transliteration than
before.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#976296: blender: Segmentation fault when importing background image

[will]

Package: blender
Version: 2.83.5+dfsg-4+b1
Followup-For: Bug #976296
X-Debbugs-Cc: wiiliamchung...@gmail.com

Importing (any) images from blender crashes the program with a segmentation
fault.
I'm able to reproduce it from a fresh net-install of Debian testing.

1. Open blender with default general view
2. Open menu and add background or reference image (both crashes blender)
3. Select any image file (even a 1px image would do)
4. Blender crashes

test@debian:~$ blender
Writing userprefs: '/home/test/.config/blender/2.83/config/userpref.blend' ok
Writing: /tmp/blender.crash.txt
Segmentation fault

blender.crash.txt: https://paste.debian.net/1175640/



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

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

Versions of packages blender depends on:
ii  blender-data  2.83.5+dfsg-4
ii  fonts-dejavu  2.37-2
ii  libavcodec58  7:4.3.1-5
ii  libavdevice58 7:4.3.1-5
ii  libavformat58 7:4.3.1-5
ii  libavutil56   7:4.3.1-5
ii  libboost-locale1.71.0 1.71.0-7+b1
ii  libc6 2.31-4
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.2+dfsg-4
ii  libgcc-s1 10.2.0-19
ii  libgl11.3.2-1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10.2.0-19
ii  libilmbase25  2.5.3-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.16~dfsg-1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libopenal11:1.19.1-2
ii  libopencolorio1v5 1.1.1~dfsg0-6+b2
ii  libopenexr25  2.5.3-2
ii  libopenimageio2.2 2.2.7.0+dfsg-2+b1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb7.1 7.1.0-2+b1
ii  libosdcpu3.4.33.4.3-3
ii  libosdgpu3.4.33.4.3-3
ii  libpcre3  2:8.39-13
ii  libpng16-16   1.6.37-3
ii  libpython3.9  3.9.1~rc1-2
ii  libsdl2-2.0-0 2.0.12+dfsg1-4
ii  libsndfile1   1.0.28-8
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610.2.0-19
ii  libswscale5   7:4.3.1-5
ii  libtbb2   2020.3-1
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.12-1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxml2   2.9.10+dfsg-6.3
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information

*** /tmp/blender.crash.txt
# Blender 2.83.5, Unknown revision
bpy.context.space_data.system_bookmarks_active = 3  # Property

# backtrace
blender(BLI_system_backtrace+0x33) [0x5644b4f2ae23]
blender(+0xef13cd) [0x5644b2ae43cd]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bcc0) [0x7f6ee9899cc0]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(PyEval_ReleaseLock+0x15) 
[0x7f6eebe80685]
blender(BPY_thread_save+0x25) [0x5644b4ad39b5]
blender(+0x13d1ee2) [0x5644b2fc4ee2]
blender(RNA_function_call+0x12) [0x5644b2f79f52]
blender(+0x14e7629) [0x5644b30da629]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_MakeTpCall+0x90) 
[0x7f6eebda5bf0]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x8632) 
[0x7f6eebd562e2]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x6f023) [0x7f6eebd4d023]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x78c5) 
[0x7f6eebd55575]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x1a45cc) [0x7f6eebe825cc]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyFunction_Vectorcall+0x9d) 
[0x7f6eebda111d]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_FastCallDictTstate+0xce) 
[0x7f6eebda6aee]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_Call_Prepend+0xe0) 
[0x7f6eebda6c90]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x13b6d9) [0x7f6eebe196d9]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_MakeTpCall+0x90) 
[0x7f6eebda5bf0]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyEval_EvalFrameDefault+0x76a1) 
[0x7f6eebd55351]
/lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x6f023) [0x7f6eebd4d023]
blender(+0x14e7d7d) [0x5644b30dad7d]
blender(+0x14c36c5) [0x5644b30b66c5]
blender(+0x11aab37) [0x5644b2d9db37]
blender(+0x11ae37b) [0x5644b2da137b]

Bug#976411: d-shlibs: fails with libjsoncpp in experimental

[Jonas Smedegaard]

Quoting Gianfranco Costamagna (2020-12-04 21:02:47)
> Source: d-shlibs
> Version: 0.95
> Severity: important
> 
> Hello, looks like two packages (odil/seqtools) are now failing in d-shlibs 
> because of an error with libjsoncpp in experimental
> 
> devlibs error: There is no package matching [libjsoncpp24-dev] and noone 
> provides it, please report bug to d-shlibs maintainer
> 
> Not sure what does it mean, in experimental we have a libjsoncpp-dev 
> depending on libjsoncpp24, I don't think there are any issues there, but I 
> admit I'm a little bit lost on libjsoncpp library versioning
> 
> can you please have a look?

Solved now in d-shlibs. Thanks for reporting!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#974075: ugene: FTBFS with Qt 5.15

[tony mancill]

On Mon, Nov 09, 2020 at 05:52:43PM +0100, Andreas Beckmann wrote:
> Package: ugene
> Version: 34.0+dfsg-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source

Hi Debian-Med, hi Steffen:

I grabbed this bug to fix the QPainterPath include and noticed that
packaging of 36.0 is underway on the master branch.  I have updated the
debian/patches to apply against this new upstream version and the
package is building for me locally.  That commit has been pushed.

However, I noticed that Steffen listed a TODO in the changelog:

> * TODO: package new runtime dependencies: clark, wevote

Should I also create a branch for 34.0 to fix the FTBFS bug and upload?  Or
will that just create noise - i.e., should I wait on the new runtime
deps for 36.0?

Thanks!
tony

Bug#976414: libseqlib: ftbfs with libjsoncpp/experimental

[Gianfranco Costamagna]

Source: libseqlib
Version: 1.1.2+dfsg-9
Forwarded: https://github.com/walaj/SeqLib/issues/58
Severity: important

Hello, the package ftbfs with the new libjsoncpp in experimental.
Unfortunately, even if the patch might be just trivial as discarding the return 
value, I'm not confident in providing a patch,
this is why I opened an upstream ticket.

Thanks for having a look

Gianfranco

Bug#976409: glibc breaks node-iconv autopkgtest: AssertionError [ERR_ASSERTION]: Missing expected exception

[Xavier]

Control: tags -1 + ftbfs

Le 04/12/2020 à 20:46, Paul Gevers a écrit :
> Source: glibc, node-iconv
> Control: found -1 glibc/2.31-5
> Control: found -1 node-iconv/2.3.5-4
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of glibc the autopkgtest of node-iconv fails in
> testing on all architectures when that autopkgtest is run with the
> binary packages of glibc from unstable. It passes when run with only
> packages from testing. In tabular form:
> 
>passfail
> glibc  from testing2.31-5
> node-iconv from testing2.3.5-4
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of glibc to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
Hi,

I rebuild node-iconv (nocheck) and rebuild/autopkgtest reverse
dependencies of node-iconv, all passed:
 * rebuild: node-body-parser, node-encoding, node-expat,
node-iconv-lite, node-raw-body
 * autopkgtest: node-body-parser, node-d3-dsv, node-raw-body

So maybe we can just ignore 2 failing tests for now (a "should throw"
which doesn't throw).

NB: I tried also with node-iconv 3.0.0, same problem in test.

Bug#730111: Still present in 2.1.3-1

[Pavel Sanda]

On Wed, 18 Mar 2015 12:28:48 +0100 Alexander Stiebing  
wrote:
> Bug still like described in Nov. 2013, none of the proposed actions out
> of the comments have been done.

The change of the message to be more informative will be fixed in lyx 2.3.7 & 
2.4.
https://www.lyx.org/trac/changeset/b670990bc12fe1dd1d9d7b5fa8258a32caa7e91a/lyxgit

Moving RCS from suggested to Recommends look reasonable to me.
After that the bug can be closed.

Pavel

Bug#976120: (QAbc packaging) debhelper version question

[Andrey Rahmatullin]

On Fri, Dec 04, 2020 at 08:39:26PM +0100, Benoît Rouits wrote:
> I use debhelper but I don't use specific features
> of debhelper 13.
> Anyway, should I set debhelper = 13 as build dependency
Yes.

> or can I set debhelper >= 12 to be more flexible
> for transition from sid to testing and to stable ?
It won't help "for transition from sid to testing" and there is no
"transition to stable".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#976410: glibc breaks libpod autopkgtest: dh_auto_build: error: cd _output && go install -trimpath ...

[Aurelien Jarno]

control: reassign libpod/2.0.6+dfsg1-2

On 2020-12-04 20:50, Paul Gevers wrote:
> Source: glibc, libpod
> Control: found -1 glibc/2.31-5
> Control: found -1 libpod/2.0.6+dfsg1-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of glibc the autopkgtest of libpod fails in testing
> when that autopkgtest is run with the binary packages of glibc from
> unstable. It passes when run with only packages from testing. In tabular
> form:
> 
>passfail
> glibc  from testing2.31-5
> libpod from testing2.0.6+dfsg1-2
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of glibc to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?

I have tried and for me the issue is reproducible with both old and new
glibc. I am therefore reassign the bug to libpod.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#976413: odil: FTBFS with jsoncpp/experimental (patch)

[Gianfranco Costamagna]

Source: odil
Version: 0.12.0-2
Severity: important

Hello, looks like the package fails with the experimental libjsoncpp-dev 
because of d-shlibsmove unable to convert the new jsoncpp dependency.

devlibs error: There is no package matching [libjsoncpp24-dev] and noone 
provides it, please report bug to d-shlibs maintainer

I think dropping that override is enough to fix the issue but fails in 
evaluating the runtime dependency probably

But there might be an issue with d-shlibs package itself (I opened bug #976411).

G.

Bug#971571: transition: libgit2

[Sebastian Ramacher]

On 2020-12-05 00:12:00, Utkarsh Gupta wrote:
> Hi Sebastian,
> 
> On Fri, Dec 4, 2020 at 10:54 PM Sebastian Ramacher  
> wrote:
> > Please go ahead with the upload to unstable.
> 
> Great, thanks, I did an upload just now! :)

Scheduled the binNMUs except for horizon-eda (involved in python3.9-defaults).

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#976412: seqtools: FTBFS with jsoncpp/experimental (patch)

[Gianfranco Costamagna]

Source: seqtools
Version: 4.44.1+dfsg-6
Severity: important

Hello, looks like the package fails with the experimental libjsoncpp-dev 
because of d-shlibsmove unable to convert the new jsoncpp dependency.

devlibs error: There is no package matching [libjsoncpp24-dev] and noone 
provides it, please report bug to d-shlibs maintainer

I think dropping that override is enough to fix the issue but fails in 
evaluating the runtime dependency probably

diff -Nru seqtools-4.44.1+dfsg/debian/rules seqtools-4.44.1+dfsg/debian/rules
--- seqtools-4.44.1+dfsg/debian/rules   2020-10-15 16:10:33.0 +0200
+++ seqtools-4.44.1+dfsg/debian/rules   2020-12-04 20:28:28.0 +0100
@@ -13,7 +13,6 @@
d-shlibmove --commit \
--multiarch \
--devunversioned \
-   --override s/libjsoncpp1-dev/libjsoncpp-dev/ \
--exclude-la \
--movedev debian/tmp/usr/include/* usr/include \
debian/tmp/usr/lib/*/*.so

But there might be an issue with d-shlibs package itself (I opened bug #976411).

G.

Bug#976411: d-shlibs: fails with libjsoncpp in experimental

[Gianfranco Costamagna]

Source: d-shlibs
Version: 0.95
Severity: important

Hello, looks like two packages (odil/seqtools) are now failing in d-shlibs 
because of an error with libjsoncpp in experimental

devlibs error: There is no package matching [libjsoncpp24-dev] and noone 
provides it, please report bug to d-shlibs maintainer

Not sure what does it mean, in experimental we have a libjsoncpp-dev depending 
on libjsoncpp24, I don't think there are any issues there, but I admit I'm a 
little bit lost on libjsoncpp library versioning

can you please have a look?

thanks

Gianfranco

Bug#976366: Upgrade to 247 broke keyboard input on Wayland session

[Michael Biebl]

Am 04.12.2020 um 11:56 schrieb Marc Dequènes (duck):

On 2020-12-04 17:04, Michael Biebl wrote:


Is policykit-1 installed and working?


I dug a little bit more on this front and I am affected by this:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860040
which then made the polkit agent quit on start.

I have not tested yet if removing hidepid would be sufficient but 
polkit's behavior is really annoying.




hidepid is known to cause problems and no longer a supported configuration:
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#hidepid-unsupported

Bug#976341: [Pkg-javascript-devel] Bug#976341: Bug#976341: Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker

[Jonas Smedegaard]

Quoting Xavier (2020-12-04 16:35:31)
> Le 04/12/2020 à 15:32, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-12-04 11:48:58)
> >> Le 03/12/2020 à 19:05, Jonas Smedegaard a écrit :
> >>> Quoting Xavier (2020-12-03 18:30:54)
>  Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit :
> > Please provide real (not virtual) package node-jest-worker, and 
> > have jest depend on or recommend that, as appropriate.
> > 
> > [...]
> > 
> >> node-babel7 does provide versioned virtual packages (like acorn).
> > 
> > You are right: I failed to check correctly versioning.  apt and aptitude 
> > apparently does *not* show version for virtual packages (I thought so, 
> > and I thought I had checked that with node-types-uuid).
> > 
> > This works:
> > 
> >   apt-cache showpkg node-types-babel-code-frame | grep '^[a-z]'
> > 
> > This also works, and is more flexible to e.g. reveal that 3 node-types-* 
> > packages do not provide version:
> > 
> >   sudo sync-available
> >   grep-available -FProvides -sProvides node-types- | grep -Po 
> > '\bnode-types-[^,]+'
> > 
> > This should also work flexibly and more elegant, but doesn't for me (not 
> > sure why):
> > 
> >   grep-status --field=Provides -sProvides node-types-babel-code-frame
> > 
> > 
> >> I'll study if node-babel7 can be split into multiple packages. It took 
> >> me around 4 hours to split jest correctly...
> 
> Take a look at https://people.debian.org/~yadd/babel-spaghetti-dish.png
> (generated with add-node-component --cmptree). I don't know how to split
> node-babel7 for now...

I suggest to convert only the most popular virtual packages into real 
binary packages.

This lists virtual packages provided by node-babel7:

  aptitude -F%p search '?reverse-provides(node-babel7)'

This lists packages depending on any of those virtual packages:

  aptitude -F%p search '?depends(?reverse-provides(node-babel7))'

What I cannot figure out is how to group by _which_ virtual package it 
depends on.

[ several hours fighting with "aptitude search" later... ]

I give up: I think it should be possible to express a non-interactive 
"aptitude search" command similar to interactive display which I 
personally use a lot, but cannot figure that out.  So here is instead a 
super-quick intro to doing it in aptitude interactively (in case you are 
not familiar with that already):

 1. Run "aptitude -u" to start interactive fullscreen session with 
up-date package information
 2. hit "/" to search, type "node-babel7", and hit ENTER
 3. Hit ENTER to switch from package list mode to package details
 4. Move to bottom with arrow keys or PAGEDOWN or END
 5. Hit ENTER when standing on top of "Packages depending on ..."
 6. Look at each "Dependencies on provided ..."

Just looking at the counts in "Dependencies on provided ..." lines, it 
seems the most beneficial to change from virtual to real package are 
these (sorted by popularity, and with popularity count appended):

  node-babel-types 21
  node-babel-template 11
  node-babel-traverse 10
  node-babel-runtime 8
  node-babel-helper-function-name 5
  node-babel-plugin-syntax-jsx 4
  node-babel-plugin-transform-async-to-generator 3
  node-babel-plugin-transform-exponentiation-operator 3
  node-babel-code-frame 2
  node-babel-core 2
  node-babel-helper-get-function-arity 2
  node-babel-helper-hoist-variables 2
  node-babel-helper-optimise-call-expression 2
  node-babel-helper-remap-async-to-generator 2
  node-babel-plugin-syntax-class-properties 2
  node-babel-plugin-syntax-dynamic-import 2
  node-babel-generator 1
  node-babel-helper-bindify-decorators 1
  node-babel-helper-builder-binary-assignment-operator-visitor 1
  node-babel-helper-builder-react-jsx 1
  node-babel-helper-call-delegate 1
  node-babel-helper-define-map 1
  node-babel-helper-explode-assignable-expression 1
  node-babel-helper-explode-class 1
  node-babel-helper-replace-supers 1
  node-babel-helpers 1
  node-babel-plugin-syntax-async-generators 1
  node-babel-plugin-syntax-decorators 1
  node-babel-plugin-syntax-do-expressions 1
  node-babel-plugin-syntax-flow 1
  node-babel-plugin-syntax-function-bind 1
  node-babel-plugin-syntax-object-rest-spread 1
  node-babel-plugin-transform-flow-strip-types 1
  node-babel-plugin-transform-react-display-name 1
  node-babel-plugin-transform-react-jsx 1
  node-babel-plugin-transform-react-jsx-self 1
  node-babel-plugin-transform-react-jsx-source 1
  node-babel-plugin-transform-regenerator 2
  node-babel-plugin-transform-strict-mode 1
  node-babel-polyfill 1
  node-babel-preset-flow 1
  node-babel-register 1

Popularity counts are heavily skewed by src:node-babel packages, 
however, so if we for some reason wanted ignore that source package then 
it would look like this:

  node-babel-plugin-transform-async-to-generator 1
  node-babel-plugin-transform-exponentiation-operator 1
  node-babel-plugin-transform-regenerator 1
  node-babel-template 1

So if you care about babel6 packages then start from the top of the 
upper 

Bug#972820: confirmation, test case

[Ryan Pavlik]

Looks like https://bugs.debian.org/964477 is related or the same, not
sure which way the merge should go. There's some existing discussion
there, including suggesting that the commit I cited below was not the
only thing that broke it, given it was marked "found" in 10.1.0-1.

It also looks like https://bugs.debian.org/972936 might be related, as
well as the archived bug https://bugs.debian.org/946285

I've collected some mentions of this issue in the readme of


Thanks for your help!

Ryan

On 12/4/2020 12:27 PM, Ryan Pavlik wrote:
> I have also experienced this bug, as have a lot of others on the
> internet (try searching for "libc6-dev : Breaks: libgcc-8-dev (<
> 8.4.0-2~) but 8.3.0-6 is to be installed" to see). The bug appears to be
> in the new gcc-10 package, not the gcc-8 package it's replacing on upgrade.
>
> It looks like it's a result of the lack of transitional packages from
> libgcc1 to libgcc-s1 (and its relatives). They were removed from sid and
> bullseye for 10.1.0-2, in this commit:
> https://salsa.debian.org/toolchain-team/gcc/-/commit/e8047f6d4947d94d7475987d0697434f1e6504d7
>  
> (though multi-arch properties were removed before then).
>
> I was able to work around this issue by creating a simple mostly-empty
> source package that created the missing transitional packages and
> installing them, though this is of course inferior to having them
> actually provided by the relevant source package.
> https://salsa.debian.org/rpavlik/gcc-10-compat (I only mocked up/built
> the packages required to test on x86_64/i386, but I'd expect the same
> problem and solution on the other platforms that have additional libgcc
> packages.)
>
> I have a reproducible test case: I did it in a Dockerfile, but you could
> do the equivalent commands in a chroot or which ever way you prefer.
> Essentially, you can start with a fairly minimal Debian Buster install,
> and install the following packages:
>
> apt-get install -y -qq --no-install-recommends gcc-8 libc6-dev libreoffice
>
> (This is one minimal set to reproduce - there may be others.)
>
> Then, when you switch the Buster sources to Bullseye, you'll get this
> error on your attempt to apt-get dist-upgrade:
>
>
> 
>
> Calculating upgrade... Error!
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6 is to be
> installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be
> caused by held packages.
>
> 
>
> You can confirm the fix by adding the repo with my workaround
> transitional packages:
>
> deb
> http://download.opensuse.org/repositories/home:/rpavlik:/bullseye-fix
> Debian_Testing/
>
> (key is at
> http://download.opensuse.org/repositories/home:/rpavlik:/bullseye-fix/Debian_Testing/Release.key
> )
>
> I've uploaded my dockerfile for experimenting with this bug to
> https://salsa.debian.org/rpavlik/gcc-upgrade-testcase
>
> It looks to me, based on the workaround I was able to create, that the
> solution might include re-enabling the transitional packages for
> bullseye/sid at least until the release of bullseye as stable. At that
> point, anyone upgrading to testing or unstable would be coming from a
> bullseye release that has the gcc-10 with new names, so the transitional
> packages would not be needed anymore.
>
>
>



signature.asc
Description: OpenPGP digital signature

Bug#976410: glibc breaks libpod autopkgtest: dh_auto_build: error: cd _output && go install -trimpath ...

[Paul Gevers]

Source: glibc, libpod
Control: found -1 glibc/2.31-5
Control: found -1 libpod/2.0.6+dfsg1-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of glibc the autopkgtest of libpod fails in testing
when that autopkgtest is run with the binary packages of glibc from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
glibc  from testing2.31-5
libpod from testing2.0.6+dfsg1-2
all others from testingfrom testing

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=glibc

https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libpod/8618093/log.gz

cd _output && go install -trimpath -v -p 2 -tags "apparmor ostree
seccomp selinux systemd varlink" -ldflags "-X
main.buildInfo=2.0.6+dfsg1-2" github.com/containers/libpod/cmd/podman
github.com/containers/libpod/cmd/podman/common
github.com/containers/libpod/cmd/podman/containers
github.com/containers/libpod/cmd/podman/generate
github.com/containers/libpod/cmd/podman/healthcheck
github.com/containers/libpod/cmd/podman/images
github.com/containers/libpod/cmd/podman/inspect
github.com/containers/libpod/cmd/podman/manifest
github.com/containers/libpod/cmd/podman/networks
github.com/containers/libpod/cmd/podman/parse
github.com/containers/libpod/cmd/podman/play
github.com/containers/libpod/cmd/podman/pods
github.com/containers/libpod/cmd/podman/registry
github.com/containers/libpod/cmd/podman/report
github.com/containers/libpod/cmd/podman/system
github.com/containers/libpod/cmd/podman/system/connection
github.com/containers/libpod/cmd/podman/utils
github.com/containers/libpod/cmd/podman/validate
github.com/containers/libpod/cmd/podman/volumes
github.com/containers/libpod/docs
github.com/containers/libpod/docs/varlink
github.com/containers/libpod/hack/podman-registry-go
github.com/containers/libpod/libpod
github.com/containers/libpod/libpod/common
github.com/containers/libpod/libpod/define
github.com/containers/libpod/libpod/driver
github.com/containers/libpod/libpod/events
github.com/containers/libpod/libpod/filters
github.com/containers/libpod/libpod/image
github.com/containers/libpod/libpod/layers
github.com/containers/libpod/libpod/linkmode
github.com/containers/libpod/libpod/lock
github.com/containers/libpod/libpod/lock/file
github.com/containers/libpod/libpod/lock/shm
github.com/containers/libpod/libpod/logs
github.com/containers/libpod/libpod/logs/reversereader
github.com/containers/libpod/pkg/annotations
github.com/containers/libpod/pkg/api/handlers
github.com/containers/libpod/pkg/api/handlers/compat
github.com/containers/libpod/pkg/api/handlers/libpod
github.com/containers/libpod/pkg/api/handlers/swagger
github.com/containers/libpod/pkg/api/handlers/utils
github.com/containers/libpod/pkg/api/server
github.com/containers/libpod/pkg/api/server/idletracker
github.com/containers/libpod/pkg/api/types
github.com/containers/libpod/pkg/auth
github.com/containers/libpod/pkg/autoupdate
github.com/containers/libpod/pkg/bindings
github.com/containers/libpod/pkg/bindings/containers
github.com/containers/libpod/pkg/bindings/generate
github.com/containers/libpod/pkg/bindings/images
github.com/containers/libpod/pkg/bindings/manifests
github.com/containers/libpod/pkg/bindings/network
github.com/containers/libpod/pkg/bindings/play
github.com/containers/libpod/pkg/bindings/pods
github.com/containers/libpod/pkg/bindings/system
github.com/containers/libpod/pkg/bindings/volumes
github.com/containers/libpod/pkg/cgroups
github.com/containers/libpod/pkg/channelwriter
github.com/containers/libpod/pkg/checkpoint
github.com/containers/libpod/pkg/criu
github.com/containers/libpod/pkg/ctime
github.com/containers/libpod/pkg/domain/entities
github.com/containers/libpod/pkg/domain/filters
github.com/containers/libpod/pkg/domain/infra
github.com/containers/libpod/pkg/domain/infra/abi
github.com/containers/libpod/pkg/domain/infra/abi/parse
github.com/containers/libpod/pkg/domain/infra/abi/terminal
github.com/containers/libpod/pkg/domain/infra/tunnel
github.com/containers/libpod/pkg/domain/utils
github.com/containers/libpod/pkg/env
github.com/containers/libpod/pkg/errorhandling
github.com/containers/libpod/pkg/hooks
github.com/containers/libpod/pkg/hooks/0.1.0
github.com/containers/libpod/pkg/hooks/1.0.0
github.com/containers/libpod/pkg/hooks/exec
github.com/containers/libpod/pkg/inspect

Bug#976409: glibc breaks node-iconv autopkgtest: AssertionError [ERR_ASSERTION]: Missing expected exception

[Paul Gevers]

Source: glibc, node-iconv
Control: found -1 glibc/2.31-5
Control: found -1 node-iconv/2.3.5-4
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of glibc the autopkgtest of node-iconv fails in
testing on all architectures when that autopkgtest is run with the
binary packages of glibc from unstable. It passes when run with only
packages from testing. In tabular form:

   passfail
glibc  from testing2.31-5
node-iconv from testing2.3.5-4
all others from testingfrom testing

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=glibc

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-iconv/8618841/log.gz

autopkgtest [07:11:24]: test pkg-js-autopkgtest:
/usr/share/pkg-js-autopkgtest/runner
autopkgtest [07:11:24]: test pkg-js-autopkgtest: [---
# Using package.json
# Node module name is iconv
# Build files found:
# Test files found: test
# Files/dir to be installed from source: test
# Copy test files
# Copy debian/tests/pkg-js content
'debian/tests/pkg-js' ->
'/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/debian/tests/pkg-js'
'debian/tests/pkg-js/test' ->
'/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/debian/tests/pkg-js/test'
# Searching module in /usr/lib/nodejs/iconv
# Searching module in /usr/lib/aarch64-linux-gnu/nodejs/iconv
# Found /usr/lib/aarch64-linux-gnu/nodejs/iconv
# Searching files to link in /usr/lib/aarch64-linux-gnu/nodejs/iconv
'./build' -> '/usr/lib/aarch64-linux-gnu/nodejs/iconv/build'
'./lib' -> '/usr/lib/aarch64-linux-gnu/nodejs/iconv/lib'
'./package.json' -> '/usr/lib/aarch64-linux-gnu/nodejs/iconv/package.json'
# Searching module in /usr/share/nodejs/iconv
# Launch debian/tests/pkg-js/test with sh -ex
+ mkdir -p test/tmp
+ node test/run-tests.js
assert.js:101
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: Missing expected exception.
at Object.
(/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/test/test-basic.js:136:8)
at Module._compile (internal/modules/cjs/loader.js:1015:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1035:10)
at Module.load (internal/modules/cjs/loader.js:879:32)
at Function.Module._load (internal/modules/cjs/loader.js:724:14)
at Module.require (internal/modules/cjs/loader.js:903:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object.
(/tmp/autopkgtest-lxc.djwhve30/downtmp/autopkgtest_tmp/smokeZDEmls/test/run-tests.js:2:1)
at Module._compile (internal/modules/cjs/loader.js:1015:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1035:10) {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: undefined,
  expected: undefined,
  operator: 'throws'
}
autopkgtest [07:11:25]: test pkg-js-autopkgtest: ---]




OpenPGP_signature
Description: OpenPGP digital signature

Bug#974706: This package isn't complete, as the cjlx parts aren't packaged

[Louis-Philippe Véronneau]

fixed 974706 1.1.12-1
thanks

I have fixed the package in Salsa [1] and it's ready to upload once
cljx-clojure passes NEW.

[1]: https://salsa.debian.org/clojure-team/prismatic-schema-clojure

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973537: ausweisapp2: Backporting 1.20.2-1 to buster requires small patch

[John Paul Adrian Glaubitz]

On 12/4/20 8:37 PM, Alexander Weisse wrote:> I guess that's too much work. 
1.22.0 now also depends on
> libqt5qmlworkerscript5 and maybe other features of Qt 5.12. 
> 
> 1.20.2 with my patch is probably the highest version one can build for
> buster.

OK, I'll uploaded a patched 1.20.2 to backports then.

> And bullseye is coming soon...

I see you have good humor (or a different definition of "soon") ;-).

Adrian

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

Bug#976120: (QAbc packaging) debhelper version question

[Benoît Rouits]

Hello,

About packaging QAbc I have an interrogation:
I use debhelper but I don't use specific features
of debhelper 13.
Anyway, should I set debhelper = 13 as build dependency
or can I set debhelper >= 12 to be more flexible
for transition from sid to testing and to stable ?

Thanks for your replies.
 Benoît

Bug#976310: [Pkg-javascript-devel] Bug#976310: Bug#976310: node-compression-webpack-plugin: TypeError: (0 , _schemaUtils.validate) is not a function

[Pirate Praveen]

Control: clone -1 -2
Control: reassign -2 node-css-loader
Control: retitle -2 many dependencies in the archive differ by major 
versions


On Fri, Dec 4, 2020 at 02:35, Pirate Praveen  
wrote:
I will try to get css-loader from debian working with gitlab as a 
proper fix.


With css-loader 3, the error is given at bottom,

I think some of the dependencies of node-css-loader 3 in the archive 
are not matching major versions


 "postcss-modules-extract-imports": "^2.0.0", vs 
node-postcss-modules-extract-imports: 3.0.0-1

   "postcss-modules-local-by-default": "^3.0.2", and 4.0.0 is embedded
   "postcss-modules-scope": "^2.1.1", and 3.0 is embedded
   "postcss-modules-values": "^3.0.0", vs node-postcss-modules-values 
4.0

   "postcss-value-parser": "^4.0.2", vs node-postcss-value-parser

ERROR in 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/base/browser/ui/menu/men
u.css 
(/usr/share/nodejs/css-loader/dist/cjs.js??ref--9-1!/var/lib/gitlab/.node_modu

les/monaco-editor/esm/vs/base/browser/ui/menu/menu.css)
Module build failed (from /usr/share/nodejs/css-loader/dist/cjs.js):
Error: true is not a PostCSS plugin
   at Processor.normalize 
(/var/lib/gitlab/.node_modules/postcss/lib/processor.js:1

68:15)
   at new Processor 
(/var/lib/gitlab/.node_modules/postcss/lib/processor.js:52:25)
   at postcss 
(/var/lib/gitlab/.node_modules/postcss/lib/postcss.js:55:10)

   at Object.loader (/usr/share/nodejs/css-loader/dist/index.js:84:24)
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/base/browser/ui/menu/menu.css

4:14-120
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/base/browser/ui/menu/menu.js
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/platform/contextview/browser/c

ontextMenuHandler.js
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/platform/contextview/browser/c

ontextMenuService.js
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/editor/standalone/browser/stan

daloneServices.js
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/editor/standalone/browser/stan

daloneEditor.js
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/editor/editor.api.js
@ 
include-loader!/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/editor/editor.a

pi.js
@ 
/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/language/typescript/monaco.con

tribution.js
@ 
include-loader!/var/lib/gitlab/.node_modules/monaco-editor/esm/vs/editor/editor.m

ain.js
@ ./editor/editor_lite.js
@ ./blob/utils.js
@ ./snippet/snippet_bundle.js
@ ./snippet/snippet_edit.js
@ ./pages/snippets/new/index.js
@ multi ./main ./pages/snippets/new/index.js

Bug#976144: librttopo1: buggy/missing geojson support

[Sebastiaan Couwenberg]

On 12/4/20 7:54 PM, Roman K wrote:
>> Понедельник, 30 ноября 2020, 15:56 +03:00 от Sebastiaan Couwenberg 
>> :
>> On 11/30/20 1:31 PM, Roman Kurakin wrote:
>>> Since librttopo is suggested as a replacement for liblwgeom, and the part 
>>> of it
>>> functionality is missing (switched off by ifdef) the bug becomes critical.
>>>
>>> Functionality is switched off due to missing code in configure. Looks like 
>>> it
>>> was lost while fork from original liblwgeom (part of postgis project).
>>>
>>> All of the versions currently in debian are affected by this problem.
>>
>> Thanks for the patch, but I'm hesitant to apply it as it's a little
>> invasive.
>>
>> Currently libspatialite is the only user of librttopo, and it likely
>> doesn't need the geojson support.
>
> But what should do packages that are not part of debian?
> liblwgeom is removed from postgis 3.0...

That's up to those projects, if they can't wait for librttopo to get
fixed they could consider embedding a patched copy. Or reinstate the
shared library changes in the postgis package for their own local
package repo for example.

>> Please forward your changes upstream:
>>
>>   https://git.osgeo.org/gitea/rttopo/librttopo
>>
>> Once the changes are applied upstream we can consider included them in
>> the Debian package.
>
> Already done, but project doesn’t look as actively maintained, the bug was 
> described three years ago,
> but bug reporter was unable to provide a patch.
> https://git.osgeo.org/gitea/rttopo/librttopo/issues/21#issuecomment-8877

librttopo is indeed not developed very actively, but it so far serves it
purpose of enabling the topology support in spatialite.

With the postgis Debian package no longer providing liblwgeom it is not
unlikely that librttopo will get more users which may motivate more
active development. Especially if that's in the form of pull requests
that can be merged easily.

If you want to raise more awareness of this issue, you may also want to
discuss it on the mailinglist: librttopo-...@lists.osgeo.org

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#900837: update on mass-rebuild of packages for reproducible builds

[Paul Gevers]

Hi Vagrant

On 04-12-2020 03:46, Vagrant Cascadian wrote:
> On 2019-03-05, Holger Levsen wrote:
>> I ran Chris's script again on coccia, with the result that currently
>> 6084 source packages in the archive need a rebuild for reproducible
>> builds, as they were built with an old dpkg version not producing
>> .buildinfo files.
> 
> I ran it just now, and we're down to 3433! Still a ways to go, but
> getting there...
> 
> Updated list attached.

Maybe it's slightly more interesting what's in bullseye as we have quite
a bit of junk in unstable.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976352: transition: libjsoncpp

[Gianfranco Costamagna]

Of the 44 involved packages, 34 of them are binNMU ok, rebuilds were fine.

Of the remaining 10, 1 is an unrelated FTBFS, one is trivially fixable and the 
other are ongoing.

I'll open bugs with patches in the next few days.

G.

cmake   ok
bamtoolsok
chromiumok
dublin-traceroute   ok
ignition-fuel-tools ok
iptux   ok
kodi-pvr-argustvok
kodi-pvr-hdhomerun  ok
lgogdownloader  ok
libjson-rpc-cpp ok
libopenshot ok
minetestok
mstflintok
oomdok
opendht ok
openvr  ok
openxr-sdk-source   ok
orthanc ok
ossim   ok
securefsok
sysdig  ok
vtk7ok
vtk9ok
waybar  ok
ginkgocadx  ok
orthanc-dicomwebok
orthanc-gdcmok
orthanc-mysql   ok
orthanc-postgresql  ok
orthanc-python  ok
orthanc-webviewer   ok
orthanc-wsi ok
ringok
tvc ok
kopanocore  fail (unrelated: #969297)
libseqlib   fail
mrptfail (json)
odilfail
open3d  fail
polybar fail (unrelated: #975795)
seqtoolsfail (dh_shlibs trivial fix)
spring  fail
springlobby fail
vtk6fail

Bug#976377: RM: sqlite/2.8.17-15, golang-gosqlite-dev/0.0~hg20130601-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Simon,

On 04-12-2020 11:10, Simon McVittie wrote:
> Please mark golang-gosqlite-dev and sqlite for removal from testing.
> sqlite version 2 has been unsupported since 2005 and its removal from
> Debian was first proposed in 2010; golang-gosqlite-dev is the last
> remaining reverse-dependency in testing, and has no rdeps itself.
> See https://bugs.debian.org/607969 for more information.

Any reason why you don't request this from unstable? That's the normal
route that packages are removed from testing.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976407: RFS: shotwell/0.30.11-1 -- digital photo organize

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: shotwell
   Version : 0.30.11-1
   Upstream Author : Jim Nelson 
   URL : https://wiki.gnome.org/Apps/Shotwell
   License : LGPL-2.1
   Vcs : https://jff.email/cgit/shotwell.git
   Section : gnome

It builds those binary packages:

  shotwell-common - digital photo organizer - common files
  shotwell - digital photo organizer

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.11-1.dsc

or from 

 git https://jff.email/cgit/shotwell.git?h=release%2Fdebian%2F0.30.11-1


Changes since the last upload:

 shotwell (0.30.11-1) unstable; urgency=medium
 .
   * New upstream release.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#973537: ausweisapp2: Backporting 1.20.2-1 to buster requires small patch

[John Paul Adrian Glaubitz]

On 12/4/20 7:39 PM, A. Klitzing wrote:
> that won't work because 1.22.0 requires Qt 5.12 or higher. Buster uses Qt 
> 5.11.

Well, my question was whether there might be a way to patch that out ;-).

Adrian

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

Bug#973537: ausweisapp2: Backporting 1.20.2-1 to buster requires small patch

[A. Klitzing]

> I just uploaded updated the package to 1.22.0 in unstable.
>
> Could you check whether your patch applies to 1.22.0 as well? If yes, I can 
> just upload
> a backported 1.22.0 with your patch included.
>
> Adrian

Hi Adrian,

that won't work because 1.22.0 requires Qt 5.12 or higher. Buster uses Qt 5.11.

André