Bug#994167: ITP: r-bioc-metapod -- GNU R meta-analyses on P-Values of differential analyses

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-metapod -- GNU R meta-analyses on P-Values of differential 
analyses
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-metapod
  Version : 1.0.0
  Upstream Author : Aaron Lun
* URL : https://bioconductor.org/packages/metapod/
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R meta-analyses on P-Values of differential analyses
 Implements a variety of methods for combining p-values in differential
 analyses of genome-scale datasets. Functions can combine p-values across
 different tests in the same analysis (e.g., genomic windows in ChIP-seq,
 exons in RNA-seq) or for corresponding tests across separate analyses
 (e.g., replicated comparisons, effect of different treatment conditions).
 Support is provided for handling log-transformed input p-values, missing
 values and weighting where appropriate.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-metapod

Bug#994151: youtube-dl: the youtube-dl project seams to have died

[Andreas Tille]

Hi,

thank you for the report.  I'll check the situation next week.  I admit
I could need help for youtube-dl or its forks.  I have > 1000 team
maintained packages on my desk and having some helping hands for a
moving target like download programs from youtube.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#994080: qemu-system-x86: Upgrading to 1:2.8+dfsg-6+deb9u15 breaks user-mode networking in guest)

[Matt Roberds]

Markus Koschany  wrote:

Since I do not have an imminent solution for this issue, I intend to
revert the patch for CVE-2021-3592. I will release a regression
update shortly.


I installed this update ( 1:2.8+dfsg-6+deb9u16 ) on the host, for all
15 of the qemu packages I mentioned in my original post, and I can
confirm that it fixes the problem.

User-mode networking works again in the guest; I can access the
Internet in a browser from the guest, and I can scp files to and from
the host in the guest.

Thanks for your help!

Matt Roberds

Bug#994099: twclock: improve .desktop file

[Ervin Hegedüs]

Hi Daniele,

On Sun, Sep 12, 2021 at 10:02:47PM +0200, Daniele Forsi wrote:
> Ervin Hegedüs wrote:
> 
> > this was the lintian tag why I removed the Exec:
> >
> > https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file
> 
> that lintian pages tells to remove the menu file
> /usr/share/menu/twclock not the Exec line

thanks - that's what I also wrote here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994099#26

but first I have to check the behavior without menu file.

73, Ervin

Bug#994166: python3-libvirt: Domain fails to start when virtio video 3D acceleration is enabled

[David Gilmour]

Package: python3-libvirt
Version: 7.0.0-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

qemu-system-common was upgraded to 6.1 from 5.2.  This immediately broke 
support for 3D acceleration in a domain that had previously been using it 
without any problems.

The domain failed to start with the following details available in the 
virt-manager error popup dialog:

Error starting domain: internal error: qemu unexpectedly closed the monitor: 
2021-09-13T03:51:53.214212Z qemu-system-x86_64: -device 
virtio-vga-gl,id=video0,max_outputs=1,bus=pcie.0,addr=0x1: missing object type 
'virtio-gpu-gl-device'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, 
in newfn
ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in 
startup
self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1353, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 
2021-09-13T03:51:53.214212Z qemu-system-x86_64: -device 
virtio-vga-gl,id=video0,max_outputs=1,bus=pcie.0,addr=0x1: missing object type 
'virtio-gpu-gl-device'

The virtio-vga-gl device is new in QEMU 6.1, and is supposed to be supported by 
libvirt 7.6. I don't know if the problem is in the python3-libvirt package, one 
of the libvirt packages, or qemu.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Tried to start the domain.

   * What was the outcome of this action?

The domain did not start.

   * What outcome did you expect instead?

I expected the domain to start.

*** End of the template - remove these template lines ***


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

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

Versions of packages python3-libvirt depends on:
ii  libc6 2.31-17
ii  libvirt0  7.6.0-1
ii  python3   3.9.2-3

Versions of packages python3-libvirt recommends:
ii  libvirt-daemon  7.6.0-1

python3-libvirt suggests no packages.

-- no debconf information

Bug#959161: ITA: complexity -- tool for analyzing the complexity of C program functions

[Boian Bonev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wnpp
Severity: normal
Control: owner -1 !
Control: thanks

I intend to adopt the complexity package.

There are no bugs open.
The upstream looks like not dead with a recent release.
The update to the latest release version is not trivial - it includes
removing repackaging because the offending file is licensed under a
free license (but would generate content that itself is under a non-
DFSG license and that is not used in the build).

The proposed upload is in mentors.

I believe that I am able to properly maintain it.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmE+wckACgkQE2VyCRPS
8i31fg/+OULA91T9o88NMiDCezasjn5fJkYSEuuJkMY7ENA8GEfQTSnSGyc1EeR6
bmjoMmC4ir3c1kkLwIqO1fpWXgSfZC1JdpuoLXlWFWXCZUFhzoNnfAtySpPDFGvA
+iL4H+icVaazHhrFZGTQ3KEZ3QAnUa1/PVWFLD28SUke5jEgcE+/t4tEvwLo8Kf6
apUAjkocWpBrFk0wgCJxEFQFQU0o+aQLjkxgF+sT51HYbpD8bEvZfJmvw/w4onFW
rlayYrR9vGhAF6TbKz1k6PXbQGnFy19b6hX5X0RkvkyfSfeEEZkQw9cPwveqtNNj
rw2yAA+8Ko10XIMEyT5j7et5GCIpL5j+CKr3Y2Qj7g1ZcugE3hakN2BTco9ePTle
VygaP85S/sdaNR/TMPfCxAcfi3MjLiBAAS58A8cIJLyVCEQVkAr/f/M8TD8/7l5R
DBbw+lzj6FVMOBRPzzKpvjQTF4Wz1vPuOrLgI7JAgLKgzg/KZ3rQfda9ojpAb13E
cHdaas2fA9wd/e6E/TTbWPOB0hczsjCcFAi2VBNcn+w8SBbUOrHka21UMCnP5wFJ
caWeWr0+HhV6hsz+yRpaOVsuW1PF8E1ei30xR3oFKKe/SPi8bn/RM9SCWNdO5lJW
sy5dKtONGVU0fmOIgEJF8t1x0xtxKZuH4xEbRtJxzPUOBftzeD8=
=r8IN
-END PGP SIGNATURE-

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Sam Hartman]

> "Ole" == Ole Tange  writes:

Ole> On Tue, Sep 7, 2021 at 11:06 AM Lucas Nussbaum  
wrote:
Ole> :
>> (1) the wording almost requires citation

Ole> I take this as you agree that it does not require
Ole> citation. Also you do not point to how the default behaviour of
Ole> the current version of GNU Parallel conflicts with Debian's
Ole> standards. If you believe it conflicts with Debian's standards,
Ole> please point to the specific paragraph(s).

I'm sorry, but that's just not how it works (pointing to specific
paragraphs in a case like this).

My take on this discussion is that there's nothing for debian-legal
here.
This seems clearly within the power Debian grants individual maintainers
to either keep the citation notice or to remove it.

You as upstream can make your decisions after the Debian maintainer
makes theirs.  You can do anything from thanking the maintainer
(presumably if they do something you agree with), to raising a trademark
issue (saying you believe Debian needs to change the name), to
reconsidering where you put your time based on what funding you are
receiving.

I don't think that discussing this issue on debian-legal any more serves
any purpose.
There isn't a project level consensus that would override a maintainer
here.
It seems that the maintainer would have sufficient support if they
removed the citation requirement.
However it also seems unlikely that there would be sufficient support to
override a maintainer if they chose to keep the notice.
There were also some debconf or wrapper options discussed, and those
also seem within the latitude we grant our maintainers.

--Sam

Bug#994165: pipewire: add pipewire-alsa/pipewire-jack packages

[Paul Wise]

Source: pipewire
Severity: wishlist

On Arch Linux, to enable forwarding of the ALSA and JACK APIs to
PipeWire you only have to install pipewire-alsa and pipewire-jack while
on Debian you have to manually copy some files around. I think it would
be better to follow the Arch Linux model and have -alsa/-jack packages
just like there is the pipewire-pulse package in Debian.

https://archlinux.org/packages/extra/x86_64/pipewire-alsa/files/
https://archlinux.org/packages/extra/x86_64/pipewire-jack/files/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

[Vincent Lefevre]

Control: forcemerge 953032 994036

Now, due to the comments below, these are the same bug.

Note that in my case, this doesn't fill the logs, because I execute
xkbcomp just once just after starting X (but there may be good reasons
to execute it much more often).

On 2021-09-13 02:17:11 +0200, Vincent Lefevre wrote:
> Control: reassign -1 x11-xkb-utils 7.7+5
> Control: retitle -1 x11-xkb-utils: xkbcomp gives internal errors on unknown 
> keysyms (e.g. some XF86* with xkb-data 2.33-1)
> Control: notforwarded -1
> Control: tags -1 fixed-upstream
> 
> On 2021-09-10 19:08:59 +0200, Vincent Lefevre wrote:
> > This is apparently an upstream bug (which I have just reported),
> > introduced in 2.33, as some commit added these unknown keysyms.
> 
> Upstream regards this as a bug in xkbcomp, which has been fixed in
> xkbcomp 1.4.4 (the errors are downgraded to warnings, which is OK
> since one can disable warnings, and this is what I currently do,
> except for testing).
> 
> Note: x11-xkb-utils 7.7+5 (the current version in unstable) has
> xkbcomp 1.4.3 only.

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

Bug#472311: Merge duplicates bugs in most

[Benj. Mako Hill]

severity 472311 wishlist
forwarded 472311 j...@jedsoft.org
merge 472311 585566
thanks

Greetings!

I embarrassed for fixing this up before but I realize that these two
bugs are duplicates. I'll clean this up now before I close these with
an upload I'm preparing now.

Regards,
Mako

-- 
Benjamin Mako Hill
https://mako.cc/academic/


signature.asc
Description: PGP signature

Bug#907767: time to go, then

[Adam Borowski]

Control: clone -1 -2
Control: retitle -2 RM: mozplugger -- RoQA; useless; dead upstream
Control: reassign -2 ftp.debian.org

In Sep 2018, Adrian Bunk wrote:
> As far as I can see, not a single one of the 15 (sic) browser packages
> in the dependencies does both still exist in unstable and still work
> with mozplugger.

So what's the reason to keep it?
I happen to know a group of guys (11 humans, 1 cat/god) who are good at
dealing with "package X exists when it shouldn't".  Have at it!

drill -t any mozplugger.mozdev.org
→ NXDOMAIN


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#993638: libxml2: XHTML 1.0 validation is broken

[Vincent Lefevre]

Control: found -1 2.9.12+dfsg-4

On 2021-09-04 03:40:17 +0200, Vincent Lefevre wrote:
> After the upgrade to 2.9.12+dfsg-3, XHTML 1.0 validation is broken.
> There was no such issue with 2.9.10+dfsg-6.7.

Still broken in 2.9.12+dfsg-4.

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

Bug#677602: localepurge: dpkg --prune-excluded and --list-missing

[Trent W. Buck]

For the record,

This is to publish my coping strategies for this feature being missing from 
dpkg.

This is what I've been doing in debootstrap,
to purge packages unavoidably installed BEFORE localepurge, but
still benefit from path-exclude (MUCH faster) for packages installs AFTER 
localpurge:

debootstrap --variant=minbase ... $t
...
chroot $t apt-get install locales localepurge
chroot $t sed -i /etc/locale.nopurge -e 's/^USE_DPKG/#ARGH#&/'
chroot $t localepurge
chroot $t sed -i /etc/locale.nopurge -e 's/^#ARGH#//'
chroot $t apt-get install 

This is more annoying in mmdebstrap, which
for speed reasons tries to do only 2 rounds of apt-get
(one for apt, one for everything else).







This shows & measures some strategies for "doing" localepurge for what is 
approximately Debian Live XFCE:

ROW SIZE  REAL   USER   SYSCOMMAND
  1 282M  2m41s  9m07s  0m13s  ./tmp.sh  # baseline, no localepurge
  2 290M  2m49s  9m32s  0m14s  ./tmp.sh --include=localepurge
  3 290M  2m50s  9m32s  0m13s  ./tmp.sh --include=localepurge 
--essential-hook='echo localepurge localepurge/use-dpkg-feature boolean false | 
chroot $1 debconf-set-selections'
  4 266M  2m38s  8m57s  0m13s  ./tmp.sh --include=localepurge 
--essential-hook='echo localepurge localepurge/use-dpkg-feature boolean false | 
chroot $1 debconf-set-selections' --customize-hook='chroot $1 localepurge'
  5 275M  2m40s  9m12s  0m13s  ./tmp.sh --essential-hook='chroot $1 apt-get 
install -y localepurge'
  6 265M  2m35s  8m52s  0m12s  ./tmp.sh --essential-hook='chroot $1 apt-get 
install -y localepurge& $1 sed -i /etc/locale.nopurge -e 
"s/^USE_DPKG/#ARGH#&/"& $1 localepurge& $1 sed -i 
/etc/locale.nopurge -e "s/^#ARGH#//"'
  7 267M  2m34s  8m44s  0m12s  ./tmp.sh --setup-hook='mkdir -p 
$1/etc/dpkg/dpkg.cfg.d' --setup-hook='copy-in 
/etc/dpkg/dpkg.cfg.d/50localepurge /etc/dpkg/dpkg.cfg.d'
  =
  6% 4%  SAVINGS FROM LOCALEPURGE
  =

>From past experience, when localepurge is working correctly,
the image should build 8%-12% faster AND be 8%-12% smaller.

You can see that the intuitive approach (2) doesn't work at all.
Oddly, nor does simply telling localepurge to use its pre-path-exclude code. (3)
Manually firing localepurge afterwards mostly works. (4)

We get the best results by fully preserving the original debootstrap workaround 
(6),
i.e. an entire separate apt-get process, just for localepurge & its 
dependencies,
AND doing a manual localepurge, then allowing  packages to 
install using path-excludes.

Finally, we can "cheat" by inserting a localepurge generated ahead of time on 
another system. (7)
This works well but assumes the build system and built system have identical 
locales configuration.


PS: I can't explain why the "working" cases (4,6,7) have varying sizes 
(265/266/267M).




APPENDIX: tmp.sh


#!/bin/bash
# NOTE: aptopt/dpkgopt are optional "go faster" racing stripes.
# NOTE: Without --variant=apt, "chroot $1 apt-get" is failing for reasons I 
don't understand.
time mmdebstrap bullseye delete-me.squashfs \
--variant=apt \
--logfile=delete-me.log \
--include=linux-image-generic,live-boot,live-config,task-xfce-desktop \
--include=locales \
--essential-hook='echo locales locales/default_environment_locale   select 
en_AU.UTF-8   | chroot $1 debconf-set-selections' \
--essential-hook='echo locales locales/locales_to_be_generated multiselect 
en_AU.UTF-8 UTF-8 | chroot $1 debconf-set-selections' \
--aptopt='Acquire::http::Proxy "http://odin:3142;' \
--dpkgopt=force-unsafe-io \
"$@" &&
du -shx delete-me.squashfs

Bug#994162: RM: gtksourceview2 -- ROM; unmaintained library

[Jeremy Bicha]

Control: tags -1 -moreinfo
Control: block -1 by 994161
Control: retitle -1 RM: gtksourceview2 -- ROM; unmaintained library

I went ahead and filed a removal bug for matita so dropping the moreinfo flag.

Thank you,
Jeremy Bicha

Bug#994163: RM: matit -- RoQA; unbuildable since 2018, depends on gtksourceview2

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: mat...@packages.debian.org
Affects: matita
Control: block 994162 by -1

matita is now the last thing preventing the removal of gtksourceview2
from Debian.

It has been unbuildable in Debian for 2 or 3 years.

The latest upstream release was in 2016 (and is the version that was in Debian).

References
--
https://bugs.debian.org/913606
https://buildd.debian.org/status/logs.php?pkg=matita=amd64
http://matita.cs.unibo.it/

Thanks,
Jeremy Bicha

Bug#994162: RM: gtksourceview2: ROM; unmaintained library

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: gtksourcevi...@packages.debian.org
Affects: gtksourceview2
Control: block -1 by 994098
Tags: moreinfo

Please remove gtksourceview2 from Debian. See
https://bugs.debian.org/911166 for background.

I am setting the moreinfo tag since matita still depends on gtksourceview2.

Thank you,
Jeremy Bicha

Bug#994161: RM: golang-github-mattn-go-gtk -- RoQA; unused, depends on gtksourceview2

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: golang-github-mattn-go-...@packages.debian.org
Affects: src:golang-github-mattn-go-gtk

golang-github-mattn-go-gtk has no remaining reverse dependencies.

It depends on gtksourceview2 which we are trying to remove from Debian soon.

(gtksourceview4 is recommended for gtk3 apps and gtksourceview5 will
be packaged for gtk4 apps)

I got approval from the maintainer Drew before filing this bug.

Thanks,
Jeremy Bicha

Bug#994149: RFS: mailnag/2.2.0-1 [QA] -- extensible mail notification daemon

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: mailnag
   Version : 2.2.0-1
   Upstream Author : Patrick Ulbrich 
 * URL : https://github.com/pulb/mailnag
 * License : CC0-1.0, GPL-2.0+, Python-2.0
 * Vcs :
   Section : mail

It builds those binary packages:

  mailnag - extensible mail notification daemon

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mailnag/mailnag_2.2.0-1.dsc

Changes since the last upload:

 mailnag (2.2.0-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream version 2.2.0
   * Set Maintainer to Debian QA Group. see #968540
   * d/control:
 - Remove Vcs-* entries, no longer exists.
 - Add Rules-Requires-Root: no
 - Bump debhelper to 13
 - Update Standards-Version to 4.6.0
   * d/watch: Update to version 4
   * Add metadata file.
   * d/copyright:
 - Change URL to https
 - Update years
 - Add new copyright entries.

Regards,
Håvard

Bug#994036: xkb-data: gives lots of internal errors with xkbcomp on XF86* keysyms

[Vincent Lefevre]

Control: reassign -1 x11-xkb-utils 7.7+5
Control: retitle -1 x11-xkb-utils: xkbcomp gives internal errors on unknown 
keysyms (e.g. some XF86* with xkb-data 2.33-1)
Control: notforwarded -1
Control: tags -1 fixed-upstream

On 2021-09-10 19:08:59 +0200, Vincent Lefevre wrote:
> This is apparently an upstream bug (which I have just reported),
> introduced in 2.33, as some commit added these unknown keysyms.

Upstream regards this as a bug in xkbcomp, which has been fixed in
xkbcomp 1.4.4 (the errors are downgraded to warnings, which is OK
since one can disable warnings, and this is what I currently do,
except for testing).

Note: x11-xkb-utils 7.7+5 (the current version in unstable) has
xkbcomp 1.4.3 only.

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

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

[Adam Borowski]

On Sun, Sep 12, 2021 at 02:51:28PM +0200, Olivier Girondel wrote:
>   * Package name: lebiniou
> Version : 3.62.0-1

>   * New upstream release 3.62.0.
>   * debian/control: Build-Depends: Remove htmlmin, python3-setuptools.
>   * debian/control: Build-Depends: Add liblo-dev.
>   * debian/copyright: Update.
>   * debian/lebiniou.lintian-overrides: Update.
>   * debian/rules: Remove override_dh_autoconfigure.
>   * debian/source/lintian-overrides: Remove.

Hi!
The autopkgtest fails with:

mkdir: cannot create directory ‘/home/kilobyte/.lebiniou’: No such file or 
directory
cp: cannot create regular file '/home/kilobyte/.lebiniou': No such file or 
directory
cat: /home/kilobyte/.lebiniou/lebiniou.json: No such file or directory

[!] Failed to load settings: unable to open 
/home/kilobyte/.lebiniou/lebiniou.json: No such file or directory
ALSA lib confmisc.c:855:(parse_card) cannot find card '0'
ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_card_inum 
returned error: No such file or directory
ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings
ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name
ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5599:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM default
O_o error opening PCM device default
/usr/share/lebiniou/test/lebiniou-test.sh: line 57: 15722 Aborted   
  lebiniou $OPTIONS > $AUTOPKGTEST_TMP/video1.log
[!] Failed to load settings: unable to open 
/home/kilobyte/.lebiniou/lebiniou.json: No such file or directory
ALSA lib confmisc.c:855:(parse_card) cannot find card '0'
ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_card_inum 
returned error: No such file or directory
ALSA lib confmisc.c:422:(snd_func_concat) error evaluating strings
ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1334:(snd_func_refer) error evaluating name
ALSA lib conf.c:5111:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5599:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM default
O_o error opening PCM device default
/usr/share/lebiniou/test/lebiniou-test.sh: line 62: 15723 Aborted   
  lebiniou $OPTIONS > $AUTOPKGTEST_TMP/video2.log
ls: cannot access '/tmp/autopkgtest.Onnpyt/autopkgtest_tmp/*.mp4': No such file 
or directory

You can't use $HOME in autopkgtests.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#994139: lintian: warning about superficial autopkgtests is counterproductive

[Felix Lechner]

Hi,

On Sun, Sep 12, 2021 at 3:27 PM Simon McVittie  wrote:
>
> the first of those is the new missing-tests-control, and I would
> agree with making it an error.

Done. It is now an error. [1]

I'll note that the condition is somewhat artificial. It would probably
be better to declare all testing matters—like deployment of a team's
test suite—in d/tests/control. The mere presence of that file would
declare the test suite. The condition could then never occur,
rendering the tag obsolete.

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/79c47559e95213c4318b7e02130aa962332c75ea

> I think the second of those is the old testsuite-autopkgtest-missing,
> which apparently no longer exists. Saying that testsuite-autopkgtest-missing
> is an old name for the new missing-tests-control seems inaccurate?

The old tag testsuite-autopkgtest-missing tested somewhat
indiscriminately whether 'autopkgtest' was mentioned in the field
Testsuite in d/control. [2] Dpkg since version 1.17.11, however,
automatically adds that value to the dsc when d/tests/control is
present [3]. That part of the condition is no longer meaningful. (It
was arguably also the only error detected by the tag.)

For the other half of the tag—and the purpose stated in its
description—namely "package does not declare a test suite" [3] there
is from what I can tell no project consensus. That is why the tag was
deleted.

As a side note, the old tag to which you seem attached took a stance
against superficial tests. [5]

[2] 
https://salsa.debian.org/lintian/lintian/-/commit/c81fb3dbc4425c4322c67f0f3eeb2c208e337736#6f4367b101cfbfb8143c3faa1edd9c67326e2614_76_70
[3] https://sources.debian.org/src/dpkg/1.20.9/debian/changelog/
[4] 
https://salsa.debian.org/lintian/lintian/-/commit/c81fb3dbc4425c4322c67f0f3eeb2c208e337736#339cb554585174385393ac6779bbc6202a1339b4_4_0
[5] 
https://salsa.debian.org/lintian/lintian/-/commit/c81fb3dbc4425c4322c67f0f3eeb2c208e337736#339cb554585174385393ac6779bbc6202a1339b4_19_0

> Conversely, if superficial-tests is serious enough to justify a lintian
> tag, then testsuite-autopkgtest-missing should be a lintian tag of equal
> or higher severity, because it's a strictly lower level of test coverage
> than superficial-tests.

I agree with you here, but that logic does not hold universally. The
level of coverage is only one of several criteria that apply when
settling on a tag's appropriate visibility. For example, there may be
a stronger project consensus that tests should be meaningful rather
than that tests should be required.

> to avoid
> "noise" for the maintainers of packages where autopkgtest coverage is not
> feasible to implement, then perhaps they should be classification tags?

Classification tags are used for research in the archive. They are
examined via our website's JSON interface and can yield helpful
information about relative prevalence ratios. They cannot reduce noise
for certain package families. For that, you may be excited about a new
feature in Lintian. [6] You can now request screens for your package
family although there are some hurdles to being so recognized. [7]

In response to Paul's email, which came in the meantime, the screens
can be used to mask the tag superficial-tests (or any other
autopkgtest tag discussed here) for sources for which meaningful tests
do not exist.

[6] 
https://salsa.debian.org/lintian/lintian/-/commit/8c3d587559cfbdf5dd41e9ba1f66c9ab52de577e
[7] https://lintian.debian.org/screens

Kind regards
Felix Lechner

Bug#994160: libmojolicious-plugin-assetpack-perl: newer upstream version (2.13) available

[Philip Hands]

Package: libmojolicious-plugin-assetpack-perl
Version: 2.11-1
Severity: wishlist

Hi,

I notice that this package has new upstream maintenance, which is good since it
was previously in limbo having been deprecated by the author in favour of 
webpack.

As can be seen here:

  https://metacpan.org/dist/Mojolicious-Plugin-AssetPack

and here:

  https://github.com/mojolicious/mojo-assetpack/commits/main

mantenance has now resumed under the aegis of the mojolicious team.

BTW The only reason I noticed this is that I am packaging openQA at present, so
was looking at openSUSE's ticketing system, and there was a thread regarding
upgrading openQA to use webpack which concluded with the issue being moot when
one of the participants appears to have taken on the role of upstream for
assetpack.

Cheers, Phil.

Bug#994139: lintian: warning about superficial autopkgtests is counterproductive

[Paul Wise]

On Sun, 2021-09-12 at 23:27 +0100, Simon McVittie wrote:

> I don't think it makes sense for the new superficial-tests to be considered
> worse (= higher severity) than the old testsuite-autopkgtest-missing.

I was initially thinking of cases were the package is perfectly
possible to test properly but the maintainer just added a foo -v
superficial test instead of adding a real test. I hadn't considered
packages that aren't possible to test, for those I guess I assumed
maintainers would just not add any tests. If the amount of packages
with superficial tests that aren't possible to properly test is higher
than the amount of packages that are possible to properly test, then
your reasoning makes sense and the severities should be changed. From
the examples you presented, I think that is correct so I agree the
severities should be changed indeed. I do feel however that the value
of superficial tests is usually quite minimal and so I would suggest to
use the same severity for zero tests as for only superficial tests.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#989051: [Debian-med-packaging] Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI

[Maarten L. Hekkelman]

Hi Étienne,

Thank you very much for your reply. Luckily I found out the same route 
(using qemu) myself and fixed the problem All architectures are now 
green in tracker: https://buildd.debian.org/status/package.php?p=mrc


regards, -maarten


Op 12-09-2021 om 15:59 schreef Étienne Mollier:

Hi Maarten,

Maarten L. Hekkelman, on 2021-09-02:

I found the underlying problem, apparently the ABI field of the ELF header
should contain a flag indicating it is a Linux executable. In order to set
this flag properly, I need to find out various things and perhaps it is
easiest to try to figure out these myself. Is it possible to get access to a
HPPA machine running Debian? I am a Debian maintainer, if that makes any
difference.

Without easy access to a PA-RISC machine, you can resort to
Qemu.  The Debian hppa port can be emulated using one of the
emulators provided in the package qemu-system-misc.  If you
combine it with the package qemu-user-static (and also have
Debian ports keyring at hand), then you can directly debootstrap
a chroot able to run PA-RISC binaries:

$ uname -m
x86_64

$ sudo debootstrap \
--arch=hppa \
--keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg \
--include=debian-ports-archive-keyring \
sid sid-hppa-chroot http://ftp.ports.debian.org/debian-ports
I: Target architecture can be executed
[...]
I: Base system installed successfully.

$ sudo chroot sid-hppa-chroot uname -m
parisc


Otherwise, could you provide me the output of `cpp -dM /dev/null` and
perhaps also how to detect PA-RISC/Debian in a cmake file. That last
question is perhaps a bit too much to ask for, but any hint is appreciated.

Feel free to checkout cpp_hppa.h in attachment; I obtained it
with the aforementioned method.

In hope this helps,
Have a nice day,  :)


--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

On 2021-09-12 02:58 PM, Steve Dondley wrote:


Here is my version of app.js:
https://gist.github.com/sdondley/9db6dbffb8fb751c4afcd1092ab24fd0


Alright, so all confusion is from the fact that I did hack the app.js
file and did not revert it back to its original state as I thought. I
did make this change to app.js:

2696c2696
<   this.env.search_scope = 'base';
---

  this.env.search_scope = 'all';


This is a bug an upstream bug. Sorry to waste your time. Please close
this out. I will report this to roundcube project.


I'll know better next time that the files don't go directly into the 
package and are merely pulled from the source on github. Thanks for 
pointing this out.

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

Here is my version of app.js:
https://gist.github.com/sdondley/9db6dbffb8fb751c4afcd1092ab24fd0


Alright, so all confusion is from the fact that I did hack the app.js 
file and did not revert it back to its original state as I thought. I 
did make this change to app.js:


2696c2696
<   this.env.search_scope = 'base';
---

  this.env.search_scope = 'all';


This is a bug an upstream bug. Sorry to waste your time. Please close 
this out. I will report this to roundcube project.

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

OK, I figured it out. So this is really bizarre.

The freshly downlaoded copy of app.js still does not match your md5. I 
get:


53dc7e81f7db265b0e3860ec718a3e1e

I get this for both the installed copy of app.js and the one I
downloaded from the .deb package.


OK, disregard this, too. This is because the same file is getting me 
symlinked. I'm not very familiar with how these files get packaged. 
Amateur mistake.

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

On 2021-09-12 02:27 PM, Guilhem Moulin wrote:

On Sun, 12 Sep 2021 at 14:16:58 -0400, Steve Dondley via
Pkg-roundcube-maintainers wrote:

What's the easiest way to get my hands on the original file from the
package?


We don't have Debian-specific modification, so you can simply take it
from upstream.

$ curl -Ls
https://github.com/roundcube/roundcubemail/raw/1.4.11/program/js/app.js
| md5sum
b4865d6536b9188b7f5c3ae0361a1cb5  -


This is the md5 I get when I check against 1.4.10 not 1.4.11. When I 
check against 1.4.11, I get


53dc7e81f7db265b0e3860ec718a3e1e

Bug#994158: bt-adapter (and other bluetooth tools) throws assertions failed rather than user-understandable errors if bluetoothd not running or no host adapter present

[Alain Knaff]

Package: bluez-tools
Version: 2.0~20170911.0.7cb788c-4

Hi,

bt-adapter -i fails assertions when attempting to start it without 
bluetoothd running, or no host adapter present.


If bluetoothd is not running, it waits a long while (why? It's a TCP 
connection, which should fail immediately), and finally throws following 
assertion failed:

**
ERROR:lib/helpers.c:319:intf_supported: assertion failed: (introspection_proxy 
!= NULL)
Bail out! ERROR:lib/helpers.c:319:intf_supported: assertion failed: 
(introspection_proxy != NULL)
Aborted


If bluetoothd *is* running, but no hostadapter (HCI) present, it throws 
the following assertion:

**
ERROR:lib/bluez/adapter.c:165:adapter_get_dbus_object_path: assertion failed: 
(ADAPTER_IS(self))
Bail out! ERROR:lib/bluez/adapter.c:165:adapter_get_dbus_object_path: assertion 
failed: (ADAPTER_IS(self))
Aborted

Normally, assertions should only be thrown for *internal* bugs in the 
application, but not for external conditions (such as services or 
hardware not present). For the user it would be much more obvious if it 
plainly said something to the effect of "Bluetoothd service not running" 
or "No Bluetooth Host Adapter (HCI) found"

Thanks,

Alain

Bug#994159: opentmpfiles: abandoned by upstream developer

[Simon McVittie]

Source: opentmpfiles
Version: 0.3.1-2
Severity: important
Tags: upstream wontfix

I happened to notice that opentmpfiles is now unmaintained upstream:

> Since systemd-tmpfiles is a single binary which can be compiled and
> run without systemd, we have decided to retire this project. For more
> information see the related issue[1].
> [1] https://github.com/OpenRC/opentmpfiles/issues/19

If someone wants to maintain a non-systemd implementation of tmpfiles.d
in Debian, they should probably either become the upstream maintainer
of a fork of opentmpfiles that fixes its RC bugs, or package a different
implementation that does not suffer from CVE-2017-18925 (the upstream
issue mentions an implementation in Rust, but I don't know whether it's
production-ready).

systemd/experimental adds a systemd-standalone-tmpfiles binary package
that can be used on Linux ports without using systemd as pid 1, although
that isn't in unstable yet, and is probably not suitable for kFreeBSD or Hurd.

smcv

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

On 2021-09-12 02:16 PM, Steve Dondley wrote:

On 2021-09-12 02:07 PM, Guilhem Moulin wrote:

On Sun, 12 Sep 2021 at 13:02:41 -0400, Steve Dondley via
Pkg-roundcube-maintainers wrote:

That said, there must still be a bug because roundcube is supposed to
remember the search scope feature from the $_SESSION variable and 
it's not
doing that. Looking at the PHP code, roundcube is most certainly 
intended to

has this ability. If you manually refresh the page after selecting a
different folder the setting does, in fact, kick in.

The $_SESSION variable for search_scope gets ignored and overridden 
by some
javascript. And replacing app.min.js with app.js fixes the problem. 
Why that

fixes the problem, I have no earthly idea.


I can't reproduce this in a clean Bullseye chroot.  Removed app.min.js
so the non-minified version is used instead, but I still have to 
reload
the page to prefill the search dialog with Scope=all.  Does your 
app.js

matches what we shipped in roundcube-core?  DEBIAN/md5sums snippet:

b4865d6536b9188b7f5c3ae0361a1cb5  
usr/share/roundcube/program/js/app.js
7a0c881ca3e9cbff512853fcdb8e6650  
usr/share/roundcube/program/js/app.min.js

4f3ace3cd9376165005b754226ca1bd8
usr/share/roundcube/program/js/app.min.js.gz
5b9f0a46d6913f9b3481fece00930cd9
usr/share/roundcube/program/js/app.min.js.map


They all match except for app.js. I did modify it when troubleshooting
the problem but I'm pretty sure i reverted everything back.

What's the easiest way to get my hands on the original file from the 
package?


OK, I figured it out. So this is really bizarre.

The freshly downlaoded copy of app.js still does not match your md5. I 
get:


53dc7e81f7db265b0e3860ec718a3e1e

I get this for both the installed copy of app.js and the one I 
downloaded from the .deb package.

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

On 2021-09-12 02:28 PM, Steve Dondley wrote:

On 2021-09-12 02:16 PM, Steve Dondley wrote:

On 2021-09-12 02:07 PM, Guilhem Moulin wrote:

On Sun, 12 Sep 2021 at 13:02:41 -0400, Steve Dondley via
Pkg-roundcube-maintainers wrote:
That said, there must still be a bug because roundcube is supposed 
to
remember the search scope feature from the $_SESSION variable and 
it's not
doing that. Looking at the PHP code, roundcube is most certainly 
intended to

has this ability. If you manually refresh the page after selecting a
different folder the setting does, in fact, kick in.

The $_SESSION variable for search_scope gets ignored and overridden 
by some
javascript. And replacing app.min.js with app.js fixes the problem. 
Why that

fixes the problem, I have no earthly idea.


I can't reproduce this in a clean Bullseye chroot.  Removed 
app.min.js
so the non-minified version is used instead, but I still have to 
reload
the page to prefill the search dialog with Scope=all.  Does your 
app.js

matches what we shipped in roundcube-core?  DEBIAN/md5sums snippet:

b4865d6536b9188b7f5c3ae0361a1cb5  
usr/share/roundcube/program/js/app.js
7a0c881ca3e9cbff512853fcdb8e6650  
usr/share/roundcube/program/js/app.min.js

4f3ace3cd9376165005b754226ca1bd8
usr/share/roundcube/program/js/app.min.js.gz
5b9f0a46d6913f9b3481fece00930cd9
usr/share/roundcube/program/js/app.min.js.map


They all match except for app.js. I did modify it when troubleshooting
the problem but I'm pretty sure i reverted everything back.

What's the easiest way to get my hands on the original file from the 
package?


OK, I figured it out. So this is really bizarre.

The freshly downlaoded copy of app.js still does not match your md5. I 
get:


53dc7e81f7db265b0e3860ec718a3e1e

I get this for both the installed copy of app.js and the one I
downloaded from the .deb package.


Here is my version of app.js: 
https://gist.github.com/sdondley/9db6dbffb8fb751c4afcd1092ab24fd0

Bug#994139: lintian: warning about superficial autopkgtests is counterproductive

[Simon McVittie]

On Sun, 12 Sep 2021 at 13:49:35 -0700, Felix Lechner wrote:
> Either way, the project relies here on the fact
> that having a meaningful testsuite may provide a faster migration from
> unstable to testing.

I think there might be some misunderstanding here. Tests that are marked
with "Restrictions: superficial" cannot make migration faster, even if
they pass: they can only block or delay migration, by failing. That's
the purpose of the superficial keyword: it tells the autopkgtest
infrastructure not to assume that this particular test-case has meaningful
coverage.

If every test in the test suite has a "neutral" result, then there is
no migration bonus. Tests that pass but are marked as superficial are
considered to be "neutral" rather than a success, meaning they do not
speed up migration for a package that does not "deserve" it.

(Other neutral results include tests that fail but are marked as "flaky",
and tests that are skipped because they require isolation or other
functionality that the testbed cannot provide - for example, trying to
run flatpak's test suite inside an lxc container is skipped, because the
security restrictions imposed by lxc prevent flatpak from working.)

Adding tests that *are* superficial, but are not *marked* as superficial,
is a serious problem, because it can cause packages to migrate too
soon (and the release team's RC policy since bullseye says this is a
release-critical bug). However, this is not really feasible for Lintian
to detect, so I think the Lintian maintainers should treat detection of
that class of bug as being out-of-scope.

> On Sun, Sep 12, 2021 at 1:17 PM Simon McVittie  wrote:
> > If that's the case, I would have expected it to be emitted for packages
> > that have absolutely no autopkgtest coverage
> 
> You are right! The tag is issued when 'Testsuite: autopkgtest' was
> declared in d/control but no d/tests/control is present. [1] It should
> arguably be an error instead of info. [2]

I think there are three separate tags that would potentially be useful
in this general space, in decreasing order of severity:

1. (Testsuite: autopkgtest in d/control) && (no d/tests/control)

2. absence of autopkgtest coverage, declared correctly
   (no Testsuite and no d/tests/control)

3. there is autopkgtest coverage but it is all marked as superficial

I think the first of those is the new missing-tests-control, and I would
agree with making it an error. It's a contradiction between related
source files: d/control says there is a test suite, but (the absence of)
d/tests/control says there is not, and only one of those can be true.

I think the second of those is the old testsuite-autopkgtest-missing,
which apparently no longer exists. Saying that testsuite-autopkgtest-missing
is an old name for the new missing-tests-control seems inaccurate?

The third of those is the new superficial-tests.

> Lintian does not currently complain when no test suite is present. As
> you noted, some sources like GNOME shell extensions are essentially
> impossible to test.

I don't think it makes sense for the new superficial-tests to be considered
worse (= higher severity) than the old testsuite-autopkgtest-missing.
If the old testsuite-autopkgtest-missing is not serious enough to justify
even an info-level lintian tag, then neither is superficial-tests.

Conversely, if superficial-tests is serious enough to justify a lintian
tag, then testsuite-autopkgtest-missing should be a lintian tag of equal
or higher severity, because it's a strictly lower level of test coverage
than superficial-tests.

If you think these should not emit maintainer-facing tags, to avoid
"noise" for the maintainers of packages where autopkgtest coverage is not
feasible to implement, then perhaps they should be classification tags?

smcv

Bug#994050: linux-image-5.10.0-8-amd64: Hauppauge WinTV-HVR1110 DVB-T/Hybrid bug 125 ms polling on ir-kbd-i2c.ko bad DEFAULT_POLLING_INTERVAL

[Joaquín Alberto Calderón Pozo]

Thanks for the aclarations, this misunderstanding are for English isn't my 
mother language.

I really apreciate your guide.

I just contacted to Upstream main mantainers (as you sugested) and let's see 
how this develop.

See ya!

From: Salvatore Bonaccorso  on behalf of 
Salvatore Bonaccorso 
Sent: Saturday, September 11, 2021 08:58
To: Joaquín Alberto Calderón Pozo 
Cc: 994...@bugs.debian.org <994...@bugs.debian.org>
Subject: Re: Bug#994050: linux-image-5.10.0-8-amd64: Hauppauge WinTV-HVR1110 
DVB-T/Hybrid bug 125 ms polling on ir-kbd-i2c.ko bad DEFAULT_POLLING_INTERVAL

Hi!

On Sat, Sep 11, 2021 at 02:18:30AM +, Joaquín Alberto Calderón Pozo wrote:
> Hi Salvatore.
>
> As I mentioned early, I am newbie in reporting bugs and your help is
> much appreciated.
>
> It is the first time I report a bug, and as you noticed I don't know
> where to start, this is the reason I read the debian documentation
> and using the reportbug program.
>
> As after what you've told me it doesn't seem to be a downstream
> issue, I will investigate and further report in upstream and sorry
> for the inconveniences.

First of all, don't worry it was not to "push back" you in any way.
Thinking of what you reported I was just stating that this should be
turned directly to upstream.

You did already a good analysis tracking down where you see the
problem, and even if the patch you apply might not be the "real"
solution it gives the maintainers maybe th right hint. You did already
a great start on this trying to track down hwere you see the issue.

The get_maintainers.pl script in the linux (upstream) sources gives
the possibility to find the "correct" persons to contact.

So this would be my suggestion to contact Mauro Carvalho Chehab and
the respective linux-media lists.

Thanks for reporting!

Regards,
Salvatore

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

On 2021-09-12 02:07 PM, Guilhem Moulin wrote:

On Sun, 12 Sep 2021 at 13:02:41 -0400, Steve Dondley via
Pkg-roundcube-maintainers wrote:

That said, there must still be a bug because roundcube is supposed to
remember the search scope feature from the $_SESSION variable and it's 
not
doing that. Looking at the PHP code, roundcube is most certainly 
intended to

has this ability. If you manually refresh the page after selecting a
different folder the setting does, in fact, kick in.

The $_SESSION variable for search_scope gets ignored and overridden by 
some
javascript. And replacing app.min.js with app.js fixes the problem. 
Why that

fixes the problem, I have no earthly idea.


I can't reproduce this in a clean Bullseye chroot.  Removed app.min.js
so the non-minified version is used instead, but I still have to reload
the page to prefill the search dialog with Scope=all.  Does your app.js
matches what we shipped in roundcube-core?  DEBIAN/md5sums snippet:

b4865d6536b9188b7f5c3ae0361a1cb5  
usr/share/roundcube/program/js/app.js
7a0c881ca3e9cbff512853fcdb8e6650  
usr/share/roundcube/program/js/app.min.js

4f3ace3cd9376165005b754226ca1bd8
usr/share/roundcube/program/js/app.min.js.gz
5b9f0a46d6913f9b3481fece00930cd9
usr/share/roundcube/program/js/app.min.js.map


They all match except for app.js. I did modify it when troubleshooting 
the problem but I'm pretty sure i reverted everything back.


What's the easiest way to get my hands on the original file from the 
package?

Bug#991967: #991967: Simply ACPI powerdown/reset issue?

[Elliott Mitchell]

On Sat, Sep 11, 2021 at 01:29:12PM +0200, Salvatore Bonaccorso wrote:
> On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
> > An experiment lead to a potential alternative explanation for #991967.
> > The issue may be ACPI (non-UEFI) powerdown/reset was broken at
> > 4.19.194-3.  Presence of Xen on the system may be unrelated.
> > 
> > Failing that, it could be Xen and non-UEFI systems are effected.  (Xen
> > was tried on a UEFI system and the issue wasn't observed)
> 
> Following up on https://bugs.debian.org/991967#12
> 
> Did you succeeded in bisecting the issue as you seem to have it
> reproducible?

Problem is that is rather a lot of kernel builds, which also means a lot
of downtime...   Right now distribution update seems worthy of greater
attention.

The one notable bit is the one I sent in the last message.  The system
does NOT have UEFI, and a test system with UEFI seemed to have no
problem.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#973850: lilo: Should not be included in bullseye

[Simon McVittie]

On Fri, 06 Nov 2020 at 00:32:22 +0100, Joachim Wiedorn wrote:
> I am maintainer and developer of lilo, but have closed
> development with version 24.2 in year 2016. Since this time some people
> wanted to overtake development, but didn't do it after all.
...
> Because of this items, I register a RC bug on the package to ensure it stay
> out of bullseye. The Debian release team is informed.

Now that bullseye has been released, should lilo be removed from unstable
so that it will not be in any future Debian release either?

If so, the way to do that is to report a RM bug against the ftp.debian.org
pseudo-package. I can help with this if you would like.

smcv

Bug#994157: ntp: I cannot start a local network dedicated NTP server for some reason. Previosly I had working server. all clients receive 10.19.10.1: Server dropped: strata too high.

[richman1000000]

Package: ntp
Version: 1:4.2.8p12+dfsg-4
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages ntp depends on:
ii  adduser3.118
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libedit2   3.1-20181209-1
ii  libopts25  1:5.18.12-4
ii  libssl1.1  1.1.1d-0+deb10u7
ii  lsb-base   10.2019051400
ii  netbase5.6
ii  tzdata 2021a-0+deb10u1

Versions of packages ntp recommends:
ii  perl  5.28.1-6+deb10u1
ii  sntp  1:4.2.8p12+dfsg-4

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/ntp.conf changed:
driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst
restrict default
restrict 10.19.10.0  mask 255.255.255.224   nomodify notrap
restrict 127.0.0.1
restrict ::1
logfile /var/log/ntp.log


-- no debconf information

Bug#967445: golang-github-mattn-go-gtk: depends on deprecated GTK 2

[Drew Parsons]

Source: golang-github-mattn-go-gtk
Followup-For: Bug #967445

I don't see any movement upstream to port go-gtk to gtk-3 (or gtk-4).
Probably go-gtk should be considered strictly as a GTK-2 client.

I packaged golang-github-mattn-go-gtk since it was required by
golang-github-anacrolix-dms, but dms was updated soon after packaging
was done.

So we don't need golang-github-mattn-go-gtk any more.
Perhaps the simplest thing is to just remove it altogether.

Drew

Bug#980692: dask: FTBFS: dh_sphinxdoc: error: debian/python-dask-doc/usr/share/doc/python-dask-doc/html/_static/js/html5shiv.min.js is missing

[Drew Parsons]

Source: dask
Followup-For: Bug #980692

There's no actual close tag for the BTS Control server, so it didn't
close the bug from the control line. I think we need to use the
980692-d...@bugs.debian.org address to close the bug if the tag was
missing in the changelog.

Drew

Bug#630880: chkrootkit: Patch for 630880

[Richard Lewis]

Package: chkrootkit
Version: 0.54-1+b2
Tags: patch
Followup-For: Bug #630880
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

Please consider the attached patch that fixes this bug

The patch
- improves the filtering for /etc/cron.daily/chkrootkit
   by expanding the list of 'allowed' packet sniffers to include
 wpa_supplicant, dhcpcd, etc
- quotes more variables
- makes tabs consistent
- includes stderr in the output (just in case)

Thanks for considering

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

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

Versions of packages chkrootkit depends on:
ii  binutils   2.35.2-2
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13
ii  net-tools  1.60+git20181103.0eebece-1
ii  openssh-client 1:8.4p1-5
ii  procps 2:3.3.17-5

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- Configuration Files:
/etc/cron.daily/chkrootkit changed [not included]

-- debconf information:
* chkrootkit/run_daily_opts: -q
* chkrootkit/diff_mode: true
* chkrootkit/run_daily: true
--- etc.cron.daily.chkrootkit.orig  2021-09-12 22:04:13.087114719 +0100
+++ etc.cron.daily.chkrootkit.new   2021-09-12 22:12:57.534539024 +0100
@@ -7,45 +7,74 @@
 LOG_DIR=/var/log/chkrootkit
 IGNORE_FILE=/dev/null
 
-if [ ! -x $CHKROOTKIT ]; then
-  exit 0
+if [ ! -x "$CHKROOTKIT" ]; then
+   exit 0
 fi
 
-if [ -f $CF ]; then
-. $CF
+if [ -f "$CF" ]; then
+   . "$CF"
 fi
 
-if [ ! -r "${IGNORE_FILE}" ]; then
- IGNORE_FILE=/dev/null
+if [ ! -r "$IGNORE_FILE" ]; then
+   IGNORE_FILE=/dev/null
 fi
 
+if [ "${RUN_DAILY-false}" = "true" ]; then
+   if [ "${DIFF_MODE-false}" = "true" ]; then
+   case "${RUN_DAILY_OPTS-}" in
+   # if '-q' is used then the first line is blank and the
+   # second is a list of files containing a '.': we add 
back
+   # the description and convert from a space-separated 
list
+   # to a new-line separated one.  filter_with_sed is used 
below
+   *q*)
+   filter_with_sed(){
+   sed -r \
+   -e '1cThe following suspicious 
files and directories were found' \
+   -e '2s/ /\n/g' "$@"
+   }
+   ;;
+   *)
+   filter_with_sed(){
+   sed -r "$@"
+   }
+   ;;
+   esac
 
-if [ "$RUN_DAILY" = "true" ]; then
-if [ "$DIFF_MODE" = "true" ]; then
-   eval $CHKROOTKIT $RUN_DAILY_OPTS 2>&1 | egrep 
-v -f "${IGNORE_FILE}" > $LOG_DIR/log.today || true
-if [ ! -f $LOG_DIR/log.expected ]; then
-   echo "ERROR: No file 
$LOG_DIR/log.expected"
-   echo "This file should contain 
expected output from chkrootkit"
-   echo
-   echo "Today's run produced the 
following output:"
-   echo "--- [ BEGIN: cat 
$LOG_DIR/log.today  ] ---"
-   cat $LOG_DIR/log.today
-   echo "--- [ END: cat 
$LOG_DIR/log.today ] ---"
-   echo
-   echo "To create this file 
containing all output from today's run, do (as root)"
-   echo "# cp -a 
$LOG_DIR/log.today $LOG_DIR/log.expected"
-   elif ! diff -q $LOG_DIR/log.expected 
$LOG_DIR/log.today > /dev/null 2>&1; then
-   echo "ERROR: chkrootkit output 
was not as expected."
-   echo
-   echo "The difference is:"
-   echo "---[ BEGIN: diff -u 
$LOG_DIR/log.expected $LOG_DIR/log.today ] ---"
-   diff -u $LOG_DIR/log.expected 
$LOG_DIR/log.today || true
-   echo "---[ END: diff -u 
$LOG_DIR/log.expected $LOG_DIR/log.today ] ---"
-   echo
-   echo "To update the 

Bug#994156: RM: libindicator -- RoQA; superseded by libayatana-indicator, not in bullseye, no rdeps

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sunwea...@debian.org
Control: block -1 by 994155

libindicator was removed from testing in December, and it was not released
in bullseye. It's considered obsolete (see #895038), has been superseded
by libayatana-indicator, and is unmaintained. All Debian packages that
depended on it have been removed or ported to libayatana-indicator,
except for libappindicator, whose removal I requested today (#994155).

As with libappindicator, I think it's time to remove src:libindicator.

Thanks,
smcv

Bug#994155: RM: libappindicator -- RoQA; superseded by libayatana-appindicator, not in bullseye, no rdeps

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sunwea...@debian.org

libappindicator was removed from testing in December, and it was not
released in bullseye. It's considered obsolete (see #895037), has
been superseded by libayatana-appindicator, and is unmaintained. All
Debian packages that depended on it have been removed or ported to
libayatana-appindicator.

I think it's time we remove src:libappindicator.

Thanks,
smcv

Bug#994154: ITP: obs-scene-switcher -- plugin for OBS Studio to improve the native scene switcher

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, warmupt...@web.de

* Package name: obs-scene-switcher
  Version : 1.15.3
  Upstream Author : WarmUpTill 
* URL : 
https://obsproject.com/forum/resources/advanced-scene-switcher.395/
* License : GPL-2
  Programming Lang: C++
  Description : plugin for OBS Studio to improve the native scene switcher

 Advanced Scene Switcher plug-in is based on the built in scene switcher. It
 extends its functionality by adding the following:
 .
   - Audio based scene switching (Audio tab).
   - Media based scene switching (Media tab).
   - System time based scene switching (Time tab).
   - Sequence of automated scene switches (Scene Sequence tab).
   - Cursor position based scene switching (Region).
   - The option to switch to a scene after detection of being idle (Idle tab).
   - Executable based scene switching (Executable tab).
   - File content based scene switching (File).
   - Improvements for the window title based scene switching (full-screen /
 maximized detection, ignore windows).
   - The ability select a different transition for each automated switch case
 (Transitions tab).
   - Automatically pause the scene switcher based on scene or window title
 hotkey to start and stop the scene switcher.
   - Trigger actions on scene change.
   - and more ...

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

Also what makes you think this setting should work?  It's not 
documented

AFAICT, but the way to control default search fields is controlled by
‘$config['search_mods']’ but per
https://github.com/roundcube/roundcubemail/issues/7556
“doesn't work for scope”.  That upstream issue is still open and the PR
implementing this was never merged in:
https://github.com/roundcube/roundcubemail/pull/5209 .


OK, so it looks like what happened is I must hacked in that patch to the 
1.3 version many moons ago to get that functionality working and that 
bit of code in the config file is some cruft left over. My server was 
recently upgraded to bullseye. The upgrade broke my hack.


That said, there must still be a bug because roundcube is supposed to 
remember the search scope feature from the $_SESSION variable and it's 
not doing that. Looking at the PHP code, roundcube is most certainly 
intended to has this ability. If you manually refresh the page after 
selecting a different folder the setting does, in fact, kick in.


The $_SESSION variable for search_scope gets ignored and overridden by 
some javascript. And replacing app.min.js with app.js fixes the problem. 
Why that fixes the problem, I have no earthly idea.

Bug#994139: lintian: warning about superficial autopkgtests is counterproductive

[Felix Lechner]

Hi,

On Sun, Sep 12, 2021 at 1:17 PM Simon McVittie  wrote:
>
> If that's the case, I would have expected it to be emitted for packages
> that have absolutely no autopkgtest coverage

You are right! The tag is issued when 'Testsuite: autopkgtest' was
declared in d/control but no d/tests/control is present. [1] It should
arguably be an error instead of info. [2]

Lintian does not currently complain when no test suite is present. As
you noted, some sources like GNOME shell extensions are essentially
impossible to test. Also, some long-time contributors reportedly
dislike autopkgtest. Either way, the project relies here on the fact
that having a meaningful testsuite may provide a faster migration from
unstable to testing.

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Testsuite.pm#L89-91
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/m/missing-tests-control.tag

Bug#994153: chkrootkit: bashism resulting in spurious '-e' in output

[Richard Lewis]

Package: chkrootkit
Version: 0.54-1+b2
Severity: normal
Tags: patch
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

Line 814 of /usr/sbin/chkrootkit assumes the shell is bash, and 
passes '-e' to echo - this is not supported by POSIX and I get a
spurious '-e' in the output of the cron job. (checkbashisms(1)
also spots this)

The attached patch removes the '-e' (and fixes the tabs)

thanks for considering






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

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

Versions of packages chkrootkit depends on:
ii  binutils   2.35.2-2
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13
ii  net-tools  1.60+git20181103.0eebece-1
ii  openssh-client 1:8.4p1-5
ii  procps 2:3.3.17-5

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- Configuration Files:
/etc/cron.daily/chkrootkit changed [not included]

-- debconf information excluded
--- usr.sbin.chkrootkit.orig2021-07-25 19:48:31.0 +0100
+++ usr.sbin.chkrootkit.new 2021-09-12 21:20:26.753997683 +0100
@@ -811,7 +811,7 @@
 outmsg="${files}\n${dirs}"
fi
   if [ "${QUIET}" = "t" -a "$outmsg" ]; then
-echo -e "The following suspicious files and directories were 
found:\n\n $outmsg"
+   echo "The following 
suspicious files and directories were found:\n\n $outmsg"
   fi
fi
 

Bug#994152: ca-certificates fails foreign installation: doesn't know about openjdk-18

[Helmut Grohne]

Package: ca-certificates-java
Version: 20190909
Severity: important
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:astyle

ca-certificates-java.postinst currently fails when installing
default-jdk for a foreign architecture. The situation picks different
openjdk versions for native and foreign. In particular, the native one
tends to be openjdk-18, which is missing in
ca-certificates-java.postinst. Example failure:

| Setting up ca-certificates-java (20190909) ...
| head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file or 
directory
| /usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.
| /var/lib/dpkg/info/ca-certificates-java.postinst: line 101: java: command not 
found
| dpkg: error processing package ca-certificates-java (--configure):
|  installed ca-certificates-java package post-installation script subprocess 
returned error exit status 127

I guess that adding openjdk-18 support to the postinst fixes this, but I
haven't verified.

The failure can be reproduced as follows:

mmdebstrap --variant=apt --architectures=amd64,ppc64el 
--include=default-jdk:ppc64el sid /dev/null

Helmut

Bug#994151: youtube-dl: the youtube-dl project seams to have died

[michel]

Package: youtube-dl
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,

the youtube-dl project seams to have died.
There was no new release since 6/6/2021
The last commit was on 1 of Jully.
This delay is very long for this project.
A partial solution for downloading age restricted videos
from youtube was found, but it still isn't implemented.
It doesn't seam to be a legal threat.
The devs haven't given any statement. 

It seams unlikely that it will come back to life.
People seam to be moving to the yt-dlp fork.
https://github.com/yt-dlp/yt-dlp

The proposed solution: is to package and backport yt-dlp
and wait a little longer before completly replacing
youtube-dl with yt-dlp

Bug#994138: kernel command line (grub) UUID=... and PARTUUID=... Can not mount on filesystem /run/live/rootfs/filesystem since Debian bullseye

[Patrick Schleizer]

Package: live-boot
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

the following is a regression in Debian bullseye. No such issue in
Debian buster.

Kernel command line 'debug=1' shows that live-boot attempts to run the
following mount command:

mount -t -o ro,noatime 'PARTUUID=41414141-01' /run(live/rootfs/filesystem

That is an invalid syntax and mount with show usage information and exit
non-zero.

Above is happening because following syntax in /boot/grub/grub.cfg /
kernel command line is broken by live-boot:

linux   /boot/vmlinuz-5.10.0-8-amd64 root=PARTUUID=41414141-01 ro

Also broken:

linux   /boot/vmlinuz-5.10.0-8-amd64
root=UUID=26ada0c0-1165-4098-884d-aafd2220c2c6

In that case, live-boot attempts to run:

mount -t -o ro,noatime 'UUID=26ada0c0-1165-4098-884d-aafd2220c2c6'
/run/live/rootfs/filesystem

Functional:

linux   /boot/vmlinuz-5.10.0-8-amd64
root=/dev/disk/by-uuid/26ada0c0-1165-4098-884d-aafd2220c2c6 ro

The bug might be somewhere inside this source file:

https://salsa.debian.org/live-team/live-boot/-/blob/master/components/9990-overlay.sh

9990-overlay.sh doesn't seem to understand root=UUID= and PARTUUID=
syntax anymore?

Probably non-issues: I am sure my root=UUID= and PARTUUID= is correct
because 1) I confirmed those using "sudo bklid" and 2) my system is
bootable in non-live (persistent mode). (Using grub-live [1] config.)

Kind regards,
Patrick

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

Bug#994139: lintian: warning about superficial autopkgtests is counterproductive

[Simon McVittie]

On Sun, 12 Sep 2021 at 12:48:36 -0700, Felix Lechner wrote:
> On Sun, Sep 12, 2021 at 11:09 AM Simon McVittie  wrote:
> >
> > lintian has recently started emitting warnings for packages that
> > have autopkgtests, but only superficial autopkgtests.
> 
> The tag was implemented in response to Bug#932870. [1] It was
> originally suggested on OFTC#debci by dkg (who was copied here). I
> never heard back whether my implementation met the original intent.
> The tag originally had the info visibility, but was later upgraded to
> a warning. [2]

To be clear, I think this tag would have been fine as originally
implemented; it's the subsequent increase of severity from pedantic
to warning that I think is counterproductive.

I think a package with correctly-marked superficial autopkgtests,
like libsdl2-mixer 2.0.4+dfsg1-3, is better than a package with no
autopkgtests at all, like libsdl2-mixer 2.0.4+dfsg1-2. As a result,
to avoid giving maintainers wrong incentives, I think the Lintian tags
emitted for 2.0.4+dfsg1-3 should be of equal or lower severity.

> > the meaning of
> > testsuite-autopkgtest-missing might have changed at some point so that it
> > is only emitted for packages that have debian/tests/control, rather than
> > for all packages that lack autopkgtests?
> 
> Maybe a word is missing? The tag 'testsuite-autopkgtest-missing' was
> renamed to 'missing-tests-control' and is issued at the info level
> when sources do NOT ship debian/tests/control (or declare a predefined
> test suite in d/control, usually for teams). [3]

If that's the case, I would have expected it to be emitted for packages
that have absolutely no autopkgtest coverage, such as
gnome-shell-extension-caffeine. In the past, I think I saw
testsuite-autopkgtest-missing emitted for that package, but at the moment,
the replacement tag missing-tests-control is not emitted. Should it be?

The missing-tests-control description now says:

The source package declares the generic Testsuite: autopkgtest
field but provides no debian/tests/control file.

but packages like gnome-shell-extension-caffeine that don't have any
tests at all will not usually have a Testsuite field. If the intention
was for this tag to detect packages with zero test coverage, then it
should also be emitted for packages with no Testsuite.

GNOME shell extensions are probably a convenient example to use when
evaluating "you have no tests" tags, because they are unlikely to
get meaningful test coverage: they're essentially impossible to test
without using something like openQA, which would be a lot of effort
and inconveniently likely to fail as a result of changes that are
not actually bugs, and it isn't obvious how it would fit into the
autopkgtest framework even if someone has the time to implement it. I
think if we get test coverage for desktop environments, it would be more
likely to be a separate, parallel GUI-testing infrastructure alongside
autopkgtest.

smcv

Bug#994150: licensecheck FTBFS: test failures

[Adrian Bunk]

Source: licensecheck
Version: 3.2.12-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=licensecheck=all=3.2.12-1=1630869568=0

...
# locale encoding: UTF-8
# executable: blib/script/licensecheck
# Failed test 'Testing stdout'
# at t/encoding.t line 57.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-utf8.h\tGNU G | eq | t/encoding/copr-utf8.h\tGNU G |
# | eneral Public License v2.0 or || eneral Public License v2.0 or |
# |  later\t2004-2015 Oliva 'f00' ||  later\t2004-2015 Oliva 'f00' |
# |  Oberto / 2001-2010 Paul 'bar ||  Oberto / 2001-2010 Paul 'bar |
# +---++---+

# Failed test 'Latin-1 in UTF-8 parsed by default returns mojibake'
# at t/encoding.t line 59.
# Failed test 'Testing stdout'
# at t/encoding.t line 62.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-utf8.h\tGNU G | eq | t/encoding/copr-utf8.h\tGNU G |
# | eneral Public License v2.0 or || eneral Public License v2.0 or |
# |  later\t2004-2015 Oliva 'f00' ||  later\t2004-2015 Oliva 'f00' |
# |  Oberto / 2001-2010 Paul 'bar ||  Oberto / 2001-2010 Paul 'bar |
# +---++---+

# Failed test 'Latin-1 in UTF-8 parsed by guessing returns chars'
# at t/encoding.t line 64.
# Failed test 'Testing stdout'
# at t/encoding.t line 79.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-iso8859.h\tGN | eq | t/encoding/copr-iso8859.h\tGN |
# | U General Public License, Ver || U General Public License, Ver |
# | sion 2 [obsolete FSF postal a || sion 2 [obsolete FSF postal a |
# | ddress (Temple Place)]\t2011  || ddress (Temple Place)]\t2011  |
# | Heinrich M\n  || Heinrich Müller \n |
# +---++---+

# Failed test 'Latin-1 in ISO 8859-1 parsed by default returns chars'
# at t/encoding.t line 81.
# Failed test 'Testing stdout'
# at t/encoding.t line 85.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/copr-iso8859.h\tGN | eq | t/encoding/copr-iso8859.h\tGN |
# | U General Public License, Ver || U General Public License, Ver |
# | sion 2 [obsolete FSF postal a || sion 2 [obsolete FSF postal a |
# | ddress (Temple Place)]\t2011  || ddress (Temple Place)]\t2011  |
# | Heinrich M\n  || Heinrich Müller \n |
# +---++---+

# Failed test 'Latin-1 in ISO 8859-1 parsed by guessing returns chars'
# at t/encoding.t line 87.
# Failed test 'Testing stdout'
# at t/encoding.t line 102.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/README.gs550j\tUNK | eq | t/encoding/README.gs550j\tUNK |
# | UKI.\n|| u.ac.jp) / 1999 Norihito Ohmo |
# |   || ri. / 1996-1999 Daisuke SUZUK |
# |   || I.\n  |
# +---++---+

# Failed test 'CJK in EUC-JP parsed by default returns mojibake and warns'
# at t/encoding.t line 104.
# Failed test 'Testing stdout'
# at t/encoding.t line 107.
# +---++---+
# | GOT   | OP | CHECK |
# +---++---+
# | t/encoding/README.gs550j\tUNK | eq | t/encoding/README.gs550j\tUNK |
# | UKI.\n|| u.ac.jp) / 1999 Norihito Ohmo |
# |   || ri. / 1996-1999 Daisuke SUZUK |
# |   || I.\n  |
# +---++---+

# Failed test 'CJK in 

Bug#892058: Your Debian key is expiring

[Vagrant Cascadian]

On 2021-08-22, felix.lech...@lease-up.com wrote:
> This is a courtesy reminder that your Debian key is expiring on 2021-09-12.
...
> If you like this service, please leave a favorable comment here [2].
> Thank you!

Thanks for the reminders!

Now I just need to time my future expiry closer to the keyring-maint
cycle to minimize the risk of downtime... :)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#994148: jalview: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: jalview 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of jalview debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#994099: twclock: improve .desktop file

[Daniele Forsi]

Ervin Hegedüs wrote:

> this was the lintian tag why I removed the Exec:
>
> https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file

that lintian pages tells to remove the menu file
/usr/share/menu/twclock not the Exec line

-- 
73 de IU5HKX Daniele

Bug#994147: bullseye-pu: package libavif/0.8.4-2+deb11u1

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
X-Debbugs-Cc: by...@debian.org
Severity: normal

Dear Debian Release Team,

I am proposing a bullseye-pu upload to fix Debian bug
https://bugs.debian.org/994144 .


[ Reason ]


In current version of libavif-dev/0.8.4-2 (shipped in Debian 11), the
/usr/lib//pkgconfig/libavif.pc file has the following content:


prefix=/usr
exec_prefix=${prefix}/bin
libdir=${prefix}/lib
includedir=${prefix}/include

Name: libavif
Description: Library for encoding and decoding .avif files
Version: 0.8.4
Libs: -L${libdir} -lavif
Cflags: -I${includedir}


...where libdir should be ${prefix}/@CMAKE_INSTALL_LIBDIR@
(@CMAKE_INSTALL_LIBDIR@ will be replaced by arch triplet during compilation).
This will make packages that build-depend on libavif-dev to receive wrong -
L{libdir} parameter during compilation, and may incur FTBFS.

Libavif fixed this issue in v0.9.2 release. I am looking to backport this
certain patch
https://github.com/AOMediaCodec/libavif/commit/c6acdf6b7c69c9d23917cf814a3b17ce639a7266
into libavif in Debian 11.


[ Impact ]
Users that uses on libavif library through pkg-config in Debian 11 may fail to
build from source due to wrong compilation parameters.

[ Tests ]
Manually tested by myself.

[ Risks ]
Minimal. The patch is already present in latest upstream release (v0.9.2) as
well as libavif in Debian Testing / Debian Unstable.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Upstream fix can be found as
https://github.com/AOMediaCodec/libavif/commit/c6acdf6b7c69c9d23917cf814a3b17ce639a7266.patch
.

[ Other info ]
Full debdiff provided in attachment.

diff -Nru libavif-0.8.4/debian/changelog libavif-0.8.4/debian/changelog
--- libavif-0.8.4/debian/changelog	2020-12-07 13:52:51.0 -0500
+++ libavif-0.8.4/debian/changelog	2021-09-12 15:54:48.0 -0400
@@ -1,3 +1,11 @@
+libavif (0.8.4-2+deb11u1) bullseye; urgency=medium
+
+  * debian/patches/c6acdf6b7c69c9d23917cf814a3b17ce639a7266.patch:
+Add upstream fix to correct libdir in libavif.pc pkgconfig file.
+(Closes: #994144)
+
+ -- Boyuan Yang   Sun, 12 Sep 2021 15:54:48 -0400
+
 libavif (0.8.4-2) unstable; urgency=medium
 
   * Source-only upload. 
diff -Nru libavif-0.8.4/debian/patches/c6acdf6b7c69c9d23917cf814a3b17ce639a7266.patch libavif-0.8.4/debian/patches/c6acdf6b7c69c9d23917cf814a3b17ce639a7266.patch
--- libavif-0.8.4/debian/patches/c6acdf6b7c69c9d23917cf814a3b17ce639a7266.patch	1969-12-31 19:00:00.0 -0500
+++ libavif-0.8.4/debian/patches/c6acdf6b7c69c9d23917cf814a3b17ce639a7266.patch	2021-09-12 15:39:30.0 -0400
@@ -0,0 +1,23 @@
+From c6acdf6b7c69c9d23917cf814a3b17ce639a7266 Mon Sep 17 00:00:00 2001
+From: Mike Frysinger 
+Date: Thu, 4 Mar 2021 21:20:33 -0500
+Subject: [PATCH] libavif.pc: respect libdir setting
+
+Do not hardcode "lib" as that is often the wrong path with multilib.
+On an x86_64 system for example, it should actually be "lib64".
+---
+ libavif.pc.cmake | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libavif.pc.cmake b/libavif.pc.cmake
+index 006539b1..4ef2c8a9 100644
+--- a/libavif.pc.cmake
 b/libavif.pc.cmake
+@@ -1,6 +1,6 @@
+ prefix=@CMAKE_INSTALL_PREFIX@
+ exec_prefix=${prefix}/bin
+-libdir=${prefix}/lib
++libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
+ includedir=${prefix}/include
+ 
+ Name: @PROJECT_NAME@
diff -Nru libavif-0.8.4/debian/patches/series libavif-0.8.4/debian/patches/series
--- libavif-0.8.4/debian/patches/series	2020-11-10 10:09:03.0 -0500
+++ libavif-0.8.4/debian/patches/series	2021-09-12 15:39:39.0 -0400
@@ -1 +1,2 @@
 0001-Use-system-cJSON-library.patch
+c6acdf6b7c69c9d23917cf814a3b17ce639a7266.patch


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

Bug#994146: Debian 11 iwlwifi fail to load microcode

[Thomas Fazekas]

Package: firmware-iwlwifi
Version : 20210315-3
OS version : 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64
GNU/Linux (Bullseye)
Affected hardware : Intel(R) Dual Band Wireless N 7260 (rev 6b)

After upgrading to Debian Bullseye the system fails to bring up wlan0

Related dmesg log :
[8.161363] iwlwifi :3d:00.0: enabling device ( -> 0002)
[8.171390] iwlwifi :3d:00.0: firmware: direct-loading firmware
iwlwifi-7260-17.ucode
[8.171666] iwlwifi :3d:00.0: loaded firmware version
17.3216344376.0 7260-17.ucode op_mode iwlmvm
[8.171689] iwlwifi :3d:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)
[8.241108] iwlwifi :3d:00.0: Detected Intel(R) Dual Band Wireless N
7260, REV=0x144
[   13.320241] iwlwifi :3d:00.0: Failed to load firmware chunk!
[   13.320246] iwlwifi :3d:00.0: iwlwifi transaction failed, dumping
registers
[   13.320248] iwlwifi :3d:00.0: iwlwifi device config registers:
[   13.320512] iwlwifi :3d:00.0: : 08b18086 00100406 0280006b
0010 cc14   
[   13.320514] iwlwifi :3d:00.0: 0020:   
c0608086  00c8  0100
[   13.320515] iwlwifi :3d:00.0: 0040: 00020010 10008ec0 00130c10
0106ec11 101100ca   
[   13.320517] iwlwifi :3d:00.0: 0060:  00080812 0405
 00010001   
[   13.320518] iwlwifi :3d:00.0: 0080:   
    
[   13.320520] iwlwifi :3d:00.0: 00a0:   
    
[   13.320522] iwlwifi :3d:00.0: 00c0:   c823d001
0d00 00814005 fee003f8  
[   13.320523] iwlwifi :3d:00.0: 00e0:   
    
[   13.320525] iwlwifi :3d:00.0: 0100: 14010001 4000 
00462031 2000 2000 000e 
[   13.320526] iwlwifi :3d:00.0: 0120:   
    
[   13.320528] iwlwifi :3d:00.0: 0140: 14c10003 ffbb884d 104a7dff
15410018 08460846 0001000b 0141cafe 00f01e1f
[   13.320529] iwlwifi :3d:00.0: iwlwifi device memory mapped registers:
[   13.320581] iwlwifi :3d:00.0: : 40489204 8040 2000
0800    
[   13.320583] iwlwifi :3d:00.0: 0020: 0009 080003c5 0144
 8000 803a 80008040 00080046
[   13.320587] iwlwifi :3d:00.0: iwlwifi device AER capability
structure:
[   13.320620] iwlwifi :3d:00.0: : 14010001 4000 
00462031 2000 2000 000e 
[   13.320621] iwlwifi :3d:00.0: 0020:   
[   13.320623] iwlwifi :3d:00.0: iwlwifi parent port (:3c:01.0)
config registers:
[   13.320760] iwlwifi :3c:01.0: : 240412d8 00180407 06040005
00010010   003d3d3c 01f1
[   13.320762] iwlwifi :3c:01.0: 0020: cc10cc10 0001fff1 
  0040  000201ff
[   13.320763] iwlwifi :3c:01.0: 0040: ffc34c01 0008 
00816405 fee002d8   
[   13.320765] iwlwifi :3c:01.0: 0060:  0034b009 04001060
04000800 8000 0a730100 76b50080 21901d27
[   13.320766] iwlwifi :3c:01.0: 0080: 000f  3308
00790010 8000 116b 000f0022 
[   13.320768] iwlwifi :3c:01.0: 00a0:   
 c00d 240412d8  
[   13.320769] iwlwifi :3c:01.0: 00c0: 00620010 8001 0010
01203c11 10110042  014803c0 
[   13.320771] iwlwifi :3c:01.0: 00e0:  00040800 0400
 00010042   
[   13.320772] iwlwifi :3c:01.0: 0100: 14010001  
00062011  2000 00a0 
[   13.320774] iwlwifi :3c:01.0: 0120:   
    
[   13.320775] iwlwifi :3c:01.0: 0140: 20c10002 0801 0300
 047f0009 8001  087f0019
[   13.320777] iwlwifi :3c:01.0: 0160: 0100  
    
[   13.320778] iwlwifi :3c:01.0: 0180:   
    
[   13.320780] iwlwifi :3c:01.0: 01a0:   
    
[   13.320781] iwlwifi :3c:01.0: 01c0:   
    
[   13.320783] iwlwifi :3c:01.0: 01e0:   
    
[   13.320784] iwlwifi :3c:01.0: 0200:   
[   13.320788] iwlwifi :3d:00.0: Could not load the [0] uCode section

Bug#994139: lintian: warning about superficial autopkgtests is counterproductive

[Felix Lechner]

Hi,

On Sun, Sep 12, 2021 at 11:09 AM Simon McVittie  wrote:
>
> lintian has recently started emitting warnings for packages that
> have autopkgtests, but only superficial autopkgtests.

The tag was implemented in response to Bug#932870. [1] It was
originally suggested on OFTC#debci by dkg (who was copied here). I
never heard back whether my implementation met the original intent.
The tag originally had the info visibility, but was later upgraded to
a warning. [2]

> I think this is counterproductive.

Thank you for that pointer. This reply merely acknowledges your
filing. I am trying to reconstruct how users perceive the interaction
of these tags. Lintian hopes to offer middle-of-the-road advice.

> the meaning of
> testsuite-autopkgtest-missing might have changed at some point so that it
> is only emitted for packages that have debian/tests/control, rather than
> for all packages that lack autopkgtests?

Maybe a word is missing? The tag 'testsuite-autopkgtest-missing' was
renamed to 'missing-tests-control' and is issued at the info level
when sources do NOT ship debian/tests/control (or declare a predefined
test suite in d/control, usually for teams). [3]

Lintian also issues 'no-tests' for defective control stanzas [4] and
the somewhat specialized 'no-op-testsuite' for fakers [5]. The
relevant code with a few other tags is located here. [6]

I will likely respond with a suggested solution at some point in the
future. Meanwhile, comments are welcome!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/932870
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/cbf654cce71dd2ac294c82767963cc0507093d42
[3] 
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/m/missing-tests-control.tag
[4] https://salsa.debian.org/lintian/lintian/-/blob/master/tags/n/no-tests.tag
[5] 
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/n/no-op-testsuite.tag
[6] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Testsuite.pm

Bug#994145: ITP: mediawiki-extension-codemirror -- Syntax highlighting in MediaWiki's wikitext editor

[Taavi Väänänen]

Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 
X-Debbugs-Cc: debian-de...@lists.debian.org, lego...@debian.org

* Package name: mediawiki-extension-codemirror
  Version : 4.0.0
  Upstream Author : Pavel Astakhov 
* URL : https://www.mediawiki.org/wiki/Extension:CodeMirror
* License : GPL
  Programming Lang: PHP
  Description : Syntax highlighting in MediaWiki's wikitext editor

CodeMirror extension provides syntax highlighting in MediaWiki's
wikitext editor. It adds a button to the editing toolbar that allows
for switching syntax highlighting on and off. It supports the 2010
WikiEditor toolbar as well as the VisualEditor toolbar.

I am working on the packaging on [0].

[0]: https://salsa.debian.org/mediawiki-team/mediawiki-extension-codemirror



OpenPGP_signature
Description: OpenPGP digital signature

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Guilhem Moulin]

On Sun, 12 Sep 2021 at 15:10:18 -0400, Steve Dondley via 
Pkg-roundcube-maintainers wrote:
> On 2021-09-12 02:58 PM, Steve Dondley wrote:
>>> Here is my version of app.js:
>>> https://gist.github.com/sdondley/9db6dbffb8fb751c4afcd1092ab24fd0
>> 
>> Alright, so all confusion is from the fact that I did hack the app.js
>> file and did not revert it back to its original state as I thought. I
>> did make this change to app.js:
>> 
>> 2696c2696
>> <   this.env.search_scope = 'base';
>> ---
>>>this.env.search_scope = 'all';
>> 
>> This is a bug an upstream bug. Sorry to waste your time. Please close
>> this out. I will report this to roundcube project.
> 
> I'll know better next time that the files don't go directly into the package
> and are merely pulled from the source on github. Thanks for pointing this
> out.

No no, sorry for misleading you, the files *are* included in the
package, see `dpkg-deb -c /path/to/roundcube-core_1.4.11+dfsg.1-4_all.deb`.

There is no guaranty that we ship exact copies of what's found in
upstream releases, either: for instance we generate the .min.js files
ourselves, and have a handful of Debian-specific modifications on other
files.

I suggested GitHub as an easy way for you to get a copy of the file we
ship in our package, but it *only* works because we happen to ship the
*same* file (that's why I checked the digest earlier).  A reliable way
for arbitrary files/packages is to extract the content of the .deb:

   dpkg-deb --fsys-tarfile /path/to/roundcube-core_1.4.11+dfsg.1-4_all.deb \
   | tar -xOf- ./usr/share/roundcube/program/js/app.js

or if you want to replace the existing version:

   dpkg-deb --fsys-tarfile /path/to/roundcube-core_1.4.11+dfsg.1-4_all.deb \
   | tar -C/ -xf- ./usr/share/roundcube/program/js/app.js

But for *that file* downloading from the upstream repository is a valid
option and I thought it was also easier :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#839400: hplip: setup of HPLIP toolbox is faulty

[Brian Potkin]

On Sat 01 Oct 2016 at 09:00:39 -0400, WRMelgaard wrote:

> Package: hplip
> Version: 3.14.6-1+b2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> Previously installed version was done manually from HP website, decided to 
> use the Debian packag system for upgrade
> Using Synaptic, installed the hplip package. (also hplip-gui) Toolbox would 
> not execute from KDE menu or icon on panel.
> Discovered that the KDE menu points to /usr/bin/hp-toolbox, which is a link 
> to /usr/share/hplip, which does not appear to exist.
> Attempting to find hplip using Dolphin, a search from /usr/share for hplip 
> finds a folder hplip. However, opening a Dolphin window showing hidden files 
> does not reveal a folder /usr/share/hplip.

As OdyX says:

 > This is not a supported use-case

Closing.

Regards,

Brian.

Bug#994144: libavif-dev: Version in bullseye provides broken pkgconfig file (libdir wrong)

[Boyuan Yang]

Package: libavif-dev
Version: 0.8.4-2
Severity: important
Control: fixed -1 0.9.2-1

In libavif before v0.9.2, the pkgconfig file shipped by the library is broken
under multiarch setup due to hardcoding $prefix/lib/ as libdir.

This bug is fixed in libavif/0.9.2.

Thanks,
Boyuan Yang


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

Bug#989000: distutils: missing CFLAGS/LDFLAGS from environment

[Samuel Thibault]

Hello,

From: Debian FTP Masters 
>* Fix CFLAGS in the python3.x-config scripts. Closes: #992669, #989000.

Thanks for fixing CFLAGS!

However LDFLAGS are still missing:

Samuel Thibault, le sam. 22 mai 2021 23:10:16 +0200, a ecrit:
> blhc also notices that LDFLAGS is not getting included:
> 
> https://salsa.debian.org/a11y-team/brltty/-/jobs/1660079
> 
> 2438:LDFLAGS missing (-Wl,-z,now): x86_64-linux-gnu-gcc -pthread -shared 
> -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-z,relro -g 
> -fwrapv -O2 -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 ./../../../Bindings/Python/bindings.o ./brlapi.auto.o 
> -L./../../Programs -lbrlapi -lpthread -o 
> build/lib.linux-x86_64-3.9/brlapi.cpython-39-x86_64-linux-gnu.so

That is still the case, see for instance:

https://salsa.debian.org/a11y-team/brltty/-/jobs/1938826

Samuel

Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

[Simon McVittie]

On Sat, 11 Sep 2021 at 18:29:41 +0100, Simon McVittie wrote:
> On Sat, 11 Sep 2021 at 18:50:05 +0200, Sebastian Ramacher wrote:
> > Unless netatalk is a blocker, let's go ahead with mutter.
> 
> Thanks, I'll start this transition today.

I've uploaded:

- gnome-control-center
- gnome-desktop3
- gnome-remote-desktop
- gnome-settings-daemon
- gnome-shell
- gnome-shell-extensions
- gsettings-desktop-schemas
- mutter

together with various GNOME Shell extensions, and escalated the GNOME shell
extensions' "please be compatible with v40" bugs to serious so that
autoremovals will kick in where appropriate.

As I said earlier, gnome-desktop3 is not, strictly speaking, part of this
transition, but its version number is often used as a proxy for the version
number of GNOME as a whole, so it'll be less confusing for everyone if it
migrates around the same time as the rest of this transition (+/- a week
or two is not a big deal, +/- a month could get confusing).

According to
https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
it might be necessary to remove
gnome-shell-extension-easyscreencast_1.1.0+git20210116.3252312-1 from
testing if #993061 cannot be fixed soon. The other packages with an upper
limit have already been uploaded to unstable and will hopefully transition
reasonably smoothly.

The remaining transitions for GNOME 40 are libgweather (#993934) and
evolution-data-server (#993945). jbicha suggests that after gnome-shell
migrates, we do libgweather next, and finally e-d-s.

smcv

Bug#977363: assertion crash when adding a new alias

[Stefan]

Has this been solved with 20201127? I was not able to reproduce this
issue.

-- 
Stefan

Bug#994099: twclock: improve .desktop file

[Ervin Hegedüs]

Hi Christoph,

On Sat, Sep 11, 2021 at 10:54:44PM +0200, Christoph Berg wrote:
> 
> Exec was actually removed in the last upload.
> 
> Ervin, do you remember why that was done? Afaict without "Exec", the
> program won't be launched. (But I'm not a .desktop user)

this was the lintian tag why I removed the Exec:

https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file

Now I remember when I prepared this package, I had a Debian SID
desktop (in a VM), and I played with that. First I tryed to
remove the d/menu as the lintian page proposes, but then the
installer didn't create any menu entry.

In next days, I'l install a Debian SID and a testing desktop
systems, and will try to play on them again.


73, Ervin
 

Bug#994143: RFS: gnome-shell-mailnag/40.0-1 [QA] [RC] -- mail notification extension for GNOME Shell

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "gnome-shell-mailnag":

 * Package name: gnome-shell-mailnag
   Version : 40.0-1
   Upstream Author :
 * URL : https://github.com/pulb/mailnag-gnome-shell
 * License : GPL-2.0+, BSD-3-clause
 * Vcs :
   Section : gnome

It builds those binary packages:

  gnome-shell-mailnag - mail notification extension for GNOME Shell

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

  https://mentors.debian.net/package/gnome-shell-mailnag/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnome-shell-mailnag/gnome-shell-mailnag_40.0-1.dsc

Changes since the last upload:

 gnome-shell-mailnag (40.0-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream version 40.0
 - Compatible with GNOME 40. Closes: #993203
   * d/control:
 - Remove Vcs-* entries, no longer exists.
 - Update Standards-Version to 4.6.0
 - Use debhelper-compat and bump debhelper to 13
 - Add Rules-Requires-Root: no
   * d/watch: Update URL.
   * d/rules:
 - Add compiler hardening
 - Remove trailing whitespace
   * d/copyright: Update years
   * d/upstream/metadata: Add Bug-Database, Bug-Submit, Repository
 and Repository-Browse.

Regards,
Håvard

Bug#964720: Wrong paths to pgpewrap

[Stefan]

I didn't follow the history of those changes, but I looked into the
current version of Debian 11 ("Bullseye"). neomutt 20201127.

pgpewrap has been installed to /usr/libexec/neomutt/pgpewrap

grep pgpewrap /etc/neomuttrc.d/* shows commands which are using
/usr/libexec/neomutt/pgpewrap

-- 
Stefan

Bug#994141: elfutils: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: elfutils 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of elfutils debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#994142: brltty: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: brltty 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of brltty debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#994140: open-infrastructure-compute-tools: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: open-infrastructure-compute-tools 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of open-infrastructure-
compute-tools debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Guilhem Moulin]

On Sun, 12 Sep 2021 at 14:16:58 -0400, Steve Dondley via 
Pkg-roundcube-maintainers wrote:
> What's the easiest way to get my hands on the original file from the
> package?

We don't have Debian-specific modification, so you can simply take it
from upstream.

$ curl -Ls 
https://github.com/roundcube/roundcubemail/raw/1.4.11/program/js/app.js | md5sum
b4865d6536b9188b7f5c3ae0361a1cb5  -

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#994133: libc-bin: [iconv] [fr] [manpage] Missing word in the French manpage of iconv

[Aurelien Jarno]

control: reassign -1 manpages-fr
control: retitle -1 manpages-fr: [iconv] [fr] [manpage] Missing word in the 
French manpage of iconv

Hi,

On 2021-09-12 15:36, Nicolas Patrois wrote:
> Package: libc-bin
> Version: 2.32-2
> Severity: minor
> Tags: l10n
> 
> Dear Maintainer,
> 
> In the French manpage, the word "forme" is missing in its end.
> 
> Les arguments obligatoires ou optionnels pour les options de forme longue
> le sont aussi pour les options de   courte.
> 
> Just before "courte".

The French manpage if iconv is not provided by libc-bin, but by
manpages-fr. I am therefore reassigning the bug to the right package.

Regards,
Aurelien

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

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

On 2021-09-12 09:57 AM, Steve Dondley wrote:


Are you suggesting that we should apply

--8<->8--
--- a/program/js/app.js
+++ b/program/js/app.js
@@ -5672,7 +5672,7 @@ function rcube_webmail()
   {
 var n, url = {}, mods_arr = [],
   mods = this.env.search_mods,
-  scope = this.env.search_scope || 'base',
+  scope = this.env.search_scope || 'all',
   mbox = this.env.mailbox;

 if (!filter && this.gui_objects.search_filter)
--8<->8--


By the way, my copy of app.js that came with the package has this block 
of code starting at line 5556, not 5672 like yours.


So we are looking at two different versions of the code. I'm not sure 
where yours originated from.

Bug#992872: transition: GNOME 40 (libmutter-8-0 and friends)

[David Mohammed]

budgie desktop has been uploaded to unstable.

On Sat, 11 Sept 2021 at 23:18, Simon McVittie  wrote:
>
> Control: severity -1 serious
>
> On Sat, 28 Aug 2021 at 13:52:40 +0100, Simon McVittie wrote:
> > as usual various third-party extensions will need either updating, or
> > temporarily removing from testing
>
> I've now uploaded gnome-shell 40 to unstable, so gnome-shell extensions
> incompatible with that version will soon become uninstallable. See
> #992870 for more information on this transition.
>
> budgie-desktop is not directly related to gnome-shell, but it's part of
> the libmutter transition, so it is in a similar situation.
>
> If new versions suitable for this transition were uploaded
> to experimental already, please upload to unstable, or ask
> debian-gtk-gn...@lists.debian.org or #debian-gnome if a team upload or
> NMU would be helpful.
>
> If versions compatible with GNOME 40 are not yet available, please update
> and test the extension if possible, or ask for its removal if it is not
> feasible to update it.
>
> Release team: you might want to remove incompatible extensions from
> testing if they can't be fixed soon, leaving the incompatible version
> available in unstable as a basis for updates. I'll try to follow up to
> #992870 soon with a list of unfixed packages.
>
> smcv

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Guilhem Moulin]

On Sun, 12 Sep 2021 at 13:02:41 -0400, Steve Dondley via 
Pkg-roundcube-maintainers wrote:
> That said, there must still be a bug because roundcube is supposed to
> remember the search scope feature from the $_SESSION variable and it's not
> doing that. Looking at the PHP code, roundcube is most certainly intended to
> has this ability. If you manually refresh the page after selecting a
> different folder the setting does, in fact, kick in.
>
> The $_SESSION variable for search_scope gets ignored and overridden by some
> javascript. And replacing app.min.js with app.js fixes the problem. Why that
> fixes the problem, I have no earthly idea.

I can't reproduce this in a clean Bullseye chroot.  Removed app.min.js
so the non-minified version is used instead, but I still have to reload
the page to prefill the search dialog with Scope=all.  Does your app.js
matches what we shipped in roundcube-core?  DEBIAN/md5sums snippet:

b4865d6536b9188b7f5c3ae0361a1cb5  usr/share/roundcube/program/js/app.js
7a0c881ca3e9cbff512853fcdb8e6650  usr/share/roundcube/program/js/app.min.js
4f3ace3cd9376165005b754226ca1bd8  
usr/share/roundcube/program/js/app.min.js.gz
5b9f0a46d6913f9b3481fece00930cd9  
usr/share/roundcube/program/js/app.min.js.map

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#993546: kmail: KMail sees different signing key on same mail when enabling debian-keyring

[Sandro Knauß]

Hey,

I'm quite sure, that this is not the issue of Kmail, as Kmail is using the 
GPGME to talk to gpg. So it will be an issue of libqgpgme7.

But first make sue, that you are really have an valid bug. Please verify the 
signature in a konsole via gpg --verify. I expect, that it will fail with the 
same error.

Keep in mind that Joot's using a subkey to sign ( 0x54F1A66317486713), this 
subkey needs to be available also to verify the signature. 

> When doing "gpg --list-keys 0x57930DAB0B86B067" (or long key ID)
> (with "list-options show-keyring=yes" in my gpg.conf) I see the same key
> present in my keyring (pubring.kbx) and in Debian's debian-keyring.gpg.

As I was told you alsoways have to use --with-colons when using 
gpg --list-keys  --with-colons  to get ideas about the key status.

> I have no clue how this can happen or be explained,
> but it sounds like a bug to me.

So far I know gnupg does want to get rid of multiple keyrings statched 
together. So maybe you find one of the bugs with statching. But you may get 
more up-to-date news from gnupg mantainers in Debian.

hefee

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

Bug#994139: lintian: warning about superficial autopkgtests is counterproductive

[Simon McVittie]

Package: lintian
Version: 2.105.0
Severity: normal
X-Debbugs-Cc: debian...@lists.debian.org, Paul Wise 

I see lintian has recently started emitting warnings for packages that
have autopkgtests, but only superficial autopkgtests. I think this is
counterproductive.

Obviously, if a package can have reliable autopkgtests that are not
superficial (not always feasible!), then we would prefer to have those.

However, if non-superficial autopkgtests are not achievable, then it's
*considerably* better to have superficial autopkgtests than no coverage
at all - a superficial test, like running "foo --help" and checking
that it doesn't segfault or linking a trivial program to a library and
checking that it can link, can at least check that the package is not
*completely* broken (perhaps in time to stop a serious regression in the
package or a dependency from migrating to testing).

While checking the progress of the GNOME 40 transition I noticed that the
maintainer of budgie-desktop has removed its superficial autopkgtest in
order to silence the Lintian warning, leaving it with no autopkgtest
coverage at all. I think this is the opposite of what we want! If
maintainers are unable to add extensive coverage, we should be encouraging
them to at least add superficial coverage.

The only class of tests that should be discouraged is superficial tests
that are not correctly marked with the 'superficial' keyword - but those
are probably not something that is feasible to machine-detect, except in
extremely simple cases, since the test is an arbitrary Turing-complete
script.

Some packages in the three possible categories, in order from least
to most desirable:

* gnome-shell-extension-caffeine is not really feasible to test at all:
  https://lintian.debian.org/sources/gnome-shell-extension-caffeine?version=38-1
* libsdl2-mixer only has superficial tests, which are better than nothing:
  https://lintian.debian.org/sources/libsdl2-mixer
* dbus has actual unit tests:
  https://lintian.debian.org/sources/dbus

I would expect that the test-related tags in these three packages should
reflect that order from least to most desirable, with tag severity
decreasing as we progress through the list. Something like this:

* gnome-shell-extension-caffeine: a low-severity tag encouraging the
  maintainer to add tests if feasible, but not creating so much noise
  that it masks real problems (this used to be "info" severity, and I think
  that was entirely appropriate)
* libsdl2-mixer: a low-severity tag encouraging the maintainer to add
  non-superficial tests if feasible, but not creating so much noise
  that it masks real problems (I would say "info" or "pedantic" severity)
* dbus: no tags

In fact they are:

* gnome-shell-extension-caffeine: no tags
* libsdl2-mixer: W: superficial-tests
* dbus: no tags

I think packages like gnome-shell-extension-caffeine used to be flagged
with testsuite-autopkgtest-missing, but it looks as though the meaning of
testsuite-autopkgtest-missing might have changed at some point so that it
is only emitted for packages that have debian/tests/control, rather than
for all packages that lack autopkgtests?

smcv

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

Are you suggesting that we should apply

--8<->8--
--- a/program/js/app.js
+++ b/program/js/app.js
@@ -5672,7 +5672,7 @@ function rcube_webmail()
   {
 var n, url = {}, mods_arr = [],
   mods = this.env.search_mods,
-  scope = this.env.search_scope || 'base',
+  scope = this.env.search_scope || 'all',
   mbox = this.env.mailbox;

 if (!filter && this.gui_objects.search_filter)
--8<->8--

?  If so, please reopen your upstream issue, and this Debian bug should
tagged ‘upstream’ and marked as forwarded to the GitHub issue.


No. I am not suggesting any specific fix to the javascript code.

I'm saying when I overwrite the app.min.js with the *original* app.js 
that comes bundled with the package, everything works fine. No changes 
to the js code were made by me. I have no idea what the actual bug in 
the app.min.js code is. But I figured this report will help you track 
down the origin of the problem.




* What exactly did you do (or not do) that was effective

While investigating the issue, I discovered that overwriting the 
minified
app.min.js with the non-minified app.js file resolved the problem. It 
appears

the app.min.js is probably using a stale version of app.js.


Minifying (and static pre-compression) happens at built time.  When a
source file is manually changed, the generated files that depend on it
need to be manually updated too.  The app.min.js file we *shipped*
matched the original app.js, right?


I have no idea. I know nothing about how such things work and could not 
speculate on how this bug originated.


Also note that I minifed the app.js file that came with the package with 
a web-based tool and replaced app.min.js with its output and that works 
as well.


So it doesn't appear the a minified version of the code is the problem. 
It just looks to me like app.min.js is using bad code and app.js is 
using good code. But I don't know for sure. I'll leave that to your more 
experienced hands to determine.

Bug#989051: [Debian-med-packaging] Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI

[Étienne Mollier]

Hi Maarten,

Maarten L. Hekkelman, on 2021-09-02:
> I found the underlying problem, apparently the ABI field of the ELF header
> should contain a flag indicating it is a Linux executable. In order to set
> this flag properly, I need to find out various things and perhaps it is
> easiest to try to figure out these myself. Is it possible to get access to a
> HPPA machine running Debian? I am a Debian maintainer, if that makes any
> difference.

Without easy access to a PA-RISC machine, you can resort to
Qemu.  The Debian hppa port can be emulated using one of the
emulators provided in the package qemu-system-misc.  If you
combine it with the package qemu-user-static (and also have
Debian ports keyring at hand), then you can directly debootstrap
a chroot able to run PA-RISC binaries:

$ uname -m
x86_64

$ sudo debootstrap \
--arch=hppa \
--keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg \
--include=debian-ports-archive-keyring \
sid sid-hppa-chroot http://ftp.ports.debian.org/debian-ports
I: Target architecture can be executed
[...]
I: Base system installed successfully.

$ sudo chroot sid-hppa-chroot uname -m
parisc

> Otherwise, could you provide me the output of `cpp -dM /dev/null` and
> perhaps also how to detect PA-RISC/Debian in a cmake file. That last
> question is perhaps a bit too much to ask for, but any hint is appreciated.

Feel free to checkout cpp_hppa.h in attachment; I obtained it
with the aforementioned method.

In hope this helps,
Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
#define __DBL_MIN_EXP__ (-1021)
#define __UINT_LEAST16_MAX__ 0x
#define __ATOMIC_ACQUIRE 2
#define __FLT_MIN__ 1.1754943508222875e-38F
#define __GCC_IEC_559_COMPLEX 1
#define __UINT_LEAST8_TYPE__ unsigned char
#define __INTMAX_C(c) c ## LL
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 0xff
#define __WINT_MAX__ 0xU
#define __FLT32_MIN_EXP__ (-125)
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 0xU
#define __WCHAR_MAX__ 0x7fffL
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __DBL_DENORM_MIN__ ((double)4.9406564584124654e-324L)
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_IEC_559 1
#define __FLT32X_DECIMAL_DIG__ 17
#define __FLT_EVAL_METHOD__ 0
#define __FLT64_DECIMAL_DIG__ 17
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __hppa 1
#define __UINT_FAST64_MAX__ 0xULL
#define __SIG_ATOMIC_TYPE__ int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __FLT32X_MAX_EXP__ 1024
#define __GNUC_PATCHLEVEL__ 0
#define __FLT32_HAS_DENORM__ 1
#define __UINT_FAST8_MAX__ 0xff
#define __FLT32_MAX_10_EXP__ 38
#define __INT8_C(c) c
#define __INT_LEAST8_WIDTH__ 8
#define __UINT_LEAST64_MAX__ 0xULL
#define __SHRT_MAX__ 0x7fff
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __UINT_LEAST8_MAX__ 0xff
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __UINTMAX_TYPE__ long long unsigned int
#define __linux 1
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
#define __unix 1
#define __UINT32_MAX__ 0xU
#define __LDBL_MAX_EXP__ 1024
#define __WINT_MIN__ 0U
#define __INT_LEAST16_WIDTH__ 16
#define __SCHAR_MAX__ 0x7f
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __INT64_C(c) c ## LL
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __SIZEOF_INT__ 4
#define __FLT32X_MANT_DIG__ 53
#define __USER_LABEL_PREFIX__ 
#define __STDC_HOSTED__ 1
#define __DBL_DIG__ 15
#define __FLT32_DIG__ 6
#define __FLT_EPSILON__ 1.1920928955078125e-7F
#define __SHRT_WIDTH__ 16
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __STDC_UTF_16__ 1
#define __FLT32X_HAS_INFINITY__ 1
#define __INT32_MAX__ 0x7fff
#define _PA_RISC1_1 1
#define __unix__ 1
#define __INT_WIDTH__ 32
#define __SIZEOF_LONG__ 4
#define __STDC_IEC_559__ 1
#define __STDC_ISO_10646__ 201706L
#define __UINT16_C(c) c
#define __DECIMAL_DIG__ 17
#define __STDC_IEC_559_COMPLEX__ 1
#define __FLT64_EPSILON__ 2.2204460492503131e-16F64
#define __gnu_linux__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __FLT64_MANT_DIG__ 53
#define __GNUC__ 10
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 8
#define __BIGGEST_ALIGNMENT__ 8
#define __FLT64_MAX_10_EXP__ 308
#define __DBL_MAX__ ((double)1.7976931348623157e+308L)
#define __INT_FAST32_MAX__ 0x7fff
#define __DBL_HAS_INFINITY__ 1
#define __HAVE_SPECULATION_SAFE_VALUE 1
#define __INTPTR_WIDTH__ 32
#define __UINT_LEAST32_MAX__ 0xU
#define __FLT32X_HAS_DENORM__ 1
#define __INT_FAST16_TYPE__ int
#define __LDBL_HAS_DENORM__ 1
#define __INT_LEAST32_MAX__ 0x7fff
#define __DBL_MAX_EXP__ 1024
#define __WCHAR_WIDTH__ 32
#define __FLT32_MAX__ 3.4028234663852886e+38F32

Bug#992563: transition: gdal

[Sebastiaan Couwenberg]

On 9/11/21 5:56 PM, Sebastian Ramacher wrote:
> On 2021-09-11 17:02:48 +0200, Sebastiaan Couwenberg wrote:
>> On 9/10/21 9:35 AM, Sebastian Ramacher wrote:
>>> On 2021-09-09 13:02:14, Sebastiaan Couwenberg wrote:
 On 9/9/21 5:57 AM, Sebastiaan Couwenberg wrote:
> On 9/8/21 6:56 AM, Sebastiaan Couwenberg wrote:
>> On 9/7/21 3:07 PM, Sebastiaan Couwenberg wrote:
>>> On 9/5/21 6:48 PM, Sebastian Ramacher wrote:
 On 2021-08-20 11:32:16 +0200, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-gdal.html
> Control: block -1 by 992527 992528
>
> For the Debian GIS team I'd like to transition to GDAL 3.3.1.
>
> Most reverse dependencies rebuilt successfully with GDAL 3.3.1 from
> experimental as summarized below.
>
> libgdal-grass doesn't need a binNMU as the 3.3.1 version will be
> uploaded to unstable instead.

 Assuming that the version of pdal in experimental also builds fine
 against the new version of gdal, please go ahead and also start the 
 pdal
 transition.
>>>
>>> PDAL 2.3.0 also builds successfully with GDAL 3.3 so I'll upload that to
>>> unstable once gdal is built on all release architectures. The gdal
>>> upload to unstable had to wait a bit for 3.2.2+dfsg-3 to migrated to
>>> testing to fix #993334 there too.
>>
>> gdal has built on all release architectures, and pdal has been uploaded
>> to unstable as well.
>
> Thanks for scheduling the binNMUs, please also binNMU grass to unblock
> libgdal-grass & qgis. libgdal-grass needs a source upload as usual.

 grass has been rebuilt on all release architectures too, qgis can be
 rebuilt now.
>>>
>>> The binNMUs for qgis have also been scheduled.
>>
>> RM bugreports for ncl (i386) and qgis (mipsel mips64el) have been filed.
> 
> The one for ncl won't be needed. It won't block libgdal from migrating
> to testing. It will only delay the removal of the old binary packages on
> i386 until it's fixed.

Everything that keeps libgdal28 around blocks the removal of libepsilon
(#994073).

> And to be honest, I don't think that a RoQA for a package where the
> maintainer is actively working on fixing it is appropriate.

That's not what that ncl bugreport shows.

>> grass (7.8.6~rc2-1~exp1) and otb (8.0.0~alpha1+dfsg-1~exp1) in
>> experimental also need to be rebuilt.

grass & otb in experiment still need to be rebuilt.

Kind Regards,

Bas

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

Bug#992404: gnome-shell-extension-xrdesktop: Recommends obsolete transitional package gnome-tweak-tool

[Simon McVittie]

On Wed, 18 Aug 2021 at 08:55:32 +0100, Simon McVittie wrote:
> g-s-e-xrdesktop Recommends gnome-tweak-tool, but since buster that has been
> a transitional package, and we have been asked to remove it from bookworm.
> Please update the Recommends to point to gnome-tweaks.

gnome-tweaks is not responsible for extensions management any more, so
instead please update the Recommends to gnome-shell-extension-prefs (or
maybe gnome-shell-extension-prefs-xrdesktop), and update the Description
to mention gnome-extensions-app.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994122 has an example
of suitable wording.

smcv

Bug#993065: gnome-shell-extension-xrdesktop: Please update for gnome-shell 40

[Simon McVittie]

Control: severity -1 serious

On Thu, 26 Aug 2021 at 22:32:49 -0400, Jeremy Bicha wrote:
> git master appears to be compatible with gnome-shell 3.38 and 40.

gnome-shell 40 is now in unstable.

Or, if this extension is intended to be loaded by the gnome-shell-xrdesktop
"friendly fork" of gnome-shell, please change the Depends to point to that
package instead of gnome-shell (and maybe update that to v40 too).

Thanks,
smcv

Bug#993063: gnome-shell-pomodoro: Please update to version 0.19.1

[Simon McVittie]

Control: severity -1 serious
Control: tags -1 + bookworm sid
Control: user pkg-gnome-maintain...@lists.alioth.debian.org
Control: usertags -1 + gnome-shell-40

On Thu, 26 Aug 2021 at 22:26:11 -0400, Jeremy Bicha wrote:
> Please package gnome-shell-pomodoro 0.19.1 which claims to be
> compatible with gnome-shell 3.38 and 40.

I've recently uploaded gnome-shell 40 to unstable, which I suspect will
make this extension stop working in unstable, so I'm setting this bug to
be RC.

smcv

Bug#930991: gajim in Debian stretch does not start anymore

[Stefan]

I just found this: https://dev.gajim.org/gajim/gajim/-/issues/8788

-- 
Stefan

Bug#994125: rsync: rsync hangs (?) after upgrade to bullseye

[Samuel Henrique]

Hello Janusz,

Thank you for your bug report,

We will have to try to get a more verbose output to investigate this.

Could you provide what exactly your script is doing? Like which
options of rsync it is using.
And could you try to do the same operation but with the verbose
parameters "-vvv" set and provide the log?
It's possible that you're gonna have to save the output to some file,
if it becomes too big.

Regards,

-- 
Samuel Henrique 

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Adrian Bunk]

On Thu, Sep 02, 2021 at 11:38:35PM +0100, Phil Morrell wrote:
>...
> 4. When 2 or 3 are too onerous to maintain, the package MAY use the
>convenience copy but MUST document why in README.source and SHOULD be
>included in the [security-tracker].
>...

  The package MUST be listed as being without security support in
  the debian-security-support package and the Release Notes,
  and it MUST NOT be installed as part of a default installation,
  unless the security team has explicitly agreed to support it.

If we are shipping software where Debian cannot provide security support,
then we shouldn't hide the problem from our users.

cu
Adrian

Bug#992215: rsync: please consider re-adding --copy-devices patch

[Samuel Henrique]

Hello Kevin,

Thanks for the detailed bugreport,

I agree with it and have just uploaded the fix to unstable. I'm gonna
try to get this into bullseye before the 11.1 release, and
bullseye-backports shall get the fix after it reaches testing.

Regards,

-- 
Samuel Henrique 

Bug#992231: --delay-updates leaves stale partial data and causes files to never be updated

[Samuel Henrique]

Hello Miao Wang,

Thank you for the bug report and link to the upstream patch.

> There have been fixes and backporting from upstream. I wonder if the patches
can be applied to bullseye-pu and buster-backports?

Yes, I have uploaded the fix to unstable just now, I will try to get
this fix in bullseye in time for the 11.1 release. And I'll do the
backports upload as soon as the fix reaches testing.

Thank you,


-- 
Samuel Henrique 

Bug#993805: UDD: duplicate entries for the same release

[Mattia Rizzolo]

On Tue, Sep 07, 2021 at 01:39:47PM -0400, Sandro Tosi wrote:
> > A RM bug for manual cruft removal of this arch:all package should fix it ...
> 
> i've filed #993879 -- thanks

That's good (though I think that needs an [all] to the title, which I
just added).

Now, it'd be good if somebody looked through the other apparently stale
binaries that are probably around, and either fix the auto-decruft
routine, or file a bunch of RM bugs.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#989846: CVE-2021-22895

[Sandro Knauß]

Hey,
> > > What about Buster? Is 2.5 also affected?
> > 
> > yes 2.5 is also affected. At least the source files look the same.
> 
> Ack, can you also prepare an update for buster-security, please?

I have here a proposed debdiff. I added a third patch, so users have the 
possiblility to accept invalid certs otherwise they would fail silently. At 
least for me this sounds like not a proper solution. 

* Do I need to upload also with sources? How can I check this myself?
 
Cheers,

hefee
diff -Nru nextcloud-desktop-2.5.1/debian/changelog nextcloud-desktop-2.5.1/debian/changelog
--- nextcloud-desktop-2.5.1/debian/changelog	2019-08-29 18:57:38.0 +0200
+++ nextcloud-desktop-2.5.1/debian/changelog	2021-09-11 11:53:28.0 +0200
@@ -1,3 +1,12 @@
+nextcloud-desktop (2.5.1-3+deb10u2) buster; urgency=high
+
+  * Add backported patch to fix CVE-2021-22895. (Closes: #989846)
+  * Add backported patch to fix CVE-2021-32728.
+  * Update patch for CVE-2021-32728 for v2.5.1.
+  * Add patch to make it possible to accept invalid SSL certificates.
+
+ -- Sandro Knauß   Sat, 11 Sep 2021 11:53:28 +0200
+
 nextcloud-desktop (2.5.1-3+deb10u1) buster; urgency=medium
 
   * Make nextcloud-desktop-cmd depend on nextcloud-desktop-common.
diff -Nru nextcloud-desktop-2.5.1/debian/patches/0006-Validate-the-providers-ssl-certificate.patch nextcloud-desktop-2.5.1/debian/patches/0006-Validate-the-providers-ssl-certificate.patch
--- nextcloud-desktop-2.5.1/debian/patches/0006-Validate-the-providers-ssl-certificate.patch	1970-01-01 01:00:00.0 +0100
+++ nextcloud-desktop-2.5.1/debian/patches/0006-Validate-the-providers-ssl-certificate.patch	2021-09-10 22:17:16.0 +0200
@@ -0,0 +1,37 @@
+From 142180c0e297ef500daf8328e7ea3020e33a3639 Mon Sep 17 00:00:00 2001
+From: Felix Weilbach 
+Date: Wed, 10 Feb 2021 09:53:57 +0100
+Subject: [PATCH] Validate the providers ssl certificate
+
+Signed-off-by: Felix Weilbach 
+---
+ src/gui/wizard/webview.cpp | 12 ++--
+ 1 file changed, 2 insertions(+), 10 deletions(-)
+
+--- a/src/gui/wizard/webview.cpp
 b/src/gui/wizard/webview.cpp
+@@ -45,9 +45,6 @@ public:
+ 
+ protected:
+ bool certificateError(const QWebEngineCertificateError ) override;
+-
+-private:
+-QUrl _rootUrl;
+ };
+ 
+ // We need a separate class here, since we cannot simply return the same WebEnginePage object
+@@ -157,14 +154,9 @@ QWebEnginePage * WebEnginePage::createWi
+ 
+ void WebEnginePage::setUrl(const QUrl ) {
+ QWebEnginePage::setUrl(url);
+-_rootUrl = url;
+ }
+ 
+ bool WebEnginePage::certificateError(const QWebEngineCertificateError ) {
+-if (certificateError.error() == QWebEngineCertificateError::CertificateAuthorityInvalid) {
+-return certificateError.url().host() == _rootUrl.host();
+-}
+-
+ return false;
+ }
+ 
diff -Nru nextcloud-desktop-2.5.1/debian/patches/0007-check-e2ee-public-key-against-private-one.patch nextcloud-desktop-2.5.1/debian/patches/0007-check-e2ee-public-key-against-private-one.patch
--- nextcloud-desktop-2.5.1/debian/patches/0007-check-e2ee-public-key-against-private-one.patch	1970-01-01 01:00:00.0 +0100
+++ nextcloud-desktop-2.5.1/debian/patches/0007-check-e2ee-public-key-against-private-one.patch	2021-09-11 11:28:54.0 +0200
@@ -0,0 +1,88 @@
+From 7fb09a81632de6066e55def20308d6e61cadbc48 Mon Sep 17 00:00:00 2001
+From: Matthieu Gallien 
+Date: Wed, 19 May 2021 15:36:47 +0200
+Subject: [PATCH] check e2ee public key against private one
+
+should ensure we have matching private/public keys
+
+Signed-off-by: Matthieu Gallien 
+---
+ src/libsync/clientsideencryption.cpp | 30 +++-
+ src/libsync/clientsideencryption.h   |  1 +
+ 2 files changed, 30 insertions(+), 1 deletion(-)
+
+--- a/src/libsync/clientsideencryption.cpp
 b/src/libsync/clientsideencryption.cpp
+@@ -15,6 +15,7 @@
+ #include "creds/abstractcredentials.h"
+ 
+ #include 
++#include 
+ 
+ #include 
+ 
+@@ -30,6 +31,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include 
+ 
+@@ -644,6 +646,37 @@ void ClientSideEncryption::fetchFromKeyC
+ job->start();
+ }
+ 
++ bool ClientSideEncryption::checkPublicKeyValidity() const
++ {
++ QByteArray data = EncryptionHelper::generateRandom(64);
++
++ BIO *publicKeyBio = BIO_new(BIO_s_mem());
++ QByteArray publicKeyPem = _account->e2e()->_publicKey.toPem();
++ BIO_write(publicKeyBio, publicKeyPem.constData(), publicKeyPem.size());
++ EVP_PKEY *publicKey = PEM_read_bio_PUBKEY(publicKeyBio, nullptr, nullptr, nullptr);
++ BIO_free_all(publicKeyBio);
++
++ auto encryptedData = EncryptionHelper::encryptStringAsymmetric(publicKey, data.toBase64());
++
++ BIO *privateKeyBio = BIO_new(BIO_s_mem());
++ QByteArray privateKeyPem = _account->e2e()->_privateKey;
++ BIO_write(privateKeyBio, privateKeyPem.constData(), privateKeyPem.size());
++ EVP_PKEY *key = PEM_read_bio_PrivateKey(privateKeyBio, nullptr, nullptr, nullptr);
++ 

Bug#994128: roundcube: search preference configuration setting for folder scope gets ignored

[Steve Dondley]

Package: roundcube
Version: 1.4.11+dfsg.1-4
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I set the $config['search_scope'] to a value of 'all' in the configuration
file so that the "Scope" field should default to "All folders." This feature
is broken. When switching folders, the search scope in the search form gets 
reset to
"Current folder". A manual refresh of the web page is required to get the
desired setting of "All folders".

   * What exactly did you do (or not do) that was effective

While investigating the issue, I discovered that overwriting the minified 
app.min.js with the non-minified app.js file resolved the problem. It appears
the app.min.js is probably using a stale version of app.js.

Please see my upstream bug report:
https://github.com/roundcube/roundcubemail/issues/8198



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

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

Versions of packages roundcube depends on:
ii  dpkg1.20.9
ii  roundcube-core  1.4.11+dfsg.1-4

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  dbconfig-common   2.0.19
ii  debconf [debconf-2.0] 1.5.77
ii  dpkg  1.20.9
ii  libapache2-mod-php2:7.4+76
ii  libapache2-mod-php7.4 [libapache2-mo  7.4.21-1+deb11u1
ii  libjs-bootstrap4  4.5.2+dfsg1-7
ii  libjs-codemirror  5.59.2+~cs0.23.109-1
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-minicolors   2.2.6+dfsg-4
ii  libjs-jquery-ui   1.12.1+dfsg-8
ii  libjs-jstimezonedetect1.0.6-5
ii  libmagic1 1:5.39-3
ii  php   2:7.4+76
ii  php-auth-sasl 1.1.0-1
ii  php-common2:76
ii  php-intl  2:7.4+76
ii  php-mail-mime 1.10.10-1
ii  php-masterminds-html5 2.7.4+dfsg-2
ii  php-mbstring  2:7.4+76
ii  php-net-sieve 1.4.4-2
ii  php-net-smtp  1.9.0-1
ii  php-net-socket1.2.2-2
ii  php-pear  1:1.10.12+submodules+notgz+20210212-1
ii  php7.4 [php]  7.4.21-1+deb11u1
ii  php7.4-cli [php-cli]  7.4.21-1+deb11u1
ii  php7.4-intl [php-intl]7.4.21-1+deb11u1
ii  php7.4-json [php-json]7.4.21-1+deb11u1
ii  php7.4-mbstring [php-mbstring]7.4.21-1+deb11u1
ii  roundcube-mysql   1.4.11+dfsg.1-4
ii  ucf   3.0043

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi] 2.4.48-3.1+deb11u1
ii  php-gd  2:7.4+76
ii  php-pspell  2:7.4+76
ii  php7.4-gd [php-gd]  7.4.21-1+deb11u1
ii  php7.4-pspell [php-pspell]  7.4.21-1+deb11u1

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg 
pn  php-mkopinsky-zxcvbn-php  
pn  php-net-ldap3 
ii  roundcube-plugins 1.4.11+dfsg.1-4

-- debconf information:
  roundcube/upgrade-error: abort
* roundcube/mysql/admin-user: root
* roundcube/dbconfig-remove: true
  roundcube/remove-error: abort
  roundcube/passwords-do-not-match:
* roundcube/dbconfig-reinstall: true
* roundcube/dbconfig-install: true
* roundcube/database-type: mysql
* roundcube/mysql/method: Unix socket
  roundcube/upgrade-backup: true
  roundcube/missing-db-package-error: abort
  roundcube/purge: false
* roundcube/language: en_US
* roundcube/db/dbname: roundcube
  roundcube/mysql/authplugin: default
  roundcube/remote/port:
* roundcube/dbconfig-upgrade: true
* roundcube/db/app-user: roundcube@localhost
* roundcube/hosts: email.ufcw919.org
  roundcube/internal/skip-preseed: false
  roundcube/remote/host: localhost
* roundcube/reconfigure-webserver: apache2
* roundcube/restart-webserver: true
  roundcube/remote/newhost:
* roundcube/install-error: ignore
  roundcube/internal/reconfiguring: false

Bug#993058: gnome-shell-extension-dash-to-panel: New upstream release 43

[Simon McVittie]

Control: severity -1 serious
Control: tags -1 + bookworm sid
Control: user pkg-gnome-maintain...@lists.alioth.debian.org
Control: usertags -1 + gnome-shell-40

On Thu, 26 Aug 2021 at 21:28:11 -0400, Jeremy Bicha wrote:
> gnome-shell-extension-dash-to-panel 43 was released. It works on
> gnome-shell 40 but does not work on earlier gnome-shell releases.

I've just uploaded gnome-shell 40 to unstable, which I suspect will
make this extension stop working in unstable. Please upload to unstable,
or contact the GNOME team if a team upload or NMU is desired.

smcv

Bug#779272: mpt-status: /etc/default/mpt-statusd is not created by package install

[Steven Maddox]

This would still be a useful change to have in bullseye.

At the moment I just run this after installing mpt-status...

sed -n 's/^\(MAILTO=\|PERIOD=\|REMIND=\|RUN_DAEMON=\|ID=\)/#\1/p'
/etc/init.d/mpt-statusd > /etc/default/mpt-statusd

That way I have a slightly easier way of editing such options like
MAILTO= (for which e-mail address to send alerts to) or ID= (for which
RAID controller the service should watch)

On Thu, 26 Feb 2015 10:49:58 + Chris Lewis  wrote:
> Package: mpt-status
> Version: 1.2.0-7
> Severity: normal
> 
> Dear Maintainer,
> 
> It would be nice to have a /etc/default/mpt-statusd file created with #'d out 
> options
> particularly the ID parameter for the controller. It would make setting up 
> the program
> far more obvious.
> 
> This would be a good template for it
> 
> #MAILTO=root   # Where to report problems
> #PERIOD=600# Seconds between each check(default 10 minutes)
> #REMIND=7200   # Seconds between each reminder (default 2 hours)
> #RUN_DAEMON=yes
> #ID=0
> 
> 
> 
> Cheers!
> 
> 
> *** Please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these lines ***
> 
> 
> -- System Information:
> Debian Release: 7.8
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages mpt-status depends on:
> ii  daemon0.6.4-1
> ii  libc6 2.13-38+deb7u8
> ii  lsb-base  4.1+Debian8+deb7u1
> 
> mpt-status recommends no packages.
> 
> Versions of packages mpt-status suggests:
> ii  bsd-mailx [mailx]  8.1.2-0.2006cvs-1+deb7u1
> 
> -- no debconf information
> 
> 

-- 
Steven Maddox
Lantizia

Bug#993887: gnome-shell-extension-dash-to-panel: Please add version constraint: Depends: gnome-shell (>= 40)

[Simon McVittie]

Control: retitle -1 gnome-shell-extension-dash-to-panel: Please add version 
constraint: Depends: gnome-shell (>= 40)

On Tue, 07 Sep 2021 at 15:22:42 -0400, Boyuan Yang wrote:
> As discussed in https://bugs.debian.org/993058 , gnome-shell-extension-dash-
> to-panel/43-1 does not work with GNOME Shell 3.38 or earlier versions.
> However, the current condition is that it was uploaded onto Unstable even if
> gnome-shell/40.x is still in experimental.

40.x has now reached unstable.

> please add Breaks: gnome-shell (<< 40) to the binary package to make sure that
> no users would end up with a broken GUI environment

gnome-shell-extension-dash-to-panel has Depends: gnome-shell, so it would
be more conventional to turn that into a versioned Depends on
gnome-shell (>= 40).

smcv

Bug#954315: rastertopwg segfault

[Hideki Yamane]

On Thu, 9 Sep 2021 10:51:32 +0100
Brian Potkin  wrote:
> How are you progressing with this issue using the present cups in
> unstable?

 Well, I can have some time for Debian in next week, so will check
 later. Thanks for head up! :)


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#896460: Please package ipywidgets 7

[Sandro Tosi]

Hello Gordon,

On Sat, 21 Apr 2018 10:55:29 +0200 Tobias Hansen  wrote:
> Sagemath 8.2 uses ipywidgets 7 [1] and using version 6 causes about 80 
> doctests to fail.

do you have any plan to update ipywidgets to 7+ anytime soon? the
upstream version currently in sid is severely outdated, being released
more than 4 years ago!

Several packages are requiring ipywidgets 7 and the lack of it in
Debian is hold several maintainers back from updating their packages
(I have 3 myself alone).

This bug was open more than 3 years ago: please provide an update on a
timeline for ipywidgets 7 for debian, so that we can plan accordingly.

Thanks,
Sandro

Bug#950598: python3-jupyter-sphinx: package relies on unavailable `ipywidgets.embed` module

[Sandro Tosi]

control: block -1 with 896460

On Sat, 11 Sep 2021 20:01:46 -0400 Sandro Tosi  wrote:
> On Mon, 03 Feb 2020 19:21:28 -0600 Sebastian Luque  wrote:
> > Package: python3-jupyter-sphinx
> > Version: 0.2.3-1
> > Severity: grave
> >
> > Dear Maintainer,
> >
> > The package is unuseable, as it relies on the `ipywidgets.embed` module,
> > which is unavailable in the latest sid version:
> >
> > Extension error:
> > Could not import extension jupyter_sphinx.execute (exception: No module 
> > named 'ipywidgets.embed')
>
> Frédéric-Emmanuel,
> did you look at this bug at all? it's been open for more than a year
> and a half, and it's preventing this package and its rdeps from
> migrating to testing. please address asap

I got a private reply from picca, which should have been posted here.

The issue at hand is that jupyter-sphinx really depends on ipywidgets
7, which is still not packaged for Debian, see #896460. Adding the
proper block

Bug#994109: scilab FTBFS with hdf5 1.10.7

[Gilles Filippini]

Adrian Bunk a écrit le 11/09/2021 à 23:35 :

Source: scilab
Version: 6.1.0+dfsg1-7
Severity: serious
Tags: ftbfs

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

...
In file included from /usr/include/hdf5/serial/H5public.h:32,
  from /usr/include/hdf5/serial/hdf5.h:22,
  from src/c/h5_readDataFromFile.c:26:
/usr/include/hdf5/serial/H5version.h:39:4: error: #error "Can't choose old API 
versions when deprecated APIs are disabled"
39 |   #error "Can't choose old API versions when deprecated APIs are 
disabled"
   |^
make[5]: *** [Makefile:1380: src/c/libscihdf5_algo_la-h5_readDataFromFile.lo] 
Error 1



Patch proposal attached.

Best,

_g.
diff -Nru scilab-6.1.1+dfsg2/debian/changelog 
scilab-6.1.1+dfsg2/debian/changelog
--- scilab-6.1.1+dfsg2/debian/changelog 2021-09-10 07:02:44.0 +0200
+++ scilab-6.1.1+dfsg2/debian/changelog 2021-09-12 14:50:46.0 +0200
@@ -1,3 +1,11 @@
+scilab (6.1.1+dfsg2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New patch hdf5-1.10.7.patch to disable H5_NO_DEPRECATED_SYMBOLS which
+causes FTBFS against HDF5 1.10.7 (Closes: #994109)
+
+ -- Gilles Filippini   Sun, 12 Sep 2021 14:50:46 +0200
+
 scilab (6.1.1+dfsg2-1) unstable; urgency=medium
 
   * Drop even more files from upstream's archive (now dfsg2),
diff -Nru scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch 
scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch
--- scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch 1970-01-01 
01:00:00.0 +0100
+++ scilab-6.1.1+dfsg2/debian/patches/hdf5-1.10.7.patch 2021-09-12 
14:50:46.0 +0200
@@ -0,0 +1,52 @@
+Index: scilab/scilab/modules/hdf5/Makefile.am
+===
+--- scilab.orig/scilab/modules/hdf5/Makefile.am
 scilab/scilab/modules/hdf5/Makefile.am
+@@ -103,8 +103,7 @@ FORCE_HDF_API = \
+ -DH5Gopen_vers=2 \
+ -DH5Tget_array_dims_vers=2 \
+ -DH5Acreate_vers=2 \
+--DH5Rdereference_vers=2 \
+--DNO_DEPRECATED_SYMBOLS
++-DH5Rdereference_vers=2
+ 
+ 
+ libscihdf5_la_CPPFLAGS = \
+Index: scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile.c
+===
+--- scilab.orig/scilab/modules/hdf5/src/c/h5_readDataFromFile.c
 scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile.c
+@@ -13,8 +13,6 @@
+ *
+ */
+ 
+-#define H5_NO_DEPRECATED_SYMBOLS
+-
+ #ifndef _MSC_VER
+ #include 
+ #else
+Index: scilab/scilab/modules/hdf5/includes/HDF5Objects.h
+===
+--- scilab.orig/scilab/modules/hdf5/includes/HDF5Objects.h
 scilab/scilab/modules/hdf5/includes/HDF5Objects.h
+@@ -16,7 +16,6 @@
+ #ifndef __HDF5OBJECTS_H__
+ #define __HDF5OBJECTS_H__
+ 
+-#define H5_NO_DEPRECATED_SYMBOLS
+ #undef H5_USE_16_API
+ 
+ #define H5Eset_auto_vers 2
+Index: scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile_v1.c
+===
+--- scilab.orig/scilab/modules/hdf5/src/c/h5_readDataFromFile_v1.c
 scilab/scilab/modules/hdf5/src/c/h5_readDataFromFile_v1.c
+@@ -13,8 +13,6 @@
+ *
+ */
+ 
+-#define H5_NO_DEPRECATED_SYMBOLS
+-
+ #ifndef _MSC_VER
+ #include 
+ #else
diff -Nru scilab-6.1.1+dfsg2/debian/patches/series 
scilab-6.1.1+dfsg2/debian/patches/series
--- scilab-6.1.1+dfsg2/debian/patches/series2021-09-10 07:02:44.0 
+0200
+++ scilab-6.1.1+dfsg2/debian/patches/series2021-09-12 14:50:46.0 
+0200
@@ -20,3 +20,4 @@
 no-ftbfs-icu.patch
 find_external_libintl_jar.patch
 ocaml_411.patch
+hdf5-1.10.7.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#994127: libvirt-daemon: Error creating virtual network - iptables (nf_tables) table `nat' is incompatible, use 'nft'

[Benedikt Tuchen]

Package: libvirt-daemon
Version: 7.0.0-3
Severity: graves

Dear Maintainer,

while trying to create a new virtual network on a fresh Debian 11 install I get
the following error:


Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createnet.py", line 428, in 
_async_net_create
netobj.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 3436, in create
raise libvirtError('virNetworkCreate() failed')
libvirt.libvirtError: internal error: Failed to apply firewall rules 
/usr/sbin/iptables -w --table nat --list-rules: iptables v1.8.7 (nf_tables): 
table `nat' is incompatible, use 'nft' tool.


I've installed the following packages:
qemu-kvm qemu-system-x86 qemu-utils libvirt-daemon-system virt-manager 
virt-viewer

/usr/sbin/iptables is set in automode to /usr/sbin/iptables-nft via 
update-alternatives.

I've tried to create virtual network with virt-manager.

When trying to set the rule on commandline it fails with the same error.

If you need more information feel free to ask.

Regards,
Benedikt

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 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), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.36.1-8
ii  libc6   2.31-13
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libnetcf1   1:0.2.8-1.1
ii  libparted2  3.4-1
ii  libpcap0.8  1.10.0-2
ii  libpciaccess0   0.16-1
ii  libselinux1 3.1-3
ii  libudev1247.3-6
ii  libvirt-daemon-driver-qemu  7.0.0-3
ii  libvirt07.0.0-3
ii  libxml2 2.9.10+dfsg-6.7

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   7.0.0-3
ii  libvirt-daemon-driver-vbox  7.0.0-3
ii  libvirt-daemon-driver-xen   7.0.0-3
ii  libxml2-utils   2.9.10+dfsg-6.7
ii  netcat-openbsd  1.217-3
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   7.0.0-3
pn  numad   

-- no debconf information


signature.asc
Description: PGP signature