Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

2024-05-09 Thread Louis-Philippe Véronneau

tags 1070770 patch
thanks

I've created a patch on Salsa that creates a new Lintian check for this.

https://salsa.debian.org/lintian/lintian/-/merge_requests/504

Cheers,

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



Bug#1070252: reassign 1070252 to python3-mpv

2024-05-03 Thread Louis-Philippe Véronneau

reassign 1070252 python3-mpv 1.0.4-1
retitle 1070252 python3-mpv: playback broken by libmpv 0.38
tags 1070252 fixed-upstream
thanks

It seems this is caused by the python3-mpv package and has been fixed 
upstream.


I'll make an upload as soon as I find the time.

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



Bug#1070252: sublime-music: playback broken by libmpv 0.38

2024-05-02 Thread Louis-Philippe Véronneau

Package: sublime-music
Version: 0.12.0-1
Severity: critical
Forwarded: https://github.com/sublime-music/sublime-music/issues/462

Using libmpv2 0.38, the playback is broken an results in the following trace:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sublime_music/dbus/manager.py", line 24, 
in wrapper
function(*args)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 629, in 
on_play_pause
self.play_song(self.app_config.state.current_song_index)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 1415, in 
play_song
song_details_future.add_done_callback(
  File "/usr/lib/python3/dist-packages/sublime_music/adapters/manager.py", line 
140, in add_done_callback
fn(self, *args)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 1416, in 

lambda f: do_play_song(self.song_playing_order_token, f.result())
  ^^^
  File "/usr/lib/python3/dist-packages/sublime_music/dbus/manager.py", line 24, 
in wrapper
function(*args)
  File "/usr/lib/python3/dist-packages/sublime_music/app.py", line 1166, in 
do_play_song
self.player_manager.play_media(
  File "/usr/lib/python3/dist-packages/sublime_music/players/manager.py", line 
188, in play_media
current_player.play_media(uri, progress, song)
  File "/usr/lib/python3/dist-packages/sublime_music/players/mpv.py", line 137, 
in play_media
self.mpv.command(
  File "/usr/lib/python3/dist-packages/mpv.py", line 1233, in command
_mpv_command_node(self.handle, ppointer, out)
  File "/usr/lib/python3/dist-packages/mpv.py", line 148, in raise_for_ec
raise ex
ValueError: ('Invalid value for mpv parameter', -4, (, 
, ))

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



Bug#1069591: cyckle: Fails to start

2024-04-21 Thread Jean Louis
Package: cyckle
Version: cycle
Severity: important

Dear Maintainer,

   * What led up to the situation?

$ cycle

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

I have entered name and password.

   * What was the outcome of this action?

Software cannot run.

$ cycle 
/usr/bin/cycle:35: DeprecationWarning: Use setlocale(), getencoding() and 
getlocale() instead
  dl = locale.getdefaultlocale()
WARNING: using XIM input method is unsupported and may result in problems with 
input handling and flickering. Consider unsetting GTK_IM_MODULE or setting to 
"ibus".
Traceback (most recent call last):
  File "/usr/bin/cycle", line 212, in OnInit
self.frame_init()
  File "/usr/bin/cycle", line 216, in frame_init
frame = MyFrame(None, -1, "")
^
  File "/usr/bin/cycle", line 81, in __init__
self.cal = Cal_Year(self)
   ^^
  File "/usr/share/cycle/cal_year.py", line 168, in __init__
self.Init_Year()
  File "/usr/share/cycle/cal_year.py", line 209, in Init_Year
self.SetScrollbars(20, 20, w/20, h/20)
TypeError: _ScrolledWindowBase.SetScrollbars(): argument 3 has unexpected type 
'float'
OnInit returned false, exiting...


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

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



Bug#1067650: davmail: O365Interactive fails with "superclass access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame"

2024-04-05 Thread Louis-Philippe Véronneau

On 2024-04-05 3 h 04 a.m., Alexandre Rossi wrote:

Hi,


Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: superclass 
access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame$2 (in 
unnamed module @0x112d0a71) cannot access class sun.net.www.protocol.https.Handler (in 
module java.base) because module java.base does not export sun.net.www.protocol.https to 
unnamed module @0x112d0a71


Upstream points out that davmail should be launched with:

$ /usr/bin/java \
  -Xmx512M -Dsun.net.inetaddr.ttl=60 \
  --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED \
  -jar /usr/share/davmail/davmail.jar

Do you confirm this fixes the problem?


Hi,

Thanks for the follow up.

Yes, that does fix the issue!

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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1068444: oar-web-status drawgant-svg does't work with php8.2

2024-04-05 Thread Jean Louis Mas

Package: oar-web-status
Version: 2.5.9-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
   Upgrade to Debian 12
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Restart apache2 with php8.2 modules enabled
   * What was the outcome of this action?
   The url drawgantt/drawgantt.php never display any data
   * What outcome did you expect instead?
   Normal display of the drawgantt tool

In fact the file 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php use line 606 a 
deprecated PHP function

usort($this->children, create_function('$a,$b','return $b->cmp($a);'));

create_function has been removed in php8.0 and further versions : 
"Warning This function has been DEPRECATED as of PHP 7.2.0, and REMOVED 
as of PHP 8.0.0. Relying on this function is highly discouraged".

see https://www.php.net/manual/en/function.create-function.php

This may be the root cause of the bug


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

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages oar-web-status depends on:
ii  apache2 [httpd-cgi]   2.4.57-2
ii  libappconfig-perl 1.71-2.2
ii  libdbd-pg-perl3.16.0-2
ii  libdbi-perl   1.643-4
ii  libsort-naturally-perl1.03-4
ii  libtie-ixhash-perl1.23-4
ii  perl  5.36.0-7+deb12u1
ii  php   2:8.2+93
ii  php-pgsql 2:8.2+93
ii  php8.2 [php]  8.2.7-1~deb12u1
ii  php8.2-pgsql [php-pgsql]  8.2.7-1~deb12u1

oar-web-status recommends no packages.

Versions of packages oar-web-status suggests:
pn  oar-doc  

-- no debconf information
--
Jean Louis Mas



OpenPGP_0xECE0A0796958DB8E.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1068336: kicad-footprints: The version is too high, the other packages are still 7.0.1 and not compatible

2024-04-03 Thread Louis
Package: kicad-footprints
Version: 8.0.1
Severity: important
X-Debbugs-Cc: louis19122...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Installing kicad from debian testing
   * What was the outcome of this action?
can't add any components in editor since the library doesn't load


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

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



Bug#1066011: whipper: Please drop dependencies on python3-distutils

2024-04-02 Thread Louis-Philippe Véronneau

The patch in question:

https://salsa.debian.org/python-team/packages/whipper/-/commit/574b58db64dc710796285793170482547135ad03

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



Bug#1066011: whipper: Please drop dependencies on python3-distutils

2024-04-02 Thread Louis-Philippe Véronneau

tags 1066011 +patch
forwarded 1066011 https://github.com/whipper-team/whipper/issues/611
thanks

Thanks for opening this bug report. I've created a patch that fixes this 
issue. I'm planning on downgrading this bug to keep track of the 
upstream issue.


I haven't uploaded the fix yet, since I also need to add a new patch to 
migrate from setup.py to a pyproject.toml file. Still working on that.


Cheers,

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



Bug#1067620: add max version to python3-ruamel.yaml dependency

2024-03-31 Thread Louis-Philippe Véronneau

retitle 1067620 whipper fails with python3-ruamel.yaml <= 0.18.0
forwarded 1067620 https://github.com/whipper-team/whipper/issues/605
thanks

Hi,

Thanks for opening this bug.

Sadly, even if we add a maximum version in the Debian packaging rules, 
the package will still FTBFS when python3-ruamel.yaml is updated.


I trust that this kind of failure will be caught by the testsuite 
if/when python3-ruamel.yaml is updated in the archive.


In the meantime, I've added more info to the bug so that we'll be 
notified if upstream comes up with a patch.


If you managed to fix this issue on your side and want me to test the 
patch in Debian, don't hesitate to send it!


Cheers,

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



Bug#1067650: davmail: O365Interactive fails with "superclass access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame"

2024-03-24 Thread Louis-Philippe Véronneau

Package: davmail
Version: 6.2.1.3496-1
Severity: important

Dear maintainers,

It seems something recently broke davmail's "O365Interactive" mode in Debian. 
When I try to use it (it's the only mode I can use since $work has mandatory 2FA), the 
login window is never shown and I get the following stacktrace:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: superclass 
access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame$2 (in 
unnamed module @0x112d0a71) cannot access class sun.net.www.protocol.https.Handler (in 
module java.base) because module java.base does not export sun.net.www.protocol.https to 
unnamed module @0x112d0a71
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
at 
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
at 
davmail.exchange.auth.O365InteractiveAuthenticator.lambda$authenticate$0(O365InteractiveAuthenticator.java:150)
at 
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at 
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at 
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at 
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Cheers,

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


Bug#1063915: mirror submission for debian.mirrors.ovh.net

2024-03-22 Thread Louis Sautier

On 3/22/24 17:42, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

On Wed, 2024-02-14 at 20:03 +, OVHcloud wrote:

Site: debian.mirrors.ovh.net
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: OVHcloud
Country: FR France
Location: Anycast (Gravelines, Roubaix and Strasbourg)


Hi Adam,

First, let me just explain in a bit more detail how requests are 
handled. Our DNS A record for debian.mirrors.ovh.net only points to one 
anycast IP address with 4 locations. Once it receives a request, the 
following happens:


Load balancer (anycast IP) in Beauharnois (Canada)→ Caches in 
Beauharnois → Backend in Canada if cache miss


Load balancer (anycast IP) in Gravelines (France)→ Caches in Gravelines 
→ Backend in France if cache miss


Load balancer (anycast IP) in Roubaix(France)→Caches in Roubaix→ Backend 
in France if cache miss


Load balancer (anycast IP) in Strasbourg(France)→Caches in Strasbourg→ 
Backend in France if cache miss



I know there was some discussion on IRC, so apologies if I'm rehashing
here, but:

- are the individual backends exposed in any way?
Not publicly, but if you were to give me me a source IP address, I could 
provide you with an rsync account that has access to both our backends. 
We already do this for other distributions.

- how do you ensure that the backends are in sync with each other?


We take ZFS snapshots after each sync and we send these to the backends. 
Once the latest snapshot has been sent to both backends, they start 
pointing to it. This last operation is performed simultaneously on both.


After this, we compile a list of changed URLs and issue a series of HTTP 
PURGE requests to every cache server, simultaneously too.


We also have monitoring in place to detect discrepancies between the 
backends for all our mirrors.



- what are the chances of users seeing inconsistent state if they hit
different backends which aren't at the same stage of updating?


I think the chances are pretty low as we try to run all phases of the 
sync simultaneously. The most sensitive part would be the cache 
invalidation process which might purge some URLs at slightly different 
times.


All I can say is that, despite the high number of servers already 
relying on our Debian mirror, we have never heard of errors caused by this.



Regards,

Adam


I hope this answers all your questions.


Have a nice day,


Louis



Bug#1065327: ITA: python-levenshtein

2024-03-15 Thread Louis-Philippe Véronneau

Ah, great news then, happy to let you have it :)

I'll be happy to contribute punctually if needed if you do indeed keep 
it in the DPT.


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

On 2024-03-15 07:01, Julian Gilbey wrote:

On Thu, Mar 14, 2024 at 10:40:38AM -0400, Louis-Philippe Véronneau wrote:

retitle 1065327 ITA: python-levenshtein -- extension for computing string 
similarities and edit distances (Python 3)
owner 1065327 Louis-Philippe Véronneau 
thanks

I need this package for sublime-music and since it's being orphaned, I'm 
planning to adopt it.

If someone else wants to maintain this package though, I won't fight you for it 
:)

Cheers (and thanks to morph for the work so far),


Hi Louis-Philippe,

Both Jelmer and I are also willing to take it on.  I wrote to the
Python list in response to Jelmer (before I saw your ITA):

   I've just taken a look at python-levenshtein, as I remember the name
   now: it might make more sense for me to take it as it depends on
   rapidfuzz and rapidfuzz-cpp, which I've just packaged and are sitting
   in NEW.  But if you want to take it, please feel free to do so!  (Once
   rapidfuzz makes it into unstable, a lot of debian/rules could probably
   also be simplified.)

So happy whoever wants to take it; we just won't be able to do much
until rapidfuzz, rapidfuzz-cpp and taskflow make it to unstable.

I do suggest that we keep it within the DPT, though.

Best wishes,

Julian




Bug#1065327: ITA: python-levenshtein

2024-03-14 Thread Louis-Philippe Véronneau

retitle 1065327 ITA: python-levenshtein -- extension for computing string 
similarities and edit distances (Python 3)
owner 1065327 Louis-Philippe Véronneau 
thanks

I need this package for sublime-music and since it's being orphaned, I'm 
planning to adopt it.

If someone else wants to maintain this package though, I won't fight you for it 
:)

Cheers (and thanks to morph for the work so far),

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



Bug#1064286: puppet-lint: please backport v4 to bookworm

2024-02-19 Thread Louis-Philippe Véronneau

Package: puppet-lint
Version: 4.2.4-1
Severity: wishlist

Dear maintainers,

Would it be possible to backport this package to bookworm? v4 introduces 
the `legacy_facts` check, which is very important, since the 
puppet-agent 7 to 8 transition deprecates those.


Having puppet-lint v4 backported would ease this transition a lot, since 
people could lint their existing code base with this new check before 
migrating to Trixie.


Cheers, and thanks for maintaining this package,

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



Bug#1061340: pelican: Please run tests (during build and in an autopkgtest)

2024-01-22 Thread Louis-Philippe Véronneau
.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 19, in load_source
spec.loader.exec_module(mod)
  File "", line 990, in exec_module
  File "", line 1127, in get_code
  File "", line 1185, in get_data
FileNotFoundError: [Errno 2] No such file or directory: 
'/<>/.pybuild/cpython3_3.12/build/samples/pelican.conf.py'

==
FAIL: test_theme_prefix 
(pelican.tests.test_generators.TestGenerator.test_theme_prefix)
Test `!theme` theme prefix.
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_generators.py",
 line 174, in test_theme_prefix
self.assertEqual(expected_path, os.path.dirname(filename))
AssertionError: '/bui[38 
chars]pybuild/cpython3_3.12/build/pelican/themes/notmyidea/templates' != 
'/bui[38 chars]pybuild/cpython3_3.12/build/pelican/themes/simple/templates'
- 
/<>/.pybuild/cpython3_3.12/build/pelican/themes/notmyidea/templates
?   
   ^^^ ^^^ -
+ /<>/.pybuild/cpython3_3.12/build/pelican/themes/simple/templates
?   
   ^^ ^^


==
FAIL: test_theme_static_paths_dirs 
(pelican.tests.test_generators.TestStaticGenerator.test_theme_static_paths_dirs)
Test that StaticGenerator properly copies also files mentioned in
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_generators.py",
 line 1211, in test_theme_static_paths_dirs
self.assertTrue(os.path.isdir(os.path.join(self.temp_output, "theme/css/")))
AssertionError: False is not true

==
FAIL: test_theme_static_paths_files 
(pelican.tests.test_generators.TestStaticGenerator.test_theme_static_paths_files)
Test that StaticGenerator properly copies also files mentioned in
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_generators.py",
 line 1236, in test_theme_static_paths_files
self.assertTrue(
AssertionError: False is not true

==
FAIL: test_log_filter (pelican.tests.test_log.TestLog.test_log_filter)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_log.py", line 
53, in test_log_filter
self.assertEqual(self.handler.count_logs("Log \\d", logging.WARNING), 0)
AssertionError: 5 != 0

==
FAIL: test_error_on_warning 
(pelican.tests.test_testsuite.TestSuiteTest.test_error_on_warning)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_testsuite.py",
 line 8, in test_error_on_warning
with self.assertRaises(UserWarning):
AssertionError: UserWarning not raised

--
Ran 241 tests in 2.186s

FAILED (failures=5, errors=4, skipped=30)

Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄diff --git a/debian/control b/debian/control
index 0d4a471..e362968 100644
--- a/debian/control
+++ b/debian/control
@@ -26,6 +26,9 @@ Build-Depends:
  python3-tz,
  python3-unidecode,
  python3-watchfiles,
+ python3-ordered-set ,
+ python3-typogrify ,
+ python3-markdown ,
 Standards-Version: 4.6.2
 Homepage: https://getpelican.com/
 Vcs-Git: https://salsa.debian.org/python-team/packages/pelican.git
diff --git a/debian/rules b/debian/rules
index f5ee1db..f2ecb0b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,9 +16,6 @@ override_dh_auto_build:
 	PYTHONPATH=. http_proxy='http://127.0.0.1:9/' python3 -m sphinx -N -E -bhtml docs build/html
 	rm -rf build/html/.doctrees
 
-override_dh_auto_test:
-	@echo "Tests currently disabled!"
-
 override_dh_installchangelogs:
 	dh_installchangelogs docs/changelog.rst
 


Bug#1057484: pelican: "ModuleNotFoundError: No module named 'watchfiles"

2024-01-15 Thread Louis-Philippe Véronneau

It seems this library isn't currently packaged in Debian?


I've just ITPed the package and will be uploading it to NEW ASAP.

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1060881: resfinder: please stop build-depending on python3-pdm and use python3-pdm-backend instead

2024-01-15 Thread Louis-Philippe Véronneau

Package: src:resfinder
Severity: important

Dear maintainers,

This package build-depends on python3-pdm, a management tool. It should 
instead build-depend on python3-pdm-backend, the package that provides 
the PEP517-style build backend for PDM.


The python3-pdm package itself it not really maintained and will 
probably be removed from the archive soon. Fixing this issue quickly 
would thus be helpful.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1059807: supysonic: does not write log file

2024-01-06 Thread Louis-Philippe Véronneau

Hi,

How are you running supysonic? If you run it at as a WSGI app, it would 
be the job of your webserver to log the error?


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

On Mon, 01 Jan 2024 19:24:36 +0100 Axel  wrote:

Package: supysonic
Version: 0.7.2+ds-2
Severity: normal
X-Debbugs-Cc: a...@users.sourceforge.net

Dear Maintainer,

some audio files cause the script to die prematurely, probably while attempting 
to
transcode the audio. Unfortunately no log entries are created whatsoever. If 
the log file
cannot be created, an error message is produced, but even the debug setting 
does not
result in any entries.

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

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

Versions of packages supysonic depends on:
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-3
ii  libjs-bootstrap 3.4.1+dfsg-3
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-sphinxdoc 5.3.0-4
ii  python3 3.11.2-1+b1
ii  python3-click   8.1.3-2
ii  python3-flask   2.2.2-3
ii  python3-lxml4.9.2-1+b1
ii  python3-mediafile   0.11.0-1
ii  python3-pil 9.4.0-1.1+b1
ii  python3-pony0.7.16+ds-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-watchdog2.2.1-1
ii  python3-zipstream-ng1.4.0-1

Versions of packages supysonic recommends:
ii  flac 1.4.2+ds-2
ii  lame 3.100-6
ii  libapache2-mod-wsgi-py3  4.9.4-1+b2

Versions of packages supysonic suggests:
ii  python3-psycopg2  2.9.5-1+b1

-- no debconf information




OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1060187: src:peewee: not all tests are run when building and in the autopkgtest (only 5 out of many)

2024-01-06 Thread Louis-Philippe Véronneau

Package: src:peewee
Severity: important
Version: 3.17.0+dfsg-1

Dear maintainers,

It seems peewee only runs 5 tests (out of a bunch) when building and in 
the autopkgtest:


=
platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.3.0
rootdir: /tmp/autopkgtest.VGaWKb/autopkgtest_tmp/build
collected 5 items

tests/test_utils.py . 
[100%]

=

This does not seem like a new problem (it's been the case since at least 
Debian 10), but isn't great.


I haven't investigated why this happens, but I see a `runtests.py` 
script in the upstream root directory. This is probably the right way to 
run tests?


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1056829: peewee: ftbfs with cython 3.0.x

2024-01-06 Thread Louis-Philippe Véronneau

owner 1056829 Louis-Philippe Véronneau 
thanks

This is apparently fixed in version 3.16.3. I'll try to update the package.

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


On Sun, 26 Nov 2023 10:05:53 + Matthias Klose  wrote:

Package: src:peewee
Version: 3.14.10+dfsg-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: cython3

[This bug is targeted to the upcoming trixie release]

The package fails to build in a test rebuild on at least arm64 with
cython 3.0.5, but succeeds to build with cython 0.29.36.  Please
update the package to build with cython 3.0.5 (available in experimental).

If the package cannot be built with cython 3.0.5, please change the
build dependency from cython3 to cython3-legacy (available now in
unstable).  There is no replacement for cython3-dbg.

Build logs building with cython 3.0.5 can be found at
https://people.debian.org/~stefanor/cython3/cython-3.0.5/

See also https://lists.debian.org/debian-python/2023/11/msg00034.html




OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1057484: pelican: "ModuleNotFoundError: No module named 'watchfiles"

2023-12-05 Thread Louis-Philippe Véronneau
Had a quick look at the Debian package and it seems that all tests are 
disabled.


In my opinion, this is a very good example of why tests at build (and in 
autopkgtests) are important. How do you know the package you're shipping 
isn't broken without tests? (you don't know, that's why there are tests :D).


I would thus strongly suggest you to run tests, or at least part of the 
testsuite if some locale-specific tests are unhelpful.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1057484: pelican: "ModuleNotFoundError: No module named 'watchfiles"

2023-12-05 Thread Louis-Philippe Véronneau

Package: pelican
Version: 4.9.1+dfsg-1
Severity: critical

Dear maintainers,

Running `pelican content` to generate HTML files, I get the following crash:

Traceback (most recent call last):
  File "/usr/bin/pelican", line 5, in 
from pelican.__main__ import main
  File "/usr/lib/python3/dist-packages/pelican/__init__.py", line 24, in 

from pelican.generators import (
  File "/usr/lib/python3/dist-packages/pelican/generators.py", line 20, in 

from pelican.cache import FileStampDataCacher
  File "/usr/lib/python3/dist-packages/pelican/cache.py", line 6, in 
from pelican.utils import mkdir_p
  File "/usr/lib/python3/dist-packages/pelican/utils.py", line 28, in 
import watchfiles
ModuleNotFoundError: No module named 'watchfiles'

It seems this library isn't currently packaged in Debian?

Cheers,

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



Bug#1032864: labwc ITP bug more info

2023-10-01 Thread Louis-Philippe Véronneau

My initial efforts can be found here: https://salsa.debian.org/pollo/labwc

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



Bug#1053315: RM: firmware-tomu -- RoM; RC-buggy; abandoned upstream

2023-10-01 Thread Louis-Philippe Véronneau

Package: ftp.debian.org
Severity: normal

Hello,

I haven't touched this package in a while, it's RC buggy and the 
hardware project behind it is dead.


Please remove it :)

---
po...@mirror.ftp-master.debian.org "dak rm -Rn firmware-tomu"
Will remove the following packages from unstable:

firmware-tomu |  2.0~rc7-2 | source, all

Maintainer: Louis-Philippe Véronneau 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.
---


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



Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS

2023-09-10 Thread Jérôme St-Louis
The fixes for FTBFS have been in upstream for a long time, but I have 
not found time to do a proper release or update the Debian package for a 
while.


Those FTBFS were a result of GCC changes that we fixed in upstream.

The 'latest' branch on our Git repo ( 
https://github.com/ecere/ecere-sdk/commits/latest ) includes the fixes.


Could someone please help with the maintenance instead of removing it?

Thanks a lot.

Kind regards,

-Jerome


On 9/10/23 05:21, Sebastian Ramacher wrote:

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ecere-...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:ecere-sdk

ecere-sdk FTBFS (#995050, #898832) and is not part of bullseye or
bookworm. Please remove this unmaintained package from the archive.

Cheers




Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS

2023-09-10 Thread Jérôme St-Louis
Actually the 'master' branch ( 
https://github.com/ecere/ecere-sdk/commits/master ) also includes the 
FTBFS fixes and would be a more conservative update / fix with only 181 
commits instead of 1905.


Specifically some of the related fixing commits were:

https://github.com/ecere/ecere-sdk/commit/53ec01de1c42cf342a35dc125a4fef01ffb5fced
https://github.com/ecere/ecere-sdk/commit/e52df5589f3c674e8d3c23c8d7194496dc96d60c
https://github.com/ecere/ecere-sdk/commit/9085cb19656728b5ccdbbbe26377ad5112513d01

Thanks again.

Kind regards,

-Jerome

On 9/10/23 16:24, Jérôme St-Louis wrote:
The fixes for FTBFS have been in upstream for a long time, but I have 
not found time to do a proper release or update the Debian package for 
a while.


Those FTBFS were a result of GCC changes that we fixed in upstream.

The 'latest' branch on our Git repo ( 
https://github.com/ecere/ecere-sdk/commits/latest ) includes the fixes.


Could someone please help with the maintenance instead of removing it?

Thanks a lot.

Kind regards,

-Jerome


On 9/10/23 05:21, Sebastian Ramacher wrote:

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ecere-...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:ecere-sdk

ecere-sdk FTBFS (#995050, #898832) and is not part of bullseye or
bookworm. Please remove this unmaintained package from the archive.

Cheers




Bug#1051263: sublime-music has migrated to a new repo, new upstream release available

2023-09-05 Thread Louis-Philippe Véronneau

On 2023-09-05 08 h 45, Nicolas Derive wrote:

Package: sublime-music
Version: 0.11.16-4

Dear DDs, sublime-music has migrated from GitLab to GitHub, so the 
upstream code repository is now 
https://github.com/sublime-music/sublime-music .


Also, there's a new upstream version available (0.12.0), that you 
possibly haven't been notified due to the migration.


Thanks for correcting this.


Best regards,


Nicolas Derive.



Thanks a lot for this bug report! I was indeed not aware of the change 
and I'll update the package as soon as I find some time.


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



Bug#1040066: RM: python-marshmallow-enum -- RoM; replaced by python-marshmallow >= 3.18.0

2023-09-04 Thread Louis-Philippe Véronneau

retitle 1040066 RM: python-marshmallow-enum -- RoM; replaced by python-marshmallow 
>= 3.18.0
reassign 1040066 ftp.debian.org
severity 1040066 normal
thanks


$ ssh po...@mirror.ftp-master.debian.org "dak rm -Rn flask-appbuilder"

Will remove the following packages from unstable:

flask-appbuilder | 4.1.4+ds-3 | source
python-flask-appbuilder-doc | 4.1.4+ds-3 | all
python3-flask-appbuilder | 4.1.4+ds-3 | all

Maintainer: Debian Python Team 

--- Reason ---

--


Checking reverse dependencies...
No dependency problem found.


flask-appbuilder still depends on this package, but:

* it is not in bookworm (removed from testing in 2022-12-16)
* it currently FTBFS from #1036167 and upstream still hasn't got a fix

Since flask-appbuilder is team-maintained, I did try to be a good citizen and 
make it build again.
Although I failed (since upstream still hasn't fixed #1036167), I did update 
the VCS to the latest upstream version
and triaged the BTS! (maybe this will get me some more leniency?? :D)

All in all:

* python-marshmallow-enum not being available anymore won't change anything for 
flask-appbuilder (it'll stay broken)
* the fix for flask-appbuilder with regards to the removal of 
python-marshmallow-enum is trivial and has already been committed in the VCS [1]

As such, please remove python-marshmallow-enum from the archive.


[1]: 
https://salsa.debian.org/python-team/packages/flask-appbuilder/-/commit/ccc94f13af57d72b1335ffb262e793b61d74ffd5

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1036167: flask-appbuilder: Fails to build against python3-flask-sqlalchemy 3.0.3-1

2023-09-04 Thread Louis-Philippe Véronneau

I can confirm this is still the case with upstream version 4.3.6.

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1042923: ITP: ampy -- Utility to interact with a CircuitPython or MicroPython board over a serial connection

2023-08-02 Thread Louis-Philippe Véronneau

Package: wnpp
Severity: wishlist
Owner: Louis-Philippe Véronneau 


Package name: ampy
Version : 1.1.0
URL : https://github.com/scientifichackers/ampy
License : Expat
Programming Lang: Python
Description : Utility to interact with a CircuitPython or MicroPython board 
over a serial connection.

Ampy is meant to be a simple command line tool to manipulate files and run code 
on a CircuitPython or MicroPython board over its serial connection. With ampy 
you can send files from your computer to the board's file system, download 
files from a board to your computer, and even send a Python script to a board 
to be executed.

I'm planning to maintain this package in the Python Team.

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014255: Long lines should also be ignored from non-code text files

2023-08-02 Thread Louis-Philippe Véronneau

On 2023-08-02 15 h 01, Dr. Bas Wijnen wrote:

Hi,

Axel writes that README.md and LICENSE are likely valid cases. I disagree.
While I (and I expect many developers in Debian) are used to using short lines
in text files, this is not that common for other people. Many will use the
automatic word-wrap feature of text editors and write a whole paragraph on a
single line.

I don't think I should ask upstream to reformat their non-code text files; it's
not a good use of their time, and also they would likely not even do it.

Instead, I hope lintian can avoid emitting this tag for non-code text files (in
particular: *.txt, *.html, *.md). Although CMakeLists.txt is probably an
exception: that is code and it shouldn't contain long lines.

I could add overrides, but I don't think this would be an appropriate case for
that. But please let me know if it is.

Thanks,
Bas



Note that the 'very-long-line-length-in-source-file' was marked as 
'experimental' in this commit [1] exactly for that kind of reason.


The default lintian mode doesn't use the 'experimental' tags and I would 
advise you not to include them if this tag is currently bothering you.


[1]: 
https://salsa.debian.org/lintian/lintian/-/commit/899bd1b683c479e166ebd465ff0ad101fbd04ee2


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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1033361: ITP: dunamai -- dynamic versioning library and CLI

2023-07-31 Thread Louis-Philippe Véronneau

Hello,

I need poetry-dynamic-versioning for a new version of a package I 
maintain and I'll be more than happy to review and sponsor your work on 
this.


The first step would be to join the Python Team [1]. Once that is done, 
either email me or ping me on IRC (pollo) :)


[1]: https://deb.li/PyPolicy

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1041809: rst2man: uses non-portable 'C' font, causing warnings from groff >= 1.23.0

2023-07-25 Thread Louis-Philippe Véronneau

Hi,

I've just hit this bug with package supysonic, but the man pages
aren't built by rst2man, but by sphinx:

supysonic: groff-message troff::108: warning: cannot select 
font 'C' [usr/share/man/man1/supysonic-cli-folder.1.gz:2]
supysonic: groff-message troff::96: warning: cannot select font 
'C' [usr/share/man/man1/supysonic-cli-folder.1.gz:1]
supysonic: groff-message troff::120: warning: cannot select 
font 'C' [usr/share/man/man1/supysonic-cli-user.1.gz:1]

AFAIK, sphinx doesn't use rst2man to build man pages.

The issues seems to spawn from code snippets in reStructuredText
(marked by ::), for example:

--
Once you've added a folder, you will need to scan it::

   $ supysonic-cli folder scan MyLibrary
--

sphinx is widely used to generate documentation and man pages, so I fear
this affects more packages than those just using rst2man.

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1040096: python-eventlet: deprecation of Python libraries asyncore and asynchat

2023-07-10 Thread Louis-Philippe Véronneau

On 2023-07-05 07 h 38, Thomas Goirand wrote:

On 7/2/23 03:44, Louis-Philippe Véronneau wrote:

Source: python-eventlet
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: asyncore-asynchat-deprecation

Dear maintainer(s),

In Python 3.6, asyncore and asynchat have been formally marked as 
deprecated. Code that imports these libraries will no longer work from 
Python 3.12, which is currently in Trixie.


Since python-eventlet uses either of these Python libraries, please 
prepare for this removal and migrate away from them.


See this link for more details: 
https://peps.python.org/pep-0594/#deprecated-modules


Hi Louis,

The only place where I can see the use of these libs, is where Eventlet 
is monkey patching that lib. See 
https://github.com/eventlet/eventlet/blob/master/eventlet/green/asyn{core,chat}.py. In such a case, do we still have an issue?


Cheers,

Thomas Goirand (zigo)



I'm not familiar enough with this code, but if the import is called with 
python 3.12, it will fail. I don't know how much this library depends on it.


You can always test it out yourself with python3.12 (currently in trixie 
and sid).


Cheers,

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



Bug#1040349: ipmiutil: postinst script fails when "ipmiutil sel" works but "ipmiutil sensor" fails

2023-07-04 Thread Louis Sautier

Package: ipmiutil
Version: 3.1.8-4

Hi,

In some cases (Intel S2600STB boards), ipmiutil fails to install the 
first time:

Setting up ipmiutil (3.1.8-4) ...
SDR record 61 is malformed, length 12 is less than minimum 12
0061 GetSDR error -25, rlen = 10
dpkg: error processing package ipmiutil (--configure):
 installed ipmiutil package post-installation script subprocess 
returned error exit status 231

Processing triggers for man-db (2.11.2-2) ...
Errors were encountered while processing:
 ipmiutil
E: Sub-process /usr/bin/dpkg returned an error code (1)

The second time around, it works because 
/var/lib/ipmiutil/sensor_out.txt now exists.


The issue can be reproduced by removing /var/lib/ipmiutil/sensor_out.txt 
and running the postinst script again (with -x added here to highlight 
the problem):

# dpkg-reconfigure ipmiutil
+ sbindir=/usr/bin
+ vardir=/var/lib/ipmiutil
+ sensorout=/var/lib/ipmiutil/sensor_out.txt
+ mkdir -p /var/lib/ipmiutil
+ IPMIcmd=true
+ /usr/bin/ipmiutil sel -v
+ true
+ [ ! -f /var/lib/ipmiutil/sensor_out.txt ]
+ /usr/bin/ipmiutil sensor -q
SDR record 61 is malformed, length 12 is less than minimum 12
0061 GetSDR error -25, rlen = 10

The issue here is that "ipmiutil sel" works but "ipmi sensor" does not.
https://jff.email/cgit/ipmiutil.git/tree/debian/postinst?h=debian/3.1.9-1#n16
https://jff.email/cgit/ipmiutil.git/tree/debian/postinst?h=debian/3.1.9-1#n22

The fact that a failing "ipmiutil sensor" command prevents the 
installation is problematic. Would it please be possible to make this 
failure non-fatal?


https://bugs.launchpad.net/ubuntu/+source/ipmiutil/+bug/1786562 seems to 
be the same issue, it concerns the same error message with an Intel 
S2600STB.



PS: maybe there is also an upstream ipmiutil bug to report here? "length 
12 is less than minimum 12" sounds like an off-by-one error.


Kind regards,

Louis



Bug#1033294: lintian: detect and warn about Python 2 related paths within packages

2023-07-03 Thread Louis-Philippe Véronneau

owner 1033294 po...@debian.org
thanks

I'm currently working on a fix for this (the patch is in fact ready, but 
I'm trying to clean some old python2 code in the same MR).


Cheers and thanks for reporting,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1040069: flask-appbuilder: please stop depending on python-marshmallow-enum

2023-07-01 Thread Louis-Philippe Véronneau

Source: flask-appbuilder
Severity: normal
Version: 4.1.4+ds-3

Dear maintainers,

I maintain the python-marshmallow-enum package. Since it has been 
deprecated upstream [1] (marshmallow 3.18.0 added Enum support), I'm 
planning on removing it from the archive as soon as possible.


Since this package currently depends and build-depends on 
python3-marshmallow-enum, it would be nice if you could move away from it.


This has been fixed upstream [2] in the 4.3.3 release and packaging it 
would fix this issue.


Cheers,

[1]: https://github.com/justanr/marshmallow_enum/issues/51
[2]: 
https://github.com/dpgaspar/Flask-AppBuilder/blob/master/CHANGELOG.rst#improvements-and-bug-fixes-on-433


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1040068: python-marshmallow-dataclass: please stop build-depending on python-marshmallow-enum

2023-07-01 Thread Louis-Philippe Véronneau

Source: python-marshmallow-dataclass
Severity: normal
Version: 8.5.10-1

Dear maintainers,

I maintain the python-marshmallow-enum package. Since it has been 
deprecated upstream [1] (marshmallow 3.18.0 added Enum support), I'm 
planning on removing it from the archive as soon as possible.


Since this package currently build-depends on python3-marshmallow-enum, 
it would be nice if you could move away from it.


This has been fixed upstream [2] in the 8.5.11 release and packaging it 
would fix this issue,


Cheers,

[1]: https://github.com/justanr/marshmallow_enum/issues/51
[2]: 
https://github.com/lovasoa/marshmallow_dataclass/blob/master/CHANGELOG.md#v8511-2023-01-08


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1040067: dataclasses-json: please stop depending on python-marshmallow-enum

2023-07-01 Thread Louis-Philippe Véronneau

Source: dataclasses-json
Severity: normal
Version: 0.5.9-1
Forwarded: https://github.com/lidatong/dataclasses-json/pull/384
Owner: po...@debian.org

I maintain the python-marshmallow-enum package. Since it has been 
deprecated upstream [1] (marshmallow 3.18.0 added Enum support), I'm 
planning on removing it from the archive as soon as possible.


Since this package currently depends and build-depends on 
python3-marshmallow-enum, it would be nice if you could move away from it.


This has been fixed upstream [2], but I'm waiting on a new release to 
package this fix in Debian.


[1]: https://github.com/justanr/marshmallow_enum/issues/51
[2]: https://github.com/lidatong/dataclasses-json/pull/384

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1040066: python-marshmallow-enum: Intent to remove from the archive

2023-07-01 Thread Louis-Philippe Véronneau

Source: python-marshmallow-enum
Severity: serious
Owner: po...@debian.org
X-Debbugs-CC: debian-pyt...@lists.debian.org

I maintain the python-marshmallow-enum package. Since it has been 
deprecated upstream [1] (marshmallow 3.18.0 added Enum support), I'm 
planning on removing it from the archive as soon as possible.


This bug should be enough to have python3-marshmallow-enum be removed 
from testing in the meantime and will help me link the bugs blocking the RM.


Once those are closed, I'll turn this bug into a formal RM request.

Cheers,

[1]: https://github.com/justanr/marshmallow_enum/issues/51

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1038818: grub-pc: Empty device (??? MB) in list during postinst with ZFS on / or /boot

2023-06-21 Thread Louis Sautier

Package: grub-pc
Version: 2.06-13

Hi,
When ZFS is used for the / or /boot partitions on legacy boot servers 
(with vdevs using more than one disk/partition), grub-pc's postinst 
shows this during the configure phase:


    ┌──┤ Configuring grub-pc ├──┐
    │ GRUB install devices: │
    │   │
    │  [*] /dev/sda (240057 MB; SAMSUNG_MZ7LM240HMHQ-5) │
    │  [*] /dev/sdb (240057 MB; SAMSUNG_MZ7LM240HMHQ-5) │
    │  [ ] (??? MB; ???)    │
    │  [ ] /dev/md2 (1071 MB; md2)  │
    │   │
    │   │
    │  │
    │   │
    └───┘

Along with errors:

Unknown device "/dev/": No such device


To reproduce, on a legacy boot server:
* Create a zpool with a mirror vdev using two partitions.
* Create a dataset and use it as /.
* Install Debian Bookworm on the server.
* Run "dpkg-reconfigure grub-pc".

On my test server:
root@localhost:~# df -hT
Filesystem Type  Size  Used Avail Use% Mounted on
udev   devtmpfs  7.8G 0  7.8G   0% /dev
tmpfs  tmpfs 1.6G  820K  1.6G   1% /run
zp0/zd0    zfs   216G  1.5G  214G   1% /
tmpfs  tmpfs 7.8G 0  7.8G   0% /dev/shm
tmpfs  tmpfs 5.0M 0  5.0M   0% /run/lock
/dev/md2   ext4  988M   66M  855M   8% /boot
tmpfs  tmpfs 1.6G 0  1.6G   0% /run/user/1000
root@localhost:~# lsblk -f
NAME    FSTYPE    FSVER    LABEL 
UUID FSAVAIL FSUSE% MOUNTPOINTS

sda
├─sda1
├─sda2  linux_raid_member 1.2  md2 
371c03a8-59c4-5eb7-7fda-f6f5497ae463
│ └─md2 ext4  1.0  boot 
197e5606-e75e-4809-87f9-13fbc42ed36d  854.7M 7% /boot

├─sda3  zfs_member    5000 zp0 8324519610909055574
├─sda4  swap  1    swap-sda4 
08d6106d-f50d-4391-8515-5b2b8ffa1d6b    [SWAP]

└─sda5  iso9660   Joliet Extension config-2 2023-06-16-18-40-55-00
sdb
├─sdb1
├─sdb2  linux_raid_member 1.2  md2 
371c03a8-59c4-5eb7-7fda-f6f5497ae463
│ └─md2 ext4  1.0  boot 
197e5606-e75e-4809-87f9-13fbc42ed36d  854.7M 7% /boot

├─sdb3  zfs_member    5000 zp0 8324519610909055574
└─sdb4  swap  1    swap-sdb4 
55b30849-9949-4da0-9738-43e04b40a220    [SWAP]

root@localhost:~# zfs list
NAME  USED  AVAIL REFER  MOUNTPOINT
zp0  1.42G   214G   24K  none
zp0/zd0  1.42G   214G 1.42G  /
root@localhost:~# zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP DEDUP    
HEALTH  ALTROOT
zp0    222G  1.42G   221G    - - 0% 0% 1.00x    
ONLINE  -

root@localhost:~# zpool status
  pool: zp0
 state: ONLINE
config:

    NAME    STATE READ WRITE CKSUM
    zp0 ONLINE   0 0 0
  mirror-0  ONLINE   0 0 0
    sda3    ONLINE   0 0 0
    sdb3    ONLINE   0 0 0

errors: No known data errors
root@localhost:~# cat /etc/fstab
UUID=197e5606-e75e-4809-87f9-13fbc42ed36d    /boot    ext4  defaults   
 0    0
UUID=08d6106d-f50d-4391-8515-5b2b8ffa1d6b    swap    swap  defaults   
 0    0
UUID=55b30849-9949-4da0-9738-43e04b40a220    swap    swap  defaults   
 0    0

root@localhost:~# dpkg-reconfigure grub-pc
# With set -x / set +x added around line 281 of 
/var/lib/dpkg/info/grub-pc.postinst

+++ grub-probe -t device /
++ partition='/dev/sda3
/dev/sdb3'
++ set +x
+++ grub-probe -t device /boot
++ partition=/dev/md2
++ set +x
+++ grub-probe -t device /boot/grub
++ partition=/dev/md2
++ set +x
Unknown device "/dev/": No such device
Unknown device "/dev/": No such device
Unknown device "/dev/": No such device
Unknown device "/dev/": No such device
grub-pc: Running grub-install ...
Installing for i386-pc platform.

Installation finished. No error reported.
  grub-install success for /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
  grub-install success for /dev/sdb
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-9-amd64
Found initrd image: /boot/initrd.img-6.1.0-9-amd64
done

My understanding is that the following happens:

* usable_partitions is called: 
https://salsa.debian.org/grub-team/grub/-/blob/debian/2.06-13/debian/postinst.in#L275
* partition="$(grub-probe -t device "$path" || true)" is called: 
https://salsa.debian.org/grub-team/grub/-/blob/debian/2.06-13/debian/postinst.in#L281

* It returns this:
  # grub-probe -t device /
  /dev/sda3
  /dev/sdb3
* partition_id="$(device_to_id "$partition" || true)" 

Bug#1038272: gnupg: connecting both a regular smartcard and a solokey v2 drastically increases gpg's response time

2023-06-17 Thread Louis-Philippe Véronneau

retitle 1038272 gnupg crashes the solokey v2
thanks

Debugging further, it seems there's no need to have both tokens connected,
only having the solokey v2 will suffice.

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



Bug#1038272: gnupg: connecting both a regular smartcard and a solokey v2 drastically increases gpg's response time

2023-06-16 Thread Louis-Philippe Véronneau
Even worse, it seems using gpg with both tokens connected crashes the 
solokey v2, which then becomes unresponsive to touch and CLI commands.


:(

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1038272: gnupg: connecting both a regular smartcard and a solokey v2 drastically increases gpg's response time

2023-06-16 Thread Louis-Philippe Véronneau

Package: gnupg
Version: 2.2.40-1.1
Severity: normal

Dear maintainers,

I recently purchased a Solokey v2, which does not support OpenPGP (but 
does support PIV).


Although this is the case, when both my regular smartcard (a nitrokey 
start) and the Solokey v2 are plugged in, gpg seems to get "confused" 
and takes a while to answer back (almost as if it took multiple seconds 
to recognise the solokey v2 isn't supported).


This is "Not Very Nice" as it drastically increases the time it takes to 
sign git commits when both keys are plugged in :(


With both keys plugged in (my password is cached):

--
foo@bar:/tmp$ time gpg --sign testfile.txt

real0m21,632s
user0m0,006s
sys 0m0,003s
--

With only the smartcard plugged in:

--
foo@bar:/tmp$ time gpg --sign testfile.txt

real0m0,053s
user0m0,003s
sys 0m0,004s
--

The same thing happens when I try to run `gpg --edit-card`, or when 
Thunderbird (which I configured to use gpg) tries to sign an email.


I understand this behavior could be difficult to reproduce on your side, 
since the Solokey v2 isn't publicly available yet (it's in the last 
crowdfunding fulfillment steps).


Since I'm not very familiar with debugging GPG, I haven't included any 
relevant info, but I'll be glad to run whatever commands you need me to 
on my side.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1036947: whipper: Whipper does not work when syncthing-gtk is also installed

2023-05-30 Thread Louis-Philippe Véronneau

reassign 1036947 syncthing-gtk
retitle 1036947 syncthing-gtk: Invalid version number breaks other packages
affects 1036947 whipper
severity 1036947 critical
tags 1036947 + patch
thanks

Thanks for reporting this bug. I can indeed reproduce the failure with whipper 
when syncthing-gtk is installed, with pretty much any whipper command.

As kindly mentioned by Nicolas Dandrimont on IRC, this seems to be a bug with 
syncthing-gtk itself, and not directly with whipper. As such, I'm reassigning this bug to 
syncthing-gtk and I've changed the severity to critical ("makes unrelated software 
on the system break").

The current syncthing-gtk version is not valid, as it doesn't respect PEP-440. 
Only ASCII letters ([a-zA-Z]), ASCII digits ([0-9]) and periods (.) are allowed 
after the initial + and this is what ends up crashing whipper (and maybe other 
packages?).

I tried rebuilding the package with version 
0.9.4.4+ds.git20221205.12a9702d29ab-1 (replacing the last 2 + by dots) and it 
does fix the issue, but it sounds like the wrong way to fix the issue.

I am not very familiar with syncthing-gtk's code, but it seems the issue spawns 
from the get_version() function in setup.py, which uses git tags to find the 
proper version.

Hardcoding a suitable version (say 0.9.4.4) in that file instead of using 
version=get_version() works too, but also sounds like the wrong solution, at 
least in the long term. For the sake of the upcoming release (and making sure 
whipper isn't broken randomly by syncthing-gtk), I'd say it is the simplest 
solution. I've thus attached a patch, and I encourage the maintainers to apply 
it and ask for an unblocking request post-haste.

Cheers,

[1]:  https://peps.python.org/pep-0440/

--
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
   ⠈⠳⣄Description: This hotfix patch fixes a problem with syncthing-gtk's current
 Debian version not respecting PEP-440 and thus crashing other packages. By
 bypassing the get_version() function altogether, the version used by the
 package doesn't include the git hash.
 This patch should probably be revisited after the release of Debian Bookworm
 to find long-term solution.
Forwarded: not-needed
Bug-Debian: http://bugs.debian.org/1036947
Author: Louis-Philippe Véronneau 
Index: syncthing-gtk/setup.py
===
--- syncthing-gtk.orig/setup.py
+++ syncthing-gtk/setup.py
@@ -119,7 +119,7 @@ if __name__ == "__main__":
 ]
 setup(
 name='syncthing-gtk',
-version=get_version(),
+version='0.9.4.4',
 description='GTK3 GUI for Syncthing',
 url='https://github.com/syncthing/syncthing-gtk',
 packages=['syncthing_gtk'],


Bug#1036054: pixelart does not work

2023-05-14 Thread Louis
Package: texlive-pictures
Version: 2022.20230122-3
Severity: normal

Dear Maintainer,
texlive-pictures includes pixelart v1.0.0, which does not work (see
below). It has two bugs, that have been fixed in version v1.0.2
(available on CTAN https://ctan.org/pkg/pixelart).

Thanks for your work,
Louis Paternault (author of pixelart)

##
Example file: mwe.tex

> \documentclass{article}
>
> \usepackage{pixelart}
>
> \begin{document}
> Hello, world!
> \end{document}

Document should compile flawlessly with LuaLaTeX (the resulting document
should be the same as the one produced by the exact same file, without
the line \usepackage{pixelart}). Instead, compilation fails.

> $ lualatex mwe.tex
> This is LuaHBTeX, Version 1.15.0 (TeX Live 2022/Debian) 
> […]
> (/usr/share/texlive/texmf-dist/tex/latex/pixelart/pixelart.sty
> […]
> (/usr/share/texlive/texmf-dist/tex/generic/pgf/libraries/pgflibrarypatterns.cod
> e.tex))cannot open pixelart.lua: No such file or directory
> stack traceback:
>   [C]: in function 'dofile'
>   [\directlua]:1: in main chunk.
> \luadirect ... { \luacode@maybe@printdbg {#1} #1 }
>   
> l.15 \luadirect{dofile("pixelart.lua")}
>  
> ? Type  to proceed, S to scroll future error messages,
> R to run without stopping, Q to run quietly,
> I to insert something, E to edit your file,
> 1 or ... or 9 to ignore the next 1 to 9 tokens of input,
> H for help, X to quit.
> ? 
> ! Emergency stop.
> \luadirect ... { \luacode@maybe@printdbg {#1} #1 }
>   
> l.15 \luadirect{dofile("pixelart.lua")}
>  
>  385 words of node memory still in use:
>2 hlist, 1 rule, 1 dir, 3 kern, 1 glyph, 4 attribute, 48 glue_spec, 4 
> attrib
> ute_list, 1 if_stack, 1 write, 1 pdf_colorstack nodes
>avail lists: 2:20,3:2,5:5,7:2,9:3
> !  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on mwe.log.


##
mwe.fls

PWD /home/louis/tmp
INPUT /var/lib/texmf/web2c/luahbtex/lualatex.fmt
INPUT ./mwe.tex
OUTPUT mwe.log
INPUT 
/usr/share/texlive/texmf-dist/tex/latex/latexconfig/lualatexquotejobname.lua
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ltluatex.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-main.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-init.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-basic.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-basic-merged.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-compat.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-extended.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/lualibs/lualibs-extended-merged.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-log.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-basics-gen.lua
OUTPUT /home/louis/.texlive2022/texmf-var/m_t_x_t_e_s_t.tmp
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-parsers.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-configuration.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-status.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-2022-10-03.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-fallback.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-multiscript.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-scripts.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/generic/unicode-data/ScriptExtensions.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/Scripts.txt
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-loaders.lua
INPUT 
/usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-unicode.lua
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/UnicodeData.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/UnicodeData.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/PropList.txt
INPUT 
/usr/share/texlive/texmf-dist/tex/generic/unicode-data/WordBreakProperty.txt
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/SpecialCasing.txt
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lua-uni-algos/lua-uni-case.lua
INPUT /usr/share/texlive/texmf-dist/tex/luatex/lua-uni-algos/lua-uni-parse.lua
INPUT /usr/share/texlive/texmf-dist/tex/generic/unicode-data/CaseFolding.tx

Bug#1034061: ponyorm: please update the python 3.11 patch to include latest fix.

2023-04-07 Thread Louis-Philippe Véronneau

Package: src:ponyorm

Timo Röhling has updated the 3.11 PR with a new commit fixing a bug:

https://github.com/ponyorm/pony/pull/671/commits/3ac71610c0c304c3200a2c583e94d3e93fe3889e

This should probably be included in the version that's going to end up 
in Bookworm.


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


Bug#1032864: RFP: labwc -- Labwc is a wlroots-based window-stacking compositor for wayland, inspired by openbox.

2023-03-12 Thread Louis-Philippe Véronneau

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: po...@debian.org

* Package name: labwc
  Version : 0.6.1
  Upstream Contact: Johan Malm 
* URL : https://github.com/labwc/labwc
* License : GPLv2
  Programming Lang: C
  Description : Labwc is a wlroots-based window-stacking compositor for 
wayland, inspired by openbox.

Labwc is a wlroots-based window-stacking compositor for wayland, inspired by 
openbox.

It is light-weight and independent with a focus on simply stacking windows well 
and rendering
some window decorations. It takes a no-bling/frills approach and says no to 
features such as
icons (except window buttons), animations, decorative gradients and any other 
options not
required to reasonably render common themes. It relies on clients for panels, 
screenshots,
 wallpapers and so on to create a full desktop environment.

Labwc tries to stay in keeping with wlroots and sway in terms of general 
approach and coding
style.

Labwc has no reliance on any particular Desktop Environment, Desktop Shell or 
session. Nor
does it depend on any UI toolkits such as Qt or GTK.



I have not looked into this very much, but as far as I understand, all the 
necessary
dependencies seem to already be packaged in Debian:

https://github.com/labwc/labwc/wiki#debian

I'm not against the idea of packaging this myself, but I'm not a C coder and I 
already maintain
a bunch of things in Debian. I'd be more than happy to see someone else that I 
maintain labwc :)

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


Bug#1028743: python-bottle: diff for NMU version 0.12.23-1.1

2023-02-26 Thread Louis-Philippe Véronneau

Control: tags 1028743 + pending


Dear maintainer,

I've prepared an NMU for python-bottle (versioned as 0.12.23-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

I've attached the debdiff to this message, but I've also opened a MR on 
Salsa, if you prefer to merge this.


https://salsa.debian.org/debian/python-bottle/-/merge_requests/1

Regards.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄diff -Nru python-bottle-0.12.23/debian/changelog 
python-bottle-0.12.23/debian/changelog
--- python-bottle-0.12.23/debian/changelog  2022-09-17 06:37:25.0 
-0400
+++ python-bottle-0.12.23/debian/changelog  2023-02-26 15:59:44.0 
-0500
@@ -1,3 +1,13 @@
+python-bottle (0.12.23-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ James Addison ]
+  * d/patches: add 0004 to disable the local proxy for the tests. (Closes:
+#1028743)
+
+ -- Louis-Philippe Véronneau   Sun, 26 Feb 2023 15:59:44 
-0500
+
 python-bottle (0.12.23-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch 
python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch
--- python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch  
1969-12-31 19:00:00.0 -0500
+++ python-bottle-0.12.23/debian/patches/0004-Localhost-request-no-proxy.patch  
2023-02-26 15:59:44.0 -0500
@@ -0,0 +1,30 @@
+Description: Fix the test_server 'fetch' method to disable proxying within
+ tests cases where it is used. This resolve the connection refused errors due 
to
+ the HTTP proxy enabled by default during autopkgtests.
+Author: James Addison 
+--- a/test/test_server.py
 b/test/test_server.py
+@@ -11,9 +11,9 @@
+ from bottle import _e
+ 
+ try:
+-from urllib.request import urlopen
++from urllib.request import ProxyHandler, build_opener
+ except:
+-from urllib2 import urlopen
++from urllib2 import ProxyHandler, build_opener
+ 
+ serverscript = os.path.join(os.path.dirname(__file__), 'servertest.py')
+ 
+@@ -77,8 +77,10 @@
+ raise AssertionError(line.strip().decode('utf8'))
+ 
+ def fetch(self, url):
++proxy_handler = ProxyHandler(proxies={})
++url_opener = build_opener(proxy_handler)
+ try:
+-return urlopen('http://127.0.0.1:%d/%s' % (self.port, url)).read()
++return url_opener.open('http://127.0.0.1:%d/%s' % (self.port, 
url)).read()
+ except Exception:
+ return repr(_e())
+ 
diff -Nru python-bottle-0.12.23/debian/patches/series 
python-bottle-0.12.23/debian/patches/series
--- python-bottle-0.12.23/debian/patches/series 2022-09-17 06:37:25.0 
-0400
+++ python-bottle-0.12.23/debian/patches/series 2023-02-26 15:50:45.0 
-0500
@@ -1,3 +1,4 @@
 0001-Remove-bottle.py-from-scripts.patch
 0002-Add-CLI-manpage.patch
 0003-Disable-failing-tests.patch
+0004-Localhost-request-no-proxy.patch


Bug#1031880: Downgrade u-u bug

2023-02-26 Thread Louis-Philippe Véronneau
user debian-rele...@lists.debian.org 


usertag 1031880 + bsp-2023-02-ca-montreal
severity 1031880 normal
thank you

Hi,

Although this seems like a real bug, I feel like the conditions to 
reproduce it are very specific and do not justify the current severity.


As such, I'm downgrading it to severity: normal.

Cheers,

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



Bug#1019273: apt: diff for NMU version 2.5.6+nmu1

2023-02-26 Thread Louis-Philippe Véronneau

Control: tags 1019273 + pending

Dear maintainer,

I've prepared an NMU for apt (versioned as 2.5.6+nmu1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Attached is the actual debdiff.

Regards.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄diff -Nru apt-2.5.6/COPYING apt-2.5.6+nmu1/COPYING
--- apt-2.5.6/COPYING   2023-02-08 11:07:38.0 -0500
+++ apt-2.5.6+nmu1/COPYING  2023-02-26 13:17:23.0 -0500
@@ -1,22 +1,174 @@
-Apt is copyright 1997, 1998, 1999 Jason Gunthorpe and others.
-Apt is currently developed by APT Development Team .
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: apt
+Upstream-Contact: APT Development Team 
+Source: https://salsa.debian.org/apt-team/apt
 
-License: GPLv2+
+Files: *
+Copyright: 1997-1999 Jason Gunthorpe and others
+License: GPL-2+
 
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
-
-See /usr/share/common-licenses/GPL-2, or
-<http://www.gnu.org/copyleft/gpl.txt> for the terms of the latest version
-of the GNU General Public License.
+Files: apt-pkg/cachefilter-patterns.*
+   apt-private/private-json-hooks.*
+   test/libapt/pattern_test.cc
+Copyright: 2018, 2019 Canonical Ltd
+License: GPL-2+
+
+Files: po/lt.po
+Copyright: 2006 Canonical Ltd, and Rosetta Contributors 2006
+License: GPL-2+
+
+Files: apt-pkg/contrib/weakptr.h
+   apt-pkg/contrib/string_view.h
+   CMakeLists.txt
+Copyright: 2009, 2010, 2015, 2016 Julian Andres Klode 
+License: GPL-2+
+
+Files: debian/apt.postrm
+Copyright: 1998, Ben Gertzfield 
+License: GPL-2+
+
+Files: doc/po/pt.po
+   po/bg.po
+   po/it.po
+   po/sv.po
+   po/th.po
+Copyright: 2002-2019 Free Software Foundation, Inc.
+License: GPL-2+
+
+Files: doc/po/es.po
+   po/tl.po
+Copyright: 2003, 2004, 2005, 2009, 2010, 2012 Software in the Public Interest
+License: GPL-2+
+
+Files: po/nb.po
+Copyright: 2002-2003 Lars Bahner 
+   2003-2004 Axel Bojer 
+   2004 Klaus Ade Johnstad 
+   2004 Bjorn Steensrud 
+   2003, 2005-2010 Hans Fredrik Nordhaug 
+   2016, 2018 Petter Reinholdtsen 
+License: GPL-2
+
+Files: po/tr.po
+Copyright: 2009 Rosetta Contributors and Canonical Ltd 2009
+   2013 Debian L10n Turkish 2013
+   2013-2018 Mert Dirik 
+License: GPL-2+
+
+Files: doc/po/pl.po
+Copyright: 2004 Krzysztof Fiertek 
+   2000-2004, 2010, 2012  Robert Luberda 
+License: GPL-2+
+
+Files: doc/po/it.po
+Copyright: 2000-2017 Debian Italian l10n team 

+License: GPL-2+
+
+Files: doc/po/ja.po
+Copyright: 2003-2017 Debian Japanese List 
+License: GPL-2+
+
+Files: doc/po/fr.po
+Copyright: 2000-2018 Debian French l10n team 

+License: GPL-2+
+
+Files: doc/design.dbk
+Copyright: 1997 Manoj Srivastava
+License: GPL-2+
+
+Files: doc/dpkg-tech.dbk
+Copyright: 1997 Tom Lees
+License: GPL-2+
+
+Files: methods/rred.cc
+Copyright: 2014 Anthony Towns
+License: GPL-2+
+
+Files: methods/rsh.cc
+Copyright: 2000 Ben Collins 
+License: GPL-2
+
+Files: CMake/FindBerkeley.cmake
+Copyright: 2006, Alexander Dymo, 
+   2016, Julian Andres Klode 
+License: BSD-3-clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ .
+ 1. Redistributions of source code must retain the copyright
+notice, this list of conditions and the following disclaimer.
+ 2. Redistributions in binary form must reproduce the copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+ 3. The name of the author may not be used to endorse or promote products
+derived from this software without specific prior written permission.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR P

Bug#1019273: package built and lintian passed

2023-02-26 Thread Louis-Philippe Véronneau
I've had a look at this, and I'm planning on making an NMU to patch this 
package's copyright file with the proposed patch today.


Although this is an RC bug and has been open for a while, I'll make it 
DELAYED 5, so if the maintainers disagree for some reason, they should 
have plenty of time to cancel the upload.


I'll make a Merge Request on Salsa to make sure the git repo is up to 
date with the archive.


Cheers,

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



Bug#1031966: python-pydata-sphinx-theme-doc is empty

2023-02-26 Thread Louis-Philippe Véronneau

block 1031966 by 896460
user debian-rele...@lists.debian.org 


usertag 1031966 + bsp-2023-02-ca-montreal
thanks

It seems this is the result of the doc not being built in Debian, since 
it requires ipywidgets 7 and we have version 6.


The fix for this is probably to stop building 
python-pydata-sphinx-theme-doc altogether, but I'll let Sandro have a go 
at this :)


Cheers,

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



Bug#1032013: terminator retitle bugs

2023-02-26 Thread Louis-Philippe Véronneau

retitle 901245 terminator: x-terminal-emulator -c stumbles upon shell oneliner
severity 901245 normal
found 901245 2.1.2-1
retitle 1032013 terminator: --execute flag is broken
thanks

I've split this bug in two, since it's actually two different bugs.

The original bug about "-c " is different from the one John reported about
the --execute flag being broken.

I'll upload a patch for 1032013 today, but I won't be fixing the original bug.
In my opinion, it's not as severe as 1032013, as it's not a policy violation.

Cheers,

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



Bug#901245: Handling of -e violates policy for x-terminal-emulator

2023-02-25 Thread Louis-Philippe Véronneau

Ok, so pushing further.

-e does seem to work fine with terminator 2.1.2-1. At least, these 
commands works fine:


x-terminal-emulator -e 'if test -x /bin/ss ; then watch -t ss -putsw; 
else netstat -c; fi'


x-terminal-emulator -e 'watch /'

Adding "sh -c" fails though:


$ x-terminal-emulator -e bash -c 'watch /'

(x-terminal-emulator:98199): dbind-WARNING **: 14:48:34.964: AT-SPI: 
Error retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files


usage: x-terminal-emulator [-h] [-v] [-m] [-M] [-f] [-b] [-H] [-T 
FORCEDTITLE]

   [--geometry GEOMETRY] [--command COMMAND]
   [-e EXECUTE] [-g CONFIG] [-j CONFIGJSON]
   [-x EXECUTE] [--working-directory DIR]
   [-i FORCEDICON] [-r ROLE] [-l LAYOUT] [-s]
   [-p PROFILE] [-u] [-d]
   [--debug-classes DEBUG_CLASSES]
   [--debug-methods DEBUG_METHODS] [--new-tab]
   [--unhide] [--list-profiles] [--list-layouts]


This error does seem to be caused by the issue John pointed out.

Applying the upstream patch, calling this command doesn't error out 
anymore, but now replicates the "the window comes up and disappears 
immediately." issue:


x-terminal-emulator -e bash -c 'watch /'

This command still works fine though:

x-terminal-emulator -e 'watch /'

All this to say, I'm not sure this bug is serious? It seems the -e 
option does work?


I'll try to see what to do with this bug tomorrow.

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



Bug#901245: Handling of -e violates policy for x-terminal-emulator

2023-02-25 Thread Louis-Philippe Véronneau
user debian-rele...@lists.debian.org 


usertag 901245 + bsp-2023-02-ca-montreal
thank you

Thanks for the excellent debugging session :)

I've tried to apply the patch [1] but it does not seem to fix the bug 
itself.


I'll try to dig further during the Montreal BSP.

Cheers,

[1]: 
https://github.com/gnome-terminator/terminator/commit/91cc928f0de1f9d6d51136cf50f06c35b5faca62.patch


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



Bug#1030848: qpdview FTCBFS: uses the build architecture pkg-config

2023-02-25 Thread Louis-Philippe Véronneau
user debian-rele...@lists.debian.org 


usertag 1030848 + bsp-2023-02-ca-montreal
thank you

Thanks for the patch, and sorry for deleting the old one.

I saw that upstream did indeed fix the version problem it was fixing and 
didn't understand the PKG_CONFIG part was also important for 
cross-compiling.


I'll update a new version with the fix in the next few minutes.

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



Bug#1031478: nrepl-clojure: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

2023-02-20 Thread Louis-Philippe Véronneau

tags 1031478 moreinfo unreproducible
thanks

Hi!

Thanks for the rebuild. I can't reproduce this issue on my machine, but 
I see that neither DebCI (which runs the same exact testsuite, as an 
autopkgtest) nor Reproducible builds [2] (which just rebuilds the 
package) have had issues with this...


The Clojure ecosystem in Debian still isn't the most stable one, and we 
changed a bunch of stuff right before the freeze... Could you give this 
another go and see if you still get a failure?


Cheers,

[1]: https://ci.debian.net/packages/n/nrepl-clojure/

[2]: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nrepl-clojure.html


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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1030737: ruby: please include 'gem' in the DEBIAN_RUBY_PROGRAMS env var when building

2023-02-06 Thread Louis-Philippe Véronneau

Source: ruby
Version: 1:3.1

Dear maintainers,

While looking for the `gem` manpage, I found out there is no symlink 
from /usr/share/man/man1/gem.1.gz to /usr/share/man/man1/gem3.1.1.gz, as 
is done for the other cli commands installed by this package.


This is pretty inconvenient and it took me a good minute to understand I 
needed to type `man gem3.1` to get the actual man page.


It seems this spawns from DEBIAN_RUBY_PROGRAMS in your d/rules file not 
including the `gem` command. Adding it would create a new symlink and 
solve the problem I was having.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1026514: python-param: FTBFS: TypeError: The only supported seed types are: None,

2023-02-03 Thread Louis-Philippe Véronneau

On 2023-02-03 11 h 58, FC Stegerman wrote:
> Presumably there is a way to get the version from e.g.
> "dpkg-parsechangelog -S Version" (minus the -1 revision) instead.  I'm
> not sure how other packages handle this.

You can get those values via the variables provided by 
/usr/share/dpkg/pkg-info.mk


You can "source" those in your d/rules makefile by using:

include /usr/share/dpkg/pkg-info.mk

NB: Sorry if people get this twice, I forgot to email the BTS the first 
time around ...


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



Bug#1030278: puppetserver: please patch the output of "puppetserver ca --help" to refer to the path Debian uses

2023-02-01 Thread Louis-Philippe Véronneau

Package: puppetserver
Severity: wishlist
Version: 7.9.4-1

Dear maintainers,

When running "puppetserver ca --help", the help message includes the 
following line:


migrate Migrate the existing CA directory to /etc/puppetserver/ca

We are not using the `/etc/puppetserver` path in Debian, and instead 
chose to use `/etc/puppet/puppetserver`.


This should be patched not to confuse people.

Cheers,

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



Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'

2023-01-31 Thread Louis-Philippe Véronneau

On 2023-01-31 05 h 02, Bernhard Übelacker wrote:


On Wed, 11 Jan 2023 15:20:22 -0500 
=?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=  wrote:

On 2023-01-11 01 h 26, Birger Schacht wrote:


> The crash message ("Failed to show notification") sounds to me as if 
> there is maybe no notification daemon running?


Here are the packages reportbug lists. I don't run GNOME or KDE, but a 
custom openbox DE, so maybe something is indeed missing and should be 
added in the packages' dependencies?




Hello,
could that be a dependency to "notification-daemon"?
Following link shows a list of other packages that
are providing "notification-daemon" too.

https://packages.debian.org/sid/notification-daemon

Kind regards,
Bernhard


No, this package is also installed on my system:

$ dpkg -l |grep notification-daemon
ii  notification-daemon 3.20.0-4+b1

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



Bug#1029274: RM: useful-clojure --- ROM; RC-buggy; not actually useful

2023-01-20 Thread Louis-Philippe Véronneau

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: po...@debian.org debian-cloj...@lists.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP masters,

Please RM the useful-clojure source package.

It's somewhat dead upstream (no support for modern Java, no release 
since 2018), it's currently RC-buggy (#1029246) and it's not actually 
used in Debian.


I initially packaged it as a dependency for a Clojure tool, but never 
ended up using it as the tool in question moved away from it. All this 
to say it's not actually useful anymore :P


===
$ ssh po...@mirror.ftp-master.debian.org "dak rm -Rn useful-clojure""
Will remove the following packages from unstable:

libuseful-clojure |   0.11.6-4 | all
useful-clojure |   0.11.6-4 | source

Maintainer: Debian Clojure Maintainers 



--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

===

Cheers,

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



Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'

2023-01-11 Thread Louis-Philippe Véronneau

On 2023-01-11 01 h 26, Birger Schacht wrote:

Hi,

I can not reproduce this behavior. I started usbguard-notifier and 
removed my yubikey and replugged it:


 >  ~ usbguard-notifier --debug
 > Connection has been established
 > LOG: src/Notifier.cpp::114 [DevicePresenceChanged] Device presence 
changed signal
 > LOG: src/Notifier.cpp::114 [DevicePresenceChanged] Device presence 
changed signal
 > LOG: src/Notifier.cpp::73 [DevicePolicyChanged] Device policy changed 
signal


The crash message ("Failed to show notification") sounds to me as if 
there is maybe no notification daemon running?


cheers,
Birger


Here are the packages reportbug lists. I don't run GNOME or KDE, but a 
custom openbox DE, so maybe something is indeed missing and should be 
added in the packages' dependencies?


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8

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

Versions of packages usbguard-notifier depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.4-1
ii  libnotify4   0.8.1-1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libstdc++6   12.2.0-14
ii  libusbguard1 1.1.2+ds-3+b1

usbguard-notifier recommends no packages.

usbguard-notifier suggests no packages.

-- no debconf information



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



Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'

2023-01-09 Thread Louis-Philippe Véronneau

Package: usbguard-notifier
Version: 0.1.0-1
Severity: important

Dear maintainer,

When running usbguard-notifier, either via the systemd service file, or 
on the CLI with --debug, when a new event happens, the program crashes with:


LOG: src/Notifier.cpp::114 [DevicePresenceChanged] Device presence 
changed signal

terminate called after throwing an instance of 'std::runtime_error'
  what():  Failed to show notification
Aborted

This makes it impossible to use the program :(

Happy to provide more detailed info if needed.

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



Bug#1028334: Acknowledgement (puppetserver: install default configuration files)

2023-01-09 Thread Louis-Philippe Véronneau

Note this is the postinstall scrip upstream uses:

"install --owner={{user}} --group={{user}} -d 
/opt/puppetlabs/server/data/puppetserver/jruby-gems",
"/opt/puppetlabs/puppet/bin/puppet config set --section master vardir  
/opt/puppetlabs/server/data/puppetserver",
"/opt/puppetlabs/puppet/bin/puppet config set --section master logdir  
/var/log/puppetlabs/puppetserver",
 "/opt/puppetlabs/puppet/bin/puppet config set --section master rundir  
/var/run/puppetlabs/puppetserver",
"/opt/puppetlabs/puppet/bin/puppet config set --section master pidfile 
/var/run/puppetlabs/puppetserver/puppetserver.pid",
"/opt/puppetlabs/puppet/bin/puppet config set --section master codedir 
/etc/puppetlabs/code",
"usermod --home /opt/puppetlabs/server/data/puppetserver puppet",
"install --directory --owner=puppet --group=puppet --mode=775 
/opt/puppetlabs/server/data",
"install --directory /etc/puppetlabs/puppet/ssl",
"chown -R puppet:puppet /etc/puppetlabs/puppet/ssl",
"find /etc/puppetlabs/puppet/ssl -type d -print0 | xargs -0 chmod 770"


A lot of these kind of files should probably be copied from the old 
puppet-master package.

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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028334: puppetserver: install default configuration files

2023-01-09 Thread Louis-Philippe Véronneau

Package: puppetserver
Severity: important

At the moment, default configuration files are not installed at all. 
They seem to be shipped in the "ezbake" directory.


Things will probably need to be patched, as we don't use the same 
directories upstream does.


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028333: puppetserver: find an upgrade path from puppet-master

2023-01-09 Thread Louis-Philippe Véronneau

Package: puppetserver
Severity: grave

At the moment, this package doesn't acknowledge the existence of the 
puppet-master package at all. As such, if the two packages are installed 
on the same machines, important breakage is likely.


A proper upgrade path should be found, to make the transition from 
puppet-master to puppetserver seamless.


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028332: puppetserver: please run the upstream testsuite at build

2023-01-09 Thread Louis-Philippe Véronneau

Source: puppetserver
Severity: important

At the moment, this package doesn't run any tests. It should run the 
entire upstream testsuite at build, to validate things work properly.


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028330: puppetserver: please run the upstream testsuite in an autopkgtest

2023-01-09 Thread Louis-Philippe Véronneau

Source: puppetserver
Severity: wishlist

To make this package more robust (the Clojure ecosystem is quite flaky 
in Debian...) we should be running the upstream testsuite in an autopkgtest.


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028328: puppetserver: package should have a puppetserver.classpath file

2023-01-09 Thread Louis-Philippe Véronneau

Source: puppetserver
Severity: normal

The source package doesn't have a d/puppetserver.classpath file and it 
should :)


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028327: puppetserver: binary package should depend on more clojure libraries

2023-01-09 Thread Louis-Philippe Véronneau

Package: puppetserver
Severity: important

This package used to be built as a uberjar, but not anymore. As such, a 
lot of runtime dependencies aren't declared as such in the binary package.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1026723: close bugs created by leiningen breakage

2023-01-06 Thread Louis-Philippe Véronneau

Hi,

These bugs have been fixed with the upload of leiningen 2.10.0-1.

Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028024: libcommons-parent-java: regression between 43-1 and 55-1: Failed to read artifact descriptor for org.apache.commons:commons-compress:jar:debian

2023-01-06 Thread Louis-Philippe Véronneau
On Fri, 6 Jan 2023 10:22:27 -0500 =?UTF-8?B?SsOpcsO0bWUgQ2hhcmFvdWk=?= 
 wrote:
Looking at the pom.xml diff, it seems that version 55-1 introduced a 
dependency on org.junit/junit-bom, which is not packaged in Debian.


org.junit/junit-bom is packaged in Debian, as part of the junit5 package:

junit5: 
/usr/share/maven-repo/org/junit/junit-bom/debian/junit-bom-debian.pom


It's probably not a good idea to include it as a dependency for 
libcommons-parent-java though...


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028024: libcommons-parent-java: regression between 43-1 and 55-1: Failed to read artifact descriptor for org.apache.commons:commons-compress:jar:debian

2023-01-05 Thread Louis-Philippe Véronneau

Package: libcommons-parent-java
Version: 55-1
Severity: important

Hi,

It seems the libcommons-parent-java update between 43-1 and 55-1 broke several 
Clojure packages that build with `leiningen`.

For example, when trying to build `trapperkeeper-metrics-clojure`, the `lein 
jar` step fails with:

Failed to read artifact descriptor for 
org.apache.commons:commons-compress:jar:debian
Failed to read artifact descriptor for commons-codec:commons-codec:jar:debian
Failed to read artifact descriptor for commons-io:commons-io:jar:debian
Failed to read artifact descriptor for 
commons-logging:commons-logging:jar:debian

Same goes for package `raynes-fs-clojure`:

Failed to read artifact descriptor for 
org.apache.commons:commons-compress:jar:debian

Rolling back libcommons-parent-java to version 43-1 does seem to fix the issue. 
I've tried diffing 
/usr/share/maven-repo/org/apache/commons/commons-parent/debian/commons-parent-debian.pom
 between the two versions, but I can't find anything obvious. I've attached 
said diff to this bug report, maybe it'll be of help?

I've marked this 'important', as raynes-fs-clojure is a dependency that's 
widely used in the Clojure ecosystem in Debian.

Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄
diff -W 300 -y -r 
43-1/usr/share/maven-repo/org/apache/commons/commons-parent/debian/commons-parent-debian.pom
 
55-1/usr/share/maven-repo/org/apache/commons/commons-parent/debian/commons-parent-debian.pom
  
 |  
 
-->
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.orghttp://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org
4.0.0  

4.0.0
org.apache.commons   

org.apache.commons
commons-parent 

commons-parent
debian   

debian
pom  

pom



org.apache   

org.apache
apache 

apache
debian   

debian
   




Apache Commons Parent  

Apache Commons Parent
The Apache Commons Parent POM provides common settings for 
all Apache Commons components.
The Apache Commons Parent POM provides common settings for all 
Apache Commons components.

Version 43: 
 <
- maven-compiler-plugin 3.6.1 -> 3.6.2  
 <
- maven-compiler-plugin 3.6.2 -> 3.7.0  
 <
- jacoco-maven-plugin 0.7.7.201606060606 -> 0.7.9   
 <
- maven-javadoc-plugin 2.10.4 -> 3.0.0 (Java 9 compatibility)   

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

2022-12-30 Thread Louis-Philippe Véronneau

On 2022-12-23 17 h 44, Christoph Biedl wrote:

Package: lintian
Version: 2.115.3
Severity: important

Greeting,

my recent upload of file (1:5.43-3) to experiental broke lintian's autopkgtest.

Possibly this is the relevant section.

# Hints do not match
#
# --- 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.specified.calibrated
# +++ 
../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/documentation/manual/files-general/hints.actual.parsed
# +files-general (binary): wrong-compression-in-manual-page 
[usr/share/man/man1/é³¥ã®è©©.1.gz]
#
# Unexpected tags:
#   wrong-compression-in-manual-page
#
#   Failed test 'Lintian passes for files-general'
#   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.

[ 
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian/29591169/log.gz 
]

While I didn't check what precisely went wrong, I reckon it's a slightly
changed output on gz-compressed files.

Can you please check and adjust your tests? I'd like to upload to
unstable in a week or so, and I'd prefer to have no autopkgtest breakage
by then.

Sorry for the mess, and I'm sorry this will happen again - upstream
changes file's output every now and then. The only help I can provide is
to add your package to the list of those that should receive a
notification when uploading a new upstream version, see

 
https://sources.debian.org/src/file/1%3A5.41-4/debian/README.Maintainer/#L16

If you want lintian to be included, just say the word.

Regards,

 Christoph



I can replicate this bug, but I'm currently having trouble understanding
why it happens. My current guess is that the perl regex we're using is
getting confused because the output of file's new version spits out octal
escape values that we're not sanitizing.

Lintian runs file (more precisely, `file --no-pad --print0 --print0 --`)
to get the "file_type" value of files [1].

Then, for all the files in "/usr/share/man/", it verifies .gz files are indeed
gz-compressed with this perl regex match [2]:

if ($item->file_type !~ m/gzip compressed data/)

I built the test files Lintian uses for the autopkgtest and when
I run file 1:5.43-3 on it, I do get an output that should match that regex:

-
foo@bar:/tmp/foo/usr/share/man/man1# file -v

file-5.43
magic file from /etc/magic:/usr/share/misc/magic


foo@bar:/tmp/foo/usr/share/man/man1# file "鳥の詩.1.gz"

\351\263\245\343\201\256\350\251\251.1.gz: gzip compressed data, max 
compression, from Unix, original size modulo 2^32 145

-

I then downgraded file to version 1:5.41-4 and I got a similar output,
but this time, with no octal escape?

-
foo@bar:/tmp/foo/usr/share/man/man1# file -v

file-5.41
magic file from /etc/magic:/usr/share/misc/magic


foo@bar:/tmp/foo/usr/share/man/man1# file 鳥の詩.1.gz"

鳥の詩.1.gz: gzip compressed data, max compression, from Unix, original size 
modulo 2^32 145

-

My perl-foo is pretty bad, but I guess we should be trying to espace or 
sanitize that value?
I also naively tried to install "fonts-noto", but that didn't help :)


[1]: 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index/FileTypes.pm#L75

[2]: 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Documentation/Manual.pm#L140

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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1026766: Acknowledgement (sweethome3d: Crashes with "Assertion `!xcb_xlib_threads_sequence_lost' failed")

2022-12-20 Thread Louis-Philippe Véronneau
c48 8b4c | 2478 448b | 89f4 0100 | 004c 8b94
  0x7f68890adcf8: 2490  | 0045 8b5a | 6c41 f7c3 | 0400  | 
0f84 2401 |  4183 | cb0c c4c1 | 796e c345
  0x7f68890add18: 8b92 a001 |  4585 | d20f 8415 | 0100 0047 | 
8b5c d40c | 49c1 e203 | c4c1 f96e | dac4 c179
  0x7f68890add38: 6ee3 448b | 99fc  | 00c4 c179 | 6ecb 4c8b | 
9424 9000 |  418b | 8aa8 0100 | 0041 8b5a
  0x7f68890add58: 3c45 8b92 | b400  | 4c8b 9c24 | 9000  | 
458b 9b80 |  0048 | 8bbc 2490 |  008b
  0x7f68890add78: 97cc  | 008b afa4 | 0100 008b | 87d0  | 
0045 85c0 | 0f84 4a03 |  49c1 | e103 c4c1
  0x7f68890add98: f96e d148 | c1e5 034c | 8be9 49c1 | e503 4b8d | 
34c4 488b | cf44 8bc3 | 448b 4c24 | 6c8b bc24
  0x7f68890addb8: 9c00  | 8b9c 2480 |  0089 | 1c24 4489 | 
5424 0844 | 895c 2410 | c5fa 1144 | 2418 8954
  0x7f68890addd8: 2420 c5fb | 115c 2428 | c5fa 1164 | 2430 4889 | 
6c24 38c5 | fa11 4c24 | 4089 4424 | 484c 896c
  0x7f68890addf8: 2450 4c8b | 9424 b000 |  4c89 | 5424 5845 | 
33d2 4c89 | 5424 6044 | 8974 2468 | c4e1 f97e

  0x7f68890ade18: ;   {optimized virtual_call}
  0x7f68890ade18: d266 90e8

  0x7f68890ade1c: ; ImmutableOopMap {}
  ;*invokevirtual execute {reexecute=0 rethrow=0 
return_oop=0}
  ; - 
javax.media.j3d.GeometryArrayRetained::execute@237 (line 2290)
  0x7f68890ade1c: 202e  | e9c7 fcff | ff44 8b8c | 24e0  | 
00e9 92fd |  c4c1 | 796e c3e9 | dbfe 
  0x7f68890ade3c: 4533 db45 | 33d2 c4c1 | f96e dbc4 | c179 6ee2 | 
e9e9 feff | ff45 8bf3 | 4c89 9424 | b000 
  0x7f68890ade5c: 4489 8c24 | 8000  | 4533 d244 | 8994 249c | 
 00e9 | b2fd  | 4489 9c24 | 9800 
  0x7f68890ade7c: 488b b424 | 9000  | 488b 5424 | 788b 8c24 | 
8800  | c5fa 1084 | 2484  | 0048 89b4

  0x7f68890ade9c: 24a0 

  0x7f68890adea0: ;   {optimized virtual_call}
  0x7f68890adea0: 0066 90e8

  0x7f68890adea4: ; ImmutableOopMap {[120]=Oop [144]=Oop [160]=Oop }
  ;*invokevirtual updateAlphaInVertexData 
{reexecute=0 rethrow=0 return_oop=1}
  ; - 
javax.media.j3d.GeometryArrayRetained::execute@41 (line 2266)

  0x7f68890adea4: d8eb 19f8

  0x7f68890adea8: ; implicit exception: dispatches to 
0x7f68890ae46c

  0x7f68890adea8: 448b 400c | 4183 f801 | 0f86 e702 |  448b

  0x7f68890adeb8: ;   {oop(a 
'java/lang/Boolean'{0x0004143c3fc8} = true)}
  0x7f68890adeb8: 4010 4181 | f8f9 8787 | 8274 6b45 | 33c0 4489 | 
8424 9c00 |  8b68 | 1445 8b5c


  0x7f68890aded4: ;   {metadata({type array float})}
  0x7f68890aded4: ec08 4181 | fbf8 1a00 | 000f 850d | 0300 004d | 
8d14 ecc5 | fa10 8c24 | 8400  | 4c8b 9c24
  0x7f68890adef4: 9000  | c4c1 782e | 8ba0  | 007a 0274 | 
39c4 c17a | 118b a000 |  448b | b424 8c00
  0x7f68890adf14:  4c89 | 9424 b000 |  4533 | d244 8994 | 
2480  | 00e9 f8fc |  41b8 | 0100 
  0x7f68890adf34: 4489 8424 | 9c00  | eb90 448b | 9c24 9800 | 
 458b | f34c 8994 | 24b0  | 0045 33d2
  0x7f68890adf54: 4489 9424 | 8000  | e9c5 fcff | ffbe f6ff | 
 4889 | 5c24 7044 | 8954 2478 | 4489 4424
  0x7f68890adf74: 7c44 89ac | 2480  | 0044 89b4 | 2484  | 
0044 899c | 2488  | 0089 8424 | 8c00 
  0x7f68890adf94: c5fb 11a4 | 2490  | 00c5 fa11 | b424 9800 | 
 4489 | 8c24 9c00 |  c5fa | 1194 24a0
  0x7f68890adfb4:  00c5 | fa11 9c24 | a400  | 89bc 24a8 | 
 00c5 | fa11 8424 | ac00 


  0x7f68890adfd0: ;   {runtime_call UncommonTrapBlob}
  0x7f68890adfd0:  90e8

  0x7f68890adfd4: ; ImmutableOopMap {rbp=NarrowOop [112]=Oop 
[120]=NarrowOop [144]=Oop [156]=NarrowOop [168]=NarrowOop }
  ;*invokevirtual execute {reexecute=0 rethrow=0 
return_oop=0}
  ; - 
javax.media.j3d.GeometryArrayRetained::execute@477 (line 2336)

  0x7f68890adfd4: 2840 1af8 | 488b ee48 | 8d94 24c0

  0x7f68890adfe0: ;   {runtime_call _complete_monitor_locking_Java}
  0x7f68890adfe0:  00e8

  0x7f68890adfe4: ; ImmutableOopMap {rbp=Oop [120]=Oop [144]=Oop }
  ;*monitorenter {reexecute=0 rethrow=0 return_oop=0}
  ; - 
javax.media.j3d.GeometryArrayRetained::execute@280 (line 2315)

  0x7f68890adfe4: 9869 25f8 | e9
===

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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1026766: sweethome3d: Crashes with "Assertion `!xcb_xlib_threads_sequence_lost' failed"

2022-12-20 Thread Louis-Philippe Véronneau

Package: sweethome3d
Version: 7.0.2+dfsg-3
Severity: important

Dear maintainers,

The latest version of sweethome3d on my system consistently crashes when 
I try to modify an existing file.


This is the error message I get when it crashes:

===
Java 3D: implicit antialiasing enabled
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has 
not been called

[xcb] Aborting, sorry about that.
java: ../../src/xcb_io.c:278: poll_for_event: Assertion 
`!xcb_xlib_threads_sequence_lost' failed.

Aborted
===

Cheers,


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8

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

Versions of packages sweethome3d depends on:
ii  default-jre [java8-runtime] 2:1.17-73
ii  icedtea-netx1.8.8-2
ii  java-wrappers   0.4
ii  libbatik-java   1.16+dfsg-1
ii  libfreehep-graphics2d-java  2.4+dfsg-3
ii  libfreehep-graphicsbase-java2.4+dfsg-3
ii  libfreehep-graphicsio-java  2.4+dfsg-3
ii  libfreehep-graphicsio-svg-java  2.4+dfsg-3
ii  libitext-java   2.1.7-13
ii  libjava3d-java  1.5.2+dfsg-17
ii  libsunflow-java 0.07.2.svn396+dfsg-18
ii  openjdk-11-jre [java8-runtime]  11.0.17+8-2
ii  openjdk-17-jre [java8-runtime]  17.0.5+8-2
ii  openjdk-18-jre [java8-runtime]  18.0.2+9-2

Versions of packages sweethome3d recommends:
ii  sweethome3d-furniture  1.8-1

sweethome3d suggests no packages.

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1026112: ITP: nrepl-incomplete-clojure -- simple Clojure library providing code completion

2022-12-14 Thread Louis-Philippe Véronneau

Package: wnpp
Severity: wishlist
Owner: Louis-Philippe Véronneau 

Package name: nrepl-incomplete-clojure
Version : 0.1.0
URL : https://github.com/nrepl/incomplete
License : EPL-1
Programming Lang: Clojure
Description : simple Clojure library providing code completion

nrepl-incomplete-clojure is a simple Clojure library providing code 
completion. The library was extracted from nREPL's codebase and aims to 
replace clojure-complete.


It is needed to update leiningen, one of the main clojure build tool, to 
the latest upstream version.


I'm planning to maintain this package in the Clojure Team.

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



Bug#1025644: lintian: should not have the update-debian-copyright tag at all

2022-12-06 Thread Louis-Philippe Véronneau

On 2022-12-06 15 h 13, Russ Allbery wrote:

Thorsten Glaser  writes:


The update-debian-copyright tag gives bad advice:



N:   The most recent copyright year mentioned for files in ./debian lags
N:   behind the year in the timestamp for the most recent changelog
N:   entry.



This is a fully normal thing to have. You only update the copyright year
for something when *you* do something relevant for copyright law (that
is passing the threshold of originality) in that year.



Having this tag is misleading because it’ll lead to people bumping the
year because they don’t know better and just to silence lintian.


Yeah, and I'm also dubious that we should be telling people how to manage
their copyright notices at all.  Berne explicitly doesn't require
copyright notices.  Some licenses require them, but I'm not aware of a
license where one is required to update them with new years.  Some
projects use the approach of only updating the years when the files are
changed; others update all years on all files every year (the FSF does
this, for instance, based on legal advice from their lawyers).

This doesn't feel like something Lintian should have an opinion about.



I also agree with your reasoning and I would personally be for its 
removal. I think we should note this was a feature requested in #949201.


As such, I've proposed a MR to make this tag experimental for now. I 
guess if people care about it, they can try to improve it?


https://salsa.debian.org/lintian/lintian/-/merge_requests/431

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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025400: aioprocessing: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

2022-12-03 Thread Louis-Philippe Véronneau

Source: aioprocessing
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025399: sphinx-autobuild: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

2022-12-03 Thread Louis-Philippe Véronneau

Source: sphinx-autobuild
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025396: python-aiosqlite: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

2022-12-03 Thread Louis-Philippe Véronneau

Source: python-aiosqlite
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025398: sphinx: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

2022-12-03 Thread Louis-Philippe Véronneau

Source: sphinx
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025397: pydyf: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

2022-12-03 Thread Louis-Philippe Véronneau

Source: pydyf
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025395: poliastro: please migrate away from pybuild's flit plugin to pybuild's generic pyproject plugin

2022-12-03 Thread Louis-Philippe Véronneau

Source: poliastro
Severity: important
X-Debbugs-CC: deb...@kitterman.com

Dear maintainer,

As you may have seen, pybuild has been supporting building with PEP-612 
style pyproject.toml files via a generic plugin 
(pybuild-plugin-pyproject) for a while now.


As such, we are looking forward the deprecation of pybuild's flit plugin 
in time for the Bookworm freeze.


This package is one of the last ones still using the flit plugin and 
we're asking you to migrate away from it.


Here's an example of how you can migrate to the generic pyproject plugin:

https://salsa.debian.org/python-team/packages/jeepney/-/commit/4448aa88308edde244d43595341b00f53312dd84

In theory, it works as well (or better) than the dedicated flit plugin 
and there should be no regressions.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too

2022-12-02 Thread Louis-Philippe Véronneau

On 2022-12-01 01 h 52, Stuart Prescott wrote:

Hi Scott

On 01/12/2022 15:16, Scott Kitterman wrote:

On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote:

Hi Scott,

On 01/12/2022 02:16, Scott Kitterman wrote:

Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org

The missing-prerequisite-for-pyproject-backend check appears to only
look for the prerequisite packages in Build-Depends, but since they
aren't needed for clean, they could be in Build-Depends-Indep, leading
to false positives.

Scott K


I contemplated filing a similar the other day but in writing it up, I
realised that lintian was correct. Policy requires that the 'clean'
target be functional with only the Build-Depends (and Build-Conflicts)
satisfied, and pybuild + the build-backend dependencies are involved in
the cleaning step.


Not always.  At least with the package I ran into this on, clean works 
fine

without them.


Yes indeed...

- the most obvious case where that works is where 'clean' is explicit in 
d/rules


- it would also be possible for it to work in situations where dh-python 
is (redundantly?) listed in B-D (not B-D-I), since the pyproject 
plugin's 'clean' operation has no dependency on `build`, `installer`, 
and the backend.


However, this for this second case:

- it might result in pybuild picking a different plugin through lack of 
dependencies like `tomli`. That might just work... but also feels 
slightly terrifying.


- there's not _currently_ any backend-specific cleaning code, but 
perhaps there should be, which would then need the deps to be in B-D? 
(Is that in the spec somewhere?)


I guess the main thing to be careful of in any rewording of this 
explanation is that for the most common case of using "%:\n\tdh 
--buildsystem pybuild", dh-python (or pybuild-plugin-pyproject) is 
needed in B-D not B-D-I to be policy-compliant.


cheers
Stuart


I've proposed a fix here:

https://salsa.debian.org/lintian/lintian/-/merge_requests/426

It's not precise enough to flag packages that would declare everything 
as a Build-Depends-Indep though. This would be much more complex and I 
feel this situation is overall pretty rare.


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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1024953: jsonpickle: (autopkgtest) needs update for python3.11: 'NoneType' object has no attribute 'keys'

2022-12-01 Thread Louis-Philippe Véronneau

fixed 1024953 3.0.0
tags 1024953 fixed-upstream
thanks

Hi!

Note that this bug has been fixed upstream, but haven't been released in 
a git tag yet.


I think the changes are too substantial (major version) to patch the 
issue in Debian via quilt.


I asked the upstream maintainer to make a release here: 
https://github.com/jsonpickle/jsonpickle/issues/416


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1024907: deepdiff: (autopkgtest) needs update for python3.11: AssertionError

2022-12-01 Thread Louis-Philippe Véronneau

found 1024907 6.2.1
thanks

Note that I've updated this package to the latest upstream version 
(6.2.1) on Salsa and the problem is still there.


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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

2022-11-29 Thread Louis Bouchard

Hello Salvatore,

Le 28/11/2022 à 19:22, Salvatore Bonaccorso a écrit :

Hi Louis,

The rough plan would be to have it included in the next bullseye point
release. That is scheduled to be on 17th of december[1]. It would be
great to recieve testing feedback actually on the change.

  [1] https://lists.debian.org/debian-live/2022/11/msg6.html

Regards,
Salvatore


Thank you for your quick & precise answer. I really appreciate.

Regards,
...Louis



Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

2022-11-28 Thread Louis Bouchard

Hello Salvatore,


I will likely pick that change as well for the next 5.10.y based
upload via the upcoming point release (it might count as "enabling
furhter hardware support" allowed for stable release updates).

Regards,
Salvatore


This is a very good news.

Would you happen to have an idea on the timetable for the availability 
of the upcoming 5.10 kernel ?


I am currently working on building a custom kernel with this option 
enabled so we can make Bullseye available again on our SEV enabled offer 
until the backport becomes available. If it is expected to happen soon, 
we may elect to wait for an official kernel.


TIA,

Kind regards,

...Louis



Bug#1024971: pybuild: should fail when the result of running tests is "Ran 0 tests in 0.000s"

2022-11-27 Thread Louis-Philippe Véronneau

Package: dh-python
Version: 5.20221122
Severity: wishlist

Dear maintainers,

Too often, a mistake or a misconfiguration leads to no tests being 
detected when trying to run the upstream testsuite.


When this happens, the result of the test command typically looks like 
"Ran 0 tests in 0.000s".


I thought we could catch this via Lintian and warn people, but I just 
realised Lintian does not have access to the build log.


This means if we want people to be aware of what, in my opinion, is a 
build failure, it should be done via pybuild.


As such, it would be nice if pybuild considered this case as a failure 
and exited if it happens. We probably will need to do a MBF beforehand 
though, as I'm sure it happens in tons of packages.


If there are no tests for real, I think it's OK to ask people to disable 
them altogether :)


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1024900: python-mpv: requires update for mpv 0.35.0

2022-11-27 Thread Louis-Philippe Véronneau

On 2022-11-27 13 h 04, Sebastian Ramacher wrote:

Source: python-mpv
Version: 1.0.1-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

mpv is transitioning from libmpv1 to libmpv2. As python-mpv has a
hardcoded dependency on libmpv1, it needs to be updated for libmpv2.

Cheers


Thanks for the heads up.

I've ran the testsuite with libmpv2 and I've reported what I think might 
be failure upstream.


It seems libmpv2 isn't in unstable yet though. I'll wait for it to make 
it through the buildds and I'll make an upload.


Cheers,

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



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1024697: linux-image-5.10.0-19-cloud-amd64: Please backport fix for Bug #989040 : Missing CONFIG_AMD_MEM_ENCRYPT in kernel

2022-11-23 Thread Louis Bouchard

Package: src:linux
Version: 5.10.149-2
Severity: important
X-Debbugs-Cc: lbouch...@scaleway.com

Dear Kernel team,

A fix for bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989040 
is included in kernel 5.13 but still not available for the stable kernel.


Could you please backport the fix for that bug into the stable 5.10 
kernel so it becomes available in a standard Debian Bullseye 
installation. Without this fix, Debian Bullseye is unbootable in

a virtual machine which uses Secure Enhanced Virtualization (SEV).

The fix is the enablement of the CONFIG_AMD_MEM_ENCRYPT configuration 
option.


Kind regards,

... Louis Bouchard


-- Package-specific info:
** Version:
Linux version 5.10.0-19-cloud-amd64 (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2) #1 SMP Debian 5.10.149-2 (2022-10-21)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-19-cloud-amd64 
root=UUID=25db7b8b-fbf8-47bd-b3c6-21fcf4de5f22 ro console=tty0 
console=ttyS0,115200 earlyprintk=ttyS0,115200 consoleblank=0


** Not tainted

** Kernel log:
[1.808563] systemd[1]: Created slice system-systemd\x2dgrowfs.slice.
[1.810794] systemd[1]: Created slice User and Session Slice.
[1.812361] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[1.814189] systemd[1]: Started Forward Password Requests to Wall 
Directory Watch.
[1.816108] systemd[1]: Set up automount Arbitrary Executable File 
Formats File System Automount Point.

[1.818610] systemd[1]: Reached target Local Encrypted Volumes.
[1.820342] systemd[1]: Reached target Paths.
[1.821643] systemd[1]: Reached target Remote File Systems.
[1.823172] systemd[1]: Reached target Slices.
[1.824216] systemd[1]: Reached target Swap.
[1.825333] systemd[1]: Reached target System Time Set.
[1.826843] systemd[1]: Listening on Syslog Socket.
[1.827821] systemd[1]: Listening on fsck to fsckd communication Socket.
[1.829095] systemd[1]: Listening on initctl Compatibility Named Pipe.
[1.830420] systemd[1]: Listening on Journal Audit Socket.
[1.831536] systemd[1]: Listening on Journal Socket (/dev/log).
[1.832700] systemd[1]: Listening on Journal Socket.
[1.833727] systemd[1]: Listening on udev Control Socket.
[1.834743] systemd[1]: Listening on udev Kernel Socket.
[1.836088] systemd[1]: Mounting Huge Pages File System...
[1.837358] systemd[1]: Mounting POSIX Message Queue File System...
[1.838852] systemd[1]: Mounting Kernel Debug File System...
[1.840422] systemd[1]: Mounting Kernel Trace File System...
[1.841929] systemd[1]: Starting Create list of static device nodes 
for the current kernel...

[1.843833] systemd[1]: Starting Load Kernel Module configfs...
[1.845439] systemd[1]: Starting Load Kernel Module drm...
[1.846871] systemd[1]: Starting Load Kernel Module fuse...
[1.848423] systemd[1]: Started Nameserver information manager.
[1.851234] systemd[1]: Condition check resulted in Set Up Additional 
Binary Formats being skipped.
[1.852026] systemd[1]: Condition check resulted in File System Check 
on Root Device being skipped.

[1.853998] systemd[1]: Starting Journal Service...
[1.856523] systemd[1]: Starting Load Kernel Modules...
[1.858154] systemd[1]: Starting Remount Root and Kernel File Systems...
[1.859700] fuse: init (API version 7.32)
[1.859981] systemd[1]: Starting Coldplug All udev Devices...
[1.862214] systemd[1]: Mounted Huge Pages File System.
[1.863194] systemd[1]: Mounted POSIX Message Queue File System.
[1.864151] systemd[1]: Mounted Kernel Debug File System.
[1.865057] systemd[1]: Mounted Kernel Trace File System.
[1.866053] systemd[1]: Finished Create list of static device nodes 
for the current kernel.

[1.867461] systemd[1]: modprobe@configfs.service: Succeeded.
[1.868030] systemd[1]: Finished Load Kernel Module configfs.
[1.869046] systemd[1]: modprobe@drm.service: Succeeded.
[1.869620] systemd[1]: Finished Load Kernel Module drm.
[1.870609] systemd[1]: modprobe@fuse.service: Succeeded.
[1.871568] systemd[1]: Finished Load Kernel Module fuse.
[1.873149] systemd[1]: Finished Load Kernel Modules.
[1.875661] systemd[1]: Mounting FUSE Control File System...
[1.877313] systemd[1]: Mounting Kernel Configuration File System...
[1.879176] systemd[1]: Starting Apply Kernel Variables...
[1.880825] systemd[1]: Mounted FUSE Control File System.
[1.882063] systemd[1]: Mounted Kernel Configuration File System.
[1.895464] systemd[1]: Finished Apply Kernel Variables.
[1.897833] systemd[1]: Started Journal Service.
[1.904694] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro
[1.917029] EXT4-fs (sda1): resizing filesystem from 491515 to 
2408634 blocks
[1.920492] systemd-journald[286]: Received client request to flush 
runtime journal.

[1.989419] EXT4-fs (sda1

Bug#1024166: blist: dead upstream, no maintainer upload since 2015

2022-11-15 Thread Louis-Philippe Véronneau

Package: src:blist
Severity: serious
X-Debbugs-CC: s...@debian.org

Hi,

The blist package, currently team-maintained by the Debian Python Team, 
has not been updated by its maintainer since 2015. 4 uploads fixing 
either important bugs, or making sure it respects the DPT policy have 
been made since then.


As such, I consider this package is not currently maintained by anyone, 
and thus violates the DPT policy.


Moreover, blist is dead upstream: no commit has been made to the project 
since 2014. This is problematic, as we are now carrying patches for 
Python 3.9, 3.10 and 3.11.


As such, I don't think this package should make it to Bookworm. It 
probably should eventually be RMed too.


I'm CC-ing Sebastien Delafond explicitly, as he seems to be the 
maintainer of all the packages in the archive that depend or 
build-depend on blist (python-raccoon, python-panwid, elastalert).


In a perfect world, those packages should migrate away from blist in 
time for the freeze. If not possible, it would be nice if it could have 
an active maintainer again.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1024096: rdiff-backup: please run the upstream testsuite

2022-11-14 Thread Louis-Philippe Véronneau

Package: src:rdiff-backup
Version: 2.0.5-4
Severity: important

Hi,

While working on sponsoring a patch for rdiff-backup, I saw that the 
upstream testsuite (which seems pretty complete) isn't ran at all, 
neither during the build process, nor as an autopkgtest.


Running the upstream testsuite helps catch important bugs and make 
packages more reliable.


Cheers,

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


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

2022-10-30 Thread Louis-Philippe Véronneau

Package: devscripts
Severity: wishlist

Dear maintainers,

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


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

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


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

Cheers,

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

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



Bug#997972: haskell-pandoc-citeproc has been deprecated upstream

2022-10-13 Thread Louis-Philippe Véronneau

retitle 997972 haskell-pandoc-citeproc not needed, should be RMed
thanks

Hello!

I see that pandoc has been updated (many, many thanks) and the 
aforementioned 'citeproc' package has indeed been packaged as 
"haskell-citeproc".


I see no reason for this package not to be RMed, since the current 
version of pandoc in Sid supports '--citeproc' and fails with the old 
'--filter pandoc-citeproc' anyway:


---
pandoc-citeproc: Error in $: Incompatible API versions: encoded with 
[1,22,2] but attempted to decode with [1,20].

CallStack (from HasCallStack):
  error, called at ./Text/Pandoc/JSON.hs:112:48 in 
pandoc-types-1.20-JP83YEZp4VZ5qbwCPN8866:Text.Pandoc.JSON

Error running filter pandoc-citeproc:
Filter returned error status 1
make: *** [Makefile:6: pdf] Error 83
---

Cheers, and thanks for your work on this.

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


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021590: iptables: segfault when renaming a chain

2022-10-11 Thread Louis Bouchard

Package: iptables
Version: 1.8.8-1
Severity: important
Tags: upstream
X-Debbugs-Cc: lbouch...@scaleway.com

This is the description for the upstream fix of this bug[1] :

This is an odd bug: If the number of chains is right and one renames the
last one in the list, libiptc dereferences a NULL pointer.

Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream.
This bug is to have the fix included in Debian in order to avoid such
segmentation faults.

For Sid, iptables uses the new nft libraries so the problem
does not appear unless the -legacy commands are used.

The following code (adapted from the upstream commit to work on Sid)
may be used to reproduce the issue :
8<
#!/bin/bash
#
# Cover for a bug in libiptc:
# - the chain 'node-98-tmp' is the last in the list sorted by name
# - there are 81 chains in total, so three chain index buckets
# - the last index bucket contains only the 'node-98-tmp' chain
# => rename temporarily removes it from the bucket, leaving a NULL
# bucket
# behind which is dereferenced later when inserting the chain again with
# new
# name again

(
 echo "*filter"
  for chain in node-1 node-10 node-101 node-102 node-104 node-107
  node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18
  node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27
  node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36
  node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45
  node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54
  node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62
  node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71
  node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9
  node-92 node-93 node-95 node-98-tmp; do
echo ":$chain - [0:0]"
   done
   echo "COMMIT"
  ) | $XT_MULTI iptables-legacy-restore
  $XT_MULTI iptables-legacy -E node-98-tmp node-98
  exit $?

>8

  [1] 
http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f



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

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

Versions of packages iptables depends on:
ii  libc62.35-3
ii  libip4tc21.8.8-1
ii  libip6tc21.8.8-1
ii  libmnl0  1.0.4-3
ii  libnetfilter-conntrack3  1.0.9-2
ii  libnfnetlink01.0.2-2
ii  libnftnl11   1.2.3-1
ii  libxtables12 1.8.8-1
ii  netbase  6.3

Versions of packages iptables recommends:
pn  nftables  

Versions of packages iptables suggests:
pn  firewalld  
ii  kmod   30+20220905-1

-- no debconf information



  1   2   3   4   5   6   7   8   9   10   >