date:20221030

Control: retitle -1 clickhouse: rounding issue in unit tests.

Also, on arm64, 00047_stored_aggregates_complex fails:

Buildlog excerpt (unmangled) from:
https://buildd.debian.org/status/fetch.php?pkg=clickhouse&arch=arm64&ver=18.16.1%2Bds-7.3%7Eexp2&stamp=1667169496&raw=0

8: b"--- 
/<>/dbms/tests/queries/0_stateless/00047_stored_aggregates_complex.reference
  2018-12-20 16:38:50.0 +
+++ 
/tmp/clickhouse.test..IyGS7/tmp/0_stateless/00047_stored_aggregates_complex.stdout
  2022-10-30 20:07:43.809291574 +
@@ -3,37 +3,37 @@
 2014-06-01 0   2   245 24.57   20  21  
[24.5,28.1] ['20','21','22','23','24','25','26','27','28','29']
 2014-06-01 0   3   345 34.57   30  35  
[34.5,38.1] ['30','31','32','33','34','35','36','37','38','39']
 2014-06-01 0   4   445 44.57   40  42  
[44.5,48.1] ['40','41','42','43','44','45','46','47','48','49']
-2014-06-01 0   5   545 54.57   50  56  
[54.5,58.094]   
['50','51','52','53','54','55','56','57','58','59']
+2014-06-01 0   5   545 54.57   50  56  
[54.5,58.1] ['50','51','52','53','54','55','56','57','58','59']
 2014-06-01 0   6   645 64.57   60  63  
[64.5,68.1] ['60','61','62','63','64','65','66','67','68','69']
-2014-06-01 0   7   745 74.57   70  70  
[74.5,78.11]
['70','71','72','73','74','75','76','77','78','79']
+2014-06-01 0   7   745 74.57   70  70  
[74.5,78.1] ['70','71','72','73','74','75','76','77','78','79']
 2014-06-01 0   8   845 84.57   80  84  
[84.5,88.1] ['80','81','82','83','84','85','86','87','88','89']
 2014-06-01 0   9   945 94.57   90  91  
[94.5,98.1] ['90','91','92','93','94','95','96','97','98','99']
-2014-06-01 1   10  1045104.5   7   100 105 
[104.5,108.11]  
['100','101','102','103','104','105','106','107','108','109']
-2014-06-01 1   11  1145114.5   7   110 112 
[114.5,118.11]  
['110','111','112','113','114','115','116','117','118','119']
+2014-06-01 1   10  1045104.5   7   100 105 
[104.5,108.1]   ['100','101','102','103','104','105','106','107','108','109']
+2014-06-01 1   11  1145114.5   7   110 112 
[114.5,118.1]   ['110','111','112','113','114','115','116','117','118','119']
 2014-06-01 1   12  1245124.5   7   120 126 
[124.5,128.1]   ['120','121','122','123','124','125','126','127','128','129']
 2014-06-01 1   13  1345134.5   7   130 133 
[134.5,138.1]   ['130','131','132','133','134','135','136','137','138','139']
 2014-06-01 1   14  1445144.5   7   140 140 
[144.5,148.1]   ['140','141','142','143','144','145','146','147','148','149']
 2014-06-01 1   15  1545154.5   7   150 154 
[154.5,158.1]   ['150','151','152','153','154','155','156','157','158','159']
 2014-06-01 1   16  1645164.5   7   160 161 
[164.5,168.1]   ['160','161','162','163','164','165','166','167','168','169']
-2014-06-01 1   17  1745174.5   7   170 175 
[174.5,178.12]  
['170','171','172','173','174','175','176','177','178','179']
-2014-06-01 1   18  1845184.5   7   180 182 
[184.5,188.12]  
['180','181','182','183','184','185','186','187','188','189']
+2014-06-01 1   17  1745174.5   7   170 175 
[174.5,178.1]   ['170','171','172','173','174','175','176','177','178','179']
+2014-06-01 1   18  1845184.5   7   180 182 
[184.5,188.1]   ['180','181','182','183','184','185','186','187','188','189']
 2014-06-01 1   19  1945194.5   7   190 196 
[194.5,198.1]   ['190','191','192','193','194','195','196','197','198','199']
 2014-06-01 2   20  2045204.5   7   200 203 
[204.5,208.1]   ['200','201','202','203','204','205','206','207','208','209']
 2014-06-01 2   21  2145214.5   7   210 210 
[214.5,218.1]   ['210','211','212','213','214','215','216','217','218','219']
 2014-06-01 2   22  2245224.5   7   220 224 
[224.5,228.1]   ['220','221','222','223','224','225','226','227','228','229']
 2014-06-01 2   23  2345234.5   7   230 231 
[234.5,238.1]   ['230','231','232','233','234','235','236','237','238','239']
-2014-06-01 2   24  2445244.5   7   240 245 
[244.5,248.12]  
['240','241','242','243','244','245','246','247','248','249']
+2014-06-01 2   24  2445244.5   7

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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

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

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'

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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?

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

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

2022-10-30 Thread 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

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

2022-10-30 Thread 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-----*--"

2022-10-30 Thread 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

2022-10-30 Thread 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&tag=pkgconf-rebuild-ftbfs
> 
> -- 
> Cheers,
>   Andrej
> 

-- 
Sebastian Ramacher

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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

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

https://buildd.debian.org/status/logs.php?pkg=haskell-gi-gtk&arch=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

2022-10-30 Thread 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

2022-10-30 Thread 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.

2022-10-30 Thread 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

2022-10-30 Thread 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?

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

https://buildd.debian.org/status/logs.php?pkg=fq&ver=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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

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

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

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

https://buildd.debian.org/status/logs.php?pkg=haskell-hopenpgp&arch=armel
https://buildd.debian.org/status/logs.php?pkg=haskell-hopenpgp&arch=armhf
https://buildd.debian.org/status/logs.php?pkg=haskell-hopenpgp&arch=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

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&ver=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

2022-10-30 Thread 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

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

2022-10-30 Thread 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.

2022-10-30 Thread 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

2022-10-30 Thread 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:

2022-10-30 Thread 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

2022-10-30 Thread 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

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.

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.

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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

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

2022-10-30 Thread 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 f

Bug#741521: spamassassin: DNS resolving should get reloaded

2022-10-30 Thread 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

2022-10-30 Thread 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

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

2022-10-30 Thread 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.

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

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

2022-10-30 Thread 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

2022-10-30 Thread 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

2022-10-30 Thread 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.

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, &rlim))
 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, &rlim))
+auto orig = rlim.rlim_cur;
+rlim.rlim_cur = wanted;
+
+if (orig != wanted && setrlimit(RLIMIT_CORE, &rlim))
 {
 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.

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

2022-10-30 Thread наб

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.

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

2022-10-30 Thread 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&q=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

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)

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.

2022-10-30 Thread 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

2022-10-30 Thread 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)