Bug#1066136: python3-xapian-haystack: unusable on stable due to use of deprecated module django.utils.six

2024-03-12 Thread Ole Peder Brandtzæg
Package: python3-xapian-haystack
Version: 2.1.1-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Dear Maintainer,

I installed python3-xapian-haystack in order to employ Xapian as a
Haystack backend in mailman3-web on stable (bookworm).

However, upon actually trying to use it, I got the following traceback:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
47, in inner
response = get_response(request)
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 181, 
in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python3/dist-packages/hyperkitty/views/search.py", line 54, in 
search
results = EmptySearchQuerySet()
  File "/usr/lib/python3/dist-packages/haystack/query.py", line 25, in __init__
self._determine_backend()
  File "/usr/lib/python3/dist-packages/haystack/query.py", line 58, in 
_determine_backend
self.query = connections[backend_alias].get_query()
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 114, in 
__getitem__
self.thread_local.connections[key] = load_backend(
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 60, in 
load_backend
return import_class(full_backend_path)
  File "/usr/lib/python3/dist-packages/haystack/utils/loading.py", line 22, in 
import_class
module_itself = importlib.import_module(module_path)
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1206, in _gcd_import

  File "", line 1178, in _find_and_load

  File "", line 1149, in _find_and_load_unlocked

  File "", line 690, in _load_unlocked

  File "", line 940, in exec_module

  File "", line 241, in _call_with_frames_removed

  File "/usr/lib/python3/dist-packages/xapian_backend.py", line 10, in 
from django.utils import six

Exception Type: ImportError at /hyperkitty/search
Exception Value: cannot import name 'six' from 'django.utils' 
(/usr/lib/python3/dist-packages/django/utils/__init__.py)

django.utils.six was removed in Django 3.0; the version of Django in
stable is 3.2. Hence python3-xapian-haystack is currently unusable in
stable, as it simply throws an ImportError upon loading.

Upstream fixed this issue when they dropped Python 2 support in [0].
However, I have a simpler patch that just removes the six import and
changes all occurences of `six.moves.range()` to the built-in `range()`,
which I've applied locally (hence the debsums complaint) and seems to do
the trick.

I would very much like a stable-update for this given that the package
simply does not work without the patch.

Many thanks,
Ole

[0]: 
https://github.com/notanumber/xapian-haystack/commit/0f9d94fb23ebf8cf194a3a88948a86f6dc69e786#diff-b4466d919fc4105c6306804abd396d6e0ba5e4630346928df34a5308c4700d97

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

Kernel: Linux 6.7.8 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_DK:en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-xapian-haystack depends on:
ii  python3  3.11.2-1+b1
ii  python3-django-haystack  3.2.1-1
ii  python3-xapian   1.4.22-1

python3-xapian-haystack recommends no packages.

python3-xapian-haystack suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/xapian_backend.py (from 
python3-xapian-haystack package)
--- xapian_backend.py   2017-05-18 08:50:23.0 +0200
+++ /usr/lib/python3/dist-packages/xapian_backend.py2024-03-12 
01:06:33.011301452 +0100
@@ -7,7 +7,6 @@
 import shutil
 import sys
 
-from django.utils import six
 from django.conf import settings
 from django.core.exceptions import ImproperlyConfigured
 from django.utils.encoding import force_text
@@ -346,7 +345,7 @@
 def _get_ngram_lengths(value):
 values = value.split()
 for item in values:
-for ngram_length in six.moves.range(NGRAM_MIN_LENGTH, 
NGRAM_MAX_LENGTH + 1):
+for ngram_length in range(NGRAM_MIN_LENGTH, 
NGRAM_MAX_LENGTH + 1):
 yield item, ngram_length
 
 for obj in iterable:
@@ -356,8 +355,8 @@
 def ngram_terms(value):
 for item, length in _get_ngram_lengths(value):
 item_length = len(item)
-for start in six.moves.range(0, item_length - length + 
1):
-for size in six.moves.range(length, length + 1):
+  

Bug#1054097: ITP: libparse-man-perl -- Perl library for parsing nroff-formatted manpages

2023-10-17 Thread Ole Peder Brandtzæg
On Tue, Oct 17, 2023 at 09:25:50AM +0300, Andrius Merkys wrote:
> I have just uploaded libparse-man-perl. You may find its packaging
> repository on salsa:
> 
> https://salsa.debian.org/perl-team/modules/packages/libparse-man-perl
> 
> Feel free to add yourself to the list of its uploaders.

Many thanks! My request for a Salsa account was just approved, so will
familiarise myeslf with the machinery now. =)

Best,
Ole

-- 
Ole Peder Brandtzæg | En KLST/ITK-hybrid
We drive, we sleep, we drive some more.



Bug#1054001: ITP: libapp-sdview-perl -- terminal document viewer for POD and other syntaxes

2023-10-16 Thread Ole Peder Brandtzæg
On Mon, Oct 16, 2023 at 09:25:01AM +0200, gregor herrmann wrote:
> This should probably be named sdview, as per
> https://perl-team.pages.debian.net/policy.html#Package_Naming_Policy

Ah, indeed, thanks; will retitle.

> I've also thought about packing it after reading about it :)

=)

> Indeed!
> Please check out
> https://wiki.debian.org/Teams/DebianPerlGroup/Welcome
> as a starter

Great, looking at it now. (Side note: the «Create an account on Salsa»
link points to https://signup.salsa.debian.org/, which as far as I can
tell is for team creation; https://salsa.debian.org/users/sign_up seems
to take me to the right place.)

-- 
Ole Peder Brandtzæg | En KLST/ITK-hybrid
I have been asked to tell you
that your cries of anguish are keeping the whole neighborhood awake.



Bug#1054097: ITP: libparse-man-perl -- Perl library for parsing nroff-formatted manpages

2023-10-16 Thread Ole Peder Brandtzæg
Package: wnpp
Severity: wishlist
Owner: Andrius Merkys 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libparse-man-perl
  Version : 0.03
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/dist/Parse-Man
* License : Perl 5
  Programming Lang: Perl
  Description : Perl library for parsing nroff-formatted manpages

Parse::Man, an abstract subclass of Parser::MGC, recognises nroff
grammar from a file or string value. It invokes methods when various
nroff directives are encountered. It is intended that this class be used
as a base class, with methods provided to handle the various directives
and formatting options. Typically a subclass will store intermediate
results in a data structure, building it as directed by these method
invocations.

This is a dependency of sdview/libapp-sdview-perl (see #1054001);
Andrius expressed interest in having Parse::Man in Debian and offered to
package it, hence I've marked him as the owner of this bug.

All the best,
Ole



Bug#1054001: ITP: libapp-sdview-perl -- terminal document viewer for POD and other syntaxes

2023-10-15 Thread Ole Peder Brandtzæg
On Sun, Oct 15, 2023 at 07:49:58PM +0300, Andrius Merkys wrote:
> Hi Ole,

Hi Andrius;

> I am as well interested in having Parse::Man in Debian. I can help you by
> packaging it if you wish.

Wonderful, should I just file another wnpp bug for it?

-- 
Ole Peder Brandtzæg | En KLST/ITK-hybrid
Hur snabbt måste man köra för att överleva i någons minne



Bug#1054001: ITP: libapp-sdview-perl -- terminal document viewer for POD and other syntaxes

2023-10-15 Thread Ole Peder Brandtzæg
Package: wnpp
Severity: wishlist
Owner: Ole Peder Brandtzæg 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libapp-sdview-perl
  Version : 0.13
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/dist/App-sdview
* License : Perl 5
  Programming Lang: Perl
  Description : terminal document viewer for POD and other syntaxes

The App::sdview module implements a terminal-based program for viewing
structured documents. It currently understands POD, some simple Markdown
formatting, and a basic understanding of nroff (for manpages). The
accompanying sdview script runs the App::sdview program, which renders a
structured document to a terminal output, via the less pager.

Why is this package useful/relevant?


I've found reading the documentation of various Perl modules using
sdview to be a very pleasant experience. Obviously, perldoc already
exists for this purpose, but the syntax highlighting sdview offers makes
for a much better reading experience in my opinion.

As the description notes, the support for manpages is quite rudimentary;
in my testing, the manpage for ls renders fine, whereas the manpage of
man itself does not:

⚘ ~ sdview man
Expected (?^u:\
) in /usr/share/man/man1/man.1.gz on line 1 at:
'\" t
 ^

I'm not sure if the package including such unstable features is a
blocker for packaging it; apologies for the noise if so. However, I
believe its POD support is the main selling point.

How do you plan to maintain it?
===

This would be my first Debian package, so I would need a sponsor (and
most likely a bit of mentoring). The Debian Perl Group seems to be a
natural fit for the package, but I would be happy to maintain it on my
own or co-maintain it with them/anyone else.

libapp-sdview-perl does depend on a few other modules (all by the same
upstream author) not presently packaged in Debian, so they would need to
be packaged, too, but I figured I should file this first. They are:

- Object::Pad::FieldAttr::Checked [0]
- Parse::Man [1]
- String::Tagged::Markdown [2]

All the best,
Ole

[0]: https://metacpan.org/dist/Object-Pad-FieldAttr-Checked
[1]: https://metacpan.org/dist/Parse-Man
[2]: https://metacpan.org/dist/String-Tagged-Markdown


Bug#1011440: libsnmp-perl: behaviour fixed in do_not_callback_for_failed_reports.diff reintroduced in bullseye

2022-05-23 Thread Ole Peder Brandtzæg
On Mon, May 23, 2022 at 11:00:55PM +1000, Craig Small wrote:
>   It looks like that offending code wasn't removed, it was just
> relocated further along [1].

Ah, my bad! All the indentation differences in the original patch made
it unclear to me what it actually did…

> Looking at what they have done for net-snmp 5.9.2 snmplib/snmp_api.c
> isn't changed between 5.9 and 5.9.2 so I'll apply it as the problem
> isn't going away.

Wonderful, thanks a bunch. I presume this won't land in stable anytime
soon though, right, but maybe in backports?

> Your bug report was fine BTW. If there was an easy proof of concept
> that is even better but this looks like its a timing issue with
> delayed responses. The information helped get a resolution for me
> pretty quickly.

That's good to hear. Duly noted re: the PoC!

All the best,
Ole

-- 
Ole Peder Brandtzæg | Assistant Manager, ITK
I can see you now, as through a screen
A smile on your face, your fingers dripping kerosene



Bug#1011440: libsnmp-perl: behaviour fixed in do_not_callback_for_failed_reports.diff reintroduced in bullseye

2022-05-22 Thread Ole Peder Brandtzæg
Package: libsnmp-perl
Version: 5.9+dfsg-3+b1
Severity: normal
Tags: upstream

Dear Maintainer,

Upon upgrading from buster to bullseye this weekend, which included
libsnmp-perl going from 5.7.3 to 5.9, we noticed that one of our Perl
scripts utilising SNMP started segfaulting. Stacktraces[0] indicate
similar behaviour to what Steinar H. Gunderson described in his
do_not_callback_for_failed_reports patch.[1] Looking at the source tree,
it appears this patch was commented out just after 5.8 was released,[2]
presumably due to this upstream refactor of the receive API.[3] My
knowledge of both C and SNMP is unfortunately too lacking for it to be
apparent to me what would need to change to make it possible to reapply
the patch to the refactored functions. Any ideas on how to proceed?

All the best,
Ole Peder Brandtzæg

P.S. This is my time reporting a bug with a Debian package – do let me
know if I've done something wrong or you require additional information!

[0]: https://pastebin.com/366kWZNS
[1]: https://marc.info/?l=net-snmp-coders=141374910528458=3
[2]:
https://salsa.debian.org/debian/net-snmp/-/commit/20442f3b7a0410f5da27399017436c623c705415?page=2
[3]:
https://github.com/net-snmp/net-snmp/commit/a9ce31c4b8187aea07a648cf115e956159ac072e

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

Kernel: Linux 5.17.5 (SMP w/40 CPU threads; PREEMPT)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_DK:en_US:en_GB:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages libsnmp-perl depends on:
ii  libc6   2.31-13+deb11u3
ii  libnetsnmptrapd40   5.9+dfsg-3+b1
ii  libsnmp40   5.9+dfsg-3+b1
ii  perl5.32.1-4+deb11u2
ii  perl-base [perlapi-5.32.0]  5.32.1-4+deb11u2

libsnmp-perl recommends no packages.

libsnmp-perl suggests no packages.

-- no debconf information