Bug#1023167: linux-image-6.0.0-2-amd64: squashfs regressions in upstream kernel 6.0.6

[Florian La Roche]

Package: src:linux
Version: 6.0.5-1
Severity: normal
X-Debbugs-Cc: florian.laro...@gmail.com

Dear Maintainer,

I am running containers with lxd together with snap on Debian testing. Running 
a current
kernel 6.0.6 this shows problems with lxd as detailed here:

  
https://forum.snapcraft.io/t/unsupported-version-0-of-verneed-record-linux-6-0/32160/4

The problem seems to be regressions in squshfs as reported in detail together 
with
first patches here:

  https://lore.kernel.org/lkml/20221020223616.7571-1-phil...@squashfs.org.uk/

I have applied the above patches onto of a current salsa "sid" Debian
kernel and this seems to fix the problem for me.
It would be good to see this problem fixed in newer Debian kernels (once
they are fixed upstream or as additional patches with the Debian kernel).


best regards,
special thanks for the nice work on good Ddebian kernels to all involved 
developers,


Florian La Roche

Bug#1010248: ITP: wlgreet raw wayland greeter for greetd

[Johannes Schauer Marin Rodrigues]

Quoting Marc Dequènes (duck) (2022-10-31 03:39:55)
> There's several layers of dependencies that needed packaging and going
> through NEW took a while.  Now I'm dealing with owned-ttf-parser and after
> some requested changes I hit some potential licensing issues and I'm checking
> this with the ftpmasters.  After that rusttype can be built and need to go
> through NEW.  Then I can finally upload wlgreet.
> 
> Sorry it's taking so much time.  \_o<

Oh no! This looked like a simple package at first glance but now I see the
Cargo.toml... Thank you for your work!

cheers, josch

signature.asc
Description: signature

Bug#1023166: golang-github-mdlayher-netlink: FTBFS on s390x

[Shengjing Zhu]

Source: golang-github-mdlayher-netlink
Version: 1.6.0-2
Severity: normal
X-Debbugs-Cc: z...@debian.org

Control: forwarded -1 https://github.com/mdlayher/netlink/issues/201

https://ci.debian.net/data/autopkgtest/testing/s390x/g/golang-github-mdlayher-netlink/27674954/log.gz

It's better to have it fixed, so this package can get autopkgtest bonus for
testing migration.

Bug#1010248: ITP: wlgreet raw wayland greeter for greetd

[duck]

Quack,

On 2022-10-31 05:35, Johannes Schauer Marin Rodrigues wrote:

greetd is packaged and even in testing already. Any status update on 
wlgreet?


There's several layers of dependencies that needed packaging and going 
through NEW took a while.
Now I'm dealing with owned-ttf-parser and after some requested changes I 
hit some potential licensing issues and I'm checking this with the 
ftpmasters.

After that rusttype can be built and need to go through NEW.
Then I can finally upload wlgreet.

Sorry it's taking so much time.
\_o<

--
Marc Dequènes

Bug#1018225: src:rust-rustls: fails to migrate to testing for too long: blocked by build dependency

[Peter Green]

src:rust-rustls: fails to migrate to testing for too long: blocked by build 
dependency


Specifically rust-async-std has taken some time to package, because of the 
large number
of dependencies. There has been effort on this front both by the rust team and 
by Jonas
who currently packages rust stuff outside the rust team because he doesn't like 
our
packaging workflow.

rust-async-std is now in unstable, however the autopkgtests for rust-criterion 
and
rust-async-std are failing. Jonas can you deal with these or do you want help?

Bug#1023161: RFS: libghc-filesystem/1.15.12-1 [ITP] -- Implementation of C++17 std::filesystem for C++11-20

[Ben Westover]

Hello,

On 10/30/22 9:17 PM, Adam Borowski wrote:
> # While ghc usually refers to Haskell packages, this package using the
> # namespace ghc isn't related to Haskell; according to the upstream, it
> # stands for "gulrak's helper classes".
> wrong-section-according-to-package-name
> `
>
> Is there a reason you picked that specific name?  Unlike some other
> languages, there's no convention to name C++ packages after their
> internal namespace, and this particular one clashes with Haskell,
> confusing both machines and humans.

No reason other than I don't know how C++ libraries/namespaces work and
this is only my second time ever packaging a C++ library. What should I
name it instead, libfilesystem?

Thanks,
--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1004421: ITS: cadaver

[Arnaud Rebillout]

Hi Hugh,

On 31/10/2022 06:23, Hugh McMaster wrote:

Hi Sebastian and Arnaud,

I've been working with upstream [1] to fix several issues in cadaver,
particularly its inability to regenerate its build system from source,
which is a major issue.

I'm pleased to report that we have a new upstream version, 0.24.

I believe Arnaud has taken over as maintainer but wanted to inform you
both of the new version.

Please let me know if you need any help with package maintenance. In
particular, this new version is a good opportunity to switch to dh
format in d/rules.

Bugs fixed by this upstream release include 605121 [2], 879882 [3] and
949059 [4].

Hugh

[1] https://github.com/notroj/cadaver
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605121
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879882
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949059


I will look into that and hopefully upload this new version in Debian 
this week.


Thanks for the ping and all the details, it's really helpful!

Cheers

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1023161: RFS: libghc-filesystem/1.15.12-1 [ITP] -- Implementation of C++17 std::filesystem for C++11-20

[Adam Borowski]

On Sun, Oct 30, 2022 at 09:35:57PM +, Ben Westover wrote:
>  * Package name : libghc-filesystem
>Version  : 1.15.12-1
>Upstream contact : Steffen Schümann 
>  * URL  : https://github.com/gulrak/filesystem

>  libghc-filesystem (1.15.12-1) unstable; urgency=medium
>  .
>* Initial Package (Closes: #1023160)

.--[ debian/lintian-overrides ]
# While ghc usually refers to Haskell packages, this package using the
# namespace ghc isn't related to Haskell; according to the upstream, it
# stands for "gulrak's helper classes".
wrong-section-according-to-package-name
`

Is there a reason you picked that specific name?  Unlike some other
languages, there's no convention to name C++ packages after their
internal namespace, and this particular one clashes with Haskell,
confusing both machines and humans.


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

Bug#1023085: firmware-iwlwifi: fails to load on Wireless-AC 9260

[Ash Joubert]

Failed firmware load with 20220913-1:
Oct 30 16:15:00 ripley kernel: iwlwifi :01:00.0: loaded firmware 
version 46.9d0122c0.0 9260-th-b0-jf-b0-46.ucode op_mode iwlmvm


Successful firmware load with 20210818-1:
Oct 30 16:31:34 ripley kernel: iwlwifi :01:00.0: loaded firmware 
version 46.6b541b68.0 9260-th-b0-jf-b0-46.ucode op_mode iwlmvm


(Note that the package description for firmware-iwlwifi 20220913-1 has 
not been updated and still references the 20210818-1 version 46.6b541b68.0)


Please ignore the "failed to load iwl-debug-yoyo.bin" messages which are 
cosmetic and not relevant.


lspci:
01:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)

Hardware:
Asus PCE-AC58BT PCIE adapter containing an Intel 9260 card, installed in 
an Asus H11OI-PLUS motherboard (H110 chipset) with a Kaby Lake (7th Gen) 
i7 7700.


--
Ash Joubert (they/them) 
Director / Game Developer
Transient Software Limited 
New Zealand

Bug#1023165: RFS: libtomlplusplus/3.2.0-1 [ITP] -- TOML config file parser and serializer for C++17

[Ben Westover]

Package: sponsorship-requests
Severity: wishlist
Control: block 1023164 by -1

Dear mentors,

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

 * Package name : libtomlplusplus
   Version  : 3.2.0-1
   Upstream contact : Mark Gillard 
 * URL  : https://marzer.github.io/tomlplusplus
 * License  : Expat
 * Vcs  : https://salsa.debian.org/BenTheTechGuy/libtomlplusplus
   Section  : libs

The source builds the following binary packages:

  libtomlplusplus-dev - TOML config file parser/serializer for C++17 -
development files

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/libt/libtomlplusplus/libtomlplusplus_3.2.0-1.dsc

Changes for the initial release:

 libtomlplusplus (3.2.0-1) unstable; urgency=medium
 .
   * Initial Package (Closes: #1023164)

Regards,
--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1023164: ITP: libtomlplusplus -- TOML config file parser and serializer for C++17

[Ben Westover]

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

* Package name: libtomlplusplus
  Version : 3.2.0
  Upstream Author : Mark Gillard 
* URL : https://marzer.github.io/tomlplusplus
* License : Expat
  Programming Lang: C++
  Description : TOML config file parser and serializer for C++17

toml++ is an optionally header-only TOML parser and serializer for
C++17, plus some C++20 features where available, that also supports
serializing to JSON and YAML and has proper UTF-8 handling including
BOM. It doesn't require RTTI and works with or without exceptions.

I am packaging this library because Prism Launcher depends on it. I do
not plan to maintain this package inside a team unless one expresses
interest. I'll need a sponsor for the initial upload as I am only a DM.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1023163: calibre: No module named 'PyQt6.uic'

[Leonard Lausen]

Package: calibre
Version: 6.7.1+dfsg-1
Severity: normal
Tags: patch
X-Debbugs-Cc: leon...@lausen.nl

Dear Maintainer,

opening Calibre, clicking the arrow next to "Convert books" and selecting
"Create a catalog [...]" triggers "No module named 'PyQt6.uic'" due to the
missing dependency on pyqt6-dev-tools. Once installing pyqt6-dev-tools on my
system, "Create a catalog [...]" no longer triggers the exception. Please
include it as dependency of the calibre package.

calibre, version 6.7.1
ERROR: Unhandled exception: ModuleNotFoundError:No module named 
'PyQt6.uic'

calibre 6.7.1  embedded-python: False
Linux-5.19.1-stb-cbq+-aarch64-with-glibc2.35 Linux ('64bit', 'ELF')
('Linux', '5.19.1-stb-cbq+', '#3 SMP PREEMPT Wed Aug 17 02:45:48 UTC 2022')
Python 3.10.8
Interface language: None
Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/actions/catalog.py", line 51, in 
generate_catalog
ret = generate_catalog(self.gui, dbspec, ids, self.gui.device_manager,
  File "/usr/lib/calibre/calibre/gui2/tools.py", line 328, in generate_catalog
d = Catalog(parent, dbspec, ids, db)
  File "/usr/lib/calibre/calibre/gui2/dialogs/catalog.py", line 28, in __init__
from PyQt6.uic import compileUi
ModuleNotFoundError: No module named 'PyQt6.uic'


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.19.1-stb-cbq+ (SMP w/8 CPU threads; PREEMPT)
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)

Versions of packages calibre depends on:
ii  calibre-bin6.7.1+dfsg-1
ii  fonts-liberation2  2.1.5-1
ii  libjpeg-turbo-progs1:2.1.2-1+b1
ii  libjxr-tools   1.2~git20170615.f752187-5
ii  libqt6webenginecore6-bin   6.3.1+dfsg2-13
ii  optipng0.7.7-2+b1
ii  poppler-utils  22.08.0-2.1
ii  python33.10.6-1
ii  python3-apsw   3.39.2.0-1
ii  python3-bs44.11.1-2
ii  python3-chm0.8.6-3+b2
ii  python3-css-parser 1.0.8-1
ii  python3-cssselect  1.1.0+ds-4
ii  python3-dateutil   2.8.2-1
ii  python3-feedparser 6.0.8-2
ii  python3-html2text  2020.1.16-2
ii  python3-html5-parser   0.4.10-6
ii  python3-html5lib   1.1-3
ii  python3-jeepney0.8.0-1
ii  python3-lxml   4.9.1-1+b1
ii  python3-markdown   3.4.1-2
ii  python3-mechanize  1:0.4.8+pypi-4
ii  python3-msgpack1.0.3-1+b1
ii  python3-netifaces  0.11.0-1+b2
ii  python3-pil9.2.0-1+b1
ii  python3-pkg-resources  65.5.0-1
ii  python3-py7zr  0.11.3+dfsg-4
ii  python3-pycryptodome   3.11.0+dfsg1-3+b1
ii  python3-pygments   2.12.0+dfsg-2
ii  python3-pyparsing  3.0.7-2
ii  python3-pyqt6  6.4.0-1
ii  python3-pyqt6.qtquick  6.4.0-1
ii  python3-pyqt6.qtsvg6.4.0-1
ii  python3-pyqt6.qtwebengine  6.4.0-1
ii  python3-pyqt6.sip  13.4.0-2
ii  python3-regex  0.1.2020-1+b1
ii  python3-routes 2.5.1-3
ii  python3-speechd0.11.3-2
ii  python3-zeroconf   0.39.2-1
ii  python3.10 3.10.8-1
ii  qt6-qpa-plugins6.3.1+dfsg-10
ii  xdg-utils  1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.2.1-2
ii  python3-ipython8.5.0-1
ii  qt6-wayland6.3.1-2
ii  udisks22.9.4-3+b1

Versions of packages calibre suggests:
pn  python3-openssl   
pn  python3-unrardll  

-- no debconf information

Bug#1022921: wine: broken packages after running dist-upgrade

[Zebediah Figura]

(Resending with reply-all, sorry...)

On 10/28/22 07:36, Stephen Kitt wrote:

Hi Tobias,

On Thu, 27 Oct 2022 17:53:29 +0200, Tobias Koeck  wrote:

unfortunately the system installed or wanted to install the newer
version after running.

apt-get dist-upgrade -t bullseye-backports


This is generally a bad idea, backports repositories shouldn’t be enabled
globally for upgrades. However that’s not the problem here...


  libwine : Depends: libz-mingw-w64 (>= 1.2.11+dfsg-4) but 1.2.11+dfsg-2 is
to be installed


Phil, wine’s debian/control hard-codes the above version as a minimum
requirement on libz-mingw-w64, but there is no satisfactory version available
in stable or backports. Presumably Wine needs a version of the libz DLL with
no GCC dependencies, so we’d have to backport libz-mingw-w64 too. I can take
care of that this weekend.


Hi all,

In wine 6.23 we introduced a mechanism to allow linking to external
shared-library versions of various packages. It's described in more
detail at [1], but I'd like to note that it can be done while linking to
DLLs with GCC dependencies, and also that it can be done without needing
to patch the source (as is currently done in the Debian package). The
basic idea is to use the --with-system-dllpath configure argument, i.e.
something like the following:

   configure
--with-system-dllpath=/usr/x86_64-w64-mingw32/lib/:/usr/lib/gcc/x86_64-w64-mingw32/10-win32/

This will automatically detect most libraries, including zlib, if MinGW
pkg-config is available at build time, but you can also manually specify
the compiler and linker flags, with ZLIB_PE_CFLAGS and ZLIB_PE_LIBS.

I hope this information is useful.

--Zeb

[1] https://lists.debian.org/debian-wine/2022/04/msg00014.html

Bug#1023123: linux-image-5.19.0-1-arm64: RPi3 fails to boot when headless

[Diederik de Haas]

Control: found -1 5.19.6-1
Control: severity -1 important
Control: tag -1 moreinfo

On 30 Oct 2022 13:24:55 +0100 Jan Huijsmans  wrote:
> Package: linux-image-5.19.0-1-arm64
> Severity: critical
> Justification: breaks the whole system

Only affecting RPi3 in certain conditions, thus lowering severity.
Also a factor is https://bugs.debian.org/984873 and 
https://bugs.debian.org/984873 where the same bug submitter did not respond to 
questions for more info, probably due to email bounces.


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

Bug#1022921: wine: broken packages after running dist-upgrade

[Phil Morrell]

Control: tags -1 +moreinfo

On Thu, Oct 27, 2022 at 05:53:29PM +0200, Tobias Koeck wrote:
> Version: 5.0.3-3
> 
> apt-get dist-upgrade -t bullseye-backports
> 
> Now the old one doesn't work, too.

Hi Tobias,

The bts isn't normally used for backports (sadly), and doing a
dist-upgrade isn't exactly recommended. That said however, exactly what
breakage are you seeing? wine/bullseye-backports is temporarily
uninstallable but apt recognises that and refuses to proceed, therefore
the current stable v5 should be unaffected. What's the symptom?


signature.asc
Description: PGP signature

Bug#1004421: ITS: cadaver

[Hugh McMaster]

Hi Sebastian and Arnaud,

I've been working with upstream [1] to fix several issues in cadaver,
particularly its inability to regenerate its build system from source,
which is a major issue.

I'm pleased to report that we have a new upstream version, 0.24.

I believe Arnaud has taken over as maintainer but wanted to inform you
both of the new version.

Please let me know if you need any help with package maintenance. In
particular, this new version is a good opportunity to switch to dh
format in d/rules.

Bugs fixed by this upstream release include 605121 [2], 879882 [3] and
949059 [4].

Hugh

[1] https://github.com/notroj/cadaver
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605121
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879882
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949059

Bug#1019604: Any plans to fix this?

[Ricardo Mones]

Hi maintainers,

Just wondering, after Claws Mail being removed from testing because of
this bug… is there any ongoing plan to fix this bug before freeze
starts or should I play safer and remove the bsfilter plugin from Claws
Mail to allow migration again?

thanks in advance for any response,
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «Don't look now, but there is a multi-legged creature on your
 shoulder.»


pgpt8ehG1_HyJ.pgp
Description: OpenPGP digital signature

Bug#1022921: wine: broken packages after running dist-upgrade

[Phil Morrell]

On Fri, Oct 28, 2022 at 02:36:06PM +0200, Stephen Kitt wrote:
> >  libwine : Depends: libz-mingw-w64 (>= 1.2.11+dfsg-4) but 1.2.11+dfsg-2 is
> > to be installed
> 
> Phil, wine’s debian/control hard-codes the above version as a minimum
> requirement on libz-mingw-w64, but there is no satisfactory version available
> in stable or backports. Presumably Wine needs a version of the libz DLL with
> no GCC dependencies, so we’d have to backport libz-mingw-w64 too. I can take
> care of that this weekend.

Indeed, this is the root cause of wine/bullseye-backports
uninstallability and one I didn't notice until after it passed NEW
because it's only in the binary constraints (4c4b59b439b3). I am curious
how a wine built against +dfsg-2 but linked against +dfsg-4 would
function correctly, do you know of a simple test case?

I see you followed through with your plan so thank you for the fixing
upload, I would have had to request a sponsor anyhow.


signature.asc
Description: PGP signature

Bug#1023162: tome: Incompatible with intel soundcard

[alison]

Package: tome
Version: 2.41-ah~0.git.20200131 amd64
Severity: normal
X-Debbugs-Cc: alisonw4t...@gmail.com

Dear Maintainer,

I am running debian testing. After running `sudo apt update && sudo apt
upgrade`,
pulseaudio no longer recognized my soundcard.
`sudo aptitude full-upgrade` recommended that I remove tome. After doing so, I
was able to install a system library (libboost-filesystem1.74.0) that had been
held
in conflict with tome. Now, my sound works again.
It looks like a dependencies problem.


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

Kernel: Linux 6.0.0-2-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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tome depends on:
pn  libasan5   
pn  libboost-filesystem1.67.0  
pn  libboost-filesystem1.71.0  
pn  libboost-system1.67.0  
ii  libc6  2.35-4
ii  libgcc-s1 [libgcc1]12.2.0-7
ii  libglib2.0-0   2.74.1-1
ii  libgtk2.0-02.24.33-2
ii  libjansson42.14-2
ii  libncurses66.3+20220423-2
ii  libsdl-image1.21.2.12-13+b1
ii  libsdl-ttf2.0-02.0.11-6
ii  libsdl1.2debian1.2.15+dfsg2-8
ii  libstdc++6 12.2.0-7
ii  libtinfo6  6.3+20220423-2
ii  libubsan1  12.2.0-7
ii  libx11-6   2:1.8.1-2
ii  libxext6   2:1.3.4-1+b1

tome recommends no packages.

tome suggests no packages.

Bug#1023154: RFP: hypnotix -- IPTV player

[Fabio Fantoni]

Il 30/10/2022 20:20, Thomas Uhle ha scritto:

Package: wnpp
Severity: wishlist
X-Debbugs-CC: Debian Cinnamon Team 

* Package name    : hypnotix
  Version : 2.9
  Upstream Author : Linux Mint
* URL or Web page : https://github.com/linuxmint/hypnotix
* License : GPL-3+
  Description : IPTV player

Hypnotix is an application to watch TV by streaming from M3U sources.
It is primarily developed for the Cinnamon desktop in Linux Mint but 
could be used in any other desktop environment as well.


I don't use an IPTV, I tried shortly kodi but I am not used enough about 
this type of program.


It should be seen which others are packaged in debian besides kodi (I 
know only it) and if hypnotix has anything better than these to 
determine if it is worth adding hypnotix in debian.


can you tell something about?

I don't see strong links with cinnamon from a quick look (the dependency 
with xapp is minor) so it could be maintained by another team or 
maintainer as well (if anyone will want maintain it)




OpenPGP_signature
Description: OpenPGP digital signature

Bug#897916: group plugdev is deprecated

[Christoph Anton Mitterer]

Hey.

Just for the records and the case that this group should ever be
removed:

usbguard uses it as one mean of authorizing users.

So should there be any change, one should probably visit usbguard, too.


Cheers,
Chris.

Bug#1023151: xapps-common: Recommends unneeded gist instead of netcat

[Fabio Fantoni]

Il 30/10/2022 19:45, Thomas Uhle ha scritto:

Package: xapps-common
Version: 2.0.7-1
Severity: normal

Dear maintainers,

nothing in xapps-common needs gist to be installed. But the Python 
script /usr/share/xapps-common/bin/pastebin needs netcat to be 
installed instead. So could you please replace gist by netcat in 
debian/control.
Thanks for report, you right, upstream removed gist usage in 1.2.2 
(https://github.com/linuxmint/xapp/commit/f40a5376554c2675ec9ed1e4c45d30329a8a4c32) 
and added use of netcat but in debian package was missed, I'll fix it in 
next build.


Moreover, if there is a reason for putting the executable binaries in 
/usr/share/xapps-common/bin/ instead of /usr/bin/ (which is what 
upstream does), then you should also adapt the path in 
upload-system-info (line 7) from '/usr/bin/pastebin' to 
'/usr/share/xapps-common/bin/pastebin'.
I'll fix it in next build. Commit description 
(https://salsa.debian.org/cinnamon-team/xapp/-/commit/d68e7a9e9948e0b19505b82578641823fa1088e1) 
don't specify but I suppose was moved to avoid conflict to other 
possible similar script/binary (even if no other package in official 
repo have it for now) and I think is better keep it


Thank you in advance!

Best regards,

Thomas Uhle




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration

[Jérémy Lal]

Le dim. 30 oct. 2022 à 22:42, Jérémy Lal  a écrit :

>
>
> Le jeu. 20 oct. 2022 à 13:28, Jérémy Lal  a écrit :
>
>>
>>
>> Le jeu. 20 oct. 2022 à 13:09, Alper Nebi Yasak 
>> a écrit :
>>
>>> Package: sponsorship-requests
>>> Severity: wishlist
>>> X-Debbugs-Cc: Jérémy Lal 
>>> X-Debbugs-Cc: Hans-Cristoph Steiner 
>>> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "depthcharge-tools":
>>
>>
>> I'll be glad to review/upload it next week (my DD gnupg key is being
>> renewed).
>> If anyone can do it before, that'll be okay too.
>>
>>
> Everything seems to be fine with your package.
> It builds fine, is lintian-clean, copyright is ok, and best practices are
> observed.
>
> Since it's a python program, it would make more sense to team-maintain it
> in the python-team group.
> I cloned your repo to
> https://salsa.debian.org/python-team/packages/depthcharge-tools
>
> Now you need to request write access (developer role) to that repository.
> Please have a look at https://wiki.debian.org/Teams/PythonTeam/HowToJoin
>
> After that, debian/control should be modified to be:
> Maintainer: Alper Nebi Yasak 
>  , Debian Python Team 
> Vcs-Browser:
> https://salsa.debian.org/python-team/packages/depthcharge-tools
> Vcs-Git:
> https://salsa.debian.org/python-team/packages/depthcharge-tools.git
>

Also since python-team admins are busy, I've took the liberty to make the
changes,
slightly differently (see
https://salsa.debian.org/python-team/packages/depthcharge-tools),
and I uploaded your package to NEW.

Jérémy

>

Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration

[Jérémy Lal]

Le jeu. 20 oct. 2022 à 13:28, Jérémy Lal  a écrit :

>
>
> Le jeu. 20 oct. 2022 à 13:09, Alper Nebi Yasak 
> a écrit :
>
>> Package: sponsorship-requests
>> Severity: wishlist
>> X-Debbugs-Cc: Jérémy Lal 
>> X-Debbugs-Cc: Hans-Cristoph Steiner 
>> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "depthcharge-tools":
>
>
> I'll be glad to review/upload it next week (my DD gnupg key is being
> renewed).
> If anyone can do it before, that'll be okay too.
>
>
Everything seems to be fine with your package.
It builds fine, is lintian-clean, copyright is ok, and best practices are
observed.

Since it's a python program, it would make more sense to team-maintain it
in the python-team group.
I cloned your repo to
https://salsa.debian.org/python-team/packages/depthcharge-tools

Now you need to request write access (developer role) to that repository.
Please have a look at https://wiki.debian.org/Teams/PythonTeam/HowToJoin

After that, debian/control should be modified to be:
Maintainer: Alper Nebi Yasak 
 , Debian Python Team 
Vcs-Browser: https://salsa.debian.org/python-team/packages/depthcharge-tools
Vcs-Git: https://salsa.debian.org/python-team/packages/depthcharge-tools.git

Cheers,
Jérémy

Bug#1023161: RFS: libghc-filesystem/1.15.12-1 [ITP] -- Implementation of C++17 std::filesystem for C++11-20

[Ben Westover]

Package: sponsorship-requests
Severity: wishlist
Control: block 1023160 by -1

Dear mentors,

I am looking for a sponsor for my package "libghc-filesystem":

 * Package name : libghc-filesystem
   Version  : 1.15.12-1
   Upstream contact : Steffen Schümann 
 * URL  : https://github.com/gulrak/filesystem
 * License  : Expat
 * Vcs  :
https://salsa.debian.org/BenTheTechGuy/libghc-filesystem
   Section  : libs

The source builds the following binary packages:

  libghc-filesystem-dev - C++17 std::filesystem for C++11-20 -
development files

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

  https://mentors.debian.net/package/libghc-filesystem/

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

  dget -x
https://mentors.debian.net/debian/pool/main/libg/libghc-filesystem/libghc-filesystem_1.15.12-1.dsc

Changes for the initial release:

 libghc-filesystem (1.15.12-1) unstable; urgency=medium
 .
   * Initial Package (Closes: #1023160)

Regards,
--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021560: nbconvert NMU uploaded to DELAYED/5

[Paul Gevers]

Control: tags -1 pending patch

Dear maintainer(s),

I have just uploaded an NMU to fix two RC issues in nbconvert to 
DELAYED/5. Please let me know if I should delay or cancel the upload.


You can find my work in MR!3:
https://salsa.debian.org/python-team/packages/nbconvert/-/merge_requests/3

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023160: ITP: libghc-filesystem -- Implementation of C++17 std::filesystem for C++11-20

[Ben Westover]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: m...@benthetechguy.net
Owner: Ben Westover 
Severity: wishlist

* Package name: libghc-filesystem
  Version : 1.15.12
  Upstream Author : Steffen Schümann 
* URL : https://github.com/gulrak/filesystem
* License : Expat
  Programming Lang: C++
  Description : C++17 std::filesystem implementation for C++11-20

ghc::filesystem is a header-only std::filesystem compatible helper
library, based on the C++17 and C++20 specs, but implemented for C++11,
C++14, C++17 or C++20 (tightly following the C++17 standard with very
few documented exceptions).

I am packaging this library because Prism Launcher depends on it. I do
not plan to maintain this package inside a team unless one expresses
interest. I'll need a sponsor for the initial upload as I am only a DM.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#884009: firmware: failed to load pci errors in syslog

[Dmitry Baryshkov]

Package: firmware-atheros
Followup-For: Bug #884009

The ath10k/pre-cal-pci-:04:00.0.bin and
ath10k/cal-pci-:04:00.0.bin are optional files, which can provide
calibration data for the particular device. If these are the only errors
you observe, they can be safely ignored.

-- 
With best wishes
Dmitry


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

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

firmware-atheros depends on no packages.

firmware-atheros recommends no packages.

Versions of packages firmware-atheros suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Fri, Oct 28, 2022 at 03:49:52AM -0400, Thomas Dickey wrote:
> On Fri, Oct 28, 2022 at 08:51:50AM +0200, Andreas Tille wrote:
> > Package: xterm
> > Version: 375-1
> > Severity: important
> > 
> > Hi,
> > 
> > after upgrading from xterm 374-1 to 375-1 I get:
> > 
> > $ xterm
> > xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"
> > Segmentation fault
> > 
> > I guess this local setting is relevant:
> > 
> > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > *VT100.utf8Fonts.font: fixed
> > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> >
> > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*

for the record, xfonts-terminus includes all of these sizes.

> > here.  If I uncomment these settings xterm starts.  However, I think xterm 
> > should not
> 
> Is that "uncomment", or "comment"?
> 
> (the grep seems to indicate that the latter is meant)
> 
> > crash with segmentation fault when not finding some specified font.
> 
> agreed -

I've not been able to reproduce the problem, which I suspect is in
the error-recovery section of xterm's xtermLoadFont function.

Perhaps seeing the whole set of resources would help
(the output of "xrdb -query", too).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1020799: Transition: pkg-config to pkgconf: next steps

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-10-20 11:25:13 +0100, Andrej Shadura wrote:
> Hi all,
> 
> I’ve been rebuilding packages with pkgconf for the past couple of weeks, and 
> it looks very good so far:
> 
> http://pkgconf-migration.debian.net/
> 
> I have identified and resolved some issues, and most of the build failures 
> I’ve seen were not related to pkgconf itself, but were caused by external 
> factors and were usually present when packages were built as usual (missing 
> build dependencies, compiler errors etc).

Thanks for the update. Please go ahead with this change whenever you are
ready.

Cheers

> 
> The version of pkgconf package providing the pkg-config binary package has 
> been sitting in experimental for some time. I think I have tested the upgrade 
> process quite extensively, but it would still be great if someone else could 
> have a look. In any case, my plan is to upload it to unstable in about two 
> weeks time. I will then commence another round of rebuilds; meanwhile I will 
> be working on fixing issues I’ve already run into:
> 
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=andrewsh%40debian.org=pkgconf-rebuild-ftbfs
> 
> -- 
> Cheers,
>   Andrej
> 

-- 
Sebastian Ramacher

Bug#1010248: ITP: wlgreet raw wayland greeter for greetd

[Johannes Schauer Marin Rodrigues]

Hi Marc,

Quoting Marc Dequènes (2022-04-27 08:40:00)
> Greeter to be run under sway or similar. Note that cage is currently
> not supported due to it lacking wlr-layer-shell-unstable support.
> 
> This ITP is intended to be fulfilled once greetd is packaged, see 
> #1010247.

greetd is packaged and even in testing already. Any status update on wlgreet?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1023159: inkscape: crashes opening a pdf file

[Francesco Potortì]

Package: inkscape
Version: 1.1.2-3+b1
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

When opening the attached pdf, inkscape exit with an "internal error" message.

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 inkscape depends on:
ii  lib2geom1.1.0  1.2-1
ii  libatkmm-1.6-1v5   2.28.3-1
ii  libboost-filesystem1.74.0  1.74.0-17
ii  libc6  2.35-3
ii  libcairo2  1.16.0-6
ii  libcairomm-1.0-1v5 1.14.4-1
ii  libcdr-0.1-1   0.1.6-2+b1
ii  libdbus-glib-1-2   0.112-2
ii  libfontconfig1 2.13.1-4.5
ii  libfreetype6   2.12.1+dfsg-3
ii  libgc1 1:8.2.2-3
ii  libgcc-s1  12.2.0-3
ii  libgdk-pixbuf-2.0-02.42.9+dfsg-1
ii  libglib2.0-0   2.74.0-3
ii  libglibmm-2.4-1v5  2.66.5-1
ii  libgomp1   12.2.0-3
ii  libgsl27   2.7.1+dfsg-3+b1
ii  libgspell-1-2  1.12.0-1
ii  libgtk-3-0 3.24.34-3
ii  libgtkmm-3.0-1v5   3.24.7-1
ii  libharfbuzz0b  5.2.0-2
ii  libjpeg62-turbo1:2.1.2-1+b1
ii  liblcms2-2 2.13.1-1+b1
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3+b4
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libpangoft2-1.0-0  1.50.10+ds-1
ii  libpangomm-1.4-1v5 2.46.3-1
ii  libpng16-161.6.38-2
ii  libpoppler-glib8   22.08.0-2.1
ii  libpoppler118  22.02.0-3
ii  libpotrace01.16-2
ii  libreadline8   8.2-1
ii  librevenge-0.0-0   0.0.4-6+b1
ii  librsvg2-common2.54.5+dfsg-1
ii  libsigc++-2.0-0v5  2.10.8-1
ii  libsoup2.4-1   2.74.3-1
ii  libstdc++6 12.2.0-3
ii  libvisio-0.1-1 0.1.7-1+b2
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.8.1-2
ii  libxml22.9.14+dfsg-1+b1
ii  libxslt1.1 1.1.35-1
ii  python33.10.6-1
ii  zlib1g 1:1.2.11.dfsg-4.1

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4+b1
ii  fig2dev  1:3.2.8b-3
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b4
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.3
ii  libwmf-bin   0.2.12-5
ii  python3-lxml 4.9.1-1+b1
ii  python3-numpy1:1.21.5-1+b1
ii  python3-scour0.38.2-2

Versions of packages inkscape suggests:
ii  dia   0.97.3+git20220525-4
pn  inkscape-tutorials
ii  libsvg-perl   2.87-1
ii  pstoedit  3.78-2
pn  python3-uniconvertor  
ii  ruby  1:3.0+3.1

-- no debconf information



nuovo mod AA7 10_AA7_10 modello 27.05.2015.pdf
Description: Adobe PDF document

Bug#1022255: python-xarray breaks satpy autopkgtest

[Antonio Valentino]

It seems that the issue is related to an incompatibility between the new 
xarray and the current dask.


According to [1] an update of dask to 2022.10.0 should fix the issue.

[1] https://github.com/pytroll/satpy/issues/2248#issuecomment-1296325915

cheers
antonio


On Sat, 22 Oct 2022 21:36:41 +0200 Paul Gevers  wrote:

Source: python-xarray, satpy
Control: found -1 python-xarray/2022.10.0-1
Control: found -1 satpy/0.37.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


passfail
python-xarray  from testing2022.10.0-1
satpy  from testing0.37.1-1
all others from testingfrom testing

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

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


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

Paul

[1] https://qa.debian.org/excuses.php?package=python-xarray

https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/27389134/log.gz


--
Antonio Valentino

Bug#1023158: qt6-quicktimeline FTCBFS: does not pass QT_HOST_PATH

[Helmut Grohne]

Source: qt6-quicktimeline
Version: 6.3.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qt6-quicktimeline fails to cross build from source, because it does not
pass QT_HOST_PATH to cmake. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru qt6-quicktimeline-6.3.1/debian/changelog 
qt6-quicktimeline-6.3.1/debian/changelog
--- qt6-quicktimeline-6.3.1/debian/changelog2022-08-15 19:23:31.0 
+0200
+++ qt6-quicktimeline-6.3.1/debian/changelog2022-10-30 21:14:56.0 
+0100
@@ -1,3 +1,10 @@
+qt6-quicktimeline (6.3.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass QT_HOST_PATH. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 30 Oct 2022 21:14:56 +0100
+
 qt6-quicktimeline (6.3.1-2) unstable; urgency=medium
 
   [ Patrick Franz ]
diff --minimal -Nru qt6-quicktimeline-6.3.1/debian/rules 
qt6-quicktimeline-6.3.1/debian/rules
--- qt6-quicktimeline-6.3.1/debian/rules2021-11-17 22:21:04.0 
+0100
+++ qt6-quicktimeline-6.3.1/debian/rules2022-10-30 21:14:55.0 
+0100
@@ -4,6 +4,12 @@
 # Use already defined DEB_HOST_* variables.
 include /usr/share/dpkg/architecture.mk
 
+cmake_extra_args :=
+
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+cmake_extra_args += -DQT_HOST_PATH=/usr
+endif
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
@@ -11,7 +17,8 @@
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)
+   -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) \
+   $(cmake_extra_args)
 
 execute_after_dh_auto_install:
# Reproducible builds: remove build paths from .prl files

Bug#1023157: qt6-shadertools FTCBFS: does not pass QT_HOST_PATH and more

[Helmut Grohne]

Source: qt6-shadertools
Version: 6.3.1-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qt6-shadertools fails to cross build from source. The immediate failure
is missing QT_HOST_PATH. Then Qt6::qsb is missing. Fixing that involves
depending on the qsb tool, the relevant cmake files and setting
QT_HOST_PATH_CMAKE_DIR. Beyond that we need to request qsb despite doing
a cross build. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru qt6-shadertools-6.3.1/debian/changelog 
qt6-shadertools-6.3.1/debian/changelog
--- qt6-shadertools-6.3.1/debian/changelog  2022-10-01 21:27:40.0 
+0200
+++ qt6-shadertools-6.3.1/debian/changelog  2022-10-30 18:55:46.0 
+0100
@@ -1,3 +1,13 @@
+qt6-shadertools (6.3.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Pass QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR.
++ New cross build dependency on native qsb.
++ Do build tools when cross compiling.
+
+ -- Helmut Grohne   Sun, 30 Oct 2022 18:55:46 +0100
+
 qt6-shadertools (6.3.1-3) unstable; urgency=medium
 
   [ Lisandro Damián Nicanor Pérez Meyer ]
diff --minimal -Nru qt6-shadertools-6.3.1/debian/control 
qt6-shadertools-6.3.1/debian/control
--- qt6-shadertools-6.3.1/debian/control2022-10-01 21:21:43.0 
+0200
+++ qt6-shadertools-6.3.1/debian/control2022-10-30 18:55:46.0 
+0100
@@ -6,12 +6,14 @@
 Build-Depends: cmake (>= 3.24~),
debhelper-compat (= 13),
libgl1-mesa-dev,
+   libqt6shadertools6-dev:native ,
libvulkan-dev [linux-any],
ninja-build,
pkg-config,
pkg-kde-tools,
qt6-base-dev (>= 6.3.1+dfsg~),
qt6-base-private-dev (>= 6.3.1+dfsg~),
+   qt6-shader-baker ,
 Standards-Version: 4.6.1
 Homepage: https://www.qt.io/developers/
 Rules-Requires-Root: no
diff --minimal -Nru qt6-shadertools-6.3.1/debian/rules 
qt6-shadertools-6.3.1/debian/rules
--- qt6-shadertools-6.3.1/debian/rules  2022-10-01 21:22:41.0 +0200
+++ qt6-shadertools-6.3.1/debian/rules  2022-10-30 18:55:46.0 +0100
@@ -6,13 +6,23 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+cmake_extra_args :=
+
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+cmake_extra_args += \
+   -DQT_HOST_PATH=/usr \
+   -DQT_HOST_PATH_CMAKE_DIR=/usr/lib/$(DEB_BUILD_MULTIARCH)/cmake \
+   -DQT_BUILD_TOOLS_WHEN_CROSSCOMPILING=ON
+endif
+
 %:
dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja
 
 override_dh_auto_configure:
dh_auto_configure -- \
--log-level=STATUS \
-   -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)
+   -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) \
+   $(cmake_extra_args)
 
 execute_after_dh_auto_install:
# Reproducible builds: remove build paths from .prl files

Bug#755464: arp-scan: does not honour "mac-vendor.txt" properly

[roy hills]

I believe this issue is fixed in the latest upstream version of arp-scan which 
is git tag 1.9.8 on github.

mac-vendor.txt can now accept mac addresses as normal mac addresses with ":" or 
"-" separators and with the alphabetic characters in either upper or lower 
case. This allows you to paste mac addresses from arp-scan or ifconfig directly 
into mac.vendor.txt.

Note that there is now an IEEE oui assignment for 90:18:7c, so you would need 
to add a more specific entry to mac-vendor.txt, e.g.

90:18:7c:48:dd:dbVendor Details

Thanks.

Roy
--

Bug#1023156: haskell-gi-gtk FTBFS on armel

[Adrian Bunk]

Source: haskell-gi-gtk
Version: 3.0.38-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-gi-gtk=armel

...
[498 of 508] Compiling GI.Gtk.Objects   ( GI/Gtk/Objects.hs, 
dist-ghc/build/GI/Gtk/Objects.o, dist-ghc/build/GI/Gtk/Objects.dyn_o )
ghc: panic! (the 'impossible' happened)
  (GHC version 9.0.2:
GHC.Rename.Env.plusAvail
  constructTextTagJustificationSet 
UIManagerSetAddTearoffsMethodInfo{UIManagerSetAddTearoffsMethodInfo;}
  Call stack:
  CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Outputable.hs:1230:37 in 
ghc:GHC.Utils.Outputable
pprPanic, called at compiler/GHC/Types/Avail.hs:221:19 in 
ghc:GHC.Types.Avail

Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug

-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
...


haskell-gi-gtk has only once ever been built successfully on armel.
Unless someone has a better suggestion, my short-term Plan B would be
that I request the removal of haskell-gi-gtk and reverse dependencies
on armel.

Bug#1023155: lintian: vcs-field-has-unexpected-spaces false positive

[Bradford D. Boyle]

Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: bradford.d.bo...@gmail.com

Dear Maintainer,

Running lintian for a package that contains 'Vcs-Git' field with the
following value

https://github.com/greenplum-db/greenplum-db-for-debian.git -b main [gpdb]

results in the 'vcs-field-has-unexpected-spaces' tag being reported. If
I change the value to

https://github.com/greenplum-db/greenplum-db-for-debian.git [gpdb] -b main

the warning is not printed. According to the Debian Policy Manual
(S5.6.26)

> In the case of Git, the value must have the following syntax:
>
>  [ " -b "  ] [ " ["  "]" ]


with kindest regards,
--Bradford

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

Kernel: Linux 5.19.0-2-cloud-amd64 (SMP w/2 CPU threads; PREEMPT)
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 lintian depends on:
ii  binutils2.39-8
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.9+b1
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-9
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.11.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.45-1+b3
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-2
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.58-3
ii  liblist-utilsby-perl0.12-1
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.009-1+b2
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-1+b1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1+b1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.13-1+b2
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b4
ii  liburi-perl 5.16-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.0-1+b1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-4
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#995749: fixed in usbguard-notifier 0.0.6-1

[Christoph Anton Mitterer]

On Sun, 2022-10-30 at 19:00 +, Debian FTP Masters wrote:
>    * Initial packaging (Closes: #995749)

Awesome... thanks! :-)


Cheers,
Chris.

Bug#1023144: [Pkg-rust-maintainers] Bug#1023144: rust-coreutils FTBFS after textwrap update.

[Sylvestre Ledru]

Le 30/10/2022 à 18:18, Peter Michael Green a écrit :

Package: rust-coreutils
Version: 0.0.15-1
Severity: serious




cargo build  --features "arch base32 base64 basename basenc cat chcon 
chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir 
dircolors dirname du echo env expand expr factor false fmt fold 
groups hashsum head hostid hostname id install join kill link ln 
logname ls mkdir mkfifo mknod mktemp more mv nice nl nohup nproc 
numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink 
realpath relpath rm rmdir runcon seq shred shuf sleep sort split stat 
stdbuf sum sync tac tail tee test timeout touch tr true truncate 
tsort tty uname unexpand uniq unlink uptime users vdir wc who whoami 
yes" --release --no-default-features
error: failed to select a version for the requirement `textwrap = 
"^0.15"`

candidate versions found which didn't match: 0.16.0
location searched: directory source 
`/rust-coreutils-0.0.15/debian/cargo_registry` (which is replacing 
registry `crates-io`)

required by package `coreutils v0.0.15 (/rust-coreutils-0.0.15)`
perhaps a crate was updated and forgotten to be re-vendored?
make[2]: *** [GNUmakefile:279: build-coreutils] Error 101



it is broken for a while :)

And now, waiting for rust-procfs (in NEW)

Once this one is accepted, we should be fine!
Cheers
S

Bug#1023154: RFP: hypnotix -- IPTV player

[Thomas Uhle]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: Debian Cinnamon Team 

* Package name: hypnotix
  Version : 2.9
  Upstream Author : Linux Mint
* URL or Web page : https://github.com/linuxmint/hypnotix
* License : GPL-3+
  Description : IPTV player

Hypnotix is an application to watch TV by streaming from M3U sources.
It is primarily developed for the Cinnamon desktop in Linux Mint but could 
be used in any other desktop environment as well.

Bug#1023153: fq FTBFS: missing build dependencies?

[Adrian Bunk]

Source: fq
Version: 0.0.9-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=fq=0.0.9-1

...
 debian/rules binary-arch
dh binary-arch --builddirectory=_build --buildsystem=golang --with=golang
   dh_update_autotools_config -a -O--builddirectory=_build 
-O--buildsystem=golang
   dh_autoreconf -a -O--builddirectory=_build -O--buildsystem=golang
   dh_auto_configure -a -O--builddirectory=_build -O--buildsystem=golang
   dh_auto_build -a -O--builddirectory=_build -O--buildsystem=golang
cd _build && go install -trimpath -v -p 4 github.com/wader/fq
src/github.com/wader/fq/format/toml/toml.go:7:2: cannot find package 
"github.com/BurntSushi/toml" in any of:
/usr/lib/go-1.19/src/github.com/BurntSushi/toml (from $GOROOT)
/<>/_build/src/github.com/BurntSushi/toml (from $GOPATH)
src/github.com/wader/fq/format/crypto/hash.go:18:2: cannot find package 
"golang.org/x/crypto/md4" in any of:
/usr/lib/go-1.19/src/golang.org/x/crypto/md4 (from $GOROOT)
/<>/_build/src/golang.org/x/crypto/md4 (from $GOPATH)
src/github.com/wader/fq/format/crypto/hash.go:19:2: cannot find package 
"golang.org/x/crypto/sha3" in any of:
/usr/lib/go-1.19/src/golang.org/x/crypto/sha3 (from $GOROOT)
/<>/_build/src/golang.org/x/crypto/sha3 (from $GOPATH)
dh_auto_build: error: cd _build && go install -trimpath -v -p 4 
github.com/wader/fq returned exit code 1
make: *** [debian/rules:60: binary-arch] Error 25

Bug#1023152: src:jupyter-packaging: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: jupyter-packaging
Version: 0.12.2-2
Severity: serious
Control: close -1 0.12.3-1
Tags: sid bookworm pending
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:jupyter-packaging has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug.


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


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


I have 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.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021057: cp2k autopkgtest times outs on armel

[Paul Gevers]

Hi,

On 30-10-2022 10:27, Adrian Bunk wrote:

Could you try setting the timeout to 10 hours for cp2k on armel?


We don't have that flexibility. If the test can't run in a reasonable 
time (below 2:47h per stanza in d/t/control) on armel, please skip the 
test on armel until the infrastructure grows that option.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023151: xapps-common: Recommends unneeded gist instead of netcat

[Thomas Uhle]

Package: xapps-common
Version: 2.0.7-1
Severity: normal

Dear maintainers,

nothing in xapps-common needs gist to be installed. But the Python script 
/usr/share/xapps-common/bin/pastebin needs netcat to be installed instead. 
So could you please replace gist by netcat in debian/control.


Moreover, if there is a reason for putting the executable binaries in 
/usr/share/xapps-common/bin/ instead of /usr/bin/ (which is what upstream 
does), then you should also adapt the path in upload-system-info (line 7) 
from '/usr/bin/pastebin' to '/usr/share/xapps-common/bin/pastebin'.


Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-19-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xapps-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  python3  3.9.2-3
ii  python3-gi   3.38.0-2
ii  xdg-utils1.1.3-4.1

Versions of packages xapps-common recommends:
pn  gist  
ii  inxi  3.3.22-1-1~bpo11+1

xapps-common suggests no packages.

Bug#1021779: orage: eats events

[Nicolas Mora]

Hello,

On Sun, 23 Oct 2022 11:54:52 +0200 Yves-Alexis Perez 
wrote:



for some reason your reports never reached us so I've just seen this bug and
your investigation. My feeling is that this is actually
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021698 so it might be
interesting to check if it's fixed with 3.0.16-1.



If the bug comes from libical, I can confirm that it has been fixed in 
the last release 3.0.16-1 which is now on testing.


Can you check with the last packages if the bug is still present?

/Nicolas

Bug#967823: xfce4-panel: depends on deprecated GTK 2

[Akbarkhon Variskhanov]

Source: xfce4-panel
Source-Version: 4.15.4-1

Bug#1023150: haskell-hopenpgp FTBFS on 32bit: test hang

[Adrian Bunk]

Source: haskell-hopenpgp
Version: 2.9.8-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-hopenpgp=armel
https://buildd.debian.org/status/logs.php?pkg=haskell-hopenpgp=armhf
https://buildd.debian.org/status/logs.php?pkg=haskell-hopenpgp=i386

...
Linking dist-ghc/build/tests/tests ...
touch build-ghc-stamp
perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
-E 'check_recipe'
Running dh_listpackages
libghc-hopenpgp-dev
libghc-hopenpgp-prof
libghc-hopenpgp-doc
Running 1 test suites...
Test suite tests: RUNNING...
Tests
  Properties
(checked by QuickCheck)
  PKESK packet serialization-deserialization: OK (0.04s)
+++ OK, passed 100 tests.
  Signature packet serialization-deserialization: OK (0.11s)
+++ OK, passed 100 tests.
  UserId packet serialization-deserialization:OK (0.01s)
+++ OK, passed 100 tests.
  Unit Tests
Serialization group
  01-006.public_key:  OK
  02-013.user_id: OK
  03-002.sig: OK
  04-012.ring_trust:  OK
  05-002.sig: OK
  06-012.ring_trust:  OK
  07-002.sig: OK
  08-012.ring_trust:  OK
  09-002.sig: OK
  10-012.ring_trust:  OK
  11-002.sig: OK
  12-012.ring_trust:  OK
  13-014.public_subkey:   OK
  14-002.sig: OK
  15-012.ring_trust:  OK
  16-006.public_key:  OK
  17-002.sig: OK
  18-012.ring_trust:  OK
  19-013.user_id: OK
  20-002.sig: OK
  21-012.ring_trust:  OK
  22-002.sig: OK
  23-012.ring_trust:  OK
  24-014.public_subkey:   OK
  25-002.sig: OK
  26-012.ring_trust:  OK
  27-006.public_key:  OK
  28-002.sig: OK
  29-012.ring_trust:  OK
  30-013.user_id: OK
  31-002.sig: OK
  32-012.ring_trust:  OK
  33-002.sig: OK
  34-012.ring_trust:  OK
  35-006.public_key:  OK
  36-013.user_id: OK
  37-002.sig: OK
  38-012.ring_trust:  OK
  39-002.sig: OK
  40-012.ring_trust:  OK
  41-017.attribute:   OK
  42-002.sig: OK
  43-012.ring_trust:  OK
  44-014.public_subkey:   OK
  45-002.sig: OK
  46-012.ring_trust:  OK
  47-005.secret_key:  OK
  48-013.user_id: OK
  49-002.sig: OK
  50-012.ring_trust:  OK
  51-007.secret_subkey:   OK
  52-002.sig: OK
  53-012.ring_trust:  OK
  54-005.secret_key:  OK
  55-002.sig:   

Bug#1023149: pandoc FTBFS on i386

[Adrian Bunk]

Source: pandoc
Version: 2.17.1.1-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian Haskell Group 


https://buildd.debian.org/status/logs.php?pkg=pandoc=2.17.1.1-1%2Bb3

...
[193 of 214] Compiling Text.Pandoc.Readers.EPUB

src/Text/Pandoc/Readers/EPUB.hs:79:40: error:
• Local identifier ‘FilePath’ used as a type
• In the type signature:
parseSpineElem :: PandocMonad m =>
  FilePath -> (FilePath, MimeType) -> m Pandoc
  In an equation for ‘archiveToEPUB’:
  archiveToEPUB os archive
= do (root, content) <- getManifest archive
 (coverId, meta) <- parseMeta content
 (cover, items) <- parseManifest content coverId
 
where
os'
  = os
  {readerExtensions = enableExtension
Ext_raw_html (readerExtensions os)}
parseSpineElem ::
  PandocMonad m => FilePath -> (FilePath, MimeType) -> m Pandoc
parseSpineElem (normalise -> r) (normalise -> path, mime)
  = do doc <- mimeToReader mime r path
   
mimeToReader ::
  PandocMonad m => MimeType -> FilePath -> FilePath -> m Pandoc

   |
79 | parseSpineElem :: PandocMonad m => FilePath -> (FilePath, MimeType) -> 
m Pandoc
   |

src/Text/Pandoc/Readers/EPUB.hs:84:50: error:
• Local identifier ‘FilePath’ used as a type
• In the type signature:
mimeToReader :: PandocMonad m =>
MimeType -> FilePath -> FilePath -> m Pandoc
  In an equation for ‘archiveToEPUB’:
  archiveToEPUB os archive
= do (root, content) <- getManifest archive
 (coverId, meta) <- parseMeta content
 (cover, items) <- parseManifest content coverId
 
where
os'
  = os
  {readerExtensions = enableExtension
Ext_raw_html (readerExtensions os)}
parseSpineElem ::
  PandocMonad m => FilePath -> (FilePath, MimeType) -> m Pandoc
parseSpineElem (normalise -> r) (normalise -> path, mime)
  = do doc <- mimeToReader mime r path
   
mimeToReader ::
  PandocMonad m => MimeType -> FilePath -> FilePath -> m Pandoc

   |
84 | mimeToReader :: PandocMonad m => MimeType -> FilePath -> FilePath -> m 
Pandoc
   |  
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
...


The patch below workarounds the issue, which indicates that it might
be a bug in the compiler and not a problem in pandoc?

Short-term it might even be good enough to unblock migration of several
packages to testing.

--- debian/rules.old2022-10-30 17:52:59.643347191 +
+++ debian/rules2022-10-30 17:54:14.347251214 +
@@ -192,6 +192,10 @@
 DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-optc--param 
-optcggc-min-expand=10 -O0"
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU), i386))
+DEB_SETUP_GHC_CONFIGURE_ARGS += --ghc-options="-O0"
+endif
+
 DEB_SETUP_GHC_CONFIGURE_ARGS += $(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),,-ftests)
 
 DEB_INSTALL_DOCS_ALL += README.md

Bug#1023148: desktop-base: missing links in joy-inksplat-theme

[Thomas Uhle]

Package: desktop-base
Version: 11.0.3
Severity: important

Dear maintainers,

via /etc/alternatives, 
/usr/share/images/desktop-base/login-background.svg links to 
/usr/share/desktop-base/active-theme/login/background.svg and 
/usr/share/images/desktop-base/desktop-grub.png links to 
/usr/share/desktop-base/active-theme/grub/grub-4x3.png by default.


Now if I would switch desktop-theme to joy-inksplat-theme, both links 
are no longer valid because of these two missing links:


/usr/share/desktop-base/joy-inksplat-theme/grub -> ../joy-theme/grub
/usr/share/desktop-base/joy-inksplat-theme/login -> ../joy-theme/login

Could you please add these links (similar to 
/usr/share/desktop-base/joy-inksplat-theme/lockscreen) so that 
joy-inksplat-theme could be used like all the other themes without 
separately setting /etc/alternatives/desktop-login-background and 
/etc/alternatives/desktop-grub as well.


Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-19-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages desktop-base depends on:
ii  fonts-quicksand  0.2016-2.1
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages desktop-base recommends:
pn  plymouth-label  

Versions of packages desktop-base suggests:
ii  xfce4  4.16

Bug#967824: xfce4-smartbookmark-plugin: depends on deprecated GTK 2

[Akbarkhon Variskhanov]

Source: xfce4-smartbookmark-plugin
Source-Version: 0.5.2-1

Build-Depends on libgtk2.0-dev was dropped in xfce4-smartbookmark-plugin 0.5.2-1

Bug#1022926: transition: glibc 2.36

[Aurelien Jarno]

On 2022-10-30 17:10, Sebastian Ramacher wrote:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/glibc-2.36.html
> Control: tags -1 moreinfo
> 
> On 2022-10-27 21:36:11 +0200, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.36. It has been
> > available in experimental for a bit more than one month and does not
> > have any known major issue. It has been built successfully on all
> > release architectures and many ports architectures. A few issues found
> > through the autopkgtest pseudo excuses for experimental have been fixed.
> > The remaining ones are due to britney bugs, broken autopkgtest or
> > packages parts of the transition.
> > 
> > As glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition. Here is the corresponding ben file:
> > 
> >   title = "glibc";
> >   is_affected = .depends ~ /libc[0-9.]* \(< >   is_good = .depends ~ /libc[0-9.]* \(<< 2.37\)/;
> >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> > 
> > In addition a few new symbols have been added that might prevent a few
> > other packages to migrate to testing until glibc migrates if they pick
> > up the new symbols, however those are really limited in this version and
> > mostly linked to new filesystem, processes or random functions, so
> > unlikely to be massively used by default.
> > 
> > Note that this version builds with GCC 12 instead of GCC 11, so it is a
> > prerequisite for not shipping bookworm with GCC 11.
> 
> Speaking of GCC 12 … #1022991 seems to have a first patch available
> upstream. Is there any chance that we could start this transition
> together with a fix for that bug?

I would not say we have patch yet. I posted a first patch on the mailing
list yesterday [1], and we have two epidermic answers from both sides
("Why this patch is approved?" or "So MIPS ABI idiocrasies strike
again"). One come with a proposal and another one with a partial patch.
So that's 3 different options in total. I am also worried that the
problem could be more widespread as there is a claim that clock_adjtime
is broken on all 64bit system.

So IMHO, we should just wait that things calm done, and that people
really try to understand the problem, its consequences and how to fix
it, instead of just proposing random patches.

But once we have something acceptable, I am find including it either in
a 2.35 upload or a 2.36 one, both are fine to me.

Regards
Aurelien

[1] https://sourceware.org/pipermail/libc-alpha/2022-October/143049.html

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

Bug#1023147: python3-asdf: ships /usr/lib/python3/dist-packages/docs/Makefile etc.

[Andreas Beckmann]

Package: python3-asdf
Version: 2.13.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed ships documentation build systems
and generically named files under /usr/lib/python3/dist-packages/docs/,
causing file conflicts with other packages doing the same mistake.

Looking at the file list, I find the following badly placed files, not all
of them cause file conflicts:

/usr/lib/python3/dist-packages/compatibility_tests
/usr/lib/python3/dist-packages/compatibility_tests/assert_file_correct.py
/usr/lib/python3/dist-packages/compatibility_tests/common.py
/usr/lib/python3/dist-packages/compatibility_tests/generate_file.py
/usr/lib/python3/dist-packages/compatibility_tests/test_file_compatibility.py

If these modules really need to be shipped, they need to be in some
package specific directory (i.e. something containing asdf).

/usr/lib/python3/dist-packages/docs
/usr/lib/python3/dist-packages/docs/Makefile
/usr/lib/python3/dist-packages/docs/_static
/usr/lib/python3/dist-packages/docs/_static/logo.ico
/usr/lib/python3/dist-packages/docs/_static/logo.pdf
/usr/lib/python3/dist-packages/docs/_static/logo.png
/usr/lib/python3/dist-packages/docs/asdf
/usr/lib/python3/dist-packages/docs/asdf/CODE_OF_CONDUCT.md
/usr/lib/python3/dist-packages/docs/asdf/arrays.rst
/usr/lib/python3/dist-packages/docs/asdf/asdf_tool.rst
/usr/lib/python3/dist-packages/docs/asdf/changes.rst
/usr/lib/python3/dist-packages/docs/asdf/citation.rst
/usr/lib/python3/dist-packages/docs/asdf/config.rst
/usr/lib/python3/dist-packages/docs/asdf/contributing.rst
/usr/lib/python3/dist-packages/docs/asdf/developer_api.rst
/usr/lib/python3/dist-packages/docs/asdf/developer_overview.rst
/usr/lib/python3/dist-packages/docs/asdf/developer_versioning.rst
/usr/lib/python3/dist-packages/docs/asdf/extending
/usr/lib/python3/dist-packages/docs/asdf/extending/compressors.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/converters.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/extensions.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/legacy.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/manifests.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/resources.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/schemas.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/uris.rst
/usr/lib/python3/dist-packages/docs/asdf/extending/use_cases.rst
/usr/lib/python3/dist-packages/docs/asdf/features.rst
/usr/lib/python3/dist-packages/docs/asdf/install.rst
/usr/lib/python3/dist-packages/docs/asdf/overview.rst
/usr/lib/python3/dist-packages/docs/asdf/user_api.rst
/usr/lib/python3/dist-packages/docs/asdf/using_extensions.rst
/usr/lib/python3/dist-packages/docs/conf.py
/usr/lib/python3/dist-packages/docs/index.rst
/usr/lib/python3/dist-packages/docs/make.bat

Documentation belongs into /usr/share/doc/$PACKAGE, and the build system
is probaby not needed at all.


Andreas

Bug#947264: lintian: overly generic file name: /usr/lib/python3/dist-packages/examples/README.txt

[Andreas Beckmann]

Followup-For: Bug #947264

Another example for shipping arbitrary non-python-modules with generic
names under /usr/lib/python3/dist-packages/ is python3-asdf 2.13.0-1:

/usr/lib/python3/dist-packages/docs
/usr/lib/python3/dist-packages/docs/Makefile
/usr/lib/python3/dist-packages/docs/_static
/usr/lib/python3/dist-packages/docs/_static/logo.ico
/usr/lib/python3/dist-packages/docs/_static/logo.pdf
/usr/lib/python3/dist-packages/docs/_static/logo.png
/usr/lib/python3/dist-packages/docs/asdf
/usr/lib/python3/dist-packages/docs/asdf/*.md
/usr/lib/python3/dist-packages/docs/asdf/*.rst
/usr/lib/python3/dist-packages/docs/conf.py
/usr/lib/python3/dist-packages/docs/index.rst
/usr/lib/python3/dist-packages/docs/make.bat


Andreas

Bug#1007097:

[Yuxuan Wang]

Oops sorry I didn't see the previous replies likely because Gmail sent them
to spam.

re Seth: it's only a typo in bug report

re James: I do not have that in my .psk config file

The issue came back again after I replaced my home router. I have none of
the following configs (so they should all be default):

* AddressRandomization in /etc/iwd/main.conf
* EnableNetworkConfiguration in /etc/iwd/main.conf
* AlwaysRandomizeAddress in /var/lib/iwd/.psk

But for some reason the mac address is always randomized. Also might be
related, that the WPA3 personal password I provided seem to not work as
well when that happens.

I do have iwd+wpasupplicant+networkmanager all installed, maybe there's a
conflict between iwd and wpasupplicant? (they are not marked as conflicted
in apt) I uninstalled iwd and after reboot it worked (so
networkmanager+wpasupplicant seem to work). I did not try to uninstall
wpasupplicant and keep iwd, though.

Bug#1023146: img2pdf: switch to libgs-common

[Sebastian Ramacher]

Package: img2pdf
Version: 0.4.4-2
Severity: important
Tags: sid bookworm
X-Debbugs-Cc: sramac...@debian.org

img2pdf depends on libgs9-common for the ICC profiles provide by
ghostscript. Those file moved to libgs-common and libgs9-common is now a
transitional package. Please switch the dependency to libgs-common.

Cheers
-- 
Sebastian Ramacher

Bug#1022926: transition: glibc 2.36

[Adrian Bunk]

On Sun, Oct 30, 2022 at 05:10:13PM +0100, Sebastian Ramacher wrote:
>...
> Speaking of GCC 12 … #1022991 seems to have a first patch available
> upstream. Is there any chance that we could start this transition
> together with a fix for that bug?

IMHO it would be better to have 2.35 uploaded with a one-line fix/revert 
ASAP to have everything waiting behind gcc-12 for testing migration
unblocked. The 2.36 transition could then start a few hours or weeks later.

> Cheers

cu
Adrian

Bug#1023145: clickhouse: unit test unit_tests_dbms hangs.

[Tobias Frost]

Source: clickhouse
Version: 18.16.1+ds-7.2
Severity: important

In the test upload to expermential (and local), the
unit test unit_tests_dbms hangs.
It takes 100% CPU but never completes.

For the NMU I'm preparing I'll disable this test, but
I will leave this bug open.

-- 
tobi


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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


signature.asc
Description: PGP signature

Bug#1023144: rust-coreutils FTBFS after textwrap update.

[Peter Michael Green]

Package: rust-coreutils
Version: 0.0.15-1
Severity: serious




cargo build  --features "arch base32 base64 basename basenc cat chcon 
chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir 
dircolors dirname du echo env expand expr factor false fmt fold groups 
hashsum head hostid hostname id install join kill link ln logname ls 
mkdir mkfifo mknod mktemp more mv nice nl nohup nproc numfmt od paste 
pathchk pinky pr printenv printf ptx pwd readlink realpath relpath rm 
rmdir runcon seq shred shuf sleep sort split stat stdbuf sum sync tac 
tail tee test timeout touch tr true truncate tsort tty uname unexpand 
uniq unlink uptime users vdir wc who whoami yes" --release 
--no-default-features

error: failed to select a version for the requirement `textwrap = "^0.15"`
candidate versions found which didn't match: 0.16.0
location searched: directory source 
`/rust-coreutils-0.0.15/debian/cargo_registry` (which is replacing 
registry `crates-io`)

required by package `coreutils v0.0.15 (/rust-coreutils-0.0.15)`
perhaps a crate was updated and forgotten to be re-vendored?
make[2]: *** [GNUmakefile:279: build-coreutils] Error 101

Bug#1022104: peek: Fail to record as mp4/webm: ffmpeg: No such process

[Bernhard Übelacker]

Hello Shengjing Zhu,
I tried to collect some more information for the maintainer,
by running peek in a minimal VM.

There I got the same error message "default: No such process".

After a search I received this information [1] where it is proposed
to install pulseaudio.

And indeed the parameter "-f pulse -i default" seems to
direct ffmpeg to record from pulseaudio.
And after installing it (and starting off pulseaudio manually
in my minimal jwm environment) recording got further
and could create successfully a file.

Probably this is also causing the fault at your side?

Kind regards,
Bernhard


[1] 
https://superuser.com/questions/1487109/trying-to-stream-to-youtube-default-no-such-process

(gdb) bt
#0  print_error (filename=filename@entry=0x7fffe625 "default", 
err=err@entry=-3) at src/fftools/cmdutils.c:794
#1  0x5556dd27 in open_input_file (o=o@entry=0x7fffdc40, 
filename=) at src/fftools/ffmpeg_opt.c:1266
#2  0x55571c1c in open_files (open_file=0x5556cca0 , 
inout=0x5558b81f "input", l=0x555e08d8) at src/fftools/ffmpeg_opt.c:3537
#3  ffmpeg_parse_options (argc=argc@entry=35, argv=argv@entry=0x7fffe2b8) 
at src/fftools/ffmpeg_opt.c:3577
#4  0x55560715 in main (argc=35, argv=0x7fffe2b8) at 
src/fftools/ffmpeg.c:4538

Bug#862191: ITP: brython -- implementation of Python 3 running in the browser

[Martin]

Brython packaging is a work in progress:

https://salsa.debian.org/python-team/packages/brython/

It builds, but there are two issues:

1. debian/copyright needs a lot of work, because brython consists of
   files by many authors with differenty licenses.

2. Tests do not run successfully, because of a Python path problem.
   The problem is just ignored, but shouldn't.

Any help desperately needed and welcome!

Bug#1023143: RFS: xfce4-calculator-plugin/0.7.1-1 [ITP] -- calculator plugin for Xfce panel

[Akbarkhon Variskhanov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "xfce4-calculator-plugin":

 * Package name : xfce4-calculator-plugin
   Version  : 0.7.1-1
   Upstream contact :
https://gitlab.xfce.org/panel-plugins/xfce4-calculator-plugin/-/project_members
 * URL  :
https://docs.xfce.org/panel-plugins/xfce4-calculator-plugin/start
 * License  : GPL-2.0+
 * Vcs  : [fill in URL of packaging vcs]
   Section  : xfce

The source builds the following binary packages:

  xfce4-calculator-plugin - calculator plugin for Xfce panel

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

  https://mentors.debian.net/package/xfce4-calculator-plugin/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xfce4-calculator-plugin/xfce4-calculator-plugin_0.7.1-1.dsc

Changes for the initial release:

 xfce4-calculator-plugin (0.7.1-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #850459

Regards,

Bug#1014537: unnamed packaging files in a multibinary package should be an error

[Axel Beckert]

Hi Niels,

Niels Thykier wrote:
> I understand that you are unsatisfied with this proposal and that is
> fair.

Thanks.

> Though from my point of view, your email makes it hard for me to want to
> engage with you to find a solution that would (ideally) satisfy your desires

I'm sorry, but at that point I have to say the very same about your
previous e-mail. IMHO this is not a one-sided thing. See below for an
explanation.

> as well as solve the underlying problem that Steve wants to have
> solved.

Well, your proposal IMHO shoots wide of the mark and only leaves very
few room for discussion. (If you think, I'm totally wrong here, please
see below for a possibility where we might have misunderstood each
other.) Actually I was totally fine with what Steve requested.

Additionally, cloning bug reports for lintian and lintian-brush
already sounds very final, too. (Except for the mentioned, IMHO very
minor details around debian/README.Debian and debian/TODO, which IMHO
also overshoot.)

> Notably, nowhere in your email can I see any attempt from you to say
> "Could we find an alternative where single binary source packages
> can still leverage this short cut, because I find it very valuable?"
> in a neutral or constructive manner.

Mostly because Steve's suggestion was totally fine for me, just caring
about multi-binary packages and forbidding non-prefixed debhelper
files there. This makes sense!

Which is also why I haven't joined the discussion so far. His proposal
was sane and affects likely only a few packages where multi-binary
packages have non-prefixed debhelper files, which is bad thing and can
easily lead to barely visible packaging errors as with the case in
which he ran into initially. (Actually I ran into such issues in the
past, too, when switching single binary packages to multi-binary
packages. But even before Steve's bug report, I was generally aware of
that issue.)

But the proposal in your previous mail (at least as far as I
understand it even after reading it a second time) goes much farther
and wants to forbid non-prefixed debhelper files "generally".

And I read this "generally" as "for any package, single- as well as
multi-binary packages". And that's what I'm not happy with at all.

Maybe it was meant differently (if so, please elaborate), but that's
how I understand "generally". (And I know, we're both no native
English speakers, so any of us might be wrong here. That's something
which I indeed didn't take into account when I wrote that other mail
out of frustration.)

Additionally the phrase "I am open to not installing them
[debian/README.Debian, debian/TODO] by default if one of you are
willing to drive the discussion on debian-devel to assert there is
consensus for that." implies for me that there is no room for
discussion on any other part of your proposal.

> Instead, it feels to me like you are dumping your frustration on me

It _is_ frustration, that's very correct. Like on that chomping
changelog thingy which — as far as I can see — has only been discussed
on debian-devel (which I and probably many other DDs don't have time
to follow due its huge amount of traffic), but not in any debhelper
bug reports — which I do follow, because I have an interest in
debhelper and that it is cared about — nor has the discussion about it
announced on debian-devel-annoucne (which IMHO should be done for any
discussion on major changes in Debian's tool chain or central
packages).

> and have given up on working with me in solving the problem in the
> best way for all parties (including you!).

Not specifically on working with you as a person but with those who
currently drive the way in which debhelper moves. (Until recently I
was really glad that the policy strongly recommends the usage of
debhelper. In the meanwhile my opinion on this had changed. But you're
now on a good way to revert that. :-)

I though was — until now — a bit surprised about you seemingly not
being open for discussion. So I'm quite glad about your most recent
mail (the one I'm replying to now) which shows again the Niels I knew.

> I find emails like this super draining on my motivation. I have no
> interest in spending my volunteer time working with people that
> writing emails phrased such that they make me feel like that person
> has given up on me.

Yes, and my motivation to help with debhelper in case of something
happens (like what happened to lintian) has drained a lot recently,
too. If I would have been in Uploaders, I would have removed myself
from Uploaders after my previous mail.

> I ask that you rephrase your email in a way where I do not feel you have
> given up on working with me,

Oh, ok, so there's still more room for discussion than your last mail
suggested — and despite there are already bug reports against lintian
and lintian-brush?

So let's start! My suggestions ordered by my personal preference:

* Implement what Steve actually asked for and don't overshoot: Apply
  the rules you've proposed solely 

Bug#741521: spamassassin: DNS resolving should get reloaded

[Samuel Thibault]

As a reminder, mails sent to n...@bugs.debian.org are *not* sent to the
bug submitter, so I had never received that reply:

John Damm Sørensen, le sam. 25 mars 2017 21:12:02 +0100, a ecrit:
> Have you tried adding this:
> ConditionDirectoryNotEmpty=/etc/resolv.conf
> to the Unit section of:
>  /usr/lib/systemd/system/spamassassin.service

No, but that would still fail the case when "a laptop could move from
one wifi network to another, with varying DNS configuration parameters."

Samuel

Bug#1022926: transition: glibc 2.36

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/glibc-2.36.html
Control: tags -1 moreinfo

On 2022-10-27 21:36:11 +0200, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-gl...@lists.debian.org
> 
> Dear release team,
> 
> I would like to get a transition slot for glibc 2.36. It has been
> available in experimental for a bit more than one month and does not
> have any known major issue. It has been built successfully on all
> release architectures and many ports architectures. A few issues found
> through the autopkgtest pseudo excuses for experimental have been fixed.
> The remaining ones are due to britney bugs, broken autopkgtest or
> packages parts of the transition.
> 
> As glibc is using symbol versioning, there is no soname change. That
> said a few packages are using libc internal symbols and have to be
> rebuilt for this transition. Here is the corresponding ben file:
> 
>   title = "glibc";
>   is_affected = .depends ~ /libc[0-9.]* \(<   is_good = .depends ~ /libc[0-9.]* \(<< 2.37\)/;
>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.36\)/;
> 
> In addition a few new symbols have been added that might prevent a few
> other packages to migrate to testing until glibc migrates if they pick
> up the new symbols, however those are really limited in this version and
> mostly linked to new filesystem, processes or random functions, so
> unlikely to be massively used by default.
> 
> Note that this version builds with GCC 12 instead of GCC 11, so it is a
> prerequisite for not shipping bookworm with GCC 11.

Speaking of GCC 12 … #1022991 seems to have a first patch available
upstream. Is there any chance that we could start this transition
together with a fix for that bug?

Cheers

> 
> Thanks for considering.
> 
> Regards,
> Aurelien
> 

-- 
Sebastian Ramacher

Bug#1022007: caja-extensions: Uploading to unstable for gssdp/gupnp 1.6 transition

[Andreas Henriksson]

Hello,

The gssdp/gupnp 1.6 transition just started. I'm wondering if someone
will now take care of uploading the caja-extensions NMU I uploaded to
experimental earlier into unstable?

If I don't hear anything back very soon I'll consider this a go-ahead
for NMU to unstable to avoid extending the transition time further than
necessary.

Regards,
Andreas Henriksson

Bug#1023142: ITP: python-django-pgschemas -- Django multi-tenancy using PostgreSQL schemas

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-pgschemas
  Version : 0.11.0
  Upstream Author : Lorenzo Peña 
* URL : https://github.com/lorinkoz/django-pgschemas
* License : Expat
  Programming Lang: Python
  Description : Django multi-tenancy using PostgreSQL schemas


 This app uses PostgreSQL schemas to support data multi-tenancy in a single
 Django project. It is a fork of django-tenants with some conceptual changes:
 .
  * There are static tenants and dynamic tenants. Static tenants can have their
own apps and urlconf.
  * Tenants can be simultaneously routed via subdomain and via subfolder on
shared subdomain.
  * Public is no longer the schema for storing the main site data. Public should
be used only for true shared data across all tenants. Table "overriding" via
search path is no longer encouraged.
  * Management commands can be run on multiple schemas via wildcards - the
multiproc behavior of migrations was extended to just any tenant command.

I intend to maintain this package as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmNeoCcRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoDaggAsWWVSGqoJjq8rxP5ovslwrxBp4zzZmmP
44SrWRFfvsy5jm6kcyqU6MUNDTB9paWshgWsXISor+CUwHw8F9vDKxEZ1ZrSVkBy
UZksvJDvRRqcQ8vG3xhuhV5DVfHfwhwUMd2dfmHN65VzsYDwkYN/YV+pz466p9c+
MBJ7h1TekQSklSW9rJ9ShlNrfwUS/TvreCyOEH31AZCRH4azDLgkvV3CUfWuzg67
I3oR2rxzEbtJwciJwxWYIOl3y1vIh6GRnW4qNeIK058MgVIz886WefKXG/hC6SMO
X6VskFbPVSZiuoVn9ud1kCrroPNkjhJLSkjo/Y86IHlpp9fwpKrzmA==
=gGN/
-END PGP SIGNATURE-

Bug#1023141: clickhouse: test 00700_decimal_math fails.

[Tobias Frost]

Source: clickhouse
Version: 18.16.1+ds-7.2
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The test 0700_decimal_math fails.
This seems to be arounding issue, as the diff emitted by the test:

--- 
/<>/dbms/tests/queries/0_stateless/00700_decimal_math.reference
2018-12-20 16:38:50.0 +
+++ /tmp/clickhouse.test..mLPWV/tmp/0_stateless/00700_decimal_math.stdout   
2022-10-30 12:52:41.857491058 +
@@ -4,7 +4,7 @@
 42.42006.513   42.419169
 42.42003.4875  42.417263671875
 1.00.8427007929497149  0.15729920705028513
-42.4200115.60113124678627  1.6029995567009473e50
+42.4200115.60113124678627  1.6029995567009475e50
 0.00   0   1   0
 3.14159265 0   -1  -0
 1.00   1.5707963267948966  0   0.7853981633974483
@@ -14,7 +14,7 @@
 42.42006.513   42.419169
 42.42003.4875  42.417263671875
 1.00.8427007929497149  0.15729920705028513
-42.4200115.60113124678627  1.6029995567009473e50
+42.4200115.60113124678627  1.6029995567009475e50
 0.00   0   1   0
 3.141592653589793280   -1  -0
 1.00   1.5707963267948966  0   0.7853981633974483
@@ -24,7 +24,7 @@
 42.42006.513   42.419169
 42.42003.4875  42.417263671875
 1.00.8427007929497149  0.15729920705028513
-42.4200115.60113124678627  1.6029995567009473e50
+42.4200115.60113124678627  1.6029995567009475e50
 0.00   0   1   0
 3.14159265358979279819863330330205224960   -1  -0
 1.00   1.5707963267948966  0   0.7853981633974483


That's 1.602999556700947*3*e50 vs 1.602999556700947*5*e50

For the NMU I'm currently preparing, I will disable the test but keep this bug
report open.

-- 
tobi


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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

Bug#1022003: transition: gssdp/gupnp 1.6: Status update + prepared to start

[Andreas Henriksson]

Hello,

On Sun, Oct 30, 2022 at 09:46:11AM +0100, Andreas Henriksson wrote:
> TL;DR I consider myself ready to start the transition now, with removals
> in the plan.
[...]
> Unless someone tells me I missed something I'll start uploading to
> unstable as soon as I feel I have a free time slot (which might be later
> today).

gssdp_1.6.0-3_source.changes ACCEPTED into unstable
gupnp_1.6.0-3_source.changes ACCEPTED into unstable
gupnp-igd_1.2.0-3_source.changes ACCEPTED into unstable
gupnp-tools_0.12.0-2_source.changes ACCEPTED into unstable
rygel_0.42.0-2_source.changes ACCEPTED into unstable

I'll try to poke caja-extensions maintainers to see if they want to
upload to unstable (but since I haven't heard anything so far I'll
probably go ahead and NMU it again to unstable tomorrow).

I've also filed RM bugs for dleyna-*
see: #1023131 #1023133 #1023134 #1023135

I've poked the librm bug report again and raised severity to serious.
Please consider removing librm (+ roger-router) from testing when
it's the only remaining blocker for finishing the transition.

Regards,
Andreas Henriksson

Bug#1021057: [Debichem-devel] Bug#1021057: cp2k autopkgtest times outs on armel

[Michael Banck]

Hi Paul,

On Sat, Oct 01, 2022 at 11:53:27AM +0200, Paul Gevers wrote:
> Source: cp2k
> Version: 6.1-2

I guess that was supposed to be 9.1-2, as that is (was) current and the
log you referenced also has that.

I agree with Adrian and downgraded this bug to important for now.


Michael

Bug#1023045: apt-listbugs: [INTL:de] Updated German Translation

[Francesco Poli]

On Sat, 29 Oct 2022 18:47:28 +0200 Chris Leick wrote:

> Hi,
> 
> please find attached the newest German translation.

Hello Chris!   :-)

Wow, you sent newest translation, even before I make a call for
translation updates!
And I am about to make one, actually, so your timing is perfect.

Thank you so much for your contribution, which will be included in the
next upload of the package.

Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpq9Y0CYI4U4.pgp
Description: PGP signature

Bug#1023140: uscan: please add support for git tags signed with an SSH key

[Louis-Philippe Véronneau]

Package: devscripts
Severity: wishlist

Dear maintainers,

The latest upstream version of python-mediafile (10.0.1)[1] switched 
from signing the git tag with an OpenPGP key to doing it an SSH key.


Would it be possible to add support for this in uscan?

I would be very nice to be able to have an SSH public key in d/upstream/ 
and d/watch file that looks like this:


---
version=4
opts="mode=git, pgpmode=sshtag, uversionmangle=s/v//" \
https://github.com/beetbox/mediafile.git \
refs/tags/([v\d\.]+)
---

Cheers,

[1]: https://github.com/beetbox/mediafile/releases/tag/v0.10.1

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

Bug#1023138: clickhouse: server aborts when it cannot set core file size.

[Tobias Frost]

Source: clickhouse
Version: 18.16.1+ds-7.2
Severity: normal
Tags: patch

Dear maintainer,

when building in pbuilder, I get test suit errors. This is due that
in a pbuilder environment disables core dumps.
However, clickhouse tries to set maximium core size to 1GiB, which
does not work, as setrlimit cannot increase the limit.

The attached patch fixes that: It will first check if the user has
configured something, and if so, it will try to set the configuration
value (and fail if it cannot.)
If the user has not set a value in configuration, it will either
set it to 1GiB (as before) or the maximum allowed value.

As this code is used in the server code, the situation where this can
happen is not limited to pbuilder, but can also happen if an admin
turns off or limits core dumps less than 1GiB and not adapt config
accordingly.

--
tobi



-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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
--- a/libs/libdaemon/src/BaseDaemon.cpp
+++ b/libs/libdaemon/src/BaseDaemon.cpp
@@ -905,9 +905,17 @@
 if (getrlimit(RLIMIT_CORE, ))
 throw Poco::Exception("Cannot getrlimit");
 /// 1 GiB by default. If more - it writes to disk too long.
-rlim.rlim_cur = config().getUInt64("core_dump.size_limit", 1024 * 1024 * 1024);
+auto wanted = config().getUInt64("core_dump.size_limit", 0);
+if(!wanted) {
+// configuration is not present -- default to 1 GiB, but only if current rlimits allows it.
+wanted = std::min(1024*1024*1024, rlim.rlim_cur);
+wanted = std::min(wanted, rlim.rlim_max);
+}
 
-if (setrlimit(RLIMIT_CORE, ))
+auto orig = rlim.rlim_cur;
+rlim.rlim_cur = wanted;
+
+if (orig != wanted && setrlimit(RLIMIT_CORE, ))
 {
 std::string message = "Cannot set max size of core file to " + std::to_string(rlim.rlim_cur);
 #if !defined(ADDRESS_SANITIZER) && !defined(THREAD_SANITIZER) && !defined(MEMORY_SANITIZER) && !defined(SANITIZER) && !defined(__APPLE__)


signature.asc
Description: PGP signature

Bug#1023137: clickhouse: FTBFS when building from packaging (e.g salsa) git repository.

[Tobias Frost]

Source: clickhouse
Version: 18.16.1+ds-7.2
Severity: normal
Tags: patch

When a git repository is present, upstream CMakeLists.txt is checking whether 
the
submodules (which contains 3rd party libraries). As those are stripped in 
Debian,
the build fails.

Attached quilt patch comments out the CMakeList.txt section which checks this, 
so working
with the git repository for e.g bug triaging / patch creation becomes easier.

-- 
tobi

Description: Make CMakeLists.txt ignoring git submodules.
 The embedded boost is removed, so CMake will fail believing that stuff is missing.
Author: Tobias Frost 
Forwarded: not-needed, Debian specific.
Reviewed-by: 
Last-Update: 2022-10-29 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -17,10 +17,11 @@
 message (WARNING "You are using an unsupported compiler. Compilation has only been tested with Clang 5+ and GCC 7+.")
 endif ()
 
-# Check that submodules are present only if source was downloaded with git
-if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/.git" AND NOT EXISTS "${ClickHouse_SOURCE_DIR}/contrib/boost/boost")
-message (FATAL_ERROR "Submodules are not initialized. Run\n\tgit submodule update --init --recursive")
-endif ()
+# Interferes when bulding Debian package from git repository.
+## Check that submodules are present only if source was downloaded with git
+#if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/.git" AND NOT EXISTS "${ClickHouse_SOURCE_DIR}/contrib/boost/boost")
+#message (FATAL_ERROR "Submodules are not initialized. Run\n\tgit submodule update --init --recursive")
+#endif ()
 
 # Write compile_commands.json
 set(CMAKE_EXPORT_COMPILE_COMMANDS 1)


signature.asc
Description: PGP signature

Bug#1023127: [Pkg-zfsonlinux-devel] Bug#1023127: zfs-linux: please make zfs-{initramfs, dracut} Depend on their respective -core packages

[наб]

On Sun, Oct 30, 2022 at 04:03:24PM +0200, Yurii Kolesnykov wrote:
> I don’t think that proposed patches have a practical value, in fact, they 
> make things worse. 
> E.g. I expect to have a working initrd by installing a kernel and 
> zfs-initramfs when I bootstrap a Debian ZFS install.
You will be delighted to know, then, that this continues to work.

> And I barely imagine a situation when a user uses one of initrd generators 
> and needs to have *-core package of second one installed at the same time.
Conversely, imagining (and being in) such a situation is very easy to me.
This is the reason why they are made co-installable, and only the "bare"
dracut/initramfs-tools packages aren't.

наб


signature.asc
Description: PGP signature

Bug#1023136: clickhouse: FTBFS on arch but amd64 arm64 ppc64el.

[Tobias Frost]

Source: clickhouse
Version: 18.16.1+ds-4
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)

d/rules has the following:

#exclude with_server test on archs other than listed ones
ifeq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el))
TEST_ARGS+="-E with_server"
endif

and later

override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
dh_auto_test -- ARGS+=$(TEST_ARGS)
endif

As dh_auto_test invokes "make test ", which does not
to work, as the -E syntax is ctest syntax.
On targets with GNU make, the builldlogs show a "make syntax"
error prompt.

Looking at buildd logs, this was already in seen in 18.16.1+ds-4,
so marking this version as found version.

Manually calling ctest will resolve this. (See attached patch.)

-- 
tobi

diff --git a/debian/rules b/debian/rules
index bb6b3de..cf9c8f7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -59,6 +59,11 @@ ifeq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el))
 	TEST_ARGS+="-E with_server"
 endif
 
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+TEST_ARGS+="--parallel $(NUMJOBS)"
+endif
+
 CMAKE_FLAGS = -DUNBUNDLED=1 -DUSE_STATIC_LIBRARIES=0 USE_UNWIND=0 -DCLICKHOUSE_SPLIT_BINARY=1 -DVERSION_DESCRIBE=$(shell dpkg-parsechangelog -S Version)
 
 ifeq ($(DEB_HOST_ARCH),amd64)
@@ -73,5 +78,5 @@ override_dh_auto_configure:
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-	dh_auto_test -- ARGS+=$(TEST_ARGS)
+	(cd obj-* ; ctest ARGS+=$(TEST_ARGS) )
 endif


signature.asc
Description: PGP signature

Bug#1021157: missing firmwares for Qualcomm NFA725A

[Diederik de Haas]

On Saturday, 29 October 2022 23:17:20 CET Vincent Bernat wrote:
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.gi
> > t/log/?qt=grep=WCN6855 does show various results which come very close
> > ...SILICONZ_LITE-3.6510.7 vs the referenced ...SILICONZ_LITE-3.6510.16.
> > And one commit is for symlinks to hw2.1
> > 
> > qca/rampatch_usb_00130201.bin is also present in the upstream repo, but
> > searching for nvm_usb_00130201_gf.bin did not yield any results.
> > 
> > So this looks like upstream does have most of the needed files, albeit a
> > slightly older version?
> > I don't know if anything should be done based on this, but figured I'd
> > share my findings.
> 
> I suppose the search engine only works for stuff mentioned directly in
> commit messages. The file present in the repository:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> tree/qca/nvm_usb_00130201_gf.bin.

https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/37 looks 
interesting :-)

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

Bug#1023108: xfce4-power-manager: user cannot shutdown/reboot

[Akbarkhon Variskhanov]

Control: tags -1 moreinfo

Sounds like you have some inhibitors preventing you from shutting
down. Most likely a PolicyKit issue though, as it pops up quite often
on the Xfce forums.

Anything in ~/.xsession-errors? `journalctl --user -f` could also give
us some hints.

Bug#1023131: RM: dleyna-core -- RoQA; unmaintained, needs transition, new upstream uses single repo (dleyna)

[Andreas Henriksson]

Control: clone -1 -2 -3 -4
Control: retitle -2 RM: dleyna-renderer -- RoQA; unmaintained, needs 
transition, new upstream uses single repo (dleyna)
Control: retitle -3 RM: dleyna-server -- RoQA; unmaintained, needs transition, 
new upstream uses single repo (dleyna)
Control: retitle -4 RM: dleyna-connector-dbus -- RoQA; unmaintained, needs 
transition, new upstream uses single repo (dleyna)

On Sun, Oct 30, 2022 at 03:49:56PM +0100, Andreas Henriksson wrote:
[...]
> Please remove dleyna-core, dleyna-renderer, dleyna-server,
> dleyna-connector-dbus from unstable.
[...]

Cloning, so there's one bug report for each source package.

Regards,
Andreas Henriksson

Bug#1023132: Passwd tool useradd no longer copies /etc/skel to newly created user.

[Markus W. Frei]

Package: passwd

Debian Testing

Hi,

A Debian update for Debian Testing has broken the "useradd" utility (in 
/sbin/useradd, I don't know which package it belongs to). The problem is 
that the /etc/skel folder is ignored no matter what settings are used, 
so the new user only gets the vanilla setup, & not the specially 
prepared one.


A previous version of this tool (3rd march, '22) worked fine, & if I 
replace the new file with the old one on Debian testing, it also works 
fine. I am using Calamares to install an adapted version of Debian 
Testing, & Calamares uses "useradd" to create user accounts during the 
installation (one reason is that options can be given to the tool, which 
the "adduser" tool doesn't support). So I need "useradd" to work properly.


Thanks for fixing this as soon as possible.

Bug#1022900: grub-install, efibootmgr etc. not working with new kernel

[Stephan Verbücheln]

Sice the latest vanilla kernel does not work, I have filed an upstream
bug.

https://bugzilla.kernel.org/show_bug.cgi?id=216640

Regards

Bug#1023131: RM: dleyna-core -- RoQA; unmaintained, needs transition, new upstream uses single repo (dleyna)

[Andreas Henriksson]

Package: ftp.debian.org
Severity: normal


Hello,

It's time for gssdp/gupnp 1.6 transition (see #1022003).
Intel has deprecated the dLeyna project upstream.
The debian dleyna-* packages has been orphaned basically from day 1.

There's a new upstream maintainer for dleyna but if that gets uploaded
it will be as a single src:dleyna rather than split up as currently.

dLeyna 0.8 (compatible with gssdp/gupnp 1.6 + libsoup 3.0)
has initial packaging at https://salsa.debian.org/debian/dleyna

More details in #1022009 #1022010 #1022011 #1023093

Please remove dleyna-core, dleyna-renderer, dleyna-server,
dleyna-connector-dbus from unstable.

I'll consider uploading src:dleyna 0.8 to experimental (as orphaned)
once the gssdp/gupnp 1.6 transition is done (unless anyone appears and
wants to maintain it). It will need to go through NEW anyway, so
no point in keeping the old packages around.

Regards,
Andreas Henriksson

Bug#995792: #995792 - please unbreak printing text files

[Steve McIntyre]

On Sun, Oct 30, 2022 at 03:38:06PM +0100, Samuel Thibault wrote:
>Steve McIntyre, le lun. 24 oct. 2022 10:16:39 +0100, a ecrit:
>> This bug just bit me, and I'm disappointed nothing appears to have
>> been done here to remedy this.
>
>I had actually not seen the bug report, the title of the bug report
>didn't catch my eyes.  Thus why it hadn't been fixed so far.

Then I'm glad I raised this! :-) Thanks Samuel!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Rarely is anyone thanked for the work they did to prevent the
 disaster that didn’t happen.”
   -- Mikko Hypponen (https://twitter.com/mikko/)

Bug#1006179: [Pkg-clamav-devel] Bug#1006179: ClamAV 1.0.0 release candidate now available

[Scott Kitterman]

On October 27, 2022 11:47:01 AM UTC, Andrew C Aitchison 
 wrote:
>
>According to
>   https://blog.clamav.net/2022/10/clamav-100-release-candidate-now.html
>ClamAV 1.0.0 release candidate is now available
>
>and
>   https://docs.clamav.net/faq/faq-eol.html
>says that ClamAV 1.0 will be the next Long Term Support feature release after 
>0.103.
>
>Depending on the Debian (and Ubuntu) release schedule you may wish
>to skip 0.104 (which is EOL) and 0.105 and go straight to 1.0 since it is LTS.
>
>I note that 0.105 (and presumably 1.0) requires *rust*
>and 0.104 (onwards?) requires CMake, so all options
>will need non-trivial effort.
>

Looks like we'll also need to patch tomsfastmath, such upstream parched their 
embedded copy:

https://github.com/Cisco-Talos/clamav/commit/17e52a09a91d8f6535014873ab6cb99c827b5e20

Scott K

Bug#995792: #995792 - please unbreak printing text files

[Samuel Thibault]

Steve McIntyre, le lun. 24 oct. 2022 10:16:39 +0100, a ecrit:
> This bug just bit me, and I'm disappointed nothing appears to have
> been done here to remedy this.

I had actually not seen the bug report, the title of the bug report
didn't catch my eyes.  Thus why it hadn't been fixed so far.

Samuel

Bug#995792: printing text files

[Samuel Thibault]

Hello,

Thorsten Alteholz, le sam. 29 oct. 2022 22:43:02 +, a ecrit:
> The problem seems to be that it was installed on a system without need for
> it.

That's just a small part of the problem. The real problem is a bug in
the matching rule, which I have now fixed.

> Wouldn't there be a better package than printer-driver-all-enforce to
> add a Recommends: for it?

Not sure to understand the question: isn't printer-driver-all-enforce
precisely meant to install all drivers?

Samuel

Bug#1023103: linux-image-5.10.0-14-amd64: Wrong power value on APU2 with bullseye

[Salvatore Bonaccorso]

Hi Alexis,

On Sun, Oct 30, 2022 at 10:41:12AM +0100, Alexis Domjan wrote:
> Hi Salvatore,
> 
> Le 30.10.22 à 10:21, Salvatore Bonaccorso a écrit :
> > Control: tags -1 + moreinfo
> > Since 5.10.113-1 is already superseeded by several uploads, can you
> > confirm the issue you are seeing is still present in the most current
> > uploaded version? (5.10.149-2).
> 
> Sorry, indeed, I didn't noticed it wasn't the latest available version of the 
> kernel.
> 
> After the update, however, the issue is still present with the same symptoms.
> 
> Linux 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux
> 
> Do you need more information ?

Thank you for testing. And before 5.10.113 can you pin point to a
version in which showed sensible versions? If so you have a starting
point to bisect where the problem is introduced which would be very
helpfull to determine the pontential issue.

Does the issue persist with a more recent kernel (either from
backports or from unstable)?

Regards,
Salvatore

Bug#1023068: /usr/share/perl5/Config/Model/Dpkg/Dependency.pm: warning with perl 5.36

[Dominique Dumont]

On Saturday, 29 October 2022 23:15:05 CET you wrote:
> Use of @_ in numeric gt (>) with signatured subroutine is experimental at
> /usr/share/perl5/Config/Model/Dpkg/Dependency.pm line 344.

A real bug was hidden there.

Thanks for the heads-up

Bug#1023130: matrix-synapse: embeds several Rust crates

[Jonas Smedegaard]

Package: rc:atrix-synapse
Version: 1.70.1-1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This source package embeds 54 vendor projects (Rust crates), 25 of which
is of same version as separately packaged for Debian, and additionally
26 of which is either same major version or needed only for Windows
builds - i.e. amount of vendored projects can likely be reduced to 3.

Debian Policy §4.13 says that this vendoring should be avoided.

Please package the missing (possibly only 3) projects separately, and
reorganize this package to instead depend on separately packaged Rust
crates.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNeiosACgkQLHwxRsGg
ASFWnw//YPMT/OSWcMZonWxCX/5DHbd6BY+O6I8OJLyJumAhy0qzAlCiNdCLXZj/
QcA51ho+23gPDhm5fpKUCQrHKY013IPsiORVnJPpZAD5L0WYY69gG3veLtrOCmZX
yClx89A4X0RyLoCjAeoYYdnv0LE0BI7DhpzcrJ16obhYyWt7lS+6v7N0LEQEKagD
muLEi4r8DNYD/Ok9sKhxk4CG/dBuYLElBkDPRkniMjHilqqME1iirYGSbwrqk/5Q
hvfBTdvHVOivWj7ywNSWWckf6Bcnx5G+m4RU+kvmMptx7sVT/RByNZBOwYCp7pCb
Ut9thDCPn7Z7IuP8PKmHhI8y792cTW7EJ/y1B2+YJEtDMscjgmFWF+i080OHQr9m
xD6J2i11tNUQ+pYRb4qx1cV26+GzNaaqyr1YCcRQK23kG4ouz3iVhPIqD8dBrAbY
YvqRUShgOICRcyfpPWuJiwO5dhI9BNoo4rtb3QkvjuiCf8msNKik9li/Cs86YhSs
fYe29UN4OhDRJ3d+EMhHo+YrxKFZRMEhoAodXRjsENr0BsS91G3Wf24irI2xjedB
GpUYBEROM/eniSePJTyB6a4+1DdiCLVZtixKg2GpmikB6qjUfEaHfvHR/zp1ImEY
rcoigN5P9dr5K8nauRDC3sda1TlQcPpjdaO7xdgGsQPCnp2JcRw=
=xeeq
-END PGP SIGNATURE-

Bug#1023129: kernel-handbook: guidance w.r.t. the proper dependencies for initrd-generator package-only plugins

[наб]

Source: kernel-handbook
Version: 1.0.20
Severity: wishlist

Dear Maintainer,

idk if this is within the purview of the hand-book, but given that other
parts of chapter-initramfs.dbk are, it may well be.
If it isn't, I'd appreciate being directed to the proper mailing list.

On my Bullseye system, 
-- >8 --
$ apt-cache dumpavail  | awk  '/^Package:/ {pkg=$2}  
/^Depends:.*[^-](dracut|initramfs-tools)/ {print pkg "\t" $0}' | grep -ve 
^linux-image- -e ^dracut -e ^initramfs-tools | expand -t35 | grep -Ee 
'(initramfs-tools|dracut)-core' -v | sort | uniq -w35
bilibop-lockfs Depends: bilibop-common (= 0.6.3), 
initramfs-tools, udev (>= 242-6)
bootcd Depends: busybox | busybox-static | 
busybox-cvs | busybox-cvs-static, cpio, dosfstools, e2fsprogs, fdisk | 
util-linux (<< 2.29.2-3~), file, genisoimage, initramfs-tools, 
grub-efi-amd64-bin, isolinux, lsb-base (>= 3.0-6), rsync, shellia (>= 5.6.5), 
syslinux, syslinux-common, xorriso
clevis-dracut  Depends: clevis-systemd (= 16-2), dracut, 
dracut-network
clevis-initramfs   Depends: clevis-luks (= 16-2), 
initramfs-tools
cloud-initramfs-dyn-netconfDepends: initramfs-tools
cloud-initramfs-growroot   Depends: cloud-utils (>= 0.26-2~), 
initramfs-tools, fdisk | util-linux (<< 2.29.2-3~)
cloud-initramfs-rescuevol  Depends: initramfs-tools
crossgraderDepends: python3-appdirs, python3-apt (>= 
1.0.0), python3:any, python3-pkg-resources, dpkg-dev, arch-test, initramfs-tools
cryptsetup-initramfs   Depends: busybox | busybox-static, 
cryptsetup (>= 2:2.3.7-1+deb11u1), initramfs-tools (>= 0.137) | 
linux-initramfs-tool, debconf (>= 0.5) | debconf-2.0
dropbear-initramfs Depends: busybox | busybox-static, 
dropbear-bin (>= 2020.81-3), initramfs-tools (>= 0.94), udev
live-boot-initramfs-tools  Depends: busybox | busybox-initramfs, 
initramfs-tools, udev
live-tools Depends: lsb-base, initramfs-tools
mandos-client  Depends: libavahi-common3 (>= 0.6.16), 
libavahi-core7 (>= 0.6.24), libc6 (>= 2.28), libglib2.0-0 (>= 2.40), 
libgnutls30 (>= 3.7.0), libgpgme11 (>= 1.2.0), libnl-3-200 (>= 3.2.7), 
libnl-route-3-200 (>= 3.2.7), debconf (>= 1.5.5) | debconf-2.0, adduser, 
cryptsetup (<< 2:2.0.3-1) | cryptsetup-initramfs, initramfs-tools (>= 0.99) | 
dracut (>= 044+241-3), dpkg-dev (>= 1.16.0), gnutls-bin (>= 3.6.6) | 
libgnutls30 (<< 3.6.0)
multipath-tools-boot   Depends: debconf (>= 0.5) | debconf-2.0, 
initramfs-tools | linux-initramfs-tool, lsb-base, multipath-tools (>= 0.8.5-2), 
multipath-tools (<< 0.8.5-2.1~)
open-infrastructure-system-bootDepends: busybox | busybox-initramfs, 
initramfs-tools, udev
openstack-debian-imagesDepends: debootstrap, dosfstools, e2fsprogs, 
extlinux, initramfs-tools, ipcalc, kpartx, mbr, parted, qemu-utils
plymouth   Depends: init-system-helpers (>= 1.18), 
initramfs-tools | dracut, lsb-base (>= 3.0-6), systemd (>= 232-8~), udev (>= 
232-8~), libc6 (>= 2.29), libdrm2 (>= 2.4.47), libplymouth5 (>= 0.9.5)
yubikey-luks   Depends: cryptsetup-run, initramfs-tools, 
yubikey-personalization (>= 1.5)
zfs-dracut Depends: dracut, zfs-modules | zfs-dkms, 
zfsutils-linux (>= 2.1.5-1)
zfs-initramfs  Depends: busybox-initramfs | busybox-static 
| busybox, initramfs-tools, zfs-modules | zfs-dkms, zfsutils-linux (>= 2.0.3-9)
-- >8 --

And conversely, without -v:
-- >8 --
acpi-override-initramfsDepends: initramfs-tools-core
sg3-utils-udev Depends: sg3-utils, initramfs-tools-core, 
initramfs-tools | linux-initramfs-tool
-- >8 --
  
This was spurred by me trying to install tzpfms-{dracut,initramfs},
which respectively depend on zfs-{dracut,initramfs},
which for some reason depend on dracut and initramfs-tools,
instead of the respective -core package
(for which I've opened #1023127 with patches for this).

This makes them non-co-installable, which for me means testing is way
more annoying than it should be, but I think it's a general problem of
hygiene.

Of the packages listed above, the packages of interest to this question
which I think do not get this right are:
  * clevis-{dracut,initramfs}
  * cloud-initramfs-{dyn-netconf,growroot,rescuevol}
  * dropbear-initramfs
  * live-boot-initramfs-tools

And those that don't differently are:
  * cryptsetup-initramfs\ depends on l-i-t which is satisfied by
| dracut (and t-ir), but explicitly targets
  * multipath-tools-boot/ i-t, should just be i-t-c

  * openstack-debian-images ‒ depends on i-t, but is just a program,
  so should just be i-t-c

The only one that does get it right appears to be:
  * acpi-override-initramfs

clevis-{dracut,initramfs} is another text-book example of this:
they aren't 

Bug#1023127: [Pkg-zfsonlinux-devel] Bug#1023127: zfs-linux: please make zfs-{initramfs, dracut} Depend on their respective -core packages

[Yurii Kolesnykov]

Dear наб,

I don’t think that proposed patches have a practical value, in fact, they make 
things worse. 
E.g. I expect to have a working initrd by installing a kernel and zfs-initramfs 
when I bootstrap a Debian ZFS install.
And I barely imagine a situation when a user uses one of initrd generators and 
needs to have *-core package of second one installed at the same time.

Bug#1023128: RM: freeture -- NBS; FTBFS against opencv4 and aravis-0.8

[Bo YU]

Package: ftp.debian.org
Severity: normal

Hi, 

The package has FTBFS against opencv4 and aravis-0.8 and the upstream
will not be maintained from[0]. So the package will be built again in
furture I think[1].

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922579#35
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922579#42
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1023124: libsystemd-shared-251.so: cannot open shared object file

[Salvo Tomaselli]

systemd-machine-id-setup: /usr/bin/systemd-machine-id-setup
/bin/systemd-machine-id-setup
/usr/share/man/man1/systemd-machine-id-setup.1.gz


stat /usr/bin/systemd-machine-id-setup /bin/systemd-machine-id-setup
 File: /usr/bin/systemd-machine-id-setup
 Size: 18928   Blocks: 40 IO Block: 4096   regular file
Device: 259,5   Inode: 4201937 Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2022-10-30 13:34:13.098418093 +0100
Modify: 2022-08-14 20:06:18.0 +0200
Change: 2022-08-22 15:25:56.730012624 +0200
Birth: 2022-08-22 15:25:56.610011671 +0200
 File: /bin/systemd-machine-id-setup
 Size: 18928   Blocks: 40 IO Block: 4096   regular file
Device: 259,5   Inode: 8650854 Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2022-10-30 13:38:20.0 +0100
Modify: 2022-10-14 16:34:00.0 +0200
Change: 2022-10-30 13:38:20.944385494 +0100
Birth: 2022-10-30 13:38:20.816384357 +0100



It seems my system is in a weird status from some previous issues…
Maybe originating  when apt told me to split /usr, then I had some
issues and had to manually install a bunch of packages.

Il giorno dom 30 ott 2022 alle ore 13:52 Ansgar  ha scritto:
>
> On Sun, 2022-10-30 at 13:34 +0100, Salvo "LtWorf" Tomaselli wrote:
> > Preconfiguring packages ...
> > Setting up systemd (252~rc3-2) ...
> > systemd-machine-id-setup: error while loading shared libraries: 
> > libsystemd-shared-251.so: cannot open shared object file: No such file or 
> > directory
> > dpkg: error processing package systemd (--configure):
> >  installed systemd package post-installation script subprocess returned 
> > error exit status 127
> > Errors were encountered while processing:
> >  systemd
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> The /bin/systemd-machine-id-setup shipped in the systemd 252~rc3-2
> package is linked against libsystemd-shared-252.so, not libsystemd-
> shared-251.so.
>
> Please check all paths given in the PATH used when calling dpkg/apt for
> systemd-machine-id-setup (e.g., by using `which -a systemd-machine-id-
> setup` with the correct PATH) and report their location and sha1 hash
> (sha1sum /bin/systemd-machine-id-setup ...).
>
> Please also report the output of `ls -ld /bin /usr/bin` and whether the
> system is merged-/usr already or not.
>
> Ansgar
>


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#1023127: zfs-linux: please make zfs-{initramfs,dracut} Depend on their respective -core packages

[наб]

Source: zfs-linux
Version: 2.1.6-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Currently, zfs-initramfs and zfs-dracut are not co-installable,
because they have Depends: initramfs-tools and dracut, respectively,
and those conflict.

initramfs-tools and dracut are the "please use
initramfs-tools-core/dracut-core to generate system initrds"
integration-only packages.

The actual generation program and plugins are provided in the
-core packages. Please consider the attached patches, based on recent
Salsa, to make them co-installable.

Best,
наб

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

Kernel: Linux 5.10.0-17-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From 879ae6c680ee245f1b1daf60991e887993839f1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Sun, 30 Oct 2022 13:37:46 +0100
Subject: [PATCH 1/2] d/control: zfs-dracut Depends: dracut-core instead of
 dracut

dracut-core contains dracut proper, dracut is the "please use dracut to
generate system initrds" package
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index ba2dbb7d2..571e984e9 100644
--- a/debian/control
+++ b/debian/control
@@ -217,7 +217,7 @@ Description: OpenZFS root filesystem capabilities for Linux - initramfs
 
 Package: zfs-dracut
 Architecture: all
-Depends: dracut,
+Depends: dracut-core,
  zfs-modules | zfs-dkms,
  zfsutils-linux (>= ${source:Version}),
  ${misc:Depends}
-- 
2.37.2

From 4c51ef2fea5097350b4ac3c4933efc1b69cb87ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Sun, 30 Oct 2022 14:32:52 +0100
Subject: [PATCH 2/2] d/control: zfs-initramfs-tools Depends:
 initramfs-tools-core instead of initramfs-tools

initramfs-tools-core contains initramfs-tools proper, initramfs-tools
is the "please use initramfs-tools to generate system initrds" package
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 571e984e9..297c4ced3 100644
--- a/debian/control
+++ b/debian/control
@@ -201,7 +201,7 @@ Description: OpenZFS filesystem kernel modules for Linux
 Package: zfs-initramfs
 Architecture: all
 Depends: busybox-initramfs | busybox-static | busybox,
- initramfs-tools,
+ initramfs-tools-core,
  zfs-modules | zfs-dkms,
  zfsutils-linux (>= ${source:Version}),
  ${misc:Depends}
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1023126: kea hooks are in architecture-dependend path

[Daniel Baumann]

Package: isc-kea
Version: 2.2.0-1

Hi,

kea allows to load "hook libraries" to extend its features and
configuration, e.g.:

"hooks-libraries": [
  {
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
  }
],

unfortunately, the path to the hook has to be absolute. since they are
placed in /usr/lib/$multi_arch/kea/hooks, this means that the
configuration of e.g. kea-dhcp4-server is then specific to the
architecture of the system it is running on.

it would be nice if the hooks would be placed in /usr/lib/kea/hooks
instead. I haven't though about how to handle the resulting multi-arch
issues though, maybe splitting them out to "kea-hooks" or so could
simplify the handling (as the hooks are optional and not required for
the dhcp servers).

Regards,
Daniel

Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump

[Sean Whitton]

Hello,

On Fri 14 Oct 2022 at 12:53PM +02, Vincent Lefevre wrote:

> Control: found -1 1:28.2+1-1
>
> Hi,
>
> On 2022-10-13 22:28:24 -0700, Sean Whitton wrote:
>> Can you reproduce this with what's in sid now?
>
> Yes, this still occurs:
>
> zira% ls -lh
> total 41M
> -rw--- 1 vinc17 vinc17 43M 2022-10-14 12:49:40 core
>
> Core was generated by `/usr/bin/emacs --batch -l 
> /tmp/emacs-async-comp-url-cookie.el-A86dRV.el'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7f59efe8957c in ?? () from /lib/x86_64-linux-gnu/libc.so.6

I've backported a couple of patches from upstream related to native
compilation, now, so would you be able to test again with the latest
upload?  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1023036: follow up

[MichaelR]

I didn't even read #1017842 as the "headline" didn't seem relevant but
it does indeed seem to be the same problem.  I reinstalled v0.67-2,
edited /usr/share/initramfs-tools/scripts/osk-sdl-keyscript to
comment-out "cat >/dev/null", rebuilt the initramfs, and rebooted
successfully.  I saw no signs of the LUKS passphrase being echoed to
the screen, with either virtual or physical keyboards.

I guess this can be closed as a duplicate.  Thanks for the speedy reply.

Bug#1021579: closed by Debian FTP Masters (reply to Michael Biebl ) (Bug#1021579: fixed in systemd 251.5-3)

[Michael Biebl]

Am 12.10.22 um 23:31 schrieb Aleksey Vasenev:

Should we expect this fix in bullseye or is the problem too minor?


As this has been causing a regression (see 
https://github.com/systemd/systemd/issues/25179) it's probably not a 
safe candidate for a bullseye backport.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022248: transition: icu

[GCS]

Control: tags -1 -moreinfo

On Thu, Oct 27, 2022 at 11:39 PM Sebastian Ramacher
 wrote:
> On 2022-10-22 19:17:58 +0200, László Böszörményi wrote:
> > Transition is similar to the previous ones, this time boost1.74 needs
> > to be binNMUed after level1 before other level2 packages and pyicu
> > will need a sourceful upload (its Git version seems to be ready, but I
> > wait for its release).
>
> I've set up the tracker. Please remove the moreinfo tag once the test
> builds are done.
 I can report the following. Rebuilds are done and pyicu (Python
wrapper for ICU) supporting 72.1 is released and packaged. Two
immediate problems were found and fixed by its upstream. It can be
binNMUed for ICU 72.1 version.
Package nodejs further updated for Sid, flaky test remained. Wile it
builds on buildd machines, locally I get:
not ok 3161 sequential/test-debugger-preserve-breaks # TODO : Fix flaky test
  duration_ms: 31.372
  severity: flaky
  exitcode: 1

Package 0ad and gnucash fail to build [1][2] with ICU 72.1 and bugs are filed.
Package supercollider failed to build due to another issue [3]. Its
packaging Git has a working fix and after applying that it was built
with ICU 72.1 as well.

Cheers,
Laszlo/GCS
[1] https://bugs.debian.org/1023121
[2] https://bugs.debian.org/1023122
[3] https://bugs.debian.org/1019995

Bug#1023124: libsystemd-shared-251.so: cannot open shared object file

[Ansgar]

On Sun, 2022-10-30 at 13:34 +0100, Salvo "LtWorf" Tomaselli wrote:
> Preconfiguring packages ...
> Setting up systemd (252~rc3-2) ...
> systemd-machine-id-setup: error while loading shared libraries: 
> libsystemd-shared-251.so: cannot open shared object file: No such file or 
> directory
> dpkg: error processing package systemd (--configure):
>  installed systemd package post-installation script subprocess returned error 
> exit status 127
> Errors were encountered while processing:
>  systemd
> E: Sub-process /usr/bin/dpkg returned an error code (1)

The /bin/systemd-machine-id-setup shipped in the systemd 252~rc3-2
package is linked against libsystemd-shared-252.so, not libsystemd-
shared-251.so.

Please check all paths given in the PATH used when calling dpkg/apt for
systemd-machine-id-setup (e.g., by using `which -a systemd-machine-id-
setup` with the correct PATH) and report their location and sha1 hash
(sha1sum /bin/systemd-machine-id-setup ...).

Please also report the output of `ls -ld /bin /usr/bin` and whether the
system is merged-/usr already or not.

Ansgar