Bug#996662: qtox fails to load and save profiles when configuration directories are symlinks

[debian-testing]

Package: qtox
Version: 1.17.3-1

qtox fails to load and save profiles when configuration directories are 
symlinks. The errors are as follows:

Loading an existing profile gives the following error:
Dialog box: "Couldn't load this profile" "This profile is already in use."
Log: "... persistence/profile.cpp:696 : Warning: Couldn't open tox save ..."

Creating a new profile gives the following error:
Dialog box: "Couldn't load this profile" "Wrong password."
Log: "...persistence/profile.cpp:231 : Warning: Failed to lock profile ..."

Additional Information:
Everything works ok when the configuration directory is just standard directory 
(not a symlink)
All permission where double checked and forced to 777 (eg "chmod -R 777 *")
Configuration directory being ~/.config/tox/ (eg /home/user/.config/tox/)

Version info:

apt search qtox
qtox/stable,now 1.17.3-1 amd64 [installed]

uname -rv
5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30)

Bug#996669: ITP: golang-github-lensesio-schema-registry -- Command Line Interface (CLI) and a Go client for the REST API of Confluent's Kafka Schema Registry

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: golang-github-lensesio-schema-registry
  Version : 0.1.0
  Upstream Author : Rollulus Rouloul 
* URL : https://github.com/lensesio/schema-registry
* License : Apache-2
  Programming Lang: Go
  Description : Command Line Interface (CLI) and a Go client for the REST 
API of Confluent's Kafka Schema Registry.


 Command Line Interface (CLI) and a Go client for the REST API of
 Confluent's Kafka Schema Registry.

 The package is dependency of kafkactl .
 The package will be maintained by Debian Go Packaging Team 
.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#996668: cinnamon-settings-daemon: cinnamon shutdown hang

[Matt Yates]

Package: cinnamon-settings-daemon
Version: 5.0.4-2
Severity: normal
X-Debbugs-Cc: matthew.z.ya...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?

When shutting down from the cinnamon menu, there is a 1 minute 29 second delay
with a message "A stop job is running...".  In review os syslog, it appears
that the job is related to cinnamon-settings-daemon.  Example messages from
syslog:

Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06708s:
Application 'cinnamon-settings-daemon-a11y-settings.desktop' killed by signal
15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06711s:
Application 'cinnamon-settings-daemon-orientation.desktop' killed by signal 15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06713s:
Application 'cinnamon-settings-daemon-power.desktop' killed by signal 15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06714s:
Application 'cinnamon-settings-daemon-sound.desktop' killed by signal 15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06717s:
Application 'cinnamon-settings-daemon-mouse.desktop' killed by signal 15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06719s:
Application 'cinnamon-settings-daemon-background.desktop' killed by signal 15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06729s:
Application 'cinnamon-settings-daemon-a11y-keyboard.desktop' killed by signal
15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06731s:
Application 'cinnamon-settings-daemon-wacom.desktop' killed by signal 15
Oct 17 01:01:23 duster cinnamon-session[5028]: WARNING: t+30492.06733s:
Application 'cinnamon.desktop' killed by signal 15


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

If the user first logs out of cinnamon before initiating shutdown, there is no
delay.

   * What was the outcome of this action?

Normal shutdown if user logs out of cinnamon session before initiating
shutdown,

   * What outcome did you expect instead?

Normal shutdown when initiating shutdown from cinnamon menu.

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


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

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

Versions of packages cinnamon-settings-daemon depends on:
ii  cinnamon-desktop-data5.0.0-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  gir1.2-cvc-1.0   5.0.0-2
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libcanberra-gtk3-0   0.30-8
ii  libcanberra0 0.30-8
ii  libcinnamon-desktop4 5.0.0-2
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-7
ii  libcvc0  5.0.0-2
ii  libdbus-glib-1-2 0.112-2
ii  libfontconfig1   2.13.1-4.2
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgnomekbd8 3.26.1-1+b1
ii  libgtk-3-0   3.24.30-3
ii  libgudev-1.0-0   237-2
ii  liblcms2-2   2.12~rc1-2
ii  libnotify4   0.7.9-3
ii  libnspr4 2:4.32-1
ii  libnss3  2:3.70-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpolkit-gobject-1-00.105-31
ii  libpulse015.0+dfsg1-2
ii  librsvg2-2   2.50.7+dfsg-2
ii  libsystemd0  249.5-1
ii  libupower-glib3  0.99.13-1
ii  libwacom21.11-1
ii  libx11-6 2:1.7.2-2+b1
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.8-1
ii  libxklavier165.4-4
ii  libxtst6 2:1.2.3-1
ii  python3-tinycss  0.4-3+b4

Versions of packages cinnamon-settings-daemon recommends:
ii  cinnamon-l10n  5.0.2-2
ii  pulseaudio 15.0+dfsg1-2

Versions of packages cinnamon-settings-daemon suggests:
ii  

Bug#996655: updating database with dbconfig-no-thanks doesn't seem to work

[David Mandelberg]

Op 16-10-2021 om 19:13 schreef Guilhem Moulin:

On Sat, 16 Oct 2021 at 17:45:42 -0400, David Mandelberg via 
Pkg-roundcube-maintainers wrote:

$ sudo -u www-data /usr/share/roundcube/bin/update.sh
ERROR: Configuration error. Unsupported database driver:


I suppose the command doesn't have RCUBE_CONFIG_PATH=/etc/roundcube in
its environment.  Should work better when adding it.


That worked, thank you! (It would still be nice to have updatedb.sh in 
the package, but I can work with this.)


$ sudo -u www-data RCUBE_CONFIG_PATH=/etc/roundcube 
/usr/share/roundcube/bin/update.sh

What version are you upgrading from? Type '?' if you don't know.
?
Executing database schema update.
This instance of Roundcube is up-to-date.
Have fun!

Bug#996667: kernel panic with kernel upgrade on diskless PXE + NFS system

[debian]

Package: linux-image-4.19.0-17-amd64
Version: 4.19.194-3
Severity: critical


I have the following packages installed:

linux-image-4.19.0-16-amd64
linux-image-4.19.0-17-amd64
linux-image-4.19.0-18-amd64

The system boots PXE on NFS--completely diskless.  eth0 connects to the
PXE/NFS server.  The -16 release runs just fine.  I tried to upgrade to
the -18, and then -17, releases by switching the PXE configuration, but
both failed.  The -18 release failed at:

--
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/nfs-top ... done.
Begin: Running /scripts/nfs-premount ... done.
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: eth0: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
/init: .: line 275: can't open '/run/net-eth0.conf': No such file or directory
[4.xx] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0200
--

etc.  (Retyped from a photo.)  The -17 release output is the same.

I don't know what file "line 275" refers to.

There were a lot of updates from 4.19.181-1 to 4.19.194-3.

Bug#996666: Xen PVH domains lack console

[Elliott Mitchell]

Package: grub-xen-host
Version: 2.04-20

I'm unsure which versions from stable were tried, but at a minimum
2.02+dfsg1-20+deb10u4 was and also had this issue.  I'm also unsure
whether this is actually a GRUB bug versus a Linux kernel bug.

When booting in x86 PVH mode the Linux kernel fails to load the Xen
virtual console as console.  As a result the kernel's dmesg is
unavailable for debugging during boot.

When using grub-x86_64-xen.bin (x86 PV mode) as Xen kernel:
$ cat /proc/consoles
tty0 -WU (EC p  )4:1
hvc0 -W- (E  p  )  229:0
$ 

When using grub-i386-xen_pvh.bin (x86 PVH mode) as Xen kernel:
$ cat /proc/consoles
tty0 -WU (EC p  )4:1
$ 


When using Tianocore's XEN_EFI.fd (arm64 PVH mode) as Xen kernel:
$ cat /proc/consoles
hvc0 -W- (EC p  )  229:0
$ 

Presently I think GRUB is more likely the culprit, but this is far from
certain.  Notably there are a few messages from the ACPI code, so I'm
wondering if GRUB sets up an ACPI table which isn't quite right.

I'm surprised at "tty0" being listed given the complete lack of any
sort of potential console device.  Yet this is x86, so I can understand.


-- 
(\___(\___(\__  --=> 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#996665: RFP: fcitx5-anthy -- Fcitx5 wrapper for Anthy IM engine

[Jun Nogata]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-input-met...@lists.debian.org

* Package name: fcitx5-anthy
* URL : https://gitlab.com/fcitx/fcitx5-anthy
* License : GPL2+
  Description : fcitx5-anthy is a wrapper of Anthy IM engine for Fcitx5.


-- 
野方 純 (Jun Nogata) - mail: noga...@gmail.com
 - web: http://www.nofuture.tv/diary/

Bug#991946: cython: Much newer version available

[Sandro Tosi]

control: retitle -1 cython: please package 0.29.24
control: severity -1 important


> the latest being 0.29.24 which came out in July 2021. I would so much
> appreciate it if you could find the time to update your Debian package.

The latest numpy release needs 0.29.24, so without it i cannot package that
version; please update cython to it. If you prefer i can upload it
directly, just let me know

Regards,
Sandro

Bug#996655: updating database with dbconfig-no-thanks doesn't seem to work

[David Mandelberg]

Package: roundcube-core
Version: 1.4.11+dfsg.1-4

I set up roundcube with dbconfig-no-thanks and a sqlite3 database, and 
the web interface is working. The script to update everything fails though:


$ sudo -u www-data /usr/share/roundcube/bin/update.sh
ERROR: Configuration error. Unsupported database driver:

I actually just want to upgrade the database schema though, not the 
config file. It looks like upstream has a script for that[0], but I 
don't see that file in the roundcube-core package.


 [0] 
https://github.com/roundcube/roundcubemail/blob/release-1.4/bin/updatedb.sh

Bug#991761: [Pkg-javascript-devel] Bug#991761: ITP: swc -- A super-fast typescript / javascript compiler written in rust

[Jonas Smedegaard]

Quoting Jérémy Lal (2021-10-15 17:15:43)
> Le ven. 15 oct. 2021 à 16:20, Jonas Smedegaard  a écrit :
> > Quoting Jérémy Lal (2021-08-01 12:01:46)
> > > * Package name: swc
> >
> > What is status on this?
> >
> 
> Nothing done.
> 
> 
> > Would you be interested in my help on creating+maintaining this?
> 
> Of course ! I created this ITP to lure someone into it :)

Excellent.

As you might have noticed, I prepared some build-dependencies.


> First thing is to make sure debian rustc version matches upstream 
> requirement...

...and no, the issue with requiring nightly is not crucial: I have 
patched it away in the preliminary packaging now living at 
https://salsa.debian.org/js-team/node-swc-core


 - Jonas

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

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

signature.asc
Description: signature

Bug#996661: clang-13: -static -fsanitize=undefined causes seg fault of a.out

[Ryutaroh Matsumoto]

Package: clang-13
Version: 1:13.0.0-5
Severity: normal

Dear Maintainer,

-static -fsanitize=undefined causes unusable a.out as below:
$ clang-13 -static -fsanitize=undefined hello.c 
$ ./a.out 
Segmentation fault

On the other hand, gcc-11 produces a usable a.out:
$ gcc-11 -static -fsanitize=undefined hello.c 
$ ./a.out 
hello world!

Best regards, Ryutaroh Matsumoto


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.14.12-clang13 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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 clang-13 depends on:
ii  binutils2.37-7
ii  libc6   2.32-4
ii  libc6-dev   2.32-4
ii  libclang-common-13-dev  1:13.0.0-5
ii  libclang-cpp13  1:13.0.0-5
ii  libclang1-131:13.0.0-5
ii  libgcc-11-dev   11.2.0-9
ii  libgcc-s1   11.2.0-9
ii  libllvm13   1:13.0.0-5
ii  libobjc-11-dev  11.2.0-9
ii  libstdc++-11-dev11.2.0-9
ii  libstdc++6  11.2.0-9

Versions of packages clang-13 recommends:
ii  llvm-13-dev  1:13.0.0-5
ii  python3  3.9.2-3

Versions of packages clang-13 suggests:
pn  clang-13-doc  

-- no debconf information

Bug#996660: file: mistake statically linked PIE executables as dynamically linked

[Ryutaroh Matsumoto]

Package: file
Version: 1:5.39-3
Severity: normal

Dear Maintainer,

Statically linked PIE executable are mistaken as dynamically linked as below:

$ clang-13 -static -fPIE -static-pie hello.c 
$ ldd a.out
statically linked
$ file a.out
a.out: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux), 
dynamically linked, BuildID[sha1]=8fb93260326c669fd2b80d0863ca0c536d425c19, for 
GNU/Linux 3.7.0, not stripped

Best regards, Ryutaroh Matsumoto

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.14.12-clang13 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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 file depends on:
ii  libc6  2.32-4
ii  libmagic1  1:5.39-3

file recommends no packages.

file suggests no packages.

-- no debconf information

Bug#996653: RFS: dynarmic/5+git20211012.cce7e4e+ds-1 [ITP] -- ARM dynamic recompiler

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name: dynarmic
   Version : 5+git20211012.cce7e4e+ds-1
   Upstream Author : MerryMage 
 * URL : https://github.com/merryhime/dynarmic
 * License : 0BSD
   Section : libs

It builds those binary packages:

  libdynarmic5 - ARM dynamic recompiler
  libdynarmic-dev - ARM dynamic recompiler - development

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/dynarmic/dynarmic_5+git20211012.cce7e4e+ds-1.dsc

Changes for the initial release:

 dynarmic (5+git20211012.cce7e4e+ds-1) unstable; urgency=low
 .
   * Initial release. Closes: #995917

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYWstVhQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7VGiAQC1ZMt5Empo4/tAGddW8q0fIVmz6ncr
ZAkWwOkft9mAUQEA5sZ3uI3hhmgMYUbmBrycBVw5mHI1zgTLPhDWNyVIRA8=
=TBzT
-END PGP SIGNATURE-

Bug#996659: gcc-11: static-pie cause link failure

[Ryutaroh Matsumoto]

Package: gcc-11
Version: 11.2.0-9
Severity: normal

Dear Maintainer,

gcc-11 -static -fPIE -static-pie hello.c  causes the following link failure:

/usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/11/crtbeginT.o: warning: relocation 
against `__deregister_frame_info' in read-only section `.rodata.cst8'
/usr/bin/ld: read-only segment has dynamic relocations
collect2: error: ld returned 1 exit status

On the other hand, clang-13 can handle the same situation better as below:

$ clang-13 -static -fPIE -static-pie hello.c 
$ ./a.out 
hello world!

Best regards, Ryutaroh Matsumoto

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.14.12-clang13 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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 gcc-11 depends on:
ii  binutils   2.37-7
ii  cpp-11 11.2.0-9
ii  gcc-11-base11.2.0-9
ii  libc6  2.32-4
ii  libcc1-0   11.2.0-9
ii  libgcc-11-dev  11.2.0-9
ii  libgcc-s1  11.2.0-9
ii  libgmp10   2:6.2.1+dfsg-2
ii  libisl23   0.23-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 11.2.0-9
ii  libzstd1   1.4.8+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gcc-11 recommends:
ii  libc6-dev  2.32-4

Versions of packages gcc-11 suggests:
pn  gcc-11-doc  
pn  gcc-11-locales  

-- no debconf information

Bug#996655: updating database with dbconfig-no-thanks doesn't seem to work

[Guilhem Moulin]

On Sat, 16 Oct 2021 at 17:45:42 -0400, David Mandelberg via 
Pkg-roundcube-maintainers wrote:
> $ sudo -u www-data /usr/share/roundcube/bin/update.sh
> ERROR: Configuration error. Unsupported database driver:

I suppose the command doesn't have RCUBE_CONFIG_PATH=/etc/roundcube in
its environment.  Should work better when adding it.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#996658: ITP: libcli-osprey-perl -- module to assist in writing commandline applications with OO modules

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcli-osprey-perl
  Version : 0.08
  Upstream Author : Andrew Rodland 
* URL : https://metacpan.org/release/CLI-Osprey
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to assist in writing commandline applications with 
OO modules

CLI::Osprey is a module to assist in writing commandline applications with M*
OO modules (Moose, Moo, Mo). With it, you structure your app as one or more
modules, which get instantiated with the commandline arguments as attributes.
Arguments are parsed using Getopt::Long::Descriptive, and both long and short
help messages as well as complete manual pages are automatically generated.
An app can be a single command with options, or have sub-commands (like git).
Sub-commands can be defined as modules (with options of their own) or as
simple coderefs.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#991177: libdebian-installer: reproducible builds: Embeds build path in libdebian-installer-extra.so.*

[Vagrant Cascadian]

On 2021-07-16, Cyril Brulebois wrote:
> Vagrant Cascadian  (2021-07-16):
>> The build path is embedded in various places in
>> libdebian-installer-extra.so.*:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libdebian-installer.html
>> 
>>   ./usr/lib/x86_64-linux-gnu/libdebian-installer-extra.so.4.0.8 
>> 
>>   /build/1st/libdebian-installer-0.121/build/src/../../src/list.c:30
>>   vs.
>>   /build/2/libdebian-installer-0.121/2nd/build/src/../../src/list.c:30
>> 
>> The attached patch fixes this by passing -ffile-prefix-map to CFLAGS in
>> debian/rules.
>> 
>> Alternately, with recent versions of dpkg, using dpkg-buildflags to set
>> CFLAGS should pass this option by default.
>> 
>> 
>> Thanks for maintaining libdebian-installer!
>
> I know we haven't always been stellar when it comes to merging repro
> build work, sorry about that. Any chance you could chase^Wremind us
> about such issues once Bullseye (r0, and maybe r1) is out the door?

The long-awaited requested reminder... is here! :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#996328: further information

[David Christensen]

I moved the Debian 10 disk into the Dell Latitude E6520 laptop with 
optimus graphics.  I logged in and opened my usual set of applications 
-- Thunderbird, Firefox, 2 Thunderbird, and 6 Terminal.  I started the 
Oracle VM VirtualBox Manager and started a VM in headless mode and then 
closed the Manager.  I used the machine for several hours without any 
problems.  When I moved the mouse pointer from a Terminal window into 
the Xfce panel, the GUI freaked out, several things flashed on and off 
the desktop, and I ended up with a dialog asking me to confirm deletion 
of Workspace 2.



David

Bug#996657: ITP: libtest-lib-perl -- module to use libraries from a t/lib directory

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-lib-perl
  Version : 0.002
  Upstream Author : haarg - Graham Knop (cpan:HAARG) 
* URL : https://metacpan.org/release/Test-Lib
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to use libraries from a t/lib directory

Test::Lib searches upward from the calling module for a directory t with a
lib directory inside it, and adds it to the module search path. Looks upward
up to 5 directories. This is intended to be used in test modules either
directly in t or in a subdirectory to find their included testing libraries
located in t/lib.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#996655: Processed: forcibly merging 996613 996655

[Guilhem Moulin]

Control: unmerge -1
Control: severity -1 normal

On Sat, 16 Oct 2021 at 18:42:11 -0400, David Mandelberg wrote:
> Why were these two merged?

Read too fast.  Sorry.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#996656: celluloid: can't parse backslash in MPV options

[Nicholas Guriev]

Package: celluloid
Version: 0.20-2

Dear maintainer,

Celluloid crashes or hangs if encounters backslash \ in a config. In
both cases below, the app cannot recover even after restarting.

Steps to reproduce the first case:

   1. Go to Preferences > Miscellaneous.
   2. In the Extra MPV options field put backslash "\" (with no quotes).
   3. Click Save.

Actual behaviour:

   1. The program hangs constantly printing to stderr the next line.

   ** (io.github.celluloid_player.Celluloid:32557): WARNING **: 18:47:15.492: 
Failed to apply option: --=(null)

Expected behaviour:

   1. The program complains about an invalid option.


Steps to reproduce the second case:

   1. Go to Preferences > Miscellaneous.
   2. In the Extra MPV options field type the following                
  --ytdl-raw-options=sub-langs=ru\,eo
   3. Click Save.

Actual behaviour:

   1. The program quits printing to stderr an assert message.

ERROR:celluloid-option-parser.c:83:eval_match: code should not be reached
Bail out! ERROR:celluloid-option-parser.c:83:eval_match: code should not be 
reached
Aborted

Expected behaviour:

   1. The youtube-dl script receives --sub-langs=ru,eo
   2. Or at least, Celluloid reports an error with dialog box.



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

Bug#994193: iptstate FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[Phil Dibowitz]

Got 2.2.7 out the door.

Can someone who's a DD do the honors?

On 9/13/21 6:33 AM, Helmut Grohne wrote:

Source: iptstate
Version: 2.2.6-1
Severity: serious
Tags: ftbfs

iptstate fails to build from source in unstable. A build ends as
follows:

| g++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security iptstate.cc -o iptstate -lncurses -lnetfilter_conntrack
| iptstate.cc: In function ‘void get_input(WINDOW*, std::string&, const string&, 
const flags_t&)’:
| iptstate.cc:685:30: error: format not a string literal and no format 
arguments [-Werror=format-security]
|   685 |   wprintw(cmd, prompt.c_str());
|   |  ^
| iptstate.cc: In function ‘void c_warn(WINDOW*, const string&, const 
flags_t&)’:
| iptstate.cc:750:32: error: format not a string literal and no format 
arguments [-Werror=format-security]
|   750 |   wprintw(warn, warning.c_str());
|   |^
| iptstate.cc: In function ‘int conntrack_hook(nf_conntrack_msg_type, 
nf_conntrack*, void*)’:
| iptstate.cc:1002:30: warning: ‘:’ directive output may be truncated writing 1 
byte into a region of size between 0 and 5 [-Wformat-truncation=]
|  1002 |   snprintf(ttlc,11, "%3i:%02i:%02i", hours, minutes, seconds);
|   |  ^
| iptstate.cc:1002:21: note: directive argument in the range [-59, 59]
|  1002 |   snprintf(ttlc,11, "%3i:%02i:%02i", hours, minutes, seconds);
|   | ^~~
| iptstate.cc:1002:11: note: ‘snprintf’ output between 10 and 16 bytes into a 
destination of size 11
|  1002 |   snprintf(ttlc,11, "%3i:%02i:%02i", hours, minutes, seconds);
|   |   ^~~
| cc1plus: some warnings being treated as errors
| make[1]: *** [Makefile:34: iptstate] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:4: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut




--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#996595: nvidia-legacy-390xx-driver: NVIDIA service is not starting with the system

[Alessandro Reis de Alcântara]

I uninstall all nvidia related package, before The installation to send The
bug report... I used The following commands to uninstall everything:

apt remove - -purge nvida* libnvidia*
apt autoremove

After this, i rebooted and then installed Just The
nvidia-legacy-390xx-driver.

I dont know why The libnvidia-config was installed together...

I'll verify your recomendations and give you a feedback.

Thanks a lot.

Em sáb., 16 de out. de 2021 17:33, Andreas Beckmann 
escreveu:

> Thanks.
>
> Please also send the output of
>
> update-alternatives --display glx
> update-alternatives --display nvidia
>
> Do you know why you have libnvidia-cfg1 (from the current, not the
> legacy driver)installed? That probably stems from the attempt to install
> nvidia-settings for the current driver.
> (You also have libnvidia-legacy-390xx-cfg1 installed.)
>
> If you uninstall libnvidia-cfg1 everything should be back to normal again.
>
> Andreas
>

Bug#996645: kodi: please add support for riscv64

[Vasyl Gello]

Hi!

>No, I have only found in the master branch. However I don't know
>upstream development enough to know if there are chances this is
>backported to the Matrix branch. It has been accepted relatively
>recently (end of August).

If it is not a mainstream architecture Team Kodi's PPA supports on Ubuntu,
OR there is official request from Debian (which goes through me bc I am
Team Kodi member since the beginning of the month), and there is no
bug in 19.x, unlikely it will be ported to a bugfix 19.x branch.

You should think of 19.x as Debian stable :) Bugfixes and only them.

However, to be honest, I took the responsibility to backport some big fixes
that are even not merged in master (cdatetime for example).

>I was initially expecting to have this in 19.x, as it seems that 20.x
>will not be realeased before many months. However I understand that it
>causes maintainability issues on your side, so that can perfectly wait
>for 20.x.  It would be nice to have it in 19.x if it happens that
>bookworm still ship with 19.x though.

If we diverge +deb11u1 and go stable-bpo / oldstable-bpo-sloppy way,
then it is OK to have your fix in 19.x. If not, let's expect with 20.x 
nightlies.

I am not sure if I manage to achieve my goal on delivering timely updates
to all Debian users even for Kodi, not speaking of add-ons, so I am now
trying to find a strategy that minimizes time to user :)

>Ok thanks. Do you have a rough idea when is 20.x planned?

Atm, not even roadmap that I have seen in internal team space :(
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#996580: Acknowledgement (vmdb2 hangs in the mkpart plugin after a lvcreate because of device mapper paths)

[Josip Rodin]

Hm, actually loop doesn't work well either, because the same piece of code
tries to access /dev/loop01 instead of the actual /dev/loop0p1

Once I fix that, it still later fails with:

Exec: ['blkid', '-c', '/dev/null', '-o', 'value', '-s', 'UUID', '/dev/loop0p1']
Installing GRUB for BIOS
ERROR: Do not understand partition device name /dev/loop0p1
ERROR: Exception('Do not understand partition device name /dev/loop0p1')
Something went wrong, cleaning up!

I found in the code that I could override that in the grub plugin by
specifying:

image-dev: "/dev/mapper/vg0-myvm--root"

However, even this failed with:

2021-10-16 22:09:37 INFO Exec: ['chroot', '/tmp/tmpy9lcantw', 'grub-install', 
'--target=i386-pc', '--no-nvram', '--force-extra-removable', '--no-floppy', 
'--modules=part_msdos part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', 
'/dev/mapper/vg0-myvm--root']
2021-10-16 22:09:37 DEBUG STDOUT:
2021-10-16 22:09:37 DEBUG STDERR: Installing for i386-pc platform.
grub-install: error: diskfilter writes are not supported.

2021-10-16 22:09:37 ERROR Program failed: 1

So, uhh, I'm a bit stuck here. This used to work under vmdebootstrap...

-- 
Josip Rodin

Bug#996580: Acknowledgement (vmdb2 hangs in the mkpart plugin after a lvcreate because of device mapper paths)

[Josip Rodin]

On Sat, Oct 16, 2021 at 10:42:38PM +0200, Josip Rodin wrote:
> Installing GRUB for BIOS
> ERROR: Do not understand partition device name /dev/loop0p1
> ERROR: Exception('Do not understand partition device name /dev/loop0p1')
> Something went wrong, cleaning up!
> 
> I found in the code that I could override that in the grub plugin by
> specifying:
> 
> image-dev: "/dev/mapper/vg0-myvm--root"
> 
> However, even this failed with:
> 
> 2021-10-16 22:09:37 INFO Exec: ['chroot', '/tmp/tmpy9lcantw', 'grub-install', 
> '--target=i386-pc', '--no-nvram', '--force-extra-removable', '--no-floppy', 
> '--modules=part_msdos part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', 
> '/dev/mapper/vg0-myvm--root']
> 2021-10-16 22:09:37 DEBUG STDOUT:
> 2021-10-16 22:09:37 DEBUG STDERR: Installing for i386-pc platform.
> grub-install: error: diskfilter writes are not supported.
> 
> 2021-10-16 22:09:37 ERROR Program failed: 1

As it happens, this actually does work with:

image-dev: "{{ image }}"

The log then simply says:

Exec: ['chroot', '/tmp/tmp65a32lou', 'grub-install', '--target=i386-pc', 
'--no-nvram', '--force-extra-removable', '--no-floppy', '--modules=part_msdos 
part_gpt', '--grub-mkdevicemap=/boot/grub/device.map', '/dev/loop0']

-- 
Josip Rodin

Bug#996645: kodi: please add support for riscv64

[Aurelien Jarno]

Hi,

On 2021-10-16 19:38, Vasyl Gello wrote:
> Hi Aurelien!
> 
> Thanks for the great contribution!

Thanks for your fast answer!

> - I modified debian/rules to pass -DWITH_ARCH=riscv64. It's not clear if
> >  that part should go upstream, it seems given we do not have CPU
> >  specific optimizations to add in cmake/scripts/linux/ArchSetup.cmake
> >  so it's not fully necessary. Please tell me if I am wrong, I'll submit
> >  that upstream
> 
> The Debian packaging for Debian and upstream are totally different,
> so you can send only cmake/scripts/linux/ArchSetup.cmake part there
> if needed.

Ok, thanks for the feedback. I'll send that part upstream, so that entry
from debian/rules can be dropped.

> >- Patch 0024-add-riscv-compile-defines.patch is coming from upstream and
> >  will be in Kodi 20. It conflicts with 0006-fix-s390x-build and
> >  0009-fix-alpha-build patches whichh touch the same files. As 0024 is
> >  already upstream and will appear at some point in the Debian package,
> >  I have moved the 0006 and 0009 patches after it and "rebased" them as
> >  0025 and 0026.
> 
> I must check if 19.x has that patch. As for 20.x nightlies, let me explain my 
> intention below

No, I have only found in the master branch. However I don't know
upstream development enough to know if there are chances this is
backported to the Matrix branch. It has been accepted relatively
recently (end of August).

> >- Patch 0027-link-with-pthread.patch changes the way cmake handles
> >  Thread support to correctly link with -pthread instead of -lpthread.
> >  That way GCC automatically pulls in -latomic if needed. I have noticed
> >  that debian/rules already forces LDFLAGS to contain -latomic, however
> >  it appears too early in the linker command to be early (it needs to be
> >  after the objects needing this library).
> 
> Does it apply to other architectures? I recall I had to fix "-latomic" stuff 
> in
> KissFFT… 

Unfortunately no. Note however that riscv64 behaves differently than
other architectures wrt libatomic, as it has native support for 32-bit
and 64-bit atomics. It however lacks 1-bit atomics.

> >If you are fine with this patch, could you please consider applying it
> >in the future uploads? If you aren't, do not hesitate to comment, ask
> >for more details or ask for changes to the patch
> 
> Do you expect to have this in 19.x or 20.x? Right now, I would like to have 
> 19.x
> propagated across unstable, testing, stable and oldstable-backports.

I was initially expecting to have this in 19.x, as it seems that 20.x
will not be realeased before many months. However I understand that it
causes maintainability issues on your side, so that can perfectly wait
for 20.x.  It would be nice to have it in 19.x if it happens that
bookworm still ship with 19.x though.

> However, I don't know if SRM accept changes of every upcoming bugfix release,
> so I try to keep debdiffs for 19.x as small as possible. Of course there 
> might be
> a solution by diverting +deb11u1 but let's get 19.2 into stable first.

Yes, the patch I sent you is definitely not acceptable for stable.

> As for 20.x, I will be building unofficial repo for stable-backports and 
> unstable/testing,
> and there we can experiment as we like.

Ok thanks. Do you have a rough idea when is 20.x planned?

Regards,
Aurelien

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

Bug#976334: libgtk-3-0: File choser does not display the list of folders on NFS access

[Ian Campbell]

Package: libgtk-3-0
Version: 3.24.24-4
Followup-For: Bug #976334

Dear Maintainer,

I am also seeing this behaviour when searching for documents in evince's open
dialog when pointing anywhere in my NFS home directory.

Since this bug is present in stable/bullseye and there is an upstream patch
would a stable update be possible? Not being able to search in the open dialog
is moderately annoying in practice.

Thanks,
Ian.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3+deb11u1
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-common  3.24.24-4
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.24-4
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs  1.46.2-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
pn  ibus-gtk3 
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#996595: nvidia-legacy-390xx-driver: NVIDIA service is not starting with the system

[Andreas Beckmann]

Thanks.

Please also send the output of

update-alternatives --display glx
update-alternatives --display nvidia

Do you know why you have libnvidia-cfg1 (from the current, not the 
legacy driver)installed? That probably stems from the attempt to install 
nvidia-settings for the current driver.

(You also have libnvidia-legacy-390xx-cfg1 installed.)

If you uninstall libnvidia-cfg1 everything should be back to normal again.

Andreas

Bug#994193: iptstate FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[Phil Dibowitz]

This is fixed in:

https://github.com/jaymzh/iptstate/commit/9c6b31162c2c8c5bad25ac5266ec98ce932685e2

I'll try to get a release out the door soon, but the maintainer might 
want to pull in the commit in the meantime.


On 9/13/21 6:33 AM, Helmut Grohne wrote:

Source: iptstate
Version: 2.2.6-1
Severity: serious
Tags: ftbfs

iptstate fails to build from source in unstable. A build ends as
follows:

| g++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security iptstate.cc -o iptstate -lncurses -lnetfilter_conntrack
| iptstate.cc: In function ‘void get_input(WINDOW*, std::string&, const string&, 
const flags_t&)’:
| iptstate.cc:685:30: error: format not a string literal and no format 
arguments [-Werror=format-security]
|   685 |   wprintw(cmd, prompt.c_str());
|   |  ^
| iptstate.cc: In function ‘void c_warn(WINDOW*, const string&, const 
flags_t&)’:
| iptstate.cc:750:32: error: format not a string literal and no format 
arguments [-Werror=format-security]
|   750 |   wprintw(warn, warning.c_str());
|   |^
| iptstate.cc: In function ‘int conntrack_hook(nf_conntrack_msg_type, 
nf_conntrack*, void*)’:
| iptstate.cc:1002:30: warning: ‘:’ directive output may be truncated writing 1 
byte into a region of size between 0 and 5 [-Wformat-truncation=]
|  1002 |   snprintf(ttlc,11, "%3i:%02i:%02i", hours, minutes, seconds);
|   |  ^
| iptstate.cc:1002:21: note: directive argument in the range [-59, 59]
|  1002 |   snprintf(ttlc,11, "%3i:%02i:%02i", hours, minutes, seconds);
|   | ^~~
| iptstate.cc:1002:11: note: ‘snprintf’ output between 10 and 16 bytes into a 
destination of size 11
|  1002 |   snprintf(ttlc,11, "%3i:%02i:%02i", hours, minutes, seconds);
|   |   ^~~
| cc1plus: some warnings being treated as errors
| make[1]: *** [Makefile:34: iptstate] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:4: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut




--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#989805: collectd-core: nut plugin missing

[Kevin Otte]

Yep, this broke collectd on my main home server.
Relatively easy to go comment out, but still pretty annoying along with 
the other bugs I'm still chasing down.

Bug#996618: [Pkg-opencl-devel] Bug#996618: libhmsbeagle1v5

[Andreas Beckmann]

On 16/10/2021 12.12, Adrian Bunk wrote:

   Package: libhmsbeagle1v5
   Depends: ..., beignet-opencl-icd | mesa-opencl-icd | opencl-icd

I think it is a bug in any case that beignet-opencl-icd is listed
there as first alternative (which is triggering the autoremoval),
OpenCL Maintainers are in Cc for advising what the recommended
dependencies are.


Given that mesa-opencl-icd is available everywhere, I would just take 
that as first alternative and drop beignet entirely.


The question is, if that should be downgraded to a
  Recommends: mesa-opencl-icd | opencl-icd
since the Depends only ensures that there is any opencl-icd installed, 
not neccessarily one that supports the hardware present in the machine.
And for libhmsbeagle1v5 having no opencl platform available (if no icd 
is installed) should not be different than having some platform but no 
devices available ...


Andreas

Bug#996648: dkms: The templates in /etc/dkms are pointing do debhelper 7

[Elimar Riesebieter]

Control: found -1 2.6.1-4
Control: found -1 2.8.4-3
* Elimar Riesebieter  [2021-10-16 21:20 +0200]:

> Package: dkms
> Version: 2.8.7-2
> Severity: serious
> Justification: 5
> X-Debbugs-Cc: hostmast...@hostsharing.de


-- 
  Numeric stability is probably not all that
  important when you're guessing;-)

Bug#996265: autopkgtest: The dependency of each test is added to the dependencies of the following tests

[Paul Gevers]

Hi

Oops.

On 16-10-2021 21:50, Paul Gevers wrote:
> (they are installed *before* the apt call to install the test
> dependencies).

I don't know why I thought this, but I don't see it now, so it's
probably non-sense.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996654: upgrade-reports template mentions Sarge

[Bill Allombert]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal

Hello Thomas and Nis,
(Sorry if I reported this against the wrong packages, but you are the 
more likely to be able to fix it)

The upgrade-reports template includes the question
"- Was the system pre-update a pure sarge system? If not, which packages
  were not from sarge?"

In case you do not remember it, sarge was the stable release between
2005 and 2008, so this is not exactly current.
Maybe a wording that does not depend on the current oldstable name
should be preferred.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#996265: autopkgtest: The dependency of each test is added to the dependencies of the following tests

[Paul Gevers]

Hi Fab,

On 14-10-2021 21:17, Fab Stz wrote:
>> Are you sure -21.1.2-installer
>> has no Dependency itself on the lower version?
> 
> I checked again, I don't see such a dependency.

Ack.

> The test jobs are run from the automatic salsa-ci server. I don't know which 
> backend is actually used. Ci job is defined here: [4]

That seems to be relevant info. The log says they use the null runner,
but I think it runs in LXC. More importantly however, the potentially
interesting thing here is that they run with a .changes as input to
autopkgtest, while I normally see logs against archive binaries. It's
the handling of *a package own binaries* in the Depends that seems to go
wrong in the case they are installed from local binaries, instead of the
archive (they are installed *before* the apt call to install the test
dependencies). At least that hints that this issue is not a generic
issue, but only for a particular (supported) use case.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Vasyl Gello]

Hi Helmut!

>Why would you want to do that? stable releases do have bugs and unless
>they're severe, we don't usually fix them.

I want to keep 19.x updates consistent with upstream because all 19.x point 
releases
are bugfixes and only bugfixes. Plus, as a member of Team Kodi, it is my duty to
provide consistent experience to all Debian users.

For now I try to keep diversions as low as I can to avoid triple-quadruple 
manual work
(especially building!) which takes time.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#996645: kodi: please add support for riscv64

[Vasyl Gello]

Hi Aurelien!

Thanks for the great contribution!

- I modified debian/rules to pass -DWITH_ARCH=riscv64. It's not clear if
>  that part should go upstream, it seems given we do not have CPU
>  specific optimizations to add in cmake/scripts/linux/ArchSetup.cmake
>  so it's not fully necessary. Please tell me if I am wrong, I'll submit
>  that upstream

The Debian packaging for Debian and upstream are totally different,
so you can send only cmake/scripts/linux/ArchSetup.cmake part there
if needed.

>- Patch 0024-add-riscv-compile-defines.patch is coming from upstream and
>  will be in Kodi 20. It conflicts with 0006-fix-s390x-build and
>  0009-fix-alpha-build patches whichh touch the same files. As 0024 is
>  already upstream and will appear at some point in the Debian package,
>  I have moved the 0006 and 0009 patches after it and "rebased" them as
>  0025 and 0026.

I must check if 19.x has that patch. As for 20.x nightlies, let me explain my 
intention below

>- Patch 0027-link-with-pthread.patch changes the way cmake handles
>  Thread support to correctly link with -pthread instead of -lpthread.
>  That way GCC automatically pulls in -latomic if needed. I have noticed
>  that debian/rules already forces LDFLAGS to contain -latomic, however
>  it appears too early in the linker command to be early (it needs to be
>  after the objects needing this library).

Does it apply to other architectures? I recall I had to fix "-latomic" stuff in
KissFFT… 

>If you are fine with this patch, could you please consider applying it
>in the future uploads? If you aren't, do not hesitate to comment, ask
>for more details or ask for changes to the patch

Do you expect to have this in 19.x or 20.x? Right now, I would like to have 19.x
propagated across unstable, testing, stable and oldstable-backports.

However, I don't know if SRM accept changes of every upcoming bugfix release,
so I try to keep debdiffs for 19.x as small as possible. Of course there might 
be
a solution by diverting +deb11u1 but let's get 19.2 into stable first.

As for 20.x, I will be building unofficial repo for stable-backports and 
unstable/testing,
and there we can experiment as we like.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Helmut Grohne]

On Sat, Oct 16, 2021 at 04:58:34PM +, Vasyl Gello wrote:
> >If you don't like removing
> >Multi-Arch: foreign from kodi-data, there is another way out: Move the
> >python modules to a new kodi-python-addons package. Move the relevant
> >python dependencies to this package. Make it Architecture: any (not
> >all). It can become Multi-Arch: same, but that won't help much. Any user
> >of it must depend on kodi-python-addons directly. A dependency from
> >kodi-data to kodi-python-addons is not sufficient (as kodi-data is
> >supposed to remain Multi-Arch: foreign).
> 
> This is what I want to do!

Great.

> However, this points to another drawback: we can not propagate modified 
> packages to
> stable and oldstable-bpo. So I guess removing "Multi-Arch: foreign" is better 
> for 19.x
> and for 20.x I am going to implement the refactored scheme of packages.

Why would you want to do that? stable releases do have bugs and unless
they're severe, we don't usually fix them. The M-A:foreign annotation
poses the risk of providing an installation set that does not actually
work, but the conflict on python3-pycryptodome largely prevents that
from happening practice. So why do you care about stable here?

> Is that OK to just drop "m-a: foreign" from kodi-data:all or I need something 
> more to fix?

As a short-term-fix that's certainly a good thing to d. For longer term,
the kodi-python-addons (or however you call it) solution would be
better.

Still, we'll need to figure out what to do about the conflict arising
from samba-libs to make this practically useful.

Helmut

Bug#996577: duplicity: Name error on backend HubiC (Basidentity)

[Kenneth Loafman]

This bug has been fixed in f9b5d595322c0f3463cdf6fb2cf168a259b738a9 which
will be released with 0.8,21.

fix:dev:Fixed Catch-22 in pyrax_identity.hubic.  Debian bug #996577

Name error on backend HubiC (Baseidentity).  Cannot avoid importing
pyrax since HubicIdentity requires pyrax.base_identity.BaseIdentity.

On Fri, Oct 15, 2021 at 1:06 PM BertrandB21 
wrote:

> Package: duplicity
> Version: 0.8.17-1+b1
> Severity: normal
>
> Dear Maintainer,
>
> Since the change of stable version i gopt an error on duplicty,
> I try wiht last version of pyrax
>
> the error :
> File
> "/usr/lib/python3/dist-packages/duplicity/backends/pyrax_identity/hubic.py",
> line 35, in 
> class HubicIdentity(BaseIdentity):
>  NameError: name 'BaseIdentity' is not defined
>
> -- System Information:
> Debian Release: 11.1
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
> 'stable-security')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-9-amd64 (SMP w/1 CPU thread)
> 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 duplicity depends on:
> ii  gnupg  2.2.27-2
> ii  libc6  2.31-13+deb11u2
> ii  librsync2  2.3.1-1
> ii  python33.9.2-3
> ii  python3-fasteners  0.14.1-2
> ii  python3-future 0.18.2-5
> ii  python3-lockfile   1:0.12.2-2.2
>
> Versions of packages duplicity recommends:
> ii  python3-oauthlib  3.1.0-2
> ii  python3-paramiko  2.7.2-1
> ii  python3-pexpect   4.8.0-2
> ii  python3-urllib3   1.26.5-1~exp1
> ii  rsync 3.2.3-4+deb11u1
>
> Versions of packages duplicity suggests:
> pn  lftp 
> pn  ncftp
> pn  par2 
> pn  python3-boto 
> ii  python3-pip  20.3.4-4
> ii  python3-swiftclient  1:3.10.1-2
> pn  tahoe-lafs   
>
> -- no debconf information
>
>

Bug#996651: i8kutils FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: i8kutils
Version: 1.43+nmu1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

i8kutils fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes i8kutils cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru i8kutils-1.43+nmu1/debian/changelog 
i8kutils-1.43+nmu2/debian/changelog
--- i8kutils-1.43+nmu1/debian/changelog 2021-02-06 14:57:18.0 +0100
+++ i8kutils-1.43+nmu2/debian/changelog 2021-10-16 21:22:25.0 +0200
@@ -1,3 +1,10 @@
+i8kutils (1.43+nmu2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 16 Oct 2021 21:22:25 +0200
+
 i8kutils (1.43+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru i8kutils-1.43+nmu1/debian/rules 
i8kutils-1.43+nmu2/debian/rules
--- i8kutils-1.43+nmu1/debian/rules 2017-03-06 23:37:27.0 +0100
+++ i8kutils-1.43+nmu2/debian/rules 2021-10-16 21:22:20.0 +0200
@@ -7,7 +7,7 @@
 build: build-arch build-indep
 build-arch:
dh_testdir
-   $(MAKE) CFLAGS="$(CFLAGS) $(CPPFLAGS) $(LDFLAGS)"
+   dh_auto_build -- CFLAGS="$(CFLAGS) $(CPPFLAGS) $(LDFLAGS)"
touch $@
 
 clean:

Bug#996652: libcoap3 FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: libcoap3
Version: 4.3.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libcoap3 fails to cross build from source, because configure.ac hard
codes the build architecture pkg-config. The attached patch replaces it
with the host architecture one and makes libcoap3 cross buildable.
Please consider applying it.

Helmut
--- libcoap3-4.3.0.orig/configure.ac
+++ libcoap3-4.3.0/configure.ac
@@ -435,7 +435,7 @@
 AC_MSG_NOTICE([The use of GnuTLS was explicitly requested with configure option '--with-gnutls'!])
 
 # check for valid GnuTLS version
-gnutls_version=`pkg-config --modversion gnutls`
+gnutls_version=`$PKG_CONFIG --modversion gnutls`
 AX_CHECK_GNUTLS_VERSION
 have_openssl="no" # don't confuse AC_MSG_RESULT at the end of the script
 have_mbedtls="no" # don't confuse AC_MSG_RESULT at the end of the script
@@ -453,7 +453,7 @@
 AC_MSG_NOTICE([The use of OpenSSL was explicitly requested with configure option '--with-openssl'!])
 
 # check for valid OpenSSL version
-openssl_version=`pkg-config --modversion openssl`
+openssl_version=`$PKG_CONFIG --modversion openssl`
 AX_CHECK_OPENSSL_VERSION
 have_gnutls="no" # don't confuse AC_MSG_RESULT at the end of the script
 have_mbedtls="no" # don't confuse AC_MSG_RESULT at the end of the script
@@ -495,7 +495,7 @@
   # The user hasn't requested the use of a specific cryptography library
   # we try first GnuTLS for usability ...
   if test "x$have_gnutls" = "xyes"; then
-  gnutls_version=`pkg-config --modversion gnutls`
+  gnutls_version=`$PKG_CONFIG --modversion gnutls`
   AX_CHECK_GNUTLS_VERSION
   AC_MSG_NOTICE([Using auto selected library GnuTLS for DTLS support!])
   with_gnutls_auto="yes"
@@ -505,7 +505,7 @@
 
   # ... and if not found check OpenSSL is suitable.
   elif test "x$have_openssl" = "xyes"; then
-  openssl_version=`pkg-config --modversion openssl`
+  openssl_version=`$PKG_CONFIG --modversion openssl`
   AX_CHECK_OPENSSL_VERSION
   AC_MSG_NOTICE([Using auto selected library OpenSSL for DTLS support!])
   with_openssl_auto="yes"

Bug#996650: RM: citadel -- RoQA; Orphaned, RC buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove citadel. It's orphaned for over two years without an adopter
and removed from testing since years since the current package is broken
(939377). In addition there's open security issues.

Cheers,
 Moritz

Bug#996612: libexpat1-dev: incorrect path for INTERFACE_INCLUDE_DIRECTORIES in expat.cmake

[GCS]

On Sat, Oct 16, 2021 at 9:09 PM Matteo F. Vescovi  wrote:
> On 2021-10-16 at 20:41 (+02), László Böszörményi (GCS) wrote:
> >  It's just one patch. Why do you use it in plural?
>
> Well, they can be merged in one single patch, but they were born in two
> different moments so I have the two patches attached.
 As I see, fix-expat-cmake.patch is a no-op. It duplicates a single
line for no purpose. _IMPORT_PREFIX is deleted from
expat-noconfig.cmake in the other patch making it useless.
As I see, using that alone caused this (incorrect path) bug for you.

Cheers,
Laszlo/GCS

Bug#996569: getmail6 naming issues

[Charles Cazabon]

On Fri, 15 Oct 2021 10:55:40 -0600 Charles Cazabon wrote:
> 
> So: fork is fine.  Imposing a large support burden on the original project is
> not.  I would appreciate it if this package/project was renamed to something
> that does not contain the word "getmail" or anything confusingly similar.

I have a specific suggestion for Debian to address this issue.

1.  The upstream author, or if he refuses, the Debian package maintainer, can
pick a new package name that does not pollute my getmail package,
community, mailing list, and trademark, and which will stop imposing this
unwelcome support burden on me and the getmail mailing list/community.
I don't know what name you'll pick; for the rest of this proposal, let's
use "go-grab-my-email" as an example.

2.  Package it for Debian.  Have it use the `Obsoletes: getmail` metadata so
that users upgrading a Debian system have getmail correctly removed and
the go-grab-my-email package installed, similar to what happens with the
"getmail6" package now.

3.  Additionally, make the new package display an informational screen via
apt-listchanges when getmail is removed and go-grab-my-email is installed.
It should say something like:

The getmail package has been deprecated because the current version
depends on Python 2.7, which has been removed from Debian Foo.

From now on, run `go-grab-my-email` instead of `getmail`.  This package
aims to be a backwards-compatible Python 3 port of getmail.

This provides a seamless upgrade path for current getmail users, explicitly 
deprecates the getmail package and explains why to the user, installs the
replacement package, and tells the user what happened and how to continue with
their current getmail configuration.

And since they're no longer installing "getmail" or running "getmail", my
getmail users' mailing list and my personal email are no longer inundated with
poorly-documented support requests arising from users' confusion over the
"getmail6" name, or indeed their complete ignorance of the fact that getmail
has been removed and getmail6 installed on their system.  

I have had a number of requests from users who reported problems to me and were
not even aware this package had been installed on their system in place of
getmail during an upgrade.

Thank you,

Charles
-- 
--
Charles Cazabon  
Software, consulting, and services available at http://pyropus.ca/
--

Bug#996649: node-inquirer: please include @types/inquirer types

[Jonas Smedegaard]

Package: node-inquirer
Version: 8.2.0+~cs18.4.2-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

node-inquirer includes some TypeScript type files, but apparently there
is still a @types/inquirer and that is needed by upcoming package swc.

Please include @types/inquirer with node-inquirer.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFrJ6QACgkQLHwxRsGg
ASENDw//cgq9TWprtC6tD8EdiOlOGusy2nyflDKymt91qecbz8xwZqF6hlpNDZxN
iHnq0x6L/yiEJEVEfhHH+Jo2uy8da8FmlRyilR3g3+7POAvsKbvKGu01iFlv1eHj
+bGSX5XfydU3S+bjr56ux+1NODUAtrLoxLq0hQEI/zqHHqaQwgTY2F51CAnCNmw0
tmfONLcCcPFVGdNTMI4wRS7f+Iwz/NrszvrfRWRooqvxW80oI7RpZOv3O3mZ6cnf
z/yoYut/RLlEHwdszG46nrUdELxC8XpTUrbVPwab/SNFBRq3e6Lr1MwLn53DiyFE
qJ+avCE4vH2DgOxvCtuDm781Jvq1Sz/1S1j4KzO8OnkX9/oUDMUAJ97z6q5ARX1U
PxDpHjL/WymYKUSvrYzWdARykdA7XJ2JeZHGkh+T1Wt7ELbtmZB6Y0xJBc5ngHW6
rfCJBY6THbgrmm4UKNObbSJUAhHOQu5rwpwdD6Bqw2qFz/kFg20Qaramxkvri1bL
LO6xCcO+Ijf6mhM2XacTKoT+Xcp98RCS9UKrS7RA1G/HQFqBpin99Kv8HHVtG27o
Vv3+oveNMZ4lpqdDJ/9v3D/hkSsnN7X6Jp9WEKGz0leQTlbxNzO4q3DRCg5vLiyX
uJaGd9JE3deLQay1C9o54z49tGaVkJNy52NuwCoKuS1J5ay6O54=
=CERm
-END PGP SIGNATURE-

Bug#996647: /usr/bin/xdg-email: Re: xdg-utils: xdg-email doesn't work with Debian's Thunderbird wrapper script

[Alex]

Package: xdg-utils
Version: 1.1.3-4.1
Followup-For: Bug #855859

Dear Maintainer,

I installed Thunderbird and made it as my default mail program in the 
KDE Settings.
In libreoffice, the default emailer is set to sensible-lomua, the 
wrapper script which calls xdg-email. xdg-email searches his default 
settings in the KDE settings I made before.
When I want to send an email directly in Libreoffice, that one calls 
xdg-email which should call thunderbird, but instead I got:

/usr/bin/xdg-email: 599: thunderbird.desktop: not found

This is normal, as thunderbird.destop is not in a directroy of my PATH.

I reported this as an error to the maintainer of libreoffice, but he 
said that this is a bug caused by xdg-email.


In fact, I chose thunderbird in the settings of KDE by it's icon, which 
is proposed.

When I chose it directly as /bin/thunderbird, I got this error message too.


To get it work, I hardcoded in the xdg-email Script the variable 
THUNDERBIRD by "/bin/thunderbird" in line 558.

This works, but is an ugly workaround.

Can you help, please.

Thanx


-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=KDE

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_LU.UTF-8, LC_CTYPE=de_LU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.30-1
ii  libnet-dbus-perl   1.2.0-1+b1
ii  libx11-protocol-perl   0.56-7.1
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+8

xdg-utils suggests no packages.

Bug#984401: vtk7: ftbfs with GCC-11

[John David Anglin]

Source: vtk7
Version: 7.1.1+dfsg2-10+b2
Followup-For: Bug #984401

Dear Maintainer,

On hppa:

[  3%] Building CXX object 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o
cd /<>/debian/build/ThirdParty/xdmf2/vtkxdmf2/libsrc && 
/usr/bin/mpic++ -DLinux -DMPICH_IGNORE_CXX_SEEK -DVTK_IN_VTK -D_HPUX_SOURCE 
-Dvtkxdmf2_EXPORTS -I/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc 
-I/<>/debian/build/ThirdParty/xdmf2/vtkxdmf2/libsrc 
-I/<>/debian/build/ThirdParty/xdmf2 
-I/<>/ThirdParty/xdmf2 
-I/<>/debian/build/ThirdParty/hdf5 
-I/<>/ThirdParty/hdf5 -I/usr/include/hdf5/openmpi 
-I/<>/debian/build/ThirdParty/zlib 
-I/<>/ThirdParty/zlib 
-I/<>/debian/build/ThirdParty/libxml2 
-I/<>/ThirdParty/libxml2 -I/usr/include/libxml2 
-I/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/utils -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2  -w -w -w -fPIC -MD -MT 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o -MF 
CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o.d -o 
CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o -c 
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmMsg.cxx
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx: In member 
function ‘virtual XdmfInt32 xdmf2::XdmfDsmComm::Receive(xdmf2::XdmfDsmMsg*)’:
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx:55:18: error: 
ordered comparison of pointer with integer zero (‘void*’ and ‘int’)
   55 | if(Msg->Data <= 0 ){
  |~~^~~~
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx: In member 
function ‘virtual XdmfInt32 xdmf2::XdmfDsmComm::Send(xdmf2::XdmfDsmMsg*)’:
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx:69:18: error: 
ordered comparison of pointer with integer zero (‘void*’ and ‘int’)
   69 | if(Msg->Data <= 0 ){
  |~~^~~~
make[4]: *** 
[ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/build.make:541: 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmComm.cxx.o] 
Error 1
make[4]: *** Waiting for unfinished jobs

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#996648: dkms: The templates in /etc/dkms are pointing do debhelper 7

[Elimar Riesebieter]

Package: dkms
Version: 2.8.7-2
Severity: serious
Justification: 5
X-Debbugs-Cc: hostmast...@hostsharing.de

Dear maintainers,

please adjust the control file in the templates provided in
/etc/dkms to point to at least version 12 of debhelper. This should
be backported to stable and oldstable as well. Check
whether debian/compat is needed (oldoldstable?). Installing
module binaries are complaining about version 7 which blocks the
setup of remaining packages.

Thanks
Elimar

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

Kernel: Linux 5.10.73-baumbart-lxtec-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages dkms depends on:
ii  build-essential12.9
ii  clang-13 [c-compiler]  1:13.0.0-5
ii  coreutils  8.32-4+b1
ii  dctrl-tools2.24-3+b1
ii  dpkg-dev   1.20.9
ii  gcc [c-compiler]   4:11.2.0-2
ii  gcc-10 [c-compiler]10.3.0-11
ii  gcc-11 [c-compiler]11.2.0-9
ii  kmod   29-1
ii  lsb-release11.1.0
ii  make   4.3-4.1
ii  patch  2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot  1.26-1
pn  linux-headers-686-pae | linux-headers-amd64 | linux-headers-gene  
ii  sudo  1.9.5p2-3

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.4-1
pn  menu   

-- no debconf information

Bug#995952: undertime: Getting TypeError with any timezone

[Antoine Beaupré]

Control: tags -1 +pending +patch

On 2021-10-08 15:24:56, Gabriel Filion wrote:
> Package: undertime
> Version: 2.6.0
> Severity: grave
> Justification: renders package unusable
>
> Hello,
>
> I'm currently getting stack traces consistently when using undertime. No 
> matter
> the timezone that I request, I get a stack trace with a TypeError exception:

[...]

This is now fixed in git, and in 2.6.1 just uploaded to Debian
unstable. The patch is simple, if you want to apply locally before that:

modified   undertime
@@ -323,6 +323,7 @@ class UndertimeArgumentParser(ConfigArgumentParser):
 "-t",
 "--timezones",
 nargs="+",
+default=[],
 help="time zones to show [default: current time zone]",
 )
 group.add_argument(

I also added a NEWS.Debian item.

A.


-- 
On ne résout pas un problème avec les modes de pensée qui l'ont
engendré.
- Albert Einstein

Bug#968266: gsfonts-x11: Please mark as Multi-Arch: foreign

[Graham Inggs]

Control: reassign -1 src:gsfonts-x11 0.27
Control: affects -1 src:inventor
Control: retitle -1 gsfonts-x11: Please mark as Multi-Arch: foreign

Bug#996612: libexpat1-dev: incorrect path for INTERFACE_INCLUDE_DIRECTORIES in expat.cmake

[Matteo F. Vescovi]

Hi!

On 2021-10-16 at 20:41 (+02), László Böszörményi (GCS) wrote:
>  It's just one patch. Why do you use it in plural?

Well, they can be merged in one single patch, but they were born in two
different moments so I have the two patches attached.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A

Description: libexpat.so.X.Y.Z is installed in /lib/${DEB_HOST_MULTIARCH}
 instead of /usr/lib/${DEB_HOST_MULTIARCH}, thus the path of the shared library
 is not relative to the location of this cmake file (Closes: #995907)
Author: Andrius Merkys 
Forwarded: not-needed
--- a/expat/cmake/autotools/expat-noconfig__linux.cmake.in
+++ b/expat/cmake/autotools/expat-noconfig__linux.cmake.in
@@ -8,12 +8,12 @@
 # Import target "expat::expat" for configuration ""
 set_property(TARGET expat::expat APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
 set_target_properties(expat::expat PROPERTIES
-  IMPORTED_LOCATION_NOCONFIG "${_IMPORT_PREFIX}/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@"
+  IMPORTED_LOCATION_NOCONFIG "/lib/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@"
   IMPORTED_SONAME_NOCONFIG "libexpat.so.@SO_MAJOR@"
   )
 
 list(APPEND _IMPORT_CHECK_TARGETS expat::expat )
-list(APPEND _IMPORT_CHECK_FILES_FOR_expat::expat "${_IMPORT_PREFIX}/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@" )
+list(APPEND _IMPORT_CHECK_FILES_FOR_expat::expat "/lib/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@" )
 
 # Commands beyond this point should not need to know the version.
 set(CMAKE_IMPORT_FILE_VERSION)
--- a/expat/cmake/autotools/expat.cmake
+++ b/expat/cmake/autotools/expat.cmake
@@ -46,6 +46,7 @@
 get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
 get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
 get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
+get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
 if(_IMPORT_PREFIX STREQUAL "/")
   set(_IMPORT_PREFIX "")
 endif()


signature.asc
Description: PGP signature

Bug#996646: ITP: gnome-text-editor -- simple text editor for GNOME

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org
Owner: jer...@bicha.net
Control: block -1 by 993598
Control: block -1 by 996609

Package Name: gnome-text-editor
Version: 41.1
Upstream Author: Christian Hergert
License: GPL-3+
Programming Lang: C

Description: simple text editor for GNOME
 GNOME Text Editor is a simple editor for GNOME focused on being a good
 general purpose default editor.
 .
 It works hard to keep track of changes and state even if you quit the
 application. You can come back to your work even if you've never saved
 it to a file.
 .
 It is simpler than gedit.

Other Info
--
This app will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/gnome-text-editor

I expect GNOME to switch its default text editor in their "core" to GNOME
Text Editor soon. Currently, gedit is the default. gedit will still be
available and offers more complex features.

GNOME Text Editor uses GTK4 and libadwaita.

Thanks,
Jeremy Bicha

Bug#996549: upgrade-reports: Upgrade from buster to bullseye disables php module while apache2 running

[Bill Allombert]

Le Fri, Oct 15, 2021 at 10:22:33AM +0200, Philipp a écrit :
> Package: upgrade-reports
> Severity: important
> 
> (Please provide enough information to help the Debian
> maintainers evaluate the report efficiently - e.g., by filling
> in the sections below.)
> 
> My previous release is: Debian Buster
> I am upgrading to: Debian Bullseye
> Archive date: recent version
> Upgrade date: 10/15/2021
> Method: I replaced buster with bullseye in /etc/apt/sources.list, then apt 
> {update|upgrade|dist-upgrade}
> 
> Contents of /etc/apt/sources.list:
> deb http://ftp.de.debian.org/debian/ bullseye main
> deb http://security.debian.org/debian-security bullseye-security main
> deb http://ftp.de.debian.org/debian/ bullseye-updates main
> 
> 
> - Were there any non-Debian packages installed before the upgrade?  If
>   so, what were they?
> No.
> 
> - Was the system pre-update a pure sarge system? If not, which packages
>   were not from sarge?
> Yes.

Hello Philipp,

Thanks for your report. Did you use reportbug ? Because this template is
seriously outdated, Debian sarge was released in 2005...

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#996608: linux-source-5.10: Mising dependency: dwarves

[Salvatore Bonaccorso]

Hi Elliott,

On Fri, Oct 15, 2021 at 04:34:44PM -0700, Elliott Mitchell wrote:
> Package: linux-source-5.10
> Version: 5.10.70-1
> 
> SSIA.  Debian's 5.10 configuration will NOT build without the "dwarves"
> package (`pahole`).  In light of this some package, likely
> linux-source-5.10 should recommend "dwarves".

After talking to Ben about this: Summarizing, it would make sense
to recommend it from linux-source-X.Y, and actually, unter the
assumption that many user will start with the Debian config, it would
make sense to recommend all of the tools that would be required (that
makes it likely at least libelf-dev, libssl-dev, openssl, python3).

Regards,
Salvatore

Bug#996645: kodi: please add support for riscv64

[Aurelien Jarno]

Package: kodi
Version: 2:19.2+dfsg1-2
Severity: wishlist
Tags: ftbfs upstream patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear maintainer,

kodi currently fails to build from source on riscv64 due to missing
support for this architecture [1]. You will find attached a patch to fix
that. It touches many things, so please find some more details below:

- I modified debian/rules to pass -DWITH_ARCH=riscv64. It's not clear if
  that part should go upstream, it seems given we do not have CPU
  specific optimizations to add in cmake/scripts/linux/ArchSetup.cmake
  so it's not fully necessary. Please tell me if I am wrong, I'll submit
  that upstream.

- Patch 0024-add-riscv-compile-defines.patch is coming from upstream and
  will be in Kodi 20. It conflicts with 0006-fix-s390x-build and
  0009-fix-alpha-build patches whichh touch the same files. As 0024 is
  already upstream and will appear at some point in the Debian package,
  I have moved the 0006 and 0009 patches after it and "rebased" them as
  0025 and 0026.

- Patch 0027-link-with-pthread.patch changes the way cmake handles
  Thread support to correctly link with -pthread instead of -lpthread.
  That way GCC automatically pulls in -latomic if needed. I have noticed
  that debian/rules already forces LDFLAGS to contain -latomic, however
  it appears too early in the linker command to be early (it needs to be
  after the objects needing this library).

- Patch 0028-add-risc-v-support-to-system-info.patch adds support for
  RISC-V to SystemInfo.cpp and is needed to successfully pass the
  testsuite. I have submitted it upstream [2].

If you are fine with this patch, could you please consider applying it
in the future uploads? If you aren't, do not hesitate to comment, ask
for more details or ask for changes to the patch.

Regards,
Aurelien

[1] 
https://buildd.debian.org/status/fetch.php?pkg=kodi=riscv64=2%3A19.2%2Bdfsg1-2=1634297754=0
[2] https://github.com/xbmc/xbmc/pull/20323
--- kodi-19.2+dfsg1/debian/patches/kodi/0006-fix-s390x-build.patch
+++ kodi-19.2+dfsg1/debian/patches/kodi/0006-fix-s390x-build.patch
@@ -1,49 +0,0 @@
-From: Balint Reczey 
-Date: Tue, 3 Mar 2020 23:56:06 +0100
-Subject: Fix build on s390x
-Forwarded: not-needed
-
-Upstream is most probably not interested in this port thus I have not
-forwarded the patch.

- xbmc/cores/DllLoader/DllLoader.h  | 1 +
- xbmc/cores/DllLoader/ldt_keeper.c | 1 +
- xbmc/utils/MathUtils.h| 1 +
- 3 files changed, 3 insertions(+)
-
-diff --git a/xbmc/cores/DllLoader/DllLoader.h 
b/xbmc/cores/DllLoader/DllLoader.h
-index 55ee623..81681f2 100644
 a/xbmc/cores/DllLoader/DllLoader.h
-+++ b/xbmc/cores/DllLoader/DllLoader.h
-@@ -16,6 +16,7 @@
- !defined(__arm__) && \
- !defined(__aarch64__) && \
- !defined(__mips__) && \
-+!defined(__s390x__) && \
- !defined(__SH4__) && \
- !defined(__sparc__) && \
- !defined(__arc__) && \
-diff --git a/xbmc/cores/DllLoader/ldt_keeper.c 
b/xbmc/cores/DllLoader/ldt_keeper.c
-index 0e6bc81..1e99e57 100644
 a/xbmc/cores/DllLoader/ldt_keeper.c
-+++ b/xbmc/cores/DllLoader/ldt_keeper.c
-@@ -24,6 +24,7 @@
- !defined(__arm__) && \
- !defined(__aarch64__) && \
- !defined(__mips__) && \
-+!defined(__s390x__) && \
- !defined(__SH4__) && \
- !defined(__sparc__) && \
- !defined(__arc__) && \
-diff --git a/xbmc/utils/MathUtils.h b/xbmc/utils/MathUtils.h
-index 7a69db7..4a09672 100644
 a/xbmc/utils/MathUtils.h
-+++ b/xbmc/utils/MathUtils.h
-@@ -24,6 +24,7 @@
- #if defined(__ppc__) || \
- defined(__powerpc__) || \
- defined(__mips__) || \
-+defined(__s390x__) || \
- defined(__arm__) || \
- defined(__aarch64__) || \
- defined(__SH4__) || \
--- kodi-19.2+dfsg1/debian/patches/kodi/0009-fix-alpha-build.patch
+++ kodi-19.2+dfsg1/debian/patches/kodi/0009-fix-alpha-build.patch
@@ -1,48 +0,0 @@
-From: Michael Cree 
-Date: Tue, 3 Mar 2020 23:56:07 +0100
-Subject: Fix alpha build
-Forwarded: not-needed
-Bug: https://bugs.debian.org/856815
-

- xbmc/cores/DllLoader/DllLoader.h  | 1 +
- xbmc/cores/DllLoader/ldt_keeper.c | 1 +
- xbmc/utils/MathUtils.h| 1 +
- 3 files changed, 3 insertions(+)
-
-diff --git a/xbmc/cores/DllLoader/DllLoader.h 
b/xbmc/cores/DllLoader/DllLoader.h
-index 81681f2..efcc2bc 100644
 a/xbmc/cores/DllLoader/DllLoader.h
-+++ b/xbmc/cores/DllLoader/DllLoader.h
-@@ -17,6 +17,7 @@
- !defined(__aarch64__) && \
- !defined(__mips__) && \
- !defined(__s390x__) && \
-+!defined(__alpha__) && \
- !defined(__SH4__) && \
- !defined(__sparc__) && \
- !defined(__arc__) && \
-diff --git a/xbmc/cores/DllLoader/ldt_keeper.c 
b/xbmc/cores/DllLoader/ldt_keeper.c
-index 1e99e57..4be6ebc 100644
 a/xbmc/cores/DllLoader/ldt_keeper.c
-+++ b/xbmc/cores/DllLoader/ldt_keeper.c
-@@ -25,6 +25,7 @@
- !defined(__aarch64__) && \
- !defined(__mips__) && \
- !defined(__s390x__) && \
-+!defined(__alpha__) && \
- !defined(__SH4__) && 

Bug#996612: libexpat1-dev: incorrect path for INTERFACE_INCLUDE_DIRECTORIES in expat.cmake

[GCS]

On Sat, Oct 16, 2021 at 8:12 PM Matteo F. Vescovi  wrote:
> Having the expat package fixed with the patches provided by Andrius
> could help me a lot in having OCIO building fine, sooner or later ;)
 It's just one patch. Why do you use it in plural?

Regards,
Laszlo/GCS

Bug#996549: upgrade-reports: Upgrade from buster to bullseye disables php module while apache2 running

[Paul Gevers]

Control: reassign -1 src:php7.4 7.4.21-1+deb11u1

Hi Philipp,

Thanks for reporting your upgrade issues.

On 15-10-2021 10:22, Philipp wrote:
> - Were there any problems with the system after upgrading?
> php7.4 was installed over php7.3. Therefore, php7.3 has been deactivated as 
> apache2 module. But the installer did not enable php7.4. So, after a reboot, 
> apache2 started to deliver php files as text files. This is a _serious_ issue 
> if you don't realize it fast enough because the php files may contain config 
> or other sensible information.

This looks like a php7.4 issue, so hence reassigning.

> Further Comments/Problems:
> 
> The upgrade-process or the libapache2-mod-php7.4 package should auto-enable 
> php7.4 with a2enmod - especially during an upgrade from another php version...

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996644: ITP: node-node-rs -- helper library for node-rs

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Javascript Maintainers 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-node-rs
  Version : 1.0
  Upstream Author : LongYinan 
* URL : https://github.com/napi-rs/napi-rs
* License : Expat
  Programming Lang: NodeJS
  Description : helper library for node-rs

 @node-rs/helper is a helper library for node-rs -
 a collection of NodeJS & Rust bindings.
 .
 Node.js is a back-end JavaScript runtime environment
 that runs on the V8 engine
 and executes JavaScript code outside a web browser.
 .
 Rust is a multi-paradigm, high-level,
 general-purpose programming language
 designed for performance and safety, especially safe concurrency.

This package is needed by swc.
It will be team-maintained at https://salsa.debian.org/js-team/node-node-rs

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFrHQkACgkQLHwxRsGg
ASE6KQ//W3uHmeSg8k1y5U3awh2OyYFPytUTHKvvKyAkZ7UoanYtJ44JoT9RS8qh
z8omVzmwaslTLGlaRfprpeS85kba/OQGCFHcgB2BGH/mY9kb3Y6jRgNBVRAMoJf1
Qmep5WoGh27urrvtlvDUQBaxVwTj1LVJO0LlHm4/lWlKaTh3nbiSyvYzVizh89qN
gHw/vuQusDXultf26lGPj6/SYO5llfCUoimZzOTZ5DtvRP2YNoRkHkEQXopzLroV
ROEgPs5Xeeg9l4X6S2T+wguAdUwjbJZE4w5/T2HDbCy4TZ+Pxi0NnziaiU5Vayj0
g2JjEtInWKDMzfJV5Cx3pcF4DtXo2KPe8Vfx2GDWz01+fJSOd8qlxX70Erz9YK5Y
c8o44HVZaUkqS2ikk+nMerhLXKFDAZ1Lnn5+u2xHrRJxfsBJar51JvTbWhXAVhsh
eJfJTIXC8HZS7AspsyLZ/JvASeuLLWfHR21vshscbEPO4/jGOm8F6ByP5pSYvGZi
Dd7rCJJDRv30pwFHcQJzSib3nR1lRPKjSyzGuZ+sEjb8bi8+BgqJVSmIh3w0rwos
3B0rg4+fZOQWdRfEtrdFrW8I1a7ZugELytrPIuLBQdZ6YJQtHQsV6sdlM/Tsi4Pf
wGSUL9ouP3+3hlukwfRYdqPJWcUhoQKRcGlNKDbhbr5rNZyj/ws=
=ULDT
-END PGP SIGNATURE-

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Dirk Eddelbuettel]

On 16 October 2021 at 17:50, Sebastian Ramacher wrote:
| On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote:
| > 
| > On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| > | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| > | > 
| > | > Turns out this was fully my fault. The 2.7 release sets the SO number 
to 26,
| > | > and I didn't use that.
| > | 
| > | No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the 
SOVERSION
| > | is 25. gsl 2.6 had current=25, age=0. Increasing current was correct,
| > | increasing age wasn't.
| > 
| > I will admit not fully understanding the three components used as eg in
| > upstream's configuire.ac:
| > 
| > dnl Library versioning (C:R:A == current:revision:age)
| > dnl See the libtool manual for an explanation of the numbers
| > dnl
| > dnl gsl-1.0libgsl 0:0:0  libgslcblas 0:0:0
| > [...]
| > dnl gsl-2.6libgsl 25:0:0   libgslcblas 0:0:0 
| > dnl gsl-2.7libgsl 26:0:1   libgslcblas 0:0:0 
| > 
| > and
| > 
| > GSL_CURRENT=26
| > GSL_REVISION=0
| > GSL_AGE=1
| > 
| > If I understand you correctly we needed / need
| > 
| > dnl gsl-2.7libgsl 26:0:0   libgslcblas 0:0:0 
| > 
| > GSL_CURRENT=26
| > GSL_REVISION=0
| > GSL_AGE=0
| > 
| > Is that correct (as far as the Debian package goes) ?
| 
| That would have been correct, yes.
| 
| > What do you (ie Sebastian) suggest we do going forward?  Be more careful
| > about increasing CURRENT (only) when the ABI changes? (And I CC'ed Patrick
| > from GSL upstream now.)
| 
| The change to CURRENT was fine. I would suggest following the rules from
| 
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html.
| 
| Starting from GSL_CURRENT=25, GSL_AGE=0 from gsl 2.6 and ignoring
| everything regarding GSL_REVISION.
| 
| 4. If any interfaces have been added, removed, or changed since the last
| update, increment current, and set revision to 0.
| 
| => GSL_CURRENT=26, GSL_AGE=0
| 
| 5. If any interfaces have been added since the last public release, then
| increment age.
| 
| => GSL_CURRENT=26, GSL_AGE=1
| 
| 6. If any interfaces have been removed or changed since the last public
| release, then set age to 0.
| 
| => GSL_CURRENT=26, GSL_AGE=0

Thank you so much Sebastian, that was rather helpful. I think I will look
into a package update for Debian, making this a local patch. As this will
lead to a new soname I probably will have to upload to experimental first and
then trigger a proper migration, correct.
 
| It would be good to have a release of gsl with fixed values (e.g. a gsl
| version 2.7.1). Other distributions will be affected by this issue as
| well.

Agreed. Any thoughts, Patrick?

Dirk

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

Bug#996633: plasma-workspace: plasma-baloorunner.service enters failed state

[Christian Göttsche]

Package: plasma-workspace
Version: 4:5.23.0-2

The user service plasma-baloorunner enters the failed state causing
the systemd user session state to be degraded, not running.


$ systemctl --user status plasma-baloorunner.service
× plasma-baloorunner.service - KRunner provider for baloo file indexer
Loaded: loaded (/usr/lib/systemd/user/plasma-baloorunner.service; static)
Active: failed (Result: exit-code) since Sat 2021-10-16 16:03:51
CEST; 8min ago
   Process: 3008 ExecCondition=/usr/bin/kde-systemd-start-condition
--condition baloofilerc:Basic Settings:Indexing-Enabled:true
(code=exited, status=0/SUCCESS)
   Process: 3009
ExecStart=/usr/lib/x86_64-linux-gnu/libexec/baloorunner (code=exited,
status=255/EXCEPTION)
  Main PID: 3009 (code=exited, status=255/EXCEPTION)
   CPU: 28ms

Oct 16 16:03:51 debianHome systemd[1243]: Starting KRunner provider
for baloo file indexer...
Oct 16 16:03:51 debianHome systemd[1243]: plasma-baloorunner.service:
Main process exited, code=exited, status=255/EXCEPTION
Oct 16 16:03:51 debianHome systemd[1243]: plasma-baloorunner.service:
Failed with result 'exit-code'.
Oct 16 16:03:51 debianHome systemd[1243]: Failed to start KRunner
provider for baloo file indexer.


Tail of strace output:

statx(AT_FDCWD, "/home/christian/.config/kdeglobals",
AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID,
stx_attributes=0, stx_mode=S_IFREG|0600, stx_size=4043, ...}) = 0
statx(AT_FDCWD, "/home/christian/.config/kdedefaults/kdeglobals",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe151f8f30) = -1 ENOENT (No such
file or directory)
statx(AT_FDCWD, "/etc/xdg/kdeglobals", AT_STATX_SYNC_AS_STAT,
STATX_ALL, 0x7ffe151f8f30) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/home/christian/.config/system.kdeglobals",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe151f8f30) = -1 ENOENT (No such
file or directory)
statx(AT_FDCWD,
"/home/christian/.config/kdedefaults/system.kdeglobals",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe151f8f30) = -1 ENOENT (No such
file or directory)
statx(AT_FDCWD, "/etc/xdg/system.kdeglobals", AT_STATX_SYNC_AS_STAT,
STATX_ALL, 0x7ffe151f8f30) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/home/christian/.config/kdeglobals",
AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID,
stx_attributes=0, stx_mode=S_IFREG|0600, stx_size=4043, ...}) = 0
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=2298, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=2298, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
st_size=2298, ...}, 0) = 0
statx(AT_FDCWD, "/home/christian/.config/baloofilerc",
AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID,
stx_attributes=0, stx_mode=S_IFREG|0600, stx_size=761, ...}) = 0
statx(AT_FDCWD, "/home/christian/.config/kdedefaults/baloofilerc",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe151f9040) = -1 ENOENT (No such
file or directory)
statx(AT_FDCWD, "/etc/xdg/baloofilerc", AT_STATX_SYNC_AS_STAT,
STATX_ALL, 0x7ffe151f9040) = -1 ENOENT (No such file or directory)
readlink("/home", 0x7ffe151f88b0, 1023) = -1 EINVAL (Invalid argument)
readlink("/home/christian", 0x7ffe151f88b0, 1023) = -1 EINVAL (Invalid argument)
readlink("/home/christian/.config", 0x7ffe151f88b0, 1023) = -1 EINVAL
(Invalid argument)
readlink("/home/christian/.config/baloofilerc", 0x7ffe151f88b0, 1023)
= -1 EINVAL (Invalid argument)
openat(AT_FDCWD, "/home/christian/.config/baloofilerc", O_RDONLY|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0600, stx_size=761, ...}) = 0
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0600, stx_size=761, ...}) = 0
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0600, stx_size=761, ...}) = 0
read(3, "[General]\nexclude filters=*.vhd,"..., 16384) = 761
read(3, "", 15623)  = 0
close(3)= 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f945497f000
mprotect(0x7f945497f000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
getpid()= 3725
exit_group(-1)  = ?
+++ exited with 255 +++



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

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.13.18-2
ii  drkonqi   

Bug#996636: trafficserver FTBFS on 32bit

[Jean Baptiste Favre]

Hello ADrian,
Thanks for reporting the issue.

Unfortunatly, it's a well known issue since upstream decided some years 
ago to drop 32 bits architecture support.


I've luckily been able to still offer trafficserver for x86 since then, 
but it's not the case any more from trafficserver 9.0.0.


I've asked ftp master for their advice about the opportunity of keeping 
the package in Debian or not.


Best,
Jean Baptiste Favre


On 16/10/2021 17:50, Adrian Bunk wrote:

Source: trafficserver
Version: 9.1.0+ds-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=trafficserver=9.1.0%2Bds-1

...
Log.cc: In static member function ‘static void Log::trace_va(bool, const 
sockaddr*, uint16_t, const char*, va_list)’:
Log.cc:1276:14: error: invalid cast from type ‘ink_thread’ {aka ‘long unsigned 
int’} to type ‘uint64_t’ {aka ‘long long unsigned int’}
  1276 |  reinterpret_cast(ink_thread_self()), in ? "RECV" : 
"SEND", ip, peer_port);
   |  ^
...

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Adam D. Barratt]

On Sat, 2021-10-16 at 17:29 +, Vasyl Gello wrote:
> Hi Adam!
> 
> CC'ing you because I would like to understand if removing "m-a:
> foreign" from kodi-data might affect dependency resokution on stable.
> 

I'm not really sure what you're asking here. The effect on dependency
resolution on a stable system would be exactly the same as on an
unstable system. As to what those effects are in practice, I suspect
Helmut has already looked into the details of that as it applies to
this package.

In general we'd probably need some convincing that changing M-A
qualifiers in a stable update was appropriate, but that doesn't stop
you making the change in unstable.

Regards,

Adam


> I really hope it will not put a roadblock to future Kodi 19.x updates
> in stable :)
> -- 
> Vasyl Gello
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
> 
> 
> 16 жовтня 2021 р. 16:58:34 UTC, Vasyl Gello 
> написав(-ла):
> > Hi Helmut!
> > 
> > > I vaguely guess that we're in case b) here.
> > 
> > You are absolutely correct! Kodi data package hosts code which is
> > executed by Kodi binary and
> > it depends on python3:any.
> > 
> > > If you don't like removing
> > > Multi-Arch: foreign from kodi-data, there is another way out:
> > > Move the
> > > python modules to a new kodi-python-addons package. Move the
> > > relevant
> > > python dependencies to this package. Make it Architecture: any
> > > (not
> > > all). It can become Multi-Arch: same, but that won't help much.
> > > Any user
> > > of it must depend on kodi-python-addons directly. A dependency
> > > from
> > > kodi-data to kodi-python-addons is not sufficient (as kodi-data
> > > is
> > > supposed to remain Multi-Arch: foreign).
> > 
> > This is what I want to do!
> > 
> > However, this points to another drawback: we can not propagate
> > modified packages to
> > stable and oldstable-bpo. So I guess removing "Multi-Arch: foreign"
> > is better for 19.x
> > and for 20.x I am going to implement the refactored scheme of
> > packages.
> > 
> > Is that OK to just drop "m-a: foreign" from kodi-data:all or I need
> > something more to fix?
> > -- 
> > Vasyl Gello
> > Certified SolidWorks Expert
> > 
> > Mob.:+380 (98) 465 66 77
> > 
> > E-Mail: vasek.ge...@gmail.com
> > 
> > Skype: vasek.gello
> > 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
> > 
> > 16 жовтня 2021 р. 16:22:09 UTC, Helmut Grohne 
> > написав(-ла):
> > > Hi,
> > > 
> > > I think this bug has been diverted to being able to use
> > > widevinecdm.
> > > While that turns the original request a little academic, there
> > > still is
> > > a bug there.
> > > 
> > > On Sat, Oct 16, 2021 at 02:07:19PM +0200, Justus Winter wrote:
> > > > 13:37  but, kodi-data (which is ma: foreign) depends
> > > > on
> > > >   python3-pycryptodome which contains architecture-
> > > > dependent code
> > > >   aiui
> > > 
> > > This raises the question of why kodi-data depends on
> > > python3-pycryptodome. There are basically two reasonable answers:
> > > 
> > > a) It provides programs (something you can run from a shell) that
> > > happen
> > >to use python3-pycryptodome. In this case, kodi-data also must
> > > depend
> > >on a python3 interpreter.
> > > 
> > > b) It provides python modules that use python3-pycryptodome (to
> > > be
> > >imported by other packages). In this case, kodi-data must not
> > > be
> > >marked Multi-Arch: foreign.
> > > 
> > > So regardless of the widevinecdm issue, this is a bug in kodi-
> > > data.
> > > 
> > > Now this all doesn't solve the problem of foreign installation,
> > > but we
> > > can only really think about that once we have correct metadata.
> > > 
> > > Once it has been fixed and a week has passed, we should look into
> > > https://bootstrap.debian.net/foreign_install/kodi.html. It gives
> > > a good
> > > overview of the outstanding metadata issues.
> > > 
> > > I hope this makes sense to you. If it does not, please don't
> > > hesitate to
> > > ask.
> > > 
> > > Helmut
> > > 

Bug#996643: gcc-11: FTBFS on hppa - Bootstrap comparison failure!

[John David Anglin]

Source: gcc-11
Version: 11.2.0-9
Severity: normal

Dear Maintainer,

Build fails here:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/m2/gm2-compiler-boot/M2Version.o differs
Bootstrap comparison failure!
gcc/SYSTEM.o differs

SYSTEM.o is probably a m2 file.  Not sure why it's in gcc directory.
It seems to be excluded when its in gcc/m2/gm2-compiler-boot:

# DP: ignore gm2version.o stage diff on some archtectures (m68k, riscv64)

--- a/src/configure.ac
+++ b/src/configure.ac
@@ -3678,6 +3678,7 @@ AC_SUBST(stage2_werror_flag)
 compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*"
 compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/M2Version*"
 compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/SYSTEM*"
+compare_exclusions="$compare_exclusions | *m2/gm2version\$(objext)"

Regards,
Dave

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

-- no debconf information

Bug#996374: python-nanoget: autopkgtest regression

[Nilesh Patra]

More deets: trying with samtools version 1.13 and manually creating this also 
fails.

$ samtools index alignment.bam
$ diff alignment.bam.bai alignment.bam.bai_orig
Binary files alignment.bam.bai and alignment.bam.bai_orig differ

Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996374: python-nanoget: autopkgtest regression

[Nilesh Patra]

control: forwarded -1 https://github.com/wdecoster/nanoget/issues/26

Not sure what exactly causes this, found a related (unfixed) problem in pysam 
here:

https://github.com/pysam-developers/pysam/issues/939

Maybe this is the problem ^^^

Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Vasyl Gello]

Hi Adam!

CC'ing you because I would like to understand if removing "m-a: foreign" from 
kodi-data might affect dependency resokution on stable.

I really hope it will not put a roadblock to future Kodi 19.x updates in stable 
:)
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

16 жовтня 2021 р. 16:58:34 UTC, Vasyl Gello  
написав(-ла):
>Hi Helmut!
>
>>I vaguely guess that we're in case b) here.
>
>You are absolutely correct! Kodi data package hosts code which is executed by 
>Kodi binary and
>it depends on python3:any.
>
>>If you don't like removing
>>Multi-Arch: foreign from kodi-data, there is another way out: Move the
>>python modules to a new kodi-python-addons package. Move the relevant
>>python dependencies to this package. Make it Architecture: any (not
>>all). It can become Multi-Arch: same, but that won't help much. Any user
>>of it must depend on kodi-python-addons directly. A dependency from
>>kodi-data to kodi-python-addons is not sufficient (as kodi-data is
>>supposed to remain Multi-Arch: foreign).
>
>This is what I want to do!
>
>However, this points to another drawback: we can not propagate modified 
>packages to
>stable and oldstable-bpo. So I guess removing "Multi-Arch: foreign" is better 
>for 19.x
>and for 20.x I am going to implement the refactored scheme of packages.
>
>Is that OK to just drop "m-a: foreign" from kodi-data:all or I need something 
>more to fix?
>-- 
>Vasyl Gello
>==
>Certified SolidWorks Expert
>
>Mob.:+380 (98) 465 66 77
>
>E-Mail: vasek.ge...@gmail.com
>
>Skype: vasek.gello
>==
>호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
>
>16 жовтня 2021 р. 16:22:09 UTC, Helmut Grohne  написав(-ла):
>>Hi,
>>
>>I think this bug has been diverted to being able to use widevinecdm.
>>While that turns the original request a little academic, there still is
>>a bug there.
>>
>>On Sat, Oct 16, 2021 at 02:07:19PM +0200, Justus Winter wrote:
>>> 13:37  but, kodi-data (which is ma: foreign) depends on
>>>   python3-pycryptodome which contains architecture-dependent code
>>>   aiui
>>
>>This raises the question of why kodi-data depends on
>>python3-pycryptodome. There are basically two reasonable answers:
>>
>>a) It provides programs (something you can run from a shell) that happen
>>   to use python3-pycryptodome. In this case, kodi-data also must depend
>>   on a python3 interpreter.
>>
>>b) It provides python modules that use python3-pycryptodome (to be
>>   imported by other packages). In this case, kodi-data must not be
>>   marked Multi-Arch: foreign.
>>
>>So regardless of the widevinecdm issue, this is a bug in kodi-data.
>>
>
>>
>>Now this all doesn't solve the problem of foreign installation, but we
>>can only really think about that once we have correct metadata.
>>
>>Once it has been fixed and a week has passed, we should look into
>>https://bootstrap.debian.net/foreign_install/kodi.html. It gives a good
>>overview of the outstanding metadata issues.
>>
>>I hope this makes sense to you. If it does not, please don't hesitate to
>>ask.
>>
>>Helmut
>>

Bug#993048: mosquitto init script broken with bullseye update

[sergio]

I believe the pidfile should be moved to the /run directly as this done 
for others.


--- mosquitto.orig  2021-10-16 20:12:03.825565077 +0300
+++ mosquitto   2021-10-16 20:11:06.149857678 +0300
@@ -20,7 +20,7 @@

 set -e

-PIDFILE=/run/mosquitto/mosquitto.pid
+PIDFILE=/run/mosquitto.pid
 DAEMON=/usr/sbin/mosquitto

 # /etc/init.d/mosquitto: start and stop the mosquitto MQTT message broker


--
sergio.

Bug#996407: [RFH] proteinortho: diamond-aligner breaks proteinortho autopkgtest: diamond failed with code 256

[Nilesh Patra]

On Wed, 13 Oct 2021 21:07:45 +0200 Paul Gevers  wrote:

With a recent upload of diamond-aligner the autopkgtest of proteinortho
fails in testing when that autopkgtest is run with the binary packages
of diamond-aligner from unstable. It passes when run with only packages
from testing.


Hi Michael,

Since you uploaded the latest version of diamond-aligner, could you please
fix the problem in proteinortho?
Maybe passing a '--ignore-warnings' somewhere fixes this, but I do not know 
much about
protein sequences, hence would appreciate help.

Thanks,
Nilesh

| 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/proteinortho/15931264/log.gz
|
| autopkgtest [02:08:50]: test run-unit-test: [---
| *
| Proteinortho with PoFF version 6.0.31 - An orthology
| detection tool
| *
| Detected 2 available CPU threads (adjust this with -cpus), Detected
| 'blastp+' version 2.11.0+
| Checking input files.
| Checking test/C.faa... ok
| Checking test/C2.faa... ok
| Checking test/E.faa... ok
| Checking test/L.faa... ok
| Checking test/M.faa... ok
|
| **Step 1**
| Generating indices anyway (forced).
| Building database for 'test/C.faa'(109 sequences)
| Building database for 'test/E.faa'(72 sequences)
| Building database for 'test/L.faa'(40 sequences)
| Building database for 'test/M.faa'(40 sequences)
| Building database for 'test/C2.faa'(2 sequences)
|
| **Step 2** using blastp+



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996407: diamond-aligner breaks proteinortho autopkgtest: diamond failed with code 256

[Nilesh Patra]

On Wed, 13 Oct 2021 21:07:45 +0200 Paul Gevers  wrote:

With a recent upload of diamond-aligner the autopkgtest of proteinortho
fails in testing when that autopkgtest is run with the binary packages
of diamond-aligner from unstable. It passes when run with only packages
from testing.


Hi Michael,

Since you uploaded the latest version of diamond-aligner, could you please
fix the problem in proteinortho?
Maybe passing a '--ignore-warnings' somewhere fixes this, but I do not know 
much about
protein sequences, hence would appreciate help.

Thanks,
Nilesh

| 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/proteinortho/15931264/log.gz
|
| autopkgtest [02:08:50]: test run-unit-test: [---
| *
| Proteinortho with PoFF version 6.0.31 - An orthology
| detection tool
| *
| Detected 2 available CPU threads (adjust this with -cpus), Detected
| 'blastp+' version 2.11.0+
| Checking input files.
| Checking test/C.faa... ok
| Checking test/C2.faa... ok
| Checking test/E.faa... ok
| Checking test/L.faa... ok
| Checking test/M.faa... ok
|
| **Step 1**
| Generating indices anyway (forced).
| Building database for 'test/C.faa'(109 sequences)
| Building database for 'test/E.faa'(72 sequences)
| Building database for 'test/L.faa'(40 sequences)
| Building database for 'test/M.faa'(40 sequences)
| Building database for 'test/C2.faa'   (2 sequences)
|
| **Step 2** using blastp+



OpenPGP_signature
Description: OpenPGP digital signature

Bug#932969: gprbuild: i686-w64-mingw32 compiler not found by gprconfig

[Nicolas Boulenguez]

Package: gprbuild
Followup-For: Bug #932969

Hello.

(CC-ing Stephen Kitt, the gcc-mingw-w64 maintainer)

gprconfig tries to run `$triplet-gnatgcc -dumpversion` in order to see
which $triplet-gnat version is available, if any.

$triplet-gnatgcc is a trick specific to Debian, ensuring that
compilations mixing Ada and C use the same compiler versions, in case
several GCC versions are installed.

The easyest solution would be for gnat-mingw-w64-i686 to install a
symbolic link like the gnat-$arch for official architectures.

Stephen, is it possible to add a line like
  usr/bin/gnat-mingw-w64-i686-gnatgccusr/bin/gnat-mingw-w64-i686-gcc
to
  debian/gnat-mingw-w64-i686.links ?

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Vasyl Gello]

Hi Helmut!

>I vaguely guess that we're in case b) here.

You are absolutely correct! Kodi data package hosts code which is executed by 
Kodi binary and
it depends on python3:any.

>If you don't like removing
>Multi-Arch: foreign from kodi-data, there is another way out: Move the
>python modules to a new kodi-python-addons package. Move the relevant
>python dependencies to this package. Make it Architecture: any (not
>all). It can become Multi-Arch: same, but that won't help much. Any user
>of it must depend on kodi-python-addons directly. A dependency from
>kodi-data to kodi-python-addons is not sufficient (as kodi-data is
>supposed to remain Multi-Arch: foreign).

This is what I want to do!

However, this points to another drawback: we can not propagate modified 
packages to
stable and oldstable-bpo. So I guess removing "Multi-Arch: foreign" is better 
for 19.x
and for 20.x I am going to implement the refactored scheme of packages.

Is that OK to just drop "m-a: foreign" from kodi-data:all or I need something 
more to fix?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

16 жовтня 2021 р. 16:22:09 UTC, Helmut Grohne  написав(-ла):
>Hi,
>
>I think this bug has been diverted to being able to use widevinecdm.
>While that turns the original request a little academic, there still is
>a bug there.
>
>On Sat, Oct 16, 2021 at 02:07:19PM +0200, Justus Winter wrote:
>> 13:37  but, kodi-data (which is ma: foreign) depends on
>>   python3-pycryptodome which contains architecture-dependent code
>>   aiui
>
>This raises the question of why kodi-data depends on
>python3-pycryptodome. There are basically two reasonable answers:
>
>a) It provides programs (something you can run from a shell) that happen
>   to use python3-pycryptodome. In this case, kodi-data also must depend
>   on a python3 interpreter.
>
>b) It provides python modules that use python3-pycryptodome (to be
>   imported by other packages). In this case, kodi-data must not be
>   marked Multi-Arch: foreign.
>
>So regardless of the widevinecdm issue, this is a bug in kodi-data.
>

>
>Now this all doesn't solve the problem of foreign installation, but we
>can only really think about that once we have correct metadata.
>
>Once it has been fixed and a week has passed, we should look into
>https://bootstrap.debian.net/foreign_install/kodi.html. It gives a good
>overview of the outstanding metadata issues.
>
>I hope this makes sense to you. If it does not, please don't hesitate to
>ask.
>
>Helmut
>

Bug#996642: csh: FTBFS with glibc 2.32

[Graham Inggs]

Source: csh
Version: 20110502-6
Severity: serious
Tags: ftbfs patch bookworm sid

Hi Maintainer

As can be seen in reproducible builds [1], csh FTBFS since glibc 2.32
was uploaded.
I've attached a patch from Ubuntu where this was fixed already.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/csh.html


csh-glibc2.32.debdiff
Description: Binary data

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Helmut Grohne]

Hi,

I think this bug has been diverted to being able to use widevinecdm.
While that turns the original request a little academic, there still is
a bug there.

On Sat, Oct 16, 2021 at 02:07:19PM +0200, Justus Winter wrote:
> 13:37  but, kodi-data (which is ma: foreign) depends on
>   python3-pycryptodome which contains architecture-dependent code
>   aiui

This raises the question of why kodi-data depends on
python3-pycryptodome. There are basically two reasonable answers:

a) It provides programs (something you can run from a shell) that happen
   to use python3-pycryptodome. In this case, kodi-data also must depend
   on a python3 interpreter.

b) It provides python modules that use python3-pycryptodome (to be
   imported by other packages). In this case, kodi-data must not be
   marked Multi-Arch: foreign.

So regardless of the widevinecdm issue, this is a bug in kodi-data.

I vaguely guess that we're in case b) here. If you don't like removing
Multi-Arch: foreign from kodi-data, there is another way out: Move the
python modules to a new kodi-python-addons package. Move the relevant
python dependencies to this package. Make it Architecture: any (not
all). It can become Multi-Arch: same, but that won't help much. Any user
of it must depend on kodi-python-addons directly. A dependency from
kodi-data to kodi-python-addons is not sufficient (as kodi-data is
supposed to remain Multi-Arch: foreign).

Now this all doesn't solve the problem of foreign installation, but we
can only really think about that once we have correct metadata.

Once it has been fixed and a week has passed, we should look into
https://bootstrap.debian.net/foreign_install/kodi.html. It gives a good
overview of the outstanding metadata issues.

I hope this makes sense to you. If it does not, please don't hesitate to
ask.

Helmut

Bug#996641: unixcw FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: unixcw
Version: 3.6.0-2.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

unixcw fails to cross build from source, because configure.ac hard codes
the build architecture pkg-config in one occasion. After changing it to
the host architecture one, it cross builds fine. Please consider
applying the attached patch.

Helmut
--- unixcw-3.6.0.orig/configure.ac
+++ unixcw-3.6.0/configure.ac
@@ -372,7 +372,7 @@
 			   AC_PATH_PROGS(MOC, [moc-qt5 moc], moc,`eval $PKG_CONFIG --variable=host_bins Qt5Core`)
 
 			   # https://stackoverflow.com/questions/11663702/how-to-suppress-warnings-for-file-included-from-header
-			   QT_INCLUDE_DIR=`pkg-config --variable=includedir Qt5Core`
+			   QT_INCLUDE_DIR=`$PKG_CONFIG --variable=includedir Qt5Core`
 			   QT5_CFLAGS="-isystem $QT_INCLUDE_DIR"
 			   QT5_CFLAGS+=" -isystem $QT_INCLUDE_DIR/QtWidgets"
 			   QT5_CFLAGS+=" -isystem $QT_INCLUDE_DIR/QtGui"

Bug#996640: powertop FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[Helmut Grohne]

Source: powertop
Version: 2.13-2
Severity: serious
Tags: ftbfs

powertop fails to build from source in unstable, because ncurses added
format string annotations. A non-parallel build now ends as follows:

| g++ -std=c++11 -DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/share/locale\"  
-I/usr/include/libnl3  -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 
-I/usr/include/x86_64-linux-gnu -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-Wformat -Wshadow -fno-omit-frame-pointer -fstack-protector  
-I/usr/include/libnl3 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 
-I/usr/include/x86_64-linux-gnu -pthread -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o powertop-display.o `test -f 'display.cpp' || echo 
'./'`display.cpp
| display.cpp: In function ‘void show_tab(unsigned int)’:
| display.cpp:128:26: error: format not a string literal and no format 
arguments [-Werror=format-security]
|   128 | mvwprintw(bottom_line, 0,0, c);
|   | ~^
| cc1plus: some warnings being treated as errors
| make[4]: *** [Makefile:1107: powertop-display.o] Error 1
| make[4]: Leaving directory '/<>/src'
| make[3]: *** [Makefile:657: all] Error 2
| make[3]: Leaving directory '/<>/src'
| make[2]: *** [Makefile:461: all-recursive] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:391: all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:9: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut

Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL

[Julien Cristau]

Hi,

On Sun, Oct 10, 2021 at 10:21:40PM +0200, Paul Gevers wrote:
> Source: postfix-mta-sts-resolver
> Version: 1.0.0-4
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:ca-certificates
> 
> [X-Debbugs-CC: debian...@lists.debian.org,
> ca-certifica...@packages.debian.org]
> 
> Dear maintainer(s),
> 
> With a recent upload of ca-certificates the autopkgtest of
> postfix-mta-sts-resolver fails in testing when that autopkgtest is run
> with the binary packages of ca-certificates from unstable. It passes
> when run with only packages from testing. In tabular form:
> 
>  passfail
> ca-certificates  from testing20211004
> postfix-mta-sts-resolver from testing1.0.0-4
> all others   from testingfrom testing
> 
> I copied some of the output at the bottom of this report. The *warning*
> seems to be innocent, but causes the test to fail because by default
> autopkgtest considers output on stderr as fatal (without the
> allow-stderr restriction).
> 
> Currently this regression is blocking the migration of ca-certificates
> to testing [1]. Of course, ca-certificates shouldn't just break your
> autopkgtest (or even worse, your package), but it seems to me that the
> change in ca-certificates was intended and your package needs to update
> to the new situation.
> 
That's very surprising to me, I'm not aware of any such change to
ca-certificates, much less an intended one.

> If this is a real problem in your package (and not only in your
> autopkgtest), the right binary package(s) from ca-certificates should
> really add a versioned Breaks on the unfixed version of (one of your)
> package(s). Note: the Breaks is nice even if the issue is only in the
> autopkgtest as it helps the migration software to figure out the right
> versions to combine in the tests.
> 
I think this "Note" is bad advice.  Breaks shouldn't be added just to
pacify a tool.

Cheers,
Julien

> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=ca-certificates
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/postfix-mta-sts-resolver/15856707/log.gz
> 
> autopkgtest [19:39:52]: test run: [---
> Updating certificates in /etc/ssl/certs...
> rehash: warning: skipping ca-certificates.crt,it does not contain
> exactly one certificate or CRL
> 1 added, 0 removed; done.
> Running hooks in /etc/ca-certificates/update.d...
> done.
> autopkgtest [19:40:04]: test run: ---]
> autopkgtest [19:40:04]: test run:  - - - - - - - - - - results - - - - -
> - - - - -
> run  FAIL stderr: rehash: warning: skipping
> ca-certificates.crt,it does not contain exactly one certificate or CRL
> 

Bug#996639: Epiphany crashes when opening PDF in new tab (NULL pointer dereference)

[John Scott]

Package: epiphany-browser
Version: 41.0-2
Severity: normal

Here is a proof-of-concept file you can open, assuming you have bash-
doc installed:




Proof of concept


Link



Clicking the link will try to open a new tab to view the PDF file in,
but this causes Epiphany to crash.

Here is the backtrace for the relevant thread:
#0  0x7f6619804608 in decide_policy_cb
(decision_type=WEBKIT_POLICY_DECISION_TYPE_RESPONSE, user_data=, decision=0x7f6600017e10 [WebKitResponsePolicyDecision], 
web_view=0x55a90c7f9230 [EphyWebView]) at ../embed/ephy-web-view.c:962
#1  decide_policy_cb
(web_view=0x55a90c7f9230 [EphyWebView], decision=0x7f6600017e10 
[WebKitResponsePolicyDecision], decision_type=, 
user_data=) at ../embed/ephy-web-view.c:919
#2  0x7f66126af9da in ffi_call_unix64 () at ../src/x86/unix64.S:105
#3  0x7f66126aeb21 in ffi_call_int
(cif=0x7ffd473cb370, fn=0x7f66198044b0 , 
rvalue=, avalue=, closure=)
at ../src/x86/ffi64.c:672
#8  0x7f6618cb92cf in 
(instance=, signal_id=, detail=) at ../../../gobject/gsignal.c:3553
#4  0x7f6618ca0edc in g_cclosure_marshal_generic
(closure=closure@entry=0x55a90c7ef070, 
return_gvalue=return_gvalue@entry=0x7ffd473cb510, 
n_param_values=n_param_values@entry=3, 
param_values=param_values@entry=0x7ffd473cb570, 
invocation_hint=invocation_hint@entry=0x7ffd473cb4f0, 
marshal_data=marshal_data@entry=0x0)
at ../../../gobject/gclosure.c:1534
#5  0x7f6618ca06cf in g_closure_invoke
(closure=0x55a90c7ef070, return_value=return_value@entry=0x7ffd473cb510, 
n_param_values=3, param_values=param_values@entry=0x7ffd473cb570, 
invocation_hint=invocation_hint@entry=0x7ffd473cb4f0) at 
../../../gobject/gclosure.c:830
#6  0x7f6618cb2a8b in signal_emit_unlocked_R
(node=, detail=detail@entry=0, 
instance=instance@entry=0x55a90c7f9230, 
emission_return=emission_return@entry=0x7ffd473cb670, 
instance_and_params=instance_and_params@entry=0x7ffd473cb570) at 
../../../gobject/gsignal.c:3742
#7  0x7f6618cb88e9 in g_signal_emit_valist
(instance=, signal_id=, detail=, var_args=var_args@entry=0x7ffd473cb720)
at ../../../gobject/gsignal.c:3507
#9  0x7f661551ee8c in webkitWebViewMakePolicyDecision(_WebKitWebView*, 
WebKitPolicyDecisionType, _WebKitPolicyDecision*) ()
at ./Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:2627
#10 0x7f66154fcd18 in 
NavigationClient::decidePolicyForNavigationResponse(WebKit::WebPageProxy&, 
WTF::Ref 
>&&, WTF::Ref >&&, API::Object*) () at 
./Source/WebKit/UIProcess/API/glib/WebKitNavigationClient.cpp:150
#11 0x7f661544ae33 in 
WebKit::WebPageProxy::decidePolicyForResponseShared(WTF::Ref >&&, 
WTF::ObjectIdentifier, 
WTF::ObjectIdentifier, WebKit::FrameInfoData&&, 
WebCore::PolicyCheckIdentifier, unsigned long, WebCore::ResourceResponse 
const&, WebCore::ResourceRequest const&, bool, WTF::String const&, bool, 
WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, 
WebKit::UserData const&) () at ./Source/WebKit/UIProcess/WebPageProxy.cpp:5681
#12 0x7f661544af3e in 
WebKit::WebPageProxy::decidePolicyForResponse(WTF::ObjectIdentifier,
 WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, 
WebCore::ResourceResponse const&, WebCore::ResourceRequest const&, bool, 
WTF::String const&, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned 
long, unsigned long, WebKit::UserData const&) () at 
./Source/WebKit/UIProcess/WebPageProxy.cpp:5625
#13 0x7f6615184d0d in IPC::callMemberFunctionImpl, 
WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, 
WebCore::ResourceResponse const&, WebCore::ResourceRequest const&, bool, 
WTF::String const&, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned 
long, unsigned long, WebKit::UserData const&), 
std::tuple, 
WebKit::FrameInfoData, WebCore::PolicyCheckIdentifier, unsigned long, 
WebCore::ResourceResponse, WebCore::ResourceRequest, bool, WTF::String, bool, 
WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, 
WebKit::UserData>, 0ul, 1ul, 2ul, 3ul, 4ul, 5ul, 6ul, 7ul, 8ul, 9ul, 10ul, 
11ul, 12ul>(WebKit::WebPageProxy*, void 
(WebKit::WebPageProxy::*)(WTF::ObjectIdentifier, 
WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, 
WebCore::ResourceResponse const&, WebCore::ResourceRequest const&, bool, 
WTF::String const&, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned 
long, unsigned long, WebKit::UserData const&), 
std::tuple, 
WebKit::FrameInfoData, WebCore::PolicyCheckIdentifier, unsigned long, 
WebCore::ResourceResponse, WebCore::ResourceRequest, bool, WTF::String, bool, 
WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, 
WebKit::UserData>&&, std::integer_sequence) () at 
./Source/WebKit/Platform/IPC/HandleMessage.h:43
#14 IPC::callMemberFunction, 
WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, 

Bug#996638: ITP: rime-essay -- Rime Input Method Engine preset vocabulary and language model

[Boyuan Yang]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: rime-essay
  Version : 0.0~git20210805.8882482
  Upstream Author : Gong Chen 
* URL : https://github.com/rime/rime-essay
* License : LGPL-3.0
  Programming Lang: N/A
  Description : Rime Input Method preset vocabulary and language model

 RIME is the acronym of Rime Input Method Engine.
 .
 RIME is a lightweight, extensible input method engine supporting various
input
 schematas including glyph-based input methods, romanization-based input
methods
 as well as those for Chinese dialects. It has the ability to compose phrases
 and sentences intelligently and provide very accurate traditional Chinese
 output. RIME's cross-platform core library is written in C++, and can work
 consistently on different platforms with OS-specific wrappers.
 .
 This package provides the preset vocabulary and language model data of RIME.

This package will be part of the effort to migrate from
https://tracker.debian.org/pkg/brise to https://github.com/rime/plum by
splitting individual data packages and maintaining them individually.

I plan to maintain this package under Debian Input Method Team:
https://salsa.debian.org/input-method-team/rime-essay .

Thanks,
Boyuan Yang


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

Bug#994275: Reverting breaking changes in debianutils

[Thorsten Glaser]

On Sat, 16 Oct 2021, Clint Adams wrote:

> It is my hope that update-shells will obsolete add-shell and remove-shell

Huh, what’s update-shells?

Hm, apparently something new in sid. Ouch. If you really wish for
that, it’ll involve painful versioned Pre-Depends and a largish
diff for backports :/ and, I think, at least one release in which
both are present so removing a shell in a partial upgrade won’t
fail, aborting dpkg…

> run-parts is special in that it is roughly feature-complete and, as
> far as I am aware, there are no extant alternatives other than Red
> Hat's "fork" of debianutils run-parts as a shell script.  I could be
> convinced that it shouldn't be Essential though.

run-parts is used a lot, though, as it’s rather useful.

> ischroot is pretty flawed and I continually regret acquiescing to its

Huh? -v please. I use that for some decisions on $orkplace systems.

> dpkg.  which was only important for maintainer scripts when POSIX only
> specified alternatives like `type` and `command -v` in optional
> extensions.  Now which is only important to people using bash, it seems.

No. You’re conflating “which ”, which indeed is mostly redundant
with “command -v”, with “which -a ”, which is NOT otherwise
available, and a very useful thing to have, and one which (heh, pun
not intended) I pretty much expect to exist on a system.

> I think that this (short-term transitively Essential) is fine for
> which(1), especially if GNU which is the only which(1) to make it
> through NEW within the next year and a half.

Hmmh. I personally don’t care too much which which is there, as long
as it’ll support the two(!) common uses, though ofc I’d prefer BSD ☻
but having just one is perhaps less error-prone.

> I don't know whether to be offended by anyone not seeing things.  The
> stable version of tempfile(1) prints a deprecation warning.  I filed bugs.
> I sent patches.  All breaking changes were uploaded to unstable at the
> beginning of the development cycle so to maximize the available time for
> testing.  Some people did NMUs.

I know that feeling… some package maintainers don’t seem to care about
warnings. But as something in an Essential package I fear it’s up to
you to ping them, time and time again, until they don’t depend on it
any more, instead of proactively removing it.

(I even have to support dashisms in mksh-as-/bin/sh (the lksh binary,
actually) because some bugs are so widespread…)

> These seem like minor bugs in debian-policy and lintian.

ACK.

> > upgrade failures. At least for that case I would expect that all the
> > users are fixed in release $x and then tempfile could be removed in $x
> > + 1.

Indeed.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#996636: trafficserver FTBFS on 32bit

[Adrian Bunk]

Source: trafficserver
Version: 9.1.0+ds-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=trafficserver=9.1.0%2Bds-1

...
Log.cc: In static member function ‘static void Log::trace_va(bool, const 
sockaddr*, uint16_t, const char*, va_list)’:
Log.cc:1276:14: error: invalid cast from type ‘ink_thread’ {aka ‘long unsigned 
int’} to type ‘uint64_t’ {aka ‘long long unsigned int’}
 1276 |  reinterpret_cast(ink_thread_self()), in ? "RECV" 
: "SEND", ip, peer_port);
  |  ^
...

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Sebastian Ramacher]

On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote:
> 
> On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
> | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
> | > 
> | > Turns out this was fully my fault. The 2.7 release sets the SO number to 
> 26,
> | > and I didn't use that.
> | 
> | No, it doesn't. gsl 2.7 has current=26 and age=1, meaning the the SOVERSION
> | is 25. gsl 2.6 had current=25, age=0. Increasing current was correct,
> | increasing age wasn't.
> 
> I will admit not fully understanding the three components used as eg in
> upstream's configuire.ac:
> 
> dnl Library versioning (C:R:A == current:revision:age)
> dnl See the libtool manual for an explanation of the numbers
> dnl
> dnl gsl-1.0libgsl 0:0:0  libgslcblas 0:0:0
> [...]
> dnl gsl-2.6libgsl 25:0:0   libgslcblas 0:0:0 
> dnl gsl-2.7libgsl 26:0:1   libgslcblas 0:0:0 
> 
> and
> 
> GSL_CURRENT=26
> GSL_REVISION=0
> GSL_AGE=1
> 
> If I understand you correctly we needed / need
> 
> dnl gsl-2.7libgsl 26:0:0   libgslcblas 0:0:0 
> 
> GSL_CURRENT=26
> GSL_REVISION=0
> GSL_AGE=0
> 
> Is that correct (as far as the Debian package goes) ?

That would have been correct, yes.

> What do you (ie Sebastian) suggest we do going forward?  Be more careful
> about increasing CURRENT (only) when the ABI changes? (And I CC'ed Patrick
> from GSL upstream now.)

The change to CURRENT was fine. I would suggest following the rules from
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html.

Starting from GSL_CURRENT=25, GSL_AGE=0 from gsl 2.6 and ignoring
everything regarding GSL_REVISION.

4. If any interfaces have been added, removed, or changed since the last
update, increment current, and set revision to 0.

=> GSL_CURRENT=26, GSL_AGE=0

5. If any interfaces have been added since the last public release, then
increment age.

=> GSL_CURRENT=26, GSL_AGE=1

6. If any interfaces have been removed or changed since the last public
release, then set age to 0.

=> GSL_CURRENT=26, GSL_AGE=0


It would be good to have a release of gsl with fixed values (e.g. a gsl
version 2.7.1). Other distributions will be affected by this issue as
well.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962650: libcamera: API and ABI appear to be changing without a SONAME bump

[Dorota Czaplejewicz]

Hi,

I'm interested in having libcamera in Debian. We want to use it in a downstream 
distribution (PureOS).

Is there interest in some help in maintaining this package while it's unstable?

Cheers,
Dorota


pgpB1e80FQNU6.pgp
Description: OpenPGP digital signature

Bug#981153: cargo: Please package new upstream

[Sjoerd Simons]

Hey,

Fwiw; MR for prepping an update to cargo 0.56 is available at:
  https://salsa.debian.org/rust-team/cargo/-/merge_requests/9

Full example update on my salsa repo: 
https://salsa.debian.org/sjoerd/cargo/-/tree/debian/experimental


On Tue, Aug 10, 2021 at 11:13:05AM +0200, Sjoerd Simons wrote:
> On Wed, Jan 27, 2021 at 10:52:17AM +0900, Mike Hommey wrote:
> > Source: cargo
> > Version: 0.47.0-3
> > Severity: wishlist
> > 
> > Firefox now requires version 0.48, latest upstream is 0.50, and unstable
> > is on 0.47.
> 
> Fwiw; with Cargo 0.51 the new resolver feature has been stablelized [0]. I'm
> starting to hit issues when building with various crates from the ecosystem as
> that's starting to be adopted now.
> 
> 0: 
> https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver

Bug#934017: O: gnome-shell-pomodoro -- GNOME Shell time-management app

[Tobias Frost]

Package: wnpp
Followup-For: Bug #934017
Control: retitle -1 ITA: gnome-shell-pomodoro -- GNOME Shell time-management app

I'm intending to adopt the package.

(It will be maintained in the debian group in salsa, so it is team-maintained 
by everyone.)

-- 
tobi

Bug#996635: RFS: lebiniou/3.62.1-2 -- user-friendly, powerful music visualization / VJing tool

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: lebiniou
Version : 3.62.1-2
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

   lebiniou - user-friendly, powerful music visualization / VJing tool

The package appears to be lintian-clean.

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.62.1-2.dsc

Changes since the last upload:

  * debian/control: Add Replaces: lebiniou-data (<< 3.61.0) (Closes: 
#995644).


Regards,

--
Olivier Girondel

Bug#994538: dh-python: alias /usr/bin/python disappears after installation

[Ryan Thoryk]

This appears to be the same as #991009, upgrading dh-python breaks 
python-is-python2, causing the /usr/bin/python symlink to disappear upon 
uninstallation.


I currently have dh-python held at the old version, because I still have 
some python2 packages that I need to figure out what to do about.  To 
fix this issue, maybe he could just install the python-is-python3 
package, or have dh-python recommend/depend on it.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#996634: ITP: node-napi-rs -- minimal library for Rust-based native NodeJS modules

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Javascript Maintainers 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-napi-rs
  Version : 1.0.0
  Upstream Author : LongYinan 
* URL : https://napi.rs/
* License : Expat
  Programming Lang: JavaScript, Rust
  Description : minimal library for Rust-based native NodeJS modules

 napi is the command-line tool for napi-rs -
 a minimal library for building compiled Node add-ons in Rust.
 .
 Node.js is a back-end JavaScript runtime environment
 that runs on the V8 engine
 and executes JavaScript code outside a web browser.
 .
 Rust is a multi-paradigm, high-level,
 general-purpose programming language
 designed for performance and safety, especially safe concurrency.

This package is needed by swc.
It will be team-maintained at https://salsa.debian.org/js-team/node-napi-rs

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFq4aIACgkQLHwxRsGg
ASEO4xAAnP7FeXkPlLLUJMJSJHZXalJLudO4R3Y+jGN+5HVchxpCZBKQTd3Z9K7S
qEWqYf5QliS6k5M0pt7HT5f/ObiOSpZxLi397f4TIoBB4iN8MeVBjC9ri8HagYfQ
EdJzymmTo4Q6T5EozY1hpdA58tAahg8sdUHKIdcp4Huj0pfoBAaIKtzUCJwjWXb4
UnLQbUubjMbC6z/syMHqyYU0kk5+5t9bz1Y08EbbO99CEGYPI5SsQ1DWEqMI+qmq
TBFCpPZ93okGg6wCAKBG3NDzNSYm3U7Ye1npL3cmobpu7nsmhEml3mE35q7FYbYZ
+Mbxeh36fwlbbSDjdWubW+PhvMB4idyRbXYPTFp/L9upEHzFPap2t8dUIebQGE4V
MEcFT/TeHvsYK2UGAujDMzbGUBgChZyZ2lXuQihQaEIE7ewIA2U//j00uYUClUct
zdg22jy8HfNlHIZDowuiLpvDPTEHH9hR2Expq4Pb0K4wehTyGCqwKQejrTwmUGo7
xyWmhaJCvxqz9tZxfauh8yd0F01f5RK2c1GF4AS3a5Z7MuBiLurJV7rM1qAUeF+G
kd1rEHt+jNURljOQIM5vPnuI91EffNvPmwG6OmSS1r53ftkKbfp5+d1wkEZTYGRO
tAnoyO1MWFwEZw28t6kZjdZnY4KyQZJM6tjsUFr1Zr1pMrt3H8o=
=bwgp
-END PGP SIGNATURE-

Bug#985951: ITP: upnp-router-control -- UPnP router manager

[Bastian Germann]

Control: retitle -1 ITP: upnp-router-control -- UPnP router manager
Control: reassign -1 wnpp
Control: owner -1 Daniele Napolitano 

Daniele has uploaded a reintroducing package version at 
https://mentors.debian.net/package/upnp-router-control/


I am filing this forgotten ITP for him.

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Justus Winter]

Vasyl Gello  writes:

> What's better about solution to widevinecdm is that it'll solve eternal pain 
> of CoreELEC and LibreELEC requiring them to stick with armv7l userspace and 
> Kodi only to get Widevine support.
>
> However I have an idea to test. Are you able to test builds?

Yes.


signature.asc
Description: PGP signature

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Vasyl Gello]

Hi Justus!

What's better about solution to widevinecdm is that it'll solve eternal pain of 
CoreELEC and LibreELEC requiring them to stick with armv7l userspace and Kodi 
only to get Widevine support.

However I have an idea to test. Are you able to test builds?
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#996632: llvm-toolchain-13: autopkgtest failure on i386

[Sebastian Ramacher]

Source: llvm-toolchain-13
Version: 1:13.0.0-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

While the changelog of 1:13.0.0-3 says those three tests should be
disabled, they are still failing on i386:
| FAIL: LLVM regression suite :: basic_lldb.c (5 of 40)
|  TEST 'LLVM regression suite :: basic_lldb.c' FAILED 

| Script:
| --
| : 'RUN: at line 1';   /usr/bin/clang-13 -g -o 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/basic_lldb.c.tmp
 /tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/tests/basic_lldb.c
| : 'RUN: at line 2';   /usr/bin/lldb-13 -s 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/tests/basic_lldb.in 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/basic_lldb.c.tmp
 | grep "main at basic_lldb.c:"
| --
| Exit Code: 1
|
| Command Output (stderr):
| --
| error: Lost debug server connection
|
| --
|
| 
| FAIL: LLVM regression suite :: basic_lldb2.cpp (6 of 40)
|  TEST 'LLVM regression suite :: basic_lldb2.cpp' FAILED 

| Script:
| --
| : 'RUN: at line 1';   /usr/bin/clang++-13 -g -o 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/basic_lldb2.cpp.tmp
 /tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/tests/basic_lldb2.cpp
| : 'RUN: at line 2';   /usr/bin/lldb-13 -s 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/tests/basic_lldb2.in 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/basic_lldb2.cpp.tmp
 | grep "stop reason = step over"
| --
| Exit Code: 1
|
| Command Output (stderr):
| --
| error: Lost debug server connection
|
| --
|
| 
| PASS: LLVM regression suite :: basic_openmp.c (7 of 40)

...

| PASS: LLVM regression suite :: test_leaksan.c (34 of 40)
| FAIL: LLVM regression suite :: test_tsan.c (35 of 40)
|  TEST 'LLVM regression suite :: test_tsan.c' FAILED 

| Script:
| --
| : 'RUN: at line 4';   /usr/bin/clang-13 -o 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/test_tsan.c.tmp
 -fsanitize=thread -g -O1 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/tests/test_tsan.c
| : 'RUN: at line 5';   /usr/bin/llvm-nm-13 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/test_tsan.c.tmp
 | grep __tsan
| : 'RUN: at line 6';   env TSAN_OPTIONS="log_path=stdout:exitcode=0"  
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/test_tsan.c.tmp
 2>&1 > 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/test_tsan.c.tmp.out
| : 'RUN: at line 7';   grep -q "data race" 
/tmp/autopkgtest-lxc.4iluiq00/downtmp/autopkgtest_tmp/build/tests/Output/test_tsan.c.tmp.out
| --
| Exit Code: 1
|
| Command Output (stderr):
| --
| clang: error: unsupported option '-fsanitize=thread' for target 
'i686-pc-linux-gnu'
|
| --
|
| 
| PASS: LLVM regression suite :: thinlto.c (36 of 40)
| PASS: LLVM regression suite :: warning_conversion.c (37 of 40)
| UNSUPPORTED: LLVM regression suite :: whole-toolchain.c (38 of 40)
| UNSUPPORTED: LLVM regression suite :: whole-toolchain.cpp (39 of 40)
| PASS: LLVM regression suite :: scanbuild_missing_delete.cpp (40 of 40)
| 
| Unsupported Tests (8):
|   LLVM regression suite :: buildid.c
|   LLVM regression suite :: format_diff.c
|   LLVM regression suite :: llvm-ir.c
|   LLVM regression suite :: scanbuild_py_makefile.txt
|   LLVM regression suite :: test_asan_heap.c
|   LLVM regression suite :: test_clangd.txt
|   LLVM regression suite :: whole-toolchain.c
|   LLVM regression suite :: whole-toolchain.cpp
|
| 
| Failed Tests (3):
|   LLVM regression suite :: basic_lldb.c
|   LLVM regression suite :: basic_lldb2.cpp
|   LLVM regression suite :: test_tsan.c
|
|
| Testing Time: 20.59s
|   Unsupported:  8
|   Passed : 29
|   Failed :  3
| make[3]: *** [CMakeFiles/check.dir/build.make:70: CMakeFiles/check] Error 1
| make[2]: *** [CMakeFiles/Makefile2:83: CMakeFiles/check.dir/all] Error 2
| make[1]: *** [CMakeFiles/Makefile2:90: CMakeFiles/check.dir/rule] Error 2
| make: *** [Makefile:124: check] Error 2

See
https://ci.debian.net/data/autopkgtest/testing/i386/l/llvm-toolchain-13/15962397/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996631: llvm-toolchain-13: autopkgtest failure

[Sebastian Ramacher]

Source: llvm-toolchain-13
Version: 1:13.0.0-4
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

The changes in 1:13.0.0-4 introduced new autopkgtest failures:

| autopkgtest [11:21:06]: test cmake-test: [---
| -- The C compiler identification is GNU 10.3.0
| -- The CXX compiler identification is GNU 10.3.0
| -- Detecting C compiler ABI info
| -- Detecting C compiler ABI info - done
| -- Check for working C compiler: /usr/bin/cc - skipped
| -- Detecting C compile features
| -- Detecting C compile features - done
| -- Detecting CXX compiler ABI info
| -- Detecting CXX compiler ABI info - done
| -- Check for working CXX compiler: /usr/bin/c++ - skipped
| -- Detecting CXX compile features
| -- Detecting CXX compile features - done
| -- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) 
| -- Found LibXml2: /usr/lib/aarch64-linux-gnu/libxml2.so (found version 
"2.9.12") 
| CMake Error at /usr/lib/llvm-13/lib/cmake/llvm/LLVMExports.cmake:1501 
(message):
|   The imported target "llvm-omp-device-info" references the file
|
|  "/usr/lib/llvm-13/bin/llvm-omp-device-info"
|
|   but this file does not exist.  Possible reasons include:
|
|   * The file was deleted, renamed, or moved to another location.
|
|   * An install or uninstall procedure did not complete successfully.
|
|   * The installation package was faulty and contained
|
|  "/usr/lib/llvm-13/lib/cmake/llvm/LLVMExports.cmake"
|
|   but not all the files it references.
|
| Call Stack (most recent call first):
|   /usr/lib/llvm-13/cmake/LLVMConfig.cmake:299 (include)
|   CMakeLists.txt:3 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
| See also 
"/tmp/autopkgtest-lxc.w3ziie21/downtmp/autopkgtest_tmp/build/CMakeFiles/CMakeOutput.log".
| autopkgtest [11:21:08]: test cmake-test: ---]
| autopkgtest [11:21:09]: test cmake-test:  - - - - - - - - - - results - - - - 
- - - - - -
| cmake-test   FAIL non-zero exit status 1

See
https://ci.debian.net/data/autopkgtest/testing/amd64/l/llvm-toolchain-13/15959122/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996630: toxic FTBFS: error: format not a string literal and no format arguments

[Adrian Bunk]

Source: toxic
Version: 0.11.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=toxic=0.11.1-2

...
/<>/src/game_chess.c: In function ‘chess_print_status’:
/<>/src/game_chess.c:1629:52: error: format not a string literal 
and no format arguments [-Werror=format-security]
 1629 | mvwprintw(win, board->y_top_bound  - 2, x_mid, message);
  |^~~
/<>/src/game_chess.c:1633:63: error: format not a string literal 
and no format arguments [-Werror=format-security]
 1633 | mvwprintw(win, board->y_bottom_bound + 2, x_mid, 
state->status_message);
  |  
~^~~~
  CCgame_util.o
  CCgame_snake.o
cc1: some warnings being treated as errors
make[1]: *** [Makefile:83: /<>/build/game_chess.o] Error 1

Bug#995587: transition: ruby3.0-add

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-10-15 06:44:36 -0300, Antonio Terceiro wrote:
> Hi,
> 
> On Sat, Oct 02, 2021 at 03:14:39PM -0300, Antonio Terceiro wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > We would like to add support for ruby3.0 in ruby-defaults.
> > 
> > Ben file:
> > 
> > title = "ruby3.0-add";
> > is_affected = (.depends ~ /ruby2.7 | .depends ~ /ruby3.0/) & !.source ~ 
> > /^(ruby2.7|ruby3.0|ruby-defaults)$/);
> > is_good = .depends ~ /ruby3.0/;
> > is_bad = .depends ~ /ruby2.7/ & !.depends ~ /ruby3.0/;
> > 
> > We already did a mass rebuild some time ago, and the results don't look
> > bad. We should be doing a new one soon, and will come up with a list of
> > binNMUs
> 
> This is a friendly ping. We would like to make the switch in unstable
> soon and start doing binNMUs.
> 
> We have these bugs related to this transition:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby3.0;users=debian-r...@lists.debian.org
> 
> Most of those bugs are for leaf libraries. We already started fixing the
> ones that block a lof of other (e.g. the ones with C extensions that
> FTBFS with ruby3.0) so they are ready to be binNMUed.

ruby3.0 isn't in testing yet - it currently fails to build on ppc64el.
So let's at least wait until it migrated.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Justus Winter]

Vasyl Gello  writes:

> Well, as far as I have researched, there might be even the possibility
> to co-install two different Kodi sets for different architectures, but
> that will require fixing the whole Python packaging down to
> python3.x-minimal.
>
> So what did you, do specifically? Did you rebuild Kodi with
> s/arch:all/arc:any/ for kodi-data ?

I downloaded the kodi-data deb, unpacked it using dpkg-deb, edited the
control file dropping the Multiarch: foreign and changing the
Architecture: to armhf.  Now, the resulting package depended on the
armhf versions of some python3 package with native code, which in turn
pulled the whole python3 stack to armhf.

> The only need in armhf build on arm64 is Widevine CDM, correct? I
> think it has to be solved in slightly different way - by providing a
> decoupled plug-in communicating with Kodi by means of shared memory /
> pipe / whatever. I have asked the rest of Kodi team about it.

Sure, that'd be a great solution also to contain that code.

Justus


signature.asc
Description: PGP signature

Bug#996607: transition: mutter and GNOME Shell 41 (libmutter-9)

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-10-16 00:49:39 +0100, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
> Forwarded: https://release.debian.org/transitions/html/auto-mutter.html
> 
> I know it only seems like yesterday that we did the mutter 40 transition;
> but it was delayed by a few months by the freeze, and a GNOME release
> cycle is only 6 months long, so it's already time for the next major
> release. This is staged in experimental, and is not entangled with
> other packages like evolution-data-server, gsettings-desktop-schemas
> and libgweather this time round.
> 
> As usual this will require sourceful uploads of:
> 
> * mutter
> * gnome-shell
> * gnome-shell-extensions
> * budgie-desktop (non-GNOME-team but the maintainer is usually very quick,
>   and has already uploaded a suitable version to experimental)
> 
> and then updates or removal for most Shell extensions.
> 
> Tracker: https://release.debian.org/transitions/html/auto-mutter.html
> 
> I already did some mass-bug-filing for extensions, tracked by
> .
> Some are already fixed in experimental, or even in unstable for extensions
> that happen to be compatible with both 40 and 41. Many of the rest were
> already autoremoved from testing due to incompatibility with Shell 40.

Please go ahead

Cheers

> 
> smcv
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996619: transition: ros-ros-comm

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ros-ros-comm.html

On 2021-10-16 12:14:55 +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: jspri...@debian.org
> 
> Hi release team,
> 
> I would like to transition ros-ros-comm. The auto generated ben file
> is ok and I've rebuild all reverse dependencies successfully.

Please go ahead

Cheers

> 
> Cheers Jochen
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996615: transition: ros-geometric-shapes

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ros-geometric-shapes.html

On 2021-10-16 10:01:01 +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> I would like to transition ros-geometric-shapes. The autogenerated Ben
> file is ok and I've tested the downstream dependency successfully.

Please go ahead

Cheers

> 
> Cheers Jochen
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996627: kodi-data: Kodi cannot be installed on a foreign architecture

[Vasyl Gello]

Hi Justus!

Well, as far as I have researched, there might be even the possibility to 
co-install two different Kodi sets for different architectures, but that will 
require fixing the whole Python packaging down to python3.x-minimal.

So what did you, do specifically? Did you rebuild Kodi with s/arch:all/arc:any/ 
for kodi-data ?

The only need in armhf build on arm64 is Widevine CDM, correct? I think it has 
to be solved in slightly different way - by providing a decoupled plug-in 
communicating with Kodi by means of shared memory / pipe / whatever. I have 
asked the rest of Kodi team about it.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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