Bug#1025424: beast-mcmc: please enable autopkgtest

[Andrius Merkys]

Hi,

Since #1025953 has been fixed, there are no more blockers for 
autopkgtest. I have tried running some of the examples, some of them 
pass, but there are failing ones:


$ beast-mcmc -overwrite 
/usr/share/doc/beast-mcmc/examples/Calibrations/constrainedTaxaTest3.xml


[snip]

Loading additional development parsers from 
development_parsers.properties, which is additional set of parsers only 
available for development version ...

Parsing XML file: constrainedTaxaTest3.xml
  File encoding: UTF8
Looking for plugins in /home/andrius/plugins

Creating the tree model, 'treeModel'
  taxon count = 4
  tree height = 192.94474192605344
Dec 18, 2022 2:23:13 AM dr.app.beast.BeastMain 
SEVERE: Parsing error - poorly formed BEAST file, constrainedTaxaTest3.xml:
Error parsing '' element with id, 'null':
Scale operator can only be used on parameters with an infinite upper or 
lower bound (use a RandomWalk) (xx)


Error thrown at: 
dr.inferencexml.operators.ScaleOperatorParser.parseXMLObject(Unknown Source)


Exit code is non-zero. Maybe upstream has forgotten to update the examples?

Best,
Andrius

Bug#1026309: dh_link: Dynamically create symlinks for localized man pages

[Helge Kreutzmann]

Package: debhelper
Version: 13.11.1
Severity: wishlist
Tags: l10n
X-Debbugs-Cc: Marc Haber 

I'm the Debian maintainer for manpages-l10n. This package carries
thounds of man pages for various languages.  As in the english 
original, man pages are known under various names and .so links are 
present. Upstream converts this .so links to a small text file
(callled links.txt) which would be handy for dh_link(1). This 
file contains all known so links.

Depending on the translator's work, man pages might appear or vanish 
(if they are not translated enough, see po4a(1) for details).
Therefore, creating and maintaining static .links files for dh_link is
not an option. Even creating the file with some helper code before the
build is not possible - only after building the pages I know if the
translation (i.e. the source file for dh_link) is there or not (for 
this language).

Upstreams links.txt is the "complete set", i.e. in
case *all* man pages would be translated, this would be the .links
file (maybe with some slight massaging to add the build path).
(Ideally the file name for dh_link would not be hardcoded).

However, if I provide this list to dh_link then *all* links are
created, even if the man page is not present (not build), creating
dangling symlinks. 

Therefore it would be great if I could provide dh_link (or
dh_installman) with this file and only those links are set where the
source file actually exists.

Possibly this could also be resolved differently, I noticed #971039
and #1006939 which are adressing similiar (albeit slightly different)
issues; thus I took Marc in CC.

Until this is implemented, I'm looking how to do this myself in
manpages-l10n.

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-2
ii  dpkg 1.21.12
ii  dpkg-dev 1.21.12
ii  dwz  0.14+20220924-2
ii  file 1:5.41-4
ii  libdebhelper-perl13.11.1
ii  libdpkg-perl 1.21.12
ii  man-db   2.11.1-1
ii  perl 5.36.0-6
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202204

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices

[John Scott]

Control: owner -1 glaub...@physik.fu-berlin.de

On Sun, 2022-12-18 at 08:09 +0100, John Paul Adrian Glaubitz wrote:
> I can sponsor this upload.

Thanks so much! Please go ahead whenever you're ready.


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

Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices

[John Paul Adrian Glaubitz]

Hello John!

On 12/18/22 06:22, John Scott wrote:

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net 
debian-sup...@lists.debian.org

Dear mentors and fellow Electronics Team members,

I am looking for a sponsor for my package "gcc-sh-elf":

  * Package name : gcc-sh-elf
Version  : 5
  * License  : GPL-3+
  * Vcs  : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
Section  : devel


I can sponsor this upload.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net 
debian-sup...@lists.debian.org

Dear mentors and fellow Electronics Team members,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name : gcc-sh-elf
   Version  : 5
 * License  : GPL-3+
 * Vcs  : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section  : devel

The source builds the following binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH 
devices

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

  https://mentors.debian.net/package/gcc-sh-elf/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_5.dsc

Changes since the last upload:

 gcc-sh-elf (5) experimental; urgency=medium
 .
   * Bump Standards-Version to 4.6.2, no changes required.
   * Switch to GCC 13.

This upload is so we can investigate issues as new GCC 13 snapshots get
uploaded. Furthermore, I expect it will be helpful for the reviewers of
carl9170 when I upload that in a few days. I will push my changes to Git
once the package is uploaded.

I have not yet investigated the test suite regressions, but this package
is going to experimental, so that's okay. The comprehensive autopkgtests
still pass, and those are more important.

Unless you happen to have an AR9170 wireless adapter, you probably don't
have real hardware to test this with. Fortunately this package includes
a Wine-like wrapper called sh-elf-run that enables running the built
binaries, so you can test this package even if you know nothing more
than the basics of C.


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

Bug#985840: gitlab-shell: should not ship /usr/bin/check

[Abhijith PA]

On 18/12/22 03:06 AM, Abhijith PA wrote:
> Praveen, mdbilal
> 
> On 24/03/21 07:11 PM, Julien Cristau wrote:
> 
> ...
> 
> > /usr/bin/check seems like an awfully generic program name to be shipped
> > in something like gitlab-shell.  Please don't.
> 
> I have reported this upstream. 
> https://gitlab.com/gitlab-org/gitlab-shell/-/issues/603

Hey, I didn't know you reported upstream long time before. 
https://gitlab.com/gitlab-org/gitlab-shell/-/issues/197

I will close my issue opened upstream.


--abhijith

Bug#807653: nedit and numeric keypad

[Alex Kent Hajnal]

The tests I've run are interesting:

When logged in to my desktop running Ubuntu 22.04.1, Xorg 
1:7.7+23ubuntu2 I see the issue for:

 * nedit run locally
 * nedit run on my laptop via ssh
 * nedit run on my server via ssh

When logged in to my laptop running Ubuntu 14.04.2, Xorg 
1:7.7+1ubuntu8.1 nedit runs fine for:

 * nedit run locally
 * nedit run on my server via ssh
 * nedit run on my desktop via ssh

It seems to me that the issue may actually lie in nedit's interaction 
with the running X server and not with a local library such as libXm.

Bug#1026307: Kwrite no longer remembers what files it had open before logging out of KDE or rebooting the PC

[local10]

Package: kwrite  
Version: 4:22.12.0-2


Hi,

After a recent (about December 15, 2022, +/- a few days) upgrade Kwrite no 
longer remembers what files it had open before logging out of KDE or rebooting 
the PC. If I had, for example, two files open in Kwrite in two separate windows 
before logging out of KDE, when logged back into KDE, KDE would open two empty 
Kwrite windows instead of properly showing the files that used to be in those 
windows.

Before this change, Kwrite used to remember what files it had open, and after 
logging out of KDE and then logging back into KDE would open those Kwrite 
windows and show the files in them properly.

Regards,



Operating System: Debian 12 Bookworm GNU/Linux
KDE Plasma Version: 5.26.4  KDE Frameworks Version: 5.100.0  Qt Version: 5.15.6
Kernel Version: 6.0.0-6-amd64 (64-bit)
Graphics Platform: X11


Possibly the following upgrade broke Kwrite for me though I can't be 100% sure:

Aptitude 0.8.13: log report
Thu, Dec 15 2022 23:19:47 -0500

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 29 packages, and remove 0 packages.
6542 kB of disk space will be used

[UPGRADE] ark:amd64 4:22.08.1-1 -> 4:22.12.0-2
[UPGRADE] dragonplayer:amd64 4:22.08.1-1 -> 4:22.12.0-2
[UPGRADE] intel-media-va-driver-non-free:amd64 22.6.3+ds1-1 -> 22.6.4+ds1-1
[UPGRADE] juk:amd64 4:22.04.3-1 -> 4:22.12.0-2
[UPGRADE] kamera:amd64 4:21.12.3-1 -> 4:22.12.0-2
[UPGRADE] kate:amd64 4:22.04.3-1 -> 4:22.12.0-2
[UPGRADE] kate5-data:amd64 4:22.04.3-1 -> 4:22.12.0-2
[UPGRADE] kcalc:amd64 4:22.04.1-1 -> 4:22.12.0-2
[UPGRADE] kdeconnect:amd64 21.12.3-2 -> 22.12.0-2
[UPGRADE] kdialog:amd64 4:21.12.3-1 -> 4:22.12.0-2
[UPGRADE] keditbookmarks:amd64 21.12.3-1 -> 22.12.0-2
[UPGRADE] kfind:amd64 4:21.12.3-1 -> 4:22.12.0-2
[UPGRADE] khelpcenter:amd64 4:22.04.1-1 -> 4:22.12.0-2
[UPGRADE] kio-extras:amd64 4:22.04.3-1+b1 -> 4:22.12.0-2
[UPGRADE] kio-extras-data:amd64 4:22.04.3-1 -> 4:22.12.0-2
[UPGRADE] konsole:amd64 4:22.08.1-1 -> 4:22.12.0-2
[UPGRADE] konsole-kpart:amd64 4:22.08.1-1 -> 4:22.12.0-2
[UPGRADE] kwalletmanager:amd64 4:22.04.1-1 -> 4:22.12.0-2
[UPGRADE] kwrite:amd64 4:22.04.3-1 -> 4:22.12.0-2
[UPGRADE] libkaccounts2:amd64 4:21.12.3-1 -> 4:22.12.0-2
[UPGRADE] libkf5baloowidgets-bin:amd64 4:22.08.1-1 -> 4:22.12.0-2
[UPGRADE] libkf5baloowidgets5:amd64 4:22.08.1-1 -> 4:22.12.0-2
[UPGRADE] libkf5kexiv2-15.0.0:amd64 21.12.3-1 -> 22.12.0-2
[UPGRADE] liblua5.3-0:amd64 5.3.6-1+b1 -> 5.3.6-2
[UPGRADE] libqmobipocket2:amd64 4:21.12.3-1 -> 4:22.12.0-2
[UPGRADE] pylint:amd64 2.15.5-1 -> 2.15.8-1
[UPGRADE] python3-dill:amd64 0.3.4-2 -> 0.3.6-1
[UPGRADE] python3-psutil:amd64 5.9.2-1+b1 -> 5.9.4-1
[UPGRADE] sweeper:amd64 4:21.12.3-1 -> 4:22.12.0-2


Log complete.

Bug#1017487: RFP: python-sphinx-design -- Sphinx extension for designing view size-responsive web components

[Sandro Tosi]

> > matplotlib is going to depend on this library, so i'll have a look at
> > packaging it. retitle/owner commands coming up
>
> This package is also needed to update dask.
> What is the status? Do you have a prototype already?
> If you want I could help with it.

mpl wont build a -doc package any longer so feel free to take over
this WNPP bug. I have not started working on it

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1026306: g++-mingw-w64-x86-64-win32: alternative not cleaned up: x86_64-w64-mingw32-g++

[Paul Wise]

Package: g++-mingw-w64-x86-64-win32
Version: 12.2.0-10+25
Severity: normal
Usertags: alternatives

It looks like the recent upgrade(s) didn't clean up an alternative:

 * x86_64-w64-mingw32-g++

The symlink for this points directly at the win32 threading model:

   $ ls -l /usr/bin/x86_64-w64-mingw32-g++
   lrwxrwxrwx 1 root root 28 Dec 12 16:00 /usr/bin/x86_64-w64-mingw32-g++ -> 
x86_64-w64-mingw32-g++-win32*

But the alternatives for them are still present on this system:

   $ update-alternatives --get-selections | grep mingw
   x86_64-w64-mingw32-g++ auto /usr/bin/x86_64-w64-mingw32-g++-win32
   
   $ cat /var/lib/dpkg/alternatives/x86_64-w64-mingw32-g++ 
   auto
   /usr/bin/x86_64-w64-mingw32-g++
   x86_64-w64-mingw32-c++
   /usr/bin/x86_64-w64-mingw32-c++
   
   /usr/bin/x86_64-w64-mingw32-g++-win32
   60
   /usr/bin/x86_64-w64-mingw32-c++-win32

   $ ls -l /etc/alternatives/x86_64-w64-mingw32-[gc]++
   lrwxrwxrwx 1 root root 37 Feb 12 2022 
/etc/alternatives/x86_64-w64-mingw32-c++ -> 
/usr/bin/x86_64-w64-mingw32-c++-win32*
   lrwxrwxrwx 1 root root 37 Feb 12 2022 
/etc/alternatives/x86_64-w64-mingw32-g++ -> 
/usr/bin/x86_64-w64-mingw32-g++-win32*
   
   $ ls -l /usr/bin/x86_64-w64-mingw32-c++
   lrwxrwxrwx 1 root root 28 Dec 12 16:00 /usr/bin/x86_64-w64-mingw32-c++ -> 
x86_64-w64-mingw32-c++-win32*
   
It looks like this was caused by a typo(?) in the preinst scripts:

   $ grep altern /var/lib/dpkg/info/*mingw*
   /var/lib/dpkg/info/gcc-mingw-w64-i686-win32.preinst:update-alternatives 
--remove i686-w64-mingw32-gcc /usr/bin/i686-w64-mingw32-gcc-win32
   /var/lib/dpkg/info/gcc-mingw-w64-x86-64-win32.preinst:update-alternatives 
--remove x86_64-w64-mingw32-gcc /usr/bin/x86_64-w64-mingw32-gcc-win32
   /var/lib/dpkg/info/g++-mingw-w64-i686-win32.preinst:update-alternatives 
--remove i686-w64-mingw32-g++ /usr/bin/i686-w64-mingw32-g++-win32
   /var/lib/dpkg/info/g++-mingw-w64-x86-64-win32.preinst:update-alternatives 
--remove x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-fi

   $ ls /usr/bin/x86_64-w64-mingw32-fi
   ls: cannot access '/usr/bin/x86_64-w64-mingw32-fi': No such file or directory

Here is some info from the apt history log of the upgrades:

   Start-Date: 2022-12-17 12:00:03
   Commandline: /usr/bin/unattended-upgrade
   Upgrade: gcc-mingw-w64-x86-64:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
gcc-mingw-w64:amd64 (10.3.0-15+24.4, 12.2.0-10+25), g++-mingw-w64:amd64 
(10.3.0-15+24.4, 12.2.0-10+25), gcc-mingw-w64-i686:amd64 (10.3.0-15+24.4, 
12.2.0-10+25)
   End-Date: 2022-12-17 12:00:10
   
   Start-Date: 2022-12-17 19:12:23
   Requested-By: pabs (1000)
   Upgrade: g++-mingw-w64-x86-64-win32:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
gcc-mingw-w64-i686-win32:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
gcc-mingw-w64-x86-64-win32:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
gcc-mingw-w64-x86-64-win32-runtime:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
gcc-mingw-w64-i686-win32-runtime:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
g++-mingw-w64-i686-win32:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
g++-mingw-w64-x86-64:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
gcc-mingw-w64-base:amd64 (10.3.0-15+24.4, 12.2.0-10+25), 
g++-mingw-w64-i686:amd64 (10.3.0-15+24.4, 12.2.0-10+25)
   Purge: gcc-mingw-w64-x86-64-posix:amd64 (10.3.0-15+24.4), 
gcc-mingw-w64-i686-posix-runtime:amd64 (10.3.0-15+24.4), 
gcc-mingw-w64-x86-64-posix-runtime:amd64 (10.3.0-15+24.4), 
g++-mingw-w64-i686-posix:amd64 (10.3.0-15+24.4), 
g++-mingw-w64-x86-64-posix:amd64 (10.3.0-15+24.4), 
gcc-mingw-w64-i686-posix:amd64 (10.3.0-15+24.4)
   End-Date: 2022-12-17 19:13:52

Here is the terminal log of the two upgrades:

   Log started: 2022-12-17 12:00:03
   (Reading database ... 698987 files and directories currently installed.)
   Preparing to unpack .../g++-mingw-w64_12.2.0-10+25_all.deb ...
   Unpacking g++-mingw-w64 (12.2.0-10+25) over (10.3.0-15+24.4) ...
   Preparing to unpack .../gcc-mingw-w64-i686_12.2.0-10+25_all.deb ...
   Unpacking gcc-mingw-w64-i686 (12.2.0-10+25) over (10.3.0-15+24.4) ...
   Preparing to unpack .../gcc-mingw-w64-x86-64_12.2.0-10+25_all.deb ...
   Unpacking gcc-mingw-w64-x86-64 (12.2.0-10+25) over (10.3.0-15+24.4) ...
   Preparing to unpack .../gcc-mingw-w64_12.2.0-10+25_all.deb ...
   Unpacking gcc-mingw-w64 (12.2.0-10+25) over (10.3.0-15+24.4) ...
   Setting up g++-mingw-w64 (12.2.0-10+25) ...
   Setting up gcc-mingw-w64-i686 (12.2.0-10+25) ...
   Setting up gcc-mingw-w64-x86-64 (12.2.0-10+25) ...
   Setting up gcc-mingw-w64 (12.2.0-10+25) ...
   Log ended: 2022-12-17 12:00:10
   
   Log started: 2022-12-17 19:12:23
   (Reading database ... 698988 files and directories currently installed.)
   ...
   dpkg: g++-mingw-w64-i686-posix: dependency problems, but removing anyway as 
you requested:
g++-mingw-w64-i686 depends on g++-mingw-w64-i686-posix.
   
   Removing g++-mingw-w64-i686-posix (10.3.0-15+24.4) ...
   dpkg: gcc-mingw-w64-i686-posix-runtime: dependency problems, but removing 
anyway as you requested:
gcc-mingw-w64-i686-posix 

Bug#1024078: pytango FTBFS with Python 3.11 as supported version

[James Addison]

Source: pytango
Followup-For: Bug #1024078

As a maintenance note: it looks like upstream pytango v9.4.0 should resolve 
this; it includes compatibility[1] with Python 3.11.

That release is currently planned[2] for the end of January, 2023.

[1] - https://gitlab.com/tango-controls/pytango/-/merge_requests/498

[2] - https://gitlab.com/tango-controls/pytango/-/issues/491#note_1193929461

Bug#1026305: ksh93: time: not found

[Thorsten Glaser]

Package: ksh93u+m
Version: 1.0.4-2
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

The manpage documents the time construct but it does
not seem to be available.

ksh_2020.0.0+really93u+20120801-9 is also affected.


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages ksh93u+m depends on:
ii  libc6  2.36-6

ksh93u+m recommends no packages.

Versions of packages ksh93u+m suggests:
ii  binfmt-support  2.2.2-2

-- no debconf information

Bug#1025733: merge 1020018 1025733

[Nicolas Boulenguez]

forcemerge 1020018 1025733
thanks

This is a duplicate.
1020018 is closed by libxmlada/23.0.0-1 in experimental.

Bug#1026304: obantoo build-depends on dropped package.

[Peter Michael Green]

Package: obantoo
Version: 2.1.12+ds1-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same 
release"

User: debian...@lists.debian.org
Usertags: edos-uninstallable

obantoo build-depends on libitext5-java-doc which is no longer built
by the libitext5-java source package. It is still present in unstable as
a cruft package, but is completely gone from testing.

Bug#1026104: longstanding problem with dependencies of python3-numpy in testing

[Sean Whitton]

Hello,

We had a plan to have a meeting on Tuesday if anything came up.

Reviewing #945824, I believe that even if we were eventually to overrule
the Python maintainers on this, (i) the impact to users in the meantime
is very low, and (ii) we are about to freeze, so it's unlikely we'd make
any decision applying to bookworm.

So I think we should leave this for the January meeting.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1026303: clang-tidy: clang-diagnostic-unused-macros: Spurious trigger in header guards

[Alejandro Colomar]

Package: clang-tidy
Version: 1:14.0-55.2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

The clang-tidy clang-diagnostic-unused-macros warning triggers on header
guards, which of course are unused.

Cheers,

Alex


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clang-tidy depends on:
ii  clang-tidy-14  1:14.0.6-9

clang-tidy recommends no packages.

clang-tidy suggests no packages.

-- no debconf information

Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)

[Sean Whitton]

Hello,

On Sat 17 Dec 2022 at 04:43PM +01, Guillem Jover wrote:

> Control: reopen -1
>
> Hi!
>
> Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields
> for things that fix part of a bug, but are not intended yet to close it,
> for which I use «Closes:».
>
> And for some reason I think I also got the impression, even though
> the stanza changes had been committed, they could still be backed out.
> (BTW I've now gone over the wiki and updated all paragraph references
> that applied to stanza.)
>
> In any case, I've sat down and gone over the meat of the original
> report. See below.

We're sticking with 'stanza', and in light of that, could you confirm
that the bug is reopened in order to make additional fixes, rather than
back anything else out?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1026302: isystem: Specify path for system headers

[Alejandro Colomar]

Package: cppcheck
Version: 2.9-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

Similar to GCC's -isystem to specify a path to check for system headers,
it would be very useful to tell cppcheck where to find system headers.
I'm writing a library, whose headers include eachother using <> since
it's intended to be used as a system library.  However, for building
(and linting) it, I need to tell the compiler (and linters) that the
includes are not really system includes.

Would you please add such an option?

Thanks,

Alex


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cppcheck depends on:
ii  libc6 2.36-6
ii  libgcc-s1 12.2.0-10
ii  libpcre3  2:8.39-14
ii  libstdc++612.2.0-10
ii  libtinyxml2-9 9.0.0+dfsg-3.1
ii  python3   3.10.6-3
ii  python3-pygments  2.13.0+dfsg-1

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
ii  clang 1:14.0-55.2+b1
ii  clang-tidy1:14.0-55.2+b1
pn  cppcheck-gui  

-- no debconf information

Bug#1026301: RM: mig -- NBS; not built any more

[Samuel Thibault]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: m...@packages.debian.org
Control: affects -1 + src:mig

Hello,

Since version 1.8+git20200618-10, we do not build the mig package on
non-linux ports, could you thus please remove the binary packages:

mig:amd64 1.8+git20200618-9
mig:i386 1.8+git20200618-9

Thanks,
Samuel

Bug#1026300: pycodestyle: please package 2.10.0

[Sylvestre Ledru]

Package: pycodestyle
Version: 2.9.1-1
Severity: wishlist

Dear Maintainer,

Could you please package pycodestyle ?
it is a necessary version for autopep8.

Thanks
Sylvestre


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

Kernel: Linux 6.0.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 pycodestyle depends on:
ii  python33.10.6-1
ii  python3-pkg-resources  65.5.0-1
ii  python3-pycodestyle2.9.1-1

pycodestyle recommends no packages.

pycodestyle suggests no packages.

-- no debconf information

Bug#1026299: media-types: Markdown should be added to text/plain as well.

[Eric F]

Package: media-types
Version: 4.0.0
Severity: normal
X-Debbugs-Cc: e...@disroot.org

Dear Maintainer,

   * What led up to the situation?

   When I tried to open/reading markdown files in Firefox, it doesn't
   work, and you need an add-on. Despite the addon, it still doesn't work.

   When looking in 'about:config', searching for 'mime', it show they use this
   file. After searching a bit, there a several pages describing this problem,
   like:
 - 
https://9to5answer.com/how-to-get-the-markdown-viewer-addon-of-firefox-to-work-on-linux

Markdown is widely used today, so it should be covered/included as good
as possible.

Best regards,
- Eric

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

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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

-- Configuration Files:
/etc/mime.types changed:



text/iuls   uls
text/jcr-cndcnd
text/markdown   md mkd markdown
text/mizar  miz
text/n3 n3
text/parameters
text/parityfec
text/plain  txt text pot brf srt md mkd markdown



-- no debconf information

Bug#1026298: datalad: FTBFS without network access

[Graham Inggs]

Source: datalad
Version: 0.17.10-1
Severity: serious
Tags: ftbfs

Hi Maintainer

As can be seen on reproducible builds [1], datalad 0.17.10-1 FTBFS
without network access.  I've copied what I hope is the relevant part
of a successful build below.

Regards
Graham


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


Installed /<>
Processing dependencies for datalad==0.17.10
Searching for chardet<5.0.0,>=3.0.4
Reading https://pypi.org/simple/chardet/
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:123:
PkgResourcesDeprecationWarning:  is an invalid version and will not be
supported in a future release
  warnings.warn(
Downloading 
https://files.pythonhosted.org/packages/19/c7/fa589626997dd07bd87d9269342ccb74b1720384a4d739a1872bd84fbe68/chardet-4.0.0-py2.py3-none-any.whl#sha256=f864054d66fd9118f2e67044ac8981a54775ec5b67aed0441892edb553d21da5
Best match: chardet 4.0.0
Processing chardet-4.0.0-py2.py3-none-any.whl
Installing chardet-4.0.0-py2.py3-none-any.whl to /<>/bin
Adding chardet 4.0.0 to easy-install.pth file
Installing chardetect script to bin

Bug#1026297: unifrac-tools: Frequent parallel FTBFS

[Adrian Bunk]

Source: unifrac-tools
Version: 1.1.3-1
Severity: serious
Tags: ftbfs patch
Control: block 1021542 by -1

https://tests.reproducible-builds.org/debian/history/unifrac-tools.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/unifrac-tools.html
https://buildd.debian.org/status/logs.php?pkg=unifrac-tools=arm64

...
make[3]: Entering directory '/<>/src'
make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
make[3]: Entering directory '/<>/src'
make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
make[3]: Entering directory '/<>/src'
make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
...
h5c++ -Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp -Wextra -Wno-unused-parameter 
-Wall  -std=c++14 -pedantic -I. -O4 -fPIC -L/<>/debian/tmp/usr/lib 
 faithpd.cpp -o faithpd tree.o biom.o unifrac_internal.o unifrac_cmp_cpu.o 
unifrac.o cmd.o skbio_alt.o api.o -lhdf5_cpp -llz4 -llapacke -lblas -lpthread
h5c++ -Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp -Wextra -Wno-unused-parameter 
-Wall  -std=c++14 -pedantic -I. -O4 -fPIC -L/<>/debian/tmp/usr/lib 
 faithpd.cpp -o faithpd tree.o biom.o unifrac_internal.o unifrac_cmp_cpu.o 
unifrac.o cmd.o skbio_alt.o api.o -lhdf5_cpp -llz4 -llapacke -lblas -lpthread
/usr/bin/ld: 
/usr/lib/gcc/aarch64-linux-gnu/12/../../../aarch64-linux-gnu/Scrt1.o: in 
function `_start':
(.text+0x1c): undefined reference to `main'
/usr/bin/ld: (.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:108: faithpd] Error 1


The problem is the toplevel Makefile calling make in src/ up to three
times in parallel during the build.

The easiest workaround is:

--- debian/rules.old2022-12-17 22:53:06.643268060 +
+++ debian/rules2022-12-17 22:53:11.403264194 +
@@ -7,7 +7,7 @@
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 %:
-   dh $@
+   dh $@ --no-parallel
 
 override_dh_auto_build:
mkdir -p $(CURDIR)/debian/tmp/usr/bin

Bug#805375: dash: interactive dash mishandles the quit character (^\)

[Vincent Lefevre]

Control: found -1 0.5.11+git20210903+057cd650a4ed-9

On 2015-12-07 02:27:29 +0100, Vincent Lefevre wrote:
> On 2015-12-06 23:22:11 +0100, Jilles Tjoelker wrote:
> > Dash is behaving correctly here. The flush of the input queue occurs
> > because the NOFLSH flag is not set in termios c_lflag. After 'stty
> > noflsh', there is still '^\' visible but the characters before it are
> > not discarded.
> 
> The behavior is different with bash and zsh, but I suppose that this
> is because neither bash nor zsh uses the cooked mode.

About the default behavior, there are several behaviors, depending
on the shell. I've just asked in the austin list what is expected:

https://www.mail-archive.com/austin-group-l@opengroup.org/msg10539.html

> > The default (to flush) is probably more useful, though.
> 
> Well, if the signal is ignored, then it is more intuitive to disable
> flushing, IMHO, i.e. to ignore Ctrl-\ entirely. However the terminal
> handling is buggy in this case (I mean, if one types "foo" then Ctrl-\
> then [Backspace], only the backslash is erased so that one gets "foo^"
> displayed instead of "fo").

There are still display issues, whether noflsh is used or not.

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

Bug#1026296: unifrac-tools: Incorrect Homepage link

[Adrian Bunk]

Source: unifrac-tools
Version: 1.1.3-1
Severity: minor

debian/control:Homepage: https://github.com/biocore/unifrac-tools

This should be https://github.com/biocore/unifrac-binaries

Bug#1026295: fgallery: Missing fcaption utility

[Carles Pina i Estany]

Package: fgallery
Version: 1.9.0~geo1+ds-1
Severity: wishlist

Dear Maintainer,

In the newest release fgallery there is a utility: utils/fcaption . I've
found this utility very useful to edit the captions of the images.

I wonder if it's possible to package this utility in the fgallery
package? (or in a different package).

Thanks very much for packaging fgallery anyway!

Carles

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

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

Bug#1026294: vip-manager: FTBFS: cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument to arp.NewPacket

[Mathias Gibbens]

Source: vip-manager
Version: 1.0.2-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

  vip-manager is failing to build in a clean sid schroot:

> github.com/cybertec-postgresql/vip-manager/ipmanager
> # github.com/cybertec-postgresql/vip-manager/ipmanager
> src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:101:3:
>  cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument to 
> arp.NewPacket
> src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:103:3:
>  cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument to 
> arp.NewPacket
> src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:125:3:
>  cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument to 
> arp.NewPacket
> src/github.com/cybertec-postgresql/vip-manager/ipmanager/basicConfigurer_linux.go:127:3:
>  cannot use c.VIP (variable of type net.IP) as type netip.Addr in argument to 
> arp.NewPacket


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

Bug#985840: gitlab-shell: should not ship /usr/bin/check

[Abhijith PA]

Praveen, mdbilal

On 24/03/21 07:11 PM, Julien Cristau wrote:

...

> /usr/bin/check seems like an awfully generic program name to be shipped
> in something like gitlab-shell.  Please don't.

I have reported this upstream. 
https://gitlab.com/gitlab-org/gitlab-shell/-/issues/603

For now, this will work. 
https://salsa.debian.org/go-team/packages/gitlab-shell/-/commit/0a36733fd8bc2ba10f9a7afd3ab306c96114d5a9

--abhijith

signature.asc
Description: PGP signature

Bug#1026293: sqlite3: CVE-2022-46908

[Salvatore Bonaccorso]

Source: sqlite3
Version: 3.40.0-1
Severity: important
Tags: security upstream
Forwarded: https://sqlite.org/forum/forumpost/07beac8056151b2f
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sqlite3.

CVE-2022-46908[0]:
| SQLite through 3.40.0, when relying on --safe for execution of an
| untrusted CLI script, does not properly implement the
| azProhibitedFunctions protection mechanism, and instead allows UDF
| functions such as WRITEFILE.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-46908
https://www.cve.org/CVERecord?id=CVE-2022-46908
[1] https://sqlite.org/forum/forumpost/07beac8056151b2f
[2] https://sqlite.org/src/info/cefc032473ac5ad2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1023688: incorrect syntax in patch

[Lee Maguire]

The modification to fcgiwrap.socket doesn’t appear to use values recognised by 
systemd.

I believe the configuration:

 Mode=0660
 SocketUser=www-data
 SockerGroup=www-data

Should actually be:

 SocketMode=0660
 SocketUser=www-data
 SocketGroup=www-data

Bug#1026292: python-jsonschema: Please provide a newer upstream release (>= 4.10.0)

[Samuel Henrique]

Package: python-jsonschema
Version: 4.9.1-3
Severity: wishlist

Hello maintainer,

It seems like upstream is moving quite quickly with the releasing of
new versions of jsonschema (4.17.3 at the time of this writing).

The new releases of ansible-lint (> 6.7.0) now depend on
python3-jsonschema >= 4.10.0, so I'm opening this bug to track the
request to update python-jsonschema.

The latest release of ansible-lint as of now is 6.10.0, and it
requires jsonschema >= 4.10.0,

For reference, previous bug report asking for an update:
https://bugs.debian.org/1017629

Thank you!

-- 
Samuel Henrique 



-- 
Samuel Henrique 

Bug#1026291: [deluge] please update

[Lyndon Brown]

Package: deluge
Version: 2.0.3-3.2

Please update. It's been a year since 2.0.4 and 2.0.5 were released,
and since then there's also been 2.1.0 and 2.1.1 a few months ago.

Bug#1026172: mono: FTBFS on mipsel

[Salvatore Bonaccorso]

Hi Jo,

On Thu, Dec 15, 2022 at 03:04:35PM -0500, Jo Shields wrote:
> What hardware is in the mipsel-osuosl-* machines? Mono has a history of
> triggering hardware bugs in imperfect MIPS implementations, e.g. Loongson 2

They are listed in

https://db.debian.org/machines.cgi?host=mipsel-osuosl-01
https://db.debian.org/machines.cgi?host=mipsel-osuosl-02
https://db.debian.org/machines.cgi?host=mipsel-osuosl-03
https://db.debian.org/machines.cgi?host=mipsel-osuosl-04
https://db.debian.org/machines.cgi?host=mipsel-osuosl-05

So where it failed it was a Quad Core Loongson 3A3000. It suceeded on
mipsel-osuosl-01 which is different. 

Maybe we can treat that not as RC, but I wanted to be on safe side.

Regards,
Salvatore

Bug#1026290: RM: blender [armel armhf i386 mipsel] -- ROM; FTBFS on all 32-bit release architectures

[Matteo F. Vescovi]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: blen...@packages.debian.org
Control: affects -1 + src:blender

Hi team!

Back in 2019 Blender Foundation has removed support on 32-bit
architectures [1] and since then support for those has been added via
various hacks by upstream developers.

It's now time to drop these architectures and eventually limit building
for 64 bit only.

Cheers.

mfv


[1] https://lists.blender.org/pipermail/bf-committers/2019-August/050124.html

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


signature.asc
Description: PGP signature

Bug#848995: atftp: should work with newer versions (backports)

[Andreas B. Mundt]

Package: atftp
Followup-For: Bug #848995
X-Debbugs-Cc: Benoit Panizzon , a...@debian.org

Hi Benoit,

thanks for your report.  Could you please test the latest version from
backports?  The version in bullseye is not up-to-date,
bullseye-backports and the next stable release will ship an up-to-date
atftp package.

There have been many improvements and the roll over is 
implemented in recent versions/packages.

It works fine in the test-suite.

Best regards,

  Andi

Bug#1026289: surf: The app opens, only displays a blank page

[Steve]

Package: surf
Version: 2.1+git20221016-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: marathon.duran...@gmail.com 

Dear Maintainer,

On startup no content is displayed, simply a white blank window. The
window doesn't accept any mouse input. Error message when launching from
the console:

** (surf:6798): WARNING **: 14:38:03.031: Could not open 
/sys/class/dmi/id/chassis_type: Failed to open file 
“/sys/class/dmi/id/chassis_type”: Permission denied

** (surf:6798): WARNING **: 14:38:03.031: Could not open 
/sys/firmware/acpi/pm_profile: Failed to open file 
“/sys/firmware/acpi/pm_profile”: Permission denied

I'm running it as the regular logged in user. Thanks for looking at
this.

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

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

Versions of packages surf depends on:
ii  libc6   2.36-6
ii  libgcr-base-3-1 3.41.1-1+b1
ii  libgcr-ui-3-1   3.41.1-1+b1
ii  libglib2.0-02.74.2-1
ii  libgtk-3-0  3.24.35-3
ii  libjavascriptcoregtk-4.1-0  2.38.2-1+b1
ii  libwebkit2gtk-4.1-0 2.38.2-1+b1
ii  libx11-62:1.8.1-2

Versions of packages surf recommends:
ii  curl7.86.0-2
ii  lxterminal [x-terminal-emulator]0.4.0-2
ii  rxvt-unicode [x-terminal-emulator]  9.30-2+b3
ii  suckless-tools  46-2
ii  x11-utils   7.7+5

Versions of packages surf suggests:
ii  apparmor  3.0.8-1

-- no debconf information

Bug#1026288: python3-m2r: does not import with docutils 0.19

[Dmitry Shachnev]

Package: python3-m2r
Version: 0.2.1-7.1
Severity: important
Tags: fixed-upstream

Dear Maintainer,

The m2r module does not import when python3-docutils 0.19 is installed.
That version is currently available in experimental.

>>> import m2r
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/m2r.py", line 13, in 
from docutils.core import ErrorString
ImportError: cannot import name 'ErrorString' from 'docutils.core' 
(/usr/lib/python3/dist-packages/docutils/core.py)

It also FTBFS with this version.

This bug was fixed in the following upstream commit, which is part of 0.3.0
and 0.3.1 releases:

https://github.com/miyakogi/m2r/commit/62143f2c0c12d783

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1005272: libxt6: out-of-date copyright file -

[Mechtilde Stehmann]

Package: libxt6
Followup-For: Bug #1005272
X-Debbugs-Cc: mechti...@debian.org

I tried to fix this RC bug. but I can't do it in my build environment.
It isn't buildable with gbp buildpackage. I miss pristine-tar and upstream
branch.

Regards

Mechtilde


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 libxt6 depends on:
ii  libc6 2.36-6
ii  libice6   2:1.0.10-1
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.8.1-2

libxt6 recommends no packages.

libxt6 suggests no packages.

-- no debconf information

Bug#1026287: check-dfsg-status: use systemd .timer unit instead of /etc/cron.monthly

[Holger Levsen]

Package: check-dfsg-status
Version: 1.32
Severity: normal

hi,

W: check-dfsg-status: missing-systemd-timer-for-cron-script 
[etc/cron.monthly/check-dfsg-status]
N: 
N:   This package ships the specified cron script but does not ship a 
equivalent systemd .timer unit.
N:   
N:   The "desktop" and "laptop" tasks no longer pull in anacron(8), the usual 
solution for desktop installations that are not running all the time.
N:   
N:   Please consider shipping an equivalent .timer file for this script.
N: 
N:   Please refer to the systemd.timer(5) manual page, the anacron(8) manual 
page, and Bug#1007257 for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: systemd

let to the following conversation on #debian-devel:

 is there some tool to use systemd.timer files with cron (for systems 
without systemd)
 i'm asking because https://paste.debian.net/1264393/
<  zeha> | h01ger: your idea being 'lets ship a .timer unit instead of the 
current cron job, and wrap that for non-systemd systems'?
 | h01ger: I think there is only "run the ExecStart= commands via 
cron, guarded by a `if` condition"
 would still be useful if that was in a package
 or ship both and ignore the cron file when running systemd
 or stop supporting sysv
 -d /run/systemd && exit 0 seems to be the common solution i've seen so 
far
 i'm mostly genuinly wondering what "we want" or do.
 that seems like a loaded question :-(
 not having all that compat glue seems like it would be a lot nicer/easier
 maybe the lintian msg needs adjusting too
 having a separate .timer unit instead of being about to throw stuff into 
a cron.monthly directly seems like a regression
 perhaps a monthly.timer would make sense?
 it could still be separate .service entries for each thingy
 Myon: how would that work? and what would it solve?
 i don't see the difference of writing one or two files files
 you could use monthly@bla.service, just to avoid providing that one 
file but have the automation that enables the timer unit now fail
 might be nicer to see all 'monthly' jobs in one go
 moi  U
 so you want to have cron.monthly, which ties everything into one blob, 
looses error reporting and all?
 does not look useful
 the .service units still have their own error reporting?
 hmm, monthly.timer -> monthly.target and bla.service 
WantedBy=monthly.target
 might work
 or not.
 something like that, yeah
 sounds fragile. as one failure to stop will make sure nothing will run 
ever again
 based on the discussion, i think i'd go with just the timer file. and 
if^wwhen someone complains they/we can figure something out.
 though maybe for trixie. still got a bit time to decide that.
 zeha: ansgar: Myon: waldi: may i put this conversation in a bug 
report? (if wanted i could also replace $nick with $anon-alias123 but i'd 
rather not do that. however if you prefer..)
 sure
< waldi> | h01ger: i'm also going to ask them to work on a generic unit to 
init.d converter. we are so good into individualizing costs
 | h01ger: Dine with me.
<  zeha> | h01ger: go ahead
<  Myon> | h01ger: go ahead
 zeha: ansgar: Myon: waldi: thank you! :)


tl;dr:

 based on the discussion, i think i'd go with just the timer file. and 
if^wwhen someone complains they/we can figure something out.
 though maybe for trixie. still got a bit time to decide that.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Make earth cool again.


signature.asc
Description: PGP signature

Bug#1026286: Unsatisfiable versioned dependency on python3-numpy

[Enrico Zini]

Package: python3-numba
Version: 0.56.2+dfsg-2
Severity: serious

Hello,

thank you for maintaining python3-numba!

Unfortunately the package is currently uninstallable in sid.

It depends on `python3-numpy (<< 1:1.22), python3-numpy (>= 1:1.20.0)`,
but the version of python3-numpy in sid is 1:1.23.5-2.


Thanks,

Enrico

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

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

Bug#758542: dash: defining an alias with a backslash should return an error

[наб]

Control: tags -1 + upstream patch
Control: forwarded 
https://lore.kernel.org/dash/20221217190705.atfwacsgggtaf...@tarta.nabijaczleweli.xyz/t/

Indeed; escaping of any kind (quoting or backslash) disables alias
expansion. What's even more fun is that if you do
  alias "a'b=c" "ls=cd"
then alias will give you
  ls='cd'
  a'b='c'
which is even better since it'll run code when evaled back.

I posted a patch to dash@ (archived at forwarded-to) that fixes this
by refusing characters that must be quoted in the name bit of the alias,
so the invocation above will fail with
  alias: a'b: invalid name
  alias: ls: invalid name
and commit no aliases.

наб


signature.asc
Description: PGP signature

Bug#1026199: release.debian.org: Is the toolchain list updated for bookworm

[Holger Levsen]

Hi Paul,

On Sat, Dec 17, 2022 at 04:42:43PM +0100, Paul Gevers wrote:
> Well, the key package set is something else than the set we consider for the
> first freeze. 

doh (obviously), sorry for the noise.

> The key package set is a set based on source, so indeed it
> doesn't differ per suite.

right.

> > So now I wonder: how to get this from UDD?
> I think you had the right query.

thanks for confirming! :) and the whole reply despite my error.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

June 2021 was the hottest on record for the Northern Hemisphere. In fact, 2019,
2020 and 2021 are the three hottest Junes on record for the Northern Hemisphere.
(@ScottDuncanWX)


signature.asc
Description: PGP signature

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

0.72.7 draft 1 needs embedding 73 crates (63 missing, 1 broken, 3 outdated, 6 
ahead); builds in ~43 minutes; runs but functionality not yet properly tested

Main tasks now are to keep package up-to-date with upstream releases, and
to package more of the crates currently embedded.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary packages I built - then I will share those.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/TODO


 - 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#985189: ITP: et -- Eternal Terminal (ET) is a remote shell that automatically reconnects without interrupting the session.

[Dean Hamstead]

Hopefully this effort hasnt stalled


On Sun, 14 Mar 2021 09:17:06 -0500 Jason Gauci  wrote:

> I'm fine with changing the name.
>
> On Sun, Mar 14, 2021, 8:44 AM Gard Spreemann  wrote:
>
> >
> > Jason Gauci  writes:
> >
> > > Package name : et
> > > Version : 6.1.4
> > > Upstream Author : Jason Gauci 
> > > URL : https://eternalterminal.dev/
> > > License : Apache
> > > Programming Lang: C++
> > > Description : Eternal Terminal (ET) is a remote shell that
> > automatically reconnects without interrupting the session.
> > >
> > > Eternal Terminal (ET) is a remote shell that automatically reconnects
> > without interrupting the session.
> >
> > Hi,
> >
> > Might it be sensible to consider the full name "eternalterminal" (or
> > "eternal-terminal") for this package? This would take pressure off the
> > two-letter package name space, without giving up much (any?)
> > discoverability.
> >
> > -- Gard
> >
> >
> >

Bug#1026239: transition: proftpd-dfsg

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-12-16 23:45:52 +0100, Hilmar Preusse wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: proftpd-d...@packages.debian.org
> Control: affects -1 + src:proftpd-dfsg
> 
> This transition was already started by the recent proftpd upload, but is
> not caught caught automatically since it is a virtual package name that
> has changed.

Rebuilds scheduled.

Cheers

> 
> Ben file:
> 
> title = "proftpd-dfsg";
> is_affected = .depends ~ "proftpd-abi-1.3.7d" | .depends ~ 
> "proftpd-abi-1.3.8";
> is_good = .depends ~ "proftpd-abi-1.3.8";
> is_bad = .depends ~ "proftpd-abi-1.3.7d";
> 
> Hilmar
> 
> -- 
> sigmentation fault



-- 
Sebastian Ramacher

Bug#1026285: src:ruby-nokogiri: fails to migrate to testing for too long: FTBFS on some arch

[Paul Gevers]

Source: ruby-nokogiri
Version: 1.13.7+dfsg-2
Severity: serious
Control: close -1 1.13.8+dfsg-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ruby-nokogiri has been trying to migrate 
for 62 days [2]. Hence, I am filing this bug. Your package was reported 
to FTBFS on s390x (still building), but the upload of today FTBFS on 
ppc64el already.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026283: plasma-workspace-data: Binding loop detected

[Helge Kreutzmann]

Package: plasma-workspace-data
Version: 4:5.26.4.1-1
Severity: minor

When runnig plasma, I get the following messages in my logs:
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:496:13:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:497:13:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:499:13:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:531:9:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:532:9:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:534:9:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:553:5:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:554:5:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml:556:5:
 QML Label: Binding loop detected for property "height"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/Tooltip.qml:55:9:
 QML GridLayout (parent or ancestor of QQuickLayoutAttached): Binding loop 
detected for property "minimumWidth"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/Tooltip.qml:68:9:
 QML GridLayout (parent or ancestor of QQuickLayoutAttached): Binding loop 
detected for property "minimumWidth"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:220:21:
 QML SelectableLabel: Binding loop detected for property "implicitHeight"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:220:21:
 QML SelectableLabel: Binding loop detected for property "implicitWidth"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21:
 QML SelectableLabel: Binding loop detected for property "implicitHeight"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21:
 QML SelectableLabel: Binding loop detected for property "implicitWidth"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/SelectableLabel.qml:38:5:
 QML TextArea: Binding loop detected for property "implicitHeight"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/ExpandedRepresentation.qml:167:9:
 QML HiddenItemsView: Binding loop detected for property "implicitHeight"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/HiddenItemsView.qml:33:5:
 QML GridView: Binding loop detected for property "cellWidth"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml:17:1:
 QML MouseArea (parent or ancestor of QQuickLayoutAttached): Binding loop 
detected for property "minimumWidth"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.private.systemtray/contents/ui/main.qml:18:1:
 QML MouseArea (parent or ancestor of QQuickLayoutAttached): Binding loop 
detected for property "minimumWidth"

f these messages are harmless and cannot be fixed, please add a
logcheck rule for them.

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1026284: plasma-desktop-data: Binding loop detected

[Helge Kreutzmann]

Package: plasma-desktop-data
Version: 4:5.26.4-1
Severity: minor

When runnig plasma, I get the following messages in my logs:

plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.panel/contents/ui/ConfigOverlay.qml:304:17:
 QML Heading: Binding loop detected for property "verticalAlignment"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.panel/contents/ui/ConfigOverlay.qml:312:17:
 QML SpinBox: Binding loop detected for property "implicitWidth"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.panel/contents/ui/main.qml:19:1: QML 
DropArea (parent or ancestor of QQuickLayoutAttached): Binding loop detected 
for property "preferredHeight"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/main.qml:100:5:
 QML TasksModel: Binding loop detected for property 
"groupingWindowTasksThreshold"
plasmashell.*: 
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/ToolTipDelegate.qml:86:9:
 QML ScrollView: Binding loop detected for property "bottomPadding"
plasmashell.*: 
file:///usr/share/plasma/shells/org.kde.plasma.desktop/contents/configuration/ConfigurationAppletPage.qml:38:5:
 QML Loader: Binding loop detected for property "height"

If these messages are harmless and cannot be fixed, please add a
logcheck rule for them.
 
-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plasma-desktop-data depends on:
ii  python3  3.10.6-1

Versions of packages plasma-desktop-data recommends:
ii  plasma-framework  5.100.1-1
ii  plasma-workspace  4:5.26.4.1-1
ii  qml-module-org-kde-activities 5.100.0-1
ii  qml-module-org-kde-kwindowsystem  5.100.0-1
ii  qml-module-org-kde-newstuff   5.100.0-1
ii  qml-module-qt-labs-platform   5.15.6+dfsg-2
ii  qml-module-qtquick-dialogs5.15.6-2

plasma-desktop-data suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1026282: plasma-framework: Binding loop detected

[Helge Kreutzmann]

Package: plasma-framework
Version: 5.100.1-1
Severity: minor

When runnig plasma, I get the following messages in my logs:
plasmashell.*: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/private/IconLabel.qml:56:5:
 QML GridLayout: Binding loop detected for property "width"
plasmashell.*: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/components.3/ScrollView.qml:45:27:
 QML ScrollBar: Binding loop detected for property "visible"
plasmashell.*: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/extras/ExpandableListItem.qml:478:21:
 QML Label: Binding loop detected for property "verticalAlignment"
plasmashell.*: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/extras/ExpandableListItem.qml:490:21:
 QML Label: Binding loop detected for property "verticalAlignment"
plasmashell.*: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/plasma/extras/PlaceholderMessage.qml:238:5:
 QML Heading: Binding loop detected for property "verticalAlignment"

If these messages are harmless and cannot be fixed, please add a 
logcheck rule for them.

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plasma-framework depends on:
ii  kio  5.100.0-2
ii  kpackagetool55.100.0-1
ii  libc62.36-6
ii  libegl1  1.5.0-1
ii  libgcc-s112.2.0-10
ii  libglx0  1.5.0-1
ii  libkf5activities55.100.0-1
ii  libkf5calendarevents55.100.0-1
ii  libkf5configcore55.100.1-1
ii  libkf5configgui5 5.100.1-1
ii  libkf5coreaddons55.100.0-1
ii  libkf5declarative5   5.100.0-1
ii  libkf5i18n5  5.100.0-1
ii  libkf5iconthemes55.100.0-1
ii  libkf5kiocore5   5.100.0-2
ii  libkf5kiowidgets55.100.0-2
ii  libkf5kirigami2-55.100.0-1
ii  libkf5notifications5 5.100.0-1
ii  libkf5package5   5.100.0-1
ii  libkf5plasma55.100.1-1
ii  libkf5plasmaquick5   5.100.1-1
ii  libkf5quickaddons5   5.100.0-1
ii  libkf5widgetsaddons5 5.100.0-2
ii  libkf5windowsystem5  5.100.0-1
ii  libkf5xmlgui55.100.0-1
ii  libopengl0   1.5.0-1
ii  libqt5core5a 5.15.6+dfsg-5
ii  libqt5gui5   5.15.6+dfsg-5
ii  libqt5qml5   5.15.6+dfsg-2
ii  libqt5quick5 5.15.6+dfsg-2
ii  libqt5widgets5   5.15.6+dfsg-5
ii  libqt5x11extras5 5.15.6-2
ii  libstdc++6   12.2.0-10
ii  libx11-6 2:1.8.1-2
ii  libxcb-composite01.15-1
ii  libxcb-damage0   1.15-1
ii  libxcb-render0   1.15-1
ii  libxcb1  1.15-1
ii  qml-module-org-kde-kconfig   5.100.0-1
ii  qml-module-org-kde-kquickcontrols5.100.0-1
ii  qml-module-org-kde-kquickcontrolsaddons  5.100.0-1
ii  qml-module-qtqml-models2 5.15.6+dfsg-2
ii  qml-module-qtquick-controls  5.15.6-2
ii  qml-module-qtquick-controls2 5.15.6+dfsg-2
ii  qml-module-qtquick-templates25.15.6+dfsg-2

plasma-framework recommends no packages.

plasma-framework suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1026281: qml-module-org-kde-kirigami2: Binding loop detected

[Helge Kreutzmann]

Package: qml-module-org-kde-kirigami2
Version: 5.100.0-1
Severity: minor

When runnig plasma, I get the following message in my logs:
plasmashell.*: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
 QML MouseArea: Binding loop detected for property "width"

If this message is harmless and cannot be fixed, please add a logcheck
rule for it.

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qml-module-org-kde-kirigami2 depends on:
ii  libc6 2.36-6
ii  libkf5kirigami2-5 5.100.0-1
ii  libqt5core5a [qtbase-abi-5-15-6]  5.15.6+dfsg-5
ii  libqt5gui55.15.6+dfsg-5
ii  libqt5network55.15.6+dfsg-5
ii  libqt5qml55.15.6+dfsg-2
ii  libqt5quick5  5.15.6+dfsg-2
ii  libqt5quickcontrols2-55.15.6+dfsg-2
ii  libstdc++612.2.0-10
ii  qml-module-qtgraphicaleffects 5.15.6-2
ii  qml-module-qtqml-models2  5.15.6+dfsg-2
ii  qml-module-qtquick-controls2  5.15.6+dfsg-2
ii  qml-module-qtquick-layouts5.15.6+dfsg-2
ii  qml-module-qtquick-templates2 5.15.6+dfsg-2
ii  qml-module-qtquick2   5.15.6+dfsg-2

qml-module-org-kde-kirigami2 recommends no packages.

qml-module-org-kde-kirigami2 suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1026280: wayfire: Please package related software

[Vladimir K]

Package: wayfire
Version: 0.7.5-1~exp1
Severity: wishlist

Dear Maintainer, please consider packaging plugins and software related to 
wayfire:
https://github.com/WayfireWM/wayfire-plugins-extra
https://github.com/WayfireWM/wcm
https://github.com/timgott/wayfire-shadows
https://github.com/ammen99/wayfire-plugins

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages wayfire depends on:
ii  libc62.36-6
ii  libcairo21.16.0-7
ii  libegl1  1.5.0-1
ii  libgcc-s112.2.0-10
ii  libgles2 1.5.0-1
ii  libglib2.0-0 2.74.2-1
ii  libinput10   1.22.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpixman-1-00.42.2-1
ii  libpng16-16  1.6.39-2
ii  libstdc++6   12.2.0-10
ii  libwayland-server0   1.21.0-1
ii  libwf-config10.7.1-3
ii  libwf-utils0 0.7.5-1~exp1
ii  libwlroots11 0.16.0-2
ii  libxcb1  1.15-1
ii  libxkbcommon01.4.1-1

wayfire recommends no packages.

wayfire suggests no packages.

-- no debconf information

Bug#1026279: src:mutter: fails to migrate to testing for too long: autopkgtest regression and FTBFS on armhf

[Paul Gevers]

Source: mutter
Version: 43.0-2
Severity: serious
Control: close -1 43.2-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1024438

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:mutter has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source on armhf (testsuite issue), where it built successfully in the 
past. The autopkgtest also regressed, which I reported in bug 1024438.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026278: fonts-cardo: replacement tokens block actual characters

[Adam Borowski]

Package: fonts-cardo
Version: 1.04-3
Severity: normal

A bunch of ranges that are only partially supported by Cardo have the rest
of the block filled with replacement tokens.  These tokens block a proper
glyphs being borrowed from another font.  As Cardo has a high priority
(for a good reason -- it's usually good), this effectively breaks the
affected blocks if Cardo is installed.

These blocks are:
* Runic (U+16A0..U+16F0)
* single glyph U+2112 (script capital L)
* circle arrows U+27F2, U+27F3, U+2938..U+293F
* Gothic U+10330..U+1034A
* math fraktur U+1D504..U+1D52D



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-rc8-00038-gd0ebd6ceed50 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game

[James Addison]

Package: wnpp
Severity: wishlist
Owner: James Addison 
X-Debbugs-Cc: debian-de...@lists.debian.org, j...@jp-hosting.net

* Package name: quadrilateralcowboy
  Version : 1.0.0
  Upstream Contact: Brendon Chung 
* URL : https://www.blendogames.com/qc/
* License : GPLv3
  Programming Lang: C++
  Description : first-person cyberpunk adventure game

Quadrilateral Cowboy is self-described as "a first-person hacking adventure in
a cyberpunk world".

The game features elements of programming, automation and puzzle-solving in a
variety of 3D environments.

Data files for the game are not included in this package and can be purchased
from the game's website at https://www.blendogames.com/qc/

Bug#1026276: skrooge: Local settings not applied on numbers

[Thierry Jeanmougin]

Package: skrooge
Version: 2.28.0-1+b1
Severity: minor
Tags: l10n

Dear Maintainer,

Local settings not applied on numbers
Expected: 12 345,67 €
Displayed: 12345.67€

Locale:
LANG=fr_FR.UTF-8
LANGUAGE=fr
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"

Thanks


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages skrooge depends on:
ii  kinit 5.100.0-1
ii  kio   5.100.0-2
ii  libc6 2.36-6
ii  libgcc-s1 12.2.0-10
ii  libgrantlee-templates55.2.0-4
ii  libkf5archive55.100.0-2
ii  libkf5completion5 5.100.0-1
ii  libkf5configcore5 5.100.1-1
ii  libkf5configgui5  5.100.1-1
ii  libkf5configwidgets5  5.100.0-1
ii  libkf5coreaddons5 5.100.0-1
ii  libkf5dbusaddons5 5.100.0-1
ii  libkf5i18n5   5.100.0-1
ii  libkf5iconthemes5 5.100.0-1
ii  libkf5kiocore55.100.0-2
ii  libkf5kiofilewidgets5 5.100.0-2
ii  libkf5newstuff5   5.100.0-1
ii  libkf5notifications5  5.100.0-1
ii  libkf5notifyconfig5   5.100.0-1
ii  libkf5parts5  5.100.0-1
ii  libkf5runner5 5.100.0-1
ii  libkf5service-bin 5.100.0-1
ii  libkf5service55.100.0-1
ii  libkf5textwidgets55.100.0-1
ii  libkf5wallet-bin  5.100.0-1
ii  libkf5wallet5 5.100.0-1
ii  libkf5widgetsaddons5  5.100.0-2
ii  libkf5xmlgui5 5.100.0-1
ii  libofx7   1:0.10.9-1
ii  libqca-qt5-2  2.3.5-1
ii  libqca-qt5-2-plugins  2.3.5-1
ii  libqt5concurrent5 5.15.6+dfsg-5
ii  libqt5core5a [qtbase-abi-5-15-6]  5.15.6+dfsg-5
ii  libqt5dbus5   5.15.6+dfsg-5
ii  libqt5gui55.15.6+dfsg-5
ii  libqt5network55.15.6+dfsg-5
ii  libqt5printsupport5   5.15.6+dfsg-5
ii  libqt5qml55.15.6+dfsg-2
ii  libqt5quick5  5.15.6+dfsg-2
ii  libqt5quickwidgets5   5.15.6+dfsg-2
ii  libqt5script5 5.15.6+dfsg-2
ii  libqt5sql55.15.6+dfsg-5
ii  libqt5sql5-sqlite 5.15.6+dfsg-5
ii  libqt5svg55.15.6-2
ii  libqt5webkit5 5.212.0~alpha4-26+b1
ii  libqt5widgets55.15.6+dfsg-5
ii  libqt5xml55.15.6+dfsg-5
ii  libsqlcipher0 3.4.1-2+b1
ii  libstdc++612.2.0-10
ii  skrooge-common2.28.0-1

Versions of packages skrooge recommends:
ii  poppler-utils  22.08.0-2.1

Versions of packages skrooge suggests:
pn  aqbanking-tools  

-- no debconf information

Bug#1026275: ITP: mender-connect -- remote shell access add-on

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: mender-connect
  Version : 2.1.0-1
  Upstream Author : Nothern.Tech
* URL : https://github.com/mendersoftware/mender-connect
* License : Apache-2.0
  Programming Lang: Go
  Description : remote shell access add-on

 Mender: remote shell access add-on
 .
 Mender is an open source over-the-air (OTA) software updater for embedded
 Linux devices. Mender comprises a client running at the embedded device,
 as well as a server that manages deployments across many devices.
 See: https://tracker.debian.org/mender-client
 .
 This repository contains the remote shell access add-on. It enhances the
 Mender client (https://github.com/mendersoftware/mender), allowing to
 log in to the devices remotely and start a shell in a remote terminal
 session.

Bug#1026274: ITP: golang-github-vmihailenco-msgpack.v5 -- MessagePack (msgpack.org) encoding for Golang

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: golang-github-vmihailenco-msgpack.v5
  Version : 5.3.5-1
  Upstream Author : Vladimir Mihailenco
* URL : https://github.com/vmihailenco/msgpack
* License : BSD-2-clause
  Programming Lang: Go
  Description : MessagePack (msgpack.org) encoding for Golang

 MessagePack encoding for Golang
 .
 Features
 .
  * Primitives, arrays, maps, structs, time.Time and interface{}.
  * Appengine \*datastore.Key and datastore.Cursor.
  * CustomEncoder/CustomDecoder interfaces for custom encoding.
  * Extensions to encode type information.
  * Renaming fields via msgpack:"my_field_name" and alias via
msgpack:"alias:another_name".
  * Omitting individual empty fields via msgpack:",omitempty" tag or all
empty fields in a struct.
  * Map keys sorting.
  * Encoding/decoding all structs as arrays or individual structs.
  * Encoder.SetCustomStructTag with Decoder.SetCustomStructTag
can turn msgpack into drop-in replacement for any tag.
  * Simple but very fast and efficient queries.

 This is a dependency for upcoming mender-connect packaging.

 Note that .v2 of this package is already available, but this is .v5.

Bug#1026273: ITP: golang-github-vmihailenco-tagparser.v2 -- Opinionated Golang tag parser

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: golang-github-vmihailenco-tagparser.v2
  Version : 2.0.0-1
  Upstream Author : Vladimir Mihailenco
* URL : https://github.com/vmihailenco/tagparser
* License : BSD-2-clause
  Programming Lang: Go
  Description : Opinionated Golang tag parser

 Opinionated Golang tag parser

 This is a dependency for the upcoming mender-connect packaging.
 (Actually a dep of golang-github-vmihailenco-msgpack.v5 and not
 mender-connect directly.)

 Note that an non-API-versioned version of this is already available
 in the archive, but this is .v2.

Bug#1026272: ITP: golang-github-go-ozzo-ozzo-validation.v4 -- idiomatic Go (golang) validation package.

[Andreas Henriksson]

Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson 

* Package name: golang-github-go-ozzo-ozzo-validation.v4
  Version : 4.3.0-1
  Upstream Author : Ozzo Framework
* URL : https://github.com/go-ozzo/ozzo-validation
* License : Expat
  Programming Lang: Go
  Description : idiomatic Go (golang) validation package.

 ozzo-validation is a Go package that provides configurable and extensible
 data validation capabilities. It has the following features:
 .
  * use normal programming constructs rather than error-prone struct tags
to specify how data should be validated.
  * can validate data of different types, e.g., structs, strings, byte
slices, slices, maps, arrays.
  * can validate custom data types as long as they implement the
Validatable interface.
  * can validate data types that implement the sql.Valuer interface (e.g.
sql.NullString).
  * customizable and well-formatted validation errors.
  * error code and message translation support.
  * provide a rich set of validation rules right out of box.
  * extremely easy to create and use custom validation rules.

 This package is a dependency for the upcoming mender-connect packaging.

Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)

[Guillem Jover]

On Sat, 2022-12-17 at 08:35:02 -0800, Russ Allbery wrote:
> (That said, and this is only personal preference and I don't feel that
> strongly about it, I usually err on the side of creating lots of bugs so
> that there can be roughly one bug per patch.  It can make it a bit harder
> to track things if there's one bug following a bunch of semi-related but
> separable changes.  Unfortunately, the BTS doesn't support the concept of
> a hierarchy with a tracking issue and a bunch of underlying implementaton
> issue very well.)

(Right, personally I don't think I'd split one bug per patch, as long
as the patch is covering the same thing, perhaps. In this case I
pondered about opening a new one, but given the initial discussion
and context was here it seemed best to keep it together. Should have
perhaps split the stanza stuff into another report, though. :)

(In any case, hope this is all not too inconvenient!)

> Guillem Jover  writes:
> > And for some reason I think I also got the impression, even though
> > the stanza changes had been committed, they could still be backed out.
> > (BTW I've now gone over the wiki and updated all paragraph references
> > that applied to stanza.)
> 
> I'm personally happy to stick with stanza.

Sorry, rereading that paragraph it seems not clear on what I was
trying to convey. :) I meant that because I thought this could be backed
out until an upload, I guess subconsciously postponed further changes
for this (both in dpkg and here) based on that. Should have asked.

> > I also recalled another term that has always seemed very confusing in
> > context: «control information files» or «control information area». For
> > example in a sentence such as “the control file is a control information
> > file in the control information area in a .deb archive”. :) This also
> > seems confusing when some of the files in the .deb control member are
> > not really “control files” with a deb822(5) format.
> 
> > My thinking has been going into calling these as the «metadata files»,
> > and being located in either the  «metadata part of the .deb archive» or
> > explicitly the «control member of the .deb archive», in contrast to the
> > filesystem part. In dpkg I'd be eventually switching to meta/metadata
> > and fsys/filesystem, from control or info and data. I've added a patch
> > with the proposed change, but again nothing set in stone, and I'm again
> > open to discussing pros/cons of this.
> 
> I like metadata file, but I think I prefer talking about the "control
> member" than the "metadata part" because it more closely matches what one
> sees if one takes the *.deb file apart.  But I haven't looked at your
> diffs yet.

Probably more clear currently, yeah. To expand on the above, my thinking
has been for example that if we ever have a deb 3.0 format, I'd probably
like to name the members, something like: «meta.tar.*» and «fsys.tar.*»,
and that's also what I've kind of been moving the dpkg internals to
(functions, structs and similar). Also as part of the file metadata work,
I've also have pending splitting the dpkg db info/ dir into a dir that
contains things shipped by the .deb, and a dir for stuff generated by
dpkg itself, so that they cannot conflict or get overwritten or need
to be taken into account doing any of that.

Thanks,
Guillem

Bug#1026271: ITP: libfeature-compat-class-perl -- make class syntax available

[Jonas Smedegaard]

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


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libfeature-compat-class-perl
  Version : 0.04
  Upstream Contact: Paul Evans 
* URL : https://metacpan.org/release/Feature-Compat-Class
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : make class syntax available

 Feature::Compat::Class provides the new class keyword and related others
 (method, field and ADJUST)
 in a forward-compatible way.
 .
 There is a branch of Perl development source code
 which provides this syntax, under the class named feature.
 If all goes well, this will become available
 in a stable release in due course.
 On such perls that contain the feature,
 this module simple enables it.
 .
 On older versions of perl before such syntax is availble in core,
 it is currently provided instead using the Object::Pad module,
 imported with a special set of options
 to configure it to only recognise the same syntax
 as the core perl feature,
 thus ensuring any code using it will still continue to function

This package is needed for future release of licensecheck,
to gracefully migrate from Object::Pad to pure-perl class object.
It will be maintained in the perl section of Salsa, at


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOd9nkACgkQLHwxRsGg
ASHcqw//ZbGpsKhwfHj/R3eX/wmTX7JJIrQAXzRYyj/6YY4/oGbdVTzOQEeR+Xy7
q9vZBeOjzndheZ8r3aQak/9F4Pnd5eWooQUkCr4LBiT7nQJ17s4Fia45Q5ui203X
2QrEzLV9jvgINmao6NXo1LISmHxpA1fXHInWH8y9trGuiIPO0qwTkThPBWJG5kt1
gxlxer/jq09Z9NqdpSmAS4Z78AdzxD7vP41vbR20mjSCLZYjCcOmadrFMjajaOcm
Sls/5YZjh1Sat3A3a7tGxeWtX4KHnpDQv04PCx8FGOYZ7fmsB/iMTlf4eRunZX6L
AtcsQFfWW4ZulFfYXCOlyp3D/vnxNEC2Wim4L0gG8tYfpEUR+V+zrUjfOLWWQOri
fcBRbG2j7PwiigAOftxdD3MblzAW4QDOJwk9PhfS3yd569mNSgWHah5v9J1ibfIs
ab+5kg6jX81Wpy6P/9yGuorBtddvyX4oAVqyVpF5esFBLaLcIMInVAtSUEGu7vvw
29Q/Bemdg/kf9pcJXzPOiqqBVghBfJXolSYiO7g/Ep53Fy+D2N3cxt3OwzKzDTCA
nBIpRfjU5udbmvXtbEZ1kVB4lCNfvhbW/9yCq+zsu/r4r21EikaIRCAoIsdR6rc+
xWLIIxBRmBlj0lrdtnr7vctCYsiTWhskowdgZH2I7jKEgdZkE2w=
=VvvF
-END PGP SIGNATURE-

Bug#1025863: transition: qtbase-opensource-src

[Dmitry Shachnev]

On Sat, Dec 17, 2022 at 02:57:48PM +0100, Sebastian Ramacher wrote:
> It would make sense to get it into bookworm. So let's try.

Thanks. I will try to prepare it quickly after it's published.

> Please go ahead

Uploaded everything.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1026256: backuppc: BackupPC destroys its configuration when you "Save" in the admin web console

[Axel Beckert]

Control: clone -1 -2
Control: severity -1 grave
Control: severity -2 wishlist
Control: reassign -2 perl
Control: retitle -2 perl: Please add a versioned Conflicts with backuppc

Hi Andreas,

Andreas Feldner wrote:
> after a recent update (probably to a Perl library),
> a bug in BackupPC leads to it destroying its configuration files
> when saved from the BackupPC admin console.

Urgs. That's data loss and hence validates an release-critical
severity. Hence bumping the severity to "grave".

Thanks for the heads up! (I never use the possibility to edit the
configuration via the web interface, so I probably wouldn't have
noticed myself.)

> This bug is reported upstream:
> https://github.com/backuppc/backuppc/issues/466

The upstream report mentions Data::Dumper, which is indeed a Perl
library and part of the perl Perl core, i.e. part of the libperl5.36
Debian package.

Since Data::Dumper hasn't been mentioned in
/usr/share/doc/doc/perl/changelog.Debian.gz (recently), this must have
crept in with the bump to the 5.36 upstream release in June.

The upstream bug report mentions Data::Dumper version 2.182 and
according to

  corelist -a Data::Dumper | egrep '2\.18[123]|v5\.3[456]\.'

there was indeed a version bump between Perl 5.34 (Data::Dumper 2.179)
and 5.36 (Data::Dumper 2.184) which included 2.182. So this confirms
that the Perl upstream bump in June is the cause for this issue.

> A fix seems to be available and extremely easy to apply (not
> verified myself), but is not yet part of an upstream release.

It indeed looks easy to apply. Will provide a backuppc package update
soon after this bugreport.

Niko and Dominic: Can you update the perl package similar to what you
did for "duck" recently? Maybe best only after I updated the backuppc
package. (I've cloned this bug report accordingly for that purpose.)

I suggest either a Conflicts with "backuppc (<= 4.4.0-6+b1)" or with
"backuppc (<< 4.4.0-7~)", whatever deems you more fitting.

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

Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)

[Russ Allbery]

Guillem Jover  writes:

> Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields
> for things that fix part of a bug, but are not intended yet to close it,
> for which I use «Closes:».

Ack, sorry, this was my fault.  I optimistically added a bug closer when I
started merging patches from this bug in the hope that we'd get them all
merged before the next release and then forgot about it.

(That said, and this is only personal preference and I don't feel that
strongly about it, I usually err on the side of creating lots of bugs so
that there can be roughly one bug per patch.  It can make it a bit harder
to track things if there's one bug following a bunch of semi-related but
separable changes.  Unfortunately, the BTS doesn't support the concept of
a hierarchy with a tracking issue and a bunch of underlying implementaton
issue very well.)

> And for some reason I think I also got the impression, even though
> the stanza changes had been committed, they could still be backed out.
> (BTW I've now gone over the wiki and updated all paragraph references
> that applied to stanza.)

I'm personally happy to stick with stanza.

> I also recalled another term that has always seemed very confusing in
> context: «control information files» or «control information area». For
> example in a sentence such as “the control file is a control information
> file in the control information area in a .deb archive”. :) This also
> seems confusing when some of the files in the .deb control member are
> not really “control files” with a deb822(5) format.

> My thinking has been going into calling these as the «metadata files»,
> and being located in either the  «metadata part of the .deb archive» or
> explicitly the «control member of the .deb archive», in contrast to the
> filesystem part. In dpkg I'd be eventually switching to meta/metadata
> and fsys/filesystem, from control or info and data. I've added a patch
> with the proposed change, but again nothing set in stone, and I'm again
> open to discussing pros/cons of this.

I like metadata file, but I think I prefer talking about the "control
member" than the "metadata part" because it more closely matches what one
sees if one takes the *.deb file apart.  But I haven't looked at your
diffs yet.

> Attached the proposals for discussion/review, and I might again have
> perhaps missed instances or similar.

Will take a look soon!

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

Bug#1026269: plasma-workspace-data: Cyclic dependency detected ... Globals.qml

[Helge Kreutzmann]

Package: plasma-workspace-data
Version: 4:5.26.4.1-1
Severity: minor

Whenever plasma starts up, I get the following two messages printed in
the logs:
plasmashell[]: Cyclic dependency detected between 
"file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml"
 and 
"file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationHeader.qml"
plasmashell[]: Cyclic dependency detected between 
"file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml"
 and 
"file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/ThumbnailStrip.qml"

If these messages are harmless but cannot be resolved, please supply a
logcheck filtering rule so they are no longer added to the logs at
each startup.

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1026268: python3.10: `$ python3 -m venv dir` outputs "Error: name 'cmd' is not defined" if python3-venv is not installed.

[Yu Sugawara]

Package: python3.10
Version: 3.10.9-1
Severity: normal
X-Debbugs-Cc: gusmachine+deb...@gmail.com

Dear Maintainer,

When I tried to create a python3 venv environment, I got an error message
"Error: name 'cmd' is not defined" and got partially-created venv environment.

Steps I did:
- Ran ` $ python3 -m venv venv ` to create a venv directory under the
  current directory, without installing python3-venv.

Expected:
- Have an error message "The virtual environment was not created successfully
  because ensurepip is not available."

Actual:
- Got an error message "Error: name 'cmd' is not defined" instead.

I found the following code snippet in /usr/lib/python3.10/venv/__init__.py
is suspicious. It uses a variable 'cmd' without defining it.

> def _setup_pip(self, context):
> """Installs or upgrades pip in a virtual environment"""
> try:
> self._call_new_python(context, '-m', 'ensurepip', '--upgrade',
>   '--default-pip', stderr=subprocess.STDOUT)
> except subprocess.CalledProcessError:
> stdlib = sysconfig.get_path('stdlib')
> if not os.path.exists(f'{stdlib}/ensurepip/__main__.py'):
> print("""\
> The virtual environment was not created successfully because ensurepip is not
> available.  On Debian/Ubuntu systems, you need to install the python3-venv
> package using the following command.
> 
> apt install python{}-venv
> 
> You may need to use sudo with that command.  After installing the python3-venv
> package, recreate your virtual environment.
> 
> Failing command: {}
> """.format(sysconfig.get_python_version(), cmd))
> sys.exit(1)

I installed python3-venv and now venv works for me.
But I'd be glad if I could get the correct error message.

Thanks,

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3.10 depends on:
ii  libpython3.10-stdlib  3.10.9-1
ii  media-types   8.0.0
ii  mime-support  3.66
ii  python3.10-minimal3.10.9-1

python3.10 recommends no packages.

Versions of packages python3.10 suggests:
ii  binutils 2.39.50.20221208-5
pn  python3.10-doc   
ii  python3.10-venv  3.10.9-1

-- no debconf information

Bug#1026267: RM: ruby-omniauth-crowd -- ROM; upstream inactive

[Mohammed Bilal]

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

Hello,

The upstream for ruby-omniauth-crowd is no longer active[1] and the only 
reverse-dep gitlab uses its own fork of the gem. So I think we can remove this 
gem from the archive.

[1] - https://github.com/robdimarco/omniauth_crowd
[2] - 
https://gitlab.com/gitlab-org/gitlab/-/tree/master/vendor/gems/omniauth_crowd

Thanks,
Mohd Bilal

Bug#1026266: RM: ruby-omniauth-salesforce -- ROM; upstream inactive

[Mohammed Bilal]

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


Hello,

The upstream for ruby-omniauth-salesforce is no longer active.Moreover the only 
reverse-dependency gitlab uses their own fork[2] of the gem. So I think we can 
remove this package from the archive

[1] - https://github.com/realdoug/omniauth-salesforce
[2] - 
https://gitlab.com/gitlab-org/gitlab/-/tree/master/vendor/gems/omniauth-salesforce

Thanks,
Mohd Bilal

Bug#1026265: profile-sync-daemon: Please package new upstream release (6.48+)

[Boyuan Yang]

Source: profile-sync-daemon
Severity: important
Version: 6.34-1.2
X-Debbugs-CC: j.naum...@fu-berlin.de

Dear Debian profile-sync-daemon package maintainer,

Several new upstream release (till 6.48) has released since your last upload
back in 2019. Please consider packaging the new release.

Besides, this package hasn't received any maintainer updates for nearly 3
years. If you have any difficulty in package maintenance, please feel free to
let me know.

Thanks,
Boyuan Yang


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

Bug#1021053: check-dfsg-status: doubled report

[Adam Borowski]

On Sat, Dec 17, 2022 at 03:35:58PM +, Holger Levsen wrote:
> On Sat, Oct 01, 2022 at 10:54:20AM +0200, Adam Borowski wrote:
> > When you renamed the package from vrms to check-dfsg-status, you forgot to
> > migrate the cron job.  As a result, its now sends it monthly reports twice.
> > 
> > /etc/cron.monthly/vrms
> > /etc/cron.monthly/check-dfsg-status
>  
> on don't see this here on a fresh install (of both packages from current sid),
> so am I correct to assume this happened on upgrade from non-transitional 
> package
> vrms?

Yeah.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026264: The "emerald-theme" wallpaper is not displayed in GNOME

[Jonny]

Package: desktop-base
Version: 12.0.1
Severity: minor

Hi,
the "homeworld-theme" wallpaper is specified in the "emerald-theme".

emerald-theme/wallpaper/gnome-background.xml:
   height="1024">/usr/share/desktop-base/homeworld-theme/wallpaper/contents/images/1280x1024.svg
   height="1200">/usr/share/desktop-base/homeworld-theme/wallpaper/contents/images/1600x1200.svg

 ...

s/homeworld-theme/emerald-theme/

Bug#1020248: marked as done (debian-policy: Clarifying nomenclature for control file names)

[Guillem Jover]

Control: reopen -1

Hi!

Sorry, probably my fault! As I tend to use «Fixes:» git pseudo-fields
for things that fix part of a bug, but are not intended yet to close it,
for which I use «Closes:».

And for some reason I think I also got the impression, even though
the stanza changes had been committed, they could still be backed out.
(BTW I've now gone over the wiki and updated all paragraph references
that applied to stanza.)

In any case, I've sat down and gone over the meat of the original
report. See below.

On Sat, 2022-12-17 at 03:09:10 +, Debian Bug Tracking System wrote:
> Date: Sun, 18 Sep 2022 22:28:00 +0200
> From: Guillem Jover 
> To: sub...@bugs.debian.org
> Subject: debian-policy: Clarifying nomenclature for control file names
> 
> Package: debian-policy
> Version: 4.6.1.1
> Severity: wishlist

> This is a followup from my comment at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#43
> 
> To summarize, we have IMO confusing naming and nomenclature for the
> various control files and paragraphs/stanzas, and this is even
> confusing me when having to deal with dpkg code, so I'd like to give
> these more clear and unambiguous new names, and I'd very strongly
> prefer to agree on the same naming for Debian policy and dpkg, to
> avoid further and worse confusion (even though they currently do not
> match exactly anyway, but I'd prefer to not make it worse…).
> 
> Just for reference and to give some context, I've got the following
> WIP branches, trying to clarify the names in documentation and in the
> API on, which I'll probably rework (split/merge) and reword as needed,
> so do not take them as anything set in stone:
> 
>   
> https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/clarify-control-filenames
>   
> https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/deb822-field-types
> 
> 
> File descriptions
> -
> 
> For example we have:
> 
>   * debian/control:
> policy → «Source package control file»
> dpkg   → «Debian source packages' master control file»
> 
>   * .dsc:
> policy → «Debian source control file»
> dpkg   → «Debian source packages' control file»
> 
>   * DEBIAN/control
> policy → «Binary package control files»
> dpkg   → «Debian binary packages' master control file»

Seems I missed another file:

  * .changes:
policy → «upload control file» / «Debian changes file»
dpkg   → «upload control file» / «.changes control file» /
 «Debian .changes file» / «Debian changes file»

> These are quite confusingly close.
> 
> I've been considering naming debian/control something like
> «Debian template source package control file», as that is used to
> generate both the source and binary control files. And always
> prefixing with Debian, so that would end up as:
> 
>   * debian/control: «Debian source package template control file»
>   * .dsc:   «Debian source package control file»
>   * DEBIAN/control: «Debian binary package control file»

For changes I think something like the following might be a more clear
option (and has the minor bonus of aligning perfectly on the first
words! :), with it mentioning explicitly this is about changes being
uploaded, and that it is a control file (but I'm not sure I'm entirely
convinced about it):

* .changes:   «Debian upload changes control files»

> This also removes the «master» usage in dpkg, for me for the same
> reasons as I covered at
> .

> File contents
> -
> 
> We have references to the various parts being called as «paragraphs»,
> «stanza», «blocks», but this seems to be more of an issue with dpkg, as
> the usage in the Debian policy is quite clear and uniform now, so I'll
> at least try to remove the «block» usage there, stanza has the nice
> property of being shorter and policy already mentions that this is
> currently a common alias, so I might keep paragraph and stanza for now
> in dpkg.

I've also found instances of «record» and «section» referring to fields
or stanzas.

> The other thing affecting dpkg and debian-policy is how the parts
> within the control files are referred to. We have for example:
> 
>   dpkg   → «general section of control info file»
>«source stanza»
>   policy → «general paragraph»
> 
>   dpkg   → «package's section of control info file»
>   policy → «binary package paragraphs»
> 
> 
> So, how does «source package paragraph» and «binary package paragraph»
> (of the «template control file») sound instead?

> If I've missed any other problematic nomenclature, I'm happy to
> discuss and update those on the dpkg side.

I also recalled another term that has always seemed very confusing in
context: «control information files» or «control information area». For
example in a sentence such as “the control file is a control information
file in the control information area in a .deb archive”. :) This also
seems confusing when some of the files 

Bug#1026199: release.debian.org: Is the toolchain list updated for bookworm

[Paul Gevers]

Hi Holger,

On 17-12-2022 12:50, Holger Levsen wrote:

On Sat, Dec 17, 2022 at 08:42:18AM +0100, Paul Gevers wrote:

I just refreshed the list, it's still there. I used a script on udd,
essentially this:

[...]

query = "SELECT DISTINCT package FROM packages WHERE release = 'bookworm'
and essential = 'yes'"

[...]

this made me check what we're using to calculate the set for
https://tests.reproducible-builds.org/debian/bullseye/amd64/pkg_set_key_packages.html
and it turned out to be this:

# key packages (same for all suites)
SQL_QUERY="SELECT source FROM key_packages;"
psql "postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net/udd" -t -c 
"${SQL_QUERY}" > $TMPFILE

which based on this thread seems to be wrong, as the key packages differ
per suite.


Well, the key package set is something else than the set we consider for 
the first freeze. The key package set is a set based on source, so 
indeed it doesn't differ per suite.



So now I wonder: how to get this from UDD?


I think you had the right query.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021053: check-dfsg-status: doubled report

[Holger Levsen]

Hi Adam,

sorry for the late reply and thanks for the bug report in the first place!

On Sat, Oct 01, 2022 at 10:54:20AM +0200, Adam Borowski wrote:
> When you renamed the package from vrms to check-dfsg-status, you forgot to
> migrate the cron job.  As a result, its now sends it monthly reports twice.
> 
> /etc/cron.monthly/vrms
> /etc/cron.monthly/check-dfsg-status
 
on don't see this here on a fresh install (of both packages from current sid),
so am I correct to assume this happened on upgrade from non-transitional package
vrms?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Stop saying that we are all in the same boat.
We’re all in the same storm. But we’re not all in the same boat.


signature.asc
Description: PGP signature

Bug#975325: dash(1) man page: ulimit documentation is inconsistent and out-of-date

[наб]

Control: tags -1 + upstream patch
Control: forwarded -1 
https://lore.kernel.org/dash/20221217151717.tiupxl7jrgwvw...@tarta.nabijaczleweli.xyz/t/#u

On Fri, Nov 20, 2020 at 03:25:55PM +0100, Vincent Lefevre wrote:
> On 2020-11-20 14:54:50 +0100, Vincent Lefevre wrote:
> > $ ulimit -r
> > sh: 17: ulimit: Illegal option -r
> For -r, it should probably be supported. See
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975326

Indeed; it's supported as part of ulimit -a only, and I've covered that
with my patch for #975326.

I've appended the dash@ thread with a documentation fix for ulimit -w
(and the synopsis), archived at forwarded-to.
Those are the only mis-match problems with ulimit, AFAICT at least.

наб


signature.asc
Description: PGP signature

Bug#1026263: ITP: node-benchmark --A benchmarking library

[Sandra Uwah]

Package: wnpp

Severity: wishlist

Owner: sandra uwah 

X-Debbugs-CC: debian-de...@lists.debian.org



* Package name: node-benchmark

   Version : 2.1.4

   Upstream Author : Mathias Bynens  (
https://mathiasbynens.be/)

* URL : https://benchmarkjs.com/

* License : Expat

  Programming Lang: JavaScript

  Description : A benchmarking library that supports high-resolution
timers & returns statistically significant results.

Bug#1026262: ojalgo: FTBFS tests require network access during build

[Hans Joachim Desserud]

Source: ojalgo
Version: 51.4.1+ds-1
Severity: normal
Tag: ftbfs patch

Dear Maintainer,

ojalgo currently fails to build with failing tests:
Fetch problem for AlphaVantageFetcher!
Symbol & Resolution: MSFT & DAY
java.net.UnknownHostException: www.alphavantage.co

(see 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ojalgo.html 
for more details)


Looks like one of the test suites tries to look up this domain to verify 
it can parse historical data. Since network access is disabled, this 
fails.


See the attached patch which disables this test suite, after which the 
package builds successfully.


Also thanks for the quick response and applying the patch to 
biojava4-live here the other day :)


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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


--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Disables network tests

---
Forwarded: not-needed
Last-Update: 2022-12-17

--- ojalgo-51.4.1+ds.orig/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageTest.java
+++ ojalgo-51.4.1+ds/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageTest.java
@@ -22,6 +22,7 @@
  */
 package org.ojalgo.data.domain.finance.series;
 
+import org.junit.jupiter.api.Disabled;
 import org.junit.jupiter.api.Test;
 import org.ojalgo.TestUtils;
 import org.ojalgo.type.CalendarDateUnit;
@@ -31,6 +32,7 @@ import org.ojalgo.type.CalendarDateUnit;
  *
  * @author stefanvanegmond
  */
+@Disabled("Requires network access")
 public class AlphaVantageTest extends FinanceDataTests {
 
 public AlphaVantageTest() {

Bug#1026261: ITP: markdown-exec -- Utilities to execute code blocks in Markdown files

[Carsten Schoenert]

Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: markdown-exec
  Version : 1.0.0
  Upstream Contact: Timothée Mazzucotelli 
* URL : https://pawamoy.github.io/markdown-exec
* License : ISC
  Programming Lang: Python
  Description : Utilities to execute code blocks in Markdown files

 This package enhances the functionality of PyMdown Extensions (provided
 within Debian as package python3-pymdownx). You can use markdown-exec
 if you write e.g a Python code block that computes some HTML and you want
 to place the generated HTML within a code block.

This package is new build dependency for mkdocstrings >= 0.19.1

It will be maintained within the Debian Python Team.

Bug#850202: dash: test with multiple conditions cannot handle variable whose expanded value is same as an operator

[наб]

Control: tags -1 + upstream wontfix

Hi!

On Thu, Jan 05, 2017 at 12:53:57AM +0100, J G Miller wrote:
> In Bourne shell script with dash, using either [ ] or test,
>test -n "${variable}" && echo "variable is set to -->${variable}<--"
> works as expected even if the value of variable is to a value the same
> as a test operator eg -ne or -nt
>variable="-ne" ; test -n "${variable}" && echo "variable is set to 
> -->${variable}<--"
>variable is set to -->-ne<--

Yes, the argument after -n is literal. As-expected so far.

> However the addition of another test condition with -a or -o results in an
> unexpected behavior in that the expanded variable is now treated as an 
> operator
> and not just as the string as should be the case.
> variable="-ne" ; test -n "${variable}" -a -n "${DISPLAY}" && echo 
> "variable is set to -->${variable}<--"
> dash: 1: test: Illegal number: -n

After expansion, this is test -n -ne -a -n :0.
Notably, -a, -o, (, and ) are all killed in POSIX Issue 8 (Draft 2.1),
via Austin Group Defect 1330:
  https://www.austingroupbugs.net/view.php?id=1330
They were marked obsolescent and optional in Issue 7 and earlier
(because they're awful and underspecified, you should never use them).

There are a few ways of parsing this:
if you're using a full-blown per-spec precedence-obeying parser,
like voreutils test or ksh, then you'll parse it like
  ( -n '-ne' ) && ( -n ':0' )
which resolves to true:
  $ ~/code/voreutils/out/cmd/test -n -ne -a -n :0; echo $?
  0
  $ ksh -c 'test -n -ne -a -n :0; echo $?'
  0
(well, idk if ksh uses a parse tree, but it produces the same result
that voreutils test does, and that does use one).

If you parse it in compatibility mode, like dash, bash,
and GNU coreutils test, then you'll parse it like
  ( '-n' -ne '-a' ) {garbage}
which is illegal:
  $ bash -c 'test -n -ne -a -n :0'
  bash: line 1: test: -n: integer expression expected
  $ test -n -ne -a -n :0
  ./dash: 1: test: Illegal number: -n
  $ /bin/test -n -ne -a -n :0
  /bin/test: invalid integer ‘-n’
(if you make the -ne arguments integers the garbage -n :0 makes it
 illegal anyway, and all of the above agree).

> Applying quoted parentheses makes no difference.
> variable="-ne" ; test \( -n "${variable}" \) -a \( -n "${DISPLAY}" \) && 
> echo "variable is set to -->${variable}<--"
> dash: 2: test: Illegal number: -n

This is test ( -n -ne ) -a ( -n :0 ).
This is a much more interesting case: the obvious parse here is, indeed,
  ( -n '-ne' ) && ( -n ':0' )
and GNU coreutils test, voreutils test, and ksh are in agreement now:
  $ /bin/test '(' -n -ne ')' -a '(' -n :0 ')'; echo $?
  0
  $ ~/code/voreutils/out/cmd/test '(' -n -ne ')' -a '(' -n :0 ')'; echo
  $?
  0
  $ ksh -c "test '(' -n -ne ')' -a '(' -n :0 ')'; echo \$?"
  0

Nevertheless, bash and dash still parse this differently:
  $ test '(' -n -ne ')' -a '(' -n :0 ')'; echo $?
  ./dash: 9: test: Illegal number: -n
  2
  $ bash -c "test '(' -n -ne ')' -a '(' -n :0 ')'; echo \$?"
  bash: line 1: test: -n: integer expression expected
  2
by substituting the first -n for 0, then the first ) for 0,
then adding a closing paren, yielding:
  $ test '(' 0 -ne ')' -a '(' -n :0 ')'; echo $?
  ./dash: 16: test: Illegal number: )
  2
  $ bash -c "test '(' 0 -ne ')' -a '(' -n :0 ')'; echo \$?"
  bash: line 1: test: ): integer expression expected
  2
  $ test '(' 0 -ne 0 -a '(' -n :0 ')'; echo $?
  ./dash: 18: test: closing paren expected
  2
  $ bash -c "test '(' 0 -ne 0 -a '(' -n :0 ')'; echo \$?"
  bash: line 1: test: `)' expected
  2
  $ test '(' 0 -ne 0 -a '(' -n :0 ')' ')'; echo $?
  1
  $ bash -c "test '(' 0 -ne 0 -a '(' -n :0 ')' ')'; echo \$?"
  1
we can see that they parse it as
  ( ( '-n' -ne ')' ) && ( -n ':0' )
which is unbalanced and puts -n and ) in integer spots.

> Similarly bad behavior is seen with a variable set to "-nt", which is how I 
> stumbled upon this problem.
> variable="-nt" ; test \( -n "${variable}" \) -a \( -n "${DISPLAY}" \) && 
> echo "variable is set to -->${variable}<--"
> dash: 3: test: closing paren expected

Similarly, this is test ( -n -nt ) -a ( -n :0 ), which, again,
would make most sense to be
  ( -n '-nt' ) -a ( -n ':0' )
and, similarly, the same suspects agree:
  $ /bin/test '(' -n -nt ')' -a '(' -n :0 ')'; echo $?
  0
  $ ~/code/voreutils/out/cmd/test '(' -n -nt ')' -a '(' -n :0 ')'; echo
  $?
  0
  $ ksh -c "test '(' -n -nt ')' -a '(' -n :0 ')'; echo \$?"
  0
and disagree:
  $ test '(' -n -nt ')' -a '(' -n :0 ')'; echo $?
  ./dash: 26: test: closing paren expected
  2
  $ bash -c "test '(' -n -nt ')' -a '(' -n :0 ')'; echo \$?"
  bash: line 1: test: `)' expected
  2
and through the same reduction process:
  $ test '(' -n -nt ')' -a '(' -n :0 ')' ')'; echo $?
  1
  $ bash -c "test '(' -n -nt ')' -a '(' -n :0 ')' ')'; echo \$?"
  1
we arrive at the same parse:
  ( ( '-n' -nt ')' ) && ( -n ':0' )
which is similarly unbalanced,
and strace confirms they both stat 0 and ).

> So the short term kludge 

Bug#1026260: dwww: DWWW_ALLOWEDLINKPATH seems not doing shit

[Alex Volkov]

Package: dwww
Version: 1.14
Severity: important

Dear Maintainer,

attemtping to access any manual page which happens to be outside of
DWWW_DOCPATH leads to "Access denied: dwww will not allow you to read the file"
page from runman.
Examples are, say, jar.1 manpage from openjdk-11-jdk-headless, which sits at
/usr/lib/jvm/java-11-openjdk-amd64/man/man1, or nvidia manpages in
/usr/lib/nvidia/current. Adding the respective directories (even when they are
below /usr/lib which is in the default allowed path) to DWWW_ALLOWEDLINKPATH
like this:

DWWW_ALLOWEDLINKPATH='/usr/share:/usr/lib:/usr/local/share:/var/www:/usr/lib/nvidia/current:/usr/lib/jvm/java-11-openjdk-amd64/man/man1'

has no effect. Maybe it's a Perl issue, though.

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (991, 'stable-security'), (991, 'stable'), (99, 'testing'), (90,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.3-bootes3-p-1000 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dwww depends on:
ii  apache2 [httpd-cgi]2.4.54-1~deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  debianutils4.11.2
ii  doc-base   0.11.1
ii  file   1:5.39-3
ii  libc6  2.31-13+deb11u5
ii  libfile-ncopy-perl 0.36-2.1
ii  libmime-types-perl 2.18-1
ii  man-db 2.9.4-2
ii  mime-support   3.66
ii  perl   5.32.1-4+deb11u2
ii  sensible-utils 0.0.14
ii  ucf3.0043

Versions of packages dwww recommends:
ii  apache2 [httpd]  2.4.54-1~deb11u1
ii  apt  2.2.4
ii  dlocate  1.07+nmu1
ii  info2www 1.2.2.9-24.1
ii  swish++  6.1.5-5

Versions of packages dwww suggests:
ii  chromium [www-browser] 108.0.5359.124-1~deb11u1
ii  doc-debian 6.5
ii  dpkg-www   2.61
ii  edbrowse [www-browser] 3.7.7-2
ii  elinks [www-browser]   0.13.2-1+b1
ii  firefox-esr [www-browser]  102.6.0esr-1~deb11u1
ii  konqueror [www-browser]4:20.12.0-4
ii  lynx [www-browser] 2.9.0dev.6-3~deb11u1
ii  opera [www-browser]12.16.1860
ii  w3m [www-browser]  0.5.3+git20210102-6

-- debconf information:
* dwww/index_docs: true
  dwww/nosuchdir:
  dwww/badport:
* dwww/cgidir: /usr/lib/cgi-bin
* dwww/serverport: 80
  dwww/nosuchuser:
* dwww/docrootdir: /var/www
* dwww/cgiuser: www-data

Bug#1026259: linux: SW RAID to JFS intermittent boot fail with NULL pointer dereference

[Andy Simpkins]

Source: linux
Severity: normal
X-Debbugs-Cc: rattusrat...@debian.org

Dear Maintainer,

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

   * What led up to the situation?
Images testing for SW RAID release 11.6

* What exactly did you do (or not do) that was effective (or
 ineffective)?
Installation testing option test matrix option #3 with the following
disk partitions

sda1 primary   1GB  B K raid (#1)
sda3 primary  15GBK raid (#0)
sda5 logical   1GBF swap  swap

RAID1 #0 jfs  /
RAID1 #1 ext2 /boot


* What was the outcome of this action?
kernel crash with 
[2.671938] BUG: kernel NULL pointer dereference, address: 0028

(console output attached)


* What outcome did you expect instead?
Boot into fresh installed system :-)


* More details

(1) I have demonstrated this to Sledge on MULTIPLE instalations, both
BIOS and UEFI and various degraded RAID configurations.

(2) It appears to be Machine spacific; i.e. Sledge has been unable to
reproduce the problem on his hardware

(3) We have seen the problem on installations of debian 11.5 as well

(4) Occasionally I have been able to get lucky and the system has
booted.  This, coupled with #2 might suggest a race hazard / timing
issue?

Sorry

/Andy


RAID_JFS_kernel_bug_console_out
Description: application/json

Bug#1026258: FTBFS: missing build dependency and failing tests

[Hans Joachim Desserud]

Source: ormar
Version: 0.12.0-1
Severity: serious
Tag: ftbfs

Dear Maintainer,

ormar currently fails to build from source for two reasons. The first is 
several error message like these when running the test suite:

Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/test_fastapi/test_skip_reverse_models.py:8: in 
from starlette.testclient import TestClient
/usr/lib/python3/dist-packages/starlette/testclient.py:16: in 
import httpx
E   ModuleNotFoundError: No module named 'httpx'
_ ERROR collecting tests/test_fastapi/test_wekref_exclusion.py 
_


(Taken from the build log when the package got synced to Ubuntu, but 
I've also reproduced this on Sid 
https://launchpadlibrarian.net/638906557/buildlog_ubuntu-lunar-amd64.ormar_0.12.0-1_BUILDING.txt.gz)


These errors are the easy part, it simply needs
python3-httpx
added as a build dependency. With this in place, the build result 
changes from 19 errors to 2 failing tests. I don't know why they are 
failing though, whether it is due to api changes in the test client 
used, or the functionality of the package.


=== FAILURES 
===
__ test_all_endpoints 
__


def test_all_endpoints():
client = TestClient(app)
with client as client:
item = {
"name": "test",
"categories": [{"name": "test cat"}, {"name": "test 
cat2"}],

}
response = client.post("/items/", json=item)
item_check = Item(**response.json())
assert item_check.id is not None
assert item_check.categories[0].id is not None

  no_pk_item = client.get(f"/items/{item_check.id}", 
json=item).json()
E   TypeError: TestClient.get() got an unexpected keyword 
argument 'json'


tests/test_fastapi/test_excluding_fields.py:118: TypeError
__ test_all_endpoints 
__


def test_all_endpoints():
client = TestClient(app)
with client as client:
response = client.post("/categories/", json={"name": "test 
cat"})

category = response.json()
response = client.post(
"/items/", json={"name": "test", "id": 1, "category": 
category}

)
item = Item(**response.json())
assert item.pk is not None

response = client.get("/items/")
items = [Item(**item) for item in response.json()]
assert items[0] == item

item.name = "New name"
response = client.put(f"/items/{item.pk}", json=item.dict())
assert response.json() == item.dict()

response = client.get("/items/")
items = [Item(**item) for item in response.json()]
assert items[0].name == "New name"

response = client.get("/items/raw/")
items = [Item(**item) for item in response.json()]
assert items[0].name == "New name"
assert items[0].category.name is None

response = client.get(f"/items/{item.pk}")
new_item = Item(**response.json())
assert new_item == item

response = client.delete(f"/items/{item.pk}")
assert response.json().get("deleted_rows", "__UNDEFINED__") 
!= "__UNDEFINED__"

response = client.get("/items/")
items = response.json()
assert len(items) == 0

client.post("/items/", json={"name": "test_2", "id": 2, 
"category": category})

response = client.get("/items/")
items = response.json()
assert len(items) == 1

item = Item(**items[0])
  response = client.delete(f"/items/{item.pk}", 
json=item.dict())
E   TypeError: TestClient.delete() got an unexpected keyword 
argument 'json'


tests/test_fastapi/test_more_reallife_fastapi.py:150: TypeError


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#1026253: transition: cfitsio

[Aurelien Jarno]

Hi Sebastian,

On 2022-12-17 14:43, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-cfitsio.html
> 
> Hi Aurelien
> 
> On 2022-12-17 12:52:27 +0100, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-astro-maintain...@lists.alioth.debian.org
> > 
> > Dear release team,
> > 
> > I would like to request a transition slot for cfitsio, changing the
> > library name from libcfitsio9 to libcfitsio10. The change has been
> > introduced in version 4.2.0-1 which in experimental for 2 weeks and has
> > been built on all release architectures and most debian-ports
> > architectures.
> > 
> > I have locally rebuilt all the reversed dependencies on amd64, and found
> > only 2 FTBFS:
> > 
> > - tcl-fitstcl (#1026237)
> >   => this is fixed in experimental, it just need to be uploaded to sid
> >  in sync with cfitsio
> > 
> > - purify (#1001528)
> >   => this package is in sid only
> > 
> > There is already a tracker available here:
> > 
> > https://release.debian.org/transitions/html/auto-cfitsio.html
> > 
> > Thanks for considering.
> 
> Please go ahead.

Thanks for the fast answer. I have just uploaded it.

Cheers
Aurelien

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

Bug#1025744: greetd - FTBFS with new version of rust-nix.

[Peter Green]

Control: severity -1 serious

On 14/12/2022 15:42, Marc Dequènes (duck) wrote:

Control: tags -1 + pending


Quack,

On 2022-12-08 22:21, Peter Green wrote:

I have updated rust-nix in experimental, and intend to do so in unstable
soon, the code in your package builds fine with the new version, but
the Cargo dependencies don't allow it to be used. The attached patch
updates the Debian and Cargo dependencies in your package to be consistent
with each other.


Thanks for the report and patch. I have never tested with 0.24 so I chose to 
enforce 0.25 instead.
I pushed the changes on Salsa and I intend to upload soon but I have other fixes pending that should land soon. 

The new version of rust-nix has just been uploaded to unstable, bumping 
severity.

Bug#1026257: FTBFS: more network tests in node-zx

[Hans Joachim Desserud]

Source: node-zx
Version: 7.1.1+~cs6.7.23-1
Severity: serious
Tag: ftbfs patch

Dear Maintainer,

node-zx currently fails to build with the following error messages:
   FAIL  deps  "installDeps() loader works via JS API"
Cannot find package 'cpy' imported from 
/build/node-zx-7.1.1+~cs6.7.23/test/deps.test.js


   FAIL  deps  "installDeps() loader works via CLI"
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'lodash' imported from 
/build/node-zx-7.1.1+~cs6.7.23/zx-kdsc9wx1fn.mjs

Did you mean to import lodash/lodash.js?
at new NodeError (node:internal/errors:393:5)
at packageResolve (node:internal/modules/esm/resolve:860:9)
at moduleResolve (node:internal/modules/esm/resolve:909:20)
at defaultResolve (node:internal/modules/esm/resolve:1124:11)
at nextResolve (node:internal/modules/esm/loader:163:28)
at ESMLoader.resolve (node:internal/modules/esm/loader:841:30)
at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
at ModuleWrap. 
(node:internal/modules/esm/module_job:76:40)

at link (node:internal/modules/esm/module_job:75:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}
at Object.handler 
(file:///build/node-zx-7.1.1+~cs6.7.23/test/deps.test.js:35:12)

exit code: 1

(See 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-zx.html 
for more details)


I was able to reproduce the same error message when building in pbuilder 
on my local Sid system. Turns out there's a couple of tests which call 
`npm install` and verify the results which breaks when the network is 
not available.


After expanding and applying the patch to disable network tests, the 
package builds successfully.



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

Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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


--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/patches/drop-network-test.patch b/debian/patches/drop-network-test.patch
index cf5cd17..905f6a8 100644
--- a/debian/patches/drop-network-test.patch
+++ b/debian/patches/drop-network-test.patch
@@ -1,7 +1,7 @@
 Description: drop network test
 Author: Yadd 
 Forwarded: not-needed
-Last-Update: 2022-11-07
+Last-Update: 2022-12-17
 
 --- a/test/cli.test.js
 +++ b/test/cli.test.js
@@ -37,3 +37,24 @@ Last-Update: 2022-11-07
  test('echo() works', async () => {
let stdout = ''
let log = console.log
+--- a/test/deps.test.js
 b/test/deps.test.js
+@@ -21,7 +21,7 @@ const test = suite('deps')
+ 
+ $.verbose = false
+ 
+-test('installDeps() loader works via JS API', async () => {
++test.skip('installDeps() loader works via JS API', async () => {
+   await installDeps({
+ cpy: '9.0.1',
+ 'lodash-es': '4.17.21',
+@@ -30,7 +30,7 @@ test('installDeps() loader works via JS
+   assert.instance((await import('lodash-es')).pick, Function)
+ })
+ 
+-test('installDeps() loader works via CLI', async () => {
++test.skip('installDeps() loader works via CLI', async () => {
+   let out =
+ await $`node build/cli.js --install <<< 'import _ from "lodash" /* @4.17.15 */; console.log(_.VERSION)'`
+   assert.match(out.stdout, '4.17.15')
+

Bug#1025863: transition: qtbase-opensource-src

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Dmitry

On 2022-12-10 21:45:01 +0300, Dmitry Shachnev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net
> 
> Dear Release team,
> 
> This is probably the last Qt 5 transition this release cycle.
> 
> Qt 5.15.8 sources will be published around 2023-01-04, which gives us just
> 8 days before the transition freeze. Although, if you are not against
> last-minute transition requests, we can try.

It would make sense to get it into bookworm. So let's try.

> But now I am ready to upload Qt 5.15.7 to unstable. It is already available
> in experimental, no problems were noticed.
> 
> Ben file is the following:
> 
> title = "qtbase-opensource-src and qtdeclarative-opensource-src";
> is_affected = .depends ~ "qtdeclarative-abi-5-15-7" | .depends ~ 
> "qtdeclarative-abi-5-15-6" | .depends ~ "qtbase-abi-5-15-7" | .depends ~ 
> "qtbase-abi-5-15-6";
> is_good = .depends ~ "qtbase-abi-5-15-7" | .depends ~ 
> "qtdeclarative-abi-5-15-7";
> is_bad = .depends ~ "qtbase-abi-5-15-6" | .depends ~ 
> "qtdeclarative-abi-5-15-6";
> 
> No qtwebengine this time, as it has been dealt with separately.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1024322: transition: dpdk

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Luca

On 2022-12-17 02:12:56 +, Luca Boccassi wrote:
> Control: tags -1 -moreinfo
> 
> On Wed, 23 Nov 2022 at 19:49, Sebastian Ramacher  wrote:
> >
> > Control: tags -1 moreinfo
> >
> > On 2022-11-17 14:27:25 +, Luca Boccassi wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org
> > >
> > > Hello Thomas and Release Team,
> > >
> > > As we did for Bullseye, we are proposing the following plan to allow
> > > Bookworm to ship with the latest LTS versions of DPDK and OVS. This
> > > will let us make use of the full LTS support windows for both projects,
> > > as we have done for the past few releases.
> > >
> > > Upload OVS built from git (with new sonames/package renames if
> > > necessary), new OVN, DPDK 22.11 in early-to-mid December to unstable,
> > > ideally before the 16th as we go on vacation after that, to finish the
> > > transition.
> > >
> > > Then, after OVS 3.1 releases in February, upload it unstable (no
> > > soname/transition required, as only bug fixes will go in at that
> > > point). The upstream release might happen before or after the
> > > 2023/02/12 soft freeze, and if it is after we will ask for an
> > > exception.
> > >
> > > Would this plan work for everyone?
> >
> > Sounds like that should work like last time. Please remove the moreinfo
> > tag once dpdk is ready for the upload to unstable.
> 
> Hi,
> 
> We are now ready. dpdk, openvswitch and ovn are ready in experimental.
> uhd and collectd in unstable will need a simple binary rebuild and are
> already compatible.

Please go ahead

Cheers

> 
> Kind regards,
> Luca Boccassi
> 

-- 
Sebastian Ramacher

Bug#1025930: transition: openvdb

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Mathieu

On 2022-12-12 08:21:40 +0100, Mathieu Malaterre wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I'd like to request a transition slot for openvdb 10.0.
> 
> openvdb 10.0 is available in experimental (except mipsel):
> 
> https://buildd.debian.org/status/package.php?p=openvdb=experimental
> 
> I've built all reverse dependencies without issues. I'll request the
> removal of mipsel binaries.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1019665: ruby-safe-yaml: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: ArgumentError:

[Diederik de Haas]

On 13 Sep 2022 09:00:07 -0300 Antonio Terceiro  wrote:
> Source: ruby-safe-yaml
> Version: 1.0.5-2
> Justification: FTBFS
> Usertags: ruby3.1
> 
> We are about to start the ruby3.1 transition in unstable. While trying to
> rebuild ruby-safe-yaml with ruby3.1 enabled, the build failed.
> 
> Relevant part of the build log (hopefully):
> >   ArgumentError:
> > wrong number of arguments (given 2, expected 1)
> >   # ./lib/safe_yaml/load.rb:149:in `load'
> >   # ./lib/safe_yaml.rb:29:in `safe_load'
> >   # ./spec/safe_yaml_spec.rb:7:in `safe_load_round_trip'
> >   # ./spec/safe_yaml_spec.rb:745:in `block (4 levels) in  >   (required)>'
> > 
> > Finished in 0.08109 seconds (files took 0.12613 seconds to load)
> > 134 examples, 20 failures
> > 
> > Failed examples:
> > 
> > rspec ./spec/safe_yaml_spec.rb:29 # Psych unsafe_load allows exploits 
> > through objects defined in YAML w/ !ruby/hash via custom :[]= methods

There is an upstream PR: https://github.com/dtao/safe_yaml/pull/101
which tried to address this, but someone who tried it still got errors.

Last upstream commit was from 2019-02-22 and there are several PRs open and it 
looks like the maintainer hasn't responded to any of them for > 5 YEARS

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

Bug#1026256: backuppc: BackupPC destroys its configuration when you "Save" in the admin web console

[Andreas Feldner]

Package: backuppc
Version: 4.4.0-6+b1
Severity: important

Dear Maintainer,

after a recent update (probably to a Perl library), a bug in BackupPC leads to 
it destroying
its configuration files when saved from the BackupPC admin console.

On a system updated to the current versions of Debian Testing, I made minor 
modifications to
the configuration setup in the web admin console and pressed the "Save" button.

After that, any access to the admin console led to an internal error message. 
Restarting the
backuppc service fails from that point on as well.

Reason is that any configuration file saved this way is destroyed, as the 
brackets, [] and {},
required to store arrays or maps respectively, are replaced by ordinary 
brackets ().

CAUTION: For certain configuration files, this problem will *not* lead to 
backups reporting failure, but generating
faulty or incomplete backups due to misinterpretation of the config files, 
along with lack
of proper validation of the config files.

This bug is reported upstream: https://github.com/backuppc/backuppc/issues/466
A fix seems to be available and extremely easy to apply (not verified myself), 
but is  not
yet part of an upstream release.


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 backuppc depends on:
ii  adduser3.129
ii  apache2 [httpd]2.4.54-5
ii  apache2-utils  2.4.54-5
ii  backuppc-rsync 3.1.3.0-3
ii  bzip2  1.0.8-5+b1
ii  debconf [debconf-2.0]  1.5.80
ii  exim4  4.96-9
ii  exim4-daemon-light [mail-transport-agent]  4.96-9
ii  init-system-helpers1.65.2
ii  iputils-ping   3:20221126-1
ii  libarchive-zip-perl1.68-1
ii  libbackuppc-xs-perl0.62-2+b2
ii  libc6  2.36-6
ii  libcgi-pm-perl 4.54-1
ii  libfile-listing-perl   6.15-1
ii  libtime-parsedate-perl 2015.103-4
ii  lsb-base   11.5
ii  perl   5.36.0-4
ii  sysvinit-utils [lsb-base]  3.05-7
ii  ucf3.0043

Versions of packages backuppc recommends:
ii  libio-dirent-perl0.05-1.1+b2
ii  openssh-client [ssh-client]  1:9.1p1-1
ii  rrdtool  1.7.2-4+b6
ii  samba-common-bin 2:4.17.3+dfsg-3
ii  smbclient2:4.17.3+dfsg-3

Versions of packages backuppc suggests:
pn  certbot | acme-tiny | acmetool | dehydrated | lacme  
 | lecm | lego
pn  libscgi-perl 
ii  lynx [www-browser]   2.9.0dev.10-1+b1
ii  par2 0.8.1-3
ii  rsync3.2.6-4+b1
ii  w3m [www-browser]0.5.3+git20220429-1+b1

-- Configuration Files:
/etc/backuppc/apache.conf changed [not included]
/etc/backuppc/config.pl [Errno 13] Keine Berechtigung: '/etc/backuppc/config.pl'
/etc/backuppc/hosts [Errno 13] Keine Berechtigung: '/etc/backuppc/hosts'
/etc/backuppc/localhost.pl [Errno 13] Keine Berechtigung: 
'/etc/backuppc/localhost.pl'
/etc/default/backuppc changed [not included]

-- debconf information excluded

Bug#1025944:

[matthias . geiger1024]

Version: 0.2.2
It's already the newest version. Closing.

Bug#1026253: transition: cfitsio

[Sebastian Ramacher]

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

Hi Aurelien

On 2022-12-17 12:52:27 +0100, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-astro-maintain...@lists.alioth.debian.org
> 
> Dear release team,
> 
> I would like to request a transition slot for cfitsio, changing the
> library name from libcfitsio9 to libcfitsio10. The change has been
> introduced in version 4.2.0-1 which in experimental for 2 weeks and has
> been built on all release architectures and most debian-ports
> architectures.
> 
> I have locally rebuilt all the reversed dependencies on amd64, and found
> only 2 FTBFS:
> 
> - tcl-fitstcl (#1026237)
>   => this is fixed in experimental, it just need to be uploaded to sid
>  in sync with cfitsio
> 
> - purify (#1001528)
>   => this package is in sid only
> 
> There is already a tracker available here:
> 
> https://release.debian.org/transitions/html/auto-cfitsio.html
> 
> Thanks for considering.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1026255: FTBFS: error: invalid flag: -html4

[Hans Joachim Desserud]

Source: junit5-system-exit
Version: 1.1.2-3
Severity: serious
Tags: ftbfs patch

Dear Maintainer,

junit5-system-exit currently fails to build from source with the 
following error message:
Starting process 'command 
'/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc''. Working directory: 
/build/1st/junit5-system-exit-1.1.2 Command: 
/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc 
@/build/1st/junit5-system-exit-1.1.2/build/tmp/javadoc/javadoc.options
Successfully started process 'command 
'/usr/lib/jvm/java-17-openjdk-amd64/bin/javadoc''

error: invalid flag: -html4
1 error

(for details see 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/junit5-system-exit.html)


I was able to reproduce this on my Sid system, and the package built 
successfully when replacing the flag, see the attached patch.


Based on the output from javadoc, this option now seems to be the 
default
-html5Generate HTML 5 output. This option is no longer 
required.
so alternatively the javadoc section can be trimmed down. Another thing 
is that I haven't checked when the html5 option was introduced or when 
it replaced html4. It builds successfully with the current JDK, but it 
might introduced problems when backporting the package in the future. I 
don't know if this is a concern.


Regardless, the attached patch should fix the build issue or serve as 
the base for a better fix :)


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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


--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Replace html4 option with html5

The html4 option has been removed/replaced in newer JDKs, causing a build 
failure.

---
Forwarded: no

--- junit5-system-exit-1.1.2.orig/build.gradle
+++ junit5-system-exit-1.1.2/build.gradle
@@ -74,6 +74,6 @@ publishing {
 
 javadoc {
 if(JavaVersion.current().isJava9Compatible()) {
-options.addBooleanOption('html4', true)
+options.addBooleanOption('html5', true)
 }
 }

Bug#1026254: Transition KDE PIM 22.12

[Patrick Franz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org

Hi Release Team,

we would like to request a transition for KDE PIM 22.12.

The packages depending on KDE PIM are:

* digikam
* kgpg
* kio-gdrive
* kjots
* kmymoney
* kraft
* zanshin

All of these packages should just need a rebuild against 22.12.

Note that we have not yet uploaded KDE PIM 22.12 to experimental
yet as we are waiting for one package to clear NEW, but the
packaging is complete. Once libkf5pimcommon has cleared NEW, we
can upload it to experimental immediately.
I wanted to request the transition in good time before the freeze
in January and will update this bug report when the upload to
experimental is complete.

In any case, here is the BEN file:

---
title = "KDEPIM 22.12";

is_affected = .depends ~ /libkf5.*-22.08/ | .depends ~ /libkf5.*-22.12/;
is_good = .depends ~ /libkf5.*-22.12/;
is_bad = .depends ~ /libkf5.*-22.08/;
---

Thank you.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1025642: RFS: d11amp/0.59-1 [ITP] -- Simple MP3 player

[Thomas Dettbarn]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,


So, I have noticed that not much has happened with my package in the
last couple of days...
Which is a shame, because I still think that my project is AWESOME. :)

Again, it is a MP3 player. Yes, you have a lot of them in the packages,
and this one is not that
"Different". It is more of a REIMAGINING of xmms. Afaik, said layer was
a fork from x11amp,
which was the first Linux Version of WinAmp.

It was highly customizable, and a lot of people did that, which you can
see here:https://skins.webamp.org. My player d11amp can handle those,
and thus looks badass-oldskool.


The second point I would like to make about this player is its license
model. It relies on GTK4,
which stand firmly on the ground of LGPL. There are other players, which
are using a different
frontend. And those sometimes have a Semi-Commercial License. (You know
what I mean. ;) )

With d11amp, even the default skin is EXPLICITLY CC-0, so even
screenshots are not a problem.

So, to sum up:


1. Looks cool
2. License model is open source friendly


On top of that: Isn't the whole point of Open Source to give users the
freedom to choose?
Please see d11amp as one more option. I hope you find that it deserves a
place in your
collection one day.




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


* Package name : d11amp
Version : 0.59-1
Upstream contact : Thomas Dettbarn
* URL :https://www.dettus.net/d11amp/
* License : BSD-2-Clause
* Vcs :https://github.com/dettus/d11amp/
Section : sound

The source builds the following binary packages:

d11amp - Simple MP3 player

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/d/d11amp/d11amp_0.59-1.dsc

Changes for the initial release:

d11amp (0.59-1) unstable; urgency=low
.
* initial release.
* Closes: #1025668  

Regards,


Thomas

Bug#1026234: linux-image-6.0.0-5-amd64: i915 driver fails on resume

[Floris Bruynooghe]

Hi Salvatore,

On Fri 16 Dec 2022 at 22:54 +0100, Salvatore Bonaccorso wrote:
> On Fri, Dec 16, 2022 at 10:34:08PM +0100, Floris Bruynooghe wrote:
>> On Fri 16 Dec 2022 at 21:50 +0100, Salvatore Bonaccorso wrote:
>> > On Fri, Dec 16, 2022 at 09:28:35PM +0100, Floris Bruynooghe wrote:
>> >> Package: src:linux
>> >> Version: 6.0.10-2
>> >> Severity: important
>> >> 
>> >> Dear Maintainer,
>> >> 
>> >> Since the 6.0.0-5 kernel the i915 graphics driver often fails on resume.
>> >> Downgrading to the 6.0.0-4 kernel fixes it and the driver works
>> >> flawlessly across resume, changing displays etc.
>> >> 
>> >> On the -5 kernel the following errors are observed when the driver
>> >> crashes:
>> >> 
>> >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-9: PM: parent card0 
>> >> should not be sleeping
>> >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-10: PM: parent card0 
>> >> should not be sleeping
>> >> Dec 13 11:26:58 fredriksen kernel: drm card0-DP-11: PM: parent card0 
>> >> should not be sleeping
>> >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: [drm] *ERROR* 
>> >> Sending link address failed with -5
>> >> Dec 13 11:26:58 fredriksen kernel: [ cut here ]
>> >> Dec 13 11:26:58 fredriksen kernel: i915 :00:02.0: 
>> >> drm_WARN_ON(dig_port->tc_mode != TC_PORT_DISCONNECTED)
>> >> Dec 13 11:26:58 fredriksen kernel: WARNING: CPU: 0 PID: 27095 at 
>> >> drivers/gpu/drm/i915/display/intel_tc.c:711 int>
>> >> Dec 13 11:26:58 fredriksen kernel: Modules linked in: usblp ctr ccm 
>> >> rfcomm cmac algif_hash algif_skcipher af_alg>
>> >> Dec 13 11:26:58 fredriksen kernel:  snd_sof_utils ecdh_generic 
>> >> snd_soc_hdac_hda ecc snd_hda_ext_core snd_soc_acp>
>> >> Dec 13 11:26:58 fredriksen kernel:  configfs efivarfs ip_tables x_tables 
>> >> autofs4 btrfs blake2b_generic libcrc32c>
>> >> Dec 13 11:26:58 fredriksen kernel: CPU: 0 PID: 27095 Comm: 
>> >> kworker/u32:101 Not tainted 6.0.0-5-amd64 #1  Debian >
>> >> Dec 13 11:26:58 fredriksen kernel: Hardware name: LENOVO 
>> >> 21CBCTO1WW/21CBCTO1WW, BIOS N3AET67W (1.32 ) 09/27/2022
>> >> Dec 13 11:26:58 fredriksen kernel: Workqueue: events_unbound 
>> >> async_run_entry_fn
>> >> Dec 13 11:26:58 fredriksen kernel: RIP: 
>> >> 0010:intel_tc_port_sanitize+0x2d2/0x490 [i915]
>> >> Dec 13 11:26:58 fredriksen kernel: Code: 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 
>> >> 2f e8 a7 44 42 e3 48 c7 c1 f8 a6 d6 c0>
>> >> Dec 13 11:26:58 fredriksen kernel: RSP: 0018:a84dc5debc08 EFLAGS: 
>> >> 00010286
>> >> Dec 13 11:26:58 fredriksen kernel: RAX:  RBX: 
>> >> 9c812065 RCX: 
>> >> Dec 13 11:26:58 fredriksen kernel: RDX: 0001 RSI: 
>> >> a4b7eeea RDI: 
>> >> Dec 13 11:26:58 fredriksen kernel: RBP:  R08: 
>> >> a5262260 R09: a5b5348a
>> >> Dec 13 11:26:58 fredriksen kernel: R10:  R11: 
>> >> 004a R12: 9c81101a2000
>> >> Dec 13 11:26:58 fredriksen kernel: R13: 9c8101f19900 R14: 
>> >>  R15: 9c81101a2000
>> >> Dec 13 11:26:58 fredriksen kernel: FS:  () 
>> >> GS:9c883f40() knlGS:
>> >> Dec 13 11:26:58 fredriksen kernel: CS:  0010 DS:  ES:  CR0: 
>> >> 80050033
>> >> Dec 13 11:26:58 fredriksen kernel: CR2: 55710e140b16 CR3: 
>> >> 0002db810003 CR4: 00770ef0
>> >> Dec 13 11:26:58 fredriksen kernel: PKRU: 5554
>> >> Dec 13 11:26:58 fredriksen kernel: Call Trace:
>> >> Dec 13 11:26:58 fredriksen kernel:  
>> >> Dec 13 11:26:58 fredriksen kernel:  intel_ddi_sync_state+0x3f/0x90 [i915]
>> >> Dec 13 11:26:58 fredriksen kernel:  
>> >> intel_modeset_setup_hw_state+0x3b1/0x1410 [i915]
>> >> Dec 13 11:26:58 fredriksen kernel:  ? _raw_spin_lock_irq+0x19/0x40
>> >> Dec 13 11:26:58 fredriksen kernel:  ? wait_for_completion+0x91/0x160
>> >> Dec 13 11:26:58 fredriksen kernel:  ? drm_modeset_lock+0x63/0xd0 [drm]
>> >> Dec 13 11:26:58 fredriksen kernel:  ? ww_mutex_lock+0x14/0x80
>> >> Dec 13 11:26:58 fredriksen kernel:  ? __intel_display_resume+0x1a/0xe0 
>> >> [i915]
>> >> Dec 13 11:26:58 fredriksen kernel:  __intel_display_resume+0x1a/0xe0 
>> >> [i915]
>> >> Dec 13 11:26:58 fredriksen kernel:  intel_display_resume+0xfc/0x140 [i915]
>> >> Dec 13 11:26:58 fredriksen kernel:  i915_drm_resume+0xba/0x130 [i915]
>> >> Dec 13 11:26:58 fredriksen kernel:  ? pci_pm_poweroff_noirq+0x100/0x100
>> >> Dec 13 11:26:58 fredriksen kernel:  dpm_run_callback+0x47/0x150
>> >> Dec 13 11:26:58 fredriksen kernel:  device_resume+0x88/0x190
>> >> Dec 13 11:26:58 fredriksen kernel:  async_resume+0x19/0x30
>> >> Dec 13 11:26:58 fredriksen kernel:  async_run_entry_fn+0x2d/0x130
>> >> Dec 13 11:26:58 fredriksen kernel:  process_one_work+0x1c4/0x380
>> >> Dec 13 11:26:58 fredriksen kernel:  worker_thread+0x4d/0x380
>> >> Dec 13 11:26:58 fredriksen kernel:  ? rescuer_thread+0x3a0/0x3a0
>> >> Dec 13 11:26:58 fredriksen kernel:  kthread+0xe6/0x110
>> 

Bug#986152: Offer of help

[Jeremy Sowden]

Another ping.  Offer still stands.

J.


signature.asc
Description: PGP signature

Bug#1026253: transition: cfitsio

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-astro-maintain...@lists.alioth.debian.org

Dear release team,

I would like to request a transition slot for cfitsio, changing the
library name from libcfitsio9 to libcfitsio10. The change has been
introduced in version 4.2.0-1 which in experimental for 2 weeks and has
been built on all release architectures and most debian-ports
architectures.

I have locally rebuilt all the reversed dependencies on amd64, and found
only 2 FTBFS:

- tcl-fitstcl (#1026237)
  => this is fixed in experimental, it just need to be uploaded to sid
 in sync with cfitsio

- purify (#1001528)
  => this package is in sid only

There is already a tracker available here:

https://release.debian.org/transitions/html/auto-cfitsio.html

Thanks for considering.

Regards
Aurelien

Bug#1026250: Fixed upstream

[William Desportes]

Thank you for the report
This was fixed upstream, the next release of sql-parser should follow shortly.

I think the commit that fixes it may be 
https://github.com/phpmyadmin/sql-parser/commit/4ee76d94525a092df6b6ea1109171bfc9bc73f52

Bug#1026199: release.debian.org: Is the toolchain list updated for bookworm

[Holger Levsen]

On Sat, Dec 17, 2022 at 08:42:18AM +0100, Paul Gevers wrote:
> I just refreshed the list, it's still there. I used a script on udd,
> essentially this:
[...]
> query = "SELECT DISTINCT package FROM packages WHERE release = 'bookworm'
> and essential = 'yes'"
[...]

this made me check what we're using to calculate the set for
https://tests.reproducible-builds.org/debian/bullseye/amd64/pkg_set_key_packages.html
and it turned out to be this:

# key packages (same for all suites)
SQL_QUERY="SELECT source FROM key_packages;"
psql "postgresql://udd-mirror:udd-mir...@udd-mirror.debian.net/udd" -t -c 
"${SQL_QUERY}" > $TMPFILE

which based on this thread seems to be wrong, as the key packages differ
per suite.

So now I wonder: how to get this from UDD?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Be careful when you follow the masses. Sometimes the "m" is silent.


signature.asc
Description: PGP signature