Bug#1081662: RM: python-msgspec [armel armhf i386 s390x] -- ANAIS; Upstream isn't supporting some architectures

[Carsten Schoenert]

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

Hello,

please remove existing binary packages for python3-msgspec for the
following architectures in unstable:

armel armhf i386 s390x 

Upstream isn't supporting 32bit and BE architectures.

Thanks!

Regards
Carsten

Bug#1080186: hiera-py: please patch-out the generation of the useless python3-simplejson dependency

[Carsten Schoenert]

Hello Alexandre,

Am 31.08.24 um 11:38 schrieb Alexandre Detiste:

Hi,

I think all it takes is removing this one line.

Greetings

tchet@quieter:/tmp/hiera-py$ grep simplejson -r
setup.py:install_requires = ['simplejson'],
tchet@quieter:/tmp/hiera-py$


could you be please a bit elaborate in the future?

What about using a classical starting for such bug report?

"You package is using simplejson as a binary depending package, but this 
module isn't any there used later in hiery-py. It's obviously not needed 
as an dependency.


Could you please remove this unneeded dependency because of ..."

Your bug report comes due its shortness and without any kindness a bit rude.
That's not the art and style I did experience in the past decade while 
working in Debian. Unfortunately I did see this kind of communication 
from you in various places! :-(


--
Regards
Carsten

Bug#1068248: ruff: New upstream release

[Carsten Schoenert]

Source: ruff
Followup-For: Bug #1068248

Hello Jelmer,

would you mind to have a look at this wishlist report?

Would be really helpful to get a newer version of ruff into Debian, as
already mentioned in the report packages start to depend on a more
recent version of ruff.

Thanks!

--
Regards
Carsten

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

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

Bug#1059966: thunderbird: loong64 is not present in the architecture list

[Carsten Schoenert]

Hello Dandan,

Am 04.01.24 um 09:37 schrieb zhangdandan:

The thunderbird could not be compiled for loong64 in Debian Package
Auto-Building.
Please see
https://buildd.debian.org/status/package.php?p=thunderbird&suite=sid

Maybe thunderbird's control file lacks loong64 support, for examples,
```
Package: thunderbird
-Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64 riscv64
+Architecture: amd64 arm64 i386 loong64 mips64el ppc64el s390x ppc64 riscv64
```

Please pay attention to this phenomenon that I reported.
If you have any questions, you can contact me at any time.


we disabled a lot of usual architectures where nobody will use 
Thunderbird or at least can Thunderbird in a useful way.


Did you check if a recent Thunderbird version is buildable on loong64?
If not it makes no sense to me to enable loong64 in the Architecture field.

If there are patches needed they need to get upstream, but it might be 
that Mozilla isn't really interested in adding another architecture. As 
Thunderbird is still depending a lot on the Firefox code base it's best 
to me to start any adding to a new architecture in Firefox.


--
Regards
Carsten

Bug#1078788: ITP: sphinx-removed-in -- Sphinx extension recognizes *removed[-in] directives

[Carsten Schoenert]

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

* Package name: sphinx-removed-in
  Version : 0.2.3
  Upstream Contact: Alexander Todorov 
* URL : https://github.com/MrSenko/sphinx-removed-in
* License : BSD-3-clause
  Programming Lang: Python
  Description : Sphinx extension recognizes *removed[-in] directives

 This Sphinx extension recognizes the .. versionremoved:: and
 .. removed-in:: directives. These are missing from Sphinx'es core markup.

This package is a dependency for python-sphobjinv ITP #1078565
https://bugs.debian.org/1078565

The maintenance of the package will happen within the DPT.

Bug#1078518: ITP: python-whey-pth -- Extension for Whey to support .pth files

[Carsten Schoenert]

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

* Package name: python-whey-pth
  Version : 0.0.6
  Upstream Contact: Dominic Davis-Foster 
* URL : https://github.com/repo-helper/whey-pth
* License : Expat
  Programming Lang: Python
  Description : Extension to Whey to support .pth files

 whey-pth adds the ability to support site-specific paths through .pth files if
 the Whey library is used.

This package extends python3-whey and is a build dependency for
sphinx-jinja2-compat which then is a build dependency for sphinx toolbox
where Kathara Sasikumar and I do work on right now.

I plan to maintin this packagae within the DPT.

Bug#1063884: RFS: python-autodocsumm/0.2.12-1 [ITP] -- API that automatically extends sphinx (common documentation)

[Carsten Schoenert]

Hello Marcos,

you seems to be quite unresponsive after you raised this ITP. At least
not vissible within the Debian BTS.
Are you still intrested in maintaining this package?

In the between time another person has interest in maintaining the
package within the DPT.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078264

Given there is still no packaging source available I tend to let Kathara
take over this ITP in about 2 weeks and work with her on getting the
packaging into Debian.

The reasioning is basically that we have other packages which we want to
get into Debian but depending on autodocsumm, so not having autodocsum
available in Debian is making the packaging work harder.

I encourage you to maintain this package later anyway if you want!

Regards
Carsten

Bug#1078201: thunderbird: Unable to open developer tools

[Carsten Schoenert]

Hello Paul,

Am 08.08.24 um 09:33 schrieb Paul Menzel:

Dear Debian folks,


In the hamburger menu going to *Tools* and then clicking on *Developer
tools* nothing opens – neither does Ctrl + Shift + i.

I think it once worked. Can you reproduce this issue?


no, not really. I did never used the this tool or was in the need to use 
this.
So I can't say that "nothing happens" is maybe the normal behavior if no 
AddOn is selected or being worked on.


For me the behavior is the same, no matter if I use 115.x or 128.x.

--
Regards
Carsten

Bug#1078028: RM: python-channels -- ROM; Package does conflict with an existing package

[Carsten Schoenert]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Hello FTP-Team,

the package src:python-channels is conflicting with the existing package
python-django-channels.

I did try to answer to the DAK email about the upload was going into
NEW, but i seems this additional information did not reached the team. 

We missed while doing the research unfortunately to find
https://tracker.debian.org/pkg/python-django-channels
which *is* exact the same package. So the python-channels package is
completly not needed and needs to get kicked out of the archive.

Helmut Grohne did open recently a RC bug as he detected the confliction
of both packages also.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077965

Thanks in advance!

--
Regards
Carsten

Bug#1077787: faker: Please provide a faker-doc package

[Carsten Schoenert]

Source: faker
Version: 26.0.0-1
Severity: wishlist

Dear Maintainer,

currently there is no -doc package of faker build from the source, but
it should be easy to build such a package from the scratch, the only
Sphinx extension that isn't packaged is faker.sphinx.autodoc that will
not be much of a problem..

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

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

Bug#1077755: ITP: python-picologging -- Fast and lightweight Python logging library

[Carsten Schoenert]

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


* Package name: python-picologging
  Version : 0.9.3
  Upstream Contact: Microsoft Corporation>
* URL : https://github.com/microsoft/picologging
* License : MIT/X, PSF-2.0
  Programming Lang: Python
  Description : Fast and lightweight Python logging library

 Picologging is a high-performance logging library for Python, it's about
 4-10x faster than the logging module in the standard library.
 .
 Picologging is designed to be used as a drop-in replacement for applications
 which already use logging, and supports the same API as the logging module.

I plan to maintin this packagae within the DPT.

Bug#1077208: alternative WiFi source plugin

[Carsten Schoenert]

Control: tags -1 wishlist

Hello Tad,

Am 27.07.24 um 06:00 schrieb Tad Whiteside:

I'm sorry, the

line in the above report:

download and extract the latest zip in this directory (from 
herehttps://github.com/arduino/UnoWiFi-FirmwareUpdater-Plugin/releases/download/0.0.2/UnoWiFi-Updater-ArduinoIDE-Plugin-0.0.2.zip)
should have said
download and extract the latest zip in this directory (from 
herehttps://github.com/arduino/WiFi101-FirmwareUpdater-Plugin/releases)


this information you want like to have within the package needs to go 
into the file README.Debian so it's accessible later locally in

/usr/share/doc/arduino/README.Debian

Feel free to provide a patch or at least a good suggestion of the 
content you would like to see then.


It's also possible to adjust the packaging by adding some additional 
tarball which is including such firmware. I don't know how practical 
this can be in the end as we would need to update the Debian package 
more frequently if the upstream data was updated.
Also, the old 1.x version of Arduino will not get further updates, but 
version 2 is now Electron based.


--
Regards
Carsten

Bug#1076845: rust-ammonia: Please package version 4.0.0

[Carsten Schoenert]

Source: rust-ammonia
Version: 3.3.0-1
Severity: wishlist

Dear Maintainer,

would be nice if the current version 4.0.0 could get packaged as I've a
package (not yet packaged yet) that is depening on this version of ammonia.

Regards and thanks
Carsten

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

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

Bug#1075771: kanboard: Kanboard is throwing an exception in EventDispatcher while trying to logout

[Carsten Schoenert]

Hello Joe,

I tried to reach you but your eamil system seems to not accept emails at
least from my side.

---%<---
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  j...@nahmias.net
host skippy.nahmias.net [162.243.209.86]
retry timeout exceeded


Reporting-MTA: dns; mitropoulos.debian.org

Action: failed
Final-Recipient: rfc822;j...@nahmias.net
Status: 5.0.0
Remote-MTA: dns; skippy.nahmias.net
--->%---

I was asking if you are fine if I work together with Kalyani on fixing
the current outstanding CVE issues together with this issue and finalize
a upload to s-propused-updates.

I'll wait for some days before going to work on this.

Regards
Carsten

Am Thu, Jul 04, 2024 at 11:43:30PM +0530 schrieb Kalyani Kenekar:
> Package: kanboard
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> If I am trying to logout from the kanboard UI, I am not able to logout because
> I am getting a "HTTP ERROR 500".
> 
> When I look into the error log of my webserver (nginx) I see the following
> stack trace:
> 
> Stack trace:
> #0 /usr/share/kanboard/app/Core/Session/SessionManager.php(62): 
> Symfony\Component\EventDispatcher\EventDispatcher->dispatch()
> #1 /usr/share/kanboard/app/Controller/AuthController.php(61): 
> Kanboard\Core\Session\SessionManager->close()
> #2 /usr/share/kanboard/app/Core/Controller/Runner.php(77): 
> Kanboard\Controller\AuthController->logout()
> #3 /usr/share/kanboard/app/Core/Controller/Runner.php(31): 
> Kanboard\Core\Controller\Runner->executeController()
> #4 /usr/share/kanboard/index.php(9): 
> Kanboard\Core\Controller\Runner->execute()
> #5 {main}
>   thrown in 
> /usr/share/php/Symfony/Component/EventDispatcher/EventDispatcher.php on line 
> 48" while reading response header from upstream, client: 192.168.122.1, 
> server: kanboard, request: "GET /logout HTTP/1.1", upstream: 
> "fastcgi://unix:/var/run/php/php-fpm.sock:", host: "kanboard"
> 2024/07/04 20:22:17 [error] 2890#2890: *59 FastCGI sent in stderr: "PHP 
> message: PHP Fatal error:  Uncaught TypeError: 
> Symfony\Component\EventDispatcher\EventDispatcher::dispatch(): Argument #1 
> ($event) must be of type object, string given, called in 
> /usr/share/kanboard/app/Core/Session/SessionManager.php on line 62 and 
> defined in 
> /usr/share/php/Symfony/Component/EventDispatcher/EventDispatcher.php:48
> 
> 
> This is known bug it was fixed in upstream version 1.2.32.
> The PR 5309 in detail was fixing this issue: 
> https://github.com/kanboard/kanboard/pull/5309/files
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers jammy-updates
>   APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 
> 'jammy'), (100, 'jammy-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.5.0-41-generic (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Bug#1072850: python-mkdocs: Please package new version 1.6.0

[Carsten Schoenert]

Tags: help

Hello Boyuan,

Am Sat, Jun 08, 2024 at 08:01:09PM -0400 schrieb Boyuan Yang:
> Source: python-mkdocs
> Severity: normal
> Version: 1.5.3+dfsg-1
> X-Debbugs-CC: b...@debian.org c.schoen...@t-online.de
> 
> Dear Debian python-mkdocs maintainer,
> 
> A new upstream release of mkdocs is available. Please consider reviewing it
> (as well as the compatibility of related packages) and have it packaged in 
> Debian.

I did spend now several days and attempts to work on an updated package
mkdocs based on the latest upstream version 1.6.0.
I think I did covered so far all the points and actions that were needed
to get a newer Debian version prepared.

For now I pushed my WIP to my namespace only.

https://salsa.debian.org/tijuca/python-mkdocs/

Some "ready" to use packages can be picked up on p.d.o.

https://people.debian.org/~tijuca/mkdoc/

The build itself is no problem I guess (the autopkgtest will need
further adjustments too), but I see issues if I'm trying
to browse through the contents of the installed python-mkdocs-doc package.

These issues so far are broken linking, e.g. on the start page

file:///usr/share/doc/mkdocs/html/index.html

the first a href element with the name 'introductory tutorial' is
pointing correctly to 

file:///usr/share/doc/mkdocs/html/getting-started.html

but the button beneath "Getting Started" is linked to

file:///usr/share/doc/mkdocs/html/getting-started

The same is happen to other buttons but also to a href elements all over
the content.
Dimitry did added a patch in the past that is adding
'use_directory_urls: false' to the mkdocs.yaml file that should do
exactly the trick.

https://www.mkdocs.org/user-guide/configuration/#use_directory_urls

Currently I've no idea why this is happen, but I think this behavior
might happen to all mkdocs based documentation in packages if we would
upload the current state to the archive so we need to fix this first
bevor a upload can happen.
My time and my knowledge it currently to limited o give an hint when
a fixed build can happen, I appreciate any help.
Might also be that this is an upstream issue. But it might also be we
are to strict with the removal of some vendored files. So rebuilding all
without any removed upstream files and folder would be the next logical
step.

I'm happy to look into this while DC in Busan with someone! But I will
probably not having time to look into this until DC is starting.

Regards
Carsten

Bug#1073177: apparmot profile: Failed to spawn child process “/usr/lib/thunderbird/glxtest” (Permission denied)

[Carsten Schoenert]

Hello Michael,

Am 14.06.24 um 06:38 schrieb Michael Tokarev:

When starting thunderbird, it displays this error messages:

  [GFX1-]: FireTestProcess failed: Failed to spawn child process
 “/usr/lib/thunderbird/glxtest” (Permission denied)
  [GFX1-]: No GPUs detected via PCI

This is because thunderbird apparmor profile does not let it
to execute /usr/lib/thunderbird/glxtest. Adding that one to
/etc/apparmor.d/usr.bin.thunderbird fixes the issue.


would you mind to provide the data / the line you added there?


I've no idea why thunderbird wants to run glxtest, but this is
a different question entirely.


Well, this is now somehow needed as Thunderbird is checking by this 
which hardware is available for using potentially video acceleration in 
media content that can be included in emails.
Not that we need this, it's probably mostly because the source is still 
based on the Firefox system.


@Intrigeri
I guess this issue isn't fixed in the upstream tree of apparmor and 
should get included there?


--
Regards
Carsten Schönert

Bug#1073068: rustc: Please package rust 1.76.0 or higher

[Carsten Schoenert]

Source: rustc
Severity: wishlist

Dear Maintainer,

Mozilla did release Thunderbird 128.0b1 yesterday, the first beta
version of the next planned ESR version for Thunderbird.
This version (and also the previous version 127.0bx) is requiring a
rustc version at least of 1.76.0, the current version 1.75.0 in Debian
is again to old.

Please consider to prepare a rustc version of 1.76.0 or greater. This
would make the maintainership of Thunderbird more easy as I can track
newer Mozilla Thunderbird version with less effort. Firefox is affected
from the newer version too.
Thank you!

--
Regards
Carsten

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

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

Bug#1072856: bookworm-pu: package djangorestframework/3.14.0-2

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: djangorestframew...@packages.debian.org
Control: affects -1 + src:djangorestframework
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
The user Simon Lyngshede spottet an issue with version 3.14.0-2 in
bookworm which can result in a HTML error 500 in the priject that is
using this version as the Debian package is missing the file
bootstrap-tweaks.css in the static folder.

https://bugs.debian.org/1068747

This is happen due a to agressive removing of existing CSS files while
package build.

[ Impact ]
The potential impact is limited and no data loss will happen, but the
Django application will simply not work and throw an error 500 if the CSS file
can not be found.

[ Tests ]
Currently there are no upstream or autopkgtests which will detect such a
missing file.
Upstream will probably never create such a test because they ship the
needed files within the source.

[ Risks ]
The risk of a potential data loss isn't existing, but the application
that is using that package might loose all of it's functionality.

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

[ Changes ]
The change itself is rather simple, it's a one line fix in debian/rules.
Please see below the output of debdiff.

[ Other info ]
Currently nothing I'm aware of that is needed to get mentioned here.

--
Regards
Carsten

$ debdiff ../djangorestframework_3.14.0-2.dsc 
../djangorestframework_3.14.0-2+deb12u1.dsc
diff -Nru djangorestframework-3.14.0/debian/changelog 
djangorestframework-3.14.0/debian/changelog
--- djangorestframework-3.14.0/debian/changelog 2023-01-31 12:59:37.0 
+0100
+++ djangorestframework-3.14.0/debian/changelog 2024-06-09 08:20:01.0 
+0200
@@ -1,3 +1,14 @@
+djangorestframework (3.14.0-2+deb12u1) bookworm; urgency=medium
+
+  [ Carsten Schoenert ]
+  * [0e3d1fc] d/gbp.conf: Pick up some defaults, adjust to debian/bookworm
+
+  [ Simon Lyngshede ]
+  * [7867bee] d/rules: Don't exclude bootstrap-tweaks.css file
+(Closes: #1068747)
+
+ -- Carsten Schoenert   Sun, 09 Jun 2024 08:20:01 
+0200
+
 djangorestframework (3.14.0-2) unstable; urgency=medium
 
   * Team upload
diff -Nru djangorestframework-3.14.0/debian/gbp.conf 
djangorestframework-3.14.0/debian/gbp.conf
--- djangorestframework-3.14.0/debian/gbp.conf  2023-01-31 12:59:37.0 
+0100
+++ djangorestframework-3.14.0/debian/gbp.conf  2024-06-09 08:19:45.0 
+0200
@@ -1,2 +1,11 @@
 [DEFAULT]
-debian-branch=debian/master
+compression = gz
+debian-branch = debian/bookworm
+upstream-branch = upstream
+pristine-tar = True
+
+[pq]
+patch-numbers = False
+
+[dch]
+id-length = 7
diff -Nru djangorestframework-3.14.0/debian/rules 
djangorestframework-3.14.0/debian/rules
--- djangorestframework-3.14.0/debian/rules 2023-01-31 12:59:37.0 
+0100
+++ djangorestframework-3.14.0/debian/rules 2024-06-09 08:19:45.0 
+0200
@@ -21,7 +21,7 @@
# Don't embed what's already provided elsewhere
$(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/fonts/*
$(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/font-awesome*.css
-   $(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/bootstrap*.css
+   $(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/bootstrap*.min.css
$(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/prettify*.css
$(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/js/bootstrap*.js
$(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/js/jquery*.js

Bug#1068747: python3-djangorestframework: Package does not include bootstrap-tweaks.css file

[Carsten Schoenert]

Control: fixed -1 3.15.1-2
Control: tags -1 bookworm

Hello Simon,

Am Wed, Apr 10, 2024 at 11:26:37AM +0200 schrieb Simon Lyngshede:
 
> Dear Maintainer,
> 
> When deploying a Django application, using the staticfiles module, the
> application will throw a 500, if the user attempts to access the a REST
> endpoint using a normal browser, as the staticfiles module will fail to
> locate the bootstrap-tweaks.css file. The file is shipped be the Django
> REST Framework project, but is excluded by the debian/rules file.
> 
> It happens because the following rule accidentally matches the
> bootstrap-tweaks.css file: 
> $(RM) 
> debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/bootstrap*.css
> 
> The correct rule would be:
> $(RM) 
> debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/bootstrap*.min.css

thanks for the analysis, your are correct.
For unstable this issue is now fixed by 3.15.1-2.
Fixing the issue in bookworm requires another upload to stable-proposed
updates. I'll try to work on this.

Regards
Carsten

Bug#1071425: verilator: No such file or directory at /usr/bin/verilator

[Carsten Schoenert]

Control: forwarded -1 https://github.com/verilator/verilator/issues/5140
Control: severity -1 serious

Hello Bob,

Am Sun, May 19, 2024 at 11:49:24AM +0800 schrieb Bob Wong:
... 
> When I run verilator form command line, it gives me the error Can't exec
> "/usr/bin/../share/verilator/bin/verilator": No such file or directory at
> /usr/bin/verilator line 21. I looked at the package 5.020 and find out version
> 5.024 is missing files. There is no bin folder under share/verilator 
> directory.
> Also, the perl script for verilator seems to miss lots of lines. In the 5.020
> version, there are 528 lines while in the 5.024 version there are only 22
> lines. Please fix the package to make it usable again, and thanks for your
> help.

I thought I did fixed this successfully, but obviously not.

Upstream did change the installation folder for the various verilator_*
scripts *and* binaries from /usr/bin to /usr/share/verilator/.
Which isn't correct as by FHS /usr/share is only intended for
architecture independent code.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

I raised an issue about this in the upstream bug tracker [1] as correcting
this needs a bit more work within the upstream code.
Until then you can use an older version picked from snapshot.debian.org.

[1] https://github.com/verilator/verilator/issues/5140

Regards
Carsten

Bug#1068408: Kicad bundle broken

[Carsten Schoenert]

Hello,

Am 12.04.24 um 19:31 schrieb Javier Vilarroig:

I'm in the same situation.

Right now I can't use Kicad.


you all use Debian testing, you have always the option to pick obviously 
working versions from snapshot.debian.org. Or pull in required packages 
from unstable.
If you need to work with mission critical stuff please use Debian 
stable. For sure you know this.


The situation is a bit more complex, the situation in testing would not 
have happen if the time_64 transition would not have blocked a lot of 
arch related packages for good reason.


Also in the past KiCad was usable with older libraries, which seems not 
to be the case anymore. On the other hand the KiCad application could 
handle such version mismatches far better and give the user some 
feedback what happened.


Within Debian the problem is not within the kicad binary package, this 
is "usable" without the libraries, so the libraries packages need to be 
more strict now which version of kicad they are work with..


--
Regrads
Carsten

Bug#1068008: newer rust needed

[Carsten Schoenert]

Am Wed, Apr 17, 2024 at 09:02:14AM -0400 schrieb Yaroslav Halchenko:
> Also I thought to try to build  deno
> 
> https://github.com/denoland/deno.git
> (ITP - #961337) https://bugs.debian.org/961337 deno
> 
> but it needs 
> 
> ❯ cat rust-toolchain.toml
> [toolchain]
> channel = "1.77.2"
> components = ["rustfmt", "clippy"]
> 
> so we are indeed well behind :-/

Also Thunderbird >= 125.x is depending on a newer rust version in the
archive (equivalent to FF).
Missing a newer rust blocks me from building and adjusting the Debian
packaging of current Thunderbird beta version within experimental. So
please work on a newer rust.

Regards
Carsten

Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded

[Carsten Schoenert]

Hi Guido,

Am 22.03.24 um 16:22 schrieb Carsten Schoenert:

I need to check this again and in detail, because I had recently some
issues as the expected hash ids were different while working with gbp
import and later gbp buildpackage on some package from the kicad
universe. But I think these problems are currently related to the t64
transition.

The last work on TB at the start of the work did work flawless.

@Guido
Please poke me again latest 2 weeks in case I don't have give feedback
until then.


I did a few more working on some of the packages I maintain and I did 
not encounter similar problems with wrong hash ids like a few days back. 
Given the troubled times around the liblzma versions I'm not sure the 
initial issue about the report topic years back is still solved as we 
are back to a version before 5.6.0 again.


My typical "problematic" packages are thunderbird and especially 
kicad-packages3d, I wasn't needed to package a newer version of any of 
these source packages lately.


--
Regards
Carsten

Bug#1057386: ITP: imsprog -- linux chip programmer for CH341a devices

[Carsten Schoenert]

Hello Mikhail,

Am 26.03.24 um 08:37 schrieb Kosolapov Ivan:

Hello, Carsten!
I have built a new version of IMSProg (v1.3.3).
Can you please tell me how I can get this version to you? Do I have to 
upload the new version on mentors.debian or do you get it from GitHub?


I pulled the git tree from GitHub and build the package from that source.

I can build an updated version from the same tree again.
The current entries in debian/latest looking an bit odd and chaotic.

* commit 8fa592e6b5eaa5332580ab0b1cbe7dca766dc3dd (HEAD -> 
debian/latest, origin/debian/latest)

| Author: Mikhail Medvedev 
| Date:   Mon Mar 25 18:33:32 2024 +0300
|
| a new version has been built
|
* commit 21f8b17153bba0472c68f14d0382f3d3d50aa0a6
| Author: Mikhail Medvedev 
| Date:   Mon Mar 25 16:23:43 2024 +0300
|
| Release description has been changed
|
* commit d58dc3f6be7de4b2893f5db819875803c86f769b
| Author: Mikhail Medvedev 
| Date:   Mon Mar 25 15:17:34 2024 +0300
|
| Modify changelog
|
*   commit b9cf508be810d086dfe20a8c1fa3e62c86d02be8
|\  Merge: 347b4bc d8b79c5
| | Author: Mikhail Medvedev 
| | Date:   Mon Mar 25 15:14:51 2024 +0300
| |
| | Update upstream source from tag 'v1.3.3'
| |
| | Update to upstream version '1.3.3'
| | with Debian dir d492f797a1719579b5b6fe214f0a075ca9a1903a
| |
| * commit d8b79c5bfeec760c4ab857072f4fca33e8bd5c74 (tag: v1.3.3, 
origin/main, origin/HEAD)

| | Author: Mikhail Medvedev 
| | Date:   Mon Mar 25 14:47:05 2024 +0300
| |
| | added status register form for 95xxx, 25xxx chips

Can you rebase the last tree commits into one and keep at lest the 
following lines in the changelog? (Once the package is within the 
archive of course such rebasing should not happen anymore. Have a look 
into existing changelog entries from other files for examples how to 
write the entries.)


  * New upstream release 1.3.3
  * Initial release (Closes: #1057386)

The last entry is needed with every new upstream version that is getting 
uploaded for automatic closing the ITP bug report if the FTP master 
chose to accept the package.


--
Regards
Carsten

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

[Carsten Schoenert]

Am 23.03.24 um 18:29 schrieb Matthias Geiger:

I agree that packaging all themes is doable. However, how would I create
a src: package with different upstream tarballs? I could use some help
with that. Providing a virtual package for all themes is also a good idea.


To me you don't need multiple tarballs to archive the goal, you could 
add all the various sources into one tarball. Using so called component 
tarballs brings no gain to me, the usage of them also have 
disadvantages. How these tarballs are getting used did Raphael Herzog 
explain in one of his blog posts [1].


I think you can go like this, arrange the folders and finally create a 
tarball of the top folder.



.
├── kicad-theme1
├── kicad-theme2
├── kicad-theme3
└── kicad-theme...


The creation of this tarball can be done by a script living in the 
debian/ folder. Adding later another theme is simply adding one more 
folder and adjusting d/rules, d/copyright and sequencers maybe.


If you want to create various binary packages adding a new themes will 
require a new binary upload to NEW then. This is no issue, such uploads 
get processed much quicker than a complete new src package.



Would you be ok with this package being maintained under the Electronics
Team ?


Sure, why not. Would be quite logical to place it here.

[1] 
https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/


--
Regards
Carsten

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

[Carsten Schoenert]

Hello Matthias,

Am 23.03.24 um 17:40 schrieb Matthias Geiger:

Hi Carsten,

thanks for maintaining KiCad. What you mentioned is true for Kicad <=
7.0. With 8.0 a change landed enabling installation of colorthemes
system-wide  (see https://gitlab.com/kicad/code/kicad/-/issues/15920).

I already created a package and installed it and it works as intended.
Since this does not touch user files this conforms to Debian policy.
The plugin manager does not show this scheme as installed since it only
looks for user themes.


nice, o.k., then upstream has still some work to do. :-)

Would it not better creating one src:package which would package the 
various themes all together that are out there? e.g. named kicad-themes


I dislike a bit multiple packages that a user needs to know (and to 
install then) if all could get packaged into one.
There could be of course also a virtual package kicad-themes which pulls 
in the installation of all the real other theme packages.


Most of the other themes are not under heavy development and will only 
change randomly.
Downside otoh is you will need to run a own scripting to detect changes. 
Is also not that complicated.


But that's up to you if you can agree on my ideas.

--
Regards
Carsten

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

[Carsten Schoenert]

Hello Matthias,

Am 23.03.24 um 16:51 schrieb Matthias Geiger:

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, werdah...@riseup.net

* Package name: kicad-gruvbox-theme
   Version : 1.1.0
   Upstream Contact: Alexander Brevig
* URL : https://github.com/AlexanderBrevig/kicad-gruvbox-theme
* License : MIT
   Programming Lang: n/a
   Description : Gruvbox colorscheme for KiCadi

A simple gruvbox colorscheme for the EESchema and PCBNew editors within
KiCad. KiCad 8 allows for the system-wide installation of
colorschemes, thus ITP'ing now.


how is this system wide installation intended to work.

Even the upstream project site states the installation needs to happen 
into ~/.config/kicad/colors or ~/.config/kicad/6.0/colors (besides it 
uses the older version 6.0 as user folder)


As long as I follow this feature I'm not aware that any system wide 
installation of themes is now possible.


Given it is possible, how the internal Plugin and Content Management 
will handle this?


--
Regards
Carsten

Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded

[Carsten Schoenert]

Hi Guido,

Am 22.03.24 um 09:35 schrieb Guido Günther:
...

I got pointed here by Amin.
As mentioned, pristine-tar can handle multi-block xz images so this is
not an issue. Further xz-utils v5.6.0+ (currently in unstable/ testing)
is using multi threaded compression by default.


ahh, that would explain why my last work on kicad-packages3d and in 
detail the pristine-tar commit did not take the usual hour and did take 
only about 10-15min! :-)



So this *might* be considered fixed. >

Thanks a lot for the follow up. Carsten can you confirm with TB if this works as
expected?


I need to check this again and in detail, because I had recently some 
issues as the expected hash ids were different while working with gbp 
import and later gbp buildpackage on some package from the kicad 
universe. But I think these problems are currently related to the t64 
transition.


The last work on TB at the start of the work did work flawless.

@Guido
Please poke me again latest 2 weeks in case I don't have give feedback 
until then.


--
Mit freundlichen Grüßen
Carsten Schönert

Bug#1065749: ITP: flask-debugtoolbar -- Debugging toolbar overlay information for Flask applications

[Carsten Schoenert]

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

* Package name: flask-debugtoolbar
  Version : 0.14.1
  Upstream Contact: Pallets 
* URL : https://github.com/pallets-eco/flask-debugtoolbar
* License : BSD-3-clause
  Programming Lang: Python, JS
  Description : Debugging toolbar overlay information for Flask applications

 Flask is a micro web framework for Python based on Werkzeug, Jinja 2 and good
 intentions.
 .
 This python3 package adds a toolbar overlay to Flask applications containing
 useful information for debugging.

This package is the equivalent of python-django-debug-toolbar but for
Flask.

I intend to maintain this packge within the DPT.

Bug#1057386: ITP: imsprog -- linux chip programmer for CH341a devices

[Carsten Schoenert]

Hello Mikhail,

Am 03.03.24 um 20:35 schrieb Kosolapov Ivan:

Hello, Carsten!
Regarding W: imsprog: appstream-metadata-missing-modalias:
I was already informed yesterday by Alt-Linux colleagues about the 
erroneous comment format in file 99-CH341.rules.
I have already fixed it in 
https://github.com/bigbigmdm/IMSProg/commit/8be1584358b6c7a4cb0224bc813e3e284d62cb42

Is there an urgent need for a new release because of this fix?


I think no, but I can upload a newer version to NEW every time.
It might be that a FTP-Admin is "complaining" about that warning, but a 
reject of the package should not happen.


My guess is that a review of the package will take a bit of time, I'd be 
surprised if it will get processed within of days.
So proceed with your usual development process and ping me once you 
released a new version which has fix included. I'll prepare a new upload 
then.


--
Regards
Carsten

Bug#1057386: Subject: ITP: imsprog -- linux chip programmer for CH341a devices

[Carsten Schoenert]

Hello Mikhail,

Am Mon, Dec 04, 2023 at 01:48:14PM +0300 schrieb Mikhail Medvedev:
> Package: wnpp
> Severity: wishlist
> Owner: Mikhail Medvedev 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name    : imsprog
>   Version : 1.1.2-12
>   Upstream Author : Mikhail Medvedev 
> * URL : https://github.com/bigbigmdm/IMSProg
> * License : GPL-3
>   Programming Lang: C, C++, Bash
>   Description : GUI Chip programmer for CH341a devices
> 
> 
> IMSProg  -  QT-based  GUI  application  -  I2C,  MicroWire and SPI EEP‐
> ROM/Flash chip programmer for CH341a devices. The IMSProm is a free I2C
> EEPROM  programmer tool for CH341A device based on QhexEdit2 and modify
> SNANDer programmer.
> 
>  IMSProg consists of three executable modules:
> 
>  1. IMSProg - the chip programmer itself.
> 
>  2. IMSProg_editor - chip database editor.
> 
>  3. IMSProg_database_update - online chip database update from  the ex‐
> ternal web-server.

the content and the build of the package is fine, also no real blockers
through Lintian vissible.

Except this warning:

W: imsprog: appstream-metadata-missing-modalias-provide 
usr/lib/udev/rules.d/99-CH341.rules

I'm not thiat deep in the internals of imsprog and maybe this is a false
positive, if not have a loo at these resources to hopefully get this
warning fixed:

>From https://freedesktop.org/software/appstream/docs/chap-Metadata.html

...


A modalias glob representing the hardware types (for example USB,
PCI, ACPI, DMI) this component handles. Useful for installing
printer drivers or other USB protocol drivers for smartphones,
firmware, and out of tree kernel drivers.
...

In the Debian Wiki
https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

The Lintian warning should get addressed in a further new release.

For now to me it's o.k. to upload the current version 1.3.2-1

Regrads
Carsten

Bug#1057386: Upload of imsprog

[Carsten Schoenert]

Hello Fabio,

Am 20.02.24 um 10:28 schrieb Fabio Fantoni:

Hi, is it possible to upload this shortly to try to include before the
feature freeze on Ubuntu 24.04? (February 29th)

I helped to improve the packaging, and now seems ready to me, but I'm
only DM and I can't upload new packages.

2 DD did a review on mentors over the past weeks and the recommended
changes have been made, but it seems they haven't had time to review it
again recently.


in a short term I need to answer no, I can't process this RFP on a quick 
run.
The uploader is responsible for the package and the upload itself, no 
matter if other DDs did have already done a review of the package in 
detail. Before the weekend I wont have time to dig into the current 
packaging.


--
Regards
Carsten

Bug#1057386: [Pkg-electronics-devel] imsprog , #1057386

[Carsten Schoenert]

Hello Ivan,

Am 14.02.24 um 09:07 schrieb Kosolapov Ivan:

Good day!
I am developer of the imsprog package.
(https://mentors.debian.net/package/imsprog , #1057386)
  This is a GUI tool for programming BIOS chips, automotive memory, 
satellite and TV receiver memory chips and much more using the popular 
CH341a programmer. It has no analogues in linux-systems. By many 
parameters it surpasses flashrom, because IMSProg can program not only 
SPI FLASH ROM chips, but also chips of I2C and MicroWire series, and 
also uses graphical interface. Some IMSProg functions are unique, such 
as reading the SFDP register and the ability to modify the chip's system 
registers.
I would be very grateful if this package could appear in Debian. I need 
a sponsor.


that looks like an interesting package.
I'm will to have a look and also to sponsor later potentially.

--
Regards
Carsten

Bug#1063786: nss: Please package recent version 3.97 of NSS

[Carsten Schoenert]

Source: nss
Version: 2:3.96.1-1
Severity: wishlist

Hello Mike,

could you please package version 3.97 of the NSS package?
I'm trying to package Thunderbird 123.x for experimental but this is
depending on a newer libnss3-dev package.

Thanks and regards!
Carsten

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

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

Bug#1051470: RFP: esbuild-sass-plugin -- Plugin for esbuild to handle Sass & SCSS files

[Carsten Schoenert]

The list of deps isn't that long, but there are some other packages need
to be around before esbuild-sass-plugin can be packaged.

$ date
Mo 12. Feb 08:15:18 CET 2024
$ npm2deb depends -b -r esbuild-sass-plugin
Dependencies:
NPM   Debian
esbuild-sass-plugin (3.0.0)   None
├─ resolve (^1.22.6)  node-resolve 
(1.22.8+~cs5.34.15-2)
└─ sass-embedded (^1.70.0)None
   ├─ @bufbuild/protobuf (^1.0.0) None
   ├─ buffer-builder (^0.2.0) None
   ├─ immutable (^4.0.0)  node-immutable (4.3.4-1)
   ├─ rxjs (^7.4.0)   None
   │  └─ tslib (^2.1.0)   node-tslib (2.4.1-1)
   ├─ supports-color (^8.1.1) node-supports-color 
(8.1.1+~8.1.1-1)
   └─ varint (^6.0.0) None

Bug#1062582: mkdocs-material: Files installed under wrong dir (/usr/lib/python3.11), breaking reverse-deps

[Carsten Schoenert]

Am Thu, Feb 01, 2024 at 09:24:17PM -0500 schrieb Boyuan Yang:
 
> I believe your package should install files under /usr/lib/python3/ instead.
> If an immediate fix could not be found, please consider rebuilding your
> package so that files are also provided under /usr/lib/python3.12/ .

I can confirm that placing the files of mkdocs-material in
/usr/lib/python3/ is fixing the upstream testing issues for
mkdocstring-python-handler.

Regards
Carsten

Bug#1062655: O: libcoap3 -- C-Implementation of CoAP - libraries API version 3

[Carsten Schoenert]

Package: wnpp
Severity: normal
X-Debbugs-Cc: libco...@packages.debian.org
Control: affects -1 + src:libcoap3

I intend to orphan the libcoap3 package.

The package description is:
 Lightweight application-protocol for devices that are constrained their
 resources such as computing power, RF range, memory, bandwidth, or network
 packet sizes. This protocol, CoAP, is developed in the IETF working group
 "CoRE",  and was
 standardized in RFC 7252.
 .
 The libcoap library v3 has DTLS functionality included based on TLS
 functions provided by GnuTLS or OpenSSL with enhanced behavior to the
 previous API version.
 .
 This package contains the various libcoap libraries based on API v3 with
 and without DTLS functionality.

Bug#1062257: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition

[Carsten Schoenert]

Hello Steve,

Am 31.01.24 um 21:59 schrieb Steve Langasek:
...

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.

 ^^

 Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.


I'm a bit puzzled and disappointed.

libcopap3 isn't a package that is within the QA group nor is it bit rotting.

What is the rationale behind rising a bug report at 9:51pm my time and 
firing a *direct* NMU upload just 11min later (according to the time 
stamps from the emails)?
I as the uploader for libcoap have no chance to do any action on this 
bug report! This behavior I'm not expecting within Debian.

What are the plans now with forwarding the underlying issue to upstream?
Upstream is very responsive and I've good contacts to the upstream 
authors, but who is doing this work now?


I read the wiki page mentioned from the initial email again, also there 
I can't find a written plan that would explain me why the bug reporting 
together with a direct upload did happen. I see no plan there what will 
happen on what time.


Why no usual muss bug filling did happen so groups and maintainers would 
have some knowledge about these planned changes? BTW: I've no problem 
with the technical thing what is happen, but I need to deal also with 
other things too like a CVE fix for libcopa3.


--
Regards
Carsten

Bug#1061237: bepasty FTBFS with Werkzeug >= 3.x

[Carsten Schoenert]

Hello Elena,

Am 21.01.24 um 11:11 schrieb Elena ``of Valhalla'':

Thanks for the patch!

I see that the patch is marked as

Forwared: https://github.com/bepasty/bepasty-server/issues/312

but I can't see any mention of it on that page: am I missing something
in the github interface (this is pretty likely)? or should I forward it
upstream myself?


I wanted to write something into the upstream report but hold this back 
for now.
If you could take some action within the upstream report I'd really 
appreciate that as this saves time on my side. Thank you!


--
Regards
Carsten

Bug#1061237: bepasty FTBFS with Werkzeug >= 3.x

[Carsten Schoenert]

Source: bepasty
Version: 1.2.0-2
Severity: normal

Dear Maintainer,

while preparing the upload of Flask 3.x and the depending Werkzeug 3.x
package I noticed that bepasty is FTBFS in case these packages with
versions >= 3.x are around in the chroot.

This is mostly happen as bepasty upstream isn't ready for these newer
versions.

https://github.com/bepasty/bepasty-server/issues/312

The failing test for amd64 is visible here:
https://ci.debian.net/packages/b/bepasty/unstable/amd64/41844896/

Fixing this issue isn't that difficult, instead of depending on
functionality from Werkzeug it's easier to use urllib from the Python
stdlib implementaion.

Similar to how a PR in flask-openid is targeting a fix on the same
problem in their source bepasty can be using the same attempt.

https://github.com/pallets-eco/flask-openid/pull/71/files

I added a patch to apply for convenience.

I intend to raise the severity for this report once we finalized
preparation for uploading Flask and Werkzeug 3.x into unstable.

Regards
Carsten

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From c34083257ced9d3034553c624a68878ec23ac4eb Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Sun, 21 Jan 2024 10:34:31 +0100
Subject: [PATCH] Rebuild patch queue from patch-queue branch

Added patch:
0006-src-Use-urllib.parse.quote-instead-of-werkzeug.url_q.patch

Fixes potentially issues while running the tests with installed packages
of Flask and Werkzeug which are greater than 3.x.
---
 ...arse.quote-instead-of-werkzeug.url_q.patch | 58 +++
 debian/patches/series |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 
debian/patches/0006-src-Use-urllib.parse.quote-instead-of-werkzeug.url_q.patch

diff --git 
a/debian/patches/0006-src-Use-urllib.parse.quote-instead-of-werkzeug.url_q.patch
 
b/debian/patches/0006-src-Use-urllib.parse.quote-instead-of-werkzeug.url_q.patch
new file mode 100644
index 000..bcb5d74
--- /dev/null
+++ 
b/debian/patches/0006-src-Use-urllib.parse.quote-instead-of-werkzeug.url_q.patch
@@ -0,0 +1,58 @@
+From: Carsten Schoenert 
+Date: Sun, 21 Jan 2024 09:24:14 +0100
+Subject: src: Use urllib.parse.quote instead of werkzeug.url_quote
+
+Forwared: https://github.com/bepasty/bepasty-server/issues/312
+---
+ src/bepasty/apis/lodgeit.py | 4 ++--
+ src/bepasty/views/upload.py | 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/bepasty/apis/lodgeit.py b/src/bepasty/apis/lodgeit.py
+index 980cb9e..9482f48 100644
+--- a/src/bepasty/apis/lodgeit.py
 b/src/bepasty/apis/lodgeit.py
+@@ -1,10 +1,10 @@
+ from io import BytesIO
++import urllib
+ 
+ from flask import request
+ from flask.views import MethodView
+ from pygments.lexers import get_all_lexers
+ from werkzeug.exceptions import Forbidden
+-from werkzeug.urls import url_quote
+ 
+ from ..constants import FOREVER
+ from ..utils.http import redirect_next
+@@ -53,4 +53,4 @@ class LodgeitUpload(MethodView):
+ maxlife_timestamp = FOREVER
+ name = create_item(f, filename, size, content_type, content_type_hint,
+maxlife_stamp=maxlife_timestamp)
+-return redirect_next('bepasty.display', name=name, 
_anchor=url_quote(filename))
++return redirect_next('bepasty.display', name=name, 
_anchor=urllib.parse.quote(filename))
+diff --git a/src/bepasty/views/upload.py b/src/bepasty/views/upload.py
+index fe3526b..88b778f 100644
+--- a/src/bepasty/views/upload.py
 b/src/bepasty/views/upload.py
+@@ -2,11 +2,11 @@ import os
+ import errno
+ from io import BytesIO
+ import time
++import urllib
+ 
+ from flask import abort, current_app, jsonify, request, url_for
+ from flask.views import MethodView
+ from werkzeug.exceptions import NotFound, Forbidden
+-from werkzeug.urls import url_quote
+ 
+ from ..constants import COMPLETE, FILENAME, SIZE
+ from ..utils.date_funcs import get_maxlife
+@@ -56,7 +56,7 @@ class UploadView(MethodView):
+ maxlife_timestamp = int(time.time()) + maxtime if maxtime > 0 else 
maxtime
+ name = create_item(f, filename, size, content_type, 
content_type_hint, maxlife_stamp=maxlife_timestamp)
+ kw = {}
+-kw['_anchor'] = url_quote(filename)
++kw['_anchor'] = urllib.parse.quote(filename)
+ if content_type == 'text/x-bepasty-redirect':
+ # after creating a redirect, we want to stay on the bepasty
+ # redirect display, so the user can copy the URL.
diff --git a/debian/patches/series b/debian/patches/series
index 342bea7

Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Carsten Schoenert]

Hello Julian,

Am 04.01.24 um 10:23 schrieb Julian Gilbey:
...

The build of src:flask is depending on python3-werkzeug >= 3.x, which has
itself a dependency on python3-markupsafe, so if you spot a missing direct
dependency I'm interested how this comes to play as Markupsafe should be
around at build time.


In the debian/experimental branch of python-werkzeug, debian/control
does not mention python3-markupsafe, but it should do.


hmm, you were talking about Werkzeug, I was within the src:flask 
package. A bit of misunderstanding.
If you spot a issue in src:python-werkzeug than of course that's great 
you fixed this!


--
Regards
Carsten

Bug#1059538: flask-socketio: Please package recent version 5.3.6

[Carsten Schoenert]

Am Wed, Dec 27, 2023 at 08:48:56PM +0100 schrieb Carsten Schoenert:
 
> Updating your package to the most recent version should fix the failing
> tests hopefully.

I've done a import of the version 5.3.6, did a simple build of the new
sources without further adjustments and can confirm that a build and a
run of the tests do pass against the current archive versions in
unstable and experimental.

Please consider updating your package so we can move further with updating
Flask and Werkzeug > 3.
I intend to proceed with uploading newer versions of Flask and Werkzeug
at the end of January 2024.

Thanks!

Regards
Carsten

Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Carsten Schoenert]

Hello Gregor,

Am 22.12.23 um 00:04 schrieb Gregor Riepl:


My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit
for release, it should be enough to upgrade to 2.3.5 to address these
unit test failures.


I did come to the conclusion that Werkzeug 2.3.x has some bigger changes 
that will break most of the existing packages in some way. The main 
differences to Werkzeug 3.x than isn't that big.



flask-login got recent updates which so far I've seen will fix these
issues in the test suite. So if you want to push things further try to
update/patch flask-login to a recent version targeting experimental.
Just rebuilding flask-login against the version of python3-werkzeug in
experimental will not fix the problems, so also not an intermediate
update to 2.3.5, Python 3.12 is now very strict about deprecation
warnings.


That doesn't make any sense to me. These deprecations are obviously in
werkzeug and not flask-login. Why would changes in flask-login fix them?


Because a updated flask-login and other (updated) packages have also 
underlying changes that require than a updated package of Werkzeug. And 
some upstream projects did change their source in a way so they can deal 
different versions of Werkzeug. So a usual update is magical fixing 
build issues we did have in older versions against recent Flask/Werkzeug 
versions.


I was able to fix not all of the current fallout, but quite a few of them.

--
Regards
Carsten

Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Carsten Schoenert]

Hello Julian,

Am 03.01.24 um 22:22 schrieb Julian Gilbey:

Just to throw in: these werkzeug failures are also causing a similar
FTBFS in debugpy; I've temporarily addressed it by skipping these unit
tests, but that's not a great solution.

I just took a quick look at upgrading the unstable/testing version of
werkzeug to 2.3.8 in the meantime.  It was pretty quick, and the
package tests all pass.  Shall I upload it to unstable?


in the end it's up to you. I personally still see no real gain in doing 
such a version bump if we could spend the same time on fixing issues we 
currently see for Flask/Werkzeug >= 3.x given that we need to migrate 
any way in a not to far future. Why spend now time on things that could 
happen already within the past 6 months? What do we really gain?


And, in case you decide to upload Werkzeug 2.3.8, my guess is you will 
see almost the same fallout as that is still visible for the both 
packages with the version bump to 3.x in experimental. With one 
exception, it will produce pressure to fix out the issues we seen until 
now even more.


I worked on a lot of packages that had FTBFS or test suite issues in the 
past 2-3 weeks, the current queue of outstanding packages for 
Flask/Werkzeug 3.x is down to 5 packages.
I've seen other Python team members who did also some upload to fix 
packages, thank you all for working on that.


https://qa.debian.org/excuses.php?experimental=1&package=python-werkzeug
https://qa.debian.org/excuses.php?experimental=1&package=flask

flask-dance (python-werkzeug)
I've done several attempts to get it build with the newer versions, it's 
tricky and in my opinion the upstream package isn't really ready for the 
newer versions.

Would need open a upstream issue about the problems to get that addressed.

onionshare (python-werkzueg)
Did not look that much yet into the culprit, might be easy to fix.
https://github.com/onionshare/onionshare/pull/1677
It's tiring to work on a active upstream project that did the last 
version update now more than one year ago.



beets (flask)
Fixed locally, waiting on response from Stefano due missing commits in 
the Salsa tree.


flask-dance (flask)
Same as above.

flask-socketio (flask)
Might be fixed by a newer upstream version, I opened a wishlist bug 
about updating (http://bugs.debian.org/1059538). Maybe someone can cross 
check?


ironic-inspector (flask)
Did not look deep into that yet. Might be fixed by a newer available 
upstream version. The package currently is marked for auto removal on 
25th January, I guess Thomas Goirand is happily taking any help on this 
package.




(Incidentally, while doing this, I spotted one bug with the current
experimental version: it is missing a Build-Depends on
python3-markupsafe.)


The only requirement for Markupsafe in Flask 3.0.0 is listed in 
requirements/tests-pallets-min{.*}.


The build of src:flask is depending on python3-werkzeug >= 3.x, which 
has itself a dependency on python3-markupsafe, so if you spot a missing 
direct dependency I'm interested how this comes to play as Markupsafe 
should be around at build time.


--
Regards
Carsten

Bug#1058327: python-limits: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Carsten Schoenert]

Control: reassign -1 python3-protobuf 3.21.12-8
Control: affects -1 python-limits

Dear maintainer,

reassigning this issue as the current problem is happen in the package
python3-protobuf from my current POV. The relevant part seems to this:

> /usr/lib/python3/dist-packages/google/protobuf/internal/api_implementation.py:104:
>  in 
> from google.protobuf.pyext import _message
> E   SystemError:  returned a result with an 
> exception set

Trying to search for this error message got no useful findings. The only
reports about similar issue where about some missing linking in some C++
library that is used by python3-protobuf. Maybe now the current seen
issue is related to something similar.

I tried also the current version of python3-protobuf from experimental
3.25-1 but the output is completly the same as with the version from
unstable.
Is it possible to see waht is within the 'exception set' mentione din
the error output?

OTOH I can call the import within a running python3 shell in testing
without problems. So maybe some environment is missing or wrong withing
the package build setup?

Regards
Carsten

Am Tue, Dec 12, 2023 at 09:24:16AM +0100 schrieb Lucas Nussbaum:
> Source: python-limits
> Version: 3.6.0-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231212 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_build
> > I: pybuild base:310: /usr/bin/python3.12 setup.py build 
> > running build
> > running build_py
> > creating /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/__init__.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/version.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/limits.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/_version.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/strategies.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/errors.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/util.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > copying limits/typing.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits
> > creating /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/__init__.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/redis_sentinel.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/etcd.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/memory.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/base.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/memcached.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/mongodb.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/redis_cluster.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/registry.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > copying limits/storage/redis.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage
> > creating /<>/.pybuild/cpython3_3.12_limits/build/limits/aio
> > copying limits/aio/__init__.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio
> > copying limits/aio/strategies.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio
> > creating 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > copying limits/aio/storage/__init__.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > copying limits/aio/storage/etcd.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > copying limits/aio/storage/memory.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > copying limits/aio/storage/base.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > copying limits/aio/storage/memcached.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > copying limits/aio/storage/mongodb.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > copying limits/aio/storage/redis.py -> 
> > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage
> > running egg_info
> > creating limits.egg-info
> > writing limits.egg-info/PKG-INFO
> > writing dependency_links to limits.egg-info/dependency_links.txt
> > writing requirements to limits.egg-info/requires.txt
> > writing top-level names to limits.egg-info/top_level.txt
> > writing manifest file 'limits.egg-info/SOURCES.txt'
> > reading manifest file 'limits.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in'
>

Bug#1059016: kicad: add loongarch64 support

[Carsten Schoenert]

Hello Dandan,

Am 19.12.23 um 12:20 schrieb zhangdandan:

Dear maintainers,

The kicad source package lacks LoongArch architecture support.
Please consider the patch I have attached.

The kicad source package was compiled successfully on my local loong64
rootfs environment.
If you have any questions, you can contact me at any time.


in preparation for the current KiCad version 7.0.10 I packaged first the 
latest release version 42 of NGspice.
The buildd overview for the resulting upload shows that ngspice isn't 
can't get run the configuration successfully on loongarch64.


https://buildd.debian.org/status/fetch.php?pkg=ngspice&arch=loong64&ver=42%2Bds-1&stamp=1703970458&raw=0

The relevant part to me is probably this:


S parameter analysis enabled
GNU readline disabled.
Checking for editline:
checking for editline/readline.h... no
configure: error: Couldn't find BSD editline headers.
cd debian/build/ngspice && tail -v -n \+0 config.log


Maybe just a build dependency is missing?
Could you please have a look? Without ngspice support KiCad is missing a 
important part.


--
Regards
Carsten

Bug#1059538: flask-socketio: Please package recent version 5.3.6

[Carsten Schoenert]

Source: flask-socketio
Version: 5.3.2-1
Severity: wishlist

Dear Maintainer,

please consider updating your package to the current most recent version
5.3.6.

We are in prearation for updating Flask to version 3.x in unstable in
the next future. For now we've upload Flask and Werkzeug 3.x to
experimental.

The current version of flask-socketio in unstable and testing is failing
in the autopkgtest with python3-werkzeug 3.0.1-1 and python3-flask 3.0.0-1
available in experimental.

https://ci.debian.net/packages/f/flask-socketio/unstable/amd64/41360754/

Updating your package to the most recent version should fix the failing
tests hopefully.

Regards
Carsten

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

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

Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Carsten Schoenert]

Hello Gregor,

Am Thu, Dec 21, 2023 at 02:00:40PM +0100 schrieb Gregor Riepl:
> I don't see any other errors in the log except for the ast.Str deprecation
> warnings, and they all come from python-werkezug and not this package.
> 
> Reassiging the bug.
> Upstream has already fixed this in in 2.3.5, by the way:
> https://github.com/pallets/werkzeug/issues/2704
> 
> I can see that 3.0.1 is currently in experimental, but it would be enough to
> upgrade to the latest 2.x to fix this issue.

this makes not really sense to me. Flask 3.0.0 and Werkzeug 3.0.0 was
released on 09-30-2023, so almost three months before. Putting energy
into Flask 2.3.5 and fix other related packages while 3.x is on the way
is a waste of time in my eyes as we would need to work at least twice on
some packages...

flask-login got recent updates which so far I've seen will fix these
issues in the test suite. So if you want to push things further try to
update/patch flask-login to a recent version targeting experimental.
Just rebuilding flask-login against the version of python3-werkzeug in
experimental will not fix the problems, so also not an intermediate
update to 2.3.5, Python 3.12 is now very strict about deprecation
warnings.

Regards
Carsten

Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)

[Carsten Schoenert]

Am 15.12.23 um 20:43 schrieb Cyril Brulebois:

With these small modifications I can currently use the d-i on my X1 G11
without further issues. A small exception, as the firmware-iwlwifi/testing
can't provide the required firmware files right now they need to get
provided on an additional inserted media.


Great, thanks. Do you actual need to modprobe $module at that point? I
thought the block right after that should modprobe -r/modprobe iwlwifi
on its own? (But it wasn't sufficient before you starting unloading
iwlmvm.)


The code block above is already still trying to do this removal and 
loading of iwlwifi, but is of course not working due module deps. So 
this not working call are still visible in the logs. I'd say it's not 
nice at the moment but in the end nothing more.



-%<- line 408++
# remove and reload modules so they see the new firmware
for module in $modules; do
if ! nic_is_configured $module; then
log "removing and loading kernel module $module"
log_output modprobe -r $module || true
log_output modprobe $module || true
->%


That's something I was not able to catch nicely for the iwlwifi 
module/driver, but my understanding of the code and the functions calls 
isn't good enough right now. For more diving in I'd need to build up a 
better testing environment. I'm not able to do this at the moment.


I guess over time we will see more of such corner cases with a required 
dedicated module reload behavior. Means we need to add more code that is 
able to handle this. I haven't a good approach how a generic code for 
this could look like.


...

If you are fine I can raise a MR for easy pulling in. Otherwise feel free to
comment on my changes.


I know mixed stuff isn't too nice, and unifying might be appealing, but
that makes cherry-picking stuff harder, so I tend to only unify things
when I'm actually changing code… Others might feel differently.


This is quite always depending on the POV :-) , but I'm emotionless on 
this, the maintainers decide how to deal with such things as it's their 
time and responsibility in the end.

So I'll drop this patch.


Well spotted, for the typo.


Naaa, the spelling correction was highlighting the misspelled word. :-)

---
Regards
Carsten

Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)

[Carsten Schoenert]

Hello Cyril,

Am 13.12.23 um 20:16 schrieb Cyril Brulebois:

Carsten Schoenert  (2023-12-13):

The "trick" is to unload the iwlmvm module instead and load afterwards
the module iwlwifi again.


See the very bottom of check-missing-firmware.sh (hw-detect repository),
the loop over $modules. You could try intercepting $module = iwlwifi,
and adding a modprobe -r theotherone beforehand.


thank you very much for pointing me!

I did play around a bit and was adding and testing the mentioned approach.

https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e

With these small modifications I can currently use the d-i on my X1 G11 
without further issues. A small exception, as the 
firmware-iwlwifi/testing can't provide the required firmware files right 
now they need to get provided on an additional inserted media.


I did also same small s/space/tab modifications with no code changes 
afterwards in check-missing firmware.sh so the indentations are now 
unified to use tabs again and fixing also a small typo.


https://salsa.debian.org/tijuca/hw-detect/-/commit/2a3c045a72b4f31fc818b7f639daf5c08b7e2e5a

If you are fine I can raise a MR for easy pulling in. Otherwise feel 
free to comment on my changes.


--
Regards
Carsten

Bug#1058698: mozilla-devscripts should be removed from testing/unstable

[Carsten Schoenert]

Hello Mechtilde,

Am Thu, Dec 14, 2023 at 07:09:16PM +0100 schrieb Mechtilde:
> Hello Mathias,
> 
> thanks for the hint,
> 
> At this time mozilla-devscript is needed when you want to build
> Mozilla-AddOns from the *.xpi.
> 
> So we need to elaborate another way to do it.

I've dropped mozilla-devscripts as an dependency for thunderbird long
ago.
To get the l10n XPI files creatable I picked up the main part of
mozilla-devscripts, the shell script xpi-pack.sh, and placed it within
the debian/ folder.

https://salsa.debian.org/mozilla-team/thunderbird/-/commit/b31360b05e048826571245a2fda26d56592da435

We call this shell script then directly in debian/rules, it's quite
simple and straight forward to use.

https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/sid/debian/rules#L134

I think shipping this shell script now in only a few source packages is
acceptable, otherwise we would need to fix mozilla-devscripts with a bit
effort for not really big gain.

Another option could be to move the XPI package build functionaliy into
some debhelper package, but I haven't looked really seriously into any
option.

Regards
Carsten

Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)

[Carsten Schoenert]

Hi,

Am Thu, Mar 03, 2022 at 10:04:55AM +0700 schrieb Arnaud Rebillout:
> A Kali Linux user reported a fail install on a Dell XPS 9510. For the
> background, the Kali Linux installer is a super lightweight fork of the
> Debian installer, kept in sync with Debian.

I experience the same issue with a shiny new Lenovo Thinkpad X1 Carbon
X11 using the net-installer from 2023-12-07.
This model is using a Intel Wi-Fi® 6E AX211, 802.11ax 2x2 Wi-Fi +
Bluetooth 5.3 hardware.

The full specs is availabe here:

https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Carbon_Gen_11/ThinkPad_X1_Carbon_Gen_11_Spec.pdf

...
> The reason I'm opening this bug against Debian is because, while looking
> at the logs, a few lines caught my eyes. This is in the screenshot #3 in
> the imgur.com link above:
> 
>   check-missing-firmware: removing-and-loading kernel module iwlwifi
>   check-missing-firmware: modprobe: FATAL: Module iwlwifi is in use.
> 
> I wonder if those lines are harmless, or if it really indicates that the
> iwlwifi module can't be reloaded, therefore the wifi is not functional.
> Since someone documented on the Debian wiki that the firmware-iwlwifi is
> needed, and then the WiFi works, it seems that either those lines are
> harmless, or the iwlwifi is not always successfully reloaded.

No, these lines of course not harmless as they indicate that the iwlwifi
module couldn't be removed as the module is still in use. This happens
as this modul has dependencies as it's used by iwlmvm.

# lsmod | grep iwl
iwlmvm  589824  0
mac80211   1392640  1 iwlmvm
iwlwifi 544768  1 iwlmvm
cfg80211   1343488  3 iwlmvm,iwlwifi,mac80211
rfkill   40960  2 iwlmvm,cfg80211

The "trick" is to unload the iwlmvm module instead and load afterwards
the module iwlwifi again.

Doing so I was able to bring up a WLAN based interface on my X1 G11
after I provided the required firmware files for this chipset within the
installer was running.

I basically understand whats going on in check-missing-firmware.sh, I'm
not able to come up with a patch, if someone has some lines of code
where I can start with to dig deeper into I'm willing to work on this.

My guess is that once the needed firmware for the AX211 chipset is
included in the net-installer images the issue I currently see will not
be happen anymore. But in fact more users in the future will see this
issue as the unloading and new loading of the modules needs to be
handled differently to the current implementation.

Note: The needed firmware files for the X1 G11 are available by the
release of upstream linux-firmware 2023 

Regards
Carsten

Bug#1058575: glogic: Fails to start due AttributeError

[Carsten Schoenert]

Package: glogic
Version: 2.6-6
Severity: serious

Dear Maintainer,

qlogic isn't usable any more in unstable and testing.
It fails to start as a calling of a Python function raises a
AttributeError.


$ glogic
/usr/lib/python3/dist-packages/glogic/MainFrame.py:4: PyGIWarning: Gtk was 
imported without specifying a version first. Use gi.require_version('Gtk', 
'4.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk, Gdk, GdkPixbuf
Traceback (most recent call last):
  File "/usr/bin/glogic", line 20, in 
from glogic.MainFrame import MainFrame
  File "/usr/lib/python3/dist-packages/glogic/MainFrame.py", line 18, in 

themed_icons = Gtk.IconTheme.get_default()
   ^
AttributeError: type object 'IconTheme' has no attribute 'get_default'

Rgards
Carsten

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

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

Versions of packages glogic depends on:
ii  gir1.2-gtk-3.03.24.38-6
ii  python3   3.11.4-5+b1
ii  python3-gi3.46.0-1+b1
ii  python3-gi-cairo  3.46.0-1+b1

glogic recommends no packages.

Versions of packages glogic suggests:
ii  fonts-liberation  1:2.1.5-3

-- no debconf information

Bug#1058036: ITP: blanket -- Listen to different sounds

[Carsten Schoenert]

Hello Danial,

Am 11.12.23 um 14:06 schrieb Danial Behzadi:

Package: wnpp
Severity: wishlist
Owner: Danial Behzadi 
X-Debbugs-Cc: debian-de...@lists.debian.org, dani.be...@ubuntu.com

* Package name: blanket
   Version : 0.6.0
   Upstream Contact: Rafael Mardojai CM 
* URL : https://github.com/rafaelmardojai/blanket
* License : GPL-3+
   Programming Lang: Python
   Description : Listen to different sounds

Improve focus and increase your productivity by listening to different
sounds. Or allows you to fall asleep in a noisy environment.


even after visiting the upstream home I've no real clue what this 
package is about.
Seems the package description can be a lot improved and not just done by 
c&p!? :-)


--
Regards
Carsten

Bug#1054384: ITP: art/6.1-1 --ASCII art

[Carsten Schoenert]

Hello Yogeswaran,

Am 23.10.23 um 02:33 schrieb Yogeswaran Umasankar:

* Package name     : art
     Version          : 6.1-1
     Upstream contact : Sepand Haghighi 
   * URL              : https://github.com/sepandhaghighi/art
   * License          : MIT
   * Vcs              : https://salsa.debian.org/NGC2023/art
     Section          : python
     Description: ASCII art


the name 'art' is a very generic name, I suggest to use python-art 
according the source is a python library and a similar functionality 
could be also be provided by other programming languages.


The same is true for the binary package name, usually and mostly the 
package name is prefixed by 'python3-'.


PS: Please use reportbug to write your ITPs! It is setting all headers 
correctly.

https://wiki.debian.org/reportbug

--
Regards
Carsten Schönert

Bug#1053669: thunderbird: primary password not ask on startup - only in safe-mode it works

[Carsten Schoenert]

Hello Andreas,

On 10/9/23 20:02, Andreas Matthus wrote:

Hallo Carsten,

thank you for your answer.
Unfortunately deleting and/or change primary password give no success.

On javaconsole I see a difference:
---snipp
encrypted-openpgp-passphrase.txt corruption fixed. Corrupted file moved to 
/home/andreas/.thunderbird/ys2evdnt.default/encrypted-openpgp-passphrase.txt.corrupt
 masterpass.jsm:200:19
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsISecretDecoderRing.encryptString]
     _ensurePasswordCreatedAndCached 
chrome://openpgp/content/modules/masterpass.jsm:269

RNP.jsm:465:15
NS_ERROR_FAILURE: Couldn't decrypt string crypto-SDR.sys.mjs:199
NS_ERROR_FAILURE: Couldn't decrypt string crypto-SDR.sys.mjs:199
---snipp

Every time I start without --safe-mode encrypted-openpgp-passphrase.txt 
renamed to
encrypted-openpgp-passphrase.txt-1.corrupt, 
encrypted-openpgp-passphrase.txt-2.corrupt and so on.


All extensions I deleted an purged thunderbird-l10n-de, but just the 
same result.


you can try to stop Thunderbird, backup the file key4.db from your 
profile folder, than remove that file and restart Thunderbird.


Thunderbird will create a new file and you should be able to set again a 
new master password.

Other possible corrupted files are cert9.db and logins.json.
If you remove these files you need to re-add all the passwords and 
certificates that were used! So be careful.


It's long ago but we did have similar bug report in the past there 
deleting the key4.db was the solution. But you


As always, please make a backup of your profile folder before doing any 
modification within the profile folder.


--
Regards
Carsten

Bug#1053669: thunderbird: primary password not ask on startup - only in safe-mode it works

[Carsten Schoenert]

Hi,

Am 08.10.23 um 13:57 schrieb Andreas Matthus:

Dear Maintainer,

after upgrade to 115.3.1-1~deb12u1 from 102 I have problems by starting
thunderbird: It ask not for primary password but the passwords for all accounts
and calenders. No stored passwords found and not stored private certificates.
All accounts and old mails are seen.
Restart thunderbird shows he same behavior. Disable all plugins the same.

Start in safe-mode an "continue in Troubleshoot Mode" show the question for
primary password first and all works fine (only I can't set the language). Next
start I need this way too. Start in normal mode have the problems above every
time.


you have tried these steps?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

Is it possible to just edit the master password?
Means cleaning out the old one and setting a new afterwards?

That's what I read about it while looking for similar cases.

--
Regards
Carsten

Bug#1016703: mkdocs-material: Please package recent version

[Carsten Schoenert]

Hello Sandro,

thanks for preparing and publishing an update!
Wanted to reply earlier but due traveling the past days this was
impossible.

Am Sat, Sep 16, 2023 at 11:47:24PM -0400 schrieb Sandro Tosi:
> > this bug report is now open for one year, is there something you need
> > help with?
> >
> > I'd really appreciate a recent version could make it's way into the
> > archive.
> 
> is there something blocked by this?

Not directly, I'm working on some more mkdocs-* packaging and while
doing so I noticed some deprecation warning which were "fixed" by more
recent versions of mkdocs-material.

I'm also still working on packaging netbox which also needs
mkdocs-material and I got problems while building recent versions. At a
first view it was looking like the older version of mkdocs-material was
related to this. But gladly it was not the fault of this package.

Regards
Carsten

Bug#1052134: description of the problem

[Carsten Schoenert]

Hello Nikolay,

Am 18.09.23 um 01:22 schrieb Nikolay Sabelnikov:

how the problem can be reproduced. try to log in to Yandex mail if
2-factor protection is configured, through the application on the Yandex
key phone. So first the application password is created, which by the
way will be enough, but for some reason the mail program is trying to
log in through 2-factor protection. In the window that opens, after
trying to log in, a 400 error pops up and that's it. I turned to yandex,
but they sent me to contact Mozilla's contributors. But I'll notify you
first. Maybe they fixed it in the new versions.


this is to me clear a upstream issue and not a Debian packaging related 
issue.


Please open a bug report on

https://bugzilla.mozilla.org/

and give back afterwards the bug number within the Bugzilla instance so 
we can track the progress of the upstream report.


--
Regards
Carsten

Bug#1016703: mkdocs-material: Please package recent version

[Carsten Schoenert]

Hello Sandro,

Am Fri, Aug 05, 2022 at 08:06:20PM +0200 schrieb Carsten Schoenert:
> Package: mkdocs-material
> Version: 8.2.5-1
> Severity: wishlist
> 
> Hello Sandro,
> 
> could you please consider to package the recent upstream version of
> mkdocs-material?
> 
> Could you also please (re)close the issue #1008691 by the newer version
> within the new changelog entry?
> 
> As Paul Grevers explained to me has the BTS a problem if a bug report
> has the same version marked fixes as the report has been open against before.
> That's currently the reason the package isn't midrating to testing.

this bug report is now open for one year, is there something you need
help with?

I'd really appreciate a recent version could make it's way into the
archive.

Regards
Carsten

Bug#1051978: ITP: python-yamlfix -- Simple opionated yaml formatter that keeps your comments

[Carsten Schoenert]

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

* Package name: python-yamlfix
  Version : 1.13.0
  Upstream Contact: Lyz 
* URL : https://github.com/lyz-code/yamlfix
* License : GPL-3
  Programming Lang: Python
  Description : Simple opionated yaml formatter that keeps your comments

 yamlfix is a Python based YAML file formatter which will fix any known
 formatting issue within your YAML files automatically.
 .
 It can read configuration settings from pyproject.toml, from configuration
 files or environment variables while it is called from the CLI or by
 including as Python library.
 .
 Main feature are:
  * Add the header --- to your file.
  * Correct truthy strings: 'True' -> true, 'no' -> 'false'
  * Remove unnecessary apostrophes:
title: 'Why we sleep' -> title: Why we sleep.
  * Correct comments
  * Ensure that there is exactly one newline at the end of each file, to
comply with the POSIX standard.
  * Split long lines.
  * Respect Jinja2 syntax.
  * Convert short lists to flow-style list: [item, item]
  * Convert lists longer than line-width to block-style

This package will get maintained within the Debian Python Team.

Bug#1051777: python3-pymdownx: Update package with a recent upstream version

[Carsten Schoenert]

Package: python3-pymdownx
Version: 9.5-2
Severity: wishlist

Hi,

please package a recent version of pymdown-extensions, the current
version in the archive is almost over a year old.

Thanks!

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

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

Versions of packages python3-pymdownx depends on:
ii  python3   3.11.4-5+b1
ii  python3-markdown  3.4.4-1

python3-pymdownx recommends no packages.

python3-pymdownx suggests no packages.

-- no debconf information

Bug#1051758: ITP: python-ruyaml -- YAML 1.2 loader/dumper package for Python

[Carsten Schoenert]

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

* Package name: python-ruyaml
  Version : 0.91.0
  Upstream Contact: Anthon van der Neut, Ruamel bvba 

Sorin Sbarnea 
* URL : https://github.com/pycontribs/ruyaml
* License : MIT
  Programming Lang: Python
  Description : YAML 1.2 loader/dumper package for Python

 The ruyaml package is a fork of ruamel.yaml aimed to made in order to secure
 the future of the library, mainly by having a pool of maintainers and can be
 used as a drop-in replacement for python3-ruamel.yaml.

This package is a dependency for yamlfix (a simple opinionated yaml
formatter that keeps your comments) which I intend to package to.

Packaging will happen within the Debian Python Team.

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[Carsten Schoenert]

Hello Alejandro,

Am 09.09.23 um 22:46 schrieb Alejandro Colomar:

Hi,

Since some recent version, every time I delete a mail, the list scrolls
up a few messages, and I need to manually scroll down again, every time.


did tried to follow these steps?

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

I can't reproduce this issues.

--
Regards
Carsten

Bug#1051470: RFP: esbuild-sass-plugin -- Plugin for esbuild to handle Sass & SCSS files

[Carsten Schoenert]

Package: wnpp
Severity: wishlist

* Package name: esbuild-sass-plugin
  Version : 2.15.0
  Upstream Contact: Gianluca Romeo 
* URL : https://github.com/glromeo/esbuild-sass-plugin
* License : MIT/X
  Programming Lang: Javescript
  Description : Plugin for esbuild to handle Sass & SCSS files

An esbuild plugin for loading Sass/SCSS files using the CSS content type.

This plugin was forked from esbuild-sass-plugin to facilitate migrations
from Webpack. Libraries that rely on sass-loader's import resolution
logic should mostly just work.

Features:
* PostCSS & CSS modules
* support for constructable stylesheet to be used in custom elements
  or dynamic style to be added to the html page
* uses the new Dart Sass Js API.
* caching
* url rewriting
* pre-compiling (to add global resources to the sass files)

Bug#1051368: python3-selenium: Selenium Python still can't find chromedriver

[Carsten Schoenert]

Control: tags -1 severity normal

Hello Jonathan,

Am Wed, Sep 06, 2023 at 04:37:28PM -0400 schrieb Jonathan Kamens:
 
> Opening a new ticket since bug 1050378 is resolved and I don't know
> how to reopen a resolved ticket (nor do I know if it is even possible
> for me to reopen a resolved ticket).

https://www.debian.org/Bugs/server-control#reopen

if you use 'bts' this would become the following CLI command:

$ bts 1050378 reopen

If you prefer to use a MTA ensure to include the following line at the
very beginning of the body.

reopen 1050378

> python3-selenium 4.12.0+dfsg-1 still doesn't work.
> 
> I get this when I try to create a selenium.webdriver.Chrome object:
> 
> selenium.common.exceptions.NoSuchDriverException: Message: Unable to obtain 
> driver for chrome using Selenium Manager.; For documentation on this error, 
> please visit: 
> https://www.selenium.dev/documentation/webdriver/troubleshooting/errors/driver_location
> 
> The ChangeLog for this release claims:
> 
>   * [5b22b76] d/README.Debian: Add section about the Selenium Manager
>   * [25b0d5f] d/NEWS moved to d/python-selenium.NEWS
> (Closes: #1050378)
> 
> But neither of those files exists in the python3-selenium package. Was
> there an intention to add them to the package that wasn't followed
> through on?

This is indeed a issue, both file should be within the package
python3-selenium but are not in 4.12.0-1. This slipped somehow through.
The file are moved now into the correct binary package.

> Incidentally, I took a look at README.Debian in the source package and
> there are some issues with the text that may be worth fixing as well.
> In particular:
> 
> >While writing it's not packaged for Debian. In order to make python3-selenium
> 
> I suggest changing "While writing" (which is not really an idiom that
> is used in English) to "At this time".
> 
> >usable with this new circumstance you will need to adjust your source in a
> >way to choose the used driver directly and skip the calling of the manager
> >code in Selenium. Please have a look at the following example how to archive
> 
> I think you mean to say "achieve" here rather than "archive".

Correct, I'm not a native english speaking person and all spelling and
grammar tools do not not detect all common mistakes, I fixed the
relevant parts which will get included in a next upload.

> In any case I do not believe that documenting this deficiency in
> README.Debian, even if/when it is included in the package, is a
> sufficient fix for the issue. The issue IMO should remain unresolved
> until Selenium Manager is properly packaged for Debian.

And then? Who will package the required package? I'm not tend to do
this. And adding at minimum two lines of additional code to your
project/code/application that is intended to be running on a Debian
system isn't a big thing to me.

If you rely on Selenium Manager you should fill a RFP issue I suggest.

If you think the problem (and also the possible solutions) aren't well
enough explained and to less documentation is provided how to work
around the new requirement for Selenium Manager is now needed as a
middle layer we are happy to get suggestions and text snippets how this
can be improved.

To find out how to set the driver interface manually instead by the
Selenium Manager took me about 30min
on searching with my preferred search engine. I'm sure others will be
able to find quite the same in a similar time.

So no, I don't think your report is of severity grave nor is
python3-selenium within Debian not working currently.

Regards
Carsten

Bug#1050882: kicad-libraries metapackage version mixup

[Carsten Schoenert]

Hello antto,

Am 31.08.23 um 01:14 schrieb antto:

Dear Maintainer,

After upgrading to Debian12, the normal version of kicad is 6.x, after enabling
backports you can get kicad 7.x.
When you "Force Version" of the kicad-libraries metapackage in Synaptic to 7.x,
you would think that you'll get all the version 7 packages, but you don't, it
requires "(>=6.0.0~)" according to Synaptic, for kicad-footprints/kicad-
symbols/kicad-templates. it only correctly suggests kicad-packages3d v7.x.


you see this because the package of kicad-packages3d is "only" 
suggested. The other packages are depending packages.


And from a technical point there is no reason to depend on version 7.x, 
the older versions <7 are also working correctly. So I did see no hard 
reason to bump any version for the depending packages.



And if you already had the stable kicad version, you will upgrade kicad itself
to v7 (from backports), the "libraries" metapackage will also get upgraded to
v7, but your actual library files (symbols, footprints, templates) will stay at
version 6 because they cover the requirements of the metapackage.


Hmm, interesting point. But this was intended at time thinking about the 
package dependencies while working on the first package for KiCad 7.



This seems wrong to me, the whole point of the "kicad-libraries" metapackage as
far as i know is to "group" the real packages that make up the libraries
(symbols, footprints, templates, 3D models).

I expected that the kicad-libraries metapackage actually upgrades the real
packages to the same version (or at least to some version above 7).


I agree on the point this isn't the best and probably expected behavior. 
And now after a while there are no technical reasons against to bump the 
version dependencies. Will happen at the next upstream version bump.


--
Regards
Carsten

Bug#1050595: thunderbird: Menus are mangled

[Carsten Schoenert]

Hello Hilary,

Am 27.08.23 um 00:50 schrieb Hilary Snaden:


Three menubars are displayed, the first where the titlebar should be,
then two more beneath it. All but the active item is in black text on
a near-black background.
you don't give any more information about the DE or AddOns you are 
using, but to me it looks like a possible problem with the theming of 
the DE.



https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues


You have already tried the suggestions from here?


Kernel: Linux 6.1.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN


This let me indicate you are using a graphic card from NVidia, sometimes 
the card drivers are responsible for visible issues.


--
Regards
Carsten

Bug#1049979: nss: Please package version 3.92

[Carsten Schoenert]

Source: nss
Version: 2:3.91-1
Severity: wishlist

Hello Mike,

couly you please package the current most recent version 3.92 of nss
please?

I try to keep track of the beta versions of Thunderbird but version
117.0+ requires nss >= 3.92 to be around.

Regards
Carsten

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

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

Bug#1043586: dnstwist: Failing autopkgtest with python3-selenium 4.11.2+dfsg-1

[Carsten Schoenert]

Source: dnstwist
Version: 0~20230509-1
Severity: important

Dear Maintainer,

the autopkgtest of dnstwist is failing with the most recent version of
python3-selenium.

This is due a internal change in Selenium upstream since version 4.11.0.
Upstream is using a method/component called Selenium Manager since then
and as we can't ship this due it's binary form calling webdriver.Chrome()
needs to be extended about the information which driver needs to be used.

Please see attached patch that will fix the autopkgtest so it can bee
succeeding as before. Feel free to modify the patch to your needs or
requirements.
Note: The attached patch is modifing the source of dnstwist, you
probably need to check my adjustments that makes the autopkgtest working
again as changing the source has a deep impact on the usage of this package.

Regards
Carsten

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From f4ebc3b8f71ef516efd5f56144b5fe8fb1ef7292 Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Sun, 13 Aug 2023 12:21:37 +0200
Subject: [PATCH] Add Set-driver-binary-manually-to-chromedriver.patch

This modification is required to make dnstwist function together with
python3-selenium 4.11.2 onwards due a internal change in the upstream
Python library of Selenium.
---
 ...iver-binary-manually-to-chromedriver.patch | 42 +++
 debian/patches/series |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
debian/patches/Set-driver-binary-manually-to-chromedriver.patch

diff --git a/debian/patches/Set-driver-binary-manually-to-chromedriver.patch 
b/debian/patches/Set-driver-binary-manually-to-chromedriver.patch
new file mode 100644
index 000..343562c
--- /dev/null
+++ b/debian/patches/Set-driver-binary-manually-to-chromedriver.patch
@@ -0,0 +1,42 @@
+From: Carsten Schoenert 
+Date: Sun, 13 Aug 2023 11:48:22 +0200
+Subject: Set driver binary manually to chromedriver
+
+The Selenium upstream project is using a method/component called
+Selenium Manager since version 4.11.0+.
+This specific part is looking out which driver can be used, as this is
+shipped currently in a binary form only it's not included in
+python3-selenium. The only usable driver in Debian is chromedriver so we
+can adjust the usage of the Selenium stuff to use the binary
+/usr/bin/chromedriver.
+
+Forwared: Not-Needed
+---
+ dnstwist.py | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/dnstwist.py b/dnstwist.py
+index 702e0ad..03b665e 100755
+--- a/dnstwist.py
 b/dnstwist.py
+@@ -367,12 +367,19 @@ class HeadlessBrowser():
+   )
+ 
+   def __init__(self, useragent=None):
++  # Upstream relies on the Selenium Manager to find the correct
++  # webdriver which isn't provided by package python3-selenium.
++  # Instead dropping the automatic detection and set the driver 
hard
++  # to chromedriver and give that option to Chrome() 
initialization.
++  from selenium.webdriver.chrome.service import Service as 
ChromeService
++  service = ChromeService(executable_path="/usr/bin/chromedriver")
++
+   chrome_options = webdriver.ChromeOptions()
+   for opt in self.WEBDRIVER_ARGUMENTS:
+   chrome_options.add_argument(opt)
+   chrome_options.add_experimental_option('excludeSwitches', 
['enable-automation'])
+   
chrome_options.add_experimental_option('useAutomationExtension', False)
+-  self.driver = webdriver.Chrome(options=chrome_options)
++  self.driver = webdriver.Chrome(options=chrome_options, 
service=service)
+   self.driver.set_page_load_timeout(self.WEBDRIVER_TIMEOUT)
+   self.driver.execute_cdp_cmd('Network.setUserAgentOverride', 
{'userAgent':
+   useragent or self.driver.execute_script('return 
navigator.userAgent').replace('Headless', '')
diff --git a/debian/patches/series b/debian/patches/series
index e7c402f..4ba2989 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 patch-out-embedded-jquery-cdn.patch
 issue194.patch
+Set-driver-binary-manually-to-chromedriver.patch
-- 
2.40.1

Bug#1008159: [PATCH] More MIME file types and URI scheme handlers in thunderbird.desktop

[Carsten Schoenert]

Control: tags -1 pending

Hello Max,

Am 08.08.23 um 13:31 schrieb Max Nikulin:

On 05/08/2023 13:08, Carsten Schoenert wrote:


Could you please cut all these additions into own peaces/patches?
By this it's more visible what the addition of adding a specific handler
is made of. And using git blame will make it easier to find what content
was added by which commit.


See the attached files. They do not include text/x-calendar present in
the original patch. I am in doubts if it frequently appears in the wild.


thanks, I applied them locally. I rebased afterwards and sorted the 
entries so they are ordered alphabetically. So it's better readable for 
humans.



Frankly speaking, I have see a little value in splitting a commit that
changes just single line. I would not even try to add multiple MimeType
entries even if they would be supported by some frameworks. I believe
the comment was detailed enough to review entries of the list.


it's not about the comment, it's about traceability of modifications and 
atomic commits.


It's far easier to revert things partially if needed if you handle 
things in small enough peaces.



I decided to try git sparse-checkout and I was significantly more
optimistic how much data I have to get to make a series of commits
changing just single line. 1G is too much from my point of view. Perhaps
shallow clone could reduce it by several times.


Well the size of the packaging tree is rather big yes, but that is the 
cost for holding all releases and work within one tree.


If you don't care much about all the history or all possible branches 
you can pull in just the branch you want with quite zero history.


git clone --depth 1 $URL -b branchname

--
Regards
Carsten

Bug#1041409: Bug#1043138: Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[Carsten Schoenert]

Hi again,

Am 12.08.23 um 15:40 schrieb Paul Gevers:


I'm trying to do that, but it's a fight.


another try would be to use the upstream precompiled binaries.


https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/115.1.0/linux-x86_64/


Just extract to somewhere and start the thunderbird binary, it will pick 
up the profile automatically.


If the issue is quite the same I suggest to open a upstream issue in the 
Bugzilla system.



https://bugzilla.mozilla.org/home


--
Regards
Carsten

Bug#1043367: thunderbird 115.1 is unresponsive

[Carsten Schoenert]

Hello IOhannes,

Am 09.08.23 um 17:24 schrieb IOhannes m zmölnig (Debian/GNU):

Dear Maintainer,

after upgrading thunderbird to 1:115.1.0-1, it has become unusable.

starting works nicely and i get the password prompt, after which the
main screen is shown.

however, the window is totally unresponsive, and thunderbird works
happily at 100% for hours.


this isn't normal for sure. But there can be various reasons why TB is 
eaten all available CPU power. In quite all the cases I've encountered 
the profile was the reason for this.


You might have seen and tried some options you have seen on the Debian 
wiki page, if not please keep an eye on it.



https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues


The mainly two main points to debug the situation are to run the JS 
console if possible and to start up with a clean profile if no reason 
and solution can be found in the JS log console.


Sorry, I haven't more useful tips.

...

As you can see i'm slightly tight on disk space (and my ~/.thunderbird/
folder takes about 5.2GB), but i *think* this should be a usable setup.

of course, thunderbird_115 upgraded my profile, so i can no longer
downgrade to the thunderbird from bookworm :-(


There is the option '--allow-downgrade' which works quite acceptable in 
recent days in case you need to start with an older version.



$ thunderbird -h | grep downgrade
  --allow-downgrade  Allows downgrading a profile.


--
Regards
Carsten

Bug#1043508: jquery-timepicker: Failing autopkgtest with python3-selenium 4.11.2+dfsg-1

[Carsten Schoenert]

Source: jquery-timepicker
Version: 1.6.3-4
Severity: important

Dear Maintainer,

the autopkgtest of jquery-timepicker is failing with the most recent
version of python3-selenium.

This is due a internal change in Selenium upstream since version 4.11.0.
Upstream is using a method/component called Selenium Manager since then
and as we can't ship this due it's binary form calling webdriver.Chrome()
needs to be extended about the information which driver needs to be used.

Please see attached patch that will fix the autopkgtest so it can bee
succeeding as before.

Regards
Carsten

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 18ec221fd0f31bdb16c5f915732ac595d5c0a79b Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Sat, 12 Aug 2023 09:27:11 +0200
Subject: [PATCH] autopkgtest: Tune Selenium setup to use local chromedriver

Selenium upstream did change the internal behavior to use Selenium
Manager which we can not use directly, it's shipped as a pre-compiled
binary currently. It's not packaged yet in any form.

Instead set the path to the chromdriver executable manually and extend
the options on the webdriver.chrome() call.
---
 debian/tests/test-runner.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/tests/test-runner.py b/debian/tests/test-runner.py
index e78db56..f2f4db3 100644
--- a/debian/tests/test-runner.py
+++ b/debian/tests/test-runner.py
@@ -1,6 +1,7 @@
 from selenium import webdriver
 from selenium.webdriver.support.wait import WebDriverWait
 from selenium.webdriver.common.by import By
+from selenium.webdriver.chrome.service import Service as ChromeService
 import os
 
 options = webdriver.ChromeOptions()
@@ -9,7 +10,8 @@ options.add_argument('--no-sandbox')
 options.add_argument('--headless')
 options.add_argument('--disable-gpu')
 options.add_argument('--disable-dev-shm-usage')
-driver = webdriver.Chrome(options=options)
+service = ChromeService(executable_path="/usr/bin/chromedriver")
+driver = webdriver.Chrome(options=options, service=service)
 
 print("Running tests")
 driver.get("http://localhost:/SpecRunner.html?random=false";)
-- 
2.40.1

Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[Carsten Schoenert]

Hello Paul,

Am 10.08.23 um 21:57 schrieb Paul Gevers:

Hi,

I upgraded thunderbird after the latest version migrated to testing
and sending messages fails until I disable signing them. It seems this
issue is still present, despite the switch to the internal version.


the internal shipped version of RNP is typically the most recent 
upstream version. To me it's very unlikely that the problem you is based 
on the internal RNP version.


There is #1043138 which was about a similar problem, seems there the 
issue could be solved by re-importing the secret key. Alexis (Reply #20) 
could solve his issue too by a re-import.



https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043138#15


Otherwise I can "just" suggest to do the classical dance of debugging 
and starting with a clean profile too. I still can't reproduce this 
problem on any of my installations.



The failure message is rather unspecific: "Sending of the message failed."


Open the JS console might bring more clue what probably might be go wrong.

Crtl + Shift + j

or the command line option '--jsconsole' will do the trick.

--
Regards
Carsten

Bug#1043138: thunderbird: cannot send OpenPGP signed message: rnp_op_sign_add_signature failed since upgrade to 115.1.0 (sid)

[Carsten Schoenert]

Hello Jamie,

I can't reproduce this issue.

Am 06.08.23 um 16:10 schrieb Jamie McClelland:


After upgrading to 115.1.0, when sending a message with "Digitally sign"
selected I consistently receive an error that "Sending of the message
failed." (When
just encrypting it works fine.)

The error console reports:

CryptoAPI.sync() failed result:  Error: rnp_op_encrypt_add_signature failed
  encryptAndOrSign chrome://openpgp/content/modules/RNP.jsm:3526
  sync chrome://openpgp/content/modules/cryptoAPI/interface.js:56
  encryptMessageStart chrome://openpgp/content/modules/encryption.jsm:446
  finishCryptoEncapsulation
chrome://openpgp/content/modules/mimeEncrypt.jsm:516
  createMessageFile resource:///modules/MimeMessage.jsm:90
interface.js:46:17
Error: failure in finishCryptoEncapsulation, exitCode: -1
  finishCryptoEncapsulation
chrome://openpgp/content/modules/mimeEncrypt.jsm:537
  createMessageFile resource:///modules/MimeMessage.jsm:90
mimeEncrypt.jsm:554:15
mimeEncrypt.js: caught exception: Error
Message: 'failure in finishCryptoEncapsulation, exitCode: -1'
File:chrome://openpgp/content/modules/mimeEncrypt.jsm
Line:537
Stack:
finishCryptoEncapsulation@chrome://openpgp/content/modules/mimeEncrypt.jsm:537:15
createMessageFile@resource:///modules/MimeMessage.jsm:90:27


Error: failure in finishCryptoEncapsulation, exitCode: -1
mimeEncrypt.jsm:537:15
  finishCryptoEncapsulation
chrome://openpgp/content/modules/mimeEncrypt.jsm:537
  createMessageFile resource:///modules/MimeMessage.jsm:90
  InterpretGeneratorResume self-hosted:1455
  AsyncFunctionNext self-hosted:852
mailnews.send: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "failure in finishCryptoEncapsulation, 
exitCode: -1" {file: "chrome://openpgp/content/modules/mimeEncrypt.jsm" line:> 537}]'[JavaScript Error: 
"failure in finishCryptoEncapsulation, exitCode: -1" {file: 
"chrome://openpgp/content/modules/mimeEncrypt.jsm" line: 537}]' when calling method:
[nsIMsgComposeSecure::finishCryptoEncapsulation]
  createMessageFile resource:///modules/MimeMessage.jsm:90
MessageSend.jsm:137:32
  createAndSendMessage resource:///modules/MessageSend.jsm:137
mailnews.send: Sending failed; , exitCode=2153185313, originalMsgURI=
MessageSend.jsm:362:32
  fail resource:///modules/MessageSend.jsm:362
  createAndSendMessage resource:///modules/MessageSend.jsm:145
Error: rnp_op_encrypt_add_signature failed RNP.jsm:3526:21


You don't give any further information so it's difficult to give some 
good advice.


There are some general suggestions how to narrow down potential issues 
while working with a somehow dysfunctional Thunderbird application in 
the Debian Wiki.



https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues


Taking parts of the log from your error messages let me think it's not a 
issue within Thunderbird itself, it looks like you've configured 
Thunderbird to use GPG and not the internal crypto handling.


So far I remember you need ensure you have commented out this line in 
~/.gnupg/gpg-agent.conf


$ grep pinentry  ~/.gnupg/gpg-agent.conf 
#allow-loopback-pinentry


And also don't have set "pinentry-mode loopback" in ~/.gnupg/gpg.conf.

To see more information you will need to enable some debugging.

https://www.gnupg.org/documentation/manuals/gpgme/Debugging.html

e.g.


$ GPGME_DEBUG=9:~/gpgme.log thunderbird --jsconsole


--
Regards
Carsten

Bug#1043057: thunderbird: `[GFX1-]: FireTestProcess failed: Abspalten des Kindprozesses »/usr/lib/thunderbird/glxtest« gescheitert (Datei oder Verzeichnis nicht gefunden)`

[Carsten Schoenert]

Hello Paul,

Am 05.08.23 um 14:10 schrieb Paul Menzel:

Upgrading *thunderbird* from 1:102.13.1-1 to 115.1.0-1 the messages
below are printed to the terminal:

  [GFX1-]: FireTestProcess failed: Abspalten des Kindprozesses
»/usr/lib/thunderbird/glxtest« gescheitert (Datei oder Verzeichnis nicht 
gefunden)

  [GFX1-]: glxtest: ManageChildProcess failed

  [GFX1-]: No GPUs detected via PCI

Copying the executable from *firefox* fixes the issue.

  sudo cp -a /usr/lib/firefox/glxtest /usr/lib/thunderbird/glxtest


So far I do see your report this "hides" more or less the error message 
you've seen before. I can reproduce this on my big workstation too but I 
do not encounter any other problems like glitches in the UI.



After that, the message below is shown:

  [GFX1-]: FireTestProcess failed: Abspalten des Kindprozesses
»/usr/lib/thunderbird/vaapitest« gescheitert (Datei oder Verzeichnis nicht 
gefunden)


Well, these to binaries are used to detect if you have a graphic card 
which is able to support VA-API. Currently for whatever reason the two 
binaries are not build by the build process of Thunderbird for whatever 
reason. Might be an upstream issue, or might be a build configure issue.


VA-API is a useful thing for Firefox and Chromiun, but not really needed 
for running Thunderbird which is a MUA.


BTW: Please enforce to use the system locale so all messages are in 
English then if you want to report issues. For example use at least


$ LANG= thunderbird

--
Refards
Carsten

Bug#888900: closed by Carsten Schoenert (Re: reassign 888900 to src:thunderbird)

[Carsten Schoenert]

My previous statement about IA64 isn't a supported architecture any more
isn't true, IA64 is still within the ports section.

But I won't reopen this report as I'm not able and willing to keep also
track of an non RC architecture for Thunderbird. Keep Thunderbird in a
buildable state for the current RC architectures (execpt the already
removes architectures here) is taken mostly all the avaiable time and
energy.

If some non RC architecture want to be more supported by someone please
work on usptreaming first the needed patches.

Regards
Carsten

Bug#1008159: [PATCH] More MIME file types and URI scheme handlers in thunderbird.desktop

[Carsten Schoenert]

Hi Max,

this patch and also this bug report wasn't on my radar, it simply slipped
through.

I'm happy to add this to the Debian package build, but a small request
for modification I have.

Could you please cut all these additions into own peaces/patches?
By this it's more visible what the addition of adding a specific handler
is made of. And using git blame will make it easier to find what content
was added by which commit.

Regards
Carsten

Am Sat, Apr 01, 2023 at 05:50:53PM +0700 schrieb Max Nikulin:
> Control: tags -1 +patch
> 
> I have noticed that besides mid: (Message-ID) protocol more URI schemes
> supported by thunderbird are missed in the .desktop file. It can open e.g.
> .ics files from https://, but I do not think it should be added.
> 
> For symmetry I have added x-/non-x- counterparts to text/calendar and
> text/vcard types.
> 
> See the attachment for a patch.

> More MIME file types and URI scheme handlers in thunderbird.desktop
> 
>   * Thunderbird is capable to handle more URI schemes:
> -  USENET news links,
> - mid: RFC 2392 - Content-ID and Message-ID Uniform Resource Locators,
> - webcal: and webcals: calendars in iCalendar format,
> - add alternatives for .ics and .vcf files.
> (Closes: #1008159)
> 
> --- thunderbird_102.9.1-1/debian/thunderbird.desktop  2023-03-18 
> 12:09:36.0 +
> +++ thunderbird/debian/thunderbird.desktop2023-04-01 10:17:39.553667864 
> +
> @@ -9,7 +9,7 @@
>  Version=1.0
>  Icon=thunderbird
>  Categories=Network;Email;News;GTK;
> -MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;
> +MimeType=message/rfc822;x-scheme-handler/mailto;x-scheme-handler/mid;x-scheme-handler/news;x-scheme-handler/webcal;x-scheme-handler/webcals;text/calendar;text/x-calendar;text/vcard;text/x-vcard;
>  StartupWMClass=thunderbird-default
>  StartupNotify=true
>  Name[ast]=Veceru de corréu Thunderbird

Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[Carsten Schoenert]

Hello Daniel,

Am 22.07.23 um 19:49 schrieb Daniel Kahn Gillmor:

Control: block 1041409 by 1038812

Hi all--

Thanks for noticing this.  Putting rnp 0.17.0 in the archive will
require sexpp to land in the archive as well, but has been in in NEW for
a few weeks (see #1038812).


I've currently switched the build for Thunderbird to use the internal 
version of RNP so the usage of the PGP functions is available again and 
I plan to upload the current version of 115.0.1 later the day again to 
experimental. We still have a few FTBFS issues within some RC platforms 
to solve. Once these problems are gone I wanted to upload 115.x to unstable.


Maybe Thorsten can have a look at the package sexpp within the NEW queue?


   --dkg

On Tue 2023-07-18 19:06:58 +0200, Carsten Schoenert wrote:

Hi Alper,

Am 18.07.23 um 17:20 schrieb Alper Nebi Yasak:

I decided to upgrade Thunderbird to the version in experimental, and
noticed that its OpenPGP functionality is completely broken: the Key
Manager is empty, and it doesn't even attempt to decrypt/verify
encrypted/signed messages (at least over external gnupg).


ha, by accident I noticed the described behavior just a few hour ago too!
Thanks for trying out Thunderbird from experimental, I expect we will
find a few more glitches like that.


The "Troubleshooting Information" page says the expected minimum version
for the RNP library is 0.17.0, where I had 0.16.3-1 installed as
currently in unstable.


Unfortunately the Thunderbird build system does not do a really good job
on detecting required versions for libraries or equal. And it's mostly
difficult to detect such version bumps by reviewing manually changes
after importing a new version.


Seeing a 0.17.0~git20220428-1 version for librnp0 in experimental, I
tried installing that. But that doesn't work either, apparently its
source is older than 0.16.1? (Also see bug #1031363).

So I think Thunderbird needs to depend on librnp0 >= 0.17.0 (currently
unversioned), but no such version is in Debian yet. I got it to work by
sloppily packaging the newer source. (The proper package may take a bit,
has a new dependency apparently in NEW -- I'm CC-ing the maintainer.)


Your analysis is correct, Thunderbird will need a version constrain on
librnp0. But this requires the package to be available at least in
experimental.

I'll do some work around this and change the build system while
preparing the next upload so it is using the internal shipped librnp
version until Daniel has uploaded a newer version.

--
Regards
Carsten


--
Regards
Carsten

Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[Carsten Schoenert]

Hi Alper,

Am 18.07.23 um 17:20 schrieb Alper Nebi Yasak:

I decided to upgrade Thunderbird to the version in experimental, and
noticed that its OpenPGP functionality is completely broken: the Key
Manager is empty, and it doesn't even attempt to decrypt/verify
encrypted/signed messages (at least over external gnupg).


ha, by accident I noticed the described behavior just a few hour ago too!
Thanks for trying out Thunderbird from experimental, I expect we will 
find a few more glitches like that.



The "Troubleshooting Information" page says the expected minimum version
for the RNP library is 0.17.0, where I had 0.16.3-1 installed as
currently in unstable.


Unfortunately the Thunderbird build system does not do a really good job 
on detecting required versions for libraries or equal. And it's mostly 
difficult to detect such version bumps by reviewing manually changes 
after importing a new version.



Seeing a 0.17.0~git20220428-1 version for librnp0 in experimental, I
tried installing that. But that doesn't work either, apparently its
source is older than 0.16.1? (Also see bug #1031363).

So I think Thunderbird needs to depend on librnp0 >= 0.17.0 (currently
unversioned), but no such version is in Debian yet. I got it to work by
sloppily packaging the newer source. (The proper package may take a bit,
has a new dependency apparently in NEW -- I'm CC-ing the maintainer.)


Your analysis is correct, Thunderbird will need a version constrain on 
librnp0. But this requires the package to be available at least in 
experimental.


I'll do some work around this and change the build system while 
preparing the next upload so it is using the internal shipped librnp 
version until Daniel has uploaded a newer version.


--
Regards
Carsten

Bug#1038859: nss: Please package version 3.90

[Carsten Schoenert]

Source: nss
Version: 2:3.87.1-1
Severity: wishlist

Hello Mike,

I'm trying to get a first set of packages build for Thunderbird 115.0
beta.
This version requires NSS3 at version 3.90+.

Coudl you please package and upload the current most recent version of
NSS3? Thanks.

Regards
Carsten

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

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

Bug#1038437: RM: libcoap2 -- ROM; EOL, unmaintained and no longer supported by upstream

[Carsten Schoenert]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove the source package libcoap2 including all binary packages
build from that source package in unstable.

libcoap with the API version 2 isn't developed nor supported by upstream
any more, it's been superseded by the source package libcoap3.

libcoap2 packages aren't included for the reason from above within the
bookworm release and only living currently within the unstable archive.

Regards
Carsten

Bug#1037085: RFP: strawberry-graphql -- GraphQL library for Python that leverages type annotations

[Carsten Schoenert]

Package: wnpp
Severity: wishlist

* Package name: strawberry-graphql
  Version : 0.180.5
  Upstream Contact: Patrick Arminio 
* URL : https://github.com/strawberry-graphql/strawberry
* License : Expat
  Programming Lang: Python
  Description : GraphQL library for Python that leverages type annotations

Strawberry is a new GraphQL library for Python 3, inspired by
dataclasses. One of its goals is to provide a great developer experience
for both GraphQL beginners and advanced users.

Strawberry is a code-first GraphQL server library that uses Python type
annotations to define GraphQL types. This allows you to focus more on how
you can integrate one ore more DBs into your workflow and less on the
idiosyncrasies of GraphQL itself.

This library is a upcomming build and package dependency for NetBox (see
ITP https://bugs.debian.org/1017079).

Bug#1037009: ITP: python-drf-spectacular-sidecar-nonfree -- Serve builds of Swagger UI and Redoc for Django REST framework

[Carsten Schoenert]

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

* Package name: python-drf-spectacular-sidecar-nonfree
  Version : 2023.5.1
  Upstream Contact: T. Franzel 
* URL : https://github.com/tfranzel/drf-spectacular-sidecar
* License : Apache-2.0, BSD-3, MIT/X
  Programming Lang: Python, JS, CSS
  Description : Serve builds of Swagger UI and Redoc for Django REST 
framework

Serve self-contained distribution builds of Swagger UI and Redoc with
Django either via runserver or collectstatic.

This Django app is an optional addition to drf-spectacular, but does not
depend on it. It may also be used independently.
It uses parts of 
Swagger UI version 4.18.3
Redoc version 2.0.0

The pulled in files for Swager-UI und Redoc are fetched from jsdelivr
and are unfortunately only the minimized parts that probbaly make the
package non-free as I'm unable to rebuild them.
.
The source for Redoc is available from
https://github.com/Redocly/redoc
but isn't packaged or available in some form in Debian.

The same is true for Swagger UI, the source is also avaialbe on GitHub
https://github.com/swagger-api/swagger-ui

So far also no Debian packages are created yet for Swagger-UI which
could be used to rebuild or reference the used minimized files in
drf-spectacular-sidecar.

This package is new dependency for NetBox (see ITP
https://bugs.debian.org/1017079) as since version 3.5.0 NetBox Upstream
has moved over to support using the OpenAPI 3.0 spec to generate the
REST API schema.

I plan to maintain the package within the an Debian Python Team.
As like for NetBox I appreciate any help around how the minimized files
could be rebuild so the package wouldn't needed to be placed in
non-free.

Regards
Carsten

Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

[Carsten Schoenert]

Since my last email about the status usptream did finalize the first
version 3.5.x.

One major release goal was the moving to the OpenAPI 3.0 spec, which
means a switching of the B-D drf-yasg [1] to drf-spectacular-sidecar [2].

>From a packaging POV the new dependency has the quit ethe same issues as
the olde ones, also drf-spectacular-sidecar use precompiled minimized JS
libraries which are not easy rebuildable as no source of the used data
is included in the upstream project. Also it's unclear right now how we
might get the correct sources to recompile the files.

Besides that there are no new additionl Debian packages needed to get a
recent version of NetBox build and packaged. I was able to update the
Graphene related packages in Debian to the most recent versions.

The nearly similar problem to rebuild the minimized files in the NetBox
source is still not solved, I haven't figured out yet how to do this.

[1] https://github.com/axnsan12/drf-yasg
[2] https://github.com/tfranzel/drf-spectacular-sidecar

Regards
Carsten

Bug#1036722: unblock: thunderbird/1:102.11.0-1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: thunderb...@packages.debian.org
Control: affects -1 + src:thunderbird

Please unblock package thunderbird

[ Reason ]
Upstream released a new ESR version of Thunderbird which included as
usual some CVE fixes a few days ago.
https://www.mozilla.org/en-US/security/advisories/mfsa2023-18/

[ Impact ]
Users of bookworm would need to stay with the previous release
1:102.10.0-1 without the latest fixes.

[ Tests ]
The package build has a small set of tests which are successfully
succeeded.
I also use the new version on various devices without any problems.

[ Risks ]
The risk is nearly zero, the same version was build for Debian stable
and oldstable are in the archive and are used without reported problems.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]
I don't have added a debdiff as this would be a rather hughe diff due
the included changes from the underlying changes from firefox.
The changes between 102.10.0 and 102.11.0 can be viewed on Salsa on

https://salsa.debian.org/mozilla-team/thunderbird/-/commit/0626d725e05e7c6a4ef4fb204dddbbd0d1e116c9

unblock thunderbird/1:102.11.0-1

Bug#1035334: unblock: python-selenium/4.9.0+dfsg-1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-selen...@packages.debian.org
Control: affects -1 + src:python-selenium

Please unblock package python-selenium

[ Reason ]
Upstream released another round of update to address some minor updates
and fixes of the 4.x series.
>From the CHANGES files:
* Remove "shadow_root" assertion in Python bindings for Firefox (#11821)
* Simplify driver binary and driver location selecting (#11864)
* Do not pass desired caps in Safari (#11854)
* Selenium Manager get Browser Version from Options classes
* Selenium Manager use binary from Browser Options
* Adding v112 and removing v109

[ Impact ]
Users of bookworm won't get the latest fixes and adjustments, might
result in non usable functionality.

[ Tests ]
The autopkgtest succeeded and so far no bug report nor private email
communication did need to happen.
Using the new version in some of my personal scripts did not show any
problems or regressions.

[ Risks ]
I'd say the risk of introducing problems is quite zero as basically the
difference to the previous version isn't big and straight forward from
reviewing the code changes.
OTOH python-selenium is marked as key package and requires a manual
unblock due this.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
A mostly better viewable diff of the upstream changes between 4.8.3 and
4.9.0 can seen on the Salsa upstream tree.

https://salsa.debian.org/sagiru-guest/python-selenium/-/commit/02f43bac627b47adb42fac57011e2e578797cdab

unblock python-selenium/4.9.0+dfsg-1
diff -Nru python-selenium-4.8.3+dfsg/CHANGES python-selenium-4.9.0+dfsg/CHANGES
--- python-selenium-4.8.3+dfsg/CHANGES  2023-03-24 19:05:50.0 +0100
+++ python-selenium-4.9.0+dfsg/CHANGES  2023-04-21 01:41:21.0 +0200
@@ -1,3 +1,11 @@
+Selenium 4.9.0
+* Remove "shadow_root" assertion in Python bindings for Firefox (#11821)
+* Simplify driver binary and driver location selecting (#11864)
+* Do not pass desired caps in Safari (#11854)
+* Selenium Manager get Browser Version from Options classes
+* Selenium Manager use binary from Browser Options
+* Adding v112 and removing v109
+
 Selenium 4.8.3
 * Add fine grained control for arguments provided to service subprocesses by 
passing a `popen_kw` mapping for all services.
 * `Options` classes now allow `timeout` to be set partially and no longer 
raise an exception when all values are not provided. (#11623)
diff -Nru python-selenium-4.8.3+dfsg/debian/changelog 
python-selenium-4.9.0+dfsg/debian/changelog
--- python-selenium-4.8.3+dfsg/debian/changelog 2023-03-29 12:14:56.0 
+0200
+++ python-selenium-4.9.0+dfsg/debian/changelog 2023-04-22 13:02:57.0 
+0200
@@ -1,3 +1,12 @@
+python-selenium (4.9.0+dfsg-1) unstable; urgency=medium
+
+  * [02f43ba] New upstream version 4.9.0+dfsg
+  * [e4e1dcd] Use a not so usual port for chromium test
+Use port 8088 instead of 8000, the port 8000 might be in use already by
+    some other process.
+
+ -- Carsten Schoenert   Sat, 22 Apr 2023 13:02:57 
+0200
+
 python-selenium (4.8.3+dfsg-1) unstable; urgency=medium
 
   * [9118276] New upstream version 4.8.3+dfsg
diff -Nru python-selenium-4.8.3+dfsg/debian/tests/test-chromium 
python-selenium-4.9.0+dfsg/debian/tests/test-chromium
--- python-selenium-4.8.3+dfsg/debian/tests/test-chromium   2023-03-29 
12:14:56.0 +0200
+++ python-selenium-4.9.0+dfsg/debian/tests/test-chromium   2023-04-22 
13:02:57.0 +0200
@@ -2,7 +2,7 @@
 
 set -exu
 
-python3 -m http.server 8000 --bind 127.0.0.1 --directory="$(pwd)" &
+python3 -m http.server 8088 --bind 127.0.0.1 --directory="$(pwd)" &
 pid=$!
 trap "kill $pid" EXIT
 
@@ -23,23 +23,26 @@
 
 driver = webdriver.Chrome(options = chrome_options)
 
-print("Getting data from http://127.0.0.1:8000";)
+print("Getting data from http://127.0.0.1:8088";)
 
-if driver.get("http://127.0.0.1:8000";) == None:
+if driver.get("http://127.0.0.1:8088";) == None:
 print("Success.")
 else:
 print("Failed!")
+sys.exit(1)
 
 print("Looking for a link named 'debian/'")
 link = driver.find_element(By.LINK_TEXT, "debian/")
 
 if link.click() == None:
 print("Success.")
+print()
+print("\nTest seems to be successful!\nTest was using the following HTML 
data to test the Chrome webdriver.\n")
+print("--- %< ---")
+print(driver.page_source)
+print("--- >% ---")
 else:
 print("Failed!")
+sys.exit(1)
 
-p

Bug#1035296: kicad: Program crashes

[Carsten Schoenert]

Hello Serkan,

Am 30.04.23 um 08:32 schrieb Serkan:

Dear Maintainer,

The program crashes when clicking the "Select item(s)" button with the
simulation probe selected. When I run the program from the terminal, the phrase
"Sharding failure" appears.

Short summary:
After completing the simulation calculations, selecting the wire in the
"Schematic Editor" and clicking the "Select item(s)" (arrow) button at the top
right to see the waveform in a node crashes the program.


this sounds like some issue related to libngspice.

You might try to install the libngspice0 package from experimental 
release and retry your steps.



https://packages.debian.org/experimental/libngspice0
If this does not help at least some down striped KiCad project files 
would be needed so we can try to re-adjust your setup. Without any data 
it's impossible to see the issue on my side.


Please provide some more information (data, logs, steps etc.) what you 
are doing.


Extra note:
Debian is now quite short before the full freeze of the bookworm 
release, unfortunately the KiCad 7 release did happen to late by 
upstream to make it available in bookworm. Even if your issue is a 
upstream issue no fixup for the old 6.x release will happen. It's also 
possible that your issue isn't happen within KiCad 7. KiCad 7 is in 
Debian available also in the experimental release. It's build on top of 
unstable so you should be able to simply install the packages on the CLI 
after a potential modification of your sources.list data.


--
Regards
Carsten

Bug#1034046: unblock: markdown-exec/1.4.0-1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: markdown-e...@packages.debian.org
Control: affects -1 + src:markdown-exec

Please unblock package markdown-exec

[ Reason ]
The package got rather small upstream modifications since 1.3.0 I'd like
to see in the bookworm release. Another reason is the mark as a core
package which requires a manually unblock by the RT.

An diff about the differences between 1.3.0 and 1.4.0 can be viewed on
the project GitHub website.

https://github.com/pawamoy/markdown-exec/compare/1.3.0...1.4.0

[ Impact ]
The user can use a improved Session handling which was added to 1.4.0.

[ Tests ]
All the tests while package build and within the autopkgtest run
succeeded. Using the newer Debian package in local projects working just
fine.

[ Risks ]
The risks are quite low as only extra functionality was added and no
changes did happen to the existing code.
No issues got reported since the upload of 1.4.0-1 almost 3 weeks ago.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


diff -Nru markdown-exec-1.3.0/CHANGELOG.md markdown-exec-1.4.0/CHANGELOG.md
--- markdown-exec-1.3.0/CHANGELOG.md2023-02-18 13:54:04.0 +0100
+++ markdown-exec-1.4.0/CHANGELOG.md2023-03-15 21:43:25.0 +0100
@@ -5,6 +5,14 @@
 and this project adheres to [Semantic 
Versioning](http://semver.org/spec/v2.0.0.html).
 
 

+## [1.4.0](https://github.com/pawamoy/markdown-exec/releases/tag/1.4.0) - 
2023-03-15
+
+[Compare with 
1.3.0](https://github.com/pawamoy/markdown-exec/compare/1.3.0...1.4.0)
+
+### Features
+
+- Sessions: persist and reuse state for Python and Pycon code blocks 
([a8fef5e](https://github.com/pawamoy/markdown-exec/commit/a8fef5e90b1d7165e16ff5afe4b84e8441503098)
 by Timothée Mazzucotelli). [Issue 
#16](https://github.com/pawamoy/markdown-exec/issues/16)
+
 ## [1.3.0](https://github.com/pawamoy/markdown-exec/releases/tag/1.3.0) - 
2023-02-18
 
 [Compare with 1.2.0](https://github.com/pawamoy/markdown-exec/compare/1.2.0...1.3.0)

diff -Nru markdown-exec-1.3.0/debian/changelog 
markdown-exec-1.4.0/debian/changelog
--- markdown-exec-1.3.0/debian/changelog2023-02-27 12:21:30.0 
+0100
+++ markdown-exec-1.4.0/debian/changelog2023-03-19 07:26:01.0 
+0100
@@ -1,3 +1,9 @@
+markdown-exec (1.4.0-1) unstable; urgency=medium
+
+  * [2aede3c] New upstream version 1.4.0
+
+ -- Carsten Schoenert   Sun, 19 Mar 2023 07:26:01 
+0100
+
 markdown-exec (1.3.0-1) unstable; urgency=medium
 
   * [8a80096] New upstream version 1.3.0

diff -Nru markdown-exec-1.3.0/docs/usage/index.md 
markdown-exec-1.4.0/docs/usage/index.md
--- markdown-exec-1.3.0/docs/usage/index.md 2023-02-18 13:54:04.0 
+0100
+++ markdown-exec-1.4.0/docs/usage/index.md 2023-03-15 21:43:25.0 
+0100
@@ -258,6 +258,27 @@
 > WARNING  -  markdown_exec: Execution of python code block 'print world' 
exited with errors
 > ```
 
+## Sessions

+
+Markdown Exec makes it possible to persist state between executed code blocks.
+To persist state and reuse it in other code blocks, give a session name to 
your blocks:
+
+md exec="1" source="material-block" title="Sessions"
+```python exec="1" session="greet"
+def greet(name):
+print(f"Hello {name}!")
+```
+
+Hello Mushu!
+
+```python exec="1" session="greet"
+greet("Ping")
+```
+
+
+WARNING: **Limitation**  
+Sessions only work with Python and Pycon syntax for now.

+
 ## Literate Markdown
 
 With this extension, it is also possible to write "literate programming" Markdown.

diff -Nru markdown-exec-1.3.0/README.md markdown-exec-1.4.0/README.md
--- markdown-exec-1.3.0/README.md   2023-02-18 13:54:04.0 +0100
+++ markdown-exec-1.4.0/README.md   2023-03-15 21:43:25.0 +0100
@@ -91,5 +91,14 @@
 
 The `exec` option will be true for every possible value except `0`, `no`, `off` and `false` (case insensitive).
 
+Below you can see an example of running a bash script that is expected to

+return a non-zero exit code:
+
+md
+```bash exec="1" source="tabbed-left" returncode="2"
+grep extra_css README.md && exit 2
+```
+
+
 See [usage](https://pawamoy.github.io/markdown-exec/usage/) for more details,
 and the [gallery](https://pawamoy.github.io/markdown-exec/gallery/) for more 
examples!
diff -Nru markdown-exec-1.3.0/src/markdown_exec/formatters/base.py 
markdown-exec-1.4.0/src/markdown_exec/formatters/base.py
--- markdown-exec-1.3.0/src/markdown_exec/formatters/base.py2023-02-18 
13:54:04.0 +0100
+++ markdown-exec-1.4.0/src/markdown_exec/formatters/base.py2023-03-15 
21:43:25.0 +0100
@@ -50,6 +50,7 @@
 id: str = "",  # noqa: A002,V

Bug#1033789: unblock: verilator/5.006-3

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: verila...@packages.debian.org
Control: affects -1 + src:verilator

Please unblock package verilator

[ Reason ]
Dimitry Shachnev reported a RC issue (#1033667) against the verilator
package which is fixed by version 5.006-3.

[ Impact ]
Without that fix users are unable to install the verilator package in
bookworm.

[ Tests ]
The verialtor package has currently no autopkgtest so only manual
testing was happen.

[ Risks ]
There are no typical risks, verilator has no reverse dependencies by
or in other packages.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

As no modification did happen in the upstream related code parts I add
the debian/ related changes directly inline.

diff --git a/debian/changelog b/debian/changelog
index 4c4d83e7..48675e51 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+verilator (5.006-3) unstable; urgency=medium
+
+  * Team upload
+  [ Dmitry Shachnev ]
+  * [38e486b] Move ${sphinxdoc:Built-Using} to the correct field.
+(Closes: #1033667)
+
+  [ Carsten Schoenert ]
+  * [975c120] d/gbp.conf: Adjust to debian/bookworm
+  * [e05438c] Rebuild patch queue from patch-queue branch
+Added patches:
+Fix-build-on-hppa.patch
+Fix-date-on-the-front-page-of-verilator.pdf-3956-3957.patch
+(Closes: #1030913, #1031711)
+
+ -- Carsten Schoenert   Thu, 30 Mar 2023 20:05:11 
+0200
+
 verilator (5.006-2) unstable; urgency=medium

   * Team upload
diff --git a/debian/control b/debian/control
index d02cf292..add11de7 100644
--- a/debian/control
+++ b/debian/control
@@ -31,8 +31,9 @@ Depends:
  ${misc:Depends},
  ${perl:Depends},
  ${shlibs:Depends},
- ${sphinxdoc:Built-Using},
  ${sphinxdoc:Depends},
+Built-Using:
+ ${sphinxdoc:Built-Using},
 Recommends:
  libsystemc-dev,
 Suggests:
diff --git a/debian/gbp.conf b/debian/gbp.conf
index f892216e..f59e67e2 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -3,7 +3,7 @@
 pristine-tar = True
 # generate gz compressed orig.tar file
 compression = gz
-debian-branch = debian/sid
+debian-branch = debian/bookworm
 upstream-branch = upstream

 [pq]
diff --git a/debian/patches/Fix-build-on-hppa.patch 
b/debian/patches/Fix-build-on-hppa.patch
new file mode 100644
index ..d0a82040
--- /dev/null
+++ b/debian/patches/Fix-build-on-hppa.patch
@@ -0,0 +1,24 @@
+From: Larry Doolittle 
+Date: Fri, 10 Feb 2023 21:31:44 -0800
+Subject: Fix build on hppa
+
+As supplied by John David Anglin in Debian bug #1030913
+
+Forwarded: https://github.com/verilator/verilator/pull/3954
+---
+ include/verilatedos.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/include/verilatedos.h b/include/verilatedos.h
+index 0e30164..7efd61e 100644
+--- a/include/verilatedos.h
 b/include/verilatedos.h
+@@ -519,6 +519,8 @@ using ssize_t = uint32_t;  ///< signed size_t; returned 
from read()
+ # define VL_CPU_RELAX() asm volatile("nop" ::: "memory");
+ #elif defined(__aarch64__) || defined(__arm__)
+ # define VL_CPU_RELAX() asm volatile("yield" ::: "memory")
++#elif defined(__hppa__)  // HPPA does not currently have yield/pause
++# define VL_CPU_RELAX() asm volatile("nop" ::: "memory")
+ #elif defined(__loongarch__)  // LoongArch does not currently have yield/pause
+ # define VL_CPU_RELAX() asm volatile("nop" ::: "memory")
+ #elif defined(__mips64el__) || defined(__mips__) || defined(__mips64__) || 
defined(__mips64)
diff --git 
a/debian/patches/Fix-date-on-the-front-page-of-verilator.pdf-3956-3957.patch 
b/debian/patches/Fix-date-on-the-front-page-of-verilator.pdf-3956-3957.patch
new file mode 100644
index ..d4d559a2
--- /dev/null
+++ b/debian/patches/Fix-date-on-the-front-page-of-verilator.pdf-3956-3957.patch
@@ -0,0 +1,69 @@
+From: Larry Doolittle 
+Date: Sun, 12 Feb 2023 20:21:03 -0800
+Subject: Fix date on the front page of verilator.pdf (#3956) (#3957)
+
+Forwarded: https://github.com/verilator/verilator/issues/3956
+---
+ docs/guide/conf.py | 27 ---
+ 1 file changed, 12 insertions(+), 15 deletions(-)
+
+diff --git a/docs/guide/conf.py b/docs/guide/conf.py
+index 04759c6..9f69245 100644
+--- a/docs/guide/conf.py
 b/docs/guide/conf.py
+@@ -10,7 +10,6 @@
+ # --
+ # -- Path setup
+
+-from datetime import datetime
+ import os
+ import re
+ import sys
+@@ -24,10 +23,17 @@ def get_vlt_version():
+ filename = "../../Makefile"
+ with open(filename, "r", encoding="utf8") as fh:
+ for line in fh:
+-match = re.search(r"PACKAGE_VERSION_NUMBER *= *([a-z0-9.]+)", 
line)
++match = re.search(r"PACKAGE_VERSION *= *([a-z0-9.]+) +([-0-9]+)"

Bug#1033787: unblock: python-selenium/4.8.3+dfsg-1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-selen...@packages.debian.org
Control: affects -1 + src:python-selenium

Please unblock package python-selenium

[ Reason ]
There was another micro update of python-selenium which includes these
modifications (according to the documented upstream changes). Not all of
these modification are located within the Python specific flavor of
Selenium. There were added a lot more of type safe checking basically
in this update and the -doc package got Sphinx related updates.

Selenium 4.8.3
* Add fine grained control for arguments provided to service
 subprocesses by passing a `popen_kw` mapping for all services.
* `Options` classes now allow `timeout` to be set partially and no
  longer raise an exception when all values are not provided. (#11623)
* No longer sending `SIGKILL` to subprocesses in instances where
  `SIGTERM` was successful within 60 seconds.
* Add CDP files for v111 and remove v108
* Pass default to `pop` when parsing service popen_kw
* Using json output with Selenium Manager
* Sphinx config update to keep invoked methods and shorter aliases in
  documentation (#11802)

[ Impact ]
User couldn't use the latest and greatest version of python-selenium in
Debian bookworm.

[ Tests ]
All upstream tests were successfull, a small checking of some local used
Selenium based snippets did also work as expected. Also the DebCI did
not shown any regressions.

[ Risks ]
There are no real risk to me, looking at the upstream changes I don't
see any potential pitfalls.
python-selenium is a key package and needs an manual unblock by the RT.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
There is also a differential view visable in the source repository on
GitHub.

https://github.com/SeleniumHQ/selenium/compare/selenium-4.8.2-python...selenium-4.8.3-python

But this is much bigger as the attached debdiff file as it also contains
parts of upstream code which we do filter out to fullfill the DFSG
requirements.

The Debian related modifications are only this rather small part.

$ git diff debian/4.8.2+dfsg-1 debian/
diff --git a/debian/changelog b/debian/changelog
index e10915a..ef494f9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-selenium (4.8.3+dfsg-1) unstable; urgency=medium
+
+  * [9118276] New upstream version 4.8.3+dfsg
+  * [5bb3ae9] debian/: Move d/docs to d/python-selenium-doc.links
+
+ -- Carsten Schoenert   Wed, 29 Mar 2023 12:14:56 
+0200
+
 python-selenium (4.8.2+dfsg-1) unstable; urgency=medium

   * [8e56110] New upstream version 4.8.2+dfsg
diff --git a/debian/docs b/debian/docs
deleted file mode 100644
index a1320b1..000
--- a/debian/docs
+++ /dev/null
@@ -1 +0,0 @@
-README.rst
diff --git a/debian/python-selenium-doc.links b/debian/python-selenium-doc.links
new file mode 100644
index 000..567b3ed
--- /dev/null
+++ b/debian/python-selenium-doc.links
@@ -0,0 +1,4 @@
+# We can't just copy/install the original symlink from the source, it would
+# point to a non existing file after the packaging. So do the correct linking
+# here.
+usr/share/doc/python-selenium-doc/html/_sources/index.rst.txt   
usr/share/doc/python-selenium-doc/README.rst

unblock python-selenium/4.8.3+dfsg-1
diff -Nru python-selenium-4.8.2+dfsg/CHANGES python-selenium-4.8.3+dfsg/CHANGES
--- python-selenium-4.8.2+dfsg/CHANGES  2023-02-18 00:17:10.0 +0100
+++ python-selenium-4.8.3+dfsg/CHANGES  2023-03-24 19:05:50.0 +0100
@@ -1,3 +1,12 @@
+Selenium 4.8.3
+* Add fine grained control for arguments provided to service subprocesses by 
passing a `popen_kw` mapping for all services.
+* `Options` classes now allow `timeout` to be set partially and no longer 
raise an exception when all values are not provided. (#11623)
+* No longer sending `SIGKILL` to subprocesses in instances where `SIGTERM` was 
successful within 60 seconds.
+* Add CDP files for v111 and remove v108
+* Pass default to `pop` when parsing service popen_kw
+* Using json output with Selenium Manager
+* Sphinx config update to keep invoked methods and shorter aliases in 
documentation (#11802)
+
 Selenium 4.8.2
 * Update tox.ini for a valid "isort" version (#11667)
 * Undo a bug fix that caused a worse bug. (#11666)
diff -Nru python-selenium-4.8.2+dfsg/conftest.py 
python-selenium-4.8.3+dfsg/conftest.py
--- python-selenium-4.8.2+dfsg/conftest.py  2023-02-18 00:17:10.0 
+0100
+++ python-selenium-4.8.3+dfsg/conftest.py  2023-03-24 19:05:50.0 
+0100
@@ -237,7 +237,9 @@
 )
 except Exception:
 print("Starting the Selenium server")
-process = subprocess.Popen(["java", "-jar", _path, "standalone", 
"--port", ""])
+process =

Bug#1033667: verilator: Uninstallable in sid because of ${sphinxdoc:Built-Using} dependency

[Carsten Schoenert]

Hello Dimitry,

Am Wed, Mar 29, 2023 at 09:10:17PM +0300 schrieb Dmitry Shachnev:
 
> In a clean sid chroot, verilator is not installable:
... 
> This is because that package has ${sphinxdoc:Built-Using} among its
> dependencies.
> 
> That substitution variable is intended to be used in Built-Using field of
> architecture-dependent packages, NOT in Depends field.
> 
> I have created a merge request [1] on salsa to fix this.
> 
> [1]: https://salsa.debian.org/electronics-team/verilator/-/merge_requests/3

nice catch!
Thanks also for preparing a patch/MR on this!

I've to admit I haven't looked that much on th existing structure in
d/control while working on verilator weeks ago as the package could be
build successfully in the past.

Will have a look on this the next days!

Regards
Carsten

Bug#1031345: kicad: Please update

[Carsten Schoenert]

Hello Marius,

Am 29.03.23 um 20:23 schrieb Marius Paul Isken:

Please upgrade the package to 7.0.1, upstream was released six weeks ago.


did you noticed you writing to an already closed bug report?

This issue was closed due an uploaded version 7.0.1.
The reason why KiCad 7.x will not get included within the bookworm 
release was written in my first answer to the bugreport.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031345#10

If you are using unstable/testing you can still install the relevant 
packages from experimental mostly to get the most recent version of KiCad.


--
Regards
Carsten

Bug#1026118: thunderbird: please add support for riscv64

[Carsten Schoenert]

Hello Bo,

Am 29.03.23 um 01:23 schrieb Bo YU:

Source: thunderbird
Version: 1:110.0~b4-1
Followup-For: Bug #1026118

FYI, I just can build the thunderbird package on qemu-user with the
patch. Once it can be built on Unmatched, I will update it here.

The riscv64 binary packages here:
https://drive.google.com/drive/folders/1klWvrjq-geMFAWIXTas6lPz8e8_7Eavo


will give the patch a try together with the next major version 113 probably.

--
Regrads
Carsten

Bug#1033188: unblock: thunderbird/1:102.9.0-1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: thunderb...@packages.debian.org
Control: affects -1 + src:thunderbird

Please unblock package thunderbird

[ Reason ]
A new upstream release of the Thunderbird ESR series did happen that fixes a
few CVE vulnerabilities.

[ Impact ]
Debian testing/bullseye would stick with version 102.8.0.

[ Tests ]
Even if the autopkgtests are marked superficial the main test did show
that Thunbderbird is able to start and is picking up the global settings
from /etc/thunderbird.
Besides that I tested the new version a lot on alocal basis.

[ Risks ]
We are in the middle of the ESR releases and upstream change are now a
lot less deep and agressive than on a start of a new ESR series.
stable-security and also oldstable-security already are using 102.9.0 as
actual version.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing (only for the
  debian/folder)

[ Other info ]
The modifications for the source are quite big as usual but are going in
parallel with firefox-esr due the same sorce code base. Please see further down
for a diff of the chnages on the debian side.
Basically only the Standards-Version was changed.

unblock thunderbird/1:102.9.0-1

$ git diff debian/1%102.8.0-1 debian/
diff --git a/debian/changelog b/debian/changelog
index b1c0dd97102..340fa97407c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+thunderbird (1:102.9.0-1) unstable; urgency=medium
+
+  * [ad8cc7c] New upstream version 102.9.0
+Fixed CVE issues in upstream version 102.9 (MFSA 2023-11):
+CVE-2023-25751: Incorrect code generation during JIT compilation
+CVE-2023-28164: URL being dragged from a removed cross-origin iframe
+into the same tab triggered navigation
+CVE-2023-28162: Invalid downcast in Worklets
+CVE-2023-25752: Potential out-of-bounds when accessing throttled streams
+CVE-2023-28176: Memory safety bugs fixed in Thunderbird 102.9
+  * [b0a22c0] d/control: Increase Standards-Version to 4.6.2
+No further changes needed.
+
+ -- Carsten Schoenert   Wed, 15 Mar 2023 19:54:53 
+0100
+
 thunderbird (1:102.8.0-1) unstable; urgency=medium
 
   * [b130936] New upstream version 102.8.0
diff --git a/debian/control b/debian/control
index 13c0245e0c8..7f30678cab7 100644
--- a/debian/control
+++ b/debian/control
@@ -60,7 +60,7 @@ Vcs-Git: 
https://salsa.debian.org/mozilla-team/thunderbird.git -b debian/sid
 Vcs-Browser: 
https://salsa.debian.org/mozilla-team/thunderbird/commits/debian/sid/
 Homepage: https://www.thunderbird.net/
 X-Debian-Homepage: http://wiki.debian.org/Thunderbird
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 
 Package: thunderbird
 Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64

Bug#1033119: thunderbird: cannot auth against Oauth2 microsoft365 account

[Carsten Schoenert]

Hello Kamil,

Am 17.03.23 um 17:04 schrieb Kamil Jońca:

Package: thunderbird
Version: 1:102.9.0-1
Severity: normal
X-Debbugs-Cc: kjo...@poczta.onet.pl

Dear Maintainer,

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

* What led up to the situation?

  Trying to fetch mail from microsoft365 account, where oauth2 is configured
* What exactly did you do (or not do) that was effective (or
  ineffective)?
After upgrade I started thunderbird as usual.

* What was the outcome of this action?

"waiting icon", message "connected to outlook.office365.com" in status
bar. No new mails were fetched.

* What outcome did you expect instead?
Fetch new mails.


it seems that the depending library libnss3-dev, that got an update 
right after the update of the Thunderbird package, had introduced some 
regressions that could result in the problems you did encounter.


Please see https://bugs.debian.org/1033101

Please pull the new binary package and check the usability again.


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.6-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.5-1
ii  libgtk-3-0   3.24.36-3
ii  libicu72 72.1-3
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  librnp0  0.16.2-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.4-2
ii  libx11-xcb1  2:1.8.4-2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.44.0-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:7.5.0-1
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.8-3
ii  fonts-lyx 2.3.7-1
ii  libgssapi-krb5-2  1.20.1-1

-- debconf-show failed


--
Regards
Carsten

Bug#1031541: thunderbird: Thunderbird depends on obsolete package

[Carsten Schoenert]

Control: severity -1 normal

Hello Abdallah,

Am 18.02.23 um 09:37 schrieb Abdallah Yves Lambert:

Package: thunderbird
Version: 1:104.0~b2-1
Severity: grave
Justification: renders package unusable


I don't think so.


Dear Maintainer,

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

* What led up to the situation?
upgrding system, I could not remove libicu71 which is obsolete,
because thunderbird 1:104.0~b2-1 depends on it (the conflict resolver
suggest to downgrade thunderbird)


The version you use is only available in experimental, and this for a 
very long time as the thunderbird package can't get updated to more 
recent versions for various reasons.


Currently I don't think it makes sense to rebuild this rather old 
version to use a newer icu version, but you could do this by yourself 
e.g. if you really want to stay on this version.


Otherwise I suggest to downgrade thunderbird and use the version 
available in ustable/testing.


Due the started freeze for bookworm I will not spend a serious amount of 
time on getting the version in experimental updated to something new.


--
Regards
Carsten

Bug#1031345: kicad: Please update

[Carsten Schoenert]

Control: severity -1 wishlist

Hello Matthias,

Am 15.02.23 um 13:25 schrieb Matthias Urlichs:


KiCAD 7 is out. Please update; it really should be in Bookworm.
unfortunately this will not happen, it's simply to late get KiCad 7.0.0 
into the next stable release.
We will work on providing backported packages as usual once the bookworm 
release is out.


--
Regards
Carsten

Bug#1031339: unblock: thunderbird/102.7.2-1

[Carsten Schoenert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: thunderb...@packages.debian.org
Control: affects -1 + src:thunderbird

Please unblock package thunderbird

[ Reason ]
Due some planed traveling on my side I packaged the release candidate
for Thunderbird 102.7.1-1 before the real final release on Mozilla did
happen. I typically use the release candidate once it is available and
normally this works without problems, but not this time for 102.7.1.

Mozilla did encounter OAuth issues for user of O365 and did prepare a
new release candidate which I was not able to pick up directly.

This ended in an really delayed upload of the "fixed" Debian version
1:102.7.1+1-1 on 2023-02-07.
And shortly after my upload Mozilla released one more new version
102.7.2 which is now sitting unstable and due the date 12th February
migration time is extended to 10 days.

The next ESR version of Thunderbird (102.8.0) will get released today
but I wanted to see first the version 102.7.2-1 get migrated to tested
so users of testing do not need to wait even longer for a fixed version
of Thunderbird which is working again with O365 before I do a new upload
of the next ESR version.

[ Impact ]
Users in testing need to wait for a fixed Debian version for 

CVE-2023-0430: Revocation status of S/Mime signature certificates was
   not checked
(https://bugzilla.mozilla.org/show_bug.cgi?id=1810760)

[ Tests ]
I provided some testbuild for the real upstream version 102.7.1 before
started to upload the final version for the archive. Affected user
confirmed the fixed OAuth functionality.

[ Risks ]
There are no special risks as users confirmed the usability of the fixed
version in Debian.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]
Currently nothing to add here.

unblock thunderbird/102.7.2-1