Bug#978608: node-rollup-plugin-node-resolve: Update to new upstream version 11.x

[Pirate Praveen]

Package: node-rollup-plugin-node-resolve
Version: 10.0.0+repack+~4.2.4-1
severity: important

At least autoprefixer-rails build is broken with version 10.

https://github.com/ai/autoprefixer-rails/pull/200#issuecomment-751924645

Probably more builds are silently broken.

While at it, I think we should try to remove the embedded copy of the legacy 
plugin and port all reverse dependencies to the new version.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#978554: vice: no man page installed

[GCS]

Hi Reiner,

On Mon, Dec 28, 2020 at 4:09 PM Reiner Herrmann  wrote:
> I noticed that since 3.5.0.dfsg-1 the vice manpage is no longer
> included. The symlinks from e.g. x64.1.gz to vice.1.gz are still there,
> but the file vice.1.gz is missing.
> Also the other manpages from 3.4.0.dfsg-1 are missing:
>  c1541.1.gz, cartconv.1.gz, petcat.1.gz
 The mentioned symlinks are leftovers, sorry for that. Man pages are
no longer exists for VICE, see the 3.5 release news [1]:
"Another bunch of files were removed because their content was
hopelessly outdated and/or could be moved to other files:
 - removed the MAN pages. Read the html or pdf manual instead."

> I also noticed that the ROM images are now in /usr/share/vice instead of
> /usr/lib/vice. I have now manually copied them as documented, but I'm
> wondering what will happen when I upgrade vice.
> As some "dummy" files are now part of the package, they will probably
> get overwritten again with each update, so I have to copy them over
> again. Is this still the recommended way (as documented in README.ROMs)?
 Wasn't the 'dummy' files always there? Need to investigate. Those are
meant for placeholders for the source and its installation scripts.
The original binary files are still non-free unfortunately.
I think I've documented that if you are the only VICE user, the best
place for the ROMs is in the ~/.local/share/vice/ directory.

Regards,
Laszlo/GCS
[1] https://vice-emu.sourceforge.io/NEWS

Bug#264039: Patch to add memusage and memusagestat

[Josh Triplett]

On Tue, 21 Apr 2020 20:58:56 +0200 Stephen Kitt  wrote:
> The attached patch adds memusage and memusagestat to the libc-bin package.
> This does mean that the latter becomes dependent on libgd3, so it might be
> better to add a new memusage package; I can take care of that if the
> maintainers think it’s better.

I do think it makes sense to have these in a separate package. Would you
consider moving libmemusage.so to that same separate package?

- Josh Triplett

Bug#978555: libpam-modules: breaks cron: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file

[Sven Joachim]

Control: severity -1 serious

On 2020-12-29 00:29 +0100, Vincent Lefevre wrote:

> Control: severity -1 normal
>
> After a reboot too, the problem no longer occurs.
>
> Perhaps there should be a warning saying that some services may need
> to be restarted.

There is already code in the libpam0g postinst script to restart them,
but it is only triggered on upgrades from versions older than 1.3.1-2,
which is apparently not enough.

Silently breaking running services on upgrades is not acceptable, we can
do better. :-)

Cheers,
   Sven

Bug#977473: Re-activate test for gdcm

[Andreas Tille]

Control: retitle -1 Reactivate test for gdcm which was excluded due to failure
Control: severity -1 important

This single test prevented testing migration of this package and all
its dependencies.  Thus the test was deactivated for the moment to
enable building the package.  But the issue should be clarified.

The exclusion of the test is done in debian/patches/ignore_failing_test.patch.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#978606: ITP: golang-modernc-kv -- simple and easy to use persistent key/value (KV) store

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-modernc-kv
  Version : 1.0.3-1
  Upstream Author : cznic
* URL : modernc.org/kv
* License : BSD
  Programming Lang: Go
  Description : Package kv implements a simple and easy to use
persistent key/value (KV) store.

This is needed for perkeep.


--
Alexandre Viau
av...@debian.org

Bug#978605: ITP: golang-github-nf-cr2 -- A basic Camera Raw 2 reader

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-nf-cr2
  Version : 0.0~git20180623.4699471-1
  Upstream Author :
* URL : https://github.com/nf/cr2
* License : BSD-3-clause
  Programming Lang: Go
  Description : A basic Camera Raw 2 reader

this is needed for perkeep

--
Alexandre Viau
av...@debian.org

Bug#950771: Corrections on elaboration

[Simon khng]

Hi Chris,

To elaborate more on what I am trying to say.
The use of option '--fake' whether '--no-mtab' is present or not done by
root will
not affect '/usr/mtab', however, missing '--no-mtab' changes
'/run/mount/utab' and causes a 'umount failed: Operation not permitted'
when umount by a original user. This is rather unexpected since '--fake'
should be a simulation but changes something.

This could be just a documentation issue and it is not my intent to reopen
the issue. Just pointing it out in case it happens to be an overlooked
actual bug.

Sincerely,
Simon

Bug#978604: ITP: golang-rsc-qr -- QR codes

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-rsc-qr
  Version : 0.2.0-1
  Upstream Author : Russ Cox
* URL : https://github.com/rsc/qr
* License : BSD-3-clause
  Programming Lang: Go
  Description : QR codes

This is needed for perkeep.

--
Alexandre Viau
av...@debian.org

Bug#978603: ITP: golang-rsc-pdf -- PDF reader

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-rsc-pdf
  Version : 0.1.0-1
  Upstream Author : Russ Cox
* URL : https://github.com/rsc/pdf
* License : BSD-3-clause
  Programming Lang: Go
  Description : PDF reader

This is needed for perkeep.

--
Alexandre Viau
av...@debian.org

Bug#978602: volk: Add libcpu-features-dev to Build-Depends on powerpc and x32

[Shengjing Zhu]

Source: volk
Version: 2.4.1-2
Severity: normal
X-Debbugs-Cc: z...@debian.org

Dear Maintainer,

It seems I forgot to add powerpc and x32 to cpu-features Architecture
list.

I've fixed in cpu-features/0.6.0-3. Please add it to volk's
Build-Depends as well.

Thanks

Bug#978601: postrm doesn't remove session-noninteractive files

[Josh Triplett]

Package: libpam-runtime
Version: 1.4.0-1
Severity: normal
File: /var/lib/dpkg/info/libpam-runtime.postrm
X-Debbugs-Cc: j...@joshtriplett.org

libpam-runtime.postrm contains:

> if [ "$1" = "purge" ]; then
> rm -f /etc/pam.d/common-auth /etc/pam.d/common-account \
>   /etc/pam.d/common-session /etc/pam.d/common-password
> rm -f /var/lib/pam/auth /var/lib/pam/account /var/lib/pam/session \
>   /var/lib/pam/password /var/lib/pam/seen
> rmdir --ignore-fail-on-non-empty /var/lib/pam
> fi

This doesn't remove /etc/pam.d/common-session-noninteractive or
/var/lib/pam/session-noninteractive.

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

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

Versions of packages libpam-runtime depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libpam-modules 1.4.0-1

libpam-runtime recommends no packages.

libpam-runtime suggests no packages.

-- debconf information excluded

Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)

[Josh Triplett]

Package: libpam-modules
Version: 1.4.0-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org, debian-de...@lists.debian.org

The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to
libnsl2 and libtirpc3, which brings those packages into the
pseudo-Essential set. This is a rather substantial increase in the
number of pseudo-Essential packages; it also pulls in libgssapi-krb5-2,
libkrb5-3, libtirpc-common, libk5crypto3, libkrb5support0, and
libkeyutils1. In addition, it adds a second dependency on libcom-err2,
which was otherwise only pulled in by e2fsprogs (Essential but generally
safely removable).

I realize it makes sense to migrate from the previous libc-provided
RPC/NIS support to the separate libraries. However, this seems likely to
make those libraries quite difficult to remove from pseudo-Essential in
the future. I'm reporting this issue as soon as I noticed it, in the
hopes that it might be possible to mitigate this before the the next
stable release, before it becomes further entrenched and migrations
become more challenging.

A few possible ideas for how to address this:

- Make pam_unix dlopen the necessary libraries, which (given sufficient
  notice) would allow dropping the hard dependency. Considering that
  libc6 already only Recommends the NSS modules for NIS, it seems
  reasonable to follow suit here.
- Build pam_unix with and without NIS support, and make libpam-modules
  Pre-Depends on a non-Essential "libpam-unix-nis | libpam-unix". (This
  seems rather more invasive, but cleaner long-term.)
- Migrate libpam-modules itself towards dropping the Essential flag. PAM
  no longer "fails open" in the absence of configuration or specified
  modules, so this should be safe. A system without PAM still functions,
  and just doesn't support PAM authentications/sessions/etc; this
  doesn't seem any more unreasonable than making init non-Essential
  (because chroots and some containers don't need it), or eventually
  making login non-Essential (because systems without interactive
  console login don't need it).

I'm happy to contribute towards any of these paths, or another path that
would avoid expanding the pseudo-Essential set.

Bug#950771: closed by Chris Hofstaedtler (Re: Bug#950771: mount: unexpected behaviour with "-f" option)

[Simon khng]

Hi Chris,

To elaborate more on what I am trying to say.
The use of option '--fake' whether '--no-mtab' is present or not done by
root will cause a 'umount failed: Operation not permitted' when umount by a
original user. This is rather unexpected since '--fake' should be a
simulation and all the more unexpected if '--no-mtab' is specified.

Sincerely,
Simon

On Mon, Dec 28, 2020 at 9:00 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the mount package:
>
> #950771: mount: unexpected behaviour with "-f" option
>
> It has been closed by Chris Hofstaedtler .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Chris Hofstaedtler <
> z...@debian.org> by
> replying to this email.
>
>
> --
> 950771: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950771
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Chris Hofstaedtler 
> To: Simon , 950771-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 28 Dec 2020 01:56:47 +0100
> Subject: Re: Bug#950771: mount: unexpected behaviour with "-f" option
> * Simon  [201228 00:54]:
> > Using mount with '-f' will write to /run/mount/utab.
> > I think the '-n' option should be included implicitly since it is just a
> simulation?
>
> No. The man page even says (paraphrased) "-f can be used after -n".
>
> > When the root user does a mount with '-f' on a device previously mounted
> by another user granted with option 'user' specified in an entry of
> /etc/fstab,
> > an umount by the original user will cause a 'umount failed: Operation
> not permitted'
>
> Thats probably expected.
>
> > -- Comments/feeback/question:
> > Not sure how and if namespaces/context option can help alter user/group
> during a mount by root user.
> > Is there a way to restict which user/group can mount a device using
> user=XXX,group=xxx option in /etc/fstab since that is how /run/mount/utab
> is recorded?
>
> Not using mount or in /etc/fstab. Maybe policykit can provide finer
> grained control.
>
> Closing this for now.
>
> Chris
>
>
> -- Forwarded message --
> From: Simon 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Thu, 06 Feb 2020 09:56:35 +0800
> Subject: mount: unexpected behaviour with "-f" option
> Package: mount
> Version: 2.33.1-0.1
> Severity: minor
>
> -- Additional info:
> Using mount with '-f' will write to /run/mount/utab.
> I think the '-n' option should be included implicitly since it is just a
> simulation?
>
> When the root user does a mount with '-f' on a device previously mounted
> by another user granted with option 'user' specified in an entry of
> /etc/fstab,
> an umount by the original user will cause a 'umount failed: Operation not
> permitted'
>
> -- Comments/feeback/question:
> Not sure how and if namespaces/context option can help alter user/group
> during a mount by root user.
> Is there a way to restict which user/group can mount a device using
> user=XXX,group=xxx option in /etc/fstab since that is how /run/mount/utab
> is recorded?
>
> -- System Information:
> Debian Release: 10.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages mount depends on:
> ii  libblkid1  2.33.1-0.1
> ii  libc6  2.28-10
> ii  libmount1  2.33.1-0.1
> ii  libselinux12.8-1+b1
> ii  libsmartcols1  2.33.1-0.1
> ii  util-linux 2.33.1-0.1
>
> mount recommends no packages.
>
> Versions of packages mount suggests:
> pn  nfs-common  
>
> -- no debconf information
>

Bug#854889: still fails with qemu from buster-backports

[Matija Nalis]

found 854889 qemu/1:5.0-14~bpo10+1
thanks

sparc64 bug is still there with qemu-user-static 1:5.0-14~bpo10+1,
trying to enter qemu-debootstrap chroot with qemu-sparc64-static:


user@phyhost> sudo chroot sid bin/bash ; echo "EXIT $?"
*** longjmp causes uninitialized stack frame ***: terminated
EXIT 0


Some simple commands run, and then terminate qemu-sparc64-static
immediately:

user@phyhost> sudo chroot sid bin/dash ; echo "EXIT $?"
# arch
sparc64
EXIT 0

user@phyhost> sudo chroot sid md5sum /usr/bin/qemu-sparc64-static ; echo "EXIT 
$?"
a335ea29569463a13455746e67abc56c  /usr/bin/qemu-sparc64-static
EXIT 0

user@phyhost>

-- 
Opinions above are GNU-copylefted.

Bug#962203: NMU

[Paul Wise]

On Mon, 2020-12-28 at 21:50 -0500, Calum McConnell wrote:

> Yeah, when I tried to build it locally, it failed due to files that
> are present in the source package but missing from Git.

There are more changes than just the documentation build things though.

> I eventually gave up and just included the PDF I built locally in the
> source package.

I don't think it is ever appropriate to include generated files in
version control repositories and almost never in source tarballs.

> If you'd like, I can revert back and generate a more minimal NMU.
> ...
> As long as it gets fixed!

Maybe lets wait for A Mennucc1 to do a maintainer upload, and if it
gets close to the next autoremoval date, do a more minimal NMU.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962203: NMU

[Calum McConnell]

On Tue, 2020-12-29 at 10:36 +0800, Paul Wise wrote:
> On Mon, 14 Dec 2020 17:23:08 -0500 Calum McConnell wrote:
> 
> > I have prepared an NMU for this package.  It is currently at
> > https://mentors.debian.net/package/debdelta/ .  While I need a sponsor
> > to
> > get it into Debian, I am now reaching out to
> > ment...@lists.debian.org to
> > see if I can expedite the process.
> 
> I was looking at sponsoring this, but based on the debdiff it appears
> to have some changes that are not in the patch you posted to the bug.

Yeah, when I tried to build it locally, it failed due to files that are
present in the source package but missing from Git.  I had to manually
generate the PDF docs, and the additional changes were me trying to
automate that process.  However, while the modified commands ran fine on
my testing box and in a testing schroot, they broke spectacularally in the
unstable schroot.  After several hours of adding more build dependencies
to try and make it work, I eventually gave up and just included the PDF I
built locally in the source package.  

If you'd like, I can revert back and generate a more minimal NMU.

> It looks like A Mennucc1 will be working on this issue soon though.

As long as it gets fixed!

Thanks,
Calum


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

Bug#962203: NMU

[Paul Wise]

On Mon, 14 Dec 2020 17:23:08 -0500 Calum McConnell wrote:

> I have prepared an NMU for this package.  It is currently at
> https://mentors.debian.net/package/debdelta/ .  While I need a sponsor to
> get it into Debian, I am now reaching out to ment...@lists.debian.org to
> see if I can expedite the process.

I was looking at sponsoring this, but based on the debdiff it appears
to have some changes that are not in the patch you posted to the bug.

It looks like A Mennucc1 will be working on this issue soon though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#978598: net-snmp: reproducible builds: embeded paths to "ps" and "uname"

[Vagrant Cascadian]

Source: net-snmp
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Various files contain an embedded paths to the "uname" and "ps"
commands:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/net-snmp.html

  ./usr/bin/net-snmp-create-v3-user
  
  if·/bin/ps·-e·|·egrep·'·snmpd·*$'·>·/dev/null·2>&1·;·then
  vs.
  if·/usr/bin/ps·-e·|·egrep·'·snmpd·*$'·>·/dev/null·2>&1·;·then


The attached patch fixes this by passing the UNAMEPROG and PSPROG
variables to configure.


This ensures that regardless of weather the system is built with a
merged /usr or a traditional system, the resulting binaries will be
useable on both systems (where compatibility symlinks for /bin ->
/usr/bin typically are present).


Thanks for maintaining net-snmp!


live well,
  vagrant
From 9104ccb98745f67265e8c4338ccb0b100e531f25 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 29 Dec 2020 01:15:10 +
Subject: [PATCH] debian/rules: Pass UNAMEPROG and PSPROG to configure.

The paths to "uname" and "ps" may vary as either /bin/CMD or
/usr/bin/CMD if the system is configured as a usrmerge system. Use
/bin/CMD for the most compatible location.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 41b0a45..f8fdf8b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -54,6 +54,8 @@ override_dh_auto_configure:
 	  --with-mibdirs="\$$HOME/.snmp/mibs:$(MIBS_DIR)" \
 	  --with-mysql \
 	  --enable-blumenthal-aes \
+	  UNAMEPROG=/bin/uname \
+	  PSPROG=/bin/ps \
 	  --with-defaults
 # --with-dnssec-local-validation  # not enabled since libval doesn't exist in Debian yet
 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#978589: systemd based startup not working

[Jamie Zawinski]

The fact that $DISPLAY is not set at the time xscreensaver is launched is not a 
good sign. The cookie error suggests that ~/.Xauthority does not exist or is 
not readable. However you do appear to be running as yourself, not as "nobody". 
Perhaps $HOME is set to something weird? Maybe try setting your command to 
"printenv ; pwd ; xdpyinfo ; xscreensaver" and see if that provides some clues.

Bug#978597: ITP: golang-github-hjfreyer-taglib-go -- Pure go audio tag library in the spirit of taglib

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-hjfreyer-taglib-go
  Version : 0.0~git20151027.0ef8bba-1
  Upstream Author : Hunter Freyer
* URL : https://github.com/hjfreyer/taglib-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Pure go audio tag library in the spirit of taglib

--
Alexandre Viau
av...@debian.org

Bug#978596: ITP: golang-github-filosottile-b2 -- Efficient, idiomatic Go library for Backblaze B2 Cloud Storage.

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-filosottile-b2
  Version : 0.0~git20170207.b197f7a-1
  Upstream Author : Filippo Valsorda
* URL : https://github.com/FiloSottile/b2
* License : Expat
  Programming Lang: Go
  Description : Efficient, idiomatic Go library for Backblaze B2
Cloud Storage.

this is needed for syncthing

--
Alexandre Viau
av...@debian.org

Bug#928184: valgrind: please add valgrind-if-available metapackage

[Adam Borowski]

Control: tags -1 +patch

Here's a patch to implement this metapackage.

It has to be arch:any as dpkg-dev resolves architectures at package build
time rather than during install.

I've filed it as
https://salsa.debian.org/debian/valgrind/-/merge_requests/2
if you prefer that over a patch.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `
>From 8818a51733b07db7732ec208992aa79e5618fd7a Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Tue, 29 Dec 2020 01:20:32 +0100
Subject: [PATCH] Add a metapackage: valgrind-if-available

---
 debian/control | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/control b/debian/control
index c2672040..c515e266 100644
--- a/debian/control
+++ b/debian/control
@@ -68,3 +68,12 @@ Description: instrumentation framework for building dynamic analysis tools (MPI
  .
  This package provides the "mpiwrap" library for debugging distributed-memory
  applications which use the MPI message passing standard.
+
+Package: valgrind-if-available
+Architecture: any
+Depends: valgrind [amd64 arm64 armhf i386 mips mipsel mips64 mips64el powerpc ppc64 ppc64el s390x x32]
+Description: dependency package to pull in Valgrind if it's available
+ This metapackage installs Valgrind on architectures where it is available.
+ As the list of archs where Valgrind works changes quite often, explicitely
+ listing it as a [Build-]Depend is cumbersome and prone to being outdated.
+ Instead, you may use this metapackage.
-- 
2.30.0.rc2

Bug#978594: O: pylint-plugin-utils -- Utilities and helpers for writing Pylint plugins (Python 3)

[Joseph Herlant]

Package: wnpp
Severity: normal
X-Debbugs-Cc: aerosti...@debian.org

I intend to orphan the pylint-plugin-utils package. I haven't taken any time
for my packages this year and don't see this changing anytime soon so retiring.

The package description is:
 This is not a direct Pylint plugin, but rather a set of tools

Bug#978593: O: pylint-django -- Pylint plugin for analysing code using Django (Python 3)

[Joseph Herlant]

Package: wnpp
Severity: normal
X-Debbugs-Cc: aerosti...@debian.org

I intend to orphan the pylint-django package. I didn't take any time for my
packages this year and don't see this changing anytime soon, so retiring.

The package description is:
 Features
   * Prevents warnings about Django-generated attributes such as
 Model.objects or Views.request.
   * Prevents warnings when using ForeignKey attributes
 ("Instance of ForeignKey has no member").
   * Fixes pylint's knowledge of the types of Model and Form field attributes
   * Validates Model.__unicode__ methods.
   * Meta informational classes on forms and models do not generate errors.
 It is also used by the Prospector tool.

Bug#945188: xpdf: memory leak when changing page

[Adam Sampson]

> This issue might be in the package since poppler-0.71.patch.
> This patch makes some changes how containers get accessed.

I've had a look at this in xpopple today (my Poppler-ified version of
xpdf; see #977182 or http://offog.org/code/xpopple/).

Previously I'd kept a copy of GooList in xpopple when it was removed
from Poppler (renamed to XPDFList), but I've now reworked the remaining
GooList-using code to use std::vector instead, without using raw
pointers -- in the places where the items do need to be owning pointers
I've used vector> instead, which makes the code quite a bit
simpler.

My XPDFParams code would probably be tricky to backport to Debian's
current version, but you might be able to take the patches for the other
GooLists as is...

Cheers,

-- 
Adam Sampson  

Bug#978585: [pkg-cryptsetup-devel] Bug#978585: libcryptsetup-dev: wrong libdir variable in libcryptsetup.pc

[Guilhem Moulin]

Hi Luca,

On Mon, 28 Dec 2020 at 21:56:25 +, Luca Boccassi wrote:
> The problem is that the ${libdir} variable in the pkg-config file is
> not adjusted accordingly, so the wrong -L flags are exposed.
> Given it's a standard path this is not usually an issue when building
> reverse dependencies, but pkg-config can be used in more occasions
> than that. For example, the systemd integration test suite uses it to
> check where libraries are installed in a distro-agnostic way.

Thanks for the poke!  I'm not specially fond of that breakout link .so
/usr/lib/$DEB_HOST_MULTIARCH/libcryptsetup.so → /lib/$DEB_HOST_MULTIARCH/…
(that also causes lintian to spew a ‘breakout-link’ warning).  I'm also
not so fond of that sed rule :-P  Another way to fix the issue you
reported is to move libcryptsetup.so to /lib/$DEB_HOST_MULTIARCH/… where
the versioned link lives.  Does ec9b7931 help?  (That now causes lintian
to spew a ‘lacks-unversioned-link-to-shared-library’, but I'll silence
it following the reasoning from #843932.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#911587: infnoise: busy-waits, using too much CPU

[Axel Beckert]

Hi Stephen,

Stephen Kitt wrote:
> I have figured out what was wrong (cue brown paper bag for me), I’ll upload a
> fix shortly.

Yay, thanks! Much appreciated!

> > Not sure if any of these fix this issue.
> 
> 0.3.1 was already in unstable,

Oops, ok, sorry, my fault for not looking closer.

> but the error came from incomplete build
> flags...

Yeah, just read the changelog of the package.

> > That's nice, but any chance to get infnoise back into testing?
> 
> Yup!

Thanks again!

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

Bug#978592: O: asciidoc -- Highly configurable text format for writing documentation

[Joseph Herlant]

Package: wnpp
Severity: normal

I intend to orphan the asciidoc package. I haven't had taken the time to take
care of my packages over the last few months and don't see this changing
anytime soon so I'm retiring.

The package description is:
 AsciiDoc is a text document format for writing articles, books, manuals and
 UNIX man pages. AsciiDoc files can be translated to HTML (with or without
 stylesheets), DocBook (articles, books and refentry documents) and LinuxDoc
 using the asciidoc command. AsciiDoc can also be used to build and maintain
 websites.
 .
 You write an AsciiDoc document the same way you would write a
 normal text document, there are no markup tags or weird format notations.
 AsciiDoc files are designed to be viewed, edited and printed directly or
 translated to other presentation formats
 .

Bug#978591: golang-github-gomodule-oauth1 -- OAuth 1.0 client package for Go

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-gomodule-oauth1
  Version : 0.0~git20181215.9a59ed3-1
  Upstream Author :
* URL : https://github.com/gomodule/oauth1
* License : Apache-2.0
  Programming Lang: Go
  Description : OAuth 1.0 client package for Go

This is needed for perkeep.

--
Alexandre Viau
av...@debian.org

Bug#978590: ITP: golang-github-jonas-p-go-shp -- Go library for reading and writing ESRI Shapefiles.

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-jonas-p-go-shp
  Version : 0.1.1-1
  Upstream Author : Jonas Palm
* URL : https://github.com/jonas-p/go-shp
* License : Expat
  Programming Lang: Go
  Description : Go library for reading and writing ESRI
Shapefiles. Pure Golang implementation based on the ESRI Shapefile
technical description.

This is needed for perkeep.

--
Alexandre Viau
av...@debian.org

Bug#978524: buildah: build-using-dockerfile not sufficient privileges

[mailing lists]

so, after digging further, I found out, it is a upstream issue. something
with 1.16 broke it seems (I tested ubuntu and leap, which sadly are still
on 1.15 and 1.14) that's why I thought it was a debian issue.

the bugreport is on github is here:
https://github.com/containers/buildah/issues/2876

Bug#978589: systemd based startup not working

[Eduard Bloch]

Package: xscreensaver
Version: 5.45+dfsg1-1
Severity: important

Hi,

just what the title says. I have configured xscreensaver start via
systemd user session as suggested in README.Debian. Not working now but
it has been a few weeks ago.

I am wondering about the MAGIC COOKIE problem. My startup sequence is
old school, lightdm -> Xsession and ~/.xsession contains a few commands
and eventually "exec icewm-session".

One noteworthy thing is also that for a few seconds after login I can
see an active xscreensaver process in the process list and then it
suddenly terminates.

$ systemctl --user status xscreensaver.service
â—? xscreensaver.service - XScreenSaver
 Loaded: loaded (/usr/lib/systemd/user/xscreensaver.service; enabled; 
vendor preset: enabled)
 Active: failed (Result: exit-code) since Tue 2020-12-29 00:30:47 CET; 7min 
ago
Process: 2652 ExecStart=xscreensaver (code=exited, status=1/FAILURE)
   Main PID: 2652 (code=exited, status=1/FAILURE)
CPU: 6ms

Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: warning: 
$DISPLAY is not set: defaulting to ":0.0".
Dez 29 00:30:47 whitestar xscreensaver[2652]: Invalid MIT-MAGIC-COOKIE-1 
keyxscreensaver: 00:30:47: Can't open display: :0.0
Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: running 
as bloch/bloch (500/500)
Dez 29 00:30:47 whitestar xscreensaver[2652]: xscreensaver: 00:30:47: Errors at 
startup are usually authorization problems.
Dez 29 00:30:47 whitestar xscreensaver[2652]:   But you're not 
logging in as root (good!) so something
Dez 29 00:30:47 whitestar xscreensaver[2652]:   else must be wrong. 
 Did you read the manual and the FAQ?
Dez 29 00:30:47 whitestar xscreensaver[2652]:   
https://www.jwz.org/xscreensaver/faq.html
Dez 29 00:30:47 whitestar xscreensaver[2652]:   
https://www.jwz.org/xscreensaver/man.html
Dez 29 00:30:47 whitestar systemd[2626]: xscreensaver.service: Main process 
exited, code=exited, status=1/FAILURE
Dez 29 00:30:47 whitestar systemd[2626]: xscreensaver.service: Failed with 
result 'exit-code'.

Best regards,
Eduard.

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

Kernel: Linux 5.10.1+ (SMP w/12 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.60
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-6
ii  libcrypt11:4.4.17-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk2.0-0  2.24.32-5
ii  libpam0g 1.4.0-1
ii  libpango-1.0-0   1.46.2-3
ii  libsystemd0  247.2-3
ii  libx11-6 2:1.6.12-1
ii  libxext6 2:1.3.3-1.1
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.45+dfsg1-1

Versions of packages xscreensaver recommends:
pn  libjpeg-turbo-progs   
ii  perl  5.32.0-6
ii  wamerican [wordlist]  2019.10.06-1
ii  wngerman [wordlist]   20161207-8
ii  xfonts-100dpi 1:1.0.4+nmu1

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]   87.0.4280.88-0.3
ii  elinks [www-browser] 0.13.2-1+b1
ii  falkon [www-browser] 3.1.0+dfsg1-9
ii  firefox [www-browser]84.0-3
ii  fortune-mod [fortune]1:1.99.1-7.1
ii  gdm3 3.38.2.1-1
ii  lynx [www-browser]   2.9.0dev.6-1
pn  qcam | streamer  
ii  w3m [www-browser]0.5.3-38+b1
pn  xdaliclock   
pn  xfishtank
pn  xscreensaver-data-extra  
pn  xscreensaver-gl  
pn  xscreensaver-gl-extra

-- no debconf information

--
 hm... kann man eigentlich auch von vorne poppen oder nur von
hinten?

--
 Wo kann man eigentlich Verbesserungen für die Fortunes anbringen?
 cpt_nemo: Geschichtsfälscher!

Bug#978555: libpam-modules: breaks cron: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file

[Vincent Lefevre]

Control: severity -1 normal

After a reboot too, the problem no longer occurs.

Perhaps there should be a warning saying that some services may need
to be restarted.

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

Bug#978588: firefox: should depend on either libgdk-pixbuf package

[David Tulloh]

Package: firefox
Version: 84.0-3
Severity: important

The libgdk-pixbuf packages are migrating from
libgdk-pixbuf2.0-0 to libgdk-pixbuf-2.0.0

The most recent firefox package has matched this name transition.

However many other packages have not yet made the transition, causing
clashes which require their removal. Popular packages include
mutter and gimp. This significantly impacts the overall usability of the
system.

The dependency should be: libgdk-pixbuf-2.0-0 | libgdk-pixbuf2.0-0

This is the practice recommended by libgdk-pixbuf

Firefox only requires 2.22.0 which either package can meet.

Bug#978562: opendht: FTBFS on riscv64, linked with -lpthread instead of -pthread

[Amin Bandali]

Hello Alexandre, Aurelien,

Thanks for the patch.  I don't have access to any riscv64 machines to
test this.  However if you confirm that it fixes the build on riscv64
and introduces no regressions on any arches then I'll ask for it to be
applied upstream.

Thanks,

-- 
Amin Bandali
Free Software Consultant
Savoir-faire Linux
jami:bandali

Bug#606885: xpdf: no longer asks for password in dialog window

[Adam Sampson]

> Nowadays, when the user attempts to view a password-protected PDF
> file, no dialog window is shown

In the original Xpdf, StandardSecurityHandler::checkEncryption calls
back into PDFCore::getPassword if the password's wrong. This code has
been removed from Poppler, so xpdf's implementation of getPassword
wasn't being called.

I've fixed it in xpopple with the following patch, which makes it prompt
for the password up to three times if opening a file fails with
errEncrypted:

--- xpdf/PDFCore.cc
+++ xpdf/PDFCore.cc
@@ -139,11 +139,26 @@ PDFCore::~PDFCore() {
 int PDFCore::loadFile(QCONST GooString *fileName, QCONST GooString 
*ownerPassword,
  QCONST GooString *userPassword) {
   int err;
+  std::unique_ptr promptPassword;
+
+  for (int i = 0; i < 3; ++i) {
+setBusyCursor(true);
+err = loadFile2(new PDFDoc(fileName->copy(), ownerPassword, userPassword,
+  this));
+setBusyCursor(false);
+
+if (err != errEncrypted) {
+  break;
+}
+
+// Password not supplied or not correct -- prompt for it
+promptPassword.reset(getPassword());
+if (!promptPassword) {
+  break;
+}
+ownerPassword = userPassword = promptPassword.get();
+  }
 
-  setBusyCursor(true);
-  err = loadFile2(new PDFDoc(fileName->copy(), ownerPassword, userPassword,
-this));
-  setBusyCursor(false);
   return err;
 }

(You may also need to add #include  to get the definition of
unique_ptr if it's not already in your version.)
 
Thanks,

-- 
Adam Sampson  

Bug#978562: opendht: FTBFS on riscv64, linked with -lpthread instead of -pthread

[Alexandre Viau]

Hello Amin,

Would you consider merging this directly into opendht?

Cheers,

--
Alexandre Viau
alexan...@alexandreviau.net

On Mon, 28 Dec 2020 at 11:45, Aurelien Jarno  wrote:
>
> Source: opendht
> Version: 2.1.9.5-1
> Severity: normal
> Tags: ftbfs patch upstream
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
>
> Hi,
>
> opendht fails to build on riscv64 with the following failure:
> | /usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wno-return-type -Wall -Wextra -Wnon-virtual-dtor 
> -pedantic-errors -fvisibility=hidden -DMSGPACK_DISABLE_LEGACY_NIL 
> -DMSGPACK_DISABLE_LEGACY_CONVERT -Wl,-z,relro -Wl,-z,now -rdynamic 
> CMakeFiles/durl.dir/durl.cpp.o -o durl  -lreadline -lncurses ../libopendht.a 
> -largon2 -lrt -ldl -lpthread -lgnutls -lnettle -ljsoncpp -Wl,-Bstatic -lfmt 
> -Wl,-Bdynamic -lhttp_parser -lssl -lcrypto -ldl -lpthread -lgnutls -lnettle 
> -ljsoncpp -Wl,-Bstatic -lfmt -Wl,-Bdynamic -lhttp_parser -lssl -lcrypto
> | /usr/bin/ld: ../libopendht.a(http.cpp.o): in function `.L0 ':
> | /usr/include/asio/detail/completion_handler.hpp:72: undefined reference to 
> `__atomic_exchange_1'
> | /usr/bin/ld: ../libopendht.a(network_utils.cpp.o): in function 
> `dht::net::UdpSocket::stop()':
> | ./obj-riscv64-linux-gnu/./src/network_utils.cpp:350: undefined reference to 
> `__atomic_exchange_1'
> | /usr/bin/ld: ../libopendht.a(dht_proxy_client.cpp.o): in function 
> `__gnu_cxx::__exchange_and_add_single(int*, int)':
> | /usr/include/c++/10/ext/atomicity.h:69: undefined reference to 
> `__atomic_exchange_1'
> | collect2: error: ld returned 1 exit status
>
> The full build log is available there:
> https://buildd.debian.org/status/fetch.php?pkg=opendht=riscv64=2.1.9.5-1=1607520181=0
>
> The problem is that the linking is not done correctly, it uses -lpthread
> meaning linking with the pthread library, instead of -pthread which
> means enable thread support, and which brings libatomic.so on riscv64.
> This can be fixed by using the THREADS_PREFER_PTHREAD_FLAG option, which
> is "highly recommended" according to the documentation, but
> unfortunately not the default.
>
> This is what the attached patch does, could you please include it in the
> next upload?
>
> Thanks,
> Aurelien

Bug#978586: python3-pyqt5: There needs to be a py.typed file for pyi stubs to work

[Salvo Tomaselli]

Package: python3-pyqt5
Version: 5.15.2+dfsg-1+b1
Severity: normal
Tags: upstream

Dear Maintainer,

as it is, the pyi stubs shipped by the package are useless because a typed.py
file needs to be present for mypy to take them into consideration.

This is already done by upstream in several other python packages.

So, this is an upstream bug, but since the fix is simply:

touch /usr/lib/python3/dist-packages/PyQt5/py.typed

it could be easy to make a temporary debian specific fix.


Best


-- 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-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.31-6
ii  libgcc-s1 10.2.1-1
ii  libpython3.9  3.9.1-1
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-2
ii  libqt5dbus5   5.15.2+dfsg-2
ii  libqt5designer5   5.15.2-3
ii  libqt5gui55.15.2+dfsg-2
ii  libqt5help5   5.15.2-3
ii  libqt5network55.15.2+dfsg-2
ii  libqt5printsupport5   5.15.2+dfsg-2
ii  libqt5test5   5.15.2+dfsg-2
ii  libqt5widgets55.15.2+dfsg-2
ii  libqt5xml55.15.2+dfsg-2
ii  libstdc++610.2.1-1
ii  python3   3.9.0-4
ii  python3-pyqt5.sip 12.8.1-1+b2

python3-pyqt5 recommends no packages.

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

[Justin Erenkrantz]

On Mon, Dec 28, 2020 at 5:00 PM Justin Erenkrantz 
wrote:

> It's not clear to me if OpenSSL authors intended to make this breaking
> change.  On the serf side, we would need to think through what it would
> mean to have our app callback return false upon failure in order to
> short-circuit the check.
>
> I probably won't get a chance to open an upstream OpenSSL issue today (or
> even tomorrow)...
>

I found the original issue where they changed the behavior and added a
comment there:

https://github.com/openssl/openssl/issues/11297

Cheers.  -- justin

Bug#974011: xmille: Incorrect license/copyright for xmille

[Keith Packard]

Adrian Bunk  writes:

> I am just a normal user enjoying the game, and looking at the number of 
> uploads in the past decade two maintainers might be sufficient to handle
> the load.  ;-)

I've uploaded 'kgames' to the new queue :-)

Thanks for playing.

-- 
-keith


signature.asc
Description: PGP signature

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

[Justin Erenkrantz]

As an update, I've been able to triage this a bit further.

It's definitely that last noted change (erroring out on expired self-signed
root) that broke it.  OpenSSL 1.1.1{g,h} are fine, but {i,-stable} are
not.  Reverting just x509_vfy.c to what is in 1.1.1h causes the test to
pass.

In this test case, Serf receives 2 verify callbacks in test_ssl_handshake.
The first failing test case is to not have a known CA - so, we are
intentionally trying to trigger a verify failure.  One of the app
callback received has the expected failure, the other doesn't.  Serf
basically flags the second (success) as an unexpected pass.

2020-12-28T16:51:34.045142-05 test/test_ssl.c: Cert failure received: 4 ;
expected failure mask: 4

2020-12-28T16:51:34.045159-05 test/test_ssl.c: Cert failure received: 0 ;
expected failure mask: 4

The upstream issues/commits appear to be:

https://github.com/openssl/openssl/issues/13427
https://github.com/openssl/openssl/commit/3bed88a3970605a2ff817065f93b08e965d89e5f#diff-2a76d0a7ddc5ae2646a6c183270a7b4d5302d8491acb0af0dfbd70643efdf431

The key difference is almost certainly this change:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1h/crypto/x509/x509_vfy.c#L1754

---
return verify_cb_cert(ctx, xi, 0,

X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE);
---

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/x509/x509_vfy.c#L1755

---
if (!verify_cb_cert(ctx, xi, 0,
X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE))
return 0;

xs = xi;
goto check_cert_time;
---

Up to 1.1.1h, OpenSSL would stop processing the certificate after sending
along the leaf error to the app callback.  In -stable (1.1.1i+ and master),
if the app's callback doesn't return a failure, it will then proceed to the
date check portion (check_cert_time) - which then receives a successful
verification callback.

It's not clear to me if OpenSSL authors intended to make this breaking
change.  On the serf side, we would need to think through what it would
mean to have our app callback return false upon failure in order to
short-circuit the check.

I probably won't get a chance to open an upstream OpenSSL issue today (or
even tomorrow)...

Cheers.  -- justin

Index: test/test_ssl.c

===

--- test/test_ssl.c (revision 1884847)

+++ test/test_ssl.c (working copy)

@@ -465,6 +465,7 @@



 tb->result_flags |= TEST_RESULT_SERVERCERTCB_CALLED;



+test__log(TEST_VERBOSE, __FILE__, "Cert failure received: %d ;
expected failure mask: %d\n", failures, expected_failures);

 /* We expect an error from the certificate validation function. */

 if (failures & expected_failures)

 return APR_SUCCESS;



On Sun, Dec 27, 2020 at 11:22 AM James McCoy  wrote:

> On Sun, Dec 27, 2020 at 10:46:24AM -0500, Justin Erenkrantz wrote:
> > Thanks.  I expect that this might be due to the last change - erroring
> out on
> > an expired self-signed root cert.  Though I thought we didn’t check in a
> root
> > cert for our test chain...could Debian’s packaging be including a cert
> for
> > testing?
>
> I use create_certs.py from trunk to re-generate the test certificates
> every build, otherwise I was running into time bombs with the certs
> expiring.  Other than that, I don't do anything different than the
> normal test process.
>
> The Debian packaging does have some local patches[0] applied to address
> issues that have been fixed upstream but not yet released.
>
> [0]: https://sources.debian.org/patches/serf/1.3.9-8/
>
> > I will try to take a look this week with Debian sid...I assume it has
> 1.1.1i
> > already?  — justin
>
> Yes, it does.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
>

Bug#978585: libcryptsetup-dev: wrong libdir variable in libcryptsetup.pc

[Luca Boccassi]

Package: libcryptsetup-dev
Version: 2:2.3.4-1
Severity: normal
Tags: patch

Dear Maintainer,

When building cryptsetup, libdir is set to /lib/ but then the
libcryptsetup* packages are manually changed to install in
/usr/lib/ via dh-exec.
The problem is that the ${libdir} variable in the pkg-config file is
not adjusted accordingly, so the wrong -L flags are exposed.
Given it's a standard path this is not usually an issue when building
reverse dependencies, but pkg-config can be used in more occasions
than that. For example, the systemd integration test suite uses it to
check where libraries are installed in a distro-agnostic way.

A merge request with a quick fix has been opened on Salsa:

https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/20

Kind regards,
Luca Boccassi

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

[Rick Thomas]

As I said, simply adding --no-guess-python to ORPHANOPTS does take care of the 
immediate problem of wanting to delete deluge, but in exchange, it opens up a 
potential can of worms when there is a python package that is indeed an orphan, 
which would then not be deleted by upgrade-system.

So, for the time being, I will "err on the side of caution" and add 
--no-guess-python to ORPHANOPTS.  If upgrade-system is as a result less zealous 
about deleting orphan packages, so be it.  I can live with that.

If someone wants to track down the underlying cause of deborphan's dislike for 
python-cffi-backend, I'll be happy to help in any way I can.

Rick

On Sun, Dec 27, 2020, at 1:02 PM, Martin-Éric Racine wrote:
> Right, so in that case, there is no bug in upgrade-system.
> 
> The backend 'deborphan --guess-all' simply makes broad assumptions
> about what is superflous libraries and, for some reason, it considers
> python-cffi-backend as superflous as explained in bug #918755.
> 
> In your case, the solution indeed is to add --no-guess-python to ORPHANOPTS.
> 
> Martin-Éric

Bug#931068: zenity: Window icon is not displayed under Wayland

[Simon McVittie]

On Thu, 19 Nov 2020 at 21:07:00 +0100, Yvan Masson wrote:
> On Tue, 25 Jun 2019 17:00:15 +0100 Simon McVittie  wrote:
> > - GNOME Shell 3.30 in Xorg mode: chosen icon appears in top bar and dash
> >   (sidebar in overview)
> > - GNOME Shell 3.30 in Wayland mode: a "broken image" icon appears instead
> 
> The results you describe are exactly what I experienced. The issue is still
> here with zenity 3.32.0-6 and Gnome 3.38.1-2.
> 
> As you suggested, I checked with another desktop environment, KDE Wayland
> (using KDE Neon: plasma-desktop 4:5.20.3-0xneon+20.04+focal+build16 and
> zenity 3.32.0-5): the issue is exactly the same. It works on X11 but not on
> Wayland.
> 
> Do you want me to report this upstream?

If you want to pursue this then upstream is the right place, but I don't
think this is necessarily going to be fixable. An arbitrary --icon-name
option made sense in an X11 world, but doesn't really make sense in the
more app-oriented Wayland world view.

In Wayland, as far as I'm aware, the mechanism is that trusted/non-sandboxed
applications can tell the compositor (e.g. GNOME Shell or Plasma Desktop)
what they claim their freedesktop.org app ID is, and if they do, the
compositor will show whatever icon matches that app ID. Zenity can
either say that it's something like "org.gnome.Zenity", or leave it
unspecified and hope the compositor has a good heuristic, but
`zenity --icon-name=edit-copy` doesn't really get to say "I'm whatever
app has edit-copy as its icon".

(Sandboxed applications, like Flatpak apps, don't even get to specify
their own app ID - the compositor can get it directly from Flatpak,
and should ignore whatever the app tries to say, at least under GNOME
Shell - but that doesn't apply in this case.)

Having an option for "tell the compositor your app ID is..." might be a
more achievable upstream feature request than making --icon-name work
under Wayland?

smcv

Bug#951588: kontact: akonadi is not operational

[Sandro Knauß]

control: tags -1 + moreinfo
control: severity -1 important

Hey,

please retry with the current version in testing/unstable and give us more 
information what you have tried to do before kontact returns with a segfault. 
Maybe this issue is more for the Akonadi package?

At least from what I can tell is that is works for a lot of people, so I lower 
the severity.

hefee


On Dienstag, 18. Februar 2020 14:34:53 CET Alberto Fuentes wrote:
> Package: kontact
> Version: 4:19.08.3-1
> Severity: grave
> Justification: renders package unusable
> 
> Application: Akonadi Control (akonadi_control), signal: Aborted
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [Current thread is 1 (Thread 0x7ff192558800 (LWP 1433258))]
> 
> Thread 5 (Thread 0x7ff189e1f700 (LWP 1433262)):
> #0  0x7ff195d5abef in __GI___poll (fds=0x7ff1800021e0, nfds=1,
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7ff19510710e in ?? () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2  0x7ff19510722f in
> g_main_context_iteration () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x7ff1962e381b in
> QEventDispatcherGlib::processEvents(QFlags)
> () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #4  0x7ff19628c71b in
> QEventLoop::exec(QFlags) () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #5  0x7ff1960cd731 in QThread::exec() () from /usr/lib/x86_64-linux-
> gnu/libQt5Core.so.5
> #6  0x7ff196bf14e6 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #7  0x7ff1960ce8b2 in ?? ()
> from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8  0x7ff195c52fb7 in
> start_thread (arg=) at
> pthread_create.c:486
> #9  0x7ff195d651af in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> Thread 4 (Thread 0x7ff18a703700 (LWP 1433261)):
> #0  0x7ff195d5abef in __GI___poll (fds=0x55fdcd713ff0, nfds=2,
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7ff19510710e in ?? () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2  0x7ff195107473 in
> g_main_loop_run () from /usr/lib/x86_64-linux- gnu/libglib-2.0.so.0
> #3  0x7ff18b9c89e6 in ?? () from
> /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4  0x7ff19512fd7d in ?? ()
> from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5  0x7ff195c52fb7 in
> start_thread (arg=) at
> pthread_create.c:486
> #6  0x7ff195d651af in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> Thread 3 (Thread 0x7ff18af04700 (LWP 1433260)):
> #0  0x7ff195d5abef in __GI___poll (fds=0x55fdcd6ffb90, nfds=1,
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7ff19510710e in ?? () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2  0x7ff19510722f in
> g_main_context_iteration () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x7ff195107281 in ?? () from
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4  0x7ff19512fd7d in ?? ()
> from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5  0x7ff195c52fb7 in
> start_thread (arg=) at
> pthread_create.c:486
> #6  0x7ff195d651af in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> Thread 2 (Thread 0x7ff1912c6700 (LWP 1433259)):
> #0  0x7ff195d5abef in __GI___poll (fds=0x7ff1912c5ca8, nfds=1,
> timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7ff194ff1cf7 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
> #2  0x7ff194ff391a in xcb_wait_for_event () from /usr/lib/x86_64-linux-
> gnu/libxcb.so.1
> #3  0x7ff191eabca0 in ?? () from /usr/lib/x86_64-linux-
> gnu/libQt5XcbQpa.so.5
> #4  0x7ff1960ce8b2 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5  0x7ff195c52fb7 in
> start_thread (arg=) at
> pthread_create.c:486
> #6  0x7ff195d651af in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> Thread 1 (Thread 0x7ff192558800 (LWP 1433258)):
> [KCrash Handler]
> #6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #7  0x7ff195c90535 in __GI_abort () at abort.c:79
> #8  0x55fdcbc662e2 in akMessageHandler (type=QtFatalMsg, msg=...,
> context=...) at ./src/shared/akdebug.cpp:205
> #9  akMessageHandler (type=, context=..., msg=...) at
> ./src/shared/akdebug.cpp:194
> #10 0x55fdcbc6834e in (anonymous namespace)::RemoteLogger::dbusLogger
> (type=QtFatalMsg, ctx=..., msg=...) at ./src/shared/akremotelog.cpp:178
> #11 0x7ff1960c64b1 in ?? () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7ff1960c65c9 in ?? ()
> from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x7ff196096a44 in
> QMessageLogger::fatal(char const*, ...) const () from
> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> #14 0x55fdcbc3c4e1 in AgentManager::AgentManager (this=0x7ffd636395f0,
> verbose=, parent=) at
> /usr/include/x86_64-linux- gnu/qt5/QtCore/qlogging.h:91
> #15 0x55fdcbc3e374 in main (argc=, argv=)
> at ./src/akonadicontrol/main.cpp:76
> [Inferior 1 (process 1433258) detached]
> 
> 
> 
> -- System Information:
> 

Bug#978584: anyremote-doc: missing Breaks+Replaces: anyremote (<< 6.7.3-2)

[Andreas Beckmann]

Package: anyremote-doc
Version: 6.7.3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../anyremote-doc_6.7.3-2_all.deb ...
  Unpacking anyremote-doc (6.7.3-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/anyremote-doc_6.7.3-2_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/anyremote/NEWS.gz', which is also in 
package anyremote 6.7.3-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/anyremote-doc_6.7.3-2_all.deb

This is probably caused by a behavioral change of dh_installdocs
that was activated by the recent debhelper-compat bump.


cheers,

Andreas


anyremote=6.7.3-1_anyremote-doc=6.7.3-2.log.gz
Description: application/gzip

Bug#978583: libtrapperkeeper-filesystem-watcher-clojure: files in .jar don't follow the proper hierarchy

[Louis-Philippe Véronneau]

Package: libtrapperkeeper-filesystem-watcher-clojure
Version: 1.2.2-1
Severity: grave
Owner: po...@debian.org

The .jar in this package contains the following .clj files:

clj/
clj/puppetlabs/
clj/puppetlabs/trapperkeeper/
clj/puppetlabs/trapperkeeper/services/
clj/puppetlabs/trapperkeeper/services/protocols/
clj/puppetlabs/trapperkeeper/services/protocols/filesystem_watch_service.clj
clj/puppetlabs/trapperkeeper/services/watcher/
clj/puppetlabs/trapperkeeper/services/watcher/filesystem_watch_core.clj
clj/puppetlabs/trapperkeeper/services/watcher/filesystem_watch_service.clj

They should be following this hierarchy instead:

puppetlabs/trapperkeeper/
puppetlabs/trapperkeeper/services/
puppetlabs/trapperkeeper/services/protocols/
puppetlabs/trapperkeeper/services/protocols/filesystem_watch_service.clj
puppetlabs/trapperkeeper/services/watcher/
puppetlabs/trapperkeeper/services/watcher/filesystem_watch_core.clj
puppetlabs/trapperkeeper/services/watcher/filesystem_watch_service.clj

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

Bug#978582: RFP: replaysorery -- Record a video of the last 30s of your screen to save your best gaming moments

[Alberto Fuentes]

Package: wnpp
Severity: wishlist

* Package name: replaysorery
  Version : 0.4.2
  Upstream Author : Joshua 'Pip' Minter - https://github.com/matanui159
* URL : https://github.com/matanui159/ReplaySorcery
* License : GPL3.0
  Programming Lang: C
  Description : Record a video of the last 30s of your screen to save your
best gaming moments

Emulates nVidia ShadowPlay by constantly recording the screen without using too
many resources. At the press of keycombo, it will save the last 30 seconds

This is useful for saving the best moments of your gaming sessions without
recording everything or maybe being able to record a pesky bug that you cant
trigger or predict

Further info:
There is nothing similar to this in the debian archive and seems a very useful
addition

Bug#954823: hydrogen: Qt5 version available

[Jonas Smedegaard]

Hi Nicholas,

Quoting Nicholas D Steeves (2020-12-28 21:31:56)
> Jonas Smedegaard  writes:
> 
> > Quoting Nicholas D Steeves (2020-07-05 18:31:43)
> >> 
> >> I'm guessing the files that would have gone into the -dev package 
> >> were deleted because long ago there was no need.  Do you know if 
> >> they would now be useful for something like plugins?
> >> 
> >> If you can share why these, and other decisions, were made I'd very 
> >> much appreciate it.  At this time core functionality, MIDI, and 
> >> export of some formats was confirmed to be good (#960539), but I'm 
> >> trying to be careful about disrupting more advanced functionality 
> >> other users may depend on.
> >
> > Please explore any comments in the packaging files, or git commits - 
> > in that order.  I very much doubt that I have any more information 
> > to share than is contained in either of those.  Feel free to ask if 
> > there is some comment or commit message that you do not understand.
> >
> 
> I couldn't find the info I was looking for, but I think I got the 
> package into a good state.  It has been awaiting sponsorship for a 
> whole month, and at this point I feel like it's not going to get into 
> the NEW queue with enough time to meet the bullseye freeze deadline.
> 
> If possible, would you please sponsor Hydrogen at Bug #976113?

Sorry, I don't do sponsoring, only co-maintenance (some are confusingly 
using the term "sponsoring" for both things), and I dislike the 
atmosphere in the Multimedia team so am no longer part of that.

I wish you the best of luck getting your package sponsored - or released 
by a co-maintainer if the package is still in the multimedia team.


 - 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#978581: libjs-vue-router mismatched path-to-regexp

[Oliver Giles]

Package: libjs-vue-router
Version: 3.4.9+ds-1

3.4.9+ds-1 packages an incompatible version of path-to-regexp. This was
reported and fixed in bug #927254, but is now reproducible again in
version 3.4.9+ds-1.

Specifically, the tokensToRegExp function is lacking the attachKeys
wrapper around its return value.

>From upstream 3.4.9:

  function tokensToRegExp (tokens, keys, options) {
[...]
return attachKeys(new RegExp('^' + route, flags(options)), keys)
  }

>From 3.4.9+ds-1

  function tokensToRegexp(tokens, keys, options) {
  [...]
  return new RegExp(route, flags(options));
  }

Bug#978535: RFS: wxmaxima/20.12.0-1 -- GUI for the computer algebra system Maxima

[Adam Borowski]

On Mon, Dec 28, 2020 at 07:06:36PM +0100, Gunter Königsmann wrote:
> Re-uploading a corrected version of the package.

Still fails due to missing B-Dep on xauth.

After adding that, it builds correctly and I see no problems save for:
E: wxmaxima: privacy-breach-uses-embedded-file 
usr/share/doc/wxmaxima/wxmaxima.ca.html You may use the node-html5shiv package 
(virtual package). 
(//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js)
E: wxmaxima: privacy-breach-uses-embedded-file 
usr/share/doc/wxmaxima/wxmaxima.cs.html You may use the node-html5shiv package 
(virtual package). 
(//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js)
E: wxmaxima: privacy-breach-uses-embedded-file 
usr/share/doc/wxmaxima/wxmaxima.da.html You may use the node-html5shiv package 
(virtual package). 
(//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js)
E: wxmaxima: privacy-breach-uses-embedded-file ... use --no-tag-display-limit 
to see all (or pipe to a file/program)

This is easy to fix: just depend on node-html5shiv and patch or sed the
reference to use the local copy.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#847271: mutter: Resizing window moves the whole window

[Richard B. Kreckel]

This seems to be fixed in mutter 3.38.2-1.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978556: ITP: netr -- Display network interface throughput in terminal

[Geert Stappers]

On Mon, Dec 28, 2020 at 03:21:34PM +, Edward Neville wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Edward Neville 
> 
> * Package name: netr
>   Version : 0.1.3
>   Upstream Author : Ed Neville 
> * URL : http://www.usenix.org.uk/content/net.html
> * License : GPL
>   Programming Lang: Rust
>   Description : Display network interface throughput in terminal
> 
> Display network interface throughput by second and by minute along with
> a graph. This is quick and easy to use via a mobile handset or similar
> device where typing is cumbersome.
> 
> A sponsor is required, but check with stappers as he may be looking at
> this.

Unlikely that I look this week (so also this year) into it.

 
> I plan to maintain this within the rust team.

Good work in progress at 
https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master/src/netr/debian
 

Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#954823: hydrogen: Qt5 version available

[Nicholas D Steeves]

Control: block -1 by 976113

Hi Jonas,

Jonas Smedegaard  writes:

> Quoting Nicholas D Steeves (2020-07-05 18:31:43)
>> 
>> I'm guessing the files that would have gone into the -dev package were
>> deleted because long ago there was no need.  Do you know if they would
>> now be useful for something like plugins?
>> 
>> If you can share why these, and other decisions, were made I'd very much
>> appreciate it.  At this time core functionality, MIDI, and export of
>> some formats was confirmed to be good (#960539), but I'm trying to be
>> careful about disrupting more advanced functionality other users may
>> depend on.
>
> Please explore any comments in the packaging files, or git commits - in 
> that order.  I very much doubt that I have any more information to share 
> than is contained in either of those.  Feel free to ask if there is some 
> comment or commit message that you do not understand.
>

I couldn't find the info I was looking for, but I think I got the
package into a good state.  It has been awaiting sponsorship for a whole
month, and at this point I feel like it's not going to get into the NEW
queue with enough time to meet the bullseye freeze deadline.

If possible, would you please sponsor Hydrogen at Bug #976113?

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#955567: kalgebra: Output is always blank

[Paul Gevers]

Control: tags -1 buster

Hi Charles,

On 28-12-2020 20:51, Charles Samuels wrote:
> On Monday, December 28, 2020 11:30:18 AM PST Paul Gevers wrote:
>> I tried to reproduce this in current testing and for me it works. Is
>> this issue still a problem for you?
> 
> Yes it is still an issue (stable).

I can then only assume it got fixed in the mean time (in
unstable/testing). Tagging this bug as appropriate, but leaving it open
for now just in case somebody wants to jump in.

> Curiously, when I right click on the output area, the popup menu with "Clear" 
> is positioned in relation to the desktop and not the place I clicked at (so 
> if 
> you click at coordinate 100x100 in the area, the popup appears at 100x100 
> global coordinates).
> 
> I use KDE's desktop scaling (1.5x). I tried disabling that and then 
> restarting 
> kalgebra (without logging out) with no change.
> 
> I see nothing interesting in .xsession-errors or kalgebra's output

I can't offer much help, as I'm not familiar with the KDE stack. I was
mostly interested from the release process point of view.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sean Whitton]

Hello,

On Mon 28 Dec 2020 at 12:24AM +01, gregor herrmann wrote:

> On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
>
>> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
>> > My reasoning is that init scripts are the end goal, and that elogind is
>> > just a symptom of that end goal, and that therefore talking about
>> > elogind in isolation serves no purpose.
>> The GR specifically mentions elogind and not init scripts.
>
> "Technologies /such as/ elogind …" (emph. mine) shows to me that this
> is meant as an example, as a "demonstration", and not as an
> exhaustive list [0]. So neither is elogind "special" nor is it the
> only relevant piece of software to consider supporting. [1]

Yes, fair enough, thanks.

I think what is more relevant is that hard Depends: are harder to work
around than being asked to move files between coinstallable packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#957732: qtermwidget: ftbfs with GCC-10

[Paul Gevers]

Version: 0.16.1-1

Hi,

On Fri, 17 Apr 2020 11:09:35 + Matthias Klose  wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.

A successful upload happened since.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#955567: kalgebra: Output is always blank

[Charles Samuels]

On Monday, December 28, 2020 11:30:18 AM PST Paul Gevers wrote:
>  wrote:
> > KAlgebra shows nothing in its output screen. This only applies
> > to the algebraic displays, the graphs and dictionary tabs seem
> > to work fine.
> > 
> > Reproduce: Enter any equation into the input text box and press enter.
> > 
> > Expected: The result of the equation and the equation inputted should be
> > visible.
> > 
> > Actual: Nothing appears. Even the border of the frame appears missing.
> > 
> > Also: Right clicking on the empty area causes a context menu to appear
> > in the wrong place. I'm not sure if that's related.
> 
> I tried to reproduce this in current testing and for me it works. Is
> this issue still a problem for you?

Yes it is still an issue (stable).

Curiously, when I right click on the output area, the popup menu with "Clear" 
is positioned in relation to the desktop and not the place I clicked at (so if 
you click at coordinate 100x100 in the area, the popup appears at 100x100 
global coordinates).

I use KDE's desktop scaling (1.5x). I tried disabling that and then restarting 
kalgebra (without logging out) with no change.

I see nothing interesting in .xsession-errors or kalgebra's output

Charles

Bug#978098: webkit2gtk: Re-enable build for hurd-i386?

[Samuel Thibault]

Hello,

Laurent Bigonville, le ven. 25 déc. 2020 23:15:54 +0100, a ecrit:
> Shouldn't the patch be applied in "official" package as well (and maybe
> upstream)?

Debian maintainers usually prefer to see patches applied upstream before
adding them to their packaging. They are already submitted upstream, see
URLs in the patch file. Some of them are already applied, others need
some rework, help welcome!

And they usually rather see a complete working set before changing debian/

Samuel

Bug#976238: release-notes: Please mention that NSS NIS/NIS+ support has been moved to separate packages

[Joost van Baal-Ilić]

Hi,

Thomas: Thanks for adding this information, it does sound serious enough.  A
draft text or patch for
https://salsa.debian.org/ddp-team/release-notes/-/blob/master/en/issues.dbk
under "Package specific issues" would be needed.  (I myself lack the time now.)

HTH,

Joost

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> We do drop features all the time between stable releases,
Russ> though, and generally that too is at the maintainer's
Russ> discretion.  The package maintainer's normal obligation in
Russ> Debian isn't to keep everything working that previously was
Russ> working, but to make it obvious when something is incompatible
Russ> (ideally before it breaks on a given system in a way that's
Russ> hard to back out of).

Agreed.

Russ> Often this is done by dropping or
Russ> renaming packages so that the old package just has no upgrade
Russ> path, but we handle it in other ways as well (release notes,
Russ> NEWS.Debian, etc., depending on the severity of the
Russ> incompatibility).

Agreed.
I think a reasonable way for the TC to handle the init script part of
this bug might be to politely suggest to the maintainer that they
include a note in the release notes.
(Or for a member of the TC to just propose such a note to the release
notes maintainers).
Russ> I guess the summary of my position on init scripts
Russ> specifically is that I generally agree with Wouter's framing
Russ> of two approaches to Debian who want very different things,
Russ> and I thought (at least for init scripts) we put a range of
Russ> options on the table from "you must support both approaches"
Russ> to "we're only going to support one approach," and the option
Russ> that people chose is "one option is strongly preferred but
Russ> individual maintainers can support other approaches if they
Russ> want to and we don't want to make exploration of other
Russ> approaches impossible."  The implication was that some
Russ> individual maintainers *won't* want to support other
Russ> approaches in their individual packages, and that's a decision
Russ> they get to make, and therefore folks who want to keep
Russ> sysvinit working should be exploring options that don't
Russ> require the maintainer incorporate that support (such as a
Russ> separate package of init scripts or a conversion utility that
Russ> generates init scripts from unit files).

We are in agreement here.  I guess that's not surprising given how many
times we have discussed this:-)

Bug#978574: clevis: tpm2 pin incompatible with tpm2-tools version 5

[Christoph Biedl]

Control: tags 978574 pending

Marek Rusinowski wrote...

> It looks like currently the clevis-tpm2 is incompatible with
> tpm2-tools package in unstable (5.0-1). After trying to encrypt
> something with tpm2 I get:
> 
>   The tpm2 pin requires tpm2-tools version 3 or 4

Yeah, already on radar. I'll upload version 15 with the mentioned
upstream commit cherry-pick in a moment. Also, I'd be glad to learn
about success (failure as well) - as I currently have no hardware with
TPM support around and swtpm creates a lot of strange error messages I
cannot follow, I'm currently somewhat blind.

Christoph


signature.asc
Description: PGP signature

Bug#955567: kalgebra: Output is always blank

[Paul Gevers]

Control: notfound -1 4:20.08.0-1

Hi Charles,

On Thu, 02 Apr 2020 16:57:16 + (UTC) Charles Samuels
 wrote:
> KAlgebra shows nothing in its output screen. This only applies
> to the algebraic displays, the graphs and dictionary tabs seem
> to work fine.
> 
> Reproduce: Enter any equation into the input text box and press enter.
> 
> Expected: The result of the equation and the equation inputted should be 
> visible.
> 
> Actual: Nothing appears. Even the border of the frame appears missing.
> 
> Also: Right clicking on the empty area causes a context menu to appear
> in the wrong place. I'm not sure if that's related.

I tried to reproduce this in current testing and for me it works. Is
this issue still a problem for you?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#812920: netcf: diff for NMU version 1:0.2.8-1.1

[Boyuan Yang]

Control: tags -1 +patch  +pending

Dear maintainer,

I've prepared an NMU for netcf (versioned as 1:0.2.8-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru netcf-0.2.8/debian/changelog netcf-0.2.8/debian/changelog
--- netcf-0.2.8/debian/changelog2015-09-23 16:46:21.0
-0400
+++ netcf-0.2.8/debian/changelog2020-12-28 14:11:10.0
-0500
@@ -1,3 +1,17 @@
+netcf (1:0.2.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Set package priority back to optional.
+  * debian/control: Use current homepage. (Closes: #859848)
+  * Multi-Archify packages. (Closes: #812920)
+  * debian/rules: Do not install .pc file into /usr/share/pkgconfig/
since
+it violates multi-arch requirement. Using /usr/lib/*/pkgconfig/ is
+already good enough.
+  * debian/watch: Monitor pagure.io upstream.
+  * debian/copyright: Fix lintian warnings.
+
+ -- Boyuan Yang   Mon, 28 Dec 2020 14:11:10 -0500
+
 netcf (1:0.2.8-1) unstable; urgency=medium
 
   * Import new upstream 2.8.0
diff -Nru netcf-0.2.8/debian/control netcf-0.2.8/debian/control
--- netcf-0.2.8/debian/control  2015-09-22 17:02:03.0 -0400
+++ netcf-0.2.8/debian/control  2020-12-28 14:03:32.0 -0500
@@ -1,10 +1,10 @@
 Source: netcf
-Priority: extra
+Priority: optional
 Maintainer: Serge Hallyn 
 Build-Depends: cdbs, debhelper (>= 8.0.0), dh-autoreconf, ifupdown,
libaugeas-dev, libnl-3-dev, libnl-route-3-dev, libreadline-dev,
libtool, libxml2-dev, libxslt-dev, pkg-config
-Standards-Version: 3.9.6
+Standards-Version: 4.5.1
 Section: libs
-Homepage: https://fedorahosted.org/netcf/
+Homepage: https://pagure.io/netcf
 
 Package: netcf
 Architecture: linux-any
@@ -21,7 +21,8 @@
 Package: libnetcf-dev
 Section: libdevel
 Architecture: linux-any
-Depends: libnetcf1 (= ${binary:Version}), ${misc:Depends},
${shlibs:Depends}
+Multi-Arch: same
+Depends: libnetcf1 (= ${binary:Version}), ${misc:Depends}
 Description: development library and headers for netcf
  Netcf is a library used to modify the network configuration of a
  system. Network configurations are expressed in a platform-
independent
@@ -33,6 +34,7 @@
 
 Package: libnetcf1
 Architecture: linux-any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}, libaugeas0, augeas-
lenses, libxml2, libxslt1.1
 Conflicts: libvirt0 (<= 0.10.1-2~)
 Description: cross-platform network configuration library (runtime
library)
@@ -53,4 +55,3 @@
  'native' network configuration files.
  .
  This package contains the debugging symbols for libnetcf1.
-
diff -Nru netcf-0.2.8/debian/copyright netcf-0.2.8/debian/copyright
--- netcf-0.2.8/debian/copyright2015-09-16 16:41:53.0
-0400
+++ netcf-0.2.8/debian/copyright2020-12-28 14:09:19.0
-0500
@@ -1,29 +1,7 @@
-Format: http://dep.debian.net/deps/dep5
+Format:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: netcf
-Source: http://git.fedorahosted.org/git/?p=netcf.git
+Source: https://pagure.io/netcf/releases
 
-Files: tests/cutest.*
-Copyright: 2003 Asim Jalis
-License: permissive
- .
- This software is provided 'as-is', without any express or implied
- warranty. In no event will the authors be held liable for any damages
- arising from the use of this software.
- .
- Permission is granted to anyone to use this software for any purpose,
- including commercial applications, and to alter it and redistribute
it
- freely, subject to the following restrictions:
- .
- 1. The origin of this software must not be misrepresented; you must
not
- claim that you wrote the original software. If you use this software
in
- a product, an acknowledgment in the product documentation would be
- appreciated but is not required.
- .
- 2. Altered source versions must be plainly marked as such, and must
not be
- misrepresented as being the original software.
- .
- 3. This notice may not be removed or altered from any source
distribution.
- 
 Files: *
 Copyright: 2009-2011 David Lutterkort 
2009-2011 Laine Stump 
@@ -34,8 +12,7 @@
2010,2011 Eric Blake 
2011 Osier Yang 
2011 Aleix Conchillo 
-License: LGPL
- .
+License: LGPL-2.1+
  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
@@ -64,8 +41,28 @@
  GNU General Public License for more details.
  .
  You should have received a copy of the GNU General Public License
- along with this program. If not, see 
+ along with this program. If not, see 
  .
  On Debian systems, the complete text of the GNU General
  Public License version 2 can be found in "/usr/share/common-
licenses/GPL-2".
 
+Files: tests/cutest.*
+Copyright: 2003 Asim Jalis
+License: permissive
+ This software is provided 'as-is', without any express or implied
+ warranty. In no 

Bug#978579: rocksndiamonds: [INTL:ru] Russian debconf templates translation update

[Yuri Kozlov]

Package: rocksndiamonds
Severity: wishlist
Tags: l10n patch

Russian debconf templates translation update is attached.

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# translation of ru.po to Russian
# Dmitry E. Oboukhov, 2007.
# Yuri Kozlov , 2009, 2020.
msgid ""
msgstr ""
"Project-Id-Version: rocksndiamonds 4.2.2.0+dfsg-1\n"
"Report-Msgid-Bugs-To: rocksndiamo...@packages.debian.org\n"
"POT-Creation-Date: 2020-12-25 21:14+0100\n"
"PO-Revision-Date: 2020-12-26 06:52+0300\n"
"Last-Translator: Yuri Kozlov \n"
"Language-Team: Russian \n"
"Language: ru\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 20.08.2\n"
"Plural-Forms:  nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n"
"%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Download non-free game data?"
msgstr "Скачать несвободные ресурсы игры из интернета?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"The data files required by rocksndiamonds do not have licenses that would "
"allow them to be distributed as a package. However, they can be "
"automatically downloaded from the Internet and installed locally."
msgstr ""
"Файлы данных, требуемые для rocksndiamonds, не имеют лицензии, которая бы "
"позволяла распространять их в пакете. Однако, их можно скачать и установить"
" из "
"интернета автоматически."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Some of these require downloading large files: BD2K3 (4.5 MiB), BD Dream "
"(11 MiB), Contributions 1995 - 2006 (6 MiB), Emerald Mine Club (44 MiB), "
"Legend of Zelda (2.1 MiB), Legend of Zelda II (12 MiB), rnd_jue (18 MiB), "
"Snake Bite (6.3 MiB), Supaplex (7.2 MiB)."
msgstr ""
"Некоторые из них довольно большие: BD2K3 (4.5 MiB), BD Dream "
"(11 MiB), Contributions 1995 - 2006 (6 MiB), Emerald Mine Club (44 MiB), "
"Legend of Zelda (2.1 MiB), Legend of Zelda II (12 MiB), rnd_jue (18 MiB), "
"Snake Bite (6.3 MiB), Supaplex (7.2 MiB)."

#. Type: multiselect
#. Description
#: ../templates:3001
msgid "Games to download data for:"
msgstr "Выберите, какие игры необходимо скачать:"

#. Type: error
#. Description
#: ../templates:4001
msgid "Missing utilities for download or unpacking"
msgstr "Не найдены утилиты для скачивания и распаковки"

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"Downloading and unpacking the game data requires the packages wget, p7zip, "
"and unzip, but not all of these are available."
msgstr ""
"Для скачивания и распаковки данных игры требуются пакеты wget, p7zip и "
"unzip, но не все из них доступны."

#. Type: error
#. Description
#: ../templates:4001
msgid ""
"You should install them and then reconfigure this package by using \"dpkg-"
"reconfigure rocksndiamonds\"."
msgstr ""
"Установите их, а затем повторно запустите перенастройку данного пакета с "
"помощью «dpkg-reconfigure rocksndiamonds»."

#. Type: error
#. Description
#: ../templates:5001
msgid "Cannot download required resources"
msgstr "Не удалось скачать запрошенные ресурсы"

#. Type: error
#. Description
#: ../templates:5001
msgid ""
"An error occurred while downloading game data. You should check the network "
"connection and settings and retry later on."
msgstr ""
"При скачивании данных игры произошла ошибка. Проверьте подключение к сети и "
"настройки, а затем повторите попытку."

Bug#978578: coinor-symphony: reproducible builds: example Makefile embeds buildpath

[Vagrant Cascadian]

Source: coinor-symphony
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The file /usr/share/doc/coinor-libsymphony-doc/examples/Makefile.gz
contains the embedded build path:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/coinor-symphony.html

  SYMEXDIR·=·/build/1st/coinor-symphony-5.6.16+repack1/src/../Examples
  vs.
  SYMEXDIR·=·/build/2/coinor-symphony-5.6.16+repack1/2nd/src/../Examples


The attached patch fixes this by only shipping the Makefile.in, which is
a template for the user to regenerate the Makefile with values
appropriate to their system.

Combined with the timstamp patch recently submitted, this should be
sufficient to make coinor-symphony reproducible.


Thanks for maintaining coinor-symphony!


live well,
  vagrant
From 408fdc8e9ff62cf6dab3c7e5820c5185396cb916 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 28 Dec 2020 18:59:23 +
Subject: [PATCH 2/2] coinor-libsymphony-doc: Install example Makefile.in
 rather than Makefile.

The example Makefile embeds build paths that are not likely to be
present on the end-user system, thus requiring the end-user to
regenerate the file anyway.
---
 debian/coinor-libsymphony-doc.examples | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/coinor-libsymphony-doc.examples b/debian/coinor-libsymphony-doc.examples
index fcc3e10..b19ce33 100644
--- a/debian/coinor-libsymphony-doc.examples
+++ b/debian/coinor-libsymphony-doc.examples
@@ -1,4 +1,4 @@
 Examples/*.c
-Examples/Makefile
+Examples/Makefile.in
 Examples/README
 Examples/FLOPC++
-- 
2.30.0.rc2



signature.asc
Description: PGP signature

Bug#978113: clang++ fail to compile programs

[Nicholas Guriev]

On Sat, 2020-12-26 at 12:10 +0100, Sylvestre Ledru wrote:
> Could you please try to generate it into a regular file?

Well, if I change argument of `-o` parameter, the error is the same.

   (chrooted)builder@barberry:/$ rm -f /tmp/a.out; touch /tmp/a.out
   (chrooted)builder@barberry:/$ clang++-11 -v /tmp/main.cpp -o /tmp/a.out
   Debian clang version 11.0.0-5+b1
   Target: s390x-ibm-linux-gnu
   Thread model: posix
   InstalledDir: /usr/bin
   Found candidate GCC installation: /usr/bin/../lib/gcc/s390x-linux-gnu/10
   Found candidate GCC installation: /usr/bin/../lib/gcc/s390x-linux-gnu/8
   Found candidate GCC installation: /usr/bin/../lib/gcc/s390x-linux-gnu/9
   Found candidate GCC installation: /usr/lib/gcc/s390x-linux-gnu/10
   Found candidate GCC installation: /usr/lib/gcc/s390x-linux-gnu/8
   Found candidate GCC installation: /usr/lib/gcc/s390x-linux-gnu/9
   Selected GCC installation: /usr/bin/../lib/gcc/s390x-linux-gnu/10
   Candidate multilib: .;@m64
   Selected multilib: .;@m64
"/usr/bin/ld" --hash-style=both --build-id --eh-frame-hdr -m elf64_s390 
-dynamic-linker /lib/ld64.so.1 -o /tmp/a.out 
/usr/bin/../lib/gcc/s390x-linux-gnu/10/../../../s390x-linux-gnu/crt1.o 
/usr/bin/../lib/gcc/s390x-linux-gnu/10/../../../s390x-linux-gnu/crti.o 
/usr/bin/../lib/gcc/s390x-linux-gnu/10/crtbegin.o 
-L/usr/bin/../lib/gcc/s390x-linux-gnu/10 
-L/usr/bin/../lib/gcc/s390x-linux-gnu/10/../../../s390x-linux-gnu 
-L/lib/s390x-linux-gnu -L/usr/lib/s390x-linux-gnu 
-L/usr/bin/../lib/gcc/s390x-linux-gnu/10/../../.. -L/usr/lib/llvm-11/bin/../lib 
-L/lib -L/usr/lib /tmp/main.cpp -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc 
/usr/bin/../lib/gcc/s390x-linux-gnu/10/crtend.o 
/usr/bin/../lib/gcc/s390x-linux-gnu/10/../../../s390x-linux-gnu/crtn.o
   /usr/bin/ld:/tmp/main.cpp: file format not recognized; treating as linker 
script
   /usr/bin/ld:/tmp/main.cpp:1: syntax error
   clang: error: linker command failed with exit code 1 (use -v to see 
invocation)



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

Bug#978577: coinor-symphony: reproducible builds: Embedded timestamps in PDF files

[Vagrant Cascadian]

Source: coinor-symphony
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in 
/usr/share/doc/coinor-libsymphony-doc/man.pdf.gz:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/coinor-symphony.html

  November·29,·2020
  vs.
  January·2,·2022

The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

While this alone does not fix all reproducibility issues in
coinor-symphony (e.g. build paths), it should be reproducible once it
lands in bullseye, which does not vary build paths in the reproducible
builds test infrastructure.

Thanks for maintaining coinor-symphony!

live well,
  vagrant
From e0f55da79c9c08ce566eb0808e765addde35ef44 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 28 Dec 2020 18:58:22 +
Subject: [PATCH 1/2] debian/rules: Set FORCE_SOURCE_DATE=1 in order for
 texlive to respect SOURCE_DATE_EPOCH for reproducible timestamps.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 6f39c85..fc42b74 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,9 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@ --without autoreconf
 
-- 
2.30.0.rc2



signature.asc
Description: PGP signature

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Pablo Mestre]

El 28/12/20 a las 12:11, Julian Gilbey escribió:
> On Fri, Nov 06, 2020 at 11:43:25PM +0200, Otto Kekäläinen wrote:
>> Thanks!
>>
>> I will update the changelog and upload current
>> https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/commits/debian/master
>> unless Boyuan or Jochen have something more to add/review about the 
>> packaging.
> Hi all,
>
> I just rebuilt this package with the latest upstream version using a
> Debian testing system and had no problem at all.
>
> Would you like me to commit my changes to
> https://salsa.debian.org/python-team/packages/python-jsonrpc-server?
>
> Best wishes,
>
>Julian
Yes please...

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#978576: puppet: please ship the hiera executable

[Louis-Philippe Véronneau]

Package: puppet
Version: 5.5.22-1
Severity: normal
Control: block 924409 by -1

Dear maintainer,

Would it be possible to ship the 'hiera' executable for the Bullseye
release in this package? It seems to be what upstream does with the file
they ship in /opt/puppetlabs/puppet/bin/hiera.

It would make it possible to drop the old "hiera" package, that ships
hiera 3.

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

Bug#892908: [Pkg-puppet-devel] Bug#892908: puppet 5 is now builtin to puppet since 4.9

[Louis-Philippe Véronneau]

block 924409 by -1
thanks

On Wed, 14 Mar 2018 15:35:07 +0200 Apollon Oikonomopoulos
 wrote:
> Control: retitle -1 puppet: Hiera 5 is now built-in, please drop hiera 3 
> dependency
> Control: tags -1 wontfix
> 
> Hi,
> 
> On 07:32 Wed 14 Mar , Gabriel Filion wrote:
> > I'm just curious whether the package's dependency on the hiera package 
> > is still needed. hiera 3.x (as distributed by the hiera package) is 
> > still maintained but I'm wondering if we require it with newer puppet
> > installs.
> 
> It appears it's still necessary, at least in order to provide backward 
> compatibility. Puppet itself declares it as a runtime dependency in its 
> gemspec, so I guess it's not that easy to get rid of it (thus marking it 
> as `wontfix' for the time being).

Dear maintainer,

Would it be possible to reconsider this decision now that Buster has
been released?

Upstream still lists the hiera gem as part of their gemspec for
compatibility reason, but I think it's safe to say people have had time
to move from Hiera 3 to Hiera 5.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978575: ruby-deep-merge: Please drop the "Enhances: hiera" relation

[Louis-Philippe Véronneau]

Package: ruby-deep-merge
Version:  1.1.1-1
Severity: normal
Control: block 924409 by -1

Dear maintainer,

hiera is now part of puppet and shouldn't be shipped in Bullseye. Please
drop the "Enhances: hiera" relation so we can remove the package without
breaking yours.

Cheers,

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978574: clevis: tpm2 pin incompatible with tpm2-tools version 5

[Marek Rusinowski]

Package: clevis-tpm2
Version: 13-2
Severity: important

Dear Maintainer,

It looks like currently the clevis-tpm2 is incompatible with
tpm2-tools package in unstable (5.0-1). After trying to encrypt
something with tpm2 I get:

  The tpm2 pin requires tpm2-tools version 3 or 4

It looks like it was fixed upstream in
https://github.com/latchset/clevis/commit/ef76951e4486dadf41ca8085e09849466a0c7fd3.

That commit is unfortunately not included in the latest upstream version 15.

Thank you,
Marek

Debian Release: bullseye/sid
Kernel: Linux 5.9.0-5-amd64

Bug#977870: Failed to load /usr/lib/chromium/libGLESv2.so

[karthek]

Package: chromium
Version: 87.0.4280.88-0.3
Followup-For: Bug #977870
X-Debbugs-Cc: frustra...@karthek.com

hey,

At present hwaccel-videodecode is broken.
--enable-accelerated-video-decode makes chromium to enable it and it
shows up in chrome://gpu but,

when you actually try to play a video(like from youtube), the
mojovideodecoder fails to initialize and it will fallback to
swdecoder(ffmpeg,vpx,dav1...).

You can see it at chrome://media-internals and also by observing STDERR.

I can also confirm this by looking at `intel_gpu_top` utility's screen

Bug#978573: python3-hiera: Please drop the dependency on hiera

[Louis-Philippe Véronneau]

Package: python3-hiera
Version: 0.0.1+20190629-2
Severity: normal
Control: block -1 by 924409

Dear maintainer,

hiera is now part of puppet and shouldn't be shipped in Bullseye. Please
drop the dependency on it.

Looking at the upstream code, it seems your package calls the hiera
executable directly. You thus won't be able to make this change before
#924409 is fixed and the puppet package starts shipping the new hiera
executable.

Cheers,

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978572: src:rust-num-traits: fails to migrate to testing for too long: Depends on non-migrating rust-libm

[Paul Gevers]

Source: rust-num-traits
Version: 0.2.11-1+doctestfix
Severity: serious
Control: close -1 0.2.14-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-num-traits in its current version in unstable has been trying
to migrate for 40 days [2], but earlier versions also didn't migrate.
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=rust-num-traits




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978113: clang++ fail to compile programs

[Nicholas Guriev]

On Sat, 2020-12-26 at 12:10 +0100, Sylvestre Ledru wrote:
> 
> Could you please try to generate it into a regular file?

Sorry, I do not fully understand your question. main.cpp surely was a
regular file. At least, stat(1) reports the following.

   (chrooted)builder@barberry:/$ LANG=C stat 
/proc/8744/root/tmp/tmp.I6YfrNUQO3/main.cpp 
 File: /proc/8744/root/tmp/tmp.I6YfrNUQO3/main.cpp
 Size: 27  Blocks: 8  IO Block: 4096   regular file
   Device: 1eh/30d Inode: 11269092Links: 1
   Access: (0664/-rw-rw-r--)  Uid: ( 1000/ builder)   Gid: ( 1000/ builder)
   Access: 2020-12-28 21:01:18.457019136 +0300
   Modify: 2020-12-28 21:01:30.457149265 +0300
   Change: 2020-12-28 21:01:30.457149265 +0300
Birth: 2020-12-28 21:01:18.457019136 +0300

After reboot my laptop, parent PID and temporary directory are
different. Anyway, the original issue remains even if I copy the
main.cpp file to /tmp inside chroot and host procfs is not involved.




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

Bug#978571: xserver-xorg-video-amdgpu: FTBFS on mips64el, mipsel

[Ivo De Decker]

package: src:xserver-xorg-video-amdgpu
version: 19.1.0-2
severity: serious
tags: ftbfs

Hi,

The latest upload of xserver-xorg-video-amdgpu to unstable fails on mips64el, 
mipsel:

https://buildd.debian.org/status/package.php?p=xserver-xorg-video-amdgpu

Cheers,

Ivo

Bug#978570: src:scummvm: fails to migrate to testing for too long: FTBFS on armhf, mips64el and s390x

[Paul Gevers]

Source: scummvm
Version: 2.1.2+dfsg1-1
Severity: serious
Control: close -1 2.2.0+dfsg1-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 975492

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:scummvm in
its current version in unstable has been trying to migrate for 35 days
[2], but the upload before also didn't migrate. 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=scummvm




OpenPGP_signature
Description: OpenPGP digital signature

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Russ Allbery]

Sam Hartman  writes:

> The issue that came up in the policy discussion is that there may be
> implications for removing an init script.  As an example upgrades may
> break.  In the case of NetworkManager, you might find on an upgrade from
> buster to bullseye that you no longer have network because the init
> script disappeared.

> My recollection of the policy discussion is that there was a sense that
> we might want to say something about that if we managed to come up with
> a consensus, but we didn't want to block that on the general case.

> My take is that removing an init script is unambiguously okay under
> current policy as far as our policy on init scripts.  But for example,
> we have a rule that is fairly basic to our community that we don't break
> upgrades, or at least we try hard not to.  And it may well be that the
> TC or policy process could say more on that topic.

We do drop features all the time between stable releases, though, and
generally that too is at the maintainer's discretion.  The package
maintainer's normal obligation in Debian isn't to keep everything working
that previously was working, but to make it obvious when something is
incompatible (ideally before it breaks on a given system in a way that's
hard to back out of).  Often this is done by dropping or renaming packages
so that the old package just has no upgrade path, but we handle it in
other ways as well (release notes, NEWS.Debian, etc., depending on the
severity of the incompatibility).

That's what I took away from the point about not breaking upgrades.  I
think I may have interpreted "break" somewhat more narrowly than others,
given that.  To me, a broken upgrade is one in which the system stops
working without warning or loses data or the like.  If a package that used
to support MySQL and PostgreSQL now only supports PostgreSQL, that isn't a
"broken" upgrade as long as it's clearly advertised (in NEWS.Debian, in
release notes, etc.) and as long as it doesn't do something destructive
when it was previously using MySQL.

For example, one way that I would consider valid as a way to prevent
upgrades from breaking when one drops support for init systems that don't
support unit files would be to declare a dependency on the class of init
systems that do support unit files, so someone upgrading their system will
clearly see that they have to switch init systems or the package won't
work.  (This works particularly well if that's a change that apt will
decline to perform without special intervention.)  I think that's within
the normal sort of thing that package maintainers do when there are
incompatible changes to a package between stable releases.

I guess the summary of my position on init scripts specifically is that I
generally agree with Wouter's framing of two approaches to Debian who want
very different things, and I thought (at least for init scripts) we put a
range of options on the table from "you must support both approaches" to
"we're only going to support one approach," and the option that people
chose is "one option is strongly preferred but individual maintainers can
support other approaches if they want to and we don't want to make
exploration of other approaches impossible."  The implication was that
some individual maintainers *won't* want to support other approaches in
their individual packages, and that's a decision they get to make, and
therefore folks who want to keep sysvinit working should be exploring
options that don't require the maintainer incorporate that support (such
as a separate package of init scripts or a conversion utility that
generates init scripts from unit files).

Obviously (I hope) if a maintainer did take the dependency approach
mentioned above, there must be some straightforward path for a collection
of init scripts or a conversion utility to satisfy that dependency.
That's where the "project supports the efforts of developers working on
such technologies" part of the GR result comes in.

Just to be extremely clear, the dependency structure for logind feels
different to me and I don't have an opinion on that.

-- 
Russ Allbery (r...@debian.org)  

Bug#963605: ITP: python-language-server -- Python implementation of the Language Server Protocol

[Pablo Mestre]

Hi,

I will work on it. Sadly the Covid situation keep me away from work and
packaging

I will review all the changes on the pkg and the last upstream version

Regards
pablo

El 28/12/20 a las 12:25, Julian Gilbey escribió:
> Hi Pablo,
>
> What is the current status of your ITP for python-language-server?  It
> seems to be needed to get Spyder 4 into unstable.  If you no longer
> have interest in working on this package (or on
> python-jsonrpc-server), that's not a problem - please just say so!
>
> Best wishes,
>
>Julian

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#978569: hiera-eyaml: Please drop the dependency on hiera

[Louis-Philippe Véronneau]

Package: src:hiera-eyaml
Version: 3.2.0-1
Severity: normal
Control: block 924409 by -1

Dear maintainer,

The dependency on the hiera gem for this package was dropped in version
2.0.2 in the following commit:

https://github.com/voxpupuli/hiera-eyaml/commit/dd2291614a76031bc46a31a3a758e52878266a46#diff-36e41aa9bdc9665ced352002b2972ab725af998816ee3005565baec241ce1b3b

hiera is now part of puppet and shouldn't be shipped in Bullseye. Please
drop the dependency on it so we can remove the package without breaking
yours.

Cheers,

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978535: RFS: wxmaxima/20.12.0-1 -- GUI for the computer algebra system Maxima

[Gunter Königsmann]

Gaah! Sorry for that!

Re-uploading a corrected version of the package.

Kind regards,

  Gunter.

On 28.12.20 14:57, Adam Borowski wrote:
> On Mon, Dec 28, 2020 at 12:40:05PM +0100, Gunter Königsmann wrote:
>>  * Package name: wxmaxima
>>Version : 20.12.0-1
>>  wxmaxima (20.12.0-1) unstable; urgency=medium
>>  .
>>* A new upstream version
>>* The debian package now uses GTK3
>>* Bumped the standards version to 4.5.0
>>* Bumped the debhelper compatibility level (and min version) to 13
>>* Removed debian/compat as it no more is needed in comp level 13
>>* override-auto-test no honors the nocheck flag
>>* Removed an no-more-needed linker flag injection
>>* Dropped the workaround for the spurious COPYING file install
>>* New build depends for the automatic tests: netcat-openbsd, xvfb,
>>  debian-file-utils and appstream-util
> It fails to build:
>
> dh ifeq --buildsystem=cmake
> dh: error: Unknown sequence ifeq (choose from: binary binary-arch 
> binary-indep build build-arch build-indep clean install install-arch 
> install-indep)
> make[1]: *** [debian/rules:10: ifeq] Error 25
>
>

Bug#978568: please package new version 1.4.1

[Martin]

Package: libjs-strophe
Version: 1.2.14+dfsg-7
Severity: wishlist

In the 3.5 years since release 1.2.14, many improvements have
been made:

## Version 1.4.1 - (2020-12-02)

* #201: NodeJS related fixes: `window` and `WebSocket` are `undefined`
* New method `Strophe.Connection.prototype.setProtocol` which can be used to
  determine the protocol used after the connection has been constructed.

## Version 1.4.0 - (2020-09-10)

* #347: Bugfix. Reconnection fails when SessionResultIQ arrives too late
* #354: Strophe.js sends an authzid during PLAIN when not acting on behalf of 
another entity
* #359: Bugfix: WebSocket connection failed: Data frame received after close
* Add support for running a websocket connection inside a shared worker

## Version 1.3.6 - (2020-06-15)

- #250 Bugfix: OAuth's SASL priority being higher causes problems
- #352 Bugfix: Referencing undefined property

## Version 1.3.5 - (2020-04-29)

* Remove support for obselete SASL DIGEST-MD5 auth
* #329 Varous compatibility fixes to make Strophe.js work in NodeJS
* #344 Properly set Strophe.VERSION

## Version 1.3.4 - (2019-08-08)

* Replace webpack with rollup
* `TypeError: this._changeConnectStatus is not a function`
* Bugfix. Remove handlers on closed socket
* Add new Strophe.Connection option `explicitResourceBinding`.
  If is set to true the XMPP client needs to explicitly
  call `Strophe.Connection.prototype.bind` once the XMPP
  server has advertised the "urn:ietf:params:xml:ns:xmpp-bind" feature.

## Version 1.3.3 - (2019-05-13)

* The dist files are no longer included in the repo, but generated by NPM/Yarn
* Moved some log statements from INFO to DEBUG level
* Don't break when a falsy value is passed to `getResourceFromJid`

## Version 1.3.2 - (2019-03-21)

* #320 Fix error on SCRAM-SHA-1 client nonce generation

## Version 1.3.1 - (2018-11-15)

* #311 Expose `Strophe`, `$build`, `$msg` and `$iq` as globals

## Version 1.3.0 - (2018-10-21)

* Use ES2015 modules
* Drop support for Internet Explorer < 11

## Version 1.2.16 - (2018-09-16)
* #299 'no-auth-mech' error. Server did not offer a supported authentication 
mechanism
* #306 Fix websocket close handler exception and reporting

## Version 1.2.15 - (2018-05-21)
* #259 XML element should be sent to xmlOutput
* #266 Support Browserify/CommonJS. `require('strophe.js/src/wrapper')`
* #296 Remove error handler from old websocket before closing
* #271 SASL X-OAUTH2 authentication mechanism implemented
* #288 Strophe now logs fatal errors by default.
* Run tests with headless Chromium instead of Phantomjs

(https://github.com/strophe/strophejs/blob/master/CHANGELOG.md)

Please consider packaging the new version. Thanks!

Bug#978547: fontconfig: Please create /var/cache/fontconfig with the default SELinux context

[bauen1]

Package: fontconfig
Version: 2.13.1-4.2
Severity: wishlist
X-Debbugs-Cc: j24...@gmail.com

Dear Maintainer,

On an SELinux enabled system installing fontconfig results in the postinst 
script creating `/var/cache/fontconfig` .
However the postinst script doesn't reset the SELinux label to the default 
context like e.g. dpkg does when extracting packages, depending on the SELinux 
policy used, this could prevent legitimate access to `/var/cache/fontconfig` .

This minor annoyance could be fixed by using `mkdir -Z` instead of `mkdir` when 
creating `/var/cache/fontconfig` .

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy

Versions of packages fontconfig depends on:
ii  fontconfig-config  2.13.1-4.2
ii  libc6  2.31-6
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information

Bug#976791: closed by Debian FTP Masters (reply to Bastian Blank ) (Bug#976791: fixed in linux 5.10~rc7-1~exp1)

[Matt Corallo]

Note that the CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH in the x86 config is bogus - 
CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH depends on CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES which is not set.


On 12/27/20 5:16 PM, Matt Corallo wrote:
Note that this issue was not closed as CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is still missing. The (relevant) diff 
between my (working, self-built) rc7 and 5.10.1 in exp is:


$ diff /boot/config-5.10.0-* | grep "SND\|SOUND"
< CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
 > # CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES is not set
< CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m
< CONFIG_SND_SOC_RT1308=m

On 12/13/20 6:03 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the linux-image-amd64 package:

#976791: Enable CONFIG_SOUNDWIRE (and related drivers)

It has been closed by Debian FTP Masters  (reply to 
Bastian Blank ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters  (reply to 
Bastian Blank ) by

replying to this email.

Bug#978567: src:godot: fails to migrate to testing for too long: FTBFS on mips64el

[Paul Gevers]

Source: godot
Version: 3.2-stable-2
Severity: serious
Tags: sid bullseye ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:godot 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 tagged this bug to only affect sid and bullseye, so it doesn't
affect (old-)stable.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978566: ftp.debian.org: ValueError thrown in postcronscript during dinstall

[Niels Thykier]

Package: ftp.debian.org
Severity: minor

Noticed the following in the dinstall log:

> Dec 28 08:15:23 fasolo dinstall[54493]: ## dinstall BEGIN: 
> postcronscript  ##
> Dec 28 08:15:23 fasolo dinstall[54493]: postcronscript  Traceback (most 
> recent call last):
> Dec 28 08:15:23 fasolo dinstall[54493]: postcronscriptFile 
> "/srv/ftp-master.debian.org/dak//tools/logs.py", line 35, in 
> Dec 28 08:15:23 fasolo dinstall[54493]: postcronscript  dt, l = 
> l.split('\t', 1)
> Dec 28 08:15:23 fasolo dinstall[54493]: postcronscript  ValueError: not 
> enough values to unpack (expected 2, got 1)
> Dec 28 08:15:23 fasolo dinstall[54493]: ## dinstall END: 
> postcronscript ##


I presume it is not important because at first glance it looks like it
has been failing for 14+ days.

~Niels

Bug#978565: src:xmobar: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: xmobar
Version: 0.33-1
Severity: serious
Control: close -1 0.36-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 975472

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:xmobar 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=xmobar




OpenPGP_signature
Description: OpenPGP digital signature

Bug#978564: src:gst-plugins-bad1.0: fails to migrate to testing for too long: dependency is not migrating

[Paul Gevers]

Source: gst-plugins-bad1.0
Version: 1.18.0-2
Severity: serious
Control: close -1 1.18.2-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 976288

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:gst-plugins-bad1.0 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.

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.
In this case, I think it may be wise to upload to
testing-proposed-updates and ask for an unblock. Otherwise your two bug
fix releases may not make it to bullseye.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#839569: ITP: libselenium-remote-driver-perl -- Perl Client for Selenium Remote Driver

[Alexandre GRIVEAUX]

Hello,


I know it's 4 years old but how i can reproduce ?

I've tried downloading from 
https://metacpan.org/release/Selenium-Remote-Driver 




Running it with perl Makefile.pl and make, doesn't produce .so files.


Thanks.

Bug#977845: dgit: unhelpful behavior in case previous upload contained new upstream release

[Paul Gevers]

Hi Ian, Sean,

On 28-12-2020 13:08, Ian Jackson wrote:
> Sean Whitton writes ("Bug#977845: dgit: unhelpful behavior in case previous 
> upload contained new upstream release"):
>> On Mon 21 Dec 2020 at 09:01PM +01, Paul Gevers wrote:
>>> In the end I resorted to
>>> paul@mulciber ~/packages/bugs $ dgit clone f2fs-tools testing
>>> as unstable and testing have the same version, but that doesn't work if
>>> unstable and testing don't have the same version.
>>
>> In this situation what it seems we want to achieve is
>>
>> a) get the version you want to hack on into dgit as if `dgit clone` had
>>given it you
>>
>> b) make it easy to `dgit push` your new version, which is  based on the
>>result of (a).
> 
> The problem is that in this situation the person who uses dgit clone
> does not get the orig tarball and has no systematic way to find it.

Indeed. And the fact that I didn't expect to get a version that's not in
the archive. Yes, there's a message, but it's buried in other output.
Also, for NMU's, I think it's more natural to work on the version in the
archive, not a version that's uploaded but didn't appear (yet) in the
archive. But I think Sean is suggesting to make sure I also get
something like "dgit clone XXX unstable", i.e. I can tell dgit to make
sure I get something that reflects unstable, even though a later upload
with dgit happened.

>> However, detecting whether an upload made it to the archive would
>> require incorporating a lot of idiosyncratic knowledge about dak into
>> dgit, I think, with a fair bit of guessing?  Or is the way that dak
>> keeps track of such things amenable to adding a new ftp-master API query
>> to find out?

Without knowledge, yes, a fair bit of guessing I think. I have no
knowledge of dak on this front.

> dgit clone already knows this situation has arisen, because it can see
> that the version in git is newer than the version in the archive.

Exactly, it even tells me so (after I went back and read the output).
However, what dgit could do in such a case is create a local situation
that has both the situation in the archive

>> In the meantime what I would have done is `apt-get source` followed by
>> `dgit import-dsc` followed by pseudomerging in the result of `dgit fetch
>> unstable`.  What do you think about the error message suggesting that
>> for this sort of situation?

I'm getting around with git, but you'd have to explain quite literally
how to get there, as it's unclear to me what "pseudomerging" means.

> That wouldn't work either, because apt-get source doesn't have access
> to the orig tarball.
> 
> The original uploader had the orig tarball.  dgit push sent it to the
> archive.  But I think if the upload was REJECTed (or dcut or
> something), the archive doesn't have it any more.  I don't think
> ftpmaster keep uploaded things that don't end up in the archive.
> (Please correct me if I'm wrong.)

I'm not sure, but I think you're right.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#911587: infnoise: busy-waits, using too much CPU

[Stephen Kitt]

Hi Axel,

On Mon, 28 Dec 2020 09:29:04 +0100, Axel Beckert  wrote:
> Stephen Kitt wrote:
> > Dear Maintainer,  
> 
> You're writing to yourself as "Dear Maintainer"? :-)

I didn’t bother changing the reportbug template, and who knows the maintainer
might not always be me ;-).

> > Version 0.3 of infnoise busy-waits; 0.2.6 didn’t, so this is a
> > regression.  
> 
> Any news on this? I just dist-upgraded a box which has a Infinite
> Noise TRNG connected from Buster to Bullseye and noticed that infnoise
> is gone. That way I stumbled upon this bug report.

I have figured out what was wrong (cue brown paper bag for me), I’ll upload a
fix shortly.

> There seems a new upstream release (0.3.1) at
> https://github.com/13-37-org/infnoise/releases/tag/0.3.1 (but no
> changelog entry for it so far) and 57 more commits to master since
> then:
> 
> https://github.com/13-37-org/infnoise/compare/0.3.1...master
> 
> Not sure if any of these fix this issue.

0.3.1 was already in unstable, but the error came from incomplete build
flags...

> > I’m designating this as serious to prevent 0.3 from migrating to
> > testing.  
> 
> That's nice, but any chance to get infnoise back into testing?

Yup!

Regards,

Stephen


pgpWxr0TczIH8.pgp
Description: OpenPGP digital signature

Bug#978401: ibus-libpinyin: FTBFS on armel, armhf and mipsel: lua test failure

[Gunnar Hjalmarsson]

On 2020-12-28 15:41, Gunnar Hjalmarsson wrote:

Questions:
- How important is the upgrade to lua5.4?


I can partly answer that question myself: lua5.3, which we have used as 
a build-dep for a while, has not been recognized as a lua package when 
building. For some reason that changed with lua5.4.


Anyway, to make it really build with lua5.3 on Ubuntu I added this patch:

--- a/configure.ac
+++ b/configure.ac
@@ -173,7 +173,7 @@
 if test x"$has_lua_extension" = x"no";
 then
 PKG_CHECK_MODULES(LUA, [
-lua5.1
+lua5.3
 ], [],
 [enable_lua_extension=no]
 );

(there would probably have been a more elegant way to do it via d/rules)

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#978365: [Pkg-fonts-devel] Bug#978365: fonts-inter: FTBFS: fontmake: Error: In 'src/Inter.glyphs' -> 'master_ufo/Inter.designspace' -> 'master_ufo/instance_ufo/Inter-Thin.ufo': Compiling UFO failed

[James Godfrey-Kittle]

Here's a bunch more context on this failure:

https://github.com/rsms/inter/issues/184
https://github.com/googlefonts/fontmake/issues/581
https://github.com/rsms/inter/issues/200
https://github.com/rsms/inter/issues/210

I'm surprised the fonts-inter package is still using fontmake directly
instead of the Inter project's build tools, especially since per
https://github.com/rsms/inter/issues/200 it sounds like this could
yield incorrect output.

Bug#949610: tested your example

[Antoine Beaupré]

On 2020-12-28 17:28:26, Thomas Lange wrote:
> Your raid + luks example works when calling setup-storage, but I
> didn't manage to boot it. Can it work without an unencrypted /boot
> partition?

I'm using those configurations in production right now:

https://gitweb.torproject.org/admin/tsa-misc.git/tree/installer/disk-config

In particular, this is a RAID+LUKS+LVM configuration with a cleartext
/boot, on top of NVMe drives, on a bare-metal machine provided by Hetzner:

https://gitweb.torproject.org/admin/tsa-misc.git/tree/installer/disk-config/gnt-fsn-NVMe

You should be able to reproduce this by booting a rescue system and
running setup-storage, for example on a PX62-NVMe:

https://www.hetzner.com/dedicated-rootserver/px62-nvme

I've setup a handful of machines with this, but keep in mind we do some
post-processing outside of FAI: I only use setup-storage, not the rest
of FAI, for our installer. Those are the post-install scripts:

https://gitweb.torproject.org/admin/tsa-misc.git/tree/installer/post-scripts

and they are fired from this Python/Fabric installer:

https://gitweb.torproject.org/admin/tsa-misc.git/tree/install

... which is mostly a wrapper for:

https://gitweb.torproject.org/admin/tsa-misc.git/tree/fabric_tpa/host.py#n507

... itself a wrapper for grml-debootstrap, which is the bit that's
firing the post-install scripts inside the chroot. That may be the bits
you're missing for the machine to boot?

Sorry, this is all a bit of a mess... I hope that helps!

A.

-- 
The good news about computers is that they do what you tell them to
do. The bad news is that they do what you tell them to do.
- Ted Nelson

Bug#978563: firefox: Consider Desktop Action for "New Window" & "New Incognito Window"

[Andrew Brouwers]

Package: firefox
Version: 84.0-3

On an archlinux system, I noticed the ability to right click the
firefox desktop entry, and have both "new window" and "new incognito
window."  This appears to be achieved in their .desktop file:

https://github.com/archlinux/svntogit-packages/blob/packages/firefox/trunk/firefox.desktop

On Debian, launching an incognito window requires the extra step of
first launching a firefox instance, and using the GUI to spawn a
second window.  The arch solution is nice, as it allows a simple right
click action.

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions-identifier

Bug#978562: opendht: FTBFS on riscv64, linked with -lpthread instead of -pthread

[Aurelien Jarno]

Source: opendht
Version: 2.1.9.5-1
Severity: normal
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

opendht fails to build on riscv64 with the following failure:
| /usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wno-return-type -Wall -Wextra -Wnon-virtual-dtor 
-pedantic-errors -fvisibility=hidden -DMSGPACK_DISABLE_LEGACY_NIL 
-DMSGPACK_DISABLE_LEGACY_CONVERT -Wl,-z,relro -Wl,-z,now -rdynamic 
CMakeFiles/durl.dir/durl.cpp.o -o durl  -lreadline -lncurses ../libopendht.a 
-largon2 -lrt -ldl -lpthread -lgnutls -lnettle -ljsoncpp -Wl,-Bstatic -lfmt 
-Wl,-Bdynamic -lhttp_parser -lssl -lcrypto -ldl -lpthread -lgnutls -lnettle 
-ljsoncpp -Wl,-Bstatic -lfmt -Wl,-Bdynamic -lhttp_parser -lssl -lcrypto 
| /usr/bin/ld: ../libopendht.a(http.cpp.o): in function `.L0 ':
| /usr/include/asio/detail/completion_handler.hpp:72: undefined reference to 
`__atomic_exchange_1'
| /usr/bin/ld: ../libopendht.a(network_utils.cpp.o): in function 
`dht::net::UdpSocket::stop()':
| ./obj-riscv64-linux-gnu/./src/network_utils.cpp:350: undefined reference to 
`__atomic_exchange_1'
| /usr/bin/ld: ../libopendht.a(dht_proxy_client.cpp.o): in function 
`__gnu_cxx::__exchange_and_add_single(int*, int)':
| /usr/include/c++/10/ext/atomicity.h:69: undefined reference to 
`__atomic_exchange_1'
| collect2: error: ld returned 1 exit status

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=opendht=riscv64=2.1.9.5-1=1607520181=0

The problem is that the linking is not done correctly, it uses -lpthread
meaning linking with the pthread library, instead of -pthread which
means enable thread support, and which brings libatomic.so on riscv64.
This can be fixed by using the THREADS_PREFER_PTHREAD_FLAG option, which
is "highly recommended" according to the documentation, but
unfortunately not the default.

This is what the attached patch does, could you please include it in the
next upload?

Thanks,
Aurelien
--- opendht-2.1.9.5/debian/patches/link-pthread.patch   1970-01-01 
00:00:00.0 +
+++ opendht-2.1.9.5/debian/patches/link-pthread.patch   2020-12-28 
10:55:59.0 +
@@ -0,0 +1,18 @@
+Description: Link with -pthread instead of -lpthread
+ The canonical way to link with the thread library is to use -pthread, which
+ brings in additional libraries like libatomic.so on riscv64. However cmake
+ defaults to link with -lpthread which only bring the libpthread.so library.
+ Fortunately it has the option THREADS_PREFER_PTHREAD_FLAG for that, which is
+ "highly recommended" but not the default.
+Author: Aurelien Jarno 
+
+--- opendht-2.1.9.5.orig/CMakeLists.txt
 opendht-2.1.9.5/CMakeLists.txt
+@@ -42,6 +42,7 @@ option (OPENDHT_DOCUMENTATION "Create an
+ # Dependencies
+ list (APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")
+ if (NOT MSVC)
++set (THREADS_PREFER_PTHREAD_FLAG TRUE)
+ find_package (Threads)
+ find_package (PkgConfig REQUIRED)
+ find_package (GnuTLS 3.3 REQUIRED)
--- opendht-2.1.9.5/debian/patches/series   2020-12-08 22:56:05.0 
+
+++ opendht-2.1.9.5/debian/patches/series   2020-12-28 10:55:59.0 
+
@@ -1 +1,2 @@
 pkgconfig-static.patch
+link-pthread.patch

Bug#975943: Reopening as the bug is still not fixed

[Diederik de Haas]

Control: reopen -1 

Turns out that DPKG_MAINTSCRIPT_ARCH can also have the value 'all' and then it 
still does the wrong thing.
# aptitude reinstall udev
...
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-trunk-arm64
latest_kernel: '/boot/vmlinuz-5.10.0-trunk-arm64'
latest_initrd: '/boot/initrd.img-5.10.0-trunk-arm64'
DPKG_MAINTSCRIPT_ARCH: 'all'
arch: 'all'
...
# head -n5 /boot/firmware/config.txt 
enable_uart=1
upstream_kernel=1

kernel=vmlinuz-5.10.0-trunk-arm64
# For details on the initramfs directive, see


Just submitted a merge request to only use the direct approach:
https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/20

Cheers,
  Diederik

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